From Chris.Dearlove@baesystems.com Thu Jul 1 02:02:48 2010 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 9AFF63A67AE for ; Thu, 1 Jul 2010 02:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_50=0.001, 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 lIjSZfqq7kRv for ; Thu, 1 Jul 2010 02:02:47 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id DA63B3A63EC for ; Thu, 1 Jul 2010 02:02:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,518,1272841200"; d="scan'208";a="73896760" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 01 Jul 2010 10:02:57 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o6192uB6026585; Thu, 1 Jul 2010 10:02:57 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jul 2010 10:02:57 +0100 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: Thu, 1 Jul 2010 10:02:55 +0100 Message-ID: In-Reply-To: <4C2B801B.1070004@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] Call for comments to a new AUTOCONF charter proposal. thread-index: AcsYeoMVeeYlzuj3RBWPZfhqutHWLAAgD0NA References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net> <4C2B801B.1070004@earthlink.net> From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , "Jari Arkko" , X-OriginalArrivalTime: 01 Jul 2010 09:02:57.0046 (UTC) FILETIME=[32A17B60:01CB18FC] Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. 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, 01 Jul 2010 09:02:48 -0000 Charles Perkins > I'd be happy if it were possible for [autoconf] to > be allowed to consider the excellent body of work that > was seen already years ago -- the same body of work > that motivated me and others to create and spend a lot > of time over the last years and years. If Charlie can find a few like-minded people to work on that, why not add this as a parallel activity? The rationale of why two cases should be straightforward to make, they are almost chalk and cheese in e.g. centralised versus non-centralised. This is actually added safety to the group producing something, as if one succeeds and the other fails, that's still good. Unfortunately, I can't offer to be one of those people. Although I should be able to contribute at the read and comment level, more than that is needed. I only didn't make the suggestion earlier as it needs people (with all due respect to Charlie, plural) to do the work. -- 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 ******************************************************************** 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 emmanuel.baccelli@gmail.com Thu Jul 1 02:28:29 2010 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 AB4C93A68A5 for ; Thu, 1 Jul 2010 02:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 943c9NaPa2HN for ; Thu, 1 Jul 2010 02:28:28 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id F02823A67F7 for ; Thu, 1 Jul 2010 02:28:27 -0700 (PDT) Received: by ewy22 with SMTP id 22so748548ewy.31 for ; Thu, 01 Jul 2010 02:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=RYHUI5iqKdWvFrv6qIkJ934MxioWSHh6Ee5LmuabNLQ=; b=k34BgKz+xWmVB8Mwi8JoBgO3tGLO7O2ZVdDhVGR7rFj5rWhehlzP7JH5Plztbi+Auh AC+kODCI7uYimnSkXL1OfaspB4kVwh8wrhelueH6GsQvdVIxZ/0QB2cDUs7gLWcnwGhA 4SQ8cP2lwulbYEHU+prfCbfgrBcdz7HlvSbuw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=ohdC0un3p17WV68AszEqXQ+1KJTPQLxBN+n5dBFUOhH/5EgSoRt2/INrhAEDFV56Xi fZIhJKOPXdDBKnmixs5HR7Av57dMesct6145PFOHgc6G88X5sUb1Y+dcN1oe2bVfo32D QQ6r7bvTo0kJ9u1Oqg0t0uK4yJw83lWhLeWT0= Received: by 10.213.101.8 with SMTP id a8mr4846496ebo.71.1277976515262; Thu, 01 Jul 2010 02:28:35 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.216.173.198 with HTTP; Thu, 1 Jul 2010 02:28:15 -0700 (PDT) In-Reply-To: References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> <4C2A723E.3020806@piuha.net> <4C2B801B.1070004@earthlink.net> From: Emmanuel Baccelli Date: Thu, 1 Jul 2010 11:28:15 +0200 X-Google-Sender-Auth: xUNxGhVpZCuJZVVJcAi7nIRutRQ Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=0015174bf1ca39381c048a501861 Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. 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, 01 Jul 2010 09:28:29 -0000 --0015174bf1ca39381c048a501861 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 1, 2010 at 11:02 AM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > Charles Perkins > > I'd be happy if it were possible for [autoconf] to > > be allowed to consider the excellent body of work that > > was seen already years ago -- the same body of work > > that motivated me and others to create and spend a lot > > of time over the last years and years. > > If Charlie can find a few like-minded people to work on > that, why not add this as a parallel activity? The > rationale of why two cases should be straightforward to > make, they are almost chalk and cheese in e.g. centralised > versus non-centralised. This is actually added safety to > the group producing something, as if one succeeds and the > other fails, that's still good. > I also think this parallel approach could be appropriate too. > > Unfortunately, I can't offer to be one of those people. > Although I should be able to contribute at the read and > comment level, more than that is needed. I only didn't > make the suggestion earlier as it needs people (with > all due respect to Charlie, plural) to do the work. > > I'd be happy to help out on the matter. So I guess we have a plural + contributors ;) cheers, Emmanuel --0015174bf1ca39381c048a501861 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jul 1, 2010 at 11:02 AM, Dearlov= e, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:
Charles Perkins
> I'd be happy if it were possible for [autoconf] = to
> be allowed to consider the excellent body of work that
> was seen already years ago -- the same body of work
> that motivated me and others to create and spend a lot
> of time over the last years and years.

If Charlie can find a few like-minded people to work on
that, why not add this as a parallel activity? The
rationale of why two cases should be straightforward to
make, they are almost chalk and cheese in e.g. centralised
versus non-centralised. This is actually added safety to
the group producing something, as if one succeeds and the
other fails, that's still good.

I also think this parallel approach could be appropriate too.

=A0

Unfortunately, I can't offer to be one of those people.
Although I should be able to contribute at the read and
comment level, more than that is needed. I only didn't
make the suggestion earlier as it needs people (with
all due respect to Charlie, plural) to do the work.



I'd be happy to help out on the matter. So I guess we have a plural + = contributors ;)

cheers,

Emmanuel

--0015174bf1ca39381c048a501861-- From jari.arkko@piuha.net Thu Jul 1 13:30:25 2010 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 CD0583A6825 for ; Thu, 1 Jul 2010 13:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.614 X-Spam-Level: X-Spam-Status: No, score=-0.614 tagged_above=-999 required=5 tests=[AWL=-0.615, 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 VekXcQQHR6hu for ; Thu, 1 Jul 2010 13:30:23 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 412D13A67F5 for ; Thu, 1 Jul 2010 13:30:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A1D3D2CED3 for ; Thu, 1 Jul 2010 23:30:22 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZPJU8MtvRuy for ; Thu, 1 Jul 2010 23:30:22 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id D672C2CC62 for ; Thu, 1 Jul 2010 23:30:21 +0300 (EEST) Message-ID: <4C2CFADD.3040909@piuha.net> Date: Thu, 01 Jul 2010 23:30:21 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "autoconf@ietf.org" References: <4C2A6BB7.1000900@piuha.net> In-Reply-To: <4C2A6BB7.1000900@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 01 Jul 2010 20:30:25 -0000 I wanted to send a follow-up for two reasons. First, I received a proposal for slightly changed text from Mark and I wanted to get it out for your review as well. Please see the changed text at the end of this e-mail. Secondly, I understand that some people have had (as they should) concerns over the process of making late changes to an already approved document. In general, we try to not make any substantive changes to documents once they are approved, and the bar for making changes is definitely high. Almost all documents have some editorial changes as they go through the RFC Editor and the author's final reviews. In a small number of documents there's a technical issue that we detect after approval. We would normally not make any changes even in these cases unless there was a clear error. Minor obvious fixes may get done through a discussion of the chairs, authors, and ADs, but for anything of substantial nature we try to bring the issue to the working group. If the issue is really severe and requires large changes we cancel the approval and bring the document back to the working group, redoing last calls and other reviews so that the new version can be approved again. In this case we approved the document during IETF-77 but a few days later Erik Nordmark brought up an issue which in his mind was serious, at ietf@ietf.org mailing list. During the meeting we had some discussion about it on the list but never closed the issue. I talked to Erik face to face and did come to an agreement, but since I was busy I did not find time to follow up with concrete text proposal until much later. Two weeks ago I finally had text to send out, the same text proposal that I posted to the WG mailing list in this thread. In the meantime the RFC Editor has done their share of the work and the document is now in AUTH48, only waiting for the resolution of this issue to be published. We have not had a substantial discussion of the proposal yet with Erik -- he has acknowledged that he's seen the proposal but has been too busy at day job to do a detailed review. He has promised to provide feedback in the next few days. In the meantime I wanted to bring the issue up with the working group so that you know what is going on. Ultimately, it is your call to make changes. No single person's opinion can change the document at this stage, be it Erik, the ADs, or the authors. That being said, we do try to fix problems if there are some. In this particular issue, I personally believe that despite's Erik's concern the document as approved was factually correct. However, at the same time I think that the document could have been clearer about what it is saying about routing protocols and what it is not. That was the basis of my suggested edit. I think this edit, if agreed, is somewhere between an editorial and technical change and something that can be done in AUTH48 with the working group's acceptance. In other words, it is not necessary to redo the approval process. Jari --------------- OLD: Routing protocols running on a router may exhibit different requirements for uniqueness of interface addresses; some have no such requirements, others have requirements ranging from local uniqueness only, to uniqueness within, at least, the routing domain (as defined in [RFC1136]). Configuring an IP address that is unique within the routing domain satisfies the less stringent uniqueness requirements of local uniqueness, while also enabling protocols which have the most stringent requirements of uniqueness within the routing domain. This suggests the following principle: o an IP address assigned to an interface that connects to a link with undetermined connectivity properties should be unique, at least within the routing domain. NEW: Routing protocols running on a router may exhibit different requirements for uniqueness of interface addresses; some have no such requirements, others have requirements ranging from local uniqueness only, to uniqueness within, at least, the routing domain (as defined in [RFC1136]). Routing protocols that do not require unique IP addresses within the routing domain utilize a separate unique identifier within the routing protocol itself that must also be configured in some manner. Nevertheless, configuring an IP address that is unique within the routing domain satisfies the less stringent uniqueness requirements of local uniqueness, while also enabling protocols which have the most stringent requirements of uniqueness within the routing domain. As a result, the following principle allows for IP autoconfiguration to apply to the widest array of routing protocols: o an IP address assigned to an interface that connects to a link with undetermined connectivity properties should be unique, at least within the routing domain. And in Section 6.1: OLD: o There is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, hence they cannot be used to reliably identify routers (it is often desirable to identify a router with an IP address). NEW: o There is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, hence they cannot be used to reliably identify routers, should this be necessary by the routing protocol for which IP address autoconfiguration is being provided. OLD: Therefore, autoconfiguration solutions should be encouraged to primarily focus on configuring IP addresses that are not IPv6 link- local. NEW: Therefore, an autoconfiguration solution which provides a mechanism for assigning addresses with a wider scope than IPv6 link-local alone will be more generally useful than one that does not. From teco@inf-net.nl Fri Jul 2 00:36:22 2010 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 7562C3A6812 for ; Fri, 2 Jul 2010 00:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=1.115, 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 b0kk4LVCV9E7 for ; Fri, 2 Jul 2010 00:36:20 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 47BFC3A67CF for ; Fri, 2 Jul 2010 00:36:19 -0700 (PDT) Received: by wyg36 with SMTP id 36so403562wyg.31 for ; Fri, 02 Jul 2010 00:36:27 -0700 (PDT) Received: by 10.213.42.5 with SMTP id q5mr3402120ebe.52.1278056184145; Fri, 02 Jul 2010 00:36:24 -0700 (PDT) Received: from [192.168.2.168] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id a48sm3072747eei.0.2010.07.02.00.36.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Jul 2010 00:36:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Fri, 2 Jul 2010 09:36:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9B013BAF-D5BE-470E-9498-4EF4A1DD2C2F@inf-net.nl> References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> <4C2A723E.3020806@piuha.net> To: Zach Shelby , Jari Arkko X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. 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, 02 Jul 2010 07:36:22 -0000 Zach Shelby: > There the approach is to enable autoconfiguration with either DHCP or = using a multihop DAD technique.=20 RFC 3315: client SHOULD perform DAD, so I would not say "or". I prefer the draft charter text, where DAD is out of scope for now.=20 Draft charter text: > No new duplicate address detection mechanisms are will be specified = as a part of the first item; it is expected that address uniqueness is = guaranteed by the central node alone. Central node duplicate avoidance may be based on globally-unique = identifiers on all nodes, such as DHCPv6 DUID. Let's define our assumption here, to avoid looped discussions. We assume all nodes have guaranteed globally unique identifiers on = forehand, either link-layer addresses or vendor assigned identifiers. Otherwise, using DHCPv6 is questionable. Teco.= From zach@sensinode.com Fri Jul 2 01:04:33 2010 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 9BF773A6863 for ; Fri, 2 Jul 2010 01:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.873 X-Spam-Level: X-Spam-Status: No, score=-2.873 tagged_above=-999 required=5 tests=[AWL=0.726, 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 xnOShtqo2uyK for ; Fri, 2 Jul 2010 01:04:32 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 939D03A6847 for ; Fri, 2 Jul 2010 01:04:31 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o6284d1B015558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Jul 2010 11:04:39 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <9B013BAF-D5BE-470E-9498-4EF4A1DD2C2F@inf-net.nl> Date: Fri, 2 Jul 2010 11:04:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9070BBB2-5228-4C9B-8040-2FF25D0824B1@sensinode.com> References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> <4C2A723E.3020806@piuha.net> <9B013BAF-D5BE-470E-9498-4EF4A1DD2C2F@inf-net.nl> To: Teco Boot X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. 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, 02 Jul 2010 08:04:33 -0000 Hi Teco, On Jul 2, 2010, at 10:36 AM, Teco Boot wrote: > Zach Shelby: >> There the approach is to enable autoconfiguration with either DHCP or = using a multihop DAD technique.=20 >=20 > RFC 3315: client SHOULD perform DAD, so I would not say "or". > I prefer the draft charter text, where DAD is out of scope for now.=20 Ahh, I wasn't suggesting that you do that in Autoconf. Just some = background info on the solution in 6LoWPAN. There DAD is also not = performed on EUI-64 based addresses. Over there the situation is = different as there are sometimes 16-bit short MAC addresses to deal with = which require either DHCPv6 or random generation with DAD to use. Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From henning.rogge@fkie.fraunhofer.de Fri Jul 2 01:11:15 2010 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 4FD2C3A6863 for ; Fri, 2 Jul 2010 01:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.314 X-Spam-Level: X-Spam-Status: No, score=0.314 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] 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 dEP6A7KaRH86 for ; Fri, 2 Jul 2010 01:11:14 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by core3.amsl.com (Postfix) with ESMTP id 9240C3A68D4 for ; Fri, 2 Jul 2010 01:11:13 -0700 (PDT) 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 1OUbLI-0008SN-RN for autoconf@ietf.org; Fri, 02 Jul 2010 10:11:24 +0200 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 1OUbLI-0000wT-J4 for autoconf@ietf.org; Fri, 02 Jul 2010 10:11:24 +0200 From: Henning Rogge To: autoconf@ietf.org Date: Fri, 2 Jul 2010 10:10:24 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-23-generic; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1924385.6quZhBFGgf"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201007021011.20135.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11311/Fri Jul 2 05:08:51 2010) by mailguard.fgan.de X-Scan-Signature: de5d0da733df39e048d0c87225b8a781 Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. 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, 02 Jul 2010 08:11:15 -0000 --nextPart1924385.6quZhBFGgf Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue June 29 2010 06:20:28 Ryuji Wakikawa wrote: > Hi all, >=20 > Please find a proposal of a new AUTOCONF charter attached below. > We need to define our new charter carefully to avoid yet-another 5 years > discussion. Jari and chairs agreed to narrow down the charter items and go > straight to solution space. Just as a general comment, I think it would be a mistake to put DHCPv6=20 directly into the charter, even if we decide to go for a centralized sollut= ion=20 first. 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-961, 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 --nextPart1924385.6quZhBFGgf 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) iEYEABECAAYFAkwtnvEACgkQRIfGfFXsz+BmHgCfQp8kfPsioMBcI98pkDR1Hr9y cLUAn3NGFg0qXlFw0HIwc4Hp7ROn/Syf =TWhS -----END PGP SIGNATURE----- --nextPart1924385.6quZhBFGgf-- From arjen.holtzer@tno.nl Fri Jul 2 06:21:42 2010 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 7E0783A681A for ; Fri, 2 Jul 2010 06:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 IKirURWnjt84 for ; Fri, 2 Jul 2010 06:21:41 -0700 (PDT) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by core3.amsl.com (Postfix) with ESMTP id 0DEEB3A67C2 for ; Fri, 2 Jul 2010 06:21:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,526,1272837600"; d="scan'208";a="36664491" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1a.tno.nl with ESMTP; 02 Jul 2010 15:21:51 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 2 Jul 2010 15:21:51 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Call for comments to a new AUTOCONF charter proposal. Thread-Index: AcsYeoMVeeYlzuj3RBWPZfhqutHWLAAgD0NAADsO1tA= References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net><4C2B801B.1070004@earthlink.net> From: "Holtzer, A.C.G. (Arjen)" To: "Dearlove, Christopher (UK)" , "Charles E. Perkins" , "Jari Arkko" , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. 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, 02 Jul 2010 13:21:42 -0000 Hello autoconfers, I support this "two-case"-approach, Christopher mentions: so standardizing one centralized and one decentralized solution (or one stateful and one stateless solution, just like in the current IPv6 standards). I agree that the solution should make use of existing protocols as much as possible (e.g. DHCP, ND, ...), but my choice would be not to state in the charter that DHCP must be used in all solutions coming out of the WG. draft-bernardos-manet-autoconf-survey-05 shows there are already many proposals existing, making it a good starting point for going into solution space. Actually even more than just a starting point since many of the proposals have already been around for a while. So I support this doc. Best regards, Arjen >=20 > If Charlie can find a few like-minded people to work on that,=20 > why not add this as a parallel activity? The rationale of why=20 > two cases should be straightforward to make, they are almost=20 > chalk and cheese in e.g. centralised versus non-centralised.=20 > This is actually added safety to the group producing=20 > something, as if one succeeds and the other fails, that's still good. >=20 >=20 This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html From charles.perkins@earthlink.net Fri Jul 2 09:41:06 2010 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 A7CCD3A68D6 for ; Fri, 2 Jul 2010 09:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.216 X-Spam-Level: X-Spam-Status: No, score=-0.216 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_40=-0.185] 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 aLkJms7A0XMs for ; Fri, 2 Jul 2010 09:40:58 -0700 (PDT) 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 172F73A67D4 for ; Fri, 2 Jul 2010 09:40:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=U1SeJ6YNxKt26k0prqDhd2PyPQCNglMepSZ7vGTfaA2no8CNw583EXEY++sA0YfL; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To: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.145]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OUjIa-0003bf-8U; Fri, 02 Jul 2010 12:41:08 -0400 Message-ID: <4C2E16A3.1080007@earthlink.net> Date: Fri, 02 Jul 2010 09:41:07 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Emmanuel Baccelli , autoconf@ietf.org References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net> <4C2B801B.1070004@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52c8a99e217c984f8abd7b782b03a35f34350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. 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, 02 Jul 2010 16:41:07 -0000 Hello Emmanuel and all, Thanks for supporting the consideration of decentralized approach. I'm pretty sure we could get at least one good working solution in time a lot faster than it took to agree that not everything is an Ethernet. However, it's important to avoid making a sharp dichotomy between "centralized" and "decentralized" approaches. My big concern was that somehow the DHCP model was going to be considered the only viable choice because people (outsiders?) consider it to be the only known quantity. There are other ways to have more centralized or less centralized procedures, with or without proxy assistance, perhaps hybridized approaches, and with improved availability via elections. Those are just a few of the options, and probably all of them are way better than trying to shoehorn DHCP where it does not seem to fit. Flushing years of development and wisdom down the toilet just because they doesn't spell DHCP seems really wrong to me. Another point to keep in mind -- DHCP was designed and built from day one to be a _managed_ solution for autoconfiguration. It seems quite clear to me that most of the interesting development and inspiration for ad hoc networks has gone towards enabling networking in environments where no such tightly managed administration is possible. Thus, in my view, DHCP almost tautologically disqualifies itself from consideration without major structural redesign. How is it, then, that DHCP keeps cropping up in the discussion? Regards, Charlie P. On 7/1/2010 2:28 AM, Emmanuel Baccelli wrote: > > > On Thu, Jul 1, 2010 at 11:02 AM, Dearlove, Christopher (UK) > > > wrote: > > Charles Perkins > > I'd be happy if it were possible for [autoconf] to > > be allowed to consider the excellent body of work that > > was seen already years ago -- the same body of work > > that motivated me and others to create and spend a lot > > of time over the last years and years. > > If Charlie can find a few like-minded people to work on > that, why not add this as a parallel activity? The > rationale of why two cases should be straightforward to > make, they are almost chalk and cheese in e.g. centralised > versus non-centralised. This is actually added safety to > the group producing something, as if one succeeds and the > other fails, that's still good. > > > > I also think this parallel approach could be appropriate too. > > > Unfortunately, I can't offer to be one of those people. > Although I should be able to contribute at the read and > comment level, more than that is needed. I only didn't > make the suggestion earlier as it needs people (with > all due respect to Charlie, plural) to do the work. > > > > I'd be happy to help out on the matter. So I guess we have a plural + > contributors ;) > > cheers, > > Emmanuel > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From teco@inf-net.nl Sat Jul 3 00:13:53 2010 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 AA40C3A6859 for ; Sat, 3 Jul 2010 00:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_40=-0.185] 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 burbpypzOp6j for ; Sat, 3 Jul 2010 00:13:51 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 798813A695B for ; Sat, 3 Jul 2010 00:13:48 -0700 (PDT) Received: by ewy22 with SMTP id 22so1326318ewy.31 for ; Sat, 03 Jul 2010 00:13:56 -0700 (PDT) Received: by 10.213.29.210 with SMTP id r18mr1510796ebc.81.1278141236426; Sat, 03 Jul 2010 00:13:56 -0700 (PDT) Received: from [192.168.2.168] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id a48sm12910257eei.18.2010.07.03.00.13.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 03 Jul 2010 00:13:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4C2E16A3.1080007@earthlink.net> Date: Sat, 3 Jul 2010 09:13:54 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net> <4C2B801B.1070004@earthlink.net> <4C2E16A3.1080007@earthlink.net> To: Charles E. Perkins X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. 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, 03 Jul 2010 07:13:54 -0000 Charlie, Are you in for DHCP for getting prefixes (and other parameters), for ad hoc networks connected to the Internet (or other managed fixed network)? If so, the discussion is on addresses only. We have to deal with bootstrapping, i.e. first step in autoconf getting a routable address and the address of a DHCP server. After this, we are done. IMHO multi-hop signaling between address-less DHCP-client and unknown DHCP-server is a bad idea. Both are needed for smooth operation. Teco. Op 2 jul 2010, om 18:41 heeft Charles E. Perkins het volgende geschreven: > Hello Emmanuel and all, > > Thanks for supporting the consideration > of decentralized approach. I'm pretty > sure we could get at least one good > working solution in time a lot faster > than it took to agree that not everything > is an Ethernet. > > However, it's important to avoid making > a sharp dichotomy between "centralized" > and "decentralized" approaches. My big > concern was that somehow the DHCP model > was going to be considered the only viable > choice because people (outsiders?) consider > it to be the only known quantity. There are > other ways to have more centralized or less > centralized procedures, with or without > proxy assistance, perhaps hybridized > approaches, and with improved availability > via elections. > > Those are just a few of the options, and > probably all of them are way better than > trying to shoehorn DHCP where it does not > seem to fit. Flushing years of development > and wisdom down the toilet just because > they doesn't spell DHCP seems really wrong > to me. > > Another point to keep in mind -- DHCP was > designed and built from day one to be a > _managed_ solution for autoconfiguration. > It seems quite clear to me that most of the > interesting development and inspiration for > ad hoc networks has gone towards enabling > networking in environments where no such > tightly managed administration is possible. > Thus, in my view, DHCP almost tautologically > disqualifies itself from consideration > without major structural redesign. How is > it, then, that DHCP keeps cropping up in > the discussion? > > Regards, > Charlie P. > > > > On 7/1/2010 2:28 AM, Emmanuel Baccelli wrote: >> >> >> On Thu, Jul 1, 2010 at 11:02 AM, Dearlove, Christopher (UK) >> > >> wrote: >> >> Charles Perkins >> > I'd be happy if it were possible for [autoconf] to >> > be allowed to consider the excellent body of work that >> > was seen already years ago -- the same body of work >> > that motivated me and others to create and spend a lot >> > of time over the last years and years. >> >> If Charlie can find a few like-minded people to work on >> that, why not add this as a parallel activity? The >> rationale of why two cases should be straightforward to >> make, they are almost chalk and cheese in e.g. centralised >> versus non-centralised. This is actually added safety to >> the group producing something, as if one succeeds and the >> other fails, that's still good. >> >> >> >> I also think this parallel approach could be appropriate too. >> >> >> Unfortunately, I can't offer to be one of those people. >> Although I should be able to contribute at the read and >> comment level, more than that is needed. I only didn't >> make the suggestion earlier as it needs people (with >> all due respect to Charlie, plural) to do the work. >> >> >> >> I'd be happy to help out on the matter. So I guess we have a plural + >> contributors ;) >> >> cheers, >> >> Emmanuel >> >> >> >> _______________________________________________ >> 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 townsley@cisco.com Sat Jul 3 00:33:20 2010 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 267DC3A690D for ; Sat, 3 Jul 2010 00:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.103 X-Spam-Level: X-Spam-Status: No, score=-10.103 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_HI=-8] 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 J-aS-xhtZEje for ; Sat, 3 Jul 2010 00:33:18 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C9ED63A6859 for ; Sat, 3 Jul 2010 00:33:18 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsJAMeELkyrR7Ht/2dsb2JhbAAwkwOMNHGkLZobglOCUgSIOg X-IronPort-AV: E=Sophos;i="4.53,530,1272844800"; d="scan'208";a="221209980" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 03 Jul 2010 07:33:31 +0000 Received: from iwan-view2.cisco.com (iwan-view2.cisco.com [171.70.65.8]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o637XVHu004055 for ; Sat, 3 Jul 2010 07:33:31 GMT Received: from new-host-2.home (dhcp-10-55-86-122.cisco.com [10.55.86.122]) by iwan-view2.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o637XPH26117 for ; Sat, 3 Jul 2010 00:33:30 -0700 (PDT) Message-ID: <4C2E3702.9030606@cisco.com> Date: Fri, 02 Jul 2010 20:59:14 +0200 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: autoconf@ietf.org References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net><4C2B801B.1070004@earthlink.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. 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, 03 Jul 2010 07:33:20 -0000 My kneejerk reaction to this is that walking in with the goal of having more than one way to autoconfigure a manet is a bad idea. If we end up with two ways to autoconfigure, then we will have to invent an automatic mechanism on top to choose which autoconfiguration mechanism to use. That doesn't help anyone. In absence of knowledgeable human configuration, hard choices that narrow functional options typically far outweigh the potential benefits of one option vs. the other. So, even if you can prove that A is better than B, B is still better than A+B. Let's strive for making a choice, at least within the MANET domain. - Mark On 7/2/10 3:21 PM, Holtzer, A.C.G. (Arjen) wrote: > Hello autoconfers, > > I support this "two-case"-approach, Christopher mentions: so > standardizing one centralized and one decentralized solution (or one > stateful and one stateless solution, just like in the current IPv6 > standards). I agree that the solution should make use of existing > protocols as much as possible (e.g. DHCP, ND, ...), but my choice would > be not to state in the charter that DHCP must be used in all solutions > coming out of the WG. > > draft-bernardos-manet-autoconf-survey-05 shows there are already many > proposals existing, making it a good starting point for going into > solution space. Actually even more than just a starting point since many > of the proposals have already been around for a while. So I support this > doc. > > Best regards, > Arjen > >> >> If Charlie can find a few like-minded people to work on that, >> why not add this as a parallel activity? The rationale of why >> two cases should be straightforward to make, they are almost >> chalk and cheese in e.g. centralised versus non-centralised. >> This is actually added safety to the group producing >> something, as if one succeeds and the other fails, that's still good. >> >> > This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From teco@inf-net.nl Sat Jul 3 00:57:08 2010 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 8B7FA3A6883 for ; Sat, 3 Jul 2010 00:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=0.910, 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 XFUE0GfkJSkV for ; Sat, 3 Jul 2010 00:57:07 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 27D023A687F for ; Sat, 3 Jul 2010 00:57:06 -0700 (PDT) Received: by ewy22 with SMTP id 22so1332834ewy.31 for ; Sat, 03 Jul 2010 00:57:14 -0700 (PDT) Received: by 10.213.32.141 with SMTP id c13mr1614089ebd.22.1278143834146; Sat, 03 Jul 2010 00:57:14 -0700 (PDT) Received: from [192.168.2.168] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id x54sm13234815eeh.5.2010.07.03.00.57.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 03 Jul 2010 00:57:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4C2E3702.9030606@cisco.com> Date: Sat, 3 Jul 2010 09:57:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <16DA654B-FCA7-47F9-B441-8DB2304AA5B8@inf-net.nl> References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net><4C2B801B.1070004@earthlink.net> <4C2E3702.9030606@cisco.com> To: Mark Townsley X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. 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, 03 Jul 2010 07:57:08 -0000 Easy to invent the automatic mechanism: Only need an address? Use ND. Need more? use ND for getting address, find central server, get more. Teco. Op 2 jul 2010, om 20:59 heeft Mark Townsley het volgende geschreven: >=20 > My kneejerk reaction to this is that walking in with the goal of = having > more than one way to autoconfigure a manet is a bad idea. >=20 > If we end up with two ways to autoconfigure, then we will have to = invent > an automatic mechanism on top to choose which autoconfiguration > mechanism to use. That doesn't help anyone. In absence of = knowledgeable > human configuration, hard choices that narrow functional options > typically far outweigh the potential benefits of one option vs. the > other. So, even if you can prove that A is better than B, B is still > better than A+B. >=20 > Let's strive for making a choice, at least within the MANET domain. >=20 > - Mark >=20 >=20 > On 7/2/10 3:21 PM, Holtzer, A.C.G. (Arjen) wrote: >> Hello autoconfers, >>=20 >> I support this "two-case"-approach, Christopher mentions: so >> standardizing one centralized and one decentralized solution (or one >> stateful and one stateless solution, just like in the current IPv6 >> standards). I agree that the solution should make use of existing >> protocols as much as possible (e.g. DHCP, ND, ...), but my choice = would >> be not to state in the charter that DHCP must be used in all = solutions >> coming out of the WG. >>=20 >> draft-bernardos-manet-autoconf-survey-05 shows there are already many >> proposals existing, making it a good starting point for going into >> solution space. Actually even more than just a starting point since = many >> of the proposals have already been around for a while. So I support = this >> doc. >>=20 >> Best regards, >> Arjen >>=20 >>>=20 >>> If Charlie can find a few like-minded people to work on that,=20 >>> why not add this as a parallel activity? The rationale of why=20 >>> two cases should be straightforward to make, they are almost=20 >>> chalk and cheese in e.g. centralised versus non-centralised.=20 >>> This is actually added safety to the group producing=20 >>> something, as if one succeeds and the other fails, that's still = good. >>>=20 >>>=20 >> This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/disclaimer/email.html >>=20 >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >>=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From emmanuel.baccelli@gmail.com Sat Jul 3 03:18:13 2010 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 E67623A6937 for ; Sat, 3 Jul 2010 03:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 xTiBE-5ZUEYb for ; Sat, 3 Jul 2010 03:18:12 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 9A10E3A67A5 for ; Sat, 3 Jul 2010 03:18:11 -0700 (PDT) Received: by ewy22 with SMTP id 22so1354116ewy.31 for ; Sat, 03 Jul 2010 03:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=oESK3vI+hObxCtuDYqB7ePlbM2En5uAWe/y4J7+/hn0=; b=GU93fNjle/aXvkHwDi4tZJSctKx/iG9E965WzSzcoGF2q1e81qETZ/iP38hazxJjrN n4nP0xCcGIs5UM2jn+LIWlGC/GNWSQUl7i7SK1R0oLc+GKAACgzx/jGg59DSAgdWrvBB 4sukl+7mrl5D+Qf3qq5IwzrM9e++aWufqCSww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=o1AJAVpDT86gFBdtTmjUziMuPkfBHoxg86cT1L7PFgOyP9OrCnTTMjtfINJxzeOmHb x6P0ErFFz6gWZSnCptjCNJAVBguYDk4MR7CPrvPvj3/T+DNCNrO95L3sz3alA2rMMQQ1 WHK0SEj+jHK8JvZUL8GdO8vVuITIiQglpRv6g= Received: by 10.213.20.15 with SMTP id d15mr275929ebb.66.1278152299154; Sat, 03 Jul 2010 03:18:19 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.14.47.9 with HTTP; Sat, 3 Jul 2010 03:17:59 -0700 (PDT) In-Reply-To: <4C2E16A3.1080007@earthlink.net> References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> <4C2A723E.3020806@piuha.net> <4C2B801B.1070004@earthlink.net> <4C2E16A3.1080007@earthlink.net> From: Emmanuel Baccelli Date: Sat, 3 Jul 2010 12:17:59 +0200 X-Google-Sender-Auth: ue7Uv_Zbkl-Mssla9eR9ODt9LUw Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=0015174be082c28d37048a790581 Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. 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, 03 Jul 2010 10:18:14 -0000 --0015174be082c28d37048a790581 Content-Type: text/plain; charset=ISO-8859-1 Hi Charlie, I agree with you about trying to avoid the dichotomy centralized/decentralized. If some people want to work on a DHCP-dependent solution, let them try. If some other people want to work in parallel on a DHCP-independent solution, why not let them do it too? In my mind, these two solutions could be pretty complementary. Emmanuel On Fri, Jul 2, 2010 at 6:41 PM, Charles E. Perkins < charles.perkins@earthlink.net> wrote: > Hello Emmanuel and all, > > Thanks for supporting the consideration > of decentralized approach. I'm pretty > sure we could get at least one good > working solution in time a lot faster > than it took to agree that not everything > is an Ethernet. > > However, it's important to avoid making > a sharp dichotomy between "centralized" > and "decentralized" approaches. My big > concern was that somehow the DHCP model > was going to be considered the only viable > choice because people (outsiders?) consider > it to be the only known quantity. There are > other ways to have more centralized or less > centralized procedures, with or without > proxy assistance, perhaps hybridized > approaches, and with improved availability > via elections. > > Those are just a few of the options, and > probably all of them are way better than > trying to shoehorn DHCP where it does not > seem to fit. Flushing years of development > and wisdom down the toilet just because > they doesn't spell DHCP seems really wrong > to me. > > Another point to keep in mind -- DHCP was > designed and built from day one to be a > _managed_ solution for autoconfiguration. > It seems quite clear to me that most of the > interesting development and inspiration for > ad hoc networks has gone towards enabling > networking in environments where no such > tightly managed administration is possible. > Thus, in my view, DHCP almost tautologically > disqualifies itself from consideration > without major structural redesign. How is > it, then, that DHCP keeps cropping up in > the discussion? > > Regards, > Charlie P. > > > > > On 7/1/2010 2:28 AM, Emmanuel Baccelli wrote: > >> >> >> On Thu, Jul 1, 2010 at 11:02 AM, Dearlove, Christopher (UK) >> > >> >> wrote: >> >> Charles Perkins >> > I'd be happy if it were possible for [autoconf] to >> > be allowed to consider the excellent body of work that >> > was seen already years ago -- the same body of work >> > that motivated me and others to create and spend a lot >> > of time over the last years and years. >> >> If Charlie can find a few like-minded people to work on >> that, why not add this as a parallel activity? The >> rationale of why two cases should be straightforward to >> make, they are almost chalk and cheese in e.g. centralised >> versus non-centralised. This is actually added safety to >> the group producing something, as if one succeeds and the >> other fails, that's still good. >> >> >> >> I also think this parallel approach could be appropriate too. >> >> >> Unfortunately, I can't offer to be one of those people. >> Although I should be able to contribute at the read and >> comment level, more than that is needed. I only didn't >> make the suggestion earlier as it needs people (with >> all due respect to Charlie, plural) to do the work. >> >> >> >> I'd be happy to help out on the matter. So I guess we have a plural + >> contributors ;) >> >> cheers, >> >> Emmanuel >> >> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> > > --0015174be082c28d37048a790581 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Charlie,

I agree with you about trying to avoid the d= ichotomy centralized/decentralized. If some people want to work on a DHCP-d= ependent solution, let them try. If some other people want to work in paral= lel on a DHCP-independent solution, why not let them do it too?

In my mind, these two solutions could be pretty complem= entary.

Emmanuel



=
On Fri, Jul 2, 2010 at 6:41 PM, Charles E. Perki= ns <c= harles.perkins@earthlink.net> wrote:
Hello Emmanuel and all,

Thanks for supporting the consideration
of decentralized approach. =A0I'm pretty
sure we could get at least one good
working solution in time a lot faster
than it took to agree that not everything
is an Ethernet.

However, it's important to avoid making
a sharp dichotomy between "centralized"
and "decentralized" approaches. =A0My big
concern was that somehow the DHCP model
was going to be considered the only viable
choice because people (outsiders?) consider
it to be the only known quantity. =A0There are
other ways to have more centralized or less
centralized procedures, with or without
proxy assistance, perhaps hybridized
approaches, and with improved availability
via elections.

Those are just a few of the options, and
probably all of them are way better than
trying to shoehorn DHCP where it does not
seem to fit. =A0Flushing years of development
and wisdom down the toilet just because
they doesn't spell DHCP seems really wrong
to me.

Another point to keep in mind -- DHCP was
designed and built from day one to be a
_managed_ solution for autoconfiguration.
It seems quite clear to me that most of the
interesting development and inspiration for
ad hoc networks has gone towards enabling
networking in environments where no such
tightly managed administration is possible.
Thus, in my view, DHCP almost tautologically
disqualifies itself from consideration
without major structural redesign. =A0How is
it, then, that DHCP keeps cropping up in
the discussion?

Regards,
Charlie P.




On 7/1/2010 2:28 AM, Emmanuel Baccelli wrote:


On Thu, Jul 1, 2010 at 11:02 AM, Dearlove, Christopher (UK)
<Chri= s.Dearlove@baesystems.com <mailto:Chris.Dearlove@baesystems.com>><= div>

wrote:

=A0 =A0Charles Perkins
=A0 =A0 > I'd be happy if it were possible for [autoconf] to
=A0 =A0 > be allowed to consider the excellent body of work that
=A0 =A0 > was seen already years ago -- the same body of work
=A0 =A0 > that motivated me and others to create and spend a lot
=A0 =A0 > of time over the last years and years.

=A0 =A0If Charlie can find a few like-minded people to work on
=A0 =A0that, why not add this as a parallel activity? The
=A0 =A0rationale of why two cases should be straightforward to
=A0 =A0make, they are almost chalk and cheese in e.g. centralised
=A0 =A0versus non-centralised. This is actually added safety to
=A0 =A0the group producing something, as if one succeeds and the
=A0 =A0other fails, that's still good.



I also think this parallel approach could be appropriate too.


=A0 =A0Unfortunately, I can't offer to be one of those people.
=A0 =A0Although I should be able to contribute at the read and
=A0 =A0comment level, more than that is needed. I only didn't
=A0 =A0make the suggestion earlier as it needs people (with
=A0 =A0all due respect to Charlie, plural) to do the work.



I'd be happy to help out on the matter. So I guess we have a plural + contributors ;)

cheers,

Emmanuel



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


--0015174be082c28d37048a790581-- From townsley@cisco.com Sun Jul 4 14:18:00 2010 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 362743A6782 for ; Sun, 4 Jul 2010 14:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] 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 kSq1cgodQiVq for ; Sun, 4 Jul 2010 14:17:59 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4750E3A659A for ; Sun, 4 Jul 2010 14:17:59 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN6XMEyrR7Hu/2dsb2JhbACfaXGiLJklglOCUgSIOg X-IronPort-AV: E=Sophos;i="4.53,536,1272844800"; d="scan'208";a="221522800" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 04 Jul 2010 21:17:59 +0000 Received: from iwan-view2.cisco.com (iwan-view2.cisco.com [171.70.65.8]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o64LHx4m012605; Sun, 4 Jul 2010 21:17:59 GMT Received: from ams-townsley-8711.cisco.com (ams-townsley-8711.cisco.com [10.55.233.226]) by iwan-view2.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o64LHwH21704; Sun, 4 Jul 2010 14:17:58 -0700 (PDT) Message-ID: <4C30FA7E.6020106@cisco.com> Date: Sun, 04 Jul 2010 23:17:50 +0200 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Teco Boot References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net><4C2B801B.1070004@earthlink.net> <4C2E3702.9030606@cisco.com> <16DA654B-FCA7-47F9-B441-8DB2304AA5B8@inf-net.nl> In-Reply-To: <16DA654B-FCA7-47F9-B441-8DB2304AA5B8@inf-net.nl> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. 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, 04 Jul 2010 21:18:00 -0000 On 7/3/10 9:57 AM, Teco Boot wrote: > Easy to invent the automatic mechanism: > Only need an address? Use ND. > Need more? use ND for getting address, find central server, get more. OK, as described that's still one mechanism per type of information. So, where does the DNS server address go ;-) - Mark > > Teco. > > > Op 2 jul 2010, om 20:59 heeft Mark Townsley het volgende geschreven: > >> >> My kneejerk reaction to this is that walking in with the goal of having >> more than one way to autoconfigure a manet is a bad idea. >> >> If we end up with two ways to autoconfigure, then we will have to invent >> an automatic mechanism on top to choose which autoconfiguration >> mechanism to use. That doesn't help anyone. In absence of knowledgeable >> human configuration, hard choices that narrow functional options >> typically far outweigh the potential benefits of one option vs. the >> other. So, even if you can prove that A is better than B, B is still >> better than A+B. >> >> Let's strive for making a choice, at least within the MANET domain. >> >> - Mark >> >> >> On 7/2/10 3:21 PM, Holtzer, A.C.G. (Arjen) wrote: >>> Hello autoconfers, >>> >>> I support this "two-case"-approach, Christopher mentions: so >>> standardizing one centralized and one decentralized solution (or one >>> stateful and one stateless solution, just like in the current IPv6 >>> standards). I agree that the solution should make use of existing >>> protocols as much as possible (e.g. DHCP, ND, ...), but my choice would >>> be not to state in the charter that DHCP must be used in all solutions >>> coming out of the WG. >>> >>> draft-bernardos-manet-autoconf-survey-05 shows there are already many >>> proposals existing, making it a good starting point for going into >>> solution space. Actually even more than just a starting point since many >>> of the proposals have already been around for a while. So I support this >>> doc. >>> >>> Best regards, >>> Arjen >>> >>>> >>>> If Charlie can find a few like-minded people to work on that, >>>> why not add this as a parallel activity? The rationale of why >>>> two cases should be straightforward to make, they are almost >>>> chalk and cheese in e.g. centralised versus non-centralised. >>>> This is actually added safety to the group producing >>>> something, as if one succeeds and the other fails, that's still good. >>>> >>>> >>> This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html >>> >>> _______________________________________________ >>> 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 Chris.Dearlove@baesystems.com Mon Jul 5 02:14:19 2010 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 EE5C23A691A for ; Mon, 5 Jul 2010 02:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 G3qfFiOGSvTV for ; Mon, 5 Jul 2010 02:14:17 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 3D7C33A68A5 for ; Mon, 5 Jul 2010 02:13:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,538,1272841200"; d="scan'208";a="74447147" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 05 Jul 2010 10:13:20 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o659DJtF029144; Mon, 5 Jul 2010 10:13:20 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Jul 2010 10:13:19 +0100 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: Mon, 5 Jul 2010 10:13:18 +0100 Message-ID: In-Reply-To: <16DA654B-FCA7-47F9-B441-8DB2304AA5B8@inf-net.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] Call for comments to a new AUTOCONF charter proposal. thread-index: AcsahWAUS2ttbsJ2Tl6kI8DI8oeD2QBnGjmg References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net><4C2B801B.1070004@earthlink.net> <4C2E3702.9030606@cisco.com> <16DA654B-FCA7-47F9-B441-8DB2304AA5B8@inf-net.nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Mark Townsley" X-OriginalArrivalTime: 05 Jul 2010 09:13:19.0850 (UTC) FILETIME=[4F80D4A0:01CB1C22] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. 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, 05 Jul 2010 09:14:20 -0000 I'm still trying to work out how step one works. ND, out of the box, designed for hosts on non-multi-hop Ethernets won't give you a MANET-wide unique address. You might even find someone else with the same address as you on your only route to the server. Or is there some development of ND that I have overlooked? -- 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: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behalf Of Teco Boot Sent: 03 July 2010 08:57 To: Mark Townsley Cc: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. Easy to invent the automatic mechanism: Only need an address? Use ND. Need more? use ND for getting address, find central server, get more. Teco. Op 2 jul 2010, om 20:59 heeft Mark Townsley het volgende geschreven: > > My kneejerk reaction to this is that walking in with the goal of having > more than one way to autoconfigure a manet is a bad idea. > > If we end up with two ways to autoconfigure, then we will have to invent > an automatic mechanism on top to choose which autoconfiguration > mechanism to use. That doesn't help anyone. In absence of knowledgeable > human configuration, hard choices that narrow functional options > typically far outweigh the potential benefits of one option vs. the > other. So, even if you can prove that A is better than B, B is still > better than A+B. > > Let's strive for making a choice, at least within the MANET domain. > > - Mark > > > On 7/2/10 3:21 PM, Holtzer, A.C.G. (Arjen) wrote: >> Hello autoconfers, >> >> I support this "two-case"-approach, Christopher mentions: so >> standardizing one centralized and one decentralized solution (or one >> stateful and one stateless solution, just like in the current IPv6 >> standards). I agree that the solution should make use of existing >> protocols as much as possible (e.g. DHCP, ND, ...), but my choice would >> be not to state in the charter that DHCP must be used in all solutions >> coming out of the WG. >> >> draft-bernardos-manet-autoconf-survey-05 shows there are already many >> proposals existing, making it a good starting point for going into >> solution space. Actually even more than just a starting point since many >> of the proposals have already been around for a while. So I support this >> doc. >> >> Best regards, >> Arjen >> >>> >>> If Charlie can find a few like-minded people to work on that, >>> why not add this as a parallel activity? The rationale of why >>> two cases should be straightforward to make, they are almost >>> chalk and cheese in e.g. centralised versus non-centralised. >>> This is actually added safety to the group producing >>> something, as if one succeeds and the other fails, that's still good. >>> >>> >> This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html >> >> _______________________________________________ >> 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 ******************************************************************** 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 Jul 5 02:23:59 2010 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 B17393A6846 for ; Mon, 5 Jul 2010 02:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, 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 SoPYmRzegvT0 for ; Mon, 5 Jul 2010 02:23:58 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id ED7F43A6812 for ; Mon, 5 Jul 2010 02:23:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,539,1272841200"; d="scan'208";a="74451178" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 05 Jul 2010 10:23:58 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o659Nsrr006332; Mon, 5 Jul 2010 10:23:58 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Jul 2010 10:23:43 +0100 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: Mon, 5 Jul 2010 10:23:42 +0100 Message-ID: In-Reply-To: <4C2E3702.9030606@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] Call for comments to a new AUTOCONF charter proposal. thread-index: AcsaggvIEVNOwyieRw2etPwxjzhmlgBnjnpA References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net><4C2B801B.1070004@earthlink.net> <4C2E3702.9030606@cisco.com> From: "Dearlove, Christopher (UK)" To: "Mark Townsley" , X-OriginalArrivalTime: 05 Jul 2010 09:23:43.0072 (UTC) FILETIME=[C2F8F600:01CB1C23] Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. 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, 05 Jul 2010 09:23:59 -0000 I'm going to disagree with that, because there are fundamentally different requirements - not all MANETs are the same. The proposed solution in the current draft charter is a single DHCP server. Putting aside the technical issues in getting that to work that Charlie and others have pointed out, let's suppose it can be made to work. But there are several of us whose areas of interest, and scenarios within that area of interest, would regard such a single point of failure (or takeover) as not a good solution. Of course just having a decentralised solution would not necessarily be sufficient either, hence the comments I've made about security issues up front. I don't yet know if a solution that does all I would want it to do exists. As for how to choose, if one solution is unacceptable, then the network would clearly be using the other. More generally it's far from the only administratively configured issue in a MANET - which routing protocol for example (which also applies in the fixed Internet, nothing new there). But perhaps, rather than jumping straight in with one, or even two, approaches, we need people to indicate what they actually want/need, and whether the proposal in the draft charter, or an alternative (the latter having the disadvantage of being quite vague at this point) would give them what they need. -- 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: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behalf Of Mark Townsley Sent: 02 July 2010 19:59 To: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. My kneejerk reaction to this is that walking in with the goal of having more than one way to autoconfigure a manet is a bad idea. If we end up with two ways to autoconfigure, then we will have to invent an automatic mechanism on top to choose which autoconfiguration mechanism to use. That doesn't help anyone. In absence of knowledgeable human configuration, hard choices that narrow functional options typically far outweigh the potential benefits of one option vs. the other. So, even if you can prove that A is better than B, B is still better than A+B. Let's strive for making a choice, at least within the MANET domain. - Mark On 7/2/10 3:21 PM, Holtzer, A.C.G. (Arjen) wrote: > Hello autoconfers, > > I support this "two-case"-approach, Christopher mentions: so > standardizing one centralized and one decentralized solution (or one > stateful and one stateless solution, just like in the current IPv6 > standards). I agree that the solution should make use of existing > protocols as much as possible (e.g. DHCP, ND, ...), but my choice would > be not to state in the charter that DHCP must be used in all solutions > coming out of the WG. > > draft-bernardos-manet-autoconf-survey-05 shows there are already many > proposals existing, making it a good starting point for going into > solution space. Actually even more than just a starting point since many > of the proposals have already been around for a while. So I support this > doc. > > Best regards, > Arjen > >> >> If Charlie can find a few like-minded people to work on that, >> why not add this as a parallel activity? The rationale of why >> two cases should be straightforward to make, they are almost >> chalk and cheese in e.g. centralised versus non-centralised. >> This is actually added safety to the group producing >> something, as if one succeeds and the other fails, that's still good. >> >> > This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html > > _______________________________________________ > 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 ******************************************************************** 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 townsley@cisco.com Mon Jul 5 03:23:42 2010 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 809583A6844 for ; Mon, 5 Jul 2010 03:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.273 X-Spam-Level: X-Spam-Status: No, score=-9.273 tagged_above=-999 required=5 tests=[AWL=1.326, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 vvdyffT-Lohc for ; Mon, 5 Jul 2010 03:23:41 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9C9893A63EC for ; Mon, 5 Jul 2010 03:23:41 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADJPMUytJV2a/2dsb2JhbACfbnGjPplxhSUEiDo X-IronPort-AV: E=Sophos;i="4.53,539,1272844800"; d="scan'208";a="128851375" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 05 Jul 2010 10:23:42 +0000 Received: from iwan-view2.cisco.com (iwan-view2.cisco.com [171.70.65.8]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o65ANfoU024806; Mon, 5 Jul 2010 10:23:41 GMT Received: from ams-townsley-8711.cisco.com (ams-townsley-8711.cisco.com [10.55.233.226]) by iwan-view2.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o65ANeH25929; Mon, 5 Jul 2010 03:23:40 -0700 (PDT) Message-ID: <4C31B2A4.5050101@cisco.com> Date: Mon, 05 Jul 2010 12:23:32 +0200 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net><4C2B801B.1070004@earthlink.net> <4C2E3702.9030606@cisco.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. 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, 05 Jul 2010 10:23:42 -0000 On 7/5/10 11:23 AM, Dearlove, Christopher (UK) wrote: > I'm going to disagree with that, because there are fundamentally > different requirements - not all MANETs are the same. Is there a naming convention for all the different MANET types? How do you tell them apart? > The > proposed solution in the current draft charter is a single > DHCP server. Putting aside the technical issues in getting that > to work that Charlie and others have pointed out, let's suppose > it can be made to work. But there are several of us whose areas > of interest, and scenarios within that area of interest, would > regard such a single point of failure (or takeover) as not a good > solution. Of course just having a decentralised solution would > not necessarily be sufficient either, hence the comments I've > made about security issues up front. I don't yet know if a > solution that does all I would want it to do exists. > > As for how to choose, if one solution is unacceptable, then the > network would clearly be using the other. More generally it's > far from the only administratively configured issue in a MANET > - which routing protocol for example (which also applies in the > fixed Internet, nothing new there). I think of autoconfig as being part of a very basic bootstrapping procedure. If any one thing needs to be ubiquitous, it's this. After the device has reached a certain level of configuration and connectivity, it is more possible to negotiate options and report on mismatches. On the other hand, if basic bootstrapping fails, then all you may have to troubleshoot with is a dead device. > > But perhaps, rather than jumping straight in with one, or even > two, approaches, we need people to indicate what they actually > want/need, and whether the proposal in the draft charter, or > an alternative (the latter having the disadvantage of being > quite vague at this point) would give them what they need. Certainly putting a scope around that which must be automatically configured and that which may not would be helpful here. - Mark From Chris.Dearlove@baesystems.com Mon Jul 5 03:42:17 2010 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 A73883A68AD for ; Mon, 5 Jul 2010 03:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 YWg9oob9Mtql for ; Mon, 5 Jul 2010 03:42:16 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 66B9C3A63EC for ; Mon, 5 Jul 2010 03:42:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,539,1272841200"; d="scan'208";a="74479863" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 05 Jul 2010 11:42:17 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o65AgGte010916; Mon, 5 Jul 2010 11:42:16 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Jul 2010 11:42:16 +0100 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: Mon, 5 Jul 2010 11:42:16 +0100 Message-ID: In-Reply-To: <4C31B2A4.5050101@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] Call for comments to a new AUTOCONF charter proposal. thread-index: AcscLCaHCexfh7NbTrOgPHO7ISMA6QAAOH3A References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net><4C2B801B.1070004@earthlink.net> <4C2E3702.9030606@cisco.com> <4C31B2A4.5050101@cisco.com> From: "Dearlove, Christopher (UK)" To: "Mark Townsley" X-OriginalArrivalTime: 05 Jul 2010 10:42:16.0665 (UTC) FILETIME=[BC7E2C90:01CB1C2E] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. 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, 05 Jul 2010 10:42:17 -0000 I think asking for a naming convention is missing the point. It's an issue of requirements. I don't have a name for "sorry, I can't just use a single DHCP server as someone hostile might put it out of action". For the issue of ubiquity, we don't have a single means of obtaining an IP address in the rest of the Internet, not even the two of fixed and dynamic. -- 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: Mark Townsley [mailto:townsley@cisco.com] Sent: 05 July 2010 11:24 To: Dearlove, Christopher (UK) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. On 7/5/10 11:23 AM, Dearlove, Christopher (UK) wrote: > I'm going to disagree with that, because there are fundamentally > different requirements - not all MANETs are the same. Is there a naming convention for all the different MANET types? How do you tell them apart? > The > proposed solution in the current draft charter is a single > DHCP server. Putting aside the technical issues in getting that > to work that Charlie and others have pointed out, let's suppose > it can be made to work. But there are several of us whose areas > of interest, and scenarios within that area of interest, would > regard such a single point of failure (or takeover) as not a good > solution. Of course just having a decentralised solution would > not necessarily be sufficient either, hence the comments I've > made about security issues up front. I don't yet know if a > solution that does all I would want it to do exists. > > As for how to choose, if one solution is unacceptable, then the > network would clearly be using the other. More generally it's > far from the only administratively configured issue in a MANET > - which routing protocol for example (which also applies in the > fixed Internet, nothing new there). I think of autoconfig as being part of a very basic bootstrapping procedure. If any one thing needs to be ubiquitous, it's this. After the device has reached a certain level of configuration and connectivity, it is more possible to negotiate options and report on mismatches. On the other hand, if basic bootstrapping fails, then all you may have to troubleshoot with is a dead device. > > But perhaps, rather than jumping straight in with one, or even > two, approaches, we need people to indicate what they actually > want/need, and whether the proposal in the draft charter, or > an alternative (the latter having the disadvantage of being > quite vague at this point) would give them what they need. Certainly putting a scope around that which must be automatically configured and that which may not would be helpful here. - Mark ******************************************************************** 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 Cedric.Adjih@INRIA.fr Mon Jul 5 04:25:56 2010 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 E53DB3A67F7 for ; Mon, 5 Jul 2010 04:25:56 -0700 (PDT) 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_FR=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 o98IcAoJURO1 for ; Mon, 5 Jul 2010 04:25:56 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id 008173A67C0 for ; Mon, 5 Jul 2010 04:25:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,539,1272837600"; d="scan'208";a="62738150" Received: from canith.inria.fr (HELO [128.93.17.134]) ([128.93.17.134]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 05 Jul 2010 13:25:55 +0200 Message-ID: <4C31C13D.1020508@INRIA.fr> Date: Mon, 05 Jul 2010 13:25:49 +0200 From: Cedric Adjih User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: autoconf@ietf.org References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net><4C2B801B.1070004@earthlink.net> <4C2E3702.9030606@cisco.com> <4C31B2A4.5050101@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. 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, 05 Jul 2010 11:25:57 -0000 Hello all, Sorry to jump in this thread, but I concur with Christopher, and some other participants of the working group. In my opinion, a decentralized solution to autoconfiguration would be preferable. Having worked on MANET autoconfiguration for the French MoD (with specification, implementation, and experiments), centralized protocols seem to have more drawbacks for tactical networks, such as resilience to nodes taken out of combat as Chris. said, and also miscellaneous scenarios of network splitting/merging. -- Cedric On 07/05/2010 12:42 PM, Dearlove, Christopher (UK) wrote: > I think asking for a naming convention is missing the point. > It's an issue of requirements. I don't have a name for "sorry, > I can't just use a single DHCP server as someone hostile might > put it out of action". > > For the issue of ubiquity, we don't have a single means of > obtaining an IP address in the rest of the Internet, not even > the two of fixed and dynamic. > From teco@inf-net.nl Mon Jul 5 04:54:53 2010 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 138113A68A5 for ; Mon, 5 Jul 2010 04:54:53 -0700 (PDT) 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 7R-KMqnQvID8 for ; Mon, 5 Jul 2010 04:54:51 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 6B8353A63EC for ; Mon, 5 Jul 2010 04:54:50 -0700 (PDT) Received: by wwb13 with SMTP id 13so417774wwb.1 for ; Mon, 05 Jul 2010 04:54:48 -0700 (PDT) Received: by 10.213.29.8 with SMTP id o8mr1316285ebc.87.1278330888091; Mon, 05 Jul 2010 04:54:48 -0700 (PDT) Received: from [172.16.4.84] ([77.61.241.196]) by mx.google.com with ESMTPS id v8sm34621857eeh.20.2010.07.05.04.54.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 05 Jul 2010 04:54:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Mon, 5 Jul 2010 13:54:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7556BED3-E6FC-4135-BF46-441F2D1726F6@inf-net.nl> References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net><4C2B801B.1070004@earthlink.net> <4C2E3702.9030606@cisco.com> <16DA654B-FCA7-47F9-B441-8DB2304AA5B8@inf-net.nl> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. 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, 05 Jul 2010 11:54:53 -0000 What happens with duplicate DUIDs? If they don't exist, why would self-generated duplicate addresses occur? On the two-step approach, I can think of using the ND address = temporally, and get more info from DHCP, including a "better" address. This address = would=20 be topologically correct in case of border routers and would better fit=20= for packetbb compression. Teco. =20 Op 5 jul 2010, om 11:13 heeft Dearlove, Christopher (UK) het volgende = geschreven: > I'm still trying to work out how step one works. ND, out of > the box, designed for hosts on non-multi-hop Ethernets > won't give you a MANET-wide unique address. You might even > find someone else with the same address as you on your only > route to the server. Or is there some development of ND > that I have overlooked? >=20 > --=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 >=20 > 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 >=20 > -----Original Message----- > From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On > Behalf Of Teco Boot > Sent: 03 July 2010 08:57 > To: Mark Townsley > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter > proposal. >=20 >=20 > *** WARNING *** >=20 > 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. >=20 >=20 > Easy to invent the automatic mechanism: > Only need an address? Use ND. > Need more? use ND for getting address, find central server, get more. >=20 > Teco. >=20 >=20 > Op 2 jul 2010, om 20:59 heeft Mark Townsley het volgende geschreven: >=20 >>=20 >> My kneejerk reaction to this is that walking in with the goal of > having >> more than one way to autoconfigure a manet is a bad idea. >>=20 >> If we end up with two ways to autoconfigure, then we will have to > invent >> an automatic mechanism on top to choose which autoconfiguration >> mechanism to use. That doesn't help anyone. In absence of > knowledgeable >> human configuration, hard choices that narrow functional options >> typically far outweigh the potential benefits of one option vs. the >> other. So, even if you can prove that A is better than B, B is still >> better than A+B. >>=20 >> Let's strive for making a choice, at least within the MANET domain. >>=20 >> - Mark >>=20 >>=20 >> On 7/2/10 3:21 PM, Holtzer, A.C.G. (Arjen) wrote: >>> Hello autoconfers, >>>=20 >>> I support this "two-case"-approach, Christopher mentions: so >>> standardizing one centralized and one decentralized solution (or one >>> stateful and one stateless solution, just like in the current IPv6 >>> standards). I agree that the solution should make use of existing >>> protocols as much as possible (e.g. DHCP, ND, ...), but my choice > would >>> be not to state in the charter that DHCP must be used in all > solutions >>> coming out of the WG. >>>=20 >>> draft-bernardos-manet-autoconf-survey-05 shows there are already = many >>> proposals existing, making it a good starting point for going into >>> solution space. Actually even more than just a starting point since > many >>> of the proposals have already been around for a while. So I support > this >>> doc. >>>=20 >>> Best regards, >>> Arjen >>>=20 >>>>=20 >>>> If Charlie can find a few like-minded people to work on that,=20 >>>> why not add this as a parallel activity? The rationale of why=20 >>>> two cases should be straightforward to make, they are almost=20 >>>> chalk and cheese in e.g. centralised versus non-centralised.=20 >>>> This is actually added safety to the group producing=20 >>>> something, as if one succeeds and the other fails, that's still > good. >>>>=20 >>>>=20 >>> This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/disclaimer/email.html >>>=20 >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >>>=20 >>=20 >> _______________________________________________ >> 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 > ******************************************************************** > 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 From alexandru.petrescu@gmail.com Mon Jul 5 08:46:19 2010 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 74CDE3A693D for ; Mon, 5 Jul 2010 08:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 Cq9WF-o+XQJS for ; Mon, 5 Jul 2010 08:46:18 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 7EEE13A69B0 for ; Mon, 5 Jul 2010 08:46:18 -0700 (PDT) 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 o65FkIjx018947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 5 Jul 2010 17:46:18 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o65FkIxO013401; Mon, 5 Jul 2010 17:46:18 +0200 (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 o65FkInH011196; Mon, 5 Jul 2010 17:46:18 +0200 Message-ID: <4C31FE4A.608@gmail.com> Date: Mon, 05 Jul 2010 17:46:18 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "autoconf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: JANNETEAU Christophe Subject: [Autoconf] A new draft for RA-based prefix exchanges between MRs 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, 05 Jul 2010 15:46:19 -0000 Dear AUTOCONFers, I have submitted a new draft "Router Advertisements for Routing between Moving Networks" : http://www.ietf.org/id/draft-petrescu-autoconf-ra-based-routing-00.txt This is a evolution of a previous draft doing prefixes in the RAs, which was part of the MANEMO discussion. We added some scenarios such as route deletion and 3rd MR arrival. I am interested in any discussion that may relate the idea presented in this draft to the AUTOCONF activities. If discussed, then I am eager to present in Maastricht. (I will also post to MEXT). Alex From alexandru.petrescu@gmail.com Tue Jul 6 08:31:02 2010 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 C071F3A69A0 for ; Tue, 6 Jul 2010 08:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.073 X-Spam-Level: X-Spam-Status: No, score=0.073 tagged_above=-999 required=5 tests=[AWL=-0.278, 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 l68gxp5d9Bn7 for ; Tue, 6 Jul 2010 08:30:58 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 8B2613A6A2B for ; Tue, 6 Jul 2010 08:30:58 -0700 (PDT) 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 o66FUxYZ016646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 6 Jul 2010 17:30:59 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o66FUx71012317 for ; Tue, 6 Jul 2010 17:30:59 +0200 (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 o66FUwMB031119 for ; Tue, 6 Jul 2010 17:30:59 +0200 Message-ID: <4C334C32.4080106@gmail.com> Date: Tue, 06 Jul 2010 17:30:58 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: autoconf@ietf.org References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> <4C2A723E.3020806@piuha.net> <4C2B801B.1070004@earthlink.net> <4C2E16A3.1080007@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Autoconf] DHCP and AUTOCONF (was: Call for comments to a new AUTOCONF charter proposal.) 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, 06 Jul 2010 15:31:02 -0000 Hi Emmanuel, Le 03/07/2010 12:17, Emmanuel Baccelli a écrit : > Hi Charlie, > > I agree with you about trying to avoid the dichotomy > centralized/decentralized. I agree to try to avoid the dichotomy centralized-decentralized because DHCP has already many features exhibiting decentralization: -DHCPv6 dst address is multicast: several servers can be in that group. -several DHCP Servers running on the the same address with VRRP. -Several Relays per a DHCP Server. -DHCP Reconfigure message to let a Server suggest a Client another Server. -RA tell the Node there's a better DHCP Server available. -there are surely more. > If some people want to work on a DHCP-dependent solution, let them > try. If some other people want to work in parallel on a > DHCP-independent solution, why not let them do it too? I don't know, it's too simply put. I'd evaluate the work quantity needed for each, and prefer reuse. Alex > > In my mind, these two solutions could be pretty complementary. > > Emmanuel > > > > On Fri, Jul 2, 2010 at 6:41 PM, Charles E. Perkins > > wrote: > > Hello Emmanuel and all, > > Thanks for supporting the consideration of decentralized approach. > I'm pretty sure we could get at least one good working solution in > time a lot faster than it took to agree that not everything is an > Ethernet. > > However, it's important to avoid making a sharp dichotomy between > "centralized" and "decentralized" approaches. My big concern was > that somehow the DHCP model was going to be considered the only > viable choice because people (outsiders?) consider it to be the only > known quantity. There are other ways to have more centralized or > less centralized procedures, with or without proxy assistance, > perhaps hybridized approaches, and with improved availability via > elections. > > Those are just a few of the options, and probably all of them are way > better than trying to shoehorn DHCP where it does not seem to fit. > Flushing years of development and wisdom down the toilet just because > they doesn't spell DHCP seems really wrong to me. > > Another point to keep in mind -- DHCP was designed and built from day > one to be a _managed_ solution for autoconfiguration. It seems quite > clear to me that most of the interesting development and inspiration > for ad hoc networks has gone towards enabling networking in > environments where no such tightly managed administration is > possible. Thus, in my view, DHCP almost tautologically disqualifies > itself from consideration without major structural redesign. How is > it, then, that DHCP keeps cropping up in the discussion? > > Regards, Charlie P. > > > > > On 7/1/2010 2:28 AM, Emmanuel Baccelli wrote: > > > > On Thu, Jul 1, 2010 at 11:02 AM, Dearlove, Christopher (UK) > > >> > > wrote: > > Charles Perkins >> I'd be happy if it were possible for [autoconf] to be allowed to >> consider the excellent body of work that was seen already years ago >> -- the same body of work that motivated me and others to create and >> spend a lot of time over the last years and years. > > If Charlie can find a few like-minded people to work on that, why not > add this as a parallel activity? The rationale of why two cases > should be straightforward to make, they are almost chalk and cheese > in e.g. centralised versus non-centralised. This is actually added > safety to the group producing something, as if one succeeds and the > other fails, that's still good. > > > > I also think this parallel approach could be appropriate too. > > > Unfortunately, I can't offer to be one of those people. Although I > should be able to contribute at the read and comment level, more than > that is needed. I only didn't make the suggestion earlier as it needs > people (with all due respect to Charlie, plural) to do the work. > > > > I'd be happy to help out on the matter. So I guess we have a plural > + contributors ;) > > cheers, > > Emmanuel > > > > _______________________________________________ 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 jari.arkko@piuha.net Wed Jul 7 14:34:35 2010 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 1EEEE3A69B0 for ; Wed, 7 Jul 2010 14:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 Dhcirvn7V+Th for ; Wed, 7 Jul 2010 14:34:34 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 9F7353A6991 for ; Wed, 7 Jul 2010 14:34:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 481562CED3 for ; Thu, 8 Jul 2010 00:34:36 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2SWRBP-O94o for ; Thu, 8 Jul 2010 00:34:35 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A9DF52CEB5 for ; Thu, 8 Jul 2010 00:34:35 +0300 (EEST) Message-ID: <4C34F2E8.1080908@piuha.net> Date: Thu, 08 Jul 2010 00:34:32 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "autoconf@ietf.org" References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> In-Reply-To: <4C2CFADD.3040909@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 07 Jul 2010 21:34:35 -0000 Just a reminder that we have to decide what to do here. We will determine what to do based on WG feedback. Absent any significant opposition, the default action will be to adopt the current proposal (posted earlier to the list) and publish the RFC. I would like to decide one week from now, i.e., please send comments by Wednesday, July 14th. Jari From henning.rogge@fkie.fraunhofer.de Wed Jul 7 22:57:21 2010 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 875AA3A6803 for ; Wed, 7 Jul 2010 22:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.256 X-Spam-Level: * X-Spam-Status: No, score=1.256 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] 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 Vhxrg7nLC4Ov for ; Wed, 7 Jul 2010 22:57:20 -0700 (PDT) Received: from mailguard.fgan.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by core3.amsl.com (Postfix) with ESMTP id BEB2A3A6818 for ; Wed, 7 Jul 2010 22:57:19 -0700 (PDT) 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 1OWk6r-0007v9-VN; Thu, 08 Jul 2010 07:57:22 +0200 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 1OWk6r-0004vq-MR; Thu, 08 Jul 2010 07:57:21 +0200 From: Henning Rogge To: autoconf@ietf.org Date: Thu, 8 Jul 2010 07:57:13 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-23-generic; KDE/4.4.5; i686; ; ) References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C34F2E8.1080908@piuha.net> In-Reply-To: <4C34F2E8.1080908@piuha.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1386217.hJ5EpWQljz"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201007080757.18522.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11334/Thu Jul 8 02:37:00 2010) by mailguard.fgan.de X-Scan-Signature: 52e07e0af4405bded81fc5fcc507a670 Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 08 Jul 2010 05:57:21 -0000 --nextPart1386217.hJ5EpWQljz Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Wed July 7 2010 23:34:32 Jari Arkko wrote: > Just a reminder that we have to decide what to do here. We will > determine what to do based on WG feedback. Absent any significant > opposition, the default action will be to adopt the current proposal > (posted earlier to the list) and publish the RFC. I would like to decide > one week from now, i.e., please send comments by Wednesday, July 14th. Absence of opposition ???? 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-961, 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 --nextPart1386217.hJ5EpWQljz 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) iEYEABECAAYFAkw1aLkACgkQRIfGfFXsz+B5ngCcC+jJ/nEPVHwKspTvbyMJ50M+ tkkAmwQI2JTN6jttGQ1NtQNOeAQm+4BC =5Bp0 -----END PGP SIGNATURE----- --nextPart1386217.hJ5EpWQljz-- From teco@inf-net.nl Thu Jul 8 00:09:45 2010 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 F3C093A67D3 for ; Thu, 8 Jul 2010 00:09:44 -0700 (PDT) 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 4jiwDpE5c2Vt for ; Thu, 8 Jul 2010 00:09:44 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id B24313A6359 for ; Thu, 8 Jul 2010 00:09:43 -0700 (PDT) Received: by eyb7 with SMTP id 7so68169eyb.31 for ; Thu, 08 Jul 2010 00:09:42 -0700 (PDT) Received: by 10.213.97.196 with SMTP id m4mr6456919ebn.80.1278572980833; Thu, 08 Jul 2010 00:09:40 -0700 (PDT) Received: from [10.128.0.162] ([77.61.241.196]) by mx.google.com with ESMTPS id a48sm68658414eei.1.2010.07.08.00.09.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 08 Jul 2010 00:09:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4C34F2E8.1080908@piuha.net> Date: Thu, 8 Jul 2010 09:09:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C34F2E8.1080908@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 08 Jul 2010 07:09:45 -0000 My remarks made before.=20 On the document: 1) IMHO the remarks on link-local are not that important. 2) My biggest problem is the /128 mask, this makes L3 communication = dependent on the MANET protocol, even for nodes with perfect L2 connectivity. = Using a=20 /64 on the MANET interface, and using the /128 for the routing protocol,=20= does not have this problem. This method is used quite often (at least in = some olsr and ospf implementations). Issue can be tackled in other documents, e.g. a problem statement, or = MANET=20 addressing version 2. In other words, try to publish the document soon. On the charter: I suggest to accept some documents as WG documents: - draft-bernardos-manet-autoconf-survey - draft-baccelli-multi-hop-wireless-communication I support the two-step approach, where the second (getting prefix and = optionally other parameters) will be based on DHCPv6. I think the first step could be based on SLAAC (ND-approach) and / or = DHCPv6. I say it is to early to decide. I am against working on a solution based on a single central node. Regards, Teco =20 Op 7 jul 2010, om 23:34 heeft Jari Arkko het volgende geschreven: > Just a reminder that we have to decide what to do here. We will = determine what to do based on WG feedback. Absent any significant = opposition, the default action will be to adopt the current proposal = (posted earlier to the list) and publish the RFC. I would like to decide = one week from now, i.e., please send comments by Wednesday, July 14th. >=20 > Jari >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From Chris.Dearlove@baesystems.com Thu Jul 8 01:55:26 2010 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 3B0643A69B2 for ; Thu, 8 Jul 2010 01:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.421 X-Spam-Level: X-Spam-Status: No, score=-5.421 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_20=-0.74, 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 gKtZ7B5bqV05 for ; Thu, 8 Jul 2010 01:55:25 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 0D3AE3A681E for ; Thu, 8 Jul 2010 01:55:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,557,1272841200"; d="scan'208";a="75212977" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 08 Jul 2010 09:55:26 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o688tPba016150; Thu, 8 Jul 2010 09:55:25 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Jul 2010 09:55:25 +0100 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: Thu, 8 Jul 2010 09:55:24 +0100 Message-ID: In-Reply-To: <4C34F2E8.1080908@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) thread-index: AcseHDxCSgd0s+VmRNKyT76dvpiyHAAXhM6Q References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C34F2E8.1080908@piuha.net> From: "Dearlove, Christopher (UK)" To: "Jari Arkko" , X-OriginalArrivalTime: 08 Jul 2010 08:55:25.0485 (UTC) FILETIME=[4E5EFDD0:01CB1E7B] Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 08 Jul 2010 08:55:26 -0000 It still seems odd, at the least, to be back at the WG in AUTH48. But having said that, there are three suggested edits. Bottom line either version of each is acceptable. There is however a difference in the third one. The first two are clarifying technical comments. I'm not sure they really add anything, but they don't hurt. The third is different though, it changes the actual meaning, from "this is preferred", to "this is more useful", which are not the same thing. I think the old version is what got consensus everywhere, and changing it is a bit more than editorial. But as I said, either is acceptable in itself. -- 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: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behalf Of Jari Arkko Sent: 07 July 2010 22:35 To: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. Just a reminder that we have to decide what to do here. We will determine what to do based on WG feedback. Absent any significant opposition, the default action will be to adopt the current proposal (posted earlier to the list) and publish the RFC. I would like to decide one week from now, i.e., please send comments by Wednesday, July 14th. Jari _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf ******************************************************************** 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 Jul 8 02:01:27 2010 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 4BB193A69F0 for ; Thu, 8 Jul 2010 02:01:27 -0700 (PDT) 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 CwbyR8J6I40W for ; Thu, 8 Jul 2010 02:01:26 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 5ABE63A6946 for ; Thu, 8 Jul 2010 02:01:26 -0700 (PDT) Received: by bwz7 with SMTP id 7so358227bwz.31 for ; Thu, 08 Jul 2010 02:01:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.6.74 with SMTP id 10mr5989853bky.203.1278579685110; Thu, 08 Jul 2010 02:01:25 -0700 (PDT) Received: by 10.204.68.13 with HTTP; Thu, 8 Jul 2010 02:01:24 -0700 (PDT) In-Reply-To: References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C34F2E8.1080908@piuha.net> Date: Thu, 8 Jul 2010 11:01:24 +0200 Message-ID: From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 08 Jul 2010 09:01:27 -0000 On Thu, Jul 8, 2010 at 10:55 AM, Dearlove, Christopher (UK) wrote: > It still seems odd, at the least, to be back at the WG in AUTH48. > But having said that, there are three suggested edits. Bottom line > either version of each is acceptable. There is however a difference > in the third one. The first two are clarifying technical comments. > I'm not sure they really add anything, but they don't hurt. The > third is different though, it changes the actual meaning, from > "this is preferred", to "this is more useful", which are not the > same thing. I think the old version is what got consensus everywhere, > and changing it is a bit more than editorial. But as I said, either > is acceptable in itself. I agree with Chris. I am fine with the first two edits. The last seems to change the content on which the WG has agreed upon. I don't think we should change this in AUTH48, unless there is a very strong new argument, which the WG has missed or not correctly understood. Ulrich From charles.perkins@earthlink.net Thu Jul 8 10:29:08 2010 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 87BF43A63EC for ; Thu, 8 Jul 2010 10:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 BdCM99dKRIBn for ; Thu, 8 Jul 2010 10:29:07 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 32B193A6878 for ; Thu, 8 Jul 2010 10:29:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Afu+V841apmhH+N8ZJSwrizcaoZgnZaGq6uqRCwfdRK8+ISeV9jeiq+VNkbvzXmt; 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.130.11]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OWutv-0003ay-Oh; Thu, 08 Jul 2010 13:28:45 -0400 Message-ID: <4C360AAE.9090103@earthlink.net> Date: Thu, 08 Jul 2010 10:28:14 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Jari Arkko References: <4C2A6BB7.1000900@piuha.net> In-Reply-To: <4C2A6BB7.1000900@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52ce6178fbf82111ccbf9e2d32c981e1d7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 08 Jul 2010 17:29:09 -0000 Hello Jari, I support the publication of RFC 5889 with the inclusion of the revisions as you and Erik have suggested below. Regarding the last edit, I am also O.K. with that, but with the understanding that link-local solutions are neither favored or disfavored per se. Wide applicability and performance issues (for example) are (to me at least) much more important. Regards, Charlie P. On 6/29/2010 2:55 PM, Jari Arkko wrote: > Christopher, > >> Incidentally the charter refers to RFC 5889, which is not yet published. >> I see that is in AUTH48, but noted as on hold for a technical issue. >> AUTH48 seems rather late for a technical issue, unless meaning a >> publication technical issue rather than an engineering technical issue. > > Yes it is late. We approved the document but after approval there was a > comment on the IETF last call thread from Erik Nordmark. We are trying > to resolve it but unfortunately it took a long time for me to do so. But > we are now trying to do it. The standing proposal is below, comments > appreciated. > > Jari > > ----- > > We talked about this during Anaheim but never got to the end of it. > Sorry -- I should have posted a suggestion back then but other business > has kept me busy. I have now looked at the discussion again. > > The essence of Erik's complaint was twofold. First, the document claimed > that routing protocols require a unique IP address (and not just a > router ID), which is not true. Second, that the document unnecessarily > dismisses link local identifiers as addresses. > > About the first issue: Erik is right that not all routing protocols > require unique IP addresses at all. But at the same time, apparently > some routing protocols in the MANET space do require it (e.g., OSLR in > RFC 3626). In a way, the document is factually correct on this point as > it states that some protocols do have these requirements. But it may > also be misleading from another perspective, as we certainly do not want > to claim that using unique IP addresses is a recommended design for a > routing protocol or the only possible model. > > The second issue is partially related to the first one, as one of the > reasons for using non-link-local addresses is to enable the use of > unique addresses in routing protocols. In any case, the intent was never > to claim that link local addresses cannot be used. The document merely > makes one recommendation about a commonly used addressing model in adhoc > networks. I would like to defend the working group's right to publish > such an "example model" -- particularly after years of effort spent in > trying to find the true universal model. As long as the working group is > not making false claims, this is clearly appropriate. But I can see that > the document could be clearer about its claims. > > Here's a possible rewrite of Section 5 to address these issues: > > OLD: > Routing protocols running on a router may exhibit different > requirements for uniqueness of interface addresses; some have no such > requirements, others have requirements ranging from local uniqueness > only, to uniqueness within, at least, the routing domain (as defined > in [RFC1136]). > > Configuring an IP address that is unique within the routing domain > satisfies the less stringent uniqueness requirements of local > uniqueness, while also enabling protocols which have the most > stringent requirements of uniqueness within the routing domain. This > suggests the following principle: > > o an IP address assigned to an interface that connects to a link > with undetermined connectivity properties should be unique, at > least within the routing domain. > NEW: > Routing protocols running on a router may exhibit different > requirements for uniqueness of interface addresses; some have no such > requirements, others have requirements ranging from local uniqueness > only, to uniqueness within, at least, the routing domain (as defined > in [RFC1136]). Many modern routing protocols do not need to employ > unique addresses at all, and theoretically, their only requirement is that > some router identifier is unique. > > Nevertheless, configuring an IP address that is unique within the routing > domain satisfies the less stringent uniqueness requirements of local > uniqueness, while also enabling protocols which have the most > stringent requirements of uniqueness within the routing domain. As > a result, many current deployments have chosen to employ the following > simplifying principle: > > o an IP address assigned to an interface that connects to a link > with undetermined connectivity properties should be unique, at > least within the routing domain. > > And in Section 6.1: > > OLD: > o There is no mechanism to ensure that IPv6 link-local addresses are > unique across multiple links, hence they cannot be used to > reliably identify routers (it is often desirable to identify a > router with an IP address). > NEW: > o There is no mechanism to ensure that IPv6 link-local addresses are > unique across multiple links, hence they cannot be used to > reliably identify routers, should this be necessary in the chosen > routing protocol. > > OLD: > Therefore, autoconfiguration solutions should be encouraged to > primarily focus on configuring IP addresses that are not IPv6 link- > local. > NEW: > Therefore, a common theme in many autoconfiguration solutions is to > focus on configuring IP addresses that are not IPv6 link- > local. > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From alexandru.petrescu@gmail.com Thu Jul 8 10:42:35 2010 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 B04033A679F for ; Thu, 8 Jul 2010 10:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.268 X-Spam-Level: X-Spam-Status: No, score=-0.268 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_05=-1.11, 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 8XGBALEUaYY6 for ; Thu, 8 Jul 2010 10:42:34 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 627AE3A6847 for ; Thu, 8 Jul 2010 10:42:32 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 3C210940159 for ; Thu, 8 Jul 2010 19:42:31 +0200 (CEST) Message-ID: <4C360E05.2050601@gmail.com> Date: Thu, 08 Jul 2010 19:42:29 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: autoconf@ietf.org References: <4C2A6BB7.1000900@piuha.net> In-Reply-To: <4C2A6BB7.1000900@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100708-1, 08/07/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 08 Jul 2010 17:42:35 -0000 Le 29/06/2010 23:55, Jari Arkko a écrit : > Christopher, > >> Incidentally the charter refers to RFC 5889, which is not yet published. >> I see that is in AUTH48, but noted as on hold for a technical issue. >> AUTH48 seems rather late for a technical issue, unless meaning a >> publication technical issue rather than an engineering technical issue. > > Yes it is late. We approved the document but after approval there was a > comment on the IETF last call thread from Erik Nordmark. We are trying > to resolve it but unfortunately it took a long time for me to do so. But > we are now trying to do it. The standing proposal is below, comments > appreciated. > > Jari > > ----- > > We talked about this during Anaheim but never got to the end of it. > Sorry -- I should have posted a suggestion back then but other business > has kept me busy. I have now looked at the discussion again. > > The essence of Erik's complaint was twofold. First, the document claimed > that routing protocols require a unique IP address (and not just a > router ID), which is not true. Second, that the document unnecessarily > dismisses link local identifiers as addresses. > > About the first issue: Erik is right that not all routing protocols > require unique IP addresses at all. But at the same time, apparently > some routing protocols in the MANET space do require it (e.g., OSLR in > RFC 3626). In a way, the document is factually correct on this point as > it states that some protocols do have these requirements. But it may > also be misleading from another perspective, as we certainly do not want > to claim that using unique IP addresses is a recommended design for a > routing protocol or the only possible model. > > The second issue is partially related to the first one, as one of the > reasons for using non-link-local addresses is to enable the use of > unique addresses in routing protocols. In any case, the intent was never > to claim that link local addresses cannot be used. The document merely > makes one recommendation about a commonly used addressing model in adhoc > networks. I would like to defend the working group's right to publish > such an "example model" -- particularly after years of effort spent in > trying to find the true universal model. As long as the working group is > not making false claims, this is clearly appropriate. But I can see that > the document could be clearer about its claims. > > Here's a possible rewrite of Section 5 to address these issues: > > OLD: > Routing protocols running on a router may exhibit different > requirements for uniqueness of interface addresses; some have no such > requirements, others have requirements ranging from local uniqueness > only, to uniqueness within, at least, the routing domain (as defined > in [RFC1136]). > > Configuring an IP address that is unique within the routing domain > satisfies the less stringent uniqueness requirements of local > uniqueness, while also enabling protocols which have the most > stringent requirements of uniqueness within the routing domain. This > suggests the following principle: > > o an IP address assigned to an interface that connects to a link > with undetermined connectivity properties should be unique, at > least within the routing domain. > NEW: > Routing protocols running on a router may exhibit different > requirements for uniqueness of interface addresses; some have no such > requirements, others have requirements ranging from local uniqueness > only, to uniqueness within, at least, the routing domain (as defined > in [RFC1136]). Many modern routing protocols do not need to employ > unique addresses at all, and theoretically, their only requirement is that > some router identifier is unique. > > Nevertheless, configuring an IP address that is unique within the routing > domain satisfies the less stringent uniqueness requirements of local > uniqueness, while also enabling protocols which have the most > stringent requirements of uniqueness within the routing domain. As > a result, many current deployments have chosen to employ the following > simplifying principle: > > o an IP address assigned to an interface that connects to a link > with undetermined connectivity properties should be unique, at > least within the routing domain. > > And in Section 6.1: > > OLD: > o There is no mechanism to ensure that IPv6 link-local addresses are > unique across multiple links, hence they cannot be used to > reliably identify routers (it is often desirable to identify a > router with an IP address). > NEW: > o There is no mechanism to ensure that IPv6 link-local addresses are > unique across multiple links, hence they cannot be used to > reliably identify routers, should this be necessary in the chosen > routing protocol. There is no mechanism to ensure that IPv6 global addresses are unique across multiple globes either. They are globally unique across our globe, as the link-local addresses are unique across one link. I don't see the sense of both OLD and NEW "There is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links" - they don't need to. From that unnecessary statement to derive the conclusion "they cannot be used to reliably identify routers" is making even less sense. For me it's hard to retrofit proper thinking into text making little sense to my reading, IMHO. Alex > > OLD: > Therefore, autoconfiguration solutions should be encouraged to > primarily focus on configuring IP addresses that are not IPv6 link- > local. > NEW: > Therefore, a common theme in many autoconfiguration solutions is to > focus on configuring IP addresses that are not IPv6 link- > local. > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From sratliff@cisco.com Thu Jul 8 10:45:25 2010 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 795C13A679F for ; Thu, 8 Jul 2010 10:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 qLqAdU0OYXPn for ; Thu, 8 Jul 2010 10:45:24 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 020FD3A688B for ; Thu, 8 Jul 2010 10:45:23 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD+rNUxAZnwN/2dsb2JhbACgMXGmaJp7glyCSQSIQg X-IronPort-AV: E=Sophos;i="4.53,559,1272844800"; d="scan'208";a="130124319" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 08 Jul 2010 17:45:23 +0000 Received: from dhcp-64-102-54-238.cisco.com (dhcp-64-102-54-238.cisco.com [64.102.54.238]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o68HjNQk006059; Thu, 8 Jul 2010 17:45:23 GMT Message-Id: <401ECF37-F543-423F-912B-A10A816FC5B9@cisco.com> From: Stan Ratliff To: "Charles E. Perkins" In-Reply-To: <4C360AAE.9090103@earthlink.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Jul 2010 13:45:24 -0400 References: <4C2A6BB7.1000900@piuha.net> <4C360AAE.9090103@earthlink.net> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 08 Jul 2010 17:45:25 -0000 Jari, +1 on what Charlie said. Regards, Stan On Jul 8, 2010, at 1:28 PM, Charles E. Perkins wrote: > > Hello Jari, > > I support the publication of RFC 5889 with the inclusion of > the revisions as you and Erik have suggested below. > > Regarding the last edit, I am also O.K. with that, but > with the understanding that link-local solutions are > neither favored or disfavored per se. Wide applicability > and performance issues (for example) are (to me at least) > much more important. > > Regards, > Charlie P. > > > On 6/29/2010 2:55 PM, Jari Arkko wrote: >> Christopher, >> >>> Incidentally the charter refers to RFC 5889, which is not yet >>> published. >>> I see that is in AUTH48, but noted as on hold for a technical issue. >>> AUTH48 seems rather late for a technical issue, unless meaning a >>> publication technical issue rather than an engineering technical >>> issue. >> >> Yes it is late. We approved the document but after approval there >> was a >> comment on the IETF last call thread from Erik Nordmark. We are >> trying >> to resolve it but unfortunately it took a long time for me to do >> so. But >> we are now trying to do it. The standing proposal is below, comments >> appreciated. >> >> Jari >> >> ----- >> >> We talked about this during Anaheim but never got to the end of it. >> Sorry -- I should have posted a suggestion back then but other >> business >> has kept me busy. I have now looked at the discussion again. >> >> The essence of Erik's complaint was twofold. First, the document >> claimed >> that routing protocols require a unique IP address (and not just a >> router ID), which is not true. Second, that the document >> unnecessarily >> dismisses link local identifiers as addresses. >> >> About the first issue: Erik is right that not all routing protocols >> require unique IP addresses at all. But at the same time, apparently >> some routing protocols in the MANET space do require it (e.g., OSLR >> in >> RFC 3626). In a way, the document is factually correct on this >> point as >> it states that some protocols do have these requirements. But it may >> also be misleading from another perspective, as we certainly do not >> want >> to claim that using unique IP addresses is a recommended design for a >> routing protocol or the only possible model. >> >> The second issue is partially related to the first one, as one of the >> reasons for using non-link-local addresses is to enable the use of >> unique addresses in routing protocols. In any case, the intent was >> never >> to claim that link local addresses cannot be used. The document >> merely >> makes one recommendation about a commonly used addressing model in >> adhoc >> networks. I would like to defend the working group's right to publish >> such an "example model" -- particularly after years of effort spent >> in >> trying to find the true universal model. As long as the working >> group is >> not making false claims, this is clearly appropriate. But I can see >> that >> the document could be clearer about its claims. >> >> Here's a possible rewrite of Section 5 to address these issues: >> >> OLD: >> Routing protocols running on a router may exhibit different >> requirements for uniqueness of interface addresses; some have no such >> requirements, others have requirements ranging from local uniqueness >> only, to uniqueness within, at least, the routing domain (as defined >> in [RFC1136]). >> >> Configuring an IP address that is unique within the routing domain >> satisfies the less stringent uniqueness requirements of local >> uniqueness, while also enabling protocols which have the most >> stringent requirements of uniqueness within the routing domain. This >> suggests the following principle: >> >> o an IP address assigned to an interface that connects to a link >> with undetermined connectivity properties should be unique, at >> least within the routing domain. >> NEW: >> Routing protocols running on a router may exhibit different >> requirements for uniqueness of interface addresses; some have no such >> requirements, others have requirements ranging from local uniqueness >> only, to uniqueness within, at least, the routing domain (as defined >> in [RFC1136]). Many modern routing protocols do not need to employ >> unique addresses at all, and theoretically, their only requirement >> is that >> some router identifier is unique. >> >> Nevertheless, configuring an IP address that is unique within the >> routing >> domain satisfies the less stringent uniqueness requirements of local >> uniqueness, while also enabling protocols which have the most >> stringent requirements of uniqueness within the routing domain. As >> a result, many current deployments have chosen to employ the >> following >> simplifying principle: >> >> o an IP address assigned to an interface that connects to a link >> with undetermined connectivity properties should be unique, at >> least within the routing domain. >> >> And in Section 6.1: >> >> OLD: >> o There is no mechanism to ensure that IPv6 link-local addresses are >> unique across multiple links, hence they cannot be used to >> reliably identify routers (it is often desirable to identify a >> router with an IP address). >> NEW: >> o There is no mechanism to ensure that IPv6 link-local addresses are >> unique across multiple links, hence they cannot be used to >> reliably identify routers, should this be necessary in the chosen >> routing protocol. >> >> OLD: >> Therefore, autoconfiguration solutions should be encouraged to >> primarily focus on configuring IP addresses that are not IPv6 link- >> local. >> NEW: >> Therefore, a common theme in many autoconfiguration solutions is to >> focus on configuring IP addresses that are not IPv6 link- >> local. >> >> _______________________________________________ >> 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 Thu Jul 8 10:48:31 2010 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 D9DFA3A687A for ; Thu, 8 Jul 2010 10:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.367 X-Spam-Level: X-Spam-Status: No, score=-0.367 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_05=-1.11, 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 eeStcY682sjL for ; Thu, 8 Jul 2010 10:48:30 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 892843A6831 for ; Thu, 8 Jul 2010 10:48:28 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 85C0F9400FE for ; Thu, 8 Jul 2010 19:48:28 +0200 (CEST) Message-ID: <4C360F6A.5070208@gmail.com> Date: Thu, 08 Jul 2010 19:48:26 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: autoconf@ietf.org References: <4C2A6BB7.1000900@piuha.net> In-Reply-To: <4C2A6BB7.1000900@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100708-1, 08/07/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 08 Jul 2010 17:48:32 -0000 Le 29/06/2010 23:55, Jari Arkko a écrit : > Christopher, > >> Incidentally the charter refers to RFC 5889, which is not yet >> published. I see that is in AUTH48, but noted as on hold for a >> technical issue. AUTH48 seems rather late for a technical issue, >> unless meaning a publication technical issue rather than an >> engineering technical issue. > > Yes it is late. We approved the document but after approval there was > a comment on the IETF last call thread from Erik Nordmark. We are > trying to resolve it but unfortunately it took a long time for me to > do so. But we are now trying to do it. The standing proposal is > below, comments appreciated. Jari - I am ready to spend time reading and trying to understand. I am ready to give my oppinion about this last point - the IPv6 link-local addresses. If asked whether I agree with the NEW text on LLs then I say no, I do not agree with it. It is better than the old text but still makes little sense to my reading (e.g. "IPv6 ll addresses are not unique across links" is a statement which makes little sense, an answer to something nobody doubted; worst, to derive conclusions saying that LL addresses are not useful in "MANET ad-hoc" networks because of their lack of uniqueness is even less sense.) My two cents worth, Alex > > Jari > > ----- > > We talked about this during Anaheim but never got to the end of it. > Sorry -- I should have posted a suggestion back then but other > business has kept me busy. I have now looked at the discussion > again. > > The essence of Erik's complaint was twofold. First, the document > claimed that routing protocols require a unique IP address (and not > just a router ID), which is not true. Second, that the document > unnecessarily dismisses link local identifiers as addresses. > > About the first issue: Erik is right that not all routing protocols > require unique IP addresses at all. But at the same time, apparently > some routing protocols in the MANET space do require it (e.g., OSLR > in RFC 3626). In a way, the document is factually correct on this > point as it states that some protocols do have these requirements. > But it may also be misleading from another perspective, as we > certainly do not want to claim that using unique IP addresses is a > recommended design for a routing protocol or the only possible > model. > > The second issue is partially related to the first one, as one of the > reasons for using non-link-local addresses is to enable the use of > unique addresses in routing protocols. In any case, the intent was > never to claim that link local addresses cannot be used. The document > merely makes one recommendation about a commonly used addressing > model in adhoc networks. I would like to defend the working group's > right to publish such an "example model" -- particularly after years > of effort spent in trying to find the true universal model. As long > as the working group is not making false claims, this is clearly > appropriate. But I can see that the document could be clearer about > its claims. > > Here's a possible rewrite of Section 5 to address these issues: > > OLD: Routing protocols running on a router may exhibit different > requirements for uniqueness of interface addresses; some have no > such requirements, others have requirements ranging from local > uniqueness only, to uniqueness within, at least, the routing domain > (as defined in [RFC1136]). > > Configuring an IP address that is unique within the routing domain > satisfies the less stringent uniqueness requirements of local > uniqueness, while also enabling protocols which have the most > stringent requirements of uniqueness within the routing domain. This > suggests the following principle: > > o an IP address assigned to an interface that connects to a link with > undetermined connectivity properties should be unique, at least > within the routing domain. NEW: Routing protocols running on a router > may exhibit different requirements for uniqueness of interface > addresses; some have no such requirements, others have requirements > ranging from local uniqueness only, to uniqueness within, at least, > the routing domain (as defined in [RFC1136]). Many modern routing > protocols do not need to employ unique addresses at all, and > theoretically, their only requirement is that some router identifier > is unique. > > Nevertheless, configuring an IP address that is unique within the > routing domain satisfies the less stringent uniqueness requirements > of local uniqueness, while also enabling protocols which have the > most stringent requirements of uniqueness within the routing domain. > As a result, many current deployments have chosen to employ the > following simplifying principle: > > o an IP address assigned to an interface that connects to a link with > undetermined connectivity properties should be unique, at least > within the routing domain. > > And in Section 6.1: > > OLD: o There is no mechanism to ensure that IPv6 link-local addresses > are unique across multiple links, hence they cannot be used to > reliably identify routers (it is often desirable to identify a router > with an IP address). NEW: o There is no mechanism to ensure that IPv6 > link-local addresses are unique across multiple links, hence they > cannot be used to reliably identify routers, should this be necessary > in the chosen routing protocol. > > OLD: Therefore, autoconfiguration solutions should be encouraged to > primarily focus on configuring IP addresses that are not IPv6 link- > local. NEW: Therefore, a common theme in many autoconfiguration > solutions is to focus on configuring IP addresses that are not IPv6 > link- local. > > _______________________________________________ Autoconf mailing > list Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From alexandru.petrescu@gmail.com Thu Jul 8 11:21:42 2010 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 EB1E13A6804 for ; Thu, 8 Jul 2010 11:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[AWL=1.072, 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 GX9AmeAivlQB for ; Thu, 8 Jul 2010 11:21:41 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 6E69B3A67C0 for ; Thu, 8 Jul 2010 11:21:39 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 715159400C2 for ; Thu, 8 Jul 2010 20:21:39 +0200 (CEST) Message-ID: <4C361731.9020809@gmail.com> Date: Thu, 08 Jul 2010 20:21:37 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: autoconf@ietf.org References: <4C2A6BB7.1000900@piuha.net> <4C360AAE.9090103@earthlink.net> In-Reply-To: <4C360AAE.9090103@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100708-1, 08/07/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 08 Jul 2010 18:21:43 -0000 Le 08/07/2010 19:28, Charles E. Perkins a écrit : > > Hello Jari, > > I support the publication of RFC 5889 with the inclusion of > the revisions as you and Erik have suggested below. > > Regarding the last edit, I am also O.K. with that, but > with the understanding that link-local solutions are > neither favored or disfavored per se. That sounds as a "MAY LL" which is more positive to my reading than "There is no mechanism to ensure uniqueness LL ... hence ... cannot ..." Writing "There MAY be link-local solutions" is something I could easily agree with. Alex Wide applicability > and performance issues (for example) are (to me at least) > much more important. > > Regards, > Charlie P. > > > On 6/29/2010 2:55 PM, Jari Arkko wrote: >> Christopher, >> >>> Incidentally the charter refers to RFC 5889, which is not yet published. >>> I see that is in AUTH48, but noted as on hold for a technical issue. >>> AUTH48 seems rather late for a technical issue, unless meaning a >>> publication technical issue rather than an engineering technical issue. >> >> Yes it is late. We approved the document but after approval there was a >> comment on the IETF last call thread from Erik Nordmark. We are trying >> to resolve it but unfortunately it took a long time for me to do so. But >> we are now trying to do it. The standing proposal is below, comments >> appreciated. >> >> Jari >> >> ----- >> >> We talked about this during Anaheim but never got to the end of it. >> Sorry -- I should have posted a suggestion back then but other business >> has kept me busy. I have now looked at the discussion again. >> >> The essence of Erik's complaint was twofold. First, the document claimed >> that routing protocols require a unique IP address (and not just a >> router ID), which is not true. Second, that the document unnecessarily >> dismisses link local identifiers as addresses. >> >> About the first issue: Erik is right that not all routing protocols >> require unique IP addresses at all. But at the same time, apparently >> some routing protocols in the MANET space do require it (e.g., OSLR in >> RFC 3626). In a way, the document is factually correct on this point as >> it states that some protocols do have these requirements. But it may >> also be misleading from another perspective, as we certainly do not want >> to claim that using unique IP addresses is a recommended design for a >> routing protocol or the only possible model. >> >> The second issue is partially related to the first one, as one of the >> reasons for using non-link-local addresses is to enable the use of >> unique addresses in routing protocols. In any case, the intent was never >> to claim that link local addresses cannot be used. The document merely >> makes one recommendation about a commonly used addressing model in adhoc >> networks. I would like to defend the working group's right to publish >> such an "example model" -- particularly after years of effort spent in >> trying to find the true universal model. As long as the working group is >> not making false claims, this is clearly appropriate. But I can see that >> the document could be clearer about its claims. >> >> Here's a possible rewrite of Section 5 to address these issues: >> >> OLD: >> Routing protocols running on a router may exhibit different >> requirements for uniqueness of interface addresses; some have no such >> requirements, others have requirements ranging from local uniqueness >> only, to uniqueness within, at least, the routing domain (as defined >> in [RFC1136]). >> >> Configuring an IP address that is unique within the routing domain >> satisfies the less stringent uniqueness requirements of local >> uniqueness, while also enabling protocols which have the most >> stringent requirements of uniqueness within the routing domain. This >> suggests the following principle: >> >> o an IP address assigned to an interface that connects to a link >> with undetermined connectivity properties should be unique, at >> least within the routing domain. >> NEW: >> Routing protocols running on a router may exhibit different >> requirements for uniqueness of interface addresses; some have no such >> requirements, others have requirements ranging from local uniqueness >> only, to uniqueness within, at least, the routing domain (as defined >> in [RFC1136]). Many modern routing protocols do not need to employ >> unique addresses at all, and theoretically, their only requirement is >> that >> some router identifier is unique. >> >> Nevertheless, configuring an IP address that is unique within the routing >> domain satisfies the less stringent uniqueness requirements of local >> uniqueness, while also enabling protocols which have the most >> stringent requirements of uniqueness within the routing domain. As >> a result, many current deployments have chosen to employ the following >> simplifying principle: >> >> o an IP address assigned to an interface that connects to a link >> with undetermined connectivity properties should be unique, at >> least within the routing domain. >> >> And in Section 6.1: >> >> OLD: >> o There is no mechanism to ensure that IPv6 link-local addresses are >> unique across multiple links, hence they cannot be used to >> reliably identify routers (it is often desirable to identify a >> router with an IP address). >> NEW: >> o There is no mechanism to ensure that IPv6 link-local addresses are >> unique across multiple links, hence they cannot be used to >> reliably identify routers, should this be necessary in the chosen >> routing protocol. >> >> OLD: >> Therefore, autoconfiguration solutions should be encouraged to >> primarily focus on configuring IP addresses that are not IPv6 link- >> local. >> NEW: >> Therefore, a common theme in many autoconfiguration solutions is to >> focus on configuring IP addresses that are not IPv6 link- >> local. >> >> _______________________________________________ >> 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 zach@sensinode.com Fri Jul 9 00:58:30 2010 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 363653A6B96 for ; Fri, 9 Jul 2010 00:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.271 X-Spam-Level: X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=0.328, 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 r0RrE7hDvow4 for ; Fri, 9 Jul 2010 00:58:28 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 432083A67D3 for ; Fri, 9 Jul 2010 00:58:28 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o697wRIv029546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 Jul 2010 10:58:27 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4C360AAE.9090103@earthlink.net> Date: Fri, 9 Jul 2010 10:58:29 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <4C2A6BB7.1000900@piuha.net> <4C360AAE.9090103@earthlink.net> To: "Charles E. Perkins" X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 09 Jul 2010 07:58:30 -0000 +1 On Jul 8, 2010, at 8:28 PM, Charles E. Perkins wrote: > > Hello Jari, > > I support the publication of RFC 5889 with the inclusion of > the revisions as you and Erik have suggested below. > > Regarding the last edit, I am also O.K. with that, but > with the understanding that link-local solutions are > neither favored or disfavored per se. Wide applicability > and performance issues (for example) are (to me at least) > much more important. > > Regards, > Charlie P. > > > On 6/29/2010 2:55 PM, Jari Arkko wrote: >> Christopher, >> >>> Incidentally the charter refers to RFC 5889, which is not yet published. >>> I see that is in AUTH48, but noted as on hold for a technical issue. >>> AUTH48 seems rather late for a technical issue, unless meaning a >>> publication technical issue rather than an engineering technical issue. >> >> Yes it is late. We approved the document but after approval there was a >> comment on the IETF last call thread from Erik Nordmark. We are trying >> to resolve it but unfortunately it took a long time for me to do so. But >> we are now trying to do it. The standing proposal is below, comments >> appreciated. >> >> Jari >> >> ----- >> >> We talked about this during Anaheim but never got to the end of it. >> Sorry -- I should have posted a suggestion back then but other business >> has kept me busy. I have now looked at the discussion again. >> >> The essence of Erik's complaint was twofold. First, the document claimed >> that routing protocols require a unique IP address (and not just a >> router ID), which is not true. Second, that the document unnecessarily >> dismisses link local identifiers as addresses. >> >> About the first issue: Erik is right that not all routing protocols >> require unique IP addresses at all. But at the same time, apparently >> some routing protocols in the MANET space do require it (e.g., OSLR in >> RFC 3626). In a way, the document is factually correct on this point as >> it states that some protocols do have these requirements. But it may >> also be misleading from another perspective, as we certainly do not want >> to claim that using unique IP addresses is a recommended design for a >> routing protocol or the only possible model. >> >> The second issue is partially related to the first one, as one of the >> reasons for using non-link-local addresses is to enable the use of >> unique addresses in routing protocols. In any case, the intent was never >> to claim that link local addresses cannot be used. The document merely >> makes one recommendation about a commonly used addressing model in adhoc >> networks. I would like to defend the working group's right to publish >> such an "example model" -- particularly after years of effort spent in >> trying to find the true universal model. As long as the working group is >> not making false claims, this is clearly appropriate. But I can see that >> the document could be clearer about its claims. >> >> Here's a possible rewrite of Section 5 to address these issues: >> >> OLD: >> Routing protocols running on a router may exhibit different >> requirements for uniqueness of interface addresses; some have no such >> requirements, others have requirements ranging from local uniqueness >> only, to uniqueness within, at least, the routing domain (as defined >> in [RFC1136]). >> >> Configuring an IP address that is unique within the routing domain >> satisfies the less stringent uniqueness requirements of local >> uniqueness, while also enabling protocols which have the most >> stringent requirements of uniqueness within the routing domain. This >> suggests the following principle: >> >> o an IP address assigned to an interface that connects to a link >> with undetermined connectivity properties should be unique, at >> least within the routing domain. >> NEW: >> Routing protocols running on a router may exhibit different >> requirements for uniqueness of interface addresses; some have no such >> requirements, others have requirements ranging from local uniqueness >> only, to uniqueness within, at least, the routing domain (as defined >> in [RFC1136]). Many modern routing protocols do not need to employ >> unique addresses at all, and theoretically, their only requirement is that >> some router identifier is unique. >> >> Nevertheless, configuring an IP address that is unique within the routing >> domain satisfies the less stringent uniqueness requirements of local >> uniqueness, while also enabling protocols which have the most >> stringent requirements of uniqueness within the routing domain. As >> a result, many current deployments have chosen to employ the following >> simplifying principle: >> >> o an IP address assigned to an interface that connects to a link >> with undetermined connectivity properties should be unique, at >> least within the routing domain. >> >> And in Section 6.1: >> >> OLD: >> o There is no mechanism to ensure that IPv6 link-local addresses are >> unique across multiple links, hence they cannot be used to >> reliably identify routers (it is often desirable to identify a >> router with an IP address). >> NEW: >> o There is no mechanism to ensure that IPv6 link-local addresses are >> unique across multiple links, hence they cannot be used to >> reliably identify routers, should this be necessary in the chosen >> routing protocol. >> >> OLD: >> Therefore, autoconfiguration solutions should be encouraged to >> primarily focus on configuring IP addresses that are not IPv6 link- >> local. >> NEW: >> Therefore, a common theme in many autoconfiguration solutions is to >> focus on configuring IP addresses that are not IPv6 link- >> local. >> >> _______________________________________________ >> 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 -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From hrogge@googlemail.com Fri Jul 9 07:15:48 2010 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 A5F6D3A69FC for ; Fri, 9 Jul 2010 07:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 4HU8qSe1XebZ for ; Fri, 9 Jul 2010 07:15:47 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 42EB23A69E6 for ; Fri, 9 Jul 2010 07:15:47 -0700 (PDT) Received: by wwb24 with SMTP id 24so4128656wwb.13 for ; Fri, 09 Jul 2010 07:15:48 -0700 (PDT) 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=8BKe4uHHsKE6NCGNGvHb2DfUDSu9DgYE4HovarKC5eM=; b=PMpB2B79RnmHK74VFF+uJGK4K9nUbSBDEB3LoqvVaWDEtInbsm//GwiIwj4ZdwvHZJ df7q4Vizx6lYzG85bqiJR/Y1ul1lnxPzRdEaKXxPRTR9wCnmQOAat4mfhIc4vH8zvlFb YayktSEgJDas7dAv2citfiTm/gc7Gt6YWdgy8= 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=oWenFuNZjaYunY9zKKgUoyILdNnvrUBCwwmPFd+utAk21TMYWiWjXEl7ciaIZ6m/fP M5iESbaiB3J7kE4PEiIuccSdc78LQHh9ZP9fRXNLox+41MgpeQY+2ONh9/eUczj96D3n tNzVLR+7Q9p1BjwYK1LqObXSGLrOVURtJk9W0= Received: by 10.216.187.143 with SMTP id y15mr1868314wem.74.1278684948417; Fri, 09 Jul 2010 07:15:48 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id o11sm36717wej.45.2010.07.09.07.15.47 (version=SSLv3 cipher=RC4-MD5); Fri, 09 Jul 2010 07:15:47 -0700 (PDT) From: Henning Rogge To: autoconf@ietf.org Date: Fri, 9 Jul 2010 16:15:32 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.34-gentoo-r1; KDE/4.4.5; x86_64; ; ) References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> In-Reply-To: <4C2CFADD.3040909@piuha.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9405069.46BtVVvVxT"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201007091615.39159.hrogge@googlemail.com> Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 09 Jul 2010 14:15:48 -0000 --nextPart9405069.46BtVVvVxT Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Am Donnerstag 01 Juli 2010, 22:30:21 schrieb Jari Arkko: > OLD: > Routing protocols running on a router may exhibit different > requirements for uniqueness of interface addresses; some have no such > requirements, others have requirements ranging from local uniqueness > only, to uniqueness within, at least, the routing domain (as defined > in [RFC1136]). >=20 > Configuring an IP address that is unique within the routing domain > satisfies the less stringent uniqueness requirements of local > uniqueness, while also enabling protocols which have the most > stringent requirements of uniqueness within the routing domain. This > suggests the following principle: >=20 > o an IP address assigned to an interface that connects to a link > with undetermined connectivity properties should be unique, at > least within the routing domain. > NEW: > Routing protocols running on a router may exhibit different > requirements for uniqueness of interface addresses; some have no such > requirements, others have requirements ranging from local uniqueness > only, to uniqueness within, at least, the routing domain (as defined > in [RFC1136]). Routing protocols that do not require unique IP > addresses within the > routing domain utilize a separate unique identifier within the routing > protocol itself that must also be configured in some manner. >=20 > Nevertheless, configuring an IP address that is unique within the routi= ng > domain satisfies the less stringent uniqueness requirements of local > uniqueness, while also enabling protocols which have the most > stringent requirements of uniqueness within the routing domain. > As a result, the following principle allows for IP autoconfiguration to > apply to the widest array of routing protocols: >=20 > o an IP address assigned to an interface that connects to a link > with undetermined connectivity properties should be unique, at > least within the routing domain. ACK to this section. > And in Section 6.1: >=20 > OLD: > o There is no mechanism to ensure that IPv6 link-local addresses are > unique across multiple links, hence they cannot be used to > reliably identify routers (it is often desirable to identify a > router with an IP address). > NEW: > o There is no mechanism to ensure that IPv6 link-local addresses are > unique across multiple links, hence they cannot be used to > reliably identify routers, should this be necessary by the routing > protocol for which IP address autoconfiguration is being provided. I think this is still too strong. "There is no mechanism to ensure..." does sound as there never will be one.= If=20 we cannot find a mechanism/protocol to do this, we cannot find one that=20 creates routing unique adresses (because the later would do the former too). I think it should start with something like this: "The default mechanisms of IPv6 cannot ensure that..." (instead of "There is no mechanism to ensure that...") > OLD: > Therefore, autoconfiguration solutions should be encouraged to > primarily focus on configuring IP addresses that are not IPv6 link- > local. > NEW: > Therefore, an autoconfiguration solution which provides a mechanism for > assigning addresses with a wider scope than IPv6 link-local alone will > be more generally useful than one that does not. ACK to this. Any autoconfiguration sollution that solves the "routing unique" case can=20 easily be adapted to solve the "linklocal" one. Henning Rogge =2D-=20 1) You can't win. 2) You can't break even. 3) You can't leave the game. =E2=80=94 The Laws of Thermodynamics, summarized --nextPart9405069.46BtVVvVxT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEABECAAYFAkw3LwsACgkQcenvcwAcHWcwJQCfTNPi8tiA+Q0Msy39WvB+I3Oh 5F8AnA6WrKGLhPCWNZKC1V/76TYPxBs+ =+xZz -----END PGP SIGNATURE----- --nextPart9405069.46BtVVvVxT-- From teco@inf-net.nl Fri Jul 9 09:12:51 2010 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 3BA7C3A6995 for ; Fri, 9 Jul 2010 09:12:51 -0700 (PDT) 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 upMvwm+5JV7X for ; Fri, 9 Jul 2010 09:12:49 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 424B83A6A66 for ; Fri, 9 Jul 2010 09:12:47 -0700 (PDT) Received: by eyb7 with SMTP id 7so398415eyb.31 for ; Fri, 09 Jul 2010 09:12:48 -0700 (PDT) Received: by 10.213.33.73 with SMTP id g9mr1595473ebd.46.1278691967803; Fri, 09 Jul 2010 09:12:47 -0700 (PDT) Received: from [192.168.2.168] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id x54sm8711124eeh.17.2010.07.09.09.12.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Jul 2010 09:12:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <201007091615.39159.hrogge@googlemail.com> Date: Fri, 9 Jul 2010 18:12:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <201007091615.39159.hrogge@googlemail.com> To: Henning Rogge X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 09 Jul 2010 16:12:51 -0000 Op 9 jul 2010, om 16:15 heeft Henning Rogge het volgende geschreven: >=20 >> And in Section 6.1: >>=20 >> OLD: >> o There is no mechanism to ensure that IPv6 link-local addresses = are >> unique across multiple links, hence they cannot be used to >> reliably identify routers (it is often desirable to identify a >> router with an IP address). >> NEW: >> o There is no mechanism to ensure that IPv6 link-local addresses = are >> unique across multiple links, hence they cannot be used to >> reliably identify routers, should this be necessary by the = routing >> protocol for which IP address autoconfiguration is being = provided. >=20 > I think this is still too strong. > "There is no mechanism to ensure..." does sound as there never will be = one. If=20 > we cannot find a mechanism/protocol to do this, we cannot find one = that=20 > creates routing unique adresses (because the later would do the former = too). >=20 > I think it should start with something like this: > "The default mechanisms of IPv6 cannot ensure that..." > (instead of "There is no mechanism to ensure that...") Although I think the document should not kept waiting, I don't agree on = this. There is no mechanism to detect duplicate globals on different links. The ND DAD mechanism does not work in a MANET for LL, and _also_ not for = globals !! A mechanism that ensures unique Interface-IDs ensures unique LLs. We all agreed on that we shall not work on a new protocol for = autoconfiguring LLs. It is globals and MANET-locals (ULAs) that we are looking for. That is in the document, in old and new text. I would use unique LLs as router-IDs. I don't get what is wrong with = this, as long as LLs are unique. But LLs MUST NOT be used for multi-hop forwarded traffic. Teco. From hrogge@googlemail.com Fri Jul 9 09:46:27 2010 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 0FF393A6A91 for ; Fri, 9 Jul 2010 09:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 8CaD263fpQDW for ; Fri, 9 Jul 2010 09:46:26 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 9B0813A6946 for ; Fri, 9 Jul 2010 09:46:25 -0700 (PDT) Received: by wyb40 with SMTP id 40so1822814wyb.31 for ; Fri, 09 Jul 2010 09:46:27 -0700 (PDT) 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=McgXuaENcdyxFzgG25U1TfZULt+wscdvRPFtG4cMvqg=; b=gxzGRUEZxDLV2arq5ZLdS7bPdM0TQrJPHqXjI/+U5KyfqBukSCgMMG7Ghb+iJ1DCQY RDOOSzXfW4CzsTIsD0iBszwc5p7pQa9zdXJQHSb6Z+vYja6CGS4jM7eNL0p5vykymVp4 CkV5LtIhpUfxWgFLPumSnHOHxG1cwzzcxY+n4= 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=YBVPrPO1z2wvhEOqI1tKO4yAJvmwWmr6pqaPfXCdu5Fbu4MOJ9fZ/+3wJ0jVAoZik6 TH4TQUtLpxUvpHFqH9FKAl81RZkxsaDfxugkNG3oMBTEoT9lIRDGhFjFsuDtIeZaK4GT eqNjgjAliQTATJwdq1jTudFGM8H5+ShkGqHik= Received: by 10.227.7.212 with SMTP id e20mr1496808wbe.44.1278693987616; Fri, 09 Jul 2010 09:46:27 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id o54sm127197wej.29.2010.07.09.09.46.25 (version=SSLv3 cipher=RC4-MD5); Fri, 09 Jul 2010 09:46:25 -0700 (PDT) From: Henning Rogge To: Teco Boot Date: Fri, 9 Jul 2010 18:46:19 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.34-gentoo-r1; KDE/4.4.5; x86_64; ; ) References: <4C2A6BB7.1000900@piuha.net> <201007091615.39159.hrogge@googlemail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1386841.9Fnfz0l2Gv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201007091846.24282.hrogge@googlemail.com> Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 09 Jul 2010 16:46:27 -0000 --nextPart1386841.9Fnfz0l2Gv Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Am Freitag 09 Juli 2010, 18:12:45 schrieb Teco Boot: > > I think this is still too strong. > > "There is no mechanism to ensure..." does sound as there never will be > > one. If we cannot find a mechanism/protocol to do this, we cannot find > > one that creates routing unique adresses (because the later would do the > > former too). > >=20 > > I think it should start with something like this: > > "The default mechanisms of IPv6 cannot ensure that..." > > (instead of "There is no mechanism to ensure that...") >=20 > Although I think the document should not kept waiting, I don't agree on > this. There is no mechanism to detect duplicate globals on different > links. The ND DAD mechanism does not work in a MANET for LL, and _also_ > not for globals !! A mechanism that ensures unique Interface-IDs ensures > unique LLs. >=20 > We all agreed on that we shall not work on a new protocol for > autoconfiguring LLs. It is globals and MANET-locals (ULAs) that we are > looking for. > That is in the document, in old and new text. Yes... I just said that an autoconfiguration protocol that solves the=20 configuration problem for global unique IPs or ULAs would be trivial to ada= pt=20 for generating "link local" IPs, just by putting the LL-prefix to the=20 generated ULAs. =20 > I would use unique LLs as router-IDs. I don't get what is wrong with this, > as long as LLs are unique. There is nothing wrong with this. This strategy will solve the LL-generatio= n. Which instantly contradicts the statement "there is no mechanism to ensure.= =2E."=20 part. > But LLs MUST NOT be used for multi-hop forwarded traffic. No problem with this one. Henning Rogge =2D-=20 1) You can't win. 2) You can't break even. 3) You can't leave the game. =E2=80=94 The Laws of Thermodynamics, summarized --nextPart1386841.9Fnfz0l2Gv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEABECAAYFAkw3UmAACgkQcenvcwAcHWevGgCeIXxHbd180sNdnCms0ztaWz0T yuwAn28KBagB3MJ/il7A4I2zOnYuFw8n =AmWJ -----END PGP SIGNATURE----- --nextPart1386841.9Fnfz0l2Gv-- From erik.nordmark@oracle.com Fri Jul 9 13:53:12 2010 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 729903A68C1 for ; Fri, 9 Jul 2010 13:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 g6HdD0R35f8F for ; Fri, 9 Jul 2010 13:53:11 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 0A5A83A67EE for ; Fri, 9 Jul 2010 13:53:10 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o69KrEFO025711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Jul 2010 20:53:15 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o69EKl1q023737; Fri, 9 Jul 2010 20:53:13 GMT Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 414060291278708779; Fri, 09 Jul 2010 13:52:59 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Jul 2010 13:52:58 -0700 Message-ID: <4C378C29.2040302@oracle.com> Date: Fri, 09 Jul 2010 13:52:57 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.10) Gecko/20100621 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Jari Arkko References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> In-Reply-To: <4C2CFADD.3040909@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4C378C3A.006F:SCFMA4539814,ss=1,fgs=0 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 09 Jul 2010 20:53:12 -0000 On 07/ 1/10 01:30 PM, Jari Arkko wrote: > We have not had a substantial discussion of the proposal yet with Erik > -- he has acknowledged that he's seen the proposal but has been too busy > at day job to do a detailed review. He has promised to provide feedback > in the next few days. In the meantime I wanted to bring the issue up > with the working group so that you know what is going on. Ultimately, it > is your call to make changes. No single person's opinion can change the > document at this stage, be it Erik, the ADs, or the authors. That being > said, we do try to fix problems if there are some. > > In this particular issue, I personally believe that despite's Erik's > concern the document as approved was factually correct. However, at the > same time I think that the document could have been clearer about what > it is saying about routing protocols and what it is not. That was the > basis of my suggested edit. I think this edit, if agreed, is somewhere > between an editorial and technical change and something that can be done > in AUTH48 with the working group's acceptance. In other words, it is not > necessary to redo the approval process. I do think the document is misleading and confused. That starts with the discrepancy between the title IP Addressing Model in Ad Hoc Networks and the abstract, which limits itself to configuring IP addresses for router interfaces and not for the whole of an ad hoc network. I was under the impression that the WG was looking at a document that addressed the scope that is implied by the title. I find the more limited scope odd, since we existing routing protocols like IS-IS that can operate (exchange routing information, forward IP packets) without any IP addresses configured on the routers' interfaces. (Even though a router needs some IP addresses to be manageable with SNMP and to be able to send ICMP errors.) The implied conclusion that IPv6-link local addresses are undesirable for router's interfaces is even odder, since RIPng and OSPFv3 both require routers to use IPv6 link-local addresses for the routing protocol exchanges. The document seems to assume that the uniqueness scope of link-local addresses is limited to a single link, when it is the routability scope which is limited to the link. There is a class of link-local addresses with U=1 (those derived from EUI-64) that are globally unique - but still is not routable outside of the link. The result is that the document can easily be construed as discouraging approaches that make a lot of sense, which seems counterproductive. An example of such an approach is a routing protocol which uses IEEE MAC addresses as router ids, assigns IPv6 link-local addresses to the router's interfaces and uses that in the routing protocol exchanges, and configures global addresses for use by applications. I think the exercise here is to try to correct some minor wording in the recommendations in the document, but even if we succeed in doing so the premises expressed in the introduction and elsewhere will be a bit odd, since they focus on the configuration of router interfaces and not on the addressing model of the Ad Hoc network. > OLD: > Routing protocols running on a router may exhibit different > requirements for uniqueness of interface addresses; some have no such > requirements, others have requirements ranging from local uniqueness > only, to uniqueness within, at least, the routing domain (as defined > in [RFC1136]). > > Configuring an IP address that is unique within the routing domain > satisfies the less stringent uniqueness requirements of local > uniqueness, while also enabling protocols which have the most > stringent requirements of uniqueness within the routing domain. This > suggests the following principle: > > o an IP address assigned to an interface that connects to a link > with undetermined connectivity properties should be unique, at > least within the routing domain. > NEW: > Routing protocols running on a router may exhibit different > requirements for uniqueness of interface addresses; some have no such > requirements, others have requirements ranging from local uniqueness > only, to uniqueness within, at least, the routing domain (as defined > in [RFC1136]). Routing protocols that do not require unique IP addresses > within the > routing domain utilize a separate unique identifier within the routing > protocol itself that must also be configured in some manner. With IS-IS one doesn't configure the router id; it is a factory assigned MAC address. Such an approach is perfectly valid for Ad Hoc routing protocols as well. Note that a router (as opposed to routing protocol) require IP addresses to be managable and to be able to send ICMP errors. But the above paragraph is trying to derive recommendations from the latter. I suggest the wording Routing protocols that do not require unique IP addresses within the routing domain utilize a separate unique identifier within the routing protocol itself; such identifiers could be based on factory assignment or configuration. > Nevertheless, configuring an IP address that is unique within the routing > domain satisfies the less stringent uniqueness requirements of local > uniqueness, while also enabling protocols which have the most > stringent requirements of uniqueness within the routing domain. As a > result, the following principle allows for IP autoconfiguration to > apply to the widest array of routing protocols: > > o an IP address assigned to an interface that connects to a link > with undetermined connectivity properties should be unique, at > least within the routing domain. > > And in Section 6.1: > > OLD: > o There is no mechanism to ensure that IPv6 link-local addresses are > unique across multiple links, hence they cannot be used to > reliably identify routers (it is often desirable to identify a > router with an IP address). > NEW: > o There is no mechanism to ensure that IPv6 link-local addresses are > unique across multiple links, hence they cannot be used to > reliably identify routers, should this be necessary by the routing > protocol for which IP address autoconfiguration is being provided. According to RFC 4291 EUI-64-based interface identifiers have global scope when created from a universal token. A result of this is that link-local addresses formed from such interface identifiers have global scope. Hence the "no mechanism" above seems factually incorrect. Thus I think section 6.1 needs to differentiate between the global and local scope for the interface identifiers for it to make sense. Should I suggest replacement text? This paragraph seems like a non seqiteur: o Routers cannot forward any packets with link-local source or destination addresses to other links (as per [RFC4291]) while most of the time, routers need to be able to forward packets to/from different links. Clearly the application traffic needs to use non-link-local addresses to work across multiple links, but that has nothing to do with what IP addresses are configured on the interfaces of routers as we see from the requirement for RIPng and OSPFv3 to use IPv6 link-locals on router interfaces. Instead the issue is that link-local addresses are not useful for applications *other than routing protocols*, and that is the motivation for the subsequent paragraph: > OLD: > Therefore, autoconfiguration solutions should be encouraged to > primarily focus on configuring IP addresses that are not IPv6 link- > local. > NEW: > Therefore, an autoconfiguration solution which provides a mechanism for > assigning addresses with a wider scope than IPv6 link-local alone will > be more generally useful than one that does not. That misses the point. It is the motivation for this recommendation which is confused and misleading, and not the conclusion itself. The motivation is that applications (other than routing protocols) most likely desire to communicate across the whole Ad Hoc network, if not across the whole Internet, which makes link-local addresses of limited use. But they can still be quite useful as for the purposes of routing protocols, and bootstrapping address autoconfiguration protocols. This confusion is related to the odd scope mismatch between the title and the abstract. Clearly we want to be able to autoconfigure non-link-local addresses for applications, but the abstract limits the scope of the document to IP addressed assigned to router interfaces, and there link-local address might be just fine. Note that the last sentence in the first paragraph in section 4 is also misleading (I'm assuming that paragraph is about configuring router interfaces and not host interfaces) in saying Note that while link-local addresses are assumed to be "on link", the utility of link-local addresses is limited as described in Section 6. when in fact using link-local address, in particular those based on global scope interface identifiers, might be just fine for router interfaces. Erik From Matthew.Anderson@us.elster.com Sat Jul 10 12:17:26 2010 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 748AF3A6838 for ; Sat, 10 Jul 2010 12:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 V47hsAdlWMQ7 for ; Sat, 10 Jul 2010 12:17:25 -0700 (PDT) Received: from mail136.messagelabs.com (mail136.messagelabs.com [216.82.249.3]) by core3.amsl.com (Postfix) with SMTP id A35303A6845 for ; Sat, 10 Jul 2010 12:17:25 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Matthew.Anderson@us.elster.com X-Msg-Ref: server-8.tower-136.messagelabs.com!1278789451!48890513!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 12942 invoked from network); 10 Jul 2010 19:17:31 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-8.tower-136.messagelabs.com with SMTP; 10 Jul 2010 19:17:31 -0000 Auto-Submitted: auto-generated From: Matthew.Anderson@us.elster.com To: autoconf@ietf.org Message-ID: Date: Sat, 10 Jul 2010 15:13:42 -0400 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.1|September 28, 2009) at 07/10/2010 03:12:47 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Autoconf] AUTO: Matthew Anderson is out of the office (returning 07/19/2010) 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, 10 Jul 2010 19:17:26 -0000 I am out of the office until 07/19/2010. I am out of the office on vacation. Any critical matters related to the EARG project should be sent to Gerald Paprocki. Also - please make sure you have the correct Matt Anderson on this email if you are surprised by this out of office. Note: This is an automated response to your message "Autoconf Digest, Vol 52, Issue 10" sent on 7/10/2010 3:00:03 PM. This is the only notification you will receive while this person is away. From zach@sensinode.com Mon Jul 12 04:30:31 2010 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 BCE6A3A6886 for ; Mon, 12 Jul 2010 04:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.292 X-Spam-Level: X-Spam-Status: No, score=-3.292 tagged_above=-999 required=5 tests=[AWL=0.307, 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 M6dIOJoSRRoY for ; Mon, 12 Jul 2010 04:30:29 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id E55083A690C for ; Mon, 12 Jul 2010 04:30:27 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o6CBUVYm014529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Jul 2010 14:30:31 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4C378C29.2040302@oracle.com> Date: Mon, 12 Jul 2010 14:30:33 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 12 Jul 2010 11:30:31 -0000 On Jul 9, 2010, at 11:52 PM, Erik Nordmark wrote: > IP Addressing Model in Ad Hoc Networks Erik is right that the title and content don't match. So why not update = the name slightly: "Router Addressing Model in Ad Hoc Networks" Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From alexandru.petrescu@gmail.com Mon Jul 19 00:52:50 2010 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 AAF5B3A68BD for ; Mon, 19 Jul 2010 00:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.134 X-Spam-Level: X-Spam-Status: No, score=-1.134 tagged_above=-999 required=5 tests=[AWL=1.115, 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 2SP7SKop6H47 for ; Mon, 19 Jul 2010 00:52:50 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id AE0B83A6846 for ; Mon, 19 Jul 2010 00:52:49 -0700 (PDT) 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 o6J7r2j4015902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Jul 2010 09:53:02 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6J7r2th010086 for ; Mon, 19 Jul 2010 09:53:02 +0200 (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 o6J7r2qp011163 for ; Mon, 19 Jul 2010 09:53:02 +0200 Message-ID: <4C44045E.4060305@gmail.com> Date: Mon, 19 Jul 2010 09:53:02 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "autoconf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Autoconf] any agenda? 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, 19 Jul 2010 07:52:50 -0000 Is there an agenda for the Maastricht meeting. Alex From ryuji.wakikawa@gmail.com Mon Jul 19 22:12:54 2010 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 AD8FB3A689E for ; Mon, 19 Jul 2010 22:12:54 -0700 (PDT) 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 ke0nJcylu+fz for ; Mon, 19 Jul 2010 22:12:53 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 3AEE53A69B3 for ; Mon, 19 Jul 2010 22:12:53 -0700 (PDT) Received: by pzk6 with SMTP id 6so2503130pzk.31 for ; Mon, 19 Jul 2010 22:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=jadDRfqW2c730MJVSYfAAh6LAaulMHBHBipjm1nadSQ=; b=bzrigC5XvMlFSGDHrXqCzzmLbW5y4BS7mPcAl7kLT0WHaYdffX2W2dgOr7R4nNtj7P 9cqBnEPa8lIZ1eoyHcwd3CPzE+ho+6zL/ff5d5aJzcfN1y1f6ZMTpxabYRM/BDCVNG3t ix9MuWMm0Za5sTQzNXRaUoIeC0SYTLi8vRcvc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=n3DbDxmoUqxUUvB+rBmGwViDCP56Xf9gQtD5bfJ+lxD4BJcC/3PKPHO+Ib76UNOE2y 498uclYVQ5NRkDEv/QVMdIbz9KF4CgX/zX/Ojyi4Cf/weQa9mlPmeUEbtc1xSkV7hjJF dvq8EjfAi9etmCs1T5Wen0XwBM8MqrcVeDZeU= Received: by 10.114.36.2 with SMTP id j2mr8688421waj.88.1279602787908; Mon, 19 Jul 2010 22:13:07 -0700 (PDT) Received: from [10.0.1.2] (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id d38sm82461770wam.8.2010.07.19.22.13.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 22:13:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ryuji Wakikawa In-Reply-To: <4C44045E.4060305@gmail.com> Date: Mon, 19 Jul 2010 22:13:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4F758DFA-6F4F-45FF-92C9-EC0DD7FF2288@gmail.com> References: <4C44045E.4060305@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] any agenda? 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, 20 Jul 2010 05:12:56 -0000 Thanks alex for reminder. We will upload the agenda shortly. sorry for = late action.=20 The agenda is mostly about recharting discussion. Plus a few = presentations. regards, ryuji On 2010/07/19, at 0:53, Alexandru Petrescu wrote: > Is there an agenda for the Maastricht meeting. >=20 > Alex >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From ryuji.wakikawa@gmail.com Mon Jul 19 22:57:09 2010 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 B455C3A682E for ; Mon, 19 Jul 2010 22:57:09 -0700 (PDT) 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 nhbgZ2HhU2IO for ; Mon, 19 Jul 2010 22:57:05 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 793B93A677C for ; Mon, 19 Jul 2010 22:56:59 -0700 (PDT) Received: by pzk6 with SMTP id 6so2516291pzk.31 for ; Mon, 19 Jul 2010 22:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=GsQl67zfcQ75tNtckvxYli0EFYNwcVqh3fB+vn/GT4A=; b=rirId3ErYfLPEGAgAQvdx2P/X0OEErWcZ+7w8P70K/S/rjNLxrpR4sBbsy28JFjc8f op8ekTcutiDB4aNi9k5LIbV+A4way24GQvo+iFKTi55DX9UV7TClr/7rP1TqiMptFbqx 7eW1YTTGrauJ0iOET0QyUAtzZEdZGavnd2cXs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=GVhncdJJZD0yXH1EHP3BxmzDunztKDR+PHrvWgS4IfPHyarOORZklGVkqas+f9TZGo tTh6PaQ9zXktjw5SvVUIO0NUJUdsHA1IsxhbCGXTB3fUX5seETUqQAPm9rlKEo3CmrDL egT8jq+UutBini9jP/EnkqjtFtAWFw8RDCjUI= Received: by 10.142.132.12 with SMTP id f12mr8116067wfd.73.1279605433678; Mon, 19 Jul 2010 22:57:13 -0700 (PDT) Received: from [10.0.1.2] (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id x18sm7347148wfd.20.2010.07.19.22.57.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 22:57:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ryuji Wakikawa In-Reply-To: <4C378C29.2040302@oracle.com> Date: Mon, 19 Jul 2010 22:57:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> To: Erik Nordmark X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 20 Jul 2010 05:57:09 -0000 Hi Erik, Thanks for comments. It will be nice to have your proposed texts. As you know, AUTOCONF WG has long discussion of Link-Local address = treatment.=20 Due to the special characteristics of ad-hoc links, the uniqueness of = link-local is hardly achieved. =20 The link characteristics of ad-hoc network is quite different from the = fixed link. = http://ietfreport.isoc.org/all-ids/draft-baccelli-multi-hop-wireless-commu= nication-04.txt I'm not quite sure how we can handle your comments, because some of = comments just reset our 5 yrs achievements.=20 I would like to see the comments from AUTOCONF members.=20 thanks, ryuji On 2010/07/09, at 13:52, Erik Nordmark wrote: > On 07/ 1/10 01:30 PM, Jari Arkko wrote: >=20 >> We have not had a substantial discussion of the proposal yet with = Erik >> -- he has acknowledged that he's seen the proposal but has been too = busy >> at day job to do a detailed review. He has promised to provide = feedback >> in the next few days. In the meantime I wanted to bring the issue up >> with the working group so that you know what is going on. Ultimately, = it >> is your call to make changes. No single person's opinion can change = the >> document at this stage, be it Erik, the ADs, or the authors. That = being >> said, we do try to fix problems if there are some. >>=20 >> In this particular issue, I personally believe that despite's Erik's >> concern the document as approved was factually correct. However, at = the >> same time I think that the document could have been clearer about = what >> it is saying about routing protocols and what it is not. That was the >> basis of my suggested edit. I think this edit, if agreed, is = somewhere >> between an editorial and technical change and something that can be = done >> in AUTH48 with the working group's acceptance. In other words, it is = not >> necessary to redo the approval process. >=20 > I do think the document is misleading and confused. > That starts with the discrepancy between the title > IP Addressing Model in Ad Hoc Networks > and the abstract, which limits itself to configuring IP addresses for = router interfaces and not for the whole of an ad hoc network. >=20 > I was under the impression that the WG was looking at a document that = addressed the scope that is implied by the title. >=20 > I find the more limited scope odd, since we existing routing protocols = like IS-IS that can operate (exchange routing information, forward IP = packets) without any IP addresses configured on the routers' interfaces. = (Even though a router needs some IP addresses to be manageable with SNMP = and to be able to send ICMP errors.) >=20 > The implied conclusion that IPv6-link local addresses are undesirable = for router's interfaces is even odder, since RIPng and OSPFv3 both = require routers to use IPv6 link-local addresses for the routing = protocol exchanges. >=20 > The document seems to assume that the uniqueness scope of link-local = addresses is limited to a single link, when it is the routability scope = which is limited to the link. There is a class of link-local addresses = with U=3D1 (those derived from EUI-64) that are globally unique - but = still is not routable outside of the link. >=20 > The result is that the document can easily be construed as = discouraging approaches that make a lot of sense, which seems = counterproductive. > An example of such an approach is a routing protocol which uses IEEE = MAC addresses as router ids, assigns IPv6 link-local addresses to the = router's interfaces and uses that in the routing protocol exchanges, and = configures global addresses for use by applications. >=20 >=20 > I think the exercise here is to try to correct some minor wording in = the recommendations in the document, but even if we succeed in doing so = the premises expressed in the introduction and elsewhere will be a bit = odd, since they focus on the configuration of router interfaces and not = on the addressing model of the Ad Hoc network. >=20 >> OLD: >> Routing protocols running on a router may exhibit different >> requirements for uniqueness of interface addresses; some have no such >> requirements, others have requirements ranging from local uniqueness >> only, to uniqueness within, at least, the routing domain (as defined >> in [RFC1136]). >>=20 >> Configuring an IP address that is unique within the routing domain >> satisfies the less stringent uniqueness requirements of local >> uniqueness, while also enabling protocols which have the most >> stringent requirements of uniqueness within the routing domain. This >> suggests the following principle: >>=20 >> o an IP address assigned to an interface that connects to a link >> with undetermined connectivity properties should be unique, at >> least within the routing domain. >> NEW: >> Routing protocols running on a router may exhibit different >> requirements for uniqueness of interface addresses; some have no such >> requirements, others have requirements ranging from local uniqueness >> only, to uniqueness within, at least, the routing domain (as defined >> in [RFC1136]). Routing protocols that do not require unique IP = addresses >> within the >> routing domain utilize a separate unique identifier within the = routing >> protocol itself that must also be configured in some manner. >=20 > With IS-IS one doesn't configure the router id; it is a factory = assigned MAC address. Such an approach is perfectly valid for Ad Hoc = routing protocols as well. >=20 > Note that a router (as opposed to routing protocol) require IP = addresses to be managable and to be able to send ICMP errors. But the = above paragraph is trying to derive recommendations from the latter. >=20 > I suggest the wording > Routing protocols that do not require unique IP addresses within the > routing domain utilize a separate unique identifier within the routing > protocol itself; such identifiers could be based on factory assignment = or configuration. >=20 >> Nevertheless, configuring an IP address that is unique within the = routing >> domain satisfies the less stringent uniqueness requirements of local >> uniqueness, while also enabling protocols which have the most >> stringent requirements of uniqueness within the routing domain. As a >> result, the following principle allows for IP autoconfiguration to >> apply to the widest array of routing protocols: >>=20 >> o an IP address assigned to an interface that connects to a link >> with undetermined connectivity properties should be unique, at >> least within the routing domain. >>=20 >> And in Section 6.1: >>=20 >> OLD: >> o There is no mechanism to ensure that IPv6 link-local addresses are >> unique across multiple links, hence they cannot be used to >> reliably identify routers (it is often desirable to identify a >> router with an IP address). >> NEW: >> o There is no mechanism to ensure that IPv6 link-local addresses are >> unique across multiple links, hence they cannot be used to >> reliably identify routers, should this be necessary by the routing >> protocol for which IP address autoconfiguration is being provided. >=20 > According to RFC 4291 EUI-64-based interface identifiers have global = scope when created from a universal token. A result of this is that = link-local addresses formed from such interface identifiers have global = scope. Hence the "no mechanism" above seems factually incorrect. >=20 > Thus I think section 6.1 needs to differentiate between the global and = local scope for the interface identifiers for it to make sense. > Should I suggest replacement text? >=20 > This paragraph seems like a non seqiteur: > o Routers cannot forward any packets with link-local source or > destination addresses to other links (as per [RFC4291]) while = most > of the time, routers need to be able to forward packets to/from > different links. > Clearly the application traffic needs to use non-link-local addresses = to work across multiple links, but that has nothing to do with what IP = addresses are configured on the interfaces of routers as we see from the = requirement for RIPng and OSPFv3 to use IPv6 link-locals on router = interfaces. >=20 > Instead the issue is that link-local addresses are not useful for = applications *other than routing protocols*, and that is the motivation = for the subsequent paragraph: >=20 >> OLD: >> Therefore, autoconfiguration solutions should be encouraged to >> primarily focus on configuring IP addresses that are not IPv6 link- >> local. >> NEW: >> Therefore, an autoconfiguration solution which provides a mechanism = for >> assigning addresses with a wider scope than IPv6 link-local alone = will >> be more generally useful than one that does not. >=20 > That misses the point. It is the motivation for this recommendation = which is confused and misleading, and not the conclusion itself. The = motivation is that applications (other than routing protocols) most = likely desire to communicate across the whole Ad Hoc network, if not = across the whole Internet, which makes link-local addresses of limited = use. >=20 > But they can still be quite useful as for the purposes of routing = protocols, and bootstrapping address autoconfiguration protocols. >=20 > This confusion is related to the odd scope mismatch between the title = and the abstract. Clearly we want to be able to autoconfigure = non-link-local addresses for applications, but the abstract limits the = scope of the document to IP addressed assigned to router interfaces, and = there link-local address might be just fine. >=20 > Note that the last sentence in the first paragraph in section 4 is = also misleading (I'm assuming that paragraph is about configuring router = interfaces and not host interfaces) in saying > Note that while link-local addresses are assumed to be "on link", = the > utility of link-local addresses is limited as described in Section = 6. > when in fact using link-local address, in particular those based on = global scope interface identifiers, might be just fine for router = interfaces. >=20 > Erik > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From ryuji.wakikawa@gmail.com Mon Jul 19 22:57:50 2010 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 02E563A6BD7 for ; Mon, 19 Jul 2010 22:57:50 -0700 (PDT) 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 vSAWmORe5Luc for ; Mon, 19 Jul 2010 22:57:44 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id C8C6F3A6BB4 for ; Mon, 19 Jul 2010 22:57:43 -0700 (PDT) Received: by pvd12 with SMTP id 12so2956225pvd.31 for ; Mon, 19 Jul 2010 22:57:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=cSYEkYx9TPraaDK31HAumpsHXpL5QNWfQMo3MfPyZFE=; b=SQVRSAWI+Rtvxt3AuT3ikW3hNVgCFz3/rvoODW8YYvkudClvcdTGUSN+uQGBgTTLjv P9c8yS9hmRhB3YaPqUBlyDB7MaPtN6UKywSUwd6y2QE272BJGu1MUW4Wx21Z866XtKSA m5UvHAupdeZGNECmCfhosQhIsK7yqw2lhy/uU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=fS/pGgYU0nH64E9WAT57t6rMTIdhhekUwHpJtmzzL7UUMFgCwM8ppPsEpGtS5UXwkY V6nJUhDuNm/LjljXdamoUtGToo8T93oaGf4Y9bMqyWMQT6ANMf9R+FlE3FNugmKttLwf H6/el3lXAqRqyRKxmsiOIbrBbeK5GlVP3Do6A= Received: by 10.142.225.8 with SMTP id x8mr8450901wfg.18.1279605478879; Mon, 19 Jul 2010 22:57:58 -0700 (PDT) Received: from [10.0.1.2] (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id x18sm7347148wfd.20.2010.07.19.22.57.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 22:57:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ryuji Wakikawa In-Reply-To: <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> Date: Mon, 19 Jul 2010 22:57:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 20 Jul 2010 05:57:50 -0000 I think if the title is misleading, we should update it. However, can we change the title at this document stage? Jari? ryuji On 2010/07/12, at 4:30, Zach Shelby wrote: >=20 > On Jul 9, 2010, at 11:52 PM, Erik Nordmark wrote: >=20 >> IP Addressing Model in Ad Hoc Networks >=20 >=20 > Erik is right that the title and content don't match. So why not = update the name slightly: >=20 > "Router Addressing Model in Ad Hoc Networks" >=20 > Zach >=20 > --=20 > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From ryuji.wakikawa@gmail.com Mon Jul 19 23:32:15 2010 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 360623A68CD for ; Mon, 19 Jul 2010 23:32:15 -0700 (PDT) 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 QkXj48R41EeC for ; Mon, 19 Jul 2010 23:32:13 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id D31673A694C for ; Mon, 19 Jul 2010 23:32:13 -0700 (PDT) Received: by pvd12 with SMTP id 12so2967982pvd.31 for ; Mon, 19 Jul 2010 23:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:date:cc:content-transfer-encoding:message-id:to :x-mailer; bh=SLWXBS8s/fTwoyT9vAL7Dvh5mdt6awRH7C2yX56FLFc=; b=cwuTFt3O7LEdrf3/NFA9Spv2EbDIcxTbtOhcW6R0iD2U5QKdPF7PyFtLDWTeTqt8IS giWg8/TGnqCf1V/vtNCQUG3aAm4TcTTITLYf3GAaI3tizbjZ+i2mZhzonMsg0TCHs7rx 1WTl3y4IUcENIkJDAwrqE++9j9DN3WdDHg3jM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:to:x-mailer; b=jv03zf8aA02kzbVOLp8zV0g7p4R/qbZV49JFfbDCWlRauT/A3DKOTncklmw3AGIH3C rPzGres46gxE0c0ikRy7JE8G8NRvwt9TrlslHayM/d0IsTxBiup+E24BUrrPTXDDAK7H /td2+5d2uo/Gb+w7vTMQTMb2SCPzwoA2QZY3U= Received: by 10.114.61.8 with SMTP id j8mr8788804waa.119.1279607548369; Mon, 19 Jul 2010 23:32:28 -0700 (PDT) Received: from [10.0.1.2] (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id k17sm563358rvf.7.2010.07.19.23.32.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 23:32:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Ryuji Wakikawa Date: Mon, 19 Jul 2010 23:32:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <88FBF3FE-D9BE-4085-B73D-DCA08BA454CF@gmail.com> To: "autoconf@ietf.org autoconf@ietf.org" X-Mailer: Apple Mail (2.1081) Cc: Thomas Clausen Subject: [Autoconf] Summary of re-chartering discussions. 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, 20 Jul 2010 06:32:15 -0000 Hi all, Thanks for all your comments. We have roughly following opinions.=20 - Centralized and/or De-centerized=20 - Existing protocols (DHCP and/or ND) vs. new autoconf protocols - SIngle or Multiple AUTOCONF protocol(s) - Security issue - Informational link characteristics document Chairs will prepare for the detailed summary by the Friday meeting in = Maastricht. We may ask some folks to present their opinion based on the comments we = received for the new charter proposal. Here is my general comment (more like impression) as one of co-chair. It's important to note that several folks agree on the Jari's proposed = milestone.=20 >1. Design space survey (Informational) >2. The simple solution (such as DHCP) (PS) >3. Limitations of the simple solution (Informational) >4. Recharter for work on the more general solution I do agree on the importance of non-centerized approach for MANET and = knew many past works exist for AUTOCONF (I had one proposal, too). =20 However, as a co-chair, we see high hurdles to get the new protocol(s) = out. First, we have to define requirements of such new autoconf protocol(s),=20= for example: router's address, Global prefix, centralized-, non-centerized scenarios, single and/or multiple centralized servers, security... =20 Considering fact that people aim at so many different manet scenarios,=20= how can we agree on those requirements? Second, how can we select (a) past proposed autoconf protocol(s) or inventing a new protocol.. We don't know yet whether there is "a protocol" supporting all the = requirements of=20 MANET scenarios. Maybe there is, but we need some investigation. I am afraid to say that It will require a few more years to define only=20= requirements, then protocol standardization for !? years. Don't you think we need some exercise with the simple solution first before tackling with these huge issues? =20 At the coming AUTOCONF charter, the simplest solution may be defined as just an experimental RFC. Then, we'll have the document of "limitations of the simple solution (informational)".=20 After having these documents, it's not too late to produce "an AUTOCONF protocol (PS)". Let's say if the Jari's proposed milestone takes 1- 1.5 years, we will have better strategy for "An AUTOCONF protocol (PS)" in those years. Some of folks may feel waste of time for the Jari's proposed charter, but i believe this is worth to pay for AUTOCONF activity. Anyway, let's continue rechartering discussion in Maastricht. thanks, ryuji From alexandru.petrescu@gmail.com Mon Jul 19 23:36:38 2010 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 5AA923A69E5 for ; Mon, 19 Jul 2010 23:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.692 X-Spam-Level: X-Spam-Status: No, score=-1.692 tagged_above=-999 required=5 tests=[AWL=0.557, 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 DgOR+-WItVNO for ; Mon, 19 Jul 2010 23:36:37 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 497853A6BE6 for ; Mon, 19 Jul 2010 23:36:24 -0700 (PDT) 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 o6K6aPRk015237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jul 2010 08:36:25 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6K6aP2u003378; Tue, 20 Jul 2010 08:36:25 +0200 (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 o6K6aMp5003482; Tue, 20 Jul 2010 08:36:25 +0200 Message-ID: <4C4543E7.3070900@gmail.com> Date: Tue, 20 Jul 2010 08:36:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Ryuji Wakikawa References: <4C44045E.4060305@gmail.com> <4F758DFA-6F4F-45FF-92C9-EC0DD7FF2288@gmail.com> In-Reply-To: <4F758DFA-6F4F-45FF-92C9-EC0DD7FF2288@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] any agenda? 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, 20 Jul 2010 06:36:38 -0000 Le 20/07/2010 07:13, Ryuji Wakikawa a écrit : > Thanks alex for reminder. We will upload the agenda shortly. sorry > for late action. The agenda is mostly about recharting discussion. > Plus a few presentations. Ryuji, I will present in MEXT draft-petrescu-autoconf-ra-based-routing-00.txt, MEXT Chairs approved my request. It is however not clear to me where the draft is more pertinent: MEXT or AUTOCONF? Depending on interest, I can present it in AUTOCONF too. Did you send a public request on this list about who'd like to present and what? Maybe I've missed it... Alex > > regards, ryuji > > On 2010/07/19, at 0:53, Alexandru Petrescu wrote: > >> Is there an agenda for the Maastricht meeting. >> >> Alex >> >> _______________________________________________ Autoconf mailing >> list Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From ryuji.wakikawa@gmail.com Mon Jul 19 23:49:38 2010 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 590523A69F0 for ; Mon, 19 Jul 2010 23:49:38 -0700 (PDT) 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 UdQdFO0k6CAg for ; Mon, 19 Jul 2010 23:49:34 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id C043D3A6922 for ; Mon, 19 Jul 2010 23:49:34 -0700 (PDT) Received: by pvd12 with SMTP id 12so2973930pvd.31 for ; Mon, 19 Jul 2010 23:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=3D26MzdXnPT6voZ+A59gzYciGtBbwiXpYy9ByS4/F/U=; b=UYSE1tX8+PZA2hdgUcU5rmjEfCNMbax2aFJZ8XHAFa6fZZrl9LEC36mwaDc4/XbwMF N/xTgxQVoQyBI3of9ArPZ39Dsb+Qs+6dpYhtDHaxsJCfvqwMtouytyCdI1jFIgZa/XYu uh1Rg6R9JzxPDDcurF4riM0ZdWy4UNzDVizNs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Wj0YGPsLB9JZzl/0n6HUhkYBGPcNdSAWUPiD8dz4xhbb9BouNMEfb8/bTuM0NfF8kd chT55P6UX/5MqX3Ys0NrQo8PeiZu5UpFrWXHOqqb8DOCNP/ReQ83jStRxDocoN5tXrCK 2OplQSsUTMJnCSwu1xqi/WeTviQWOieVix6j4= Received: by 10.142.193.19 with SMTP id q19mr8667769wff.317.1279608589695; Mon, 19 Jul 2010 23:49:49 -0700 (PDT) Received: from [10.0.1.2] (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id v38sm7391491wfh.12.2010.07.19.23.49.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 23:49:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Ryuji Wakikawa In-Reply-To: <4C4543E7.3070900@gmail.com> Date: Mon, 19 Jul 2010 23:49:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8EB265A4-CD7E-4E8F-9155-90FB24346087@gmail.com> References: <4C44045E.4060305@gmail.com> <4F758DFA-6F4F-45FF-92C9-EC0DD7FF2288@gmail.com> <4C4543E7.3070900@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] any agenda? 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, 20 Jul 2010 06:49:38 -0000 Hi Alex, Thanks for request.=20 We haven't asked the presentation at this time, since=20 we don't have our charter... If the charter discussion go well at the meeting, you may have your = slot;-) You'll prepare for the slide for MEXT anyway, let's see how the meeting = goes :-) regards, ryuji On 2010/07/19, at 23:36, Alexandru Petrescu wrote: > Le 20/07/2010 07:13, Ryuji Wakikawa a =E9crit : >> Thanks alex for reminder. We will upload the agenda shortly. sorry >> for late action. The agenda is mostly about recharting discussion. >> Plus a few presentations. >=20 > Ryuji, >=20 > I will present in MEXT = draft-petrescu-autoconf-ra-based-routing-00.txt, > MEXT Chairs approved my request. >=20 > It is however not clear to me where the draft is more pertinent: MEXT > or AUTOCONF? Depending on interest, I can present it in AUTOCONF too. >=20 > Did you send a public request on this list about who'd like to present > and what? Maybe I've missed it... >=20 > Alex >=20 >>=20 >> regards, ryuji >>=20 >> On 2010/07/19, at 0:53, Alexandru Petrescu wrote: >>=20 >>> Is there an agenda for the Maastricht meeting. >>>=20 >>> Alex >>>=20 >>> _______________________________________________ Autoconf mailing >>> list Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >>=20 >>=20 >=20 >=20 From jari.arkko@piuha.net Tue Jul 20 01:42:32 2010 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 93E733A69A4 for ; Tue, 20 Jul 2010 01:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.511, 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 yojTWlcrNXAQ for ; Tue, 20 Jul 2010 01:42:31 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id A26DF3A67A4 for ; Tue, 20 Jul 2010 01:42:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0418B2CECD; Tue, 20 Jul 2010 11:42:46 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUIv4ROCG0or; Tue, 20 Jul 2010 11:42:45 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 932712CC9A; Tue, 20 Jul 2010 11:42:44 +0300 (EEST) Message-ID: <4C456182.4090700@piuha.net> Date: Tue, 20 Jul 2010 10:42:42 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Ryuji Wakikawa References: <88FBF3FE-D9BE-4085-B73D-DCA08BA454CF@gmail.com> In-Reply-To: <88FBF3FE-D9BE-4085-B73D-DCA08BA454CF@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "autoconf@ietf.org autoconf@ietf.org" , Thomas Clausen Subject: Re: [Autoconf] Summary of re-chartering discussions. 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, 20 Jul 2010 08:42:32 -0000 Ryuji, all, For what it is worth -- and having followed the discussions -- I don't mind the working group picking up the distributed design work immediately in the new charter. However, I still want to see the specification of what current protocols (DHCP) can achieve unchanged. The description of the limitations of that solution is a natural step of developing the distributed solution, along with design space analysis and other steps that people have mentioned. Jari From ryuji.wakikawa@gmail.com Tue Jul 20 17:22:13 2010 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 382B73A697D for ; Tue, 20 Jul 2010 17:22:13 -0700 (PDT) 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 W7qlo92jvK0b for ; Tue, 20 Jul 2010 17:22:12 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 4B37C3A680B for ; Tue, 20 Jul 2010 17:22:12 -0700 (PDT) Received: by vws13 with SMTP id 13so1244485vws.31 for ; Tue, 20 Jul 2010 17:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=7xDLFXhzG447wW7Wr2Z7OKMZIzWhVdZiokYx3LePpZM=; b=bS8zrSyjo6/Umr+UrWJMuFilIM18orApps/c7usjjAgEkOSoN/UFTH6/KXOpeAtPtT Amsp2SiiVPJwTaV9a2oWZOIAIpaLUjoczUZ4LwNy/MGNERrZtVLr8ql74Bn3NlEEKG97 QEUkZePNJjZKjerPi/Gk7gtAXW04B/nM8oIjM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=tjogUWx3Ioa7QM/bS0najwfWFtSQ+eNjBZmFXmLfwqLXDjPsDWNJh2lPe/STlZBDNa vHL55mTSZlmIaPTV7jh4WV4nRaZliGkJF/GrEnWeH0iSurwYCNYNBV57myViL6qor4bN gkw2OlTtnBel4fKU/15bhxSEnlz33zZkfT+34= Received: by 10.224.11.129 with SMTP id t1mr1053496qat.59.1279671747806; Tue, 20 Jul 2010 17:22:27 -0700 (PDT) Received: from macbookpro-ryuji.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id m24sm28648157qck.5.2010.07.20.17.22.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 17:22:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ryuji Wakikawa In-Reply-To: <4C456182.4090700@piuha.net> Date: Tue, 20 Jul 2010 17:22:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <75DF3A67-95F7-4324-9F5E-385530EF1602@gmail.com> References: <88FBF3FE-D9BE-4085-B73D-DCA08BA454CF@gmail.com> <4C456182.4090700@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org autoconf@ietf.org" , Thomas Clausen Subject: Re: [Autoconf] Summary of re-chartering discussions. 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, 21 Jul 2010 00:22:13 -0000 Hi Jari, Thanks for clarification.=20 I agree with you to take a look at current solutions first. I expect that AUTOCONF WG can finish this work very quickly and move to = the real AUTOCONF work soon after that. regards, ryuji On 2010/07/20, at 1:42, Jari Arkko wrote: > Ryuji, all, >=20 > For what it is worth -- and having followed the discussions -- I don't = mind the working group picking up the distributed design work = immediately in the new charter. However, I still want to see the = specification of what current protocols (DHCP) can achieve unchanged. = The description of the limitations of that solution is a natural step of = developing the distributed solution, along with design space analysis = and other steps that people have mentioned. >=20 > Jari >=20 From emmanuel.baccelli@gmail.com Wed Jul 21 02:12:19 2010 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 603293A69FF for ; Wed, 21 Jul 2010 02:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 ZNa9dYf0HkTM for ; Wed, 21 Jul 2010 02:12:18 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 7DAF73A6A04 for ; Wed, 21 Jul 2010 02:12:17 -0700 (PDT) Received: by eyb7 with SMTP id 7so1835597eyb.31 for ; Wed, 21 Jul 2010 02:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=h7hprz5h+8uI/sAX6exEJNeionoySpT7mE7lrrGxzL4=; b=EacQrHYm0n9N6HNomq8CPoK3M6C7sM3SmInV/vNEOXZ9UXXVQgfHgFBj6Y3j3Xdmu2 sThHpuWLnOIhzvz5zjj9L3n6CpA66wS+di/WNOXnh4Z/ZfVWwquOfEfuMJ3MBkE68Fad Mxi7mGXnDEvypr/9eYkrJ9Pz540C2FXgv1IsY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=g5eWDUEiuNXI1rprEPX0l5c63B2rmeqn/k+woVUx8rn5TvDE8KCn80rpp+ODrHh9ta Q6Gn4VeilBxfQ1S6yoJ1p6qb+FFlxX5uIYODIBnfK0NhnH7kYUYbdCROFSDGg8dGbInH hjKBXfFAAfZU9NnVWw+VjkJxcVlh00h7Coe+8= Received: by 10.213.2.201 with SMTP id 9mr7449423ebk.35.1279703550216; Wed, 21 Jul 2010 02:12:30 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.14.119.143 with HTTP; Wed, 21 Jul 2010 02:12:10 -0700 (PDT) In-Reply-To: References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> From: Emmanuel Baccelli Date: Wed, 21 Jul 2010 11:12:10 +0200 X-Google-Sender-Auth: bt9DnYBlGRYUr_EzRRMuuBQj-Vw Message-ID: To: "autoconf@ietf.org" Content-Type: multipart/alternative; boundary=0015174c3f60874a50048be233d2 Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 21 Jul 2010 09:12:19 -0000 --0015174c3f60874a50048be233d2 Content-Type: text/plain; charset=ISO-8859-1 I'd be OK with the slight title alteration proposed by Zach: "Router Addressing Model in Ad Hoc Networks". I think it would be fine. Emmanuel On Tue, Jul 20, 2010 at 7:57 AM, Ryuji Wakikawa wrote: > I think if the title is misleading, we should update it. > However, can we change the title at this document stage? Jari? > > ryuji > > > On 2010/07/12, at 4:30, Zach Shelby wrote: > > > > > On Jul 9, 2010, at 11:52 PM, Erik Nordmark wrote: > > > >> IP Addressing Model in Ad Hoc Networks > > > > > > Erik is right that the title and content don't match. So why not update > the name slightly: > > > > "Router Addressing Model in Ad Hoc Networks" > > > > Zach > > > > -- > > Zach Shelby, Chief Nerd, Sensinode Ltd. > > http://zachshelby.org - My blog "On the Internet of Things" > > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > > Mobile: +358 40 7796297 > > > > _______________________________________________ > > 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 > --0015174c3f60874a50048be233d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd be OK with the slight title alteration proposed by Zach: "Router Addressing Model in Ad Hoc = Networks". I think it would be fine.=A0
Emmanuel


On Tue, Jul 20, 2010 = at 7:57 AM, Ryuji Wakikawa <ryuji.wakikawa@gmail.com> wrote:
I think if the title is misleading, we should update it.
However, can we change the title at this document stage? Jari?

ryuji


On 2010/07/12, at 4:30, Zach Shelby wrote:

>
> On Jul 9, 2010, at 11:52 PM, Erik Nordmark wrote:
>
>> IP Addressing Model in Ad Hoc Networks
>
>
> Erik is right that the title and content don't match. So why not u= pdate the name slightly:
>
> "Router Addressing Model in Ad Hoc Networks"
>
> Zach
>
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://zachshelby.= org =A0- My blog "On the Internet of Things"
> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297
>
> _______________________________________________
> 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

--0015174c3f60874a50048be233d2-- From emmanuel.baccelli@gmail.com Wed Jul 21 02:58:30 2010 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 1B44B3A6BAF for ; Wed, 21 Jul 2010 02:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 42FFN3ZMakq0 for ; Wed, 21 Jul 2010 02:58:27 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 11AC13A6B71 for ; Wed, 21 Jul 2010 02:58:26 -0700 (PDT) Received: by eyb7 with SMTP id 7so1847022eyb.31 for ; Wed, 21 Jul 2010 02:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=s+bPjTrWgZxFPNYSi/O+HonFVyFuAyVQJD/1+2cnjvU=; b=oLnFspsIrSGbgXIJA+Z9ienV9ZL3+LggTotxmFmkWmPrkVuUfEhpwbfTtWhIJ5+9zT BRHbC2BbdDfJ7IK9XN3J6GV8F1O+WTXOJrdAo98DX3Z+RV11NrJWGqgo+KxM27WsrI8E MIuXmqqGl/YvO5jeRa/bU4PhqzdVnqSkagOfM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=Eu9hOs8tViKqvuXTL+jeqGx+d/cbRgxXo5zDCyeZ1ZrapfRJGnRAQKex6xnX/13zzD 8LQ1pw1fSFpVKPmoEns3h/5ONmyE5IzmdWkFu//1J5kMigRPUipynwkeQVAawCezQN7Z 0Qlg+4KaDKKEiCwhoe22AysX4HZXOdNdzWSD4= Received: by 10.213.33.73 with SMTP id g9mr7704198ebd.46.1279706319327; Wed, 21 Jul 2010 02:58:39 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.14.119.143 with HTTP; Wed, 21 Jul 2010 02:58:19 -0700 (PDT) In-Reply-To: <4C378C29.2040302@oracle.com> References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> From: Emmanuel Baccelli Date: Wed, 21 Jul 2010 11:58:19 +0200 X-Google-Sender-Auth: WpupLW3NheDl_KFNyQLcMRggppo Message-ID: To: "autoconf@ietf.org" Content-Type: multipart/alternative; boundary=0015174c3c48949488048be2d8ab Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 21 Jul 2010 09:58:30 -0000 --0015174c3c48949488048be2d8ab Content-Type: text/plain; charset=ISO-8859-1 Hi Erik, On Fri, Jul 9, 2010 at 10:52 PM, Erik Nordmark wrote: > ... > > The result is that the document can easily be construed as discouraging > approaches that make a lot of sense, which seems counterproductive. > An example of such an approach is a routing protocol which uses IEEE MAC > addresses as router ids, assigns IPv6 link-local addresses to the router's > interfaces and uses that in the routing protocol exchanges, and configures > global addresses for use by applications. > > Using MAC addresses for unique identifier is considered dangerous by many people, as MAC addresses are not always unique. There were several cases where an order of several thousands of devices where shipped with the exact same MAC address, by mistake. Moreover, MAC addresses can be altered almost at will. This is why relying on MAC addresses for unique identifiers is not sufficient in my mind. It's merely another way to say: "let other people worry about our problems". This rarely works reliably. As to using link local addresses, there are many cases where it is not appropriate, as discussed over and over in this working group and elsewhere. If you have any comments on http://ietfreport.isoc.org/all-ids/draft-baccelli-multi-hop-wireless-communication-04.txt please let us know. The fundamental properties of multi-hop wireless communications described in that document make it difficult to use link-local addresses in many cases. And again, the goal of RFC5889 is not to describe all possible addressing models for each specific scenario, but rather to describe one specific model with which we have experience in multi-hop wireless contexts, and which has proven to work OK. In that respect, I think RFC5889 does the job. Regards, Emmanuel --0015174c3c48949488048be2d8ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Erik,


On Fri, Jul 9, 2010 at 10:5= 2 PM, Erik Nordmark <erik.nordmark@oracle.com> wrote:
...
=A0
The result is that the document can easily be construed as discouraging app= roaches that make a lot of sense, which seems counterproductive.
An example of such an approach is a routing protocol which uses IEEE MAC ad= dresses as router ids, assigns IPv6 link-local addresses to the router'= s interfaces and uses that in the routing protocol exchanges, and configure= s global addresses for use by applications.

=A0

Using MAC addresses for = unique identifier is considered dangerous by many people, as MAC addresses = are not always unique. There were several cases where an order of several t= housands of devices where shipped with the exact same MAC address, by mista= ke. Moreover, MAC addresses can be altered almost at will. This is why rely= ing on MAC addresses for unique identifiers is not sufficient in my mind. I= t's merely another way to say: "let other people worry about our p= roblems". This rarely works reliably.

As to using link local addresses, there are many cases = where it is not appropriate, as discussed over and over in this working gro= up and elsewhere. If you have any comments on=A0http://ietfreport.isoc.org/a= ll-ids/draft-baccelli-multi-hop-wireless-communication-04.txt=A0= please let us know. The fundam= ental properties of multi-hop wireless communications described in that doc= ument make it difficult to use link-local addresses in many cases.

<= span class=3D"Apple-style-span" style=3D"border-collapse: collapse;">And ag= ain, the goal of RFC5889 is not to describe all possible addressing models = for each specific scenario, but rather to describe one specific model with = which we have experience in=A0multi-hop wireless contexts, and which has proven to work O= K. In that re= spect, I think=A0RFC5889=A0does the job.

<= span class=3D"Apple-style-span" style=3D"border-collapse: collapse;">Regard= s,
Emmanuel=

--0015174c3c48949488048be2d8ab-- From jari.arkko@piuha.net Wed Jul 21 04:45:41 2010 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 06A783A69FE for ; Wed, 21 Jul 2010 04:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.357, 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 LsSTZCHojTT4 for ; Wed, 21 Jul 2010 04:45:40 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id ADDB83A69F3 for ; Wed, 21 Jul 2010 04:45:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 22A8A2CCCF; Wed, 21 Jul 2010 14:45:55 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4Z5x0RbDjbb; Wed, 21 Jul 2010 14:45:54 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id C599F2CC9A; Wed, 21 Jul 2010 14:45:53 +0300 (EEST) Message-ID: <4C46DDF0.9070305@piuha.net> Date: Wed, 21 Jul 2010 14:45:52 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Ryuji Wakikawa References: <88FBF3FE-D9BE-4085-B73D-DCA08BA454CF@gmail.com> <4C456182.4090700@piuha.net> <75DF3A67-95F7-4324-9F5E-385530EF1602@gmail.com> In-Reply-To: <75DF3A67-95F7-4324-9F5E-385530EF1602@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "autoconf@ietf.org autoconf@ietf.org" , Thomas Clausen Subject: Re: [Autoconf] Summary of re-chartering discussions. 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, 21 Jul 2010 11:45:41 -0000 Ryuji, Let me try again. I don't feel a need to delay the work on the distributed solution in any way, or bind its progress to the progress of the other deliverable that I wanted to see. I merely observed that as a part of the work for developing a distributed solution you will go through the usual steps, which involve documenting why that solution is needed, what the options there are in the design space, and so on. I'm fine adding the distributed solution to the charter, if those steps are in the charter. Also, you used the phrase "real AUTOCONF work". Were you referring to new protocol development as real work, or saying something about what types of solutions are going to be needed and used? For what it is worth, it is not at all clear to me that the fully distributed solutions are the only interesting ones. Virtually all networks have Internet connectivity for various good reasons, and relying on some subset of nodes -- perhaps the Internet gateway router(s) -- for the ad hoc network address allocation may be just fine in these networks. Particularly if it comes with less complexity and less time spent waiting for new software. I know what I would do in my network. Jari From jari.arkko@piuha.net Wed Jul 21 06:01:47 2010 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 7C3353A6A09 for ; Wed, 21 Jul 2010 06:01:47 -0700 (PDT) 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.325, 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 tZME732w3TAY for ; Wed, 21 Jul 2010 06:01:46 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 7DBBA3A679C for ; Wed, 21 Jul 2010 06:01:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0071D2CCCF; Wed, 21 Jul 2010 16:02:02 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90qRWsg8Ke7T; Wed, 21 Jul 2010 16:02:01 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 2562C2CC9A; Wed, 21 Jul 2010 16:02:01 +0300 (EEST) Message-ID: <4C46EFC8.6020501@piuha.net> Date: Wed, 21 Jul 2010 16:02:00 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Emmanuel Baccelli References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 21 Jul 2010 13:01:47 -0000 I too would be fine with a title change to "Router Addressing Model in Ad Hoc Networks" or even "*A* Router Addressing Model in Ad Hoc Networks"... Jari From ulrich@herberg.name Wed Jul 21 06:04:07 2010 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 735123A679C for ; Wed, 21 Jul 2010 06:04:07 -0700 (PDT) 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.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 thmtsM53qXsq for ; Wed, 21 Jul 2010 06:04:06 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 740D63A68DD for ; Wed, 21 Jul 2010 06:04:06 -0700 (PDT) Received: by bwz7 with SMTP id 7so159492bwz.31 for ; Wed, 21 Jul 2010 06:04:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.137.193 with SMTP id x1mr74601bkt.165.1279717458851; Wed, 21 Jul 2010 06:04:18 -0700 (PDT) Received: by 10.204.23.83 with HTTP; Wed, 21 Jul 2010 06:04:18 -0700 (PDT) In-Reply-To: <4C46EFC8.6020501@piuha.net> References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> <4C46EFC8.6020501@piuha.net> Date: Wed, 21 Jul 2010 15:04:18 +0200 Message-ID: From: Ulrich Herberg To: Jari Arkko Content-Type: multipart/alternative; boundary=0015174489928c38e5048be57079 Cc: "autoconf@ietf.org" , Emmanuel Baccelli Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 21 Jul 2010 13:04:07 -0000 --0015174489928c38e5048be57079 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 21, 2010 at 3:02 PM, Jari Arkko wrote: > I too would be fine with a title change to "Router Addressing Model in Ad > Hoc Networks" or even "*A* Router Addressing Model in Ad Hoc Networks"... I think the latter is a good idea. Ulrich --0015174489928c38e5048be57079 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 21, 2010 at 3:02 PM, Jari Ar= kko <jari.arkk= o@piuha.net> wrote:
I too would be fine with a title change to "Router Addressing Model in= Ad Hoc Networks" or even "*A* Router Addressing Model in Ad Hoc = Networks"...

I thi= nk the latter is a good idea.

Ulrich
--0015174489928c38e5048be57079-- From jari.arkko@piuha.net Wed Jul 21 07:40:13 2010 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 979463A6826 for ; Wed, 21 Jul 2010 07:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.298, 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 xkmEQDs9-9vL for ; Wed, 21 Jul 2010 07:40:12 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 4F8E73A67D1 for ; Wed, 21 Jul 2010 07:40:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D38FF2CCCF; Wed, 21 Jul 2010 17:40:26 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwqdnUtE3i05; Wed, 21 Jul 2010 17:40:26 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id E8DBB2CC9A; Wed, 21 Jul 2010 17:40:25 +0300 (EEST) Message-ID: <4C4706D8.5040904@piuha.net> Date: Wed, 21 Jul 2010 17:40:24 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Erik Nordmark References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> In-Reply-To: <4C378C29.2040302@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 21 Jul 2010 14:40:13 -0000 Erik, > I do think the document is misleading and confused. > That starts with the discrepancy between the title > IP Addressing Model in Ad Hoc Networks > and the abstract, which limits itself to configuring IP addresses for > router interfaces and not for the whole of an ad hoc network. > > I was under the impression that the WG was looking at a document that > addressed the scope that is implied by the title. OK, though I suspect that Section 1 paragraph 3 and Section 6.1 bullet 2 still says almost everything there is to say about the rest, too. Nevertheless, there is a proposal for title change. Perhaps a critical issue was not making it clear enough in the document that its not just about router addressing, but also just _a_ model, not _the_ model. I asked the working group to document one practical model for addressing rather than cover all possible options, as their work in trying to do the latter had stalled. > I find the more limited scope odd, since we existing routing protocols > like IS-IS that can operate (exchange routing information, forward IP > packets) without any IP addresses configured on the routers' > interfaces. (Even though a router needs some IP addresses to be > manageable with SNMP and to be able to send ICMP errors.) > > The implied conclusion that IPv6-link local addresses are undesirable > for router's interfaces is even odder, since RIPng and OSPFv3 both > require routers to use IPv6 link-local addresses for the routing > protocol exchanges. This may have been an issue in the document as approved, but I do not think there is an implication left in the text with the proposed changes folded in. More importantly, as the document correctly states there are differences in the requirements that routing protocols place on available addresses. I think the document makes a very pragmatic model choice in this light. > The document seems to assume that the uniqueness scope of link-local > addresses is limited to a single link, when it is the routability > scope which is limited to the link. There is a class of link-local > addresses with U=1 (those derived from EUI-64) that are globally > unique - but still is not routable outside of the link. I agree about the distinction, of course. But I re-read the document today but cannot see where the document claims otherwise. > The result is that the document can easily be construed as > discouraging approaches that make a lot of sense, which seems > counterproductive. > An example of such an approach is a routing protocol which uses IEEE > MAC addresses as router ids, assigns IPv6 link-local addresses to the > router's interfaces and uses that in the routing protocol exchanges, > and configures global addresses for use by applications. Again, I do not believe that the changed document can be construed as discouraging. > I think the exercise here is to try to correct some minor wording in > the recommendations in the document, but even if we succeed in doing > so the premises expressed in the introduction and elsewhere will be a > bit odd, since they focus on the configuration of router interfaces > and not on the addressing model of the Ad Hoc network. > >> OLD: >> Routing protocols running on a router may exhibit different >> requirements for uniqueness of interface addresses; some have no such >> requirements, others have requirements ranging from local uniqueness >> only, to uniqueness within, at least, the routing domain (as defined >> in [RFC1136]). >> >> Configuring an IP address that is unique within the routing domain >> satisfies the less stringent uniqueness requirements of local >> uniqueness, while also enabling protocols which have the most >> stringent requirements of uniqueness within the routing domain. This >> suggests the following principle: >> >> o an IP address assigned to an interface that connects to a link >> with undetermined connectivity properties should be unique, at >> least within the routing domain. >> NEW: >> Routing protocols running on a router may exhibit different >> requirements for uniqueness of interface addresses; some have no such >> requirements, others have requirements ranging from local uniqueness >> only, to uniqueness within, at least, the routing domain (as defined >> in [RFC1136]). Routing protocols that do not require unique IP addresses >> within the >> routing domain utilize a separate unique identifier within the routing >> protocol itself that must also be configured in some manner. > > With IS-IS one doesn't configure the router id; it is a factory > assigned MAC address. Such an approach is perfectly valid for Ad Hoc > routing protocols as well. Agreed. I think that case is covered by "configured in some manner", however. > Note that a router (as opposed to routing protocol) require IP > addresses to be managable and to be able to send ICMP errors. But the > above paragraph is trying to derive recommendations from the latter. > > I suggest the wording > Routing protocols that do not require unique IP addresses within the > routing domain utilize a separate unique identifier within the routing > protocol itself; such identifiers could be based on factory assignment > or configuration. We can make this change. >> Nevertheless, configuring an IP address that is unique within the >> routing >> domain satisfies the less stringent uniqueness requirements of local >> uniqueness, while also enabling protocols which have the most >> stringent requirements of uniqueness within the routing domain. As a >> result, the following principle allows for IP autoconfiguration to >> apply to the widest array of routing protocols: >> >> o an IP address assigned to an interface that connects to a link >> with undetermined connectivity properties should be unique, at >> least within the routing domain. >> >> And in Section 6.1: >> >> OLD: >> o There is no mechanism to ensure that IPv6 link-local addresses are >> unique across multiple links, hence they cannot be used to >> reliably identify routers (it is often desirable to identify a >> router with an IP address). >> NEW: >> o There is no mechanism to ensure that IPv6 link-local addresses are >> unique across multiple links, hence they cannot be used to >> reliably identify routers, should this be necessary by the routing >> protocol for which IP address autoconfiguration is being provided. > > According to RFC 4291 EUI-64-based interface identifiers have global > scope when created from a universal token. A result of this is that > link-local addresses formed from such interface identifiers have > global scope. Hence the "no mechanism" above seems factually incorrect. > > Thus I think section 6.1 needs to differentiate between the global and > local scope for the interface identifiers for it to make sense. > Should I suggest replacement text? There is a difference between an intent to create addresses with a particular scope, and our ability to test that they really are unique. The text says "no mechanism to ensure" and I take that it means the testing part. This seems correct, though I do agree that it might have been confusing. > This paragraph seems like a non seqiteur: > o Routers cannot forward any packets with link-local source or > destination addresses to other links (as per [RFC4291]) while most > of the time, routers need to be able to forward packets to/from > different links. > Clearly the application traffic needs to use non-link-local addresses > to work across multiple links, but that has nothing to do with what IP > addresses are configured on the interfaces of routers as we see from > the requirement for RIPng and OSPFv3 to use IPv6 link-locals on router > interfaces. > > Instead the issue is that link-local addresses are not useful for > applications *other than routing protocols*, and that is the > motivation for the subsequent paragraph: This section talks about the limited utility of link-local addresses. I agree that the paragraph above is relevant in an application context. >> OLD: >> Therefore, autoconfiguration solutions should be encouraged to >> primarily focus on configuring IP addresses that are not IPv6 link- >> local. >> NEW: >> Therefore, an autoconfiguration solution which provides a mechanism for >> assigning addresses with a wider scope than IPv6 link-local alone will >> be more generally useful than one that does not. > > That misses the point. It is the motivation for this recommendation > which is confused and misleading, and not the conclusion itself. The > motivation is that applications (other than routing protocols) most > likely desire to communicate across the whole Ad Hoc network, if not > across the whole Internet, which makes link-local addresses of limited > use. We agree so far. > But they can still be quite useful as for the purposes of routing > protocols, and bootstrapping address autoconfiguration protocols. And no one is disputing that. However, as stated in the document there are routing protocols that _do_ require non-link local addresses. So while I agree with your "can be still quite useful" claim I do not see a basis for claiming that link local addresses should be the one and only form of address configuration for routing protocols, or even that such addresses must be available as part of an addressing model. > This confusion is related to the odd scope mismatch between the title > and the abstract. Clearly we want to be able to autoconfigure > non-link-local addresses for applications, but the abstract limits the > scope of the document to IP addressed assigned to router interfaces, > and there link-local address might be just fine. See above. > Note that the last sentence in the first paragraph in section 4 is > also misleading (I'm assuming that paragraph is about configuring > router interfaces and not host interfaces) in saying > Note that while link-local addresses are assumed to be "on link", the > utility of link-local addresses is limited as described in Section 6. > when in fact using link-local address, in particular those based on > global scope interface identifiers, might be just fine for router > interfaces. See above. Jari From teco@inf-net.nl Wed Jul 21 09:15:13 2010 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 D77313A68CE for ; Wed, 21 Jul 2010 09:15:13 -0700 (PDT) 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 AO4ayLjbC7kc for ; Wed, 21 Jul 2010 09:15:12 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id E6D833A68CD for ; Wed, 21 Jul 2010 09:15:10 -0700 (PDT) Received: by ewy22 with SMTP id 22so2687564ewy.31 for ; Wed, 21 Jul 2010 09:15:27 -0700 (PDT) Received: by 10.213.31.83 with SMTP id x19mr6454242ebc.82.1279728926822; Wed, 21 Jul 2010 09:15:26 -0700 (PDT) Received: from [192.168.2.168] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id v59sm53588019eeh.16.2010.07.21.09.15.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 Jul 2010 09:15:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4C4706D8.5040904@piuha.net> Date: Wed, 21 Jul 2010 18:15:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <32B2F99E-B762-4AA6-BDA1-90405B691C90@inf-net.nl> References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <4C4706D8.5040904@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 21 Jul 2010 16:15:14 -0000 Op 21 jul 2010, om 16:40 heeft Jari Arkko het volgende geschreven: >>> OLD: >>> Therefore, autoconfiguration solutions should be encouraged to >>> primarily focus on configuring IP addresses that are not IPv6 link- >>> local. >>> NEW: >>> Therefore, an autoconfiguration solution which provides a mechanism = for >>> assigning addresses with a wider scope than IPv6 link-local alone = will >>> be more generally useful than one that does not. >>=20 >> That misses the point. It is the motivation for this recommendation = which is confused and misleading, and not the conclusion itself. The = motivation is that applications (other than routing protocols) most = likely desire to communicate across the whole Ad Hoc network, if not = across the whole Internet, which makes link-local addresses of limited = use. >=20 > We agree so far. >=20 >> But they can still be quite useful as for the purposes of routing = protocols, and bootstrapping address autoconfiguration protocols. >=20 > And no one is disputing that. However, as stated in the document there = are routing protocols that _do_ require non-link local addresses. So = while I agree with your "can be still quite useful" claim I do not see a = basis for claiming that link local addresses should be the one and only = form of address configuration for routing protocols, or even that such = addresses must be available as part of an addressing model. Some say NHDP / OLSR need non-link local addresses. I don't agree on = this. They use link-local destination address and all messages are = hop-by-hop forwarded. Source IP Address could (Chris Dearlove) / should = (Henning Rogge) be link local.=20 Originator Address must be unique in the MANET (OLSR) or two hops = (NHDP). See http://www.ietf.org/mail-archive/web/manet/current/msg11004.html What routing protocols _do_ require non-link local addresses? DYMO OrigNode.Address must be non-link local, but DYMO packets=20 to LL-MANET-Routers would use link local source address. And of course we need non-link locals for apps. Teco= From teco@inf-net.nl Wed Jul 21 09:57:26 2010 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 6279E3A6896 for ; Wed, 21 Jul 2010 09:57:26 -0700 (PDT) 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 6wMV050etOuI for ; Wed, 21 Jul 2010 09:57:23 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 40BDA3A67F8 for ; Wed, 21 Jul 2010 09:57:22 -0700 (PDT) Received: by eyb7 with SMTP id 7so2018309eyb.31 for ; Wed, 21 Jul 2010 09:57:38 -0700 (PDT) Received: by 10.213.12.196 with SMTP id y4mr387794eby.89.1279731458193; Wed, 21 Jul 2010 09:57:38 -0700 (PDT) Received: from [192.168.2.168] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id v59sm53665692eeh.10.2010.07.21.09.57.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 Jul 2010 09:57:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Wed, 21 Jul 2010 18:57:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> To: Emmanuel Baccelli X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 21 Jul 2010 16:57:26 -0000 Emmanuel, Let's solve the duplicate unique MAC address problem. You bring the = cards, I'll take the hammer. Then, we (IETF) can stop solving others = problems. DHCP fully relies on a client provided token, which must be unique. An overwhelming majority of clients use MAC addresses. I don't say there are no problems, but many of us accept the risk. Posted before, I dealt with a DAD DOS attack. It is proven that it is = broken. I don't want to accept this risk. Ideas? Teco Op 21 jul 2010, om 11:58 heeft Emmanuel Baccelli het volgende = geschreven: > Hi Erik, >=20 >=20 > On Fri, Jul 9, 2010 at 10:52 PM, Erik Nordmark = wrote: > ... > =20 > The result is that the document can easily be construed as = discouraging approaches that make a lot of sense, which seems = counterproductive. > An example of such an approach is a routing protocol which uses IEEE = MAC addresses as router ids, assigns IPv6 link-local addresses to the = router's interfaces and uses that in the routing protocol exchanges, and = configures global addresses for use by applications. >=20 > =20 >=20 > Using MAC addresses for unique identifier is considered dangerous by = many people, as MAC addresses are not always unique. There were several = cases where an order of several thousands of devices where shipped with = the exact same MAC address, by mistake. Moreover, MAC addresses can be = altered almost at will. This is why relying on MAC addresses for unique = identifiers is not sufficient in my mind. It's merely another way to = say: "let other people worry about our problems". This rarely works = reliably. >=20 > As to using link local addresses, there are many cases where it is not = appropriate, as discussed over and over in this working group and = elsewhere. If you have any comments on = http://ietfreport.isoc.org/all-ids/draft-baccelli-multi-hop-wireless-commu= nication-04.txt please let us know. The fundamental properties of = multi-hop wireless communications described in that document make it = difficult to use link-local addresses in many cases. >=20 > And again, the goal of RFC5889 is not to describe all possible = addressing models for each specific scenario, but rather to describe one = specific model with which we have experience in multi-hop wireless = contexts, and which has proven to work OK. In that respect, I think = RFC5889 does the job. >=20 > Regards, > Emmanuel >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From hrogge@googlemail.com Wed Jul 21 10:05:32 2010 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 C7B2E3A68C8 for ; Wed, 21 Jul 2010 10:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.483, 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 Sq9LQvEl8LYP for ; Wed, 21 Jul 2010 10:05:31 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 22D5C3A6784 for ; Wed, 21 Jul 2010 10:05:30 -0700 (PDT) Received: by eyb7 with SMTP id 7so2022325eyb.31 for ; Wed, 21 Jul 2010 10:05:46 -0700 (PDT) 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=JFGNwHLizHek0DvbnpU0+ft0qhQmyMwmUBhKy2UqN6c=; b=HquOryJa4SsPo0EeqfuDSci3ZtmW70MZ4Ld9GB7RBIOVwy6DseCGMt+gxBUldQZclt 6WUavcXmdD1aeULUWXeeqZFF1kR2Vc60picf2kLaTQ9klMYAjz4T0VPZkGeaZcffLhAb I/CrCp8++gwDT4JeMHsYAYvH6Af/9Jg0GkRRQ= 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=omCPOjX1iuqGJUZidwaV/Xy34kHiGECjuffhA5RNt4De6W8rie3lkJuVAoBvO2a+uU jyivnJ+im+IiuNgq4KYK/Zj5deuTlqzCxgCQoLkZLckbs69cYtM/qx1Ddgl/lY8fevGw eRCeGgVmF2HFKU4sH9pyfHnPJYe47eGPxP9Zs= Received: by 10.213.27.206 with SMTP id j14mr6724482ebc.3.1279731946577; Wed, 21 Jul 2010 10:05:46 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id v8sm53639274eeh.20.2010.07.21.10.05.45 (version=SSLv3 cipher=RC4-MD5); Wed, 21 Jul 2010 10:05:45 -0700 (PDT) From: Henning Rogge To: autoconf@ietf.org Date: Wed, 21 Jul 2010 19:05:39 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.34-gentoo-r2; KDE/4.4.5; x86_64; ; ) References: <4C2A6BB7.1000900@piuha.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart22454393.3Fs1326D0r"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201007211905.44644.hrogge@googlemail.com> Cc: Emmanuel Baccelli Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 21 Jul 2010 17:05:32 -0000 --nextPart22454393.3Fs1326D0r Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Am Mittwoch 21 Juli 2010, 18:57:36 schrieb Teco Boot: > Emmanuel, >=20 > Let's solve the duplicate unique MAC address problem. You bring the cards, > I'll take the hammer. Then, we (IETF) can stop solving others problems. I think the problem would be network hardware without the concept of a laye= r 2=20 address. Just pure broadcast. Duplicate MACs can be a pain in the ass, but most times they are defective= =20 hardware (or misconfigured eprom/flash). > DHCP fully relies on a client provided token, which must be unique. > An overwhelming majority of clients use MAC addresses. > I don't say there are no problems, but many of us accept the risk. If we have an unique number for each device, autoconfiguration gets nearly= =20 trivial. =20 > Posted before, I dealt with a DAD DOS attack. It is proven that it is > broken. I don't want to accept this risk. > Ideas? Attacking parts of the IP stack of a node sounds interesting... is there a= =20 paper about this ? Henning Rogge =2D-=20 1) You can't win. 2) You can't break even. 3) You can't leave the game. =E2=80=94 The Laws of Thermodynamics, summarized --nextPart22454393.3Fs1326D0r Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEABECAAYFAkxHKOgACgkQcenvcwAcHWeYkgCggBxjgLBcHCW2wbdEcXEu2D8w 0ucAn3yUep7WafAxQkW520PSN5jGqabx =GwIU -----END PGP SIGNATURE----- --nextPart22454393.3Fs1326D0r-- From teco@inf-net.nl Wed Jul 21 11:02:09 2010 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 74D093A6946 for ; Wed, 21 Jul 2010 11:02:09 -0700 (PDT) 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 eulAeYr+EtHF for ; Wed, 21 Jul 2010 11:02:08 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 3E3073A6936 for ; Wed, 21 Jul 2010 11:02:08 -0700 (PDT) Received: by ewy22 with SMTP id 22so2795181ewy.31 for ; Wed, 21 Jul 2010 11:02:24 -0700 (PDT) Received: by 10.213.31.147 with SMTP id y19mr6588861ebc.57.1279735343933; Wed, 21 Jul 2010 11:02:23 -0700 (PDT) Received: from [192.168.2.168] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id z55sm53782237eeh.3.2010.07.21.11.02.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 Jul 2010 11:02:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <201007211905.44644.hrogge@googlemail.com> Date: Wed, 21 Jul 2010 20:02:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C2A6BB7.1000900@piuha.net> <201007211905.44644.hrogge@googlemail.com> To: Henning Rogge X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 21 Jul 2010 18:02:09 -0000 Op 21 jul 2010, om 19:05 heeft Henning Rogge het volgende geschreven: > Am Mittwoch 21 Juli 2010, 18:57:36 schrieb Teco Boot: >> Emmanuel, >>=20 >> Let's solve the duplicate unique MAC address problem. You bring the = cards, >> I'll take the hammer. Then, we (IETF) can stop solving others = problems. > I think the problem would be network hardware without the concept of a = layer 2=20 > address. Just pure broadcast. Sure, this type of radios exist. But there is no dup unique MAC address = problem. Often, the device has another interface with an unique MAC address.=20 But yes, there would be stuff without such. I suggest to leave those out = of scope for now. I never saw a business case for supporting these dumb = objects right now. >> Posted before, I dealt with a DAD DOS attack. It is proven that it is >> broken. I don't want to accept this risk. >> Ideas? > Attacking parts of the IP stack of a node sounds interesting... is = there a=20 > paper about this ? I didn't say it was IP. See Section 4.1.3 of RFC 3756 and SeND (RFC3971). Also mentioned in SLAAC (RFC4862). Teco From alexandru.petrescu@gmail.com Wed Jul 21 11:33:05 2010 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 D83993A6AF4 for ; Wed, 21 Jul 2010 11:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.445 X-Spam-Level: X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[AWL=0.804, 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 ASrcAICdpd8C for ; Wed, 21 Jul 2010 11:33:02 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 4145C3A6A73 for ; Wed, 21 Jul 2010 11:32:42 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id E0D2E940172 for ; Wed, 21 Jul 2010 20:32:53 +0200 (CEST) Message-ID: <4C473D4C.8050504@gmail.com> Date: Wed, 21 Jul 2010 20:32:44 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: autoconf@ietf.org References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <4C4706D8.5040904@piuha.net> In-Reply-To: <4C4706D8.5040904@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100721-0, 21/07/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 21 Jul 2010 18:33:07 -0000 Side note... Le 21/07/2010 16:40, Jari Arkko a écrit : [...] >> The result is that the document can easily be construed as >> discouraging approaches that make a lot of sense, which seems >> counterproductive. An example of such an approach is a routing >> protocol which uses IEEE MAC addresses as router ids, assigns IPv6 >> link-local addresses to the router's interfaces and uses that in >> the routing protocol exchanges, and configures global addresses >> for use by applications. > > Again, I do not believe that the changed document can be construed > as discouraging. Again, in my reading the document discourages the use of link-local addresses. It is this draft text: > in general link-local addresses are of limited utility on links with > undetermined connectivity > > [...] > > o There is no mechanism to ensure that IPv6 link-local addresses are > unique across multiple links, hence they cannot be used to reliably > identify routers (it is often desirable to identify a > > [...] > > o Routers cannot forward any packets with link-local source or > destination addresses to other links > > [...] > > Note that the use of IPv4 link-local addresses [RFC3927] in this > context should be discouraged for most applications, as the > limitations outlined in Section 6.1 for IPv6 link-local addresses > also concern IPv4 link-local addresses. There is no place in the draft talking positively about the use of link-local addresses, despite the numerous agreements on this list that link-local addresses can and are being used by routing protocols. This difference between list statements and draft text is huge. It could be solved by simply saying that "link-local addresses can and are being used by routing protocols and stateless and stateful address auto-configuration" and "IPv4 link-local addresses are in widespread use on e.g. Bluetooth with ActiveSync on numerous small wireless mobile devices; OSs in widespread use self-configure IPv4 and IPv6 link-local addresses upon startup, w/o means to forbid this self configuration". Alex > >> I think the exercise here is to try to correct some minor wording >> in the recommendations in the document, but even if we succeed in >> doing so the premises expressed in the introduction and elsewhere >> will be a bit odd, since they focus on the configuration of router >> interfaces and not on the addressing model of the Ad Hoc network. >> >>> OLD: Routing protocols running on a router may exhibit different >>> requirements for uniqueness of interface addresses; some have >>> no such requirements, others have requirements ranging from >>> local uniqueness only, to uniqueness within, at least, the >>> routing domain (as defined in [RFC1136]). >>> >>> Configuring an IP address that is unique within the routing >>> domain satisfies the less stringent uniqueness requirements of >>> local uniqueness, while also enabling protocols which have the >>> most stringent requirements of uniqueness within the routing >>> domain. This suggests the following principle: >>> >>> o an IP address assigned to an interface that connects to a link >>> with undetermined connectivity properties should be unique, at >>> least within the routing domain. NEW: Routing protocols running >>> on a router may exhibit different requirements for uniqueness of >>> interface addresses; some have no such requirements, others have >>> requirements ranging from local uniqueness only, to uniqueness >>> within, at least, the routing domain (as defined in [RFC1136]). >>> Routing protocols that do not require unique IP addresses within >>> the routing domain utilize a separate unique identifier within >>> the routing protocol itself that must also be configured in some >>> manner. >> >> With IS-IS one doesn't configure the router id; it is a factory >> assigned MAC address. Such an approach is perfectly valid for Ad >> Hoc routing protocols as well. > > Agreed. I think that case is covered by "configured in some manner", > however. > >> Note that a router (as opposed to routing protocol) require IP >> addresses to be managable and to be able to send ICMP errors. But >> the above paragraph is trying to derive recommendations from the >> latter. >> >> I suggest the wording Routing protocols that do not require unique >> IP addresses within the routing domain utilize a separate unique >> identifier within the routing protocol itself; such identifiers >> could be based on factory assignment or configuration. > > We can make this change. > >>> Nevertheless, configuring an IP address that is unique within >>> the routing domain satisfies the less stringent uniqueness >>> requirements of local uniqueness, while also enabling protocols >>> which have the most stringent requirements of uniqueness within >>> the routing domain. As a result, the following principle allows >>> for IP autoconfiguration to apply to the widest array of routing >>> protocols: >>> >>> o an IP address assigned to an interface that connects to a link >>> with undetermined connectivity properties should be unique, at >>> least within the routing domain. >>> >>> And in Section 6.1: >>> >>> OLD: o There is no mechanism to ensure that IPv6 link-local >>> addresses are unique across multiple links, hence they cannot be >>> used to reliably identify routers (it is often desirable to >>> identify a router with an IP address). NEW: o There is no >>> mechanism to ensure that IPv6 link-local addresses are unique >>> across multiple links, hence they cannot be used to reliably >>> identify routers, should this be necessary by the routing >>> protocol for which IP address autoconfiguration is being >>> provided. >> >> According to RFC 4291 EUI-64-based interface identifiers have >> global scope when created from a universal token. A result of this >> is that link-local addresses formed from such interface identifiers >> have global scope. Hence the "no mechanism" above seems factually >> incorrect. >> >> Thus I think section 6.1 needs to differentiate between the global >> and local scope for the interface identifiers for it to make sense. >> Should I suggest replacement text? > > There is a difference between an intent to create addresses with a > particular scope, and our ability to test that they really are > unique. The text says "no mechanism to ensure" and I take that it > means the testing part. This seems correct, though I do agree that > it might have been confusing. > >> This paragraph seems like a non seqiteur: o Routers cannot forward >> any packets with link-local source or destination addresses to >> other links (as per [RFC4291]) while most of the time, routers >> need to be able to forward packets to/from different links. Clearly >> the application traffic needs to use non-link-local addresses to >> work across multiple links, but that has nothing to do with what IP >> addresses are configured on the interfaces of routers as we see >> from the requirement for RIPng and OSPFv3 to use IPv6 link-locals >> on router interfaces. >> >> Instead the issue is that link-local addresses are not useful for >> applications *other than routing protocols*, and that is the >> motivation for the subsequent paragraph: > > This section talks about the limited utility of link-local > addresses. I agree that the paragraph above is relevant in an > application context. > >>> OLD: Therefore, autoconfiguration solutions should be encouraged >>> to primarily focus on configuring IP addresses that are not IPv6 >>> link- local. NEW: Therefore, an autoconfiguration solution which >>> provides a mechanism for assigning addresses with a wider scope >>> than IPv6 link-local alone will be more generally useful than one >>> that does not. >> >> That misses the point. It is the motivation for this >> recommendation which is confused and misleading, and not the >> conclusion itself. The motivation is that applications (other than >> routing protocols) most likely desire to communicate across the >> whole Ad Hoc network, if not across the whole Internet, which makes >> link-local addresses of limited use. > > We agree so far. > >> But they can still be quite useful as for the purposes of routing >> protocols, and bootstrapping address autoconfiguration protocols. > > And no one is disputing that. However, as stated in the document > there are routing protocols that _do_ require non-link local > addresses. So while I agree with your "can be still quite useful" > claim I do not see a basis for claiming that link local addresses > should be the one and only form of address configuration for routing > protocols, or even that such addresses must be available as part of > an addressing model. > >> This confusion is related to the odd scope mismatch between the >> title and the abstract. Clearly we want to be able to >> autoconfigure non-link-local addresses for applications, but the >> abstract limits the scope of the document to IP addressed assigned >> to router interfaces, and there link-local address might be just >> fine. > > See above. > >> Note that the last sentence in the first paragraph in section 4 is >> also misleading (I'm assuming that paragraph is about configuring >> router interfaces and not host interfaces) in saying Note that >> while link-local addresses are assumed to be "on link", the >> utility of link-local addresses is limited as described in Section >> 6. when in fact using link-local address, in particular those based >> on global scope interface identifiers, might be just fine for >> router interfaces. > > See above. > > Jari > > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > From alexandru.petrescu@gmail.com Wed Jul 21 11:35:42 2010 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 3E2B43A68A3 for ; Wed, 21 Jul 2010 11:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.534 X-Spam-Level: X-Spam-Status: No, score=-1.534 tagged_above=-999 required=5 tests=[AWL=0.715, 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 MvgKvRHk2GXP for ; Wed, 21 Jul 2010 11:35:28 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 47E3E3A6AF3 for ; Wed, 21 Jul 2010 11:35:22 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 473839401E4 for ; Wed, 21 Jul 2010 20:35:16 +0200 (CEST) Message-ID: <4C473DDB.6000505@gmail.com> Date: Wed, 21 Jul 2010 20:35:07 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: autoconf@ietf.org References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100721-0, 21/07/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 21 Jul 2010 18:35:42 -0000 Le 21/07/2010 11:58, Emmanuel Baccelli a écrit : > Hi Erik, > > > On Fri, Jul 9, 2010 at 10:52 PM, Erik Nordmark > wrote: > > ... > > The result is that the document can easily be construed as > discouraging approaches that make a lot of sense, which seems > counterproductive. > An example of such an approach is a routing protocol which uses IEEE > MAC addresses as router ids, assigns IPv6 link-local addresses to > the router's interfaces and uses that in the routing protocol > exchanges, and configures global addresses for use by applications. > > > Using MAC addresses for unique identifier is considered dangerous by > many people, as MAC addresses are not always unique. There were several > cases where an order of several thousands of devices where shipped with > the exact same MAC address, by mistake. Moreover, MAC addresses can be > altered almost at will. This is why relying on MAC addresses for unique > identifiers is not sufficient in my mind. It's merely another way to > say: "let other people worry about our problems". This rarely works > reliably. > > As to using link local addresses, there are many cases where it is not > appropriate, Sure, and there are many cases where they are appropriate. Why mentioning only the negative part? > as discussed over and over in this working group and > elsewhere. If you have any comments on > http://ietfreport.isoc.org/all-ids/draft-baccelli-multi-hop-wireless-communication-04.txt > please let us know. The fundamental properties of multi-hop wireless > communications described in that document make it difficult to use > link-local addresses in many cases. Hmmm... sure, in that particular draft deployment. In the multi-hop wireless communications system I build the link-local addresses are very useful and actually can't work without them. Alex > > And again, the goal of RFC5889 is not to describe all possible > addressing models for each specific scenario, but rather to describe one > specific model with which we have experience in multi-hop wireless > contexts, and which has proven to work OK. In that respect, I > think RFC5889 does the job. > > Regards, > Emmanuel > > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From Chris.Dearlove@baesystems.com Thu Jul 22 01:47:38 2010 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 B994B3A69DD for ; Thu, 22 Jul 2010 01:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.4 X-Spam-Level: X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[AWL=-1.290, BAYES_05=-1.11, 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 v5mPZzi9Iu4f for ; Thu, 22 Jul 2010 01:47:37 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 759903A6784 for ; Thu, 22 Jul 2010 01:47:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,242,1278284400"; d="scan'208";a="77795057" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Jul 2010 09:47:53 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o6M8lqwr002428; Thu, 22 Jul 2010 09:47:52 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 09:47:52 +0100 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, 22 Jul 2010 09:47:51 +0100 Message-ID: In-Reply-To: <4C473D4C.8050504@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) thread-index: AcspAzlkRg0UEV6oQ8OELKyzrJ5LbgAdgEmQ References: <4C2A6BB7.1000900@piuha.net><4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com><4C4706D8.5040904@piuha.net> <4C473D4C.8050504@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , X-OriginalArrivalTime: 22 Jul 2010 08:47:52.0925 (UTC) FILETIME=[926850D0:01CB297A] Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 08:47:39 -0000 Alexandru (But I'm just quoting this for convenience. It's not really specific to this text.) > It could be solved by simply saying that "link-local addresses can and > are being used by routing protocols and stateless and stateful address > auto-configuration" and "IPv4 link-local addresses are in widespread use > on e.g. Bluetooth with ActiveSync on numerous small wireless mobile > devices; OSs in widespread use self-configure IPv4 and IPv6 link-local > addresses upon startup, w/o means to forbid this self configuration". This is a very worrying trend. This document is in AUTH48, it's been accepted by the WG and the IESG. Even the original edits proposed (especially the third) were beyond what I understand what AUTH48 is about, which is minor editorial changes. Now we are discussing a title change and fundamental wording that took years to thrash out a compromise that can't possibly be overturned in an AUTH48 context. I think it's time to make either the original first two edits, or no edits at all, and issue. Anyone who wants to propose an alternative addressing model can write a new Internet Draft and push it down the Independent Submission track. -- 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 ******************************************************************** 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 Thu Jul 22 02:07:00 2010 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 20AFD3A69F8 for ; Thu, 22 Jul 2010 02:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[AWL=0.418, 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 YXS2NfCyXnLm for ; Thu, 22 Jul 2010 02:06:59 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id E8A553A6A55 for ; Thu, 22 Jul 2010 02:06:58 -0700 (PDT) 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 o6M97C33006897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jul 2010 11:07:12 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6M97CrS010235; Thu, 22 Jul 2010 11:07:12 +0200 (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 o6M97B87024041; Thu, 22 Jul 2010 11:07:12 +0200 Message-ID: <4C480A3F.3000103@gmail.com> Date: Thu, 22 Jul 2010 11:07:11 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4C2A6BB7.1000900@piuha.net><4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com><4C4706D8.5040904@piuha.net> <4C473D4C.8050504@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] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 09:07:00 -0000 Le 22/07/2010 10:47, Dearlove, Christopher (UK) a écrit : > Alexandru (But I'm just quoting this for convenience. It's not really > specific to this text.) >> It could be solved by simply saying that "link-local addresses can >> and are being used by routing protocols and stateless and stateful >> address auto-configuration" and "IPv4 link-local addresses are in >> widespread > use >> on e.g. Bluetooth with ActiveSync on numerous small wireless >> mobile devices; OSs in widespread use self-configure IPv4 and IPv6 >> link-local addresses upon startup, w/o means to forbid this self >> configuration". > > This is a very worrying trend. This document is in AUTH48, 48... 48 hours you mean? > it's been accepted by the WG and the IESG. Even the original edits > proposed (especially the third) were beyond what I understand what > AUTH48 is about, which is minor editorial changes. Now we are > discussing a title change and fundamental wording that took years to > thrash out a compromise that can't possibly be overturned in an > AUTH48 context. I think it's time to make either the original first > two edits, or no edits at all, and issue. Anyone who wants to propose > an alternative addressing model can write a new Internet Draft and > push it down the Independent Submission track. Sure. And an RFC is a Request For Comments. Alex > From Chris.Dearlove@baesystems.com Thu Jul 22 02:13:55 2010 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 7DF303A69FB for ; Thu, 22 Jul 2010 02:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.08 X-Spam-Level: X-Spam-Status: No, score=-7.08 tagged_above=-999 required=5 tests=[AWL=-0.481, 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 3ofNF5vKw3+C for ; Thu, 22 Jul 2010 02:13:54 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 18C343A68A2 for ; Thu, 22 Jul 2010 02:13:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,242,1278284400"; d="scan'208";a="77804014" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Jul 2010 10:14:10 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o6M9E9TJ024777; Thu, 22 Jul 2010 10:14:10 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 10:14:10 +0100 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: Thu, 22 Jul 2010 10:14:09 +0100 Message-ID: In-Reply-To: <4C480A3F.3000103@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) thread-index: AcspfUm53T/msA6vTRihNgXW9z0QEQAAHtfg References: <4C2A6BB7.1000900@piuha.net><4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com><4C4706D8.5040904@piuha.net> <4C473D4C.8050504@gmail.com> <4C480A3F.3000103@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 22 Jul 2010 09:14:10.0560 (UTC) FILETIME=[3EC05000:01CB297E] Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 09:13:55 -0000 AUTH48 is a formal RFC Editor state, as you should know. I believe that 48 did originally refer to 48 hours, but that's not the point (though it is a strong hint). The point is what AUTH48 covers, which is not a technical rewrite.=20 What RFC did or does stand for is irrelevant to this. --=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: 22 July 2010 10:07 To: Dearlove, Christopher (UK) Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF = charter proposal) *** 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. =20 Le 22/07/2010 10:47, Dearlove, Christopher (UK) a =E9crit : > Alexandru (But I'm just quoting this for convenience. It's not really > specific to this text.) >> It could be solved by simply saying that "link-local addresses can >> and are being used by routing protocols and stateless and stateful >> address auto-configuration" and "IPv4 link-local addresses are in >> widespread > use >> on e.g. Bluetooth with ActiveSync on numerous small wireless >> mobile devices; OSs in widespread use self-configure IPv4 and IPv6 >> link-local addresses upon startup, w/o means to forbid this self >> configuration". > > This is a very worrying trend. This document is in AUTH48, 48... 48 hours you mean? > it's been accepted by the WG and the IESG. Even the original edits > proposed (especially the third) were beyond what I understand what > AUTH48 is about, which is minor editorial changes. Now we are > discussing a title change and fundamental wording that took years to > thrash out a compromise that can't possibly be overturned in an > AUTH48 context. I think it's time to make either the original first > two edits, or no edits at all, and issue. Anyone who wants to propose > an alternative addressing model can write a new Internet Draft and > push it down the Independent Submission track. Sure. And an RFC is a Request For Comments. 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 ulrich@herberg.name Thu Jul 22 02:16:18 2010 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 F3C0A3A6A40 for ; Thu, 22 Jul 2010 02:16:17 -0700 (PDT) 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 Y6dWjQ95EoVd for ; Thu, 22 Jul 2010 02:16:17 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id D1DC83A68A2 for ; Thu, 22 Jul 2010 02:16:16 -0700 (PDT) Received: by bwz7 with SMTP id 7so841189bwz.31 for ; Thu, 22 Jul 2010 02:16:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.70.201 with SMTP id e9mr1084665bkj.141.1279790190059; Thu, 22 Jul 2010 02:16:30 -0700 (PDT) Received: by 10.204.23.83 with HTTP; Thu, 22 Jul 2010 02:16:29 -0700 (PDT) In-Reply-To: <4C480A3F.3000103@gmail.com> References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <4C4706D8.5040904@piuha.net> <4C473D4C.8050504@gmail.com> <4C480A3F.3000103@gmail.com> Date: Thu, 22 Jul 2010 11:16:29 +0200 Message-ID: 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] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 09:16:18 -0000 Alex, On Thu, Jul 22, 2010 at 11:07 AM, Alexandru Petrescu wrote: > > Le 22/07/2010 10:47, Dearlove, Christopher (UK) a =E9crit : >> >> Alexandru (But I'm just quoting this for convenience. It's not really >> specific to this text.) >>> >>> It could be solved by simply saying that "link-local addresses can >>> and are being used by routing protocols and stateless and stateful >>> address auto-configuration" and "IPv4 link-local addresses are in >>> widespread >> >> use >>> >>> on e.g. Bluetooth with ActiveSync on numerous small wireless >>> mobile devices; OSs in widespread use self-configure IPv4 and IPv6 >>> link-local addresses upon startup, w/o means to forbid this self >>> configuration". >> >> This is a very worrying trend. This document is in AUTH48, > > 48... 48 hours you mean? Please have a look at http://www.rfc-editor.org/pubprocess.html (in particular at the bottom of the webpage) > >> it's been accepted by the WG and the IESG. Even the original edits >> proposed (especially the third) were beyond what I understand what >> AUTH48 is about, which is minor editorial changes. Now we are >> discussing a title change and fundamental wording that took years to >> thrash out a compromise that can't possibly be overturned in an >> AUTH48 context. I think it's time to make either the original first >> two edits, or no edits at all, and issue. Anyone who wants to propose >> an alternative addressing model can write a new Internet Draft and >> push it down the Independent Submission track. I fully agree with Chris. Changing major content of a document in AUTH48 is not a good idea. > > Sure. > > And an RFC is a Request For Comments. yes, so? You may also be interested in reading http://www.ietf.org/rfc/rfc2026.txt Ulrich From alexandru.petrescu@gmail.com Thu Jul 22 02:36:07 2010 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 7C1423A68A2 for ; Thu, 22 Jul 2010 02:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.372, 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 Pp4+38ohEDeM for ; Thu, 22 Jul 2010 02:36:06 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 4F8063A6855 for ; Thu, 22 Jul 2010 02:36:06 -0700 (PDT) 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 o6M9aLd9000523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jul 2010 11:36:21 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6M9aKv5019627; Thu, 22 Jul 2010 11:36:20 +0200 (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 o6M9aKRq026025; Thu, 22 Jul 2010 11:36:20 +0200 Message-ID: <4C481114.8000706@gmail.com> Date: Thu, 22 Jul 2010 11:36:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4C2A6BB7.1000900@piuha.net><4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com><4C4706D8.5040904@piuha.net> <4C473D4C.8050504@gmail.com> <4C480A3F.3000103@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] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 09:36:07 -0000 Could you positively say what an AUTH48 _does_ cover? I understand what it does _not_ cover. I also understand that 48hours is _not_ the point. Alex Le 22/07/2010 11:14, Dearlove, Christopher (UK) a écrit : > AUTH48 is a formal RFC Editor state, as you should know. I > believe that 48 did originally refer to 48 hours, but that's > not the point (though it is a strong hint). The point is what > AUTH48 covers, which is not a technical rewrite. > > What RFC did or does stand for is irrelevant to this. > From Chris.Dearlove@baesystems.com Thu Jul 22 02:41:47 2010 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 0299C3A6A50 for ; Thu, 22 Jul 2010 02:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.058 X-Spam-Level: X-Spam-Status: No, score=-7.058 tagged_above=-999 required=5 tests=[AWL=-0.459, 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 yxnc2Rajj9Pl for ; Thu, 22 Jul 2010 02:41:46 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id C32CB3A6855 for ; Thu, 22 Jul 2010 02:41:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,242,1278284400"; d="scan'208";a="77814387" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Jul 2010 10:42:02 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o6M9g28Y016149; Thu, 22 Jul 2010 10:42:02 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 10:42:02 +0100 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: Thu, 22 Jul 2010 10:42:00 +0100 Message-ID: In-Reply-To: <4C481114.8000706@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) thread-index: AcspgVsMnax3uxGET0OgNkTWYBjfyAAALTeg References: <4C2A6BB7.1000900@piuha.net><4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com><4C4706D8.5040904@piuha.net> <4C473D4C.8050504@gmail.com> <4C480A3F.3000103@gmail.com> <4C481114.8000706@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 22 Jul 2010 09:42:02.0190 (UTC) FILETIME=[231ECEE0:01CB2982] Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 09:41:47 -0000 See the reference quoted. And you've been an RFC author, you've been through it. The text concentrates on editorial stuff (getting references right, that sort of thing). And my experience was largely about grammar, punctuation and capitalisation (lots of that one). But as I read it technical errors would probably be in scope. But rewriting the recommendations is definitely not if I am any judge at all. --=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: 22 July 2010 10:36 To: Dearlove, Christopher (UK) Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF = charter proposal) *** 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. =20 Could you positively say what an AUTH48 _does_ cover? I understand what it does _not_ cover. I also understand that 48hours is _not_ the point. Alex Le 22/07/2010 11:14, Dearlove, Christopher (UK) a =E9crit : > AUTH48 is a formal RFC Editor state, as you should know. I > believe that 48 did originally refer to 48 hours, but that's > not the point (though it is a strong hint). The point is what > AUTH48 covers, which is not a technical rewrite. > > What RFC did or does stand for is irrelevant to this. > ******************************************************************** 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 Thu Jul 22 02:49:52 2010 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 18ACE3A69DD for ; Thu, 22 Jul 2010 02:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.334, 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 RNNjQMh0t7Se for ; Thu, 22 Jul 2010 02:49:51 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id EDE653A6853 for ; Thu, 22 Jul 2010 02:49:50 -0700 (PDT) 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 o6M9o6Ar006051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jul 2010 11:50:06 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6M9o6uU023410; Thu, 22 Jul 2010 11:50:06 +0200 (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 o6M9o5No031559; Thu, 22 Jul 2010 11:50:05 +0200 Message-ID: <4C48144D.4040105@gmail.com> Date: Thu, 22 Jul 2010 11:50:05 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: autoconf@ietf.org References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> <4C46EFC8.6020501@piuha.net> In-Reply-To: <4C46EFC8.6020501@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 09:49:52 -0000 Le 21/07/2010 15:02, Jari Arkko a écrit : > I too would be fine with a title change to "Router Addressing Model in > Ad Hoc Networks" or even "*A* Router Addressing Model in Ad Hoc > Networks"... I disagree. There are Ad-Hoc Networks which don't use that Addressing Model. The way link-local addresses are formed is specifically to work in ad-hoc unplanned networks... or, this draft discourages them. Alex > > Jari > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From alexandru.petrescu@gmail.com Thu Jul 22 02:50:10 2010 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 85B3A3A6A58 for ; Thu, 22 Jul 2010 02:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.304, 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 CCAJAfuM5yCl for ; Thu, 22 Jul 2010 02:50:09 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 2304D3A6A7D for ; Thu, 22 Jul 2010 02:50:08 -0700 (PDT) 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 o6M9oNB1014152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jul 2010 11:50:23 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6M9oN4W023472; Thu, 22 Jul 2010 11:50:23 +0200 (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 o6M9oMru031694; Thu, 22 Jul 2010 11:50:23 +0200 Message-ID: <4C48145E.3020202@gmail.com> Date: Thu, 22 Jul 2010 11:50:22 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Ulrich Herberg References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <4C4706D8.5040904@piuha.net> <4C473D4C.8050504@gmail.com> <4C480A3F.3000103@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] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 09:50:10 -0000 Le 22/07/2010 11:16, Ulrich Herberg a écrit : > Alex, > > On Thu, Jul 22, 2010 at 11:07 AM, Alexandru Petrescu > wrote: >> >> Le 22/07/2010 10:47, Dearlove, Christopher (UK) a écrit : >>> >>> Alexandru (But I'm just quoting this for convenience. It's not really >>> specific to this text.) >>>> >>>> It could be solved by simply saying that "link-local addresses can >>>> and are being used by routing protocols and stateless and stateful >>>> address auto-configuration" and "IPv4 link-local addresses are in >>>> widespread >>> >>> use >>>> >>>> on e.g. Bluetooth with ActiveSync on numerous small wireless >>>> mobile devices; OSs in widespread use self-configure IPv4 and IPv6 >>>> link-local addresses upon startup, w/o means to forbid this self >>>> configuration". >>> >>> This is a very worrying trend. This document is in AUTH48, >> >> 48... 48 hours you mean? > > Please have a look at http://www.rfc-editor.org/pubprocess.html (in > particular at the bottom of the webpage) Sure, it says "Upon request or because of temporary unavailability of an author, the nominal 48 hours will be extended." Earlier it says "to look over their document for errors, editorial and otherwise." To me this does not restrict the spread of potential change. >>> it's been accepted by the WG and the IESG. Even the original edits >>> proposed (especially the third) were beyond what I understand what >>> AUTH48 is about, which is minor editorial changes. Now we are >>> discussing a title change and fundamental wording that took years to >>> thrash out a compromise that can't possibly be overturned in an >>> AUTH48 context. I think it's time to make either the original first >>> two edits, or no edits at all, and issue. Anyone who wants to propose >>> an alternative addressing model can write a new Internet Draft and >>> push it down the Independent Submission track. > > > I fully agree with Chris. Changing major content of a document in > AUTH48 is not a good idea. What _is_ a good idea in this situation where the emails on the list differ largely from the draft text (with respect to link-local addresses)? >> Sure. >> >> And an RFC is a Request For Comments. > > yes, so? So there were my comments. > You may also be interested in reading > http://www.ietf.org/rfc/rfc2026.txt Ulrich... ok, sure... "Not all specifications of protocols or services for the Internet should or will become Internet Standards or BCPs. Such non-standards track specifications are not subject to the rules for Internet standardization. Non-standards track specifications may be published directly as "Experimental" or "Informational" RFCs at the discretion of the RFC Editor in consultation with the IESG (see section 4.2)." One could thus write anything non-Internet in an Informational RFC. In that case I wonder why do we still debate it. There must be some reason... I guess it is because of the huge pretensions claimed by the title... Just call it "An Informational Document about Some Addresses" - I could live with it that way. Alex > > > Ulrich > From alexandru.petrescu@gmail.com Thu Jul 22 02:52:10 2010 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 AC6623A6853 for ; Thu, 22 Jul 2010 02:52:10 -0700 (PDT) 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 QIR3UkdTt3P6 for ; Thu, 22 Jul 2010 02:52:09 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 254763A69ED for ; Thu, 22 Jul 2010 02:52:08 -0700 (PDT) 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 o6M9qNA4007762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jul 2010 11:52:23 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6M9qM51024016; Thu, 22 Jul 2010 11:52:22 +0200 (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 o6M9qM1Y032347; Thu, 22 Jul 2010 11:52:22 +0200 Message-ID: <4C4814D6.2080907@gmail.com> Date: Thu, 22 Jul 2010 11:52:22 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4C2A6BB7.1000900@piuha.net><4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com><4C4706D8.5040904@piuha.net> <4C473D4C.8050504@gmail.com> <4C480A3F.3000103@gmail.com> <4C481114.8000706@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] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 09:52:10 -0000 There must a good reason why AUTH48 comments are discussed on the WG list. Alex Le 22/07/2010 11:42, Dearlove, Christopher (UK) a écrit : > See the reference quoted. And you've been an RFC author, you've > been through it. > > The text concentrates on editorial stuff (getting references right, > that sort of thing). And my experience was largely about grammar, > punctuation and capitalisation (lots of that one). But as I read > it technical errors would probably be in scope. But rewriting the > recommendations is definitely not if I am any judge at all. > From thomas@thomasclausen.org Thu Jul 22 02:52:37 2010 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 A75353A69DD for ; Thu, 22 Jul 2010 02:52:37 -0700 (PDT) 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 2brHFN5mW20H for ; Thu, 22 Jul 2010 02:52:36 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id E964B3A68A2 for ; Thu, 22 Jul 2010 02:52:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 5FD1D3236DB3; Thu, 22 Jul 2010 02:52:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.110] (AMontsouris-552-1-55-14.w92-140.abo.wanadoo.fr [92.140.30.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id ACAA23228BE9; Thu, 22 Jul 2010 02:52:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Heide Clausen In-Reply-To: <4C48144D.4040105@gmail.com> Date: Thu, 22 Jul 2010 11:52:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> <4C46EFC8.6020501@piuha.net> <4C48144D.4040105@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 09:52:37 -0000 On Jul 22, 2010, at 11:50 , Alexandru Petrescu wrote: > Le 21/07/2010 15:02, Jari Arkko a =E9crit : >> I too would be fine with a title change to "Router Addressing Model = in >> Ad Hoc Networks" or even "*A* Router Addressing Model in Ad Hoc >> Networks"... >=20 > I disagree. There are Ad-Hoc Networks which don't use that Addressing = Model. >=20 > The way link-local addresses are formed is specifically to work in = ad-hoc unplanned networks... or, this draft discourages them. Alex, I think you still don't capture that we're talking about multi-hop = networks here. Thomas >=20 > Alex >=20 >>=20 >> Jari >>=20 >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >>=20 >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Thu Jul 22 02:55:49 2010 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 C95573A6907 for ; Thu, 22 Jul 2010 02:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=0.257, 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 xm0X9MB4JkOk for ; Thu, 22 Jul 2010 02:55:49 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id C2DCA3A6A66 for ; Thu, 22 Jul 2010 02:55:48 -0700 (PDT) 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 o6M9u47X024344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jul 2010 11:56:04 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6M9u4lr024801; Thu, 22 Jul 2010 11:56:04 +0200 (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 o6M9u4Ub011141; Thu, 22 Jul 2010 11:56:04 +0200 Message-ID: <4C4815B4.6020907@gmail.com> Date: Thu, 22 Jul 2010 11:56:04 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Thomas Heide Clausen References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> <4C46EFC8.6020501@piuha.net> <4C48144D.4040105@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] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 09:55:49 -0000 Le 22/07/2010 11:52, Thomas Heide Clausen a écrit : > > On Jul 22, 2010, at 11:50 , Alexandru Petrescu wrote: > >> Le 21/07/2010 15:02, Jari Arkko a écrit : >>> I too would be fine with a title change to "Router Addressing >>> Model in Ad Hoc Networks" or even "*A* Router Addressing Model in >>> Ad Hoc Networks"... >> >> I disagree. There are Ad-Hoc Networks which don't use that >> Addressing Model. >> >> The way link-local addresses are formed is specifically to work in >> ad-hoc unplanned networks... or, this draft discourages them. > > Alex, I think you still don't capture that we're talking about > multi-hop networks here. Thomas - by multi-hop networks I mean: LFN--MR--MR--LFN is a multi-hop network using link-local addresses exclusively between MRs. I hope we capture each other's oppinion ok. Alex > > Thomas > > >> >> Alex >> >>> >>> Jari >>> >>> _______________________________________________ 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 thomas@thomasclausen.org Thu Jul 22 02:58:13 2010 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 C44FC3A6A81 for ; Thu, 22 Jul 2010 02:58:13 -0700 (PDT) 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 fgSz30s-ZUpG for ; Thu, 22 Jul 2010 02:58:12 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id DC52F3A6A87 for ; Thu, 22 Jul 2010 02:58:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 587A73236DB2; Thu, 22 Jul 2010 02:58:30 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.110] (AMontsouris-552-1-55-14.w92-140.abo.wanadoo.fr [92.140.30.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 570443228BE9; Thu, 22 Jul 2010 02:58:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Heide Clausen In-Reply-To: <4C4815B4.6020907@gmail.com> Date: Thu, 22 Jul 2010 11:58:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2310E7B5-FB7C-4EAE-9640-E2A6957CCF7D@thomasclausen.org> References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> <4C46EFC8.6020501@piuha.net> <4C48144D.4040105@gmail.com> <4C4815B4.6020907@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 09:58:13 -0000 On Jul 22, 2010, at 11:56 , Alexandru Petrescu wrote: > Le 22/07/2010 11:52, Thomas Heide Clausen a =E9crit : >>=20 >> On Jul 22, 2010, at 11:50 , Alexandru Petrescu wrote: >>=20 >>> Le 21/07/2010 15:02, Jari Arkko a =E9crit : >>>> I too would be fine with a title change to "Router Addressing >>>> Model in Ad Hoc Networks" or even "*A* Router Addressing Model in >>>> Ad Hoc Networks"... >>>=20 >>> I disagree. There are Ad-Hoc Networks which don't use that >>> Addressing Model. >>>=20 >>> The way link-local addresses are formed is specifically to work in >>> ad-hoc unplanned networks... or, this draft discourages them. >>=20 >> Alex, I think you still don't capture that we're talking about >> multi-hop networks here. >=20 > Thomas - by multi-hop networks I mean: LFN--MR--MR--LFN is a multi-hop > network using link-local addresses exclusively between MRs. >=20 I have no idea what LFN-MR-MR-LFN is.=20 This working group is concerned with configuring MANET routers, = specifically the interfaces hereof over which MANET routing protocols = operate. Thomas > I hope we capture each other's oppinion ok. >=20 > Alex >=20 >>=20 >> Thomas >>=20 >>=20 >>>=20 >>> Alex >>>=20 >>>>=20 >>>> Jari >>>>=20 >>>> _______________________________________________ Autoconf mailing >>>> list Autoconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/autoconf >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ Autoconf mailing >>> list Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >>=20 >>=20 >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Thu Jul 22 04:36:38 2010 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 F1B0E3A6957 for ; Thu, 22 Jul 2010 04:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.239, 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 0PkHItP0tyrx for ; Thu, 22 Jul 2010 04:36:36 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 86E2B3A691D for ; Thu, 22 Jul 2010 04:36:36 -0700 (PDT) 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 o6MBaq70011711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jul 2010 13:36:52 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6MBaqYs012707; Thu, 22 Jul 2010 13:36:52 +0200 (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 o6MBaox2009883; Thu, 22 Jul 2010 13:36:52 +0200 Message-ID: <4C482D52.4010306@gmail.com> Date: Thu, 22 Jul 2010 13:36:50 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Thomas Heide Clausen References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> <4C46EFC8.6020501@piuha.net> <4C48144D.4040105@gmail.com> <4C4815B4.6020907@gmail.com> <2310E7B5-FB7C-4EAE-9640-E2A6957CCF7D@thomasclausen.org> In-Reply-To: <2310E7B5-FB7C-4EAE-9640-E2A6957CCF7D@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 11:36:38 -0000 Le 22/07/2010 11:58, Thomas Heide Clausen a écrit : > > On Jul 22, 2010, at 11:56 , Alexandru Petrescu wrote: > >> Le 22/07/2010 11:52, Thomas Heide Clausen a écrit : >>> >>> On Jul 22, 2010, at 11:50 , Alexandru Petrescu wrote: >>> >>>> Le 21/07/2010 15:02, Jari Arkko a écrit : >>>>> I too would be fine with a title change to "Router Addressing >>>>> Model in Ad Hoc Networks" or even "*A* Router Addressing >>>>> Model in Ad Hoc Networks"... >>>> >>>> I disagree. There are Ad-Hoc Networks which don't use that >>>> Addressing Model. >>>> >>>> The way link-local addresses are formed is specifically to >>>> work in ad-hoc unplanned networks... or, this draft >>>> discourages them. >>> >>> Alex, I think you still don't capture that we're talking about >>> multi-hop networks here. >> >> Thomas - by multi-hop networks I mean: LFN--MR--MR--LFN is a >> multi-hop network using link-local addresses exclusively between >> MRs. >> > > I have no idea what LFN-MR-MR-LFN is. Are you interested to learn? The LFN--MR--MR--LFN topology and its multi-hop network nature is not strange to a co-Chair. There is a draft and I would like to present it during the next WG meeting - that could show that I do capture that we talk about multi-hop networks. > This working group is concerned with configuring MANET routers, > specifically the interfaces hereof over which MANET routing > protocols operate. Hmmm... this is something you would wish, right? Because the current Charter proposal stays "...independent on operation of any specific MANET routing protocol"... I currently agree with that way of using the word MANET in the current Charter proposal; but I'd suggest to remove "MANET" entirely from the Charter proposal, use instead agreed words. Alex From Chris.Dearlove@baesystems.com Thu Jul 22 07:21:45 2010 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 2CE633A6959 for ; Thu, 22 Jul 2010 07:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.037 X-Spam-Level: X-Spam-Status: No, score=-7.037 tagged_above=-999 required=5 tests=[AWL=-0.438, 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 XVhuQLPwjdZA for ; Thu, 22 Jul 2010 07:21:44 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 0DC933A676A for ; Thu, 22 Jul 2010 07:21:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,243,1278284400"; d="scan'208";a="77908709" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Jul 2010 15:22:00 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o6MEM0cc021771; Thu, 22 Jul 2010 15:22:00 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 15:22:00 +0100 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, 22 Jul 2010 15:21:59 +0100 Message-ID: In-Reply-To: <4C48145E.3020202@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) thread-index: Acspg1WsveQHy3cISB2uz/PnL9ROiQAJMALA References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <4C4706D8.5040904@piuha.net> <4C473D4C.8050504@gmail.com> <4C480A3F.3000103@gmail.com> <4C48145E.3020202@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , "Ulrich Herberg" X-OriginalArrivalTime: 22 Jul 2010 14:22:00.0441 (UTC) FILETIME=[3FA87E90:01CB29A9] Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 14:21:45 -0000 Alexandru > Earlier it says "to look over their document for errors, editorial and > otherwise." > > To me this does not restrict the spread of potential change. Clearly it does restrict changes. To of errors. -- 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 ******************************************************************** 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 Thu Jul 22 07:28:42 2010 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 B9FC83A6872 for ; Thu, 22 Jul 2010 07:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=0.223, 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 Znpo+VR0ZwMt for ; Thu, 22 Jul 2010 07:28:42 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 9B56F3A6358 for ; Thu, 22 Jul 2010 07:28:41 -0700 (PDT) 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 o6MEStem008004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jul 2010 16:28:55 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6MEStf3032149; Thu, 22 Jul 2010 16:28:55 +0200 (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 o6MESsUh003258; Thu, 22 Jul 2010 16:28:55 +0200 Message-ID: <4C4855A6.20200@gmail.com> Date: Thu, 22 Jul 2010 16:28:54 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <4C4706D8.5040904@piuha.net> <4C473D4C.8050504@gmail.com> <4C480A3F.3000103@gmail.com> <4C48145E.3020202@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] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 14:28:42 -0000 Le 22/07/2010 16:21, Dearlove, Christopher (UK) a écrit : > Alexandru >> Earlier it says "to look over their document for errors, editorial >> and > >> otherwise." >> >> To me this does not restrict the spread of potential change. > > Clearly it does restrict changes. To of errors. It says "editorial and otherwise". It does not say "restrict changes to of errors". "Otherwise" means other than editorial, in my reading. Alex > From Chris.Dearlove@baesystems.com Thu Jul 22 07:29:08 2010 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 199E03A6B5D for ; Thu, 22 Jul 2010 07:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.018 X-Spam-Level: X-Spam-Status: No, score=-7.018 tagged_above=-999 required=5 tests=[AWL=-0.419, 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 AqWAbp4qmhTJ for ; Thu, 22 Jul 2010 07:29:07 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id EEF123A6B4F for ; Thu, 22 Jul 2010 07:29:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,243,1278284400"; d="scan'208";a="77911184" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Jul 2010 15:29:24 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o6METNHj028241; Thu, 22 Jul 2010 15:29:23 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 15:29:23 +0100 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, 22 Jul 2010 15:29:22 +0100 Message-ID: In-Reply-To: <4C4815B4.6020907@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) thread-index: AcsphCNs+9hf0WvUQkqG2Z5OCyFh2QAJaBwQ References: <4C2A6BB7.1000900@piuha.net><4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> <4C46EFC8.6020501@piuha.net> <4C48144D.4040105@gmail.com> <4C4815B4.6020907@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , "Thomas Heide Clausen" X-OriginalArrivalTime: 22 Jul 2010 14:29:23.0755 (UTC) FILETIME=[47E4D7B0:01CB29AA] Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 14:29:08 -0000 Alexandru > by multi-hop networks I mean: LFN--MR--MR--LFN is a multi-hop > network using link-local addresses exclusively between MRs. Right this moment, I can't expand LFN (leaf node?). But no matter, I assume it's a non-routing endpoint. Now consider the network: LFN - MR - MR - MR - MR - MR - LFN That's a multi-hop network. Add more MRs if you like. ******************************************************************** 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 Thu Jul 22 07:30:18 2010 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 22DC13A6B6A for ; Thu, 22 Jul 2010 07:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[AWL=-0.401, 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 fphJZ9NrCLp8 for ; Thu, 22 Jul 2010 07:30:16 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 7A2FC3A6B37 for ; Thu, 22 Jul 2010 07:30:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,243,1278284400"; d="scan'208";a="77911500" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Jul 2010 15:30:29 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o6MEUTLM029225; Thu, 22 Jul 2010 15:30:29 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 15:30:29 +0100 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: Thu, 22 Jul 2010 15:30:27 +0100 Message-ID: In-Reply-To: <4C4855A6.20200@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) thread-index: Acspqjrd9AIJQqDBQBKfzEQFwurXoAAABThw References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <4C4706D8.5040904@piuha.net> <4C473D4C.8050504@gmail.com> <4C480A3F.3000103@gmail.com> <4C48145E.3020202@gmail.com> <4C4855A6.20200@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 22 Jul 2010 14:30:29.0054 (UTC) FILETIME=[6ED0ADE0:01CB29AA] Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 14:30:18 -0000 Errors otherwise than editorial, yes. But not changes otherwise than errors. --=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: 22 July 2010 15:29 To: Dearlove, Christopher (UK) Cc: Ulrich Herberg; autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF = charter proposal) *** 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. =20 Le 22/07/2010 16:21, Dearlove, Christopher (UK) a =E9crit : > Alexandru >> Earlier it says "to look over their document for errors, editorial >> and > >> otherwise." >> >> To me this does not restrict the spread of potential change. > > Clearly it does restrict changes. To of errors. It says "editorial and otherwise". It does not say "restrict changes to of errors". "Otherwise" means other than editorial, in my reading. 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 Thu Jul 22 08:05:14 2010 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 D92FF3A6BA2 for ; Thu, 22 Jul 2010 08:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.209, 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 9FKS1iM1poQb for ; Thu, 22 Jul 2010 08:05:14 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id D1A7C3A6B63 for ; Thu, 22 Jul 2010 08:05:13 -0700 (PDT) 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 o6MF5SkA001985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jul 2010 17:05:28 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6MF5ShQ008521; Thu, 22 Jul 2010 17:05:28 +0200 (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 o6MF5R4I025270; Thu, 22 Jul 2010 17:05:28 +0200 Message-ID: <4C485E37.3080808@gmail.com> Date: Thu, 22 Jul 2010 17:05:27 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4C2A6BB7.1000900@piuha.net><4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> <4C46EFC8.6020501@piuha.net> <4C48144D.4040105@gmail.com> <4C4815B4.6020907@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Thomas Heide Clausen Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 15:05:15 -0000 Le 22/07/2010 16:29, Dearlove, Christopher (UK) a écrit : > Alexandru >> by multi-hop networks I mean: LFN--MR--MR--LFN is a multi-hop >> network using link-local addresses exclusively between MRs. > > Right this moment, I can't expand LFN (leaf node?). But no matter, > I assume it's a non-routing endpoint. Right, LFN is a "Local Fixed Node", non-routing endpoint. > Now So you agree that LFN--MR--MR--LFN _is_ a multi-hop network? > consider the network: > > LFN - MR - MR - MR - MR - MR - LFN > > That's a multi-hop network. Yes, that too is a multi-hop network, I agree. Between each MR only link-local addresses are used. What do you think? Alex > Add more MRs if you like. > > ******************************************************************** > 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 Thu Jul 22 08:07:35 2010 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 4EE4E3A6B7C for ; Thu, 22 Jul 2010 08:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=0.197, 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 UkUdstPhsYr5 for ; Thu, 22 Jul 2010 08:07:34 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 291FF3A6B71 for ; Thu, 22 Jul 2010 08:07:34 -0700 (PDT) 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 o6MF7mjO003463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jul 2010 17:07:49 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6MF7m2D008972; Thu, 22 Jul 2010 17:07:48 +0200 (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 o6MF7mbp026028; Thu, 22 Jul 2010 17:07:48 +0200 Message-ID: <4C485EC4.7000908@gmail.com> Date: Thu, 22 Jul 2010 17:07:48 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <4C4706D8.5040904@piuha.net> <4C473D4C.8050504@gmail.com> <4C480A3F.3000103@gmail.com> <4C48145E.3020202@gmail.com> <4C4855A6.20200@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] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 15:07:35 -0000 Le 22/07/2010 16:30, Dearlove, Christopher (UK) a écrit : > Errors otherwise than editorial, yes. But not changes otherwise than > errors. Discouraging link-local addresses is an error other than editorial. It is an error compared to the reality of existing routing protocols. The presence of the discouraging text is an error compared to the presence of encouraging emails on this WG list. Alex From alexandru.petrescu@gmail.com Thu Jul 22 08:09:47 2010 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 110CF3A6A66 for ; Thu, 22 Jul 2010 08:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.186, 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 S8EQj2owlh-h for ; Thu, 22 Jul 2010 08:09:46 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id AF27F3A6B99 for ; Thu, 22 Jul 2010 08:09:45 -0700 (PDT) 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 o6MFA23v004864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 22 Jul 2010 17:10:02 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6MFA2Va009428 for ; Thu, 22 Jul 2010 17:10:02 +0200 (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 o6MFA14L017137 for ; Thu, 22 Jul 2010 17:10:02 +0200 Message-ID: <4C485F49.60606@gmail.com> Date: Thu, 22 Jul 2010 17:10:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: autoconf@ietf.org References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> <4C46EFC8.6020501@piuha.net> <4C48144D.4040105@gmail.com> <4C4815B4.6020907@gmail.com> <2310E7B5-FB7C-4EAE-9640-E2A6957CCF7D@thomasclausen.org> <4C482D52.4010306@gmail.com> In-Reply-To: <4C482D52.4010306@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 15:09:47 -0000 Le 22/07/2010 13:36, Alexandru Petrescu a écrit : > Le 22/07/2010 11:58, Thomas Heide Clausen a écrit : >> >> On Jul 22, 2010, at 11:56 , Alexandru Petrescu wrote: >> >>> Le 22/07/2010 11:52, Thomas Heide Clausen a écrit : >>>> >>>> On Jul 22, 2010, at 11:50 , Alexandru Petrescu wrote: >>>> >>>>> Le 21/07/2010 15:02, Jari Arkko a écrit : >>>>>> I too would be fine with a title change to "Router >>>>>> Addressing Model in Ad Hoc Networks" or even "*A* Router >>>>>> Addressing Model in Ad Hoc Networks"... >>>>> >>>>> I disagree. There are Ad-Hoc Networks which don't use that >>>>> Addressing Model. >>>>> >>>>> The way link-local addresses are formed is specifically to >>>>> work in ad-hoc unplanned networks... or, this draft >>>>> discourages them. >>>> >>>> Alex, I think you still don't capture that we're talking about >>>> multi-hop networks here. >>> >>> Thomas - by multi-hop networks I mean: LFN--MR--MR--LFN is a >>> multi-hop network using link-local addresses exclusively between >>> MRs. >>> >> >> I have no idea what LFN-MR-MR-LFN is. > > Are you interested to learn? The LFN--MR--MR--LFN topology and its > multi-hop network nature is not strange to a co-Chair. > > There is a draft and I would like to present it during the next WG > meeting - that could show that I do capture that we talk about > multi-hop networks. I have been asked privately about the draft in question - here it is: http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 "Router Advertisements for Routing between Moving Networks" I believe it adapted to AUTOCONF WG discussion as well, but not sure whether Chairs accept that I present it. I am scheduled to present it in MEXT WG too, Monday, 16h15 http://www.ietf.org/proceedings/78/agenda/mext.txt Alex > >> This working group is concerned with configuring MANET routers, >> specifically the interfaces hereof over which MANET routing >> protocols operate. > > Hmmm... this is something you would wish, right? Because the current > Charter proposal stays "...independent on operation of any specific > MANET routing protocol"... > > I currently agree with that way of using the word MANET in the > current Charter proposal; but I'd suggest to remove "MANET" entirely > from the Charter proposal, use instead agreed words. > > Alex > > _______________________________________________ Autoconf mailing > list Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From Chris.Dearlove@baesystems.com Thu Jul 22 08:41:06 2010 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 5CDA93A67D1 for ; Thu, 22 Jul 2010 08:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.984 X-Spam-Level: X-Spam-Status: No, score=-6.984 tagged_above=-999 required=5 tests=[AWL=-0.385, 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 RN53uyXufKwF for ; Thu, 22 Jul 2010 08:41:04 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 737143A67B3 for ; Thu, 22 Jul 2010 08:41:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,243,1278284400"; d="scan'208";a="77935966" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Jul 2010 16:41:21 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o6MFfKEa023060; Thu, 22 Jul 2010 16:41:21 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 16:41:20 +0100 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: Thu, 22 Jul 2010 16:41:19 +0100 Message-ID: In-Reply-To: <4C485E37.3080808@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) thread-index: Acspr1eDQfIJ6lCESguhIV1hIq/UYwAAgcTQ References: <4C2A6BB7.1000900@piuha.net><4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> <4C46EFC8.6020501@piuha.net> <4C48144D.4040105@gmail.com> <4C4815B4.6020907@gmail.com> <4C485E37.3080808@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 22 Jul 2010 15:41:20.0909 (UTC) FILETIME=[551E43D0:01CB29B4] Cc: autoconf@ietf.org, Thomas Heide Clausen Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 15:41:06 -0000 And then those link local addresses are visible beyond their local link. For some that is a problem. For others not. All of which is irrelevant to the matter in the subject line, where the decision is long (though longer would have been better) made. Re-hashing the last N years debate gets no one anywhere. --=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: 22 July 2010 16:05 To: Dearlove, Christopher (UK) Cc: Thomas Heide Clausen; autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new = AUTOCONF charter proposal) *** 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. =20 Le 22/07/2010 16:29, Dearlove, Christopher (UK) a =E9crit : > Alexandru >> by multi-hop networks I mean: LFN--MR--MR--LFN is a multi-hop >> network using link-local addresses exclusively between MRs. > > Right this moment, I can't expand LFN (leaf node?). But no matter, > I assume it's a non-routing endpoint. Right, LFN is a "Local Fixed Node", non-routing endpoint. > Now So you agree that LFN--MR--MR--LFN _is_ a multi-hop network? > consider the network: > > LFN - MR - MR - MR - MR - MR - LFN > > That's a multi-hop network. Yes, that too is a multi-hop network, I agree. Between each MR only link-local addresses are used. What do you think? Alex > Add more MRs if you like. > > ******************************************************************** > 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 teco@inf-net.nl Thu Jul 22 11:05:16 2010 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 6E5743A6850 for ; Thu, 22 Jul 2010 11:05:16 -0700 (PDT) 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 RNsIm42MeGQQ for ; Thu, 22 Jul 2010 11:05:15 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id B610C3A6878 for ; Thu, 22 Jul 2010 11:05:14 -0700 (PDT) Received: by ewy22 with SMTP id 22so3383965ewy.31 for ; Thu, 22 Jul 2010 11:05:31 -0700 (PDT) Received: by 10.213.3.70 with SMTP id 6mr421412ebm.51.1279821931037; Thu, 22 Jul 2010 11:05:31 -0700 (PDT) Received: from [192.168.2.180] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id v59sm55678266eeh.10.2010.07.22.11.05.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 22 Jul 2010 11:05:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4C485F49.60606@gmail.com> Date: Thu, 22 Jul 2010 20:05:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> <4C46EFC8.6020501@piuha.net> <4C48144D.4040105@gmail.com> <4C4815B4.6020907@gmail.com> <2310E7B5-FB7C-4EAE-9640-E2A6957CCF7D@thomasclausen.org> <4C482D52.4010306@gmail.com> <4C485F49.60606@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 18:05:16 -0000 Op 22 jul 2010, om 17:10 heeft Alexandru Petrescu het volgende = geschreven: >> There is a draft and I would like to present it during the next WG >> meeting - that could show that I do capture that we talk about >> multi-hop networks. >=20 > I have been asked privately about the draft in question - here it is: >=20 > http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 >=20 > "Router Advertisements for Routing between Moving Networks" >=20 > I believe it adapted to AUTOCONF WG discussion as well, but not sure > whether Chairs accept that I present it. >=20 > I am scheduled to present it in MEXT WG too, Monday, 16h15 > http://www.ietf.org/proceedings/78/agenda/mext.txt Isn't this draft about routing? So I doubt on relation with Autoconf. If it described an interesting addressing model for MANETs, I support a = small slot for a presentation. But after a quick look, I didn't see such. I'm opposed to single prefix sharing on multiple mobile networks (the = 2001:00xx/24 example). I guess it is a flaw.=20 Teco=20 From alexandru.petrescu@gmail.com Thu Jul 22 12:15:32 2010 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 88D3D3A67AF for ; Thu, 22 Jul 2010 12:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[AWL=0.643, 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 Ftxj0vgwDgVa for ; Thu, 22 Jul 2010 12:15:23 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id DD07F3A6850 for ; Thu, 22 Jul 2010 12:15:20 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id ED05E94016A; Thu, 22 Jul 2010 21:15:31 +0200 (CEST) Message-ID: <4C4898D2.5010804@gmail.com> Date: Thu, 22 Jul 2010 21:15:30 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <4C4706D8.5040904@piuha.net> <4C473D4C.8050504@gmail.com> <4C480A3F.3000103@gmail.com> <4C48145E.3020202@gmail.com> <4C4855A6.20200@gmail.com> <4C485EC4.7000908@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100722-1, 22/07/2010), Outbound message X-Antivirus-Status: Clean Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 19:15:32 -0000 Chris - allow me to Cc the list, thanks. A number of messages on the email list (at least 4 persons) said that link-local addresses could be used and they said they are not necessarily against them. Being against me is a typical behavior and I'm fine with it. But if one checks the emails one sees that personal opinions are tolerant with respect to link-local addresses, and not necessarily discourages them. It is the stubordness to update the draft which is not normal - a plain error. Alex Le 22/07/2010 17:41, Dearlove, Christopher (UK) a écrit : > No, it's not an error. It's a design decision. One you disagree > with, but broad consensus was against you. That does not make it an > error. > From alexandru.petrescu@gmail.com Thu Jul 22 12:19:01 2010 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 691CE3A6805 for ; Thu, 22 Jul 2010 12:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.664 X-Spam-Level: X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[AWL=0.585, 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 XKM816hvqxxt for ; Thu, 22 Jul 2010 12:19:00 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 588DC3A67AF for ; Thu, 22 Jul 2010 12:18:58 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id A6887940139; Thu, 22 Jul 2010 21:19:10 +0200 (CEST) Message-ID: <4C4899AD.4030808@gmail.com> Date: Thu, 22 Jul 2010 21:19:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4C2A6BB7.1000900@piuha.net><4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> <4C46EFC8.6020501@piuha.net> <4C48144D.4040105@gmail.com> <4C4815B4.6020907@gmail.com> <4C485E37.3080808@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100722-1, 22/07/2010), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org, Thomas Heide Clausen Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 19:19:01 -0000 Le 22/07/2010 17:41, Dearlove, Christopher (UK) a écrit : > And then those link local addresses are visible beyond their local > link. No, my point is not understood. The link-local addresses are not visible beyond their local link. When the MRs in LFN--MR--MR--MR--LFN use their link-local addresses these are not visible beyond their respective local link. > For some that is a problem. For others not. If they were visible - yes, it would have been a problem, but they are not. > All of which is irrelevant to the matter in the subject line, where > the decision is long (though longer would have been better) made. > Re-hashing the last N years debate gets no one anywhere. How about if during the last N years my message could not get read? Alex > From alexandru.petrescu@gmail.com Thu Jul 22 12:29:12 2010 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 66F123A68C8 for ; Thu, 22 Jul 2010 12:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.113 X-Spam-Level: X-Spam-Status: No, score=-1.113 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_36=0.6, J_CHICKENPOX_72=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 uaXDFJzMBsWa for ; Thu, 22 Jul 2010 12:29:11 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 18D793A68CD for ; Thu, 22 Jul 2010 12:29:09 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id C1F059400DE; Thu, 22 Jul 2010 21:29:21 +0200 (CEST) Message-ID: <4C489C10.10702@gmail.com> Date: Thu, 22 Jul 2010 21:29:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Teco Boot References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> <4C46EFC8.6020501@piuha.net> <4C48144D.4040105@gmail.com> <4C4815B4.6020907@gmail.com> <2310E7B5-FB7C-4EAE-9640-E2A6957CCF7D@thomasclausen.org> <4C482D52.4010306@gmail.com> <4C485F49.60606@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100722-1, 22/07/2010), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 22 Jul 2010 19:29:12 -0000 Le 22/07/2010 20:05, Teco Boot a écrit : > Op 22 jul 2010, om 17:10 heeft Alexandru Petrescu het volgende > geschreven: > >>> There is a draft and I would like to present it during the next >>> WG meeting - that could show that I do capture that we talk >>> about multi-hop networks. >> >> I have been asked privately about the draft in question - here it >> is: >> >> http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 >> >> >> "Router Advertisements for Routing between Moving Networks" >> >> I believe it adapted to AUTOCONF WG discussion as well, but not >> sure whether Chairs accept that I present it. >> >> I am scheduled to present it in MEXT WG too, Monday, 16h15 >> http://www.ietf.org/proceedings/78/agenda/mext.txt > > Isn't this draft about routing? YEs... depends how one interprets 'routing'. The prefixes received in the RA are installed in the routing table - that sounds as routing. However, the use of link-local addresses in order to exchange RAs is less about routing and more about addressing model. > So I doubt on relation with Autoconf. I have a similar doubt too... however the RA-based routing uses link-local addresses, and the deployment is a typical multi-hop mobile wireless network. Why would AUTOCONF addressing model forbid them? > If it described an interesting addressing model for MANETs, I support > a small slot for a presentation. But after a quick look, I didn't see > such. Well, this figure from the draft depicts an addressing model: > egress| |egress > ---- ---- ---- ---- ---- ---- > | LFN| |LFN | | MR | | MR | |LFN | |LFN | > ---- ---- ---- ---- ---- ---- > | | ingress| |ingress | | > --------------------- --------------------- > 2001:1::/24 2001:2::/24 In addition, this text from the same draft needs link-local addresses on the egress interfaces: > o When receiving the special RA from another MR, a MR parses the > packet for the link-local address of the sending MR, for the MNP > sent by that MR and for the lifetime. It then installs the > corresponding entry into the data structure mentioned earlier. These messages from the draft need to be exchanged by using link-local addresses: > MR1 MR2 MR3 > | | | > | MLD REPORT (LL1) | | > |----------------->|----------------->|multicast > | |MLD REPORT (LL3) | > |<-----------------|<-----------------| > | MLD|REPORT (LL2) | > |<-----------------|----------------->| > | | | > | Special RA | | > |----------------->|----------------->| > | (MNP1-LL1) | | > | | Special RA | > |<-----------------|<-----------------| > | | (MNP3-LL3) | > | | | > | Special|RA | > |<-----------------|----------------->| [...] > I'm opposed to single prefix sharing on multiple mobile networks > (the 2001:00xx/24 example). I guess it is a flaw. WEll, if it were a single prefix shared then yes, it would have been a flaw, I agree with you. But there actually two different prefixes in that figure: 2001:1::/24 and 2001:2::/24. Thanks for the remark, I am going to scan the draft make sure that there is no single prefix sharing on multiple mobile networks. I can say that in my implementation there is no single prefix sharing across multiple mobile networks. Alex > > Teco > > From alexandru.petrescu@gmail.com Thu Jul 22 13:17:00 2010 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 3F9363A684A for ; Thu, 22 Jul 2010 13:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.963 X-Spam-Level: X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_05=-1.11, 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 IqlN-DnIFSf6 for ; Thu, 22 Jul 2010 13:16:59 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id E5BCE3A680D for ; Thu, 22 Jul 2010 13:16:57 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id AB23E9400BA for ; Thu, 22 Jul 2010 22:17:10 +0200 (CEST) Message-ID: <4C48A745.7050608@gmail.com> Date: Thu, 22 Jul 2010 22:17:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "autoconf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100722-1, 22/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Autoconf] AUTOCONF, addresses and routing 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, 22 Jul 2010 20:17:00 -0000 Teco and I expressed a doubt about my draft being appropriated to AUTOCONF or not. (http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00) I believe route updating may need to be an aspect in AUTOCONF work - it must be coupled to the address auto-conf otherwise addresses won't be routable. Details: In general I see my draft mostly about routing because its main novelty is the insertion of entries in the routing table following reception of RA, and then route accordingly. Another point is that I believe, in the future, AUTOCONF work will hit on the necessity to couple the address auto-configuration mechanism with a means to update routing. Why am I saying this? Because it is the case for DHCP, for example. If DHCP Prefix Delegation is used to assign a prefix to a MR, then it would work ok as is between Server and MR. However, (some months ago it was the case), it is impossible to use DHCP Relays - in practice it breaks. Or, the topology DHCPSserver--Relay--MR is of paramount importance in a multi-hop wireless mobile network. Why DHCP Prefix Delegation breaks on Relays? Because Relay does not insert a routing table entry with respect to the prefix it just delegated. To solve it, one would require the Relay to insert an entry in the routing table. This is one kind of solution. I believe with other routing protocols (OSPF, more) it is also the case: whenever an address is assigned across hops the routing table entries must be updated. And this is not specified today - address auto-configuration is decoupled from route updating, hence routing breaks. This is why I believe route updating may be an aspect in AUTOCONF work - it must be coupled to the address auto-conf otherwise it won't work. (Too: an important point in the draft is it relies on link-local addresses between the MRs, without which it wouldn't work.) Alex From alexandru.petrescu@gmail.com Thu Jul 22 14:01:24 2010 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 C475D3A6981 for ; Thu, 22 Jul 2010 14:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_05=-1.11, 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 fEnCW7ww5EbP for ; Thu, 22 Jul 2010 14:01:24 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id B3DD73A6958 for ; Thu, 22 Jul 2010 14:01:22 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 7F27F940119 for ; Thu, 22 Jul 2010 23:01:35 +0200 (CEST) Message-ID: <4C48B1AE.2030408@gmail.com> Date: Thu, 22 Jul 2010 23:01:34 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "autoconf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100722-1, 22/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Autoconf] Another addressing model for AUTOCONF 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, 22 Jul 2010 21:01:24 -0000 Addressing model we use, pdf 300Kb: http://dl.free.fr/m95j1Km7a (the username is left empty and password is 'password', without quotes. File stays there for 30 days.) Teco asked whether my draft contains an addressing model... true - it doesn't show so obviously (http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00). I said that there is an addressing model in this figure of the draft: > egress| |egress > ---- ---- ---- ---- ---- ---- > | LFN| |LFN | | MR | | MR | |LFN | |LFN | > ---- ---- ---- ---- ---- ---- > | | ingress| |ingress | | > --------------------- --------------------- > 2001:1::/24 2001:2::/24 ThomasC and Chris also expressed doubts with respect to LFN--MR--MR--LFN topology and link-local addresses; let me explain further. We are using this addressing model on several moving networks. See the pdf at the beginning of this email. They show MR-to-MR with a single addressing scheme, then with a double addressing scheme; (double is necessary for our plan.) And then a slide shows MR-to-MR-to-MR addressing model. There are some scalability remarks and a route propagation model (pencil and paper). The mechanism has been prototyped and demoed since about one year now, on three Mobile Routers and a bunch of LFNs, which shows it may work. We have great plans for demoing on vehicles. This is an addressing model we consider strongly. It needs later to auto-configure some prefixes, because currently MNPs are pre-configured in each moving network (this is the case in some deployments). This addressing model is important to us, and uses link-local addresses. Alex From henning.rogge@fkie.fraunhofer.de Thu Jul 22 22:23:51 2010 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 736FA3A6860 for ; Thu, 22 Jul 2010 22:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[AWL=-2.042, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] 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 h+qjeiVdB6p8 for ; Thu, 22 Jul 2010 22:23:49 -0700 (PDT) Received: from mailguard.fgan.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by core3.amsl.com (Postfix) with ESMTP id 7C3A83A67FE for ; Thu, 22 Jul 2010 22:23:49 -0700 (PDT) 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 1OcAjq-0007dv-24; Fri, 23 Jul 2010 07:24:02 +0200 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 1OcAjp-0000I6-PY; Fri, 23 Jul 2010 07:24:01 +0200 From: Henning Rogge To: autoconf@ietf.org Date: Fri, 23 Jul 2010 07:23:53 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-23-generic; KDE/4.4.5; i686; ; ) References: <4C2A6BB7.1000900@piuha.net> <4C4899AD.4030808@gmail.com> In-Reply-To: <4C4899AD.4030808@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1787578.9viJ79y6m1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201007230723.58638.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11418/Fri Jul 23 06:43:37 2010) by mailguard.fgan.de X-Scan-Signature: fe63cde163a9813fbfae5d53d3252e1e Cc: "Dearlove, Christopher \(UK\)" , Thomas Heide Clausen Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 05:23:52 -0000 --nextPart1787578.9viJ79y6m1 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Thu July 22 2010 21:19:09 Alexandru Petrescu wrote: > Le 22/07/2010 17:41, Dearlove, Christopher (UK) a =E9crit : > > And then those link local addresses are visible beyond their local > > link. >=20 > No, my point is not understood. The link-local addresses are not > visible beyond their local link. >=20 > When the MRs in LFN--MR--MR--MR--LFN use their link-local addresses > these are not visible beyond their respective local link. You just have shown that you don't understand what a wireless MANET (with=20 multihop links, without most people would not consider it a MANET) is. if each of the MRs use a wireless interface, the linklocals WILL BE VISIBLE= =20 outside their direct link. There is no way to prevent this. Because multipl= e=20 links share interfaces in a non-transitive manner (see=20 http://en.wikipedia.org/wiki/Transitive_relation). 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-961, 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 --nextPart1787578.9viJ79y6m1 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) iEYEABECAAYFAkxJJ2kACgkQRIfGfFXsz+DufQCfchCadTQfe4Peb5TJZVKk9k4i J0QAn2RQHxKTTKuxeIBSnoJW4yhR5PgU =87U3 -----END PGP SIGNATURE----- --nextPart1787578.9viJ79y6m1-- From alexandru.petrescu@gmail.com Fri Jul 23 00:42:53 2010 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 BB44E3A697A for ; Fri, 23 Jul 2010 00:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.166, 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 KdXekTGt-59P for ; Fri, 23 Jul 2010 00:42:52 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 214E23A6B04 for ; Fri, 23 Jul 2010 00:42:51 -0700 (PDT) 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 o6N7h3FO004338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 09:43:03 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6N7h3rW030650; Fri, 23 Jul 2010 09:43:03 +0200 (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 o6N7h2N4007701; Fri, 23 Jul 2010 09:43:02 +0200 Message-ID: <4C494806.5060609@gmail.com> Date: Fri, 23 Jul 2010 09:43:02 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Henning Rogge References: <4C2A6BB7.1000900@piuha.net> <4C4899AD.4030808@gmail.com> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <201007230723.58638.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] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 07:42:53 -0000 Le 23/07/2010 07:23, Henning Rogge a écrit : > On Thu July 22 2010 21:19:09 Alexandru Petrescu wrote: >> Le 22/07/2010 17:41, Dearlove, Christopher (UK) a écrit : >>> And then those link local addresses are visible beyond their >>> local link. >> >> No, my point is not understood. The link-local addresses are not >> visible beyond their local link. >> >> When the MRs in LFN--MR--MR--MR--LFN use their link-local >> addresses these are not visible beyond their respective local >> link. > > You just have shown that you don't understand what a wireless MANET > (with multihop links, without most people would not consider it a > MANET) is. Ulrich, I do make efforts to understand what you understand. PArt of this effort is to refrain the temptation of claiming you don't understand what I don't understand. > if each of the MRs use a wireless interface, the linklocals WILL BE > VISIBLE outside their direct link. Well, the link local addresses will not be visible outside their direct link, because the different links are on different ESSIDs and moreover on different channels. Using wireshark on IP packets on these different links shows that the link local addressess are not visible from one link to another. When you say visible - what do you mean? I mean "not visible" to the IP stack. > There is no way to prevent this. YEs there is - use different ESSIDs and, for more insurance, use different channels and different keys. That is for WiFi. For other technologies (3G+, LTE, Bluetooth) there are other link layer means such as pdp context and more. > Because multiple links share interfaces in a non-transitive manner Well yes, at link layer level. But link layers have their protocols which help build understandable links to the IP stack. > (see http://en.wikipedia.org/wiki/Transitive_relation). Uh? Alex > > Henning Rogge > From thomas@thomasclausen.org Fri Jul 23 00:47:38 2010 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 709B03A6B08 for ; Fri, 23 Jul 2010 00:47:38 -0700 (PDT) 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 EBA5FnWeDhbq for ; Fri, 23 Jul 2010 00:47:15 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 3C5753A6B11 for ; Fri, 23 Jul 2010 00:47:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 8149F3228BE1; Fri, 23 Jul 2010 00:47:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 6BA233228050; Fri, 23 Jul 2010 00:47:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Heide Clausen In-Reply-To: <4C494806.5060609@gmail.com> Date: Fri, 23 Jul 2010 09:47:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1D0FFC66-A4C6-4E7E-A7C5-13156A9B37A3@thomasclausen.org> References: <4C2A6BB7.1000900@piuha.net> <4C4899AD.4030808@gmail.com> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1078) Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 07:47:38 -0000 On Jul 23, 2010, at 09:43 , Alexandru Petrescu wrote: > Le 23/07/2010 07:23, Henning Rogge a =E9crit : >> On Thu July 22 2010 21:19:09 Alexandru Petrescu wrote: >>> Le 22/07/2010 17:41, Dearlove, Christopher (UK) a =E9crit : >>>> And then those link local addresses are visible beyond their >>>> local link. >>>=20 >>> No, my point is not understood. The link-local addresses are not >>> visible beyond their local link. >>>=20 >>> When the MRs in LFN--MR--MR--MR--LFN use their link-local >>> addresses these are not visible beyond their respective local >>> link. >>=20 >> You just have shown that you don't understand what a wireless MANET >> (with multihop links, without most people would not consider it a >> MANET) is. >=20 > Ulrich, I do make efforts to understand what you understand. PArt of > this effort is to refrain the temptation of claiming you don't = understand what I don't understand. >=20 >> if each of the MRs use a wireless interface, the linklocals WILL BE >> VISIBLE outside their direct link. >=20 > Well, the link local addresses will not be visible outside their = direct > link, because the different links are on different ESSIDs and moreover > on different channels. That is the crux of your misunderstanding. They may, in your case, be -- = in most MANET cases, they're not. Thomas > Using wireshark on IP packets on these different > links shows that the link local addressess are not visible from one = link > to another. >=20 > When you say visible - what do you mean? I mean "not visible" to the = IP > stack. >=20 >> There is no way to prevent this. >=20 > YEs there is - use different ESSIDs and, for more insurance, use > different channels and different keys. That is for WiFi. For other > technologies (3G+, LTE, Bluetooth) there are other link layer means = such > as pdp context and more. >=20 >> Because multiple links share interfaces in a non-transitive manner >=20 > Well yes, at link layer level. But link layers have their protocols > which help build understandable links to the IP stack. >=20 >> (see http://en.wikipedia.org/wiki/Transitive_relation). >=20 > Uh? >=20 > Alex >=20 >>=20 >> Henning Rogge >>=20 >=20 >=20 From henning.rogge@fkie.fraunhofer.de Fri Jul 23 00:51:40 2010 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 5D4593A67B4 for ; Fri, 23 Jul 2010 00:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=-1.906, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] 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 04+OW6mrL-cC for ; Fri, 23 Jul 2010 00:51:39 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by core3.amsl.com (Postfix) with ESMTP id 0297B3A698C for ; Fri, 23 Jul 2010 00:51:39 -0700 (PDT) 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 1OcD2w-0003hE-SR; Fri, 23 Jul 2010 09:51:54 +0200 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 1OcD2w-0000hg-JZ; Fri, 23 Jul 2010 09:51:54 +0200 From: Henning Rogge To: Alexandru Petrescu Date: Fri, 23 Jul 2010 09:51:45 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-23-generic; KDE/4.4.5; i686; ; ) References: <4C2A6BB7.1000900@piuha.net> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com> In-Reply-To: <4C494806.5060609@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7952066.PmpPdymB7o"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201007230951.51192.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11419/Fri Jul 23 07:19:40 2010) by mailguard.fgan.de X-Scan-Signature: 4db47a2f8fc8763431e9cacb4f9c6041 Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" , Thomas Heide Clausen Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 07:51:40 -0000 --nextPart7952066.PmpPdymB7o Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Fri July 23 2010 09:43:02 Alexandru Petrescu wrote: > > if each of the MRs use a wireless interface, the linklocals WILL BE > > VISIBLE outside their direct link. >=20 > Well, the link local addresses will not be visible outside their direct > link, because the different links are on different ESSIDs and moreover > on different channels. Using wireshark on IP packets on these different > links shows that the link local addressess are not visible from one link > to another. This would only work with preplanned links, because otherwise you would hav= e=20 trouble to do neighborhood detection. How do you detect new nodes coming in= to=20 range if they cannot announce their presence with a broadcast, because they= =20 got no unique ESSID to their neighbors ? MANET routing protocols are specially designed for the case of unplanned=20 networks. You have a single shared medium which the routing protocol use fo= r=20 it's work, to do neighborhood/link detection. If you push this down to link layer, you just move the whole problem down o= ne=20 layer, because you need unique addresses on the link layer to do neighborho= od=20 detection and link establishment. If you already have a unique link-layer address, just use it to generate a= =20 unique linklocal-IP. 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-961, 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 --nextPart7952066.PmpPdymB7o 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) iEYEABECAAYFAkxJShIACgkQRIfGfFXsz+D4ZgCfZk11xnCuSN9Sam8KrviFTYdy pCIAnilisSZS7IOYIUVK50apU25z6CdG =rmY8 -----END PGP SIGNATURE----- --nextPart7952066.PmpPdymB7o-- From ulrich@herberg.name Fri Jul 23 00:53:04 2010 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 D15CC3A67E3 for ; Fri, 23 Jul 2010 00:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 yQHv0JO-pbRA for ; Fri, 23 Jul 2010 00:53:03 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id D91A73A67B4 for ; Fri, 23 Jul 2010 00:53:02 -0700 (PDT) Received: by bwz7 with SMTP id 7so1614999bwz.31 for ; Fri, 23 Jul 2010 00:53:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.103.136 with SMTP id k8mr2330397bko.37.1279871600177; Fri, 23 Jul 2010 00:53:20 -0700 (PDT) Received: by 10.204.163.5 with HTTP; Fri, 23 Jul 2010 00:53:20 -0700 (PDT) In-Reply-To: <4C494806.5060609@gmail.com> References: <4C2A6BB7.1000900@piuha.net> <4C4899AD.4030808@gmail.com> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com> Date: Fri, 23 Jul 2010 09:53:20 +0200 Message-ID: From: Ulrich Herberg To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=0016e6d624f9163167048c0954cf Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" , Thomas Heide Clausen Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 07:53:04 -0000 --0016e6d624f9163167048c0954cf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex, On Fri, Jul 23, 2010 at 9:43 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Le 23/07/2010 07:23, Henning Rogge a =E9crit : > > On Thu July 22 2010 21:19:09 Alexandru Petrescu wrote: >> >>> Le 22/07/2010 17:41, Dearlove, Christopher (UK) a =E9crit : >>> >>>> And then those link local addresses are visible beyond their >>>> local link. >>>> >>> >>> No, my point is not understood. The link-local addresses are not >>> visible beyond their local link. >>> >>> When the MRs in LFN--MR--MR--MR--LFN use their link-local >>> addresses these are not visible beyond their respective local >>> link. >>> >> >> You just have shown that you don't understand what a wireless MANET >> (with multihop links, without most people would not consider it a >> MANET) is. >> > > Ulrich, I do make efforts to understand what you understand. PArt of > this effort is to refrain the temptation of claiming you don't understand > what I don't understand. It was Henning, who said that, not me :-) (even though in this particular example, I agree with him). > > > if each of the MRs use a wireless interface, the linklocals WILL BE >> VISIBLE outside their direct link. >> > > Well, the link local addresses will not be visible outside their direct > link, because the different links are on different ESSIDs and moreover > on different channels. Using wireshark on IP packets on these different > links shows that the link local addressess are not visible from one link > to another. > Yes, but this is not the general case of a MANET. This is your very particular lab setting, which will only work in well-known, predefined constraints. > > When you say visible - what do you mean? I mean "not visible" to the IP > stack. > > > There is no way to prevent this. >> > > YEs there is - use different ESSIDs and, for more insurance, use > different channels and different keys. That is for WiFi. For other > technologies (3G+, LTE, Bluetooth) there are other link layer means such > as pdp context and more. > Then tell me, how Henning should manage the FunkFeuer Netzwerk. Using a different channel and ESSID for every link? And even worse, consider a setting where routers actually move in an unknown patterns (i.e. are "mobile"); how would you update ESSIDs and channels? > > > > Because multiple links share interfaces in a non-transitive manner >> > > Well yes, at link layer level. But link layers have their protocols > which help build understandable links to the IP stack. Yes, but then you are wrong in the MANET WG, because we are not talking about L2 meshes (like 802.11s). We are talking about multihop communication on L3. > > > (see http://en.wikipedia.org/wiki/Transitive_relation). >> > > Uh? > > Alex > > >> Henning Rogge >> >> > Ulrich --0016e6d624f9163167048c0954cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex,

On Fri, Jul 23, 2010 at 9:43 AM, Al= exandru Petrescu <alexandru.petrescu@gmail.com> wrote:
Le 23/07/2010 07:23, Henning Rogge a =E9crit :

On Thu July 22 2010 21:19:09 Alexandru Petrescu wrote:
Le 22/07/2010 17:41, Dearlove, Christopher (UK) a =E9crit :
And then those link local addresses are visible beyond their
local link.

No, my point is not understood. =A0The link-local addresses are not
visible beyond their local link.

When the MRs in LFN--MR--MR--MR--LFN use their link-local
addresses these are not visible beyond their respective local
link.

You just have shown that you don't understand what a wireless MANET
(with multihop links, without most people would not consider it a
MANET) is.

Ulrich, I do make efforts to understand what you understand. =A0PArt of
this effort is to refrain the temptation of claiming you don't understa= nd what I don't understand.


It was Henning, wh= o said that, not me :-) (even though in this particular example, I agree wi= th him).
=A0


if each of the MRs use a wireless interface, the linklocals WILL BE
VISIBLE outside their direct link.

Well, the link local addresses will not be visible outside their direct
link, because the different links are on different ESSIDs and moreover
on different channels. =A0Using wireshark on IP packets on these different<= br> links shows that the link local addressess are not visible from one link to another.

Yes, but this is not the general case = of a MANET. This is your very particular lab setting, which will only work = in well-known, predefined constraints.
=A0

When you say visible - what do you mean? =A0I mean "not visible" = to the IP
stack.


There is no way to prevent this.

YEs there is - use different ESSIDs and, for more insurance, use
different channels and different keys. =A0That is for WiFi. =A0For other technologies (3G+, LTE, Bluetooth) there are other link layer means such as pdp context and more.

Then tell me, how Henning= should manage the FunkFeuer Netzwerk. Using a different channel and ESSID = for every link? And even worse, consider a setting where routers actually m= ove in an unknown patterns (i.e. are "mobile"); how would you upd= ate ESSIDs and channels?

=A0

=A0

Because multiple links share interfaces in a non-transitive manner

Well yes, at link layer level. =A0But link layers have their protocols
which help build understandable links to the IP stack.
Yes, but then you are wrong in the MANET WG, because we are not talking ab= out L2 meshes (like 802.11s). We are talking about multihop communication o= n L3.
=A0
Uh?

Alex


Henning Rogge




Ulrich
--0016e6d624f9163167048c0954cf-- From alexandru.petrescu@gmail.com Fri Jul 23 01:00:33 2010 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 381B53A67F1 for ; Fri, 23 Jul 2010 01:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.158, 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 Ml2cVwIxoBfD for ; Fri, 23 Jul 2010 01:00:32 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id C0EB43A67DA for ; Fri, 23 Jul 2010 01:00:31 -0700 (PDT) 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 o6N80gs5012605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 10:00:42 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6N80gqY003358; Fri, 23 Jul 2010 10:00:42 +0200 (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 o6N80gqp025575; Fri, 23 Jul 2010 10:00:42 +0200 Message-ID: <4C494C29.5020004@gmail.com> Date: Fri, 23 Jul 2010 10:00:41 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Thomas Heide Clausen References: <4C2A6BB7.1000900@piuha.net> <4C4899AD.4030808@gmail.com> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com> <1D0FFC66-A4C6-4E7E-A7C5-13156A9B37A3@thomasclausen.org> In-Reply-To: <1D0FFC66-A4C6-4E7E-A7C5-13156A9B37A3@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] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 08:00:33 -0000 Le 23/07/2010 09:47, Thomas Heide Clausen a écrit : > > On Jul 23, 2010, at 09:43 , Alexandru Petrescu wrote: > >> Le 23/07/2010 07:23, Henning Rogge a écrit : >>> On Thu July 22 2010 21:19:09 Alexandru Petrescu wrote: >>>> Le 22/07/2010 17:41, Dearlove, Christopher (UK) a écrit : >>>>> And then those link local addresses are visible beyond their >>>>> local link. >>>> >>>> No, my point is not understood. The link-local addresses are >>>> not visible beyond their local link. >>>> >>>> When the MRs in LFN--MR--MR--MR--LFN use their link-local >>>> addresses these are not visible beyond their respective local >>>> link. >>> >>> You just have shown that you don't understand what a wireless >>> MANET (with multihop links, without most people would not >>> consider it a MANET) is. >> >> Ulrich, I do make efforts to understand what you understand. PArt >> of this effort is to refrain the temptation of claiming you don't >> understand what I don't understand. >> >>> if each of the MRs use a wireless interface, the linklocals WILL >>> BE VISIBLE outside their direct link. >> >> Well, the link local addresses will not be visible outside their >> direct link, because the different links are on different ESSIDs >> and moreover on different channels. > > That is the crux of your misunderstanding. They may, in your case, be > -- in most MANET cases, they're not. Thomas - help me remove this crux. Could we make an AUTOCONF non-MANET case where the link local addresses are not visible across different wireless links. Otherwise, could we be stating in the Charter that AUTOCONF deals _only_ with MANET cases where link local addresses are visible in all radio ranges, links undefined, no WiFi ESSID nor similar. Which by your definition is 'most MANET cases'. You mentioned it several times - it deserves being in the Charter. Both ways would help me a lot: in the first I stay in the group, present at meeting. In the second I go away. Alex > > Thomas > > >> Using wireshark on IP packets on these different links shows that >> the link local addressess are not visible from one link to >> another. >> >> When you say visible - what do you mean? I mean "not visible" to >> the IP stack. >> >>> There is no way to prevent this. >> >> YEs there is - use different ESSIDs and, for more insurance, use >> different channels and different keys. That is for WiFi. For >> other technologies (3G+, LTE, Bluetooth) there are other link layer >> means such as pdp context and more. >> >>> Because multiple links share interfaces in a non-transitive >>> manner >> >> Well yes, at link layer level. But link layers have their >> protocols which help build understandable links to the IP stack. >> >>> (see http://en.wikipedia.org/wiki/Transitive_relation). >> >> Uh? >> >> Alex >> >>> >>> Henning Rogge >>> >> >> > > From henning.rogge@fkie.fraunhofer.de Fri Jul 23 01:05:42 2010 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 88CD43A698F for ; Fri, 23 Jul 2010 01:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[AWL=-1.787, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] 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 dDHTgqKqBz2s for ; Fri, 23 Jul 2010 01:05:37 -0700 (PDT) Received: from mailguard.fgan.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by core3.amsl.com (Postfix) with ESMTP id 280353A6841 for ; Fri, 23 Jul 2010 01:05:37 -0700 (PDT) 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 1OcDGR-0008NZ-I6; Fri, 23 Jul 2010 10:05:51 +0200 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 1OcDGR-0000ku-9Z; Fri, 23 Jul 2010 10:05:51 +0200 From: Henning Rogge To: Alexandru Petrescu Date: Fri, 23 Jul 2010 10:05:22 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-23-generic; KDE/4.4.5; i686; ; ) References: <4C2A6BB7.1000900@piuha.net> <1D0FFC66-A4C6-4E7E-A7C5-13156A9B37A3@thomasclausen.org> <4C494C29.5020004@gmail.com> In-Reply-To: <4C494C29.5020004@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10160270.qID9i3Vmy0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201007231005.48365.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11419/Fri Jul 23 07:19:40 2010) by mailguard.fgan.de X-Scan-Signature: 2577de289e0484eccb48b316b05ab48b Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" , Thomas Heide Clausen Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 08:05:42 -0000 --nextPart10160270.qID9i3Vmy0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Fri July 23 2010 10:00:41 Alexandru Petrescu wrote: > Could we make an AUTOCONF non-MANET case where the link local addresses > are not visible across different wireless links. >=20 > Otherwise, could we be stating in the Charter that AUTOCONF deals _only_ > with MANET cases where link local addresses are visible in all radio > ranges, links undefined, no WiFi ESSID nor similar. Which by your > definition is 'most MANET cases'. You mentioned it several times - it > deserves being in the Charter. >=20 > Both ways would help me a lot: in the first I stay in the group, present > at meeting. In the second I go away. Quote from the charter of the autoconf WG: 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. "ad hoc networks" is the ANET part of 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-961, 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 --nextPart10160270.qID9i3Vmy0 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) iEYEABECAAYFAkxJTUMACgkQRIfGfFXsz+Dd6wCdGTc3ojwO/9F6BoLCsu2LLhGJ wtoAoKMrSBFt+XdrSb4YH3GvyTGWeRii =c6MS -----END PGP SIGNATURE----- --nextPart10160270.qID9i3Vmy0-- From alexandru.petrescu@gmail.com Fri Jul 23 01:11:17 2010 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 645D43A696C for ; Fri, 23 Jul 2010 01:11:16 -0700 (PDT) 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 HeIsbJKIvzEH for ; Fri, 23 Jul 2010 01:11:14 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 775FA3A67B4 for ; Fri, 23 Jul 2010 01:11:14 -0700 (PDT) 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 o6N8BRrP004785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 10:11:27 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6N8BQUh007419; Fri, 23 Jul 2010 10:11:26 +0200 (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 o6N8BQcB030621; Fri, 23 Jul 2010 10:11:26 +0200 Message-ID: <4C494EAE.9000600@gmail.com> Date: Fri, 23 Jul 2010 10:11:26 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Henning Rogge References: <4C2A6BB7.1000900@piuha.net> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com> <201007230951.51192.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <201007230951.51192.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] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 08:11:17 -0000 Le 23/07/2010 09:51, Henning Rogge a écrit : > On Fri July 23 2010 09:43:02 Alexandru Petrescu wrote: >>> if each of the MRs use a wireless interface, the linklocals WILL >>> BE VISIBLE outside their direct link. >> >> Well, the link local addresses will not be visible outside their >> direct link, because the different links are on different ESSIDs >> and moreover on different channels. Using wireshark on IP packets >> on these different links shows that the link local addressess are >> not visible from one link to another. > > This would only work with preplanned links, Most deployments have a high degree of planning. > because otherwise you would have trouble to do neighborhood > detection. How do you detect new nodes coming into range if they > cannot announce their presence with a broadcast, because they got no > unique ESSID to their neighbors ? Well good question - and I have tried. The difficult thing is the first detection - the "wifi scan" phase; once the drivers have their data set up then re-detection is very fast, in the order of tens of milliseconds. We could use that to signal between two approaching vehicles. More specifically, on WiFi, a beacon is sent periodically, but there are also periodic requests replied with a beacon. These help a lot to detect presence of a neighbor previously learned, and fast. > MANET routing protocols are specially designed for the case of > unplanned networks. You have a single shared medium which the routing > protocol use for it's work, to do neighborhood/link detection. Well very good. Is there a case where wireless multi-hop networks are possible _without_ MANET routing protocols? I believe yes, and I prototyped and demo. Besides, there exist deployments where even though the MRs are mobile they stay relatively fixed with respect to each other, in some very simple topology: truck convoy, wagons in a train, etc. These things stay formed for long hours and reform right after. These things don't need the power of MANET routing protocols because there are never loops formed at link layer, the topology is really simple. > If you push this down to link layer, you just move the whole problem > down one layer, because you need unique addresses on the link layer > to do neighborhood detection and link establishment. WEll yes... I tend to agree. However, one would avoid to bring existing link layer mechanisms up to the IP stack too. These link layer mechanisms are there and work very well in their domain. The IP stack is not fast enough on the CPU to work at vehicular speeds, interruptable by some GUI or heavy TCP. The link layer driver executing on a dedicated chipset is much more reliable for these kinds of movements. > If you already have a unique link-layer address, just use it to > generate a unique linklocal-IP. Hmmm... right, that's how link local addresses are generated. Alex > > Henning Rogge > From thomas@thomasclausen.org Fri Jul 23 01:12:03 2010 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 7AA5B3A6B1C for ; Fri, 23 Jul 2010 01:12:03 -0700 (PDT) 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 CWtigWIO2PSf for ; Fri, 23 Jul 2010 01:12:02 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id F25D83A69B3 for ; Fri, 23 Jul 2010 01:12:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 4C2533236DB3; Fri, 23 Jul 2010 01:12:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 379983228050; Fri, 23 Jul 2010 01:12:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Heide Clausen In-Reply-To: <4C494C29.5020004@gmail.com> Date: Fri, 23 Jul 2010 10:12:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1770ECCA-C51B-42C4-AB7C-A59424E1B01D@thomasclausen.org> References: <4C2A6BB7.1000900@piuha.net> <4C4899AD.4030808@gmail.com> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com> <1D0FFC66-A4C6-4E7E-A7C5-13156A9B37A3@thomasclausen.org> <4C494C29.5020004@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1078) Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 08:12:03 -0000 On Jul 23, 2010, at 10:00 , Alexandru Petrescu wrote: > Le 23/07/2010 09:47, Thomas Heide Clausen a =E9crit : >>=20 >> On Jul 23, 2010, at 09:43 , Alexandru Petrescu wrote: >>=20 >>> Le 23/07/2010 07:23, Henning Rogge a =E9crit : >>>> On Thu July 22 2010 21:19:09 Alexandru Petrescu wrote: >>>>> Le 22/07/2010 17:41, Dearlove, Christopher (UK) a =E9crit : >>>>>> And then those link local addresses are visible beyond their >>>>>> local link. >>>>>=20 >>>>> No, my point is not understood. The link-local addresses are >>>>> not visible beyond their local link. >>>>>=20 >>>>> When the MRs in LFN--MR--MR--MR--LFN use their link-local >>>>> addresses these are not visible beyond their respective local >>>>> link. >>>>=20 >>>> You just have shown that you don't understand what a wireless >>>> MANET (with multihop links, without most people would not >>>> consider it a MANET) is. >>>=20 >>> Ulrich, I do make efforts to understand what you understand. PArt >>> of this effort is to refrain the temptation of claiming you don't >>> understand what I don't understand. >>>=20 >>>> if each of the MRs use a wireless interface, the linklocals WILL >>>> BE VISIBLE outside their direct link. >>>=20 >>> Well, the link local addresses will not be visible outside their >>> direct link, because the different links are on different ESSIDs >>> and moreover on different channels. >>=20 >> That is the crux of your misunderstanding. They may, in your case, be >> -- in most MANET cases, they're not. >=20 > Thomas - help me remove this crux. >=20 > Could we make an AUTOCONF non-MANET case where the link local = addresses > are not visible across different wireless links. No, I don't see how we could make a valid case like that.=20 In part, because [autoconf] targets MANETs, trying to make a "non-MANET = case" would be quite out of scope. > Otherwise, could we be stating in the Charter that AUTOCONF deals = _only_ > with MANET cases where link local addresses are visible in all radio > ranges, links undefined, no WiFi ESSID nor similar. Which by your > definition is 'most MANET cases'. The reference to 2501 should make it clear that we were talking about = MANETs, and so should be familiar with what that entails -- which is = (among other things) that the above "link" characteristics are true (and = I just see Henning chipped in, and want to +1 to his remark as well). = But, I would guess that if adding the keyword "MANET" to the charter is = what this discussion is about, then that can be done too. Thomas > You mentioned it several times - it > deserves being in the Charter. Both ways would help me a lot: in the = first I stay in the group, present > at meeting. In the second I go away. >=20 > Alex >=20 >>=20 >> Thomas >>=20 >>=20 >>> Using wireshark on IP packets on these different links shows that >>> the link local addressess are not visible from one link to >>> another. >>>=20 >>> When you say visible - what do you mean? I mean "not visible" to >>> the IP stack. >>>=20 >>>> There is no way to prevent this. >>>=20 >>> YEs there is - use different ESSIDs and, for more insurance, use >>> different channels and different keys. That is for WiFi. For >>> other technologies (3G+, LTE, Bluetooth) there are other link layer >>> means such as pdp context and more. >>>=20 >>>> Because multiple links share interfaces in a non-transitive >>>> manner >>>=20 >>> Well yes, at link layer level. But link layers have their >>> protocols which help build understandable links to the IP stack. >>>=20 >>>> (see http://en.wikipedia.org/wiki/Transitive_relation). >>>=20 >>> Uh? >>>=20 >>> Alex >>>=20 >>>>=20 >>>> Henning Rogge >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From thomas@thomasclausen.org Fri Jul 23 01:15:19 2010 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 480113A698C for ; Fri, 23 Jul 2010 01:15:19 -0700 (PDT) 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 R0xduqVySbsh for ; Fri, 23 Jul 2010 01:15:17 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id DC7EB3A6841 for ; Fri, 23 Jul 2010 01:15:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 37F903236DB1; Fri, 23 Jul 2010 01:15:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 1CD923228050; Fri, 23 Jul 2010 01:15:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Heide Clausen In-Reply-To: <4C494EAE.9000600@gmail.com> Date: Fri, 23 Jul 2010 10:15:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <01937057-07D5-44BF-BB89-CF86EB08858C@thomasclausen.org> References: <4C2A6BB7.1000900@piuha.net> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com> <201007230951.51192.henning.rogge@fkie.fraunhofer.de> <4C494EAE.9000600@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1078) Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 08:15:19 -0000 On Jul 23, 2010, at 10:11 , Alexandru Petrescu wrote: > Le 23/07/2010 09:51, Henning Rogge a =E9crit : >> On Fri July 23 2010 09:43:02 Alexandru Petrescu wrote: >>>> if each of the MRs use a wireless interface, the linklocals WILL >>>> BE VISIBLE outside their direct link. >>>=20 >>> Well, the link local addresses will not be visible outside their >>> direct link, because the different links are on different ESSIDs >>> and moreover on different channels. Using wireshark on IP packets >>> on these different links shows that the link local addressess are >>> not visible from one link to another. >>=20 >> This would only work with preplanned links, >=20 > Most deployments have a high degree of planning. Then, they're (by definition) not ad-hoc networks. >> because otherwise you would have trouble to do neighborhood >> detection. How do you detect new nodes coming into range if they >> cannot announce their presence with a broadcast, because they got no >> unique ESSID to their neighbors ? >=20 > Well good question - and I have tried. The difficult thing is the = first > detection - the "wifi scan" phase; once the drivers have their data = set > up then re-detection is very fast, in the order of tens of = milliseconds. > We could use that to signal between two approaching vehicles. >=20 > More specifically, on WiFi, a beacon is sent periodically, but there = are > also periodic requests replied with a beacon. These help a lot to > detect presence of a neighbor previously learned, and fast. >=20 >> MANET routing protocols are specially designed for the case of >> unplanned networks. You have a single shared medium which the routing >> protocol use for it's work, to do neighborhood/link detection. >=20 > Well very good. Is there a case where wireless multi-hop networks are > possible _without_ MANET routing protocols? I believe yes, and I > prototyped and demo. Very well, but then that's not a MANET. > Besides, there exist deployments where even though the MRs are mobile > they stay relatively fixed with respect to each other, in some very > simple topology: truck convoy, wagons in a train, etc. These things > stay formed for long hours and reform right after. These things don't > need the power of MANET routing protocols because there are never = loops > formed at link layer, the topology is really simple. Very well, but then that's not a MANET. Alex, can we agree that things that are not MANETs tautologically are = not MANETs? Thomas >> If you push this down to link layer, you just move the whole problem >> down one layer, because you need unique addresses on the link layer >> to do neighborhood detection and link establishment. >=20 > WEll yes... I tend to agree. >=20 > However, one would avoid to bring existing link layer mechanisms up to > the IP stack too. These link layer mechanisms are there and work very > well in their domain. >=20 > The IP stack is not fast enough on the CPU to work at vehicular = speeds, > interruptable by some GUI or heavy TCP. >=20 > The link layer driver executing on a dedicated chipset is much more > reliable for these kinds of movements. >=20 >> If you already have a unique link-layer address, just use it to >> generate a unique linklocal-IP. >=20 > Hmmm... right, that's how link local addresses are generated. >=20 > Alex >=20 >>=20 >> Henning Rogge >>=20 >=20 >=20 From alexandru.petrescu@gmail.com Fri Jul 23 01:22:51 2010 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 AC1063A67DA for ; Fri, 23 Jul 2010 01:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.146, 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 NgR2FBT-41al for ; Fri, 23 Jul 2010 01:22:50 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 341933A67B4 for ; Fri, 23 Jul 2010 01:22:50 -0700 (PDT) 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 o6N8N1nu030166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 10:23:01 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6N8N0Km011310; Fri, 23 Jul 2010 10:23:01 +0200 (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 o6N8N04X023857; Fri, 23 Jul 2010 10:23:00 +0200 Message-ID: <4C495164.4080604@gmail.com> Date: Fri, 23 Jul 2010 10:23:00 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Ulrich Herberg References: <4C2A6BB7.1000900@piuha.net> <4C4899AD.4030808@gmail.com> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@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\)" , Thomas Heide Clausen Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 08:22:51 -0000 Le 23/07/2010 09:53, Ulrich Herberg a écrit : > Alex, > > On Fri, Jul 23, 2010 at 9:43 AM, Alexandru Petrescu > > > wrote: > > Le 23/07/2010 07:23, Henning Rogge a écrit : > > On Thu July 22 2010 21:19:09 Alexandru Petrescu wrote: > > Le 22/07/2010 17:41, Dearlove, Christopher (UK) a écrit : > > And then those link local addresses are visible beyond their local > link. > > > No, my point is not understood. The link-local addresses are not > visible beyond their local link. > > When the MRs in LFN--MR--MR--MR--LFN use their link-local addresses > these are not visible beyond their respective local link. > > > You just have shown that you don't understand what a wireless MANET > (with multihop links, without most people would not consider it a > MANET) is. > > > Ulrich, I do make efforts to understand what you understand. PArt > of this effort is to refrain the temptation of claiming you don't > understand what I don't understand. > > > > It was Henning, who said that, not me :-) (even though in this > particular example, I agree with him). I made a mistake, I am sorry Henning and Ulrich. I actually know you Ulrich, not Henning. I need a mental image about who I talk to. > if each of the MRs use a wireless interface, the linklocals WILL BE > VISIBLE outside their direct link. > > > Well, the link local addresses will not be visible outside their > direct link, because the different links are on different ESSIDs and > moreover on different channels. Using wireshark on IP packets on > these different links shows that the link local addressess are not > visible from one link to another. > > > Yes, but this is not the general case of a MANET. This is your very > particular lab setting, which will only work in well-known, > predefined constraints. WEll I disagree. WiFi is designed to use ESSIDs meaningfully, it is in the manual. WiFi deployments use ESSIDs. I'd say that one's refusal to use ESSIDs is refusal to abide to the manual, build broken things and then blame IP. > When you say visible - what do you mean? I mean "not visible" to the > IP stack. > > > There is no way to prevent this. > > > YEs there is - use different ESSIDs and, for more insurance, use > different channels and different keys. That is for WiFi. For other > technologies (3G+, LTE, Bluetooth) there are other link layer means > such as pdp context and more. > > > Then tell me, how Henning should manage the FunkFeuer Netzwerk. How much would Henning pay me to build a consistent plan for FunkFeuer Netzwerk? Then I'll say. > Using a different channel and ESSID for every link? Yes, different ESSID and channel for links in proximity where there may be a risk of visibility of link layer addresses. It's like the map colouring problem - there are solutions. Internet too has different IP subnets on different links. > And even worse, consider a setting where routers actually move in an > unknown patterns (i.e. are "mobile"); how would you update ESSIDs > and channels? Does such a setting really exist (pure random movements like in Brownian)? Example? For some wireless deployments studies have been performed to identify patterns: vehicular, urban citizen, more. For each there are possible plans on which WiFi would work good. Even the most arbitrary movements like in a battlefield have a very high degree of planning - the command and control is very centralized. > Because multiple links share interfaces in a non-transitive manner > > > Well yes, at link layer level. But link layers have their protocols > which help build understandable links to the IP stack. > > > Yes, but then you are wrong in the MANET WG, because we are not > talking about L2 meshes (like 802.11s). We are talking about multihop > communication on L3. I am in AUTOCONF not in MANET, right? Alex > > > > (see http://en.wikipedia.org/wiki/Transitive_relation). > > > Uh? > > Alex > > > Henning Rogge > > > > > Ulrich From alexandru.petrescu@gmail.com Fri Jul 23 01:40:10 2010 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 D33D13A69BC for ; Fri, 23 Jul 2010 01:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.140, 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 BcGYcttWIyEm for ; Fri, 23 Jul 2010 01:40:09 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id BBB2E3A69B5 for ; Fri, 23 Jul 2010 01:40:01 -0700 (PDT) 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 o6N8eCSe008618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 10:40:13 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6N8eCOD016208; Fri, 23 Jul 2010 10:40:12 +0200 (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 o6N8eC7x009463; Fri, 23 Jul 2010 10:40:12 +0200 Message-ID: <4C49556C.9040402@gmail.com> Date: Fri, 23 Jul 2010 10:40:12 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Henning Rogge References: <4C2A6BB7.1000900@piuha.net> <1D0FFC66-A4C6-4E7E-A7C5-13156A9B37A3@thomasclausen.org> <4C494C29.5020004@gmail.com> <201007231005.48365.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <201007231005.48365.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] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 08:40:11 -0000 Le 23/07/2010 10:05, Henning Rogge a écrit : > On Fri July 23 2010 10:00:41 Alexandru Petrescu wrote: >> Could we make an AUTOCONF non-MANET case where the link local >> addresses are not visible across different wireless links. >> >> Otherwise, could we be stating in the Charter that AUTOCONF deals >> _only_ with MANET cases where link local addresses are visible in >> all radio ranges, links undefined, no WiFi ESSID nor similar. >> Which by your definition is 'most MANET cases'. You mentioned it >> several times - it deserves being in the Charter. >> >> Both ways would help me a lot: in the first I stay in the group, >> present at meeting. In the second I go away. > > Quote from the charter of the autoconf WG: > > 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. > > "ad hoc networks" is the ANET part of MANET... To me "specs for ad-hoc networks" is a contradiction in itself. One would genuinely use the "ad-hoc" term after fact - I couldn't say "I will build an ad-hoc network" but rather "I have built an ad-hoc network". A few famous ad-hoc happenings were actually planned. And yes - you will quote me wikipedia about what A is in ANET is in MANET. And yes - I will quote you wikipedia saying how "vehicular ad-hoc networks" is about vehicles in constant close range, and how MANET is probably more University Research and VANET is probably more promissing. For some reason, I like that WiFi don't call themselves "ad-hoc" yet it's in widespread use. Alex > > Henning Rogge > From Chris.Dearlove@baesystems.com Fri Jul 23 01:42:34 2010 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 6A5023A67D7 for ; Fri, 23 Jul 2010 01:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.969 X-Spam-Level: X-Spam-Status: No, score=-6.969 tagged_above=-999 required=5 tests=[AWL=-0.370, 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 HG3XgwgyYC+J for ; Fri, 23 Jul 2010 01:42:33 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 2FD533A698F for ; Fri, 23 Jul 2010 01:42:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,246,1278284400"; d="scan'208";a="78034887" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 23 Jul 2010 09:42:50 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o6N8gnrC030086; Fri, 23 Jul 2010 09:42:50 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jul 2010 09:42:49 +0100 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: Fri, 23 Jul 2010 09:42:48 +0100 Message-ID: In-Reply-To: <4C4899AD.4030808@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) thread-index: Acsp0sl4OzULv8CuQPqRixdRnvZAZAAb/zrg References: <4C2A6BB7.1000900@piuha.net><4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> <4C46EFC8.6020501@piuha.net> <4C48144D.4040105@gmail.com> <4C4815B4.6020907@gmail.com> <4C485E37.3080808@gmail.com> <4C4899AD.4030808@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 23 Jul 2010 08:42:49.0965 (UTC) FILETIME=[083E09D0:01CB2A43] Cc: autoconf@ietf.org, Thomas Heide Clausen Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 08:42:34 -0000 If you are using the addresses even in NHDP, or even in a single neighbour cut-done NHDP that has link bidirectionality checking then they are so visible. And the point of this work is to create addresses that are so usable. Whether the visibility matters can be argued. That the visibility occurs is not the 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: 22 July 2010 20:19 To: Dearlove, Christopher (UK) Cc: Thomas Heide Clausen; autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF = charter proposal) *** 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. =20 Le 22/07/2010 17:41, Dearlove, Christopher (UK) a =E9crit : > And then those link local addresses are visible beyond their local > link. No, my point is not understood. The link-local addresses are not visible beyond their local link. When the MRs in LFN--MR--MR--MR--LFN use their link-local addresses these are not visible beyond their respective local link. > For some that is a problem. For others not. If they were visible - yes, it would have been a problem, but they are not. > All of which is irrelevant to the matter in the subject line, where > the decision is long (though longer would have been better) made. > Re-hashing the last N years debate gets no one anywhere. How about if during the last N years my message could not get read? 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 Fri Jul 23 01:43:55 2010 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 143303A69CE for ; Fri, 23 Jul 2010 01:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.956 X-Spam-Level: X-Spam-Status: No, score=-6.956 tagged_above=-999 required=5 tests=[AWL=-0.357, 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 ijGGp8ZPxOgo for ; Fri, 23 Jul 2010 01:43:54 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id C592A3A6992 for ; Fri, 23 Jul 2010 01:43:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,246,1278284400"; d="scan'208";a="78035322" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 23 Jul 2010 09:44:11 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o6N8iBkX031357; Fri, 23 Jul 2010 09:44:11 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jul 2010 09:44:11 +0100 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: Fri, 23 Jul 2010 09:44:09 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) thread-index: Acsp0sl4OzULv8CuQPqRixdRnvZAZAAb/zrgAAAR9UA= References: <4C2A6BB7.1000900@piuha.net><4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> <4C46EFC8.6020501@piuha.net> <4C48144D.4040105@gmail.com> <4C4815B4.6020907@gmail.com> <4C485E37.3080808@gmail.com> <4C4899AD.4030808@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 23 Jul 2010 08:44:11.0013 (UTC) FILETIME=[388CFB50:01CB2A43] Cc: autoconf@ietf.org, Thomas Heide Clausen Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 08:43:55 -0000 Sorry, hit return to quickly. My second paragraph should have said=20 Whether the visibility matters can be argued. That the visibility occurs cannot. --=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: Dearlove, Christopher (UK)=20 Sent: 23 July 2010 09:43 To: 'Alexandru Petrescu' Cc: Thomas Heide Clausen; autoconf@ietf.org Subject: RE: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF = charter proposal) If you are using the addresses even in NHDP, or even in a single neighbour cut-done NHDP that has link bidirectionality checking then they are so visible. And the point of this work is to create addresses that are so usable. Whether the visibility matters can be argued. That the visibility occurs is not the 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: 22 July 2010 20:19 To: Dearlove, Christopher (UK) Cc: Thomas Heide Clausen; autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF = charter proposal) *** 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. =20 Le 22/07/2010 17:41, Dearlove, Christopher (UK) a =E9crit : > And then those link local addresses are visible beyond their local > link. No, my point is not understood. The link-local addresses are not visible beyond their local link. When the MRs in LFN--MR--MR--MR--LFN use their link-local addresses these are not visible beyond their respective local link. > For some that is a problem. For others not. If they were visible - yes, it would have been a problem, but they are not. > All of which is irrelevant to the matter in the subject line, where > the decision is long (though longer would have been better) made. > Re-hashing the last N years debate gets no one anywhere. How about if during the last N years my message could not get read? 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 Fri Jul 23 01:44:47 2010 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 6B6AC3A6922 for ; Fri, 23 Jul 2010 01:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.943 X-Spam-Level: X-Spam-Status: No, score=-6.943 tagged_above=-999 required=5 tests=[AWL=-0.344, 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 kFnYEOamHSeD for ; Fri, 23 Jul 2010 01:44:46 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 3648F3A67D7 for ; Fri, 23 Jul 2010 01:44:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,246,1278284400"; d="scan'208";a="78035568" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 23 Jul 2010 09:45:04 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o6N8j3iM032152; Fri, 23 Jul 2010 09:45:03 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jul 2010 09:45:03 +0100 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: Fri, 23 Jul 2010 09:45:02 +0100 Message-ID: In-Reply-To: <4C4898D2.5010804@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) thread-index: Acsp0keqZmy7F2hIQiehy5ASXABEEQAcPaPA References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <4C4706D8.5040904@piuha.net> <4C473D4C.8050504@gmail.com> <4C480A3F.3000103@gmail.com> <4C48145E.3020202@gmail.com> <4C4855A6.20200@gmail.com> <4C485EC4.7000908@gmail.com> <4C4898D2.5010804@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 23 Jul 2010 08:45:03.0608 (UTC) FILETIME=[57E65780:01CB2A43] Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 08:44:47 -0000 Not in AUTH48. You are talking about earlier stages of the process. --=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: 22 July 2010 20:16 To: Dearlove, Christopher (UK) Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF = charter proposal) *** 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. =20 Chris - allow me to Cc the list, thanks. A number of messages on the email list (at least 4 persons) said that link-local addresses could be used and they said they are not necessarily against them. Being against me is a typical behavior and I'm fine with it. But if one checks the emails one sees that personal opinions are tolerant with respect to link-local addresses, and not necessarily discourages them. It is the stubordness to update the draft which is not normal - a plain error. Alex Le 22/07/2010 17:41, Dearlove, Christopher (UK) a =E9crit : > No, it's not an error. It's a design decision. One you disagree > with, but broad consensus was against you. That does not make it an > error. > ******************************************************************** 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 Fri Jul 23 01:45:57 2010 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 5031F3A69B5 for ; Fri, 23 Jul 2010 01:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.931 X-Spam-Level: X-Spam-Status: No, score=-6.931 tagged_above=-999 required=5 tests=[AWL=-0.332, 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 oMeYg1BiB5lM for ; Fri, 23 Jul 2010 01:45:56 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 381C53A698F for ; Fri, 23 Jul 2010 01:45:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,246,1278284400"; d="scan'208";a="78035965" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 23 Jul 2010 09:46:14 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o6N8kD0k000664; Fri, 23 Jul 2010 09:46:13 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jul 2010 09:46:13 +0100 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, 23 Jul 2010 09:46:12 +0100 Message-ID: In-Reply-To: <4C48B1AE.2030408@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] Another addressing model for AUTOCONF thread-index: Acsp4Rng3NBBiLhqQhSF6kf15leGXQAYlBmw References: <4C48B1AE.2030408@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , X-OriginalArrivalTime: 23 Jul 2010 08:46:13.0482 (UTC) FILETIME=[818C44A0:01CB2A43] Subject: Re: [Autoconf] Another addressing model for AUTOCONF 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, 23 Jul 2010 08:45:57 -0000 > ThomasC and Chris also expressed doubts with respect to LFN--MR--MR--LFN > topology and link-local addresses That disrepresents what I said. ******************************************************************** 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 Fri Jul 23 01:49:30 2010 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 347EE3A6992 for ; Fri, 23 Jul 2010 01:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[AWL=-0.321, 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 0yOpVLoNzrfO for ; Fri, 23 Jul 2010 01:49:29 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id E10F13A6834 for ; Fri, 23 Jul 2010 01:49:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,246,1278284400"; d="scan'208";a="78037055" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 23 Jul 2010 09:49:46 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o6N8njnW003412; Fri, 23 Jul 2010 09:49:46 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jul 2010 09:49:45 +0100 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, 23 Jul 2010 09:49:44 +0100 Message-ID: In-Reply-To: <4C494806.5060609@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) thread-index: AcsqOrC7af/qv14ES9eL0mWBHSX9hgACORcw References: <4C2A6BB7.1000900@piuha.net> <4C4899AD.4030808@gmail.com> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , "Henning Rogge" X-OriginalArrivalTime: 23 Jul 2010 08:49:45.0609 (UTC) FILETIME=[FFFC4790:01CB2A43] Cc: autoconf@ietf.org, Thomas Heide Clausen Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 08:49:30 -0000 > Well, the link local addresses will not be visible outside their direct > link, because the different links are on different ESSIDs and moreover > on different channels. Not in our networks. Furthermore "ESSID" is specific to a particular lower layer technology and we are not constraining ourselves to it, as has been said many times. And even then this doesn't ensure lack of visibility. ******************************************************************** 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 Jul 23 01:52:07 2010 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 DBDD23A69F0 for ; Fri, 23 Jul 2010 01:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=0.135, 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 A-Sw4hSNScrc for ; Fri, 23 Jul 2010 01:52:07 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id A02253A69B5 for ; Fri, 23 Jul 2010 01:52:06 -0700 (PDT) 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 o6N8qH44008550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 10:52:18 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6N8qHfK019388; Fri, 23 Jul 2010 10:52:17 +0200 (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 o6N8qGnw013798; Fri, 23 Jul 2010 10:52:17 +0200 Message-ID: <4C495840.60409@gmail.com> Date: Fri, 23 Jul 2010 10:52:16 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Thomas Heide Clausen References: <4C2A6BB7.1000900@piuha.net> <4C4899AD.4030808@gmail.com> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com> <1D0FFC66-A4C6-4E7E-A7C5-13156A9B37A3@thomasclausen.org> <4C494C29.5020004@gmail.com> <1770ECCA-C51B-42C4-AB7C-A59424E1B01D@thomasclausen.org> In-Reply-To: <1770ECCA-C51B-42C4-AB7C-A59424E1B01D@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] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 08:52:08 -0000 Le 23/07/2010 10:12, Thomas Heide Clausen a écrit : > > On Jul 23, 2010, at 10:00 , Alexandru Petrescu wrote: > >> Le 23/07/2010 09:47, Thomas Heide Clausen a écrit : >>> >>> On Jul 23, 2010, at 09:43 , Alexandru Petrescu wrote: >>> >>>> Le 23/07/2010 07:23, Henning Rogge a écrit : >>>>> On Thu July 22 2010 21:19:09 Alexandru Petrescu wrote: >>>>>> Le 22/07/2010 17:41, Dearlove, Christopher (UK) a écrit : >>>>>>> And then those link local addresses are visible beyond >>>>>>> their local link. >>>>>> >>>>>> No, my point is not understood. The link-local addresses >>>>>> are not visible beyond their local link. >>>>>> >>>>>> When the MRs in LFN--MR--MR--MR--LFN use their link-local >>>>>> addresses these are not visible beyond their respective >>>>>> local link. >>>>> >>>>> You just have shown that you don't understand what a >>>>> wireless MANET (with multihop links, without most people >>>>> would not consider it a MANET) is. >>>> >>>> Ulrich, I do make efforts to understand what you understand. >>>> PArt of this effort is to refrain the temptation of claiming >>>> you don't understand what I don't understand. >>>> >>>>> if each of the MRs use a wireless interface, the linklocals >>>>> WILL BE VISIBLE outside their direct link. >>>> >>>> Well, the link local addresses will not be visible outside >>>> their direct link, because the different links are on different >>>> ESSIDs and moreover on different channels. >>> >>> That is the crux of your misunderstanding. They may, in your >>> case, be -- in most MANET cases, they're not. >> >> Thomas - help me remove this crux. >> >> Could we make an AUTOCONF non-MANET case where the link local >> addresses are not visible across different wireless links. > > No, I don't see how we could make a valid case like that. > > In part, because [autoconf] targets MANETs, trying to make a > "non-MANET case" would be quite out of scope. > >> Otherwise, could we be stating in the Charter that AUTOCONF deals >> _only_ with MANET cases where link local addresses are visible in >> all radio ranges, links undefined, no WiFi ESSID nor similar. Which >> by your definition is 'most MANET cases'. > > The reference to 2501 should make it clear that we were talking about > MANETs, and so should be familiar with what that entails -- which is > (among other things) that the above "link" characteristics are true > (and I just see Henning chipped in, and want to +1 to his remark as > well). But, I would guess that if adding the keyword "MANET" to the > charter is what this discussion is about, then that can be done too. Thomas - FWIW, you seem to it's easy for AUTOCONF Charter to be MANET RFC2501 only. If so - add "MANET" in the Charter, rfc2501, make that be the exclusive AUTOCONF cases and I go away. I will not call my deployments MANET. Alex > > Thomas > >> You mentioned it several times - it deserves being in the Charter. >> Both ways would help me a lot: in the first I stay in the group, >> present at meeting. In the second I go away. >> >> Alex >> >>> >>> Thomas >>> >>> >>>> Using wireshark on IP packets on these different links shows >>>> that the link local addressess are not visible from one link >>>> to another. >>>> >>>> When you say visible - what do you mean? I mean "not visible" >>>> to the IP stack. >>>> >>>>> There is no way to prevent this. >>>> >>>> YEs there is - use different ESSIDs and, for more insurance, >>>> use different channels and different keys. That is for WiFi. >>>> For other technologies (3G+, LTE, Bluetooth) there are other >>>> link layer means such as pdp context and more. >>>> >>>>> Because multiple links share interfaces in a non-transitive >>>>> manner >>>> >>>> Well yes, at link layer level. But link layers have their >>>> protocols which help build understandable links to the IP >>>> stack. >>>> >>>>> (see http://en.wikipedia.org/wiki/Transitive_relation). >>>> >>>> Uh? >>>> >>>> Alex >>>> >>>>> >>>>> Henning Rogge >>>>> >>>> >>>> >>> >>> >> >> > > From alexandru.petrescu@gmail.com Fri Jul 23 01:53:12 2010 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 CF4E73A69EC for ; Fri, 23 Jul 2010 01:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=0.130, 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 xECExrD6Hwsc for ; Fri, 23 Jul 2010 01:53:07 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 7D24D3A69E1 for ; Fri, 23 Jul 2010 01:53:07 -0700 (PDT) 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 o6N8rKb5024867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 10:53:20 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6N8rKpB019794; Fri, 23 Jul 2010 10:53:20 +0200 (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 o6N8rJCG014307; Fri, 23 Jul 2010 10:53:19 +0200 Message-ID: <4C49587F.4040605@gmail.com> Date: Fri, 23 Jul 2010 10:53:19 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Thomas Heide Clausen References: <4C2A6BB7.1000900@piuha.net> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com> <201007230951.51192.henning.rogge@fkie.fraunhofer.de> <4C494EAE.9000600@gmail.com> <01937057-07D5-44BF-BB89-CF86EB08858C@thomasclausen.org> In-Reply-To: <01937057-07D5-44BF-BB89-CF86EB08858C@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] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 08:53:12 -0000 Le 23/07/2010 10:15, Thomas Heide Clausen a écrit : > > On Jul 23, 2010, at 10:11 , Alexandru Petrescu wrote: > >> Le 23/07/2010 09:51, Henning Rogge a écrit : >>> On Fri July 23 2010 09:43:02 Alexandru Petrescu wrote: >>>>> if each of the MRs use a wireless interface, the linklocals WILL >>>>> BE VISIBLE outside their direct link. >>>> >>>> Well, the link local addresses will not be visible outside their >>>> direct link, because the different links are on different ESSIDs >>>> and moreover on different channels. Using wireshark on IP packets >>>> on these different links shows that the link local addressess are >>>> not visible from one link to another. >>> >>> This would only work with preplanned links, >> >> Most deployments have a high degree of planning. > > Then, they're (by definition) not ad-hoc networks. > >>> because otherwise you would have trouble to do neighborhood >>> detection. How do you detect new nodes coming into range if they >>> cannot announce their presence with a broadcast, because they got no >>> unique ESSID to their neighbors ? >> >> Well good question - and I have tried. The difficult thing is the first >> detection - the "wifi scan" phase; once the drivers have their data set >> up then re-detection is very fast, in the order of tens of milliseconds. >> We could use that to signal between two approaching vehicles. >> >> More specifically, on WiFi, a beacon is sent periodically, but there are >> also periodic requests replied with a beacon. These help a lot to >> detect presence of a neighbor previously learned, and fast. >> >>> MANET routing protocols are specially designed for the case of >>> unplanned networks. You have a single shared medium which the routing >>> protocol use for it's work, to do neighborhood/link detection. >> >> Well very good. Is there a case where wireless multi-hop networks are >> possible _without_ MANET routing protocols? I believe yes, and I >> prototyped and demo. > > Very well, but then that's not a MANET. > >> Besides, there exist deployments where even though the MRs are mobile >> they stay relatively fixed with respect to each other, in some very >> simple topology: truck convoy, wagons in a train, etc. These things >> stay formed for long hours and reform right after. These things don't >> need the power of MANET routing protocols because there are never loops >> formed at link layer, the topology is really simple. > > Very well, but then that's not a MANET. > > Alex, can we agree that things that are not MANETs tautologically are not MANETs? Sure! Make the Charter tautologically MANET and then we're all clear. Alex > > Thomas > > >>> If you push this down to link layer, you just move the whole problem >>> down one layer, because you need unique addresses on the link layer >>> to do neighborhood detection and link establishment. >> >> WEll yes... I tend to agree. >> >> However, one would avoid to bring existing link layer mechanisms up to >> the IP stack too. These link layer mechanisms are there and work very >> well in their domain. >> >> The IP stack is not fast enough on the CPU to work at vehicular speeds, >> interruptable by some GUI or heavy TCP. >> >> The link layer driver executing on a dedicated chipset is much more >> reliable for these kinds of movements. >> >>> If you already have a unique link-layer address, just use it to >>> generate a unique linklocal-IP. >> >> Hmmm... right, that's how link local addresses are generated. >> >> Alex >> >>> >>> Henning Rogge >>> >> >> > > From alexandru.petrescu@gmail.com Fri Jul 23 01:57:22 2010 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 4554B3A6816 for ; Fri, 23 Jul 2010 01:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.126, 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 cEDeiDlzw-0H for ; Fri, 23 Jul 2010 01:57:21 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 3D36C3A69F0 for ; Fri, 23 Jul 2010 01:57:20 -0700 (PDT) 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 o6N8vbQg026053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 10:57:37 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6N8vbbf021045; Fri, 23 Jul 2010 10:57:37 +0200 (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 o6N8va4T015876; Fri, 23 Jul 2010 10:57:36 +0200 Message-ID: <4C495980.6060500@gmail.com> Date: Fri, 23 Jul 2010 10:57:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4C2A6BB7.1000900@piuha.net><4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> <4C46EFC8.6020501@piuha.net> <4C48144D.4040105@gmail.com> <4C4815B4.6020907@gmail.com> <4C485E37.3080808@gmail.com> <4C4899AD.4030808@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Thomas Heide Clausen Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 08:57:22 -0000 Le 23/07/2010 10:42, Dearlove, Christopher (UK) a écrit : > If you are using the addresses even in NHDP, or even in a > single neighbour cut-done NHDP that has link bidirectionality > checking then they are so visible. Hmmm... I have just tried two WiFi networks nearby (ad-hoc more, ha!) with different ESSIDs and channels and the link-locally addressed messages from one to another are invisible on Wireshark (from one link to another). Besides, in some cases even in Access Point mode the messages from STA to BS are invisible between STAs on same ESSID, but that's particular. Any other experience enlightening. Alex And the point of this work > is to create addresses that are so usable. > > Whether the visibility matters can be argued. That the visibility > occurs is not the case. > From alexandru.petrescu@gmail.com Fri Jul 23 01:58:10 2010 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 EBD4C3A6816 for ; Fri, 23 Jul 2010 01:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=0.121, 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 uGZjxOntqJZf for ; Fri, 23 Jul 2010 01:58:10 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id DC20E3A69E4 for ; Fri, 23 Jul 2010 01:58:09 -0700 (PDT) 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 o6N8wQk6030944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 10:58:26 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6N8wQtl021255; Fri, 23 Jul 2010 10:58:26 +0200 (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 o6N8wPFs016128; Fri, 23 Jul 2010 10:58:25 +0200 Message-ID: <4C4959B1.4070602@gmail.com> Date: Fri, 23 Jul 2010 10:58:25 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4C2A6BB7.1000900@piuha.net><4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> <4C46EFC8.6020501@piuha.net> <4C48144D.4040105@gmail.com> <4C4815B4.6020907@gmail.com> <4C485E37.3080808@gmail.com> <4C4899AD.4030808@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Thomas Heide Clausen Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 08:58:11 -0000 Le 23/07/2010 10:44, Dearlove, Christopher (UK) a écrit : > Sorry, hit return to quickly. My second paragraph should have > said > > Whether the visibility matters can be argued. That the visibility > occurs cannot. Well - you won't argue and I will, my IP testbed contradicts your argument. Alex > From Chris.Dearlove@baesystems.com Fri Jul 23 01:59:14 2010 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 4D63F3A6816 for ; Fri, 23 Jul 2010 01:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[AWL=-0.311, 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 33JC+LisYboJ for ; Fri, 23 Jul 2010 01:59:13 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 1790A3A69E4 for ; Fri, 23 Jul 2010 01:59:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,246,1278284400"; d="scan'208";a="78040104" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 23 Jul 2010 09:59:30 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o6N8xU6E011354; Fri, 23 Jul 2010 09:59:30 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jul 2010 09:59:30 +0100 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: Fri, 23 Jul 2010 09:59:29 +0100 Message-ID: In-Reply-To: <4C495980.6060500@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) thread-index: AcsqRRrgDW0B7x0KTNeV5TqgHUuV1QAACvIg References: <4C2A6BB7.1000900@piuha.net><4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> <4C46EFC8.6020501@piuha.net> <4C48144D.4040105@gmail.com> <4C4815B4.6020907@gmail.com> <4C485E37.3080808@gmail.com> <4C4899AD.4030808@gmail.com> <4C495980.6060500@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 23 Jul 2010 08:59:30.0348 (UTC) FILETIME=[5C845EC0:01CB2A45] Cc: autoconf@ietf.org, Thomas Heide Clausen Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 08:59:14 -0000 That's because you weren't running a MANET.=20 I'm going to stop spending time on this discussion 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: 23 July 2010 09:58 To: Dearlove, Christopher (UK) Cc: Thomas Heide Clausen; autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF = charter proposal) *** 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. =20 Le 23/07/2010 10:42, Dearlove, Christopher (UK) a =E9crit : > If you are using the addresses even in NHDP, or even in a > single neighbour cut-done NHDP that has link bidirectionality > checking then they are so visible. Hmmm... I have just tried two WiFi networks nearby (ad-hoc more, ha!)=20 with different ESSIDs and channels and the link-locally addressed=20 messages from one to another are invisible on Wireshark (from one link=20 to another). Besides, in some cases even in Access Point mode the messages from STA=20 to BS are invisible between STAs on same ESSID, but that's particular. Any other experience enlightening. Alex And the point of this work > is to create addresses that are so usable. > > Whether the visibility matters can be argued. That the visibility > occurs is not the case. > ******************************************************************** 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 Jul 23 01:59:41 2010 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 5EB8C3A69E9 for ; Fri, 23 Jul 2010 01:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.118, 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 0YVBytcViKBH for ; Fri, 23 Jul 2010 01:59:40 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 611F43A6922 for ; Fri, 23 Jul 2010 01:59:40 -0700 (PDT) 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 o6N8xuA6027836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 10:59:56 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6N8xuIi021740; Fri, 23 Jul 2010 10:59:56 +0200 (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 o6N8xtsQ016646; Fri, 23 Jul 2010 10:59:55 +0200 Message-ID: <4C495A0B.302@gmail.com> Date: Fri, 23 Jul 2010 10:59:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4C48B1AE.2030408@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] Another addressing model for AUTOCONF 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, 23 Jul 2010 08:59:41 -0000 Le 23/07/2010 10:46, Dearlove, Christopher (UK) a écrit : >> ThomasC and Chris also expressed doubts with respect to > LFN--MR--MR--LFN >> topology and link-local addresses > > That disrepresents what I said. So please clarify - represent it better, I listen. 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 Fri Jul 23 02:00:55 2010 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 74EF83A69E9 for ; Fri, 23 Jul 2010 02:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.114, 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 0Z4dDF+u4UzE for ; Fri, 23 Jul 2010 02:00:54 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 4116B3A69D8 for ; Fri, 23 Jul 2010 02:00:54 -0700 (PDT) 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 o6N919Bf014503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 11:01:09 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6N919Kc022229; Fri, 23 Jul 2010 11:01:09 +0200 (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 o6N919D6017263; Fri, 23 Jul 2010 11:01:09 +0200 Message-ID: <4C495A55.4070401@gmail.com> Date: Fri, 23 Jul 2010 11:01:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <4C4706D8.5040904@piuha.net> <4C473D4C.8050504@gmail.com> <4C480A3F.3000103@gmail.com> <4C48145E.3020202@gmail.com> <4C4855A6.20200@gmail.com> <4C485EC4.7000908@gmail.com> <4C4898D2.5010804@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] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 09:00:55 -0000 Le 23/07/2010 10:45, Dearlove, Christopher (UK) a écrit : > Not in AUTH48. You are talking about earlier stages of the process. Someone on this list redirected me to that web page about which I talk, at the bottom of that page. Alex From alexandru.petrescu@gmail.com Fri Jul 23 02:01:21 2010 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 181CF3A6B2E for ; Fri, 23 Jul 2010 02:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.110, 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 s9Ec5W1xUcPg for ; Fri, 23 Jul 2010 02:01:20 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 216243A698F for ; Fri, 23 Jul 2010 02:01:19 -0700 (PDT) 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 o6N91a0H029102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 11:01:36 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6N91aEM022313; Fri, 23 Jul 2010 11:01:36 +0200 (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 o6N91ZGv017415; Fri, 23 Jul 2010 11:01:35 +0200 Message-ID: <4C495A6F.2060902@gmail.com> Date: Fri, 23 Jul 2010 11:01:35 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4C2A6BB7.1000900@piuha.net><4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <323812CA-4C8B-4469-AA6C-0D65191F2735@sensinode.com> <4C46EFC8.6020501@piuha.net> <4C48144D.4040105@gmail.com> <4C4815B4.6020907@gmail.com> <4C485E37.3080808@gmail.com> <4C4899AD.4030808@gmail.com> <4C495980.6060500@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Thomas Heide Clausen Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 09:01:21 -0000 Le 23/07/2010 10:59, Dearlove, Christopher (UK) a écrit : > That's because you weren't running a MANET. > > I'm going to stop spending time on this discussion now. Well - I claim to run IP multi-hop wireless mobile networks without running MANET routing protocols. I suggest to stop calling everything a MANET. Alex > From alexandru.petrescu@gmail.com Fri Jul 23 02:06:02 2010 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 13E5B3A698F for ; Fri, 23 Jul 2010 02:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.107, 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 VTpFkMn9veg8 for ; Fri, 23 Jul 2010 02:06:00 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 69EDD3A6992 for ; Fri, 23 Jul 2010 02:06:00 -0700 (PDT) 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 o6N96DKu000467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 11:06:13 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6N96DC4024133; Fri, 23 Jul 2010 11:06:13 +0200 (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 o6N96CI9007822; Fri, 23 Jul 2010 11:06:12 +0200 Message-ID: <4C495B84.9070705@gmail.com> Date: Fri, 23 Jul 2010 11:06:12 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4C2A6BB7.1000900@piuha.net> <4C4899AD.4030808@gmail.com> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Thomas Heide Clausen Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 09:06:02 -0000 Le 23/07/2010 10:49, Dearlove, Christopher (UK) a écrit : >> Well, the link local addresses will not be visible outside their > direct >> link, because the different links are on different ESSIDs and >> moreover on different channels. > > Not in our networks. Furthermore "ESSID" is specific to a particular > lower layer technology and we are not constraining ourselves to it, > as has been said many times. Tell me the name of your particular lower layer technology and I will tell you the equivalent of ESSID. This equivalence exists in other than WiFi techs: pdp context for 3G, picocell ID for Bluetooth, etc. I would be surprised the unknown link layer does not have such means of link separation... > And even then this doesn't ensure lack of visibility. Link layers have this typical functionality. 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 henning.rogge@fkie.fraunhofer.de Fri Jul 23 03:43:46 2010 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 DD5103A69ED for ; Fri, 23 Jul 2010 03:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.026 X-Spam-Level: X-Spam-Status: No, score=-3.026 tagged_above=-999 required=5 tests=[AWL=-1.682, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] 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 SYHLlZy-38Fw for ; Fri, 23 Jul 2010 03:43:45 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by core3.amsl.com (Postfix) with ESMTP id 84AC93A69EC for ; Fri, 23 Jul 2010 03:43:45 -0700 (PDT) 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 1OcFjU-0006Is-3t; Fri, 23 Jul 2010 12:44:00 +0200 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 1OcFjT-0001O2-Qq; Fri, 23 Jul 2010 12:43:59 +0200 From: Henning Rogge To: Alexandru Petrescu Date: Fri, 23 Jul 2010 12:43:23 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-23-generic; KDE/4.4.5; i686; ; ) References: <4C2A6BB7.1000900@piuha.net> <4C495164.4080604@gmail.com> In-Reply-To: <4C495164.4080604@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3587657.gILq5L8SY3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201007231243.55159.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11421/Fri Jul 23 11:39:50 2010) by mailguard.fgan.de X-Scan-Signature: a8e2f18599482a3592288cf2106a6f9f Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" , Thomas Heide Clausen Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 10:43:47 -0000 --nextPart3587657.gILq5L8SY3 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Fri July 23 2010 10:23:00 Alexandru Petrescu wrote: > WEll I disagree. WiFi is designed to use ESSIDs meaningfully, it is in > the manual. WiFi deployments use ESSIDs. I'd say that one's refusal to > use ESSIDs is refusal to abide to the manual, build broken things and > then blame IP. The typical usage for an 802.11 network in adhoc mode would be to set ALL=20 nodes to the same ESSID. If you don't do so, you have trouble communicating= =20 with a node which you thought you would have no connection with (and did no= t=20 reserved an ESSID). Reserving an ESSID for each link of the network will waste a huge amount of= =20 airtime with beacons. In some cases it might be even better to switch of=20 beacons off completely (ahdemo mode). 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-961, 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 --nextPart3587657.gILq5L8SY3 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) iEYEABECAAYFAkxJckwACgkQRIfGfFXsz+AgBwCeNxWIPPHv3xm5boW1HQBYM45k JjAAn0HaSMa8kHuWZcC1clup/wDEbjTP =TRBt -----END PGP SIGNATURE----- --nextPart3587657.gILq5L8SY3-- From thomas@thomasclausen.org Fri Jul 23 03:46:36 2010 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 274783A6853 for ; Fri, 23 Jul 2010 03:46:36 -0700 (PDT) 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 vleh8xtGtXyD for ; Fri, 23 Jul 2010 03:46:35 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 51F303A67FC for ; Fri, 23 Jul 2010 03:46:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id B74723236DB2; Fri, 23 Jul 2010 03:46:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 019683228BE2; Fri, 23 Jul 2010 03:46:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Thomas Heide Clausen In-Reply-To: Date: Fri, 23 Jul 2010 12:46:50 +0200 Content-Transfer-Encoding: 7bit Message-Id: <192F4662-DA37-4EA2-BB66-76E796ED7401@thomasclausen.org> References: <4C48B1AE.2030408@gmail.com> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1078) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Another addressing model for AUTOCONF 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, 23 Jul 2010 10:46:36 -0000 On Jul 23, 2010, at 10:46 , Dearlove, Christopher (UK) wrote: >> ThomasC and Chris also expressed doubts with respect to > LFN--MR--MR--LFN >> topology and link-local addresses > > That disrepresents what I said. > +1 ThomasC > ******************************************************************** > 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 teco@inf-net.nl Fri Jul 23 03:53:57 2010 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 1DFC73A6839 for ; Fri, 23 Jul 2010 03:53:57 -0700 (PDT) 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 5THDSnUP0iQR for ; Fri, 23 Jul 2010 03:53:56 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 1CAE03A67FC for ; Fri, 23 Jul 2010 03:53:55 -0700 (PDT) Received: by ewy22 with SMTP id 22so27549ewy.31 for ; Fri, 23 Jul 2010 03:54:13 -0700 (PDT) Received: by 10.213.4.203 with SMTP id 11mr3280058ebs.5.1279882452081; Fri, 23 Jul 2010 03:54:12 -0700 (PDT) Received: from [10.128.0.173] ([77.61.241.196]) by mx.google.com with ESMTPS id x54sm174561eeh.11.2010.07.23.03.54.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 23 Jul 2010 03:54:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4C495164.4080604@gmail.com> Date: Fri, 23 Jul 2010 12:54:04 +0200 Content-Transfer-Encoding: 7bit Message-Id: <08631826-F740-4FDD-8642-41E1D507D12B@inf-net.nl> References: <4C2A6BB7.1000900@piuha.net> <4C4899AD.4030808@gmail.com> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com> <4C495164.4080604@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org autoconf@ietf.org" Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 10:53:57 -0000 Op 23 jul 2010, om 10:23 heeft Alexandru Petrescu het volgende geschreven: >> And even worse, consider a setting where routers actually move in an >> unknown patterns (i.e. are "mobile"); how would you update ESSIDs >> and channels? > > Does such a setting really exist (pure random movements like in > Brownian)? Example? > > For some wireless deployments studies have been performed to identify > patterns: vehicular, urban citizen, more. For each there are possible > plans on which WiFi would work good. > > Even the most arbitrary movements like in a battlefield have a very high > degree of planning - the command and control is very centralized. Sorry, you disqualified yourself here. Teco. From teco@inf-net.nl Fri Jul 23 03:56:30 2010 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 7DA7A3A69AC for ; Fri, 23 Jul 2010 03:56:30 -0700 (PDT) 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 exaM9LnzdogJ for ; Fri, 23 Jul 2010 03:56:29 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id CB20A3A6853 for ; Fri, 23 Jul 2010 03:56:28 -0700 (PDT) Received: by ewy22 with SMTP id 22so28439ewy.31 for ; Fri, 23 Jul 2010 03:56:46 -0700 (PDT) Received: by 10.213.32.135 with SMTP id c7mr3249803ebd.2.1279882605866; Fri, 23 Jul 2010 03:56:45 -0700 (PDT) Received: from [10.128.0.173] ([77.61.241.196]) by mx.google.com with ESMTPS id v59sm171277eeh.22.2010.07.23.03.56.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 23 Jul 2010 03:56:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4C494EAE.9000600@gmail.com> Date: Fri, 23 Jul 2010 12:56:42 +0200 Content-Transfer-Encoding: 7bit Message-Id: <49E68B55-C943-4B71-A4BD-D6424BC8AB4E@inf-net.nl> References: <4C2A6BB7.1000900@piuha.net> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com> <201007230951.51192.henning.rogge@fkie.fraunhofer.de> <4C494EAE.9000600@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org autoconf@ietf.org" Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 10:56:30 -0000 Op 23 jul 2010, om 10:11 heeft Alexandru Petrescu het volgende geschreven: > More specifically, on WiFi, a beacon is sent periodically, but there are > also periodic requests replied with a beacon. These help a lot to > detect presence of a neighbor previously learned, and fast. Far out of context of this WG. But here a correction: Only a subset of 802.11 nodes in a service set send beacons. This is APs, or elected nodes in IBSS. A beacon advertises a service set, not a station. Teco From teco@inf-net.nl Fri Jul 23 03:58:17 2010 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 2C3E73A69D2 for ; Fri, 23 Jul 2010 03:58:17 -0700 (PDT) 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 7gI+Qc4JFUPI for ; Fri, 23 Jul 2010 03:58:16 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id DCA663A69AC for ; Fri, 23 Jul 2010 03:58:15 -0700 (PDT) Received: by ewy22 with SMTP id 22so29106ewy.31 for ; Fri, 23 Jul 2010 03:58:33 -0700 (PDT) Received: by 10.213.33.197 with SMTP id i5mr465502ebd.44.1279882713435; Fri, 23 Jul 2010 03:58:33 -0700 (PDT) Received: from [10.128.0.173] ([77.61.241.196]) by mx.google.com with ESMTPS id x54sm180649eeh.11.2010.07.23.03.58.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 23 Jul 2010 03:58:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4C48B1AE.2030408@gmail.com> Date: Fri, 23 Jul 2010 12:58:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <672CA84A-1850-4B17-922F-AE75D4CF961B@inf-net.nl> References: <4C48B1AE.2030408@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Another addressing model for AUTOCONF 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, 23 Jul 2010 10:58:17 -0000 Alex, Quick comments: Your example 2001:1::/24 and 2001:2::/24 share a common prefix. Better use 2001:1::/32 and 2001:2::/32 or longer, e.g. /64. On your presso:=20 I would not use same ssid on APs in all vehicles. (slide 2, essid: = "V3"). And I dislike the address spoofing mode, suggested in slide 4. So it so +1 on others remarks. Teco. Op 22 jul 2010, om 23:01 heeft Alexandru Petrescu het volgende = geschreven: > Addressing model we use, pdf 300Kb: >=20 > http://dl.free.fr/m95j1Km7a > (the username is left empty and password is 'password', without > quotes. File stays there for 30 days.) >=20 > Teco asked whether my draft contains an addressing model... true - it = doesn't show so obviously > = (http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00). >=20 > I said that there is an addressing model in this figure of the draft: >> egress| |egress >> ---- ---- ---- ---- ---- ---- >> | LFN| |LFN | | MR | | MR | |LFN | |LFN | >> ---- ---- ---- ---- ---- ---- >> | | ingress| |ingress | | >> --------------------- --------------------- >> 2001:1::/24 2001:2::/24 >=20 > ThomasC and Chris also expressed doubts with respect to = LFN--MR--MR--LFN > topology and link-local addresses; let me explain further. >=20 > We are using this addressing model on several moving networks. See the = pdf at the beginning of this email. They show MR-to-MR with a single = addressing scheme, then with a double addressing scheme; (double is = necessary for our plan.) >=20 > And then a slide shows MR-to-MR-to-MR addressing model. >=20 > There are some scalability remarks and a route propagation model = (pencil > and paper). >=20 > The mechanism has been prototyped and demoed since about one year now, > on three Mobile Routers and a bunch of LFNs, which shows it may work. = We > have great plans for demoing on vehicles. >=20 > This is an addressing model we consider strongly. It needs later to > auto-configure some prefixes, because currently MNPs are = pre-configured > in each moving network (this is the case in some deployments). >=20 > This addressing model is important to us, and uses link-local = addresses. >=20 > Alex > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Fri Jul 23 05:08:18 2010 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 940DE3A68A2 for ; Fri, 23 Jul 2010 05:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.104, 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 47TZWkS5RV-x for ; Fri, 23 Jul 2010 05:08:17 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 8E1503A6407 for ; Fri, 23 Jul 2010 05:08:17 -0700 (PDT) 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 o6NC892V029209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 14:08:09 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6NC88Me003399; Fri, 23 Jul 2010 14:08:09 +0200 (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 o6NC87RP012682; Fri, 23 Jul 2010 14:08:08 +0200 Message-ID: <4C498627.5050008@gmail.com> Date: Fri, 23 Jul 2010 14:08:07 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Henning Rogge References: <4C2A6BB7.1000900@piuha.net> <4C495164.4080604@gmail.com> <201007231243.55159.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <201007231243.55159.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] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 12:08:18 -0000 Le 23/07/2010 12:43, Henning Rogge a écrit : > On Fri July 23 2010 10:23:00 Alexandru Petrescu wrote: >> WEll I disagree. WiFi is designed to use ESSIDs meaningfully, it is in >> the manual. WiFi deployments use ESSIDs. I'd say that one's refusal to >> use ESSIDs is refusal to abide to the manual, build broken things and >> then blame IP. > > The typical usage for an 802.11 network in adhoc mode would be to set ALL > nodes to the same ESSID. All node in close range - yes. Nodes further apart could form a different subnet. > If you don't do so, you have trouble communicating > with a node which you thought you would have no connection with (and did not > reserved an ESSID). > > Reserving an ESSID for each link of the network will waste a huge amount of > airtime with beacons. Well - depends. In a 50meter area - yes, a single ESSID is good. It's the same area where a subnet can form and have a single ESSID and where link-local addresses are visible from each other. That 50meter is a hard limit specified. > In some cases it might be even better to switch of > beacons off completely (ahdemo mode). Yes, in some cases yes. Alex > > Henning Rogge > From alexandru.petrescu@gmail.com Fri Jul 23 05:10:25 2010 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 B6FA63A68BE for ; Fri, 23 Jul 2010 05:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.101, 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 iGu0flFL7hFt for ; Fri, 23 Jul 2010 05:10:24 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 64D943A680A for ; Fri, 23 Jul 2010 05:10:24 -0700 (PDT) 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 o6NCAfLn020331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 14:10:41 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6NCAfwC004354; Fri, 23 Jul 2010 14:10:41 +0200 (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 o6NCAe9s013845; Fri, 23 Jul 2010 14:10:40 +0200 Message-ID: <4C4986C0.1060003@gmail.com> Date: Fri, 23 Jul 2010 14:10:40 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Teco Boot References: <4C48B1AE.2030408@gmail.com> <672CA84A-1850-4B17-922F-AE75D4CF961B@inf-net.nl> In-Reply-To: <672CA84A-1850-4B17-922F-AE75D4CF961B@inf-net.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Another addressing model for AUTOCONF 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, 23 Jul 2010 12:10:25 -0000 Le 23/07/2010 12:58, Teco Boot a écrit : > Alex, > > Quick comments: > Your example 2001:1::/24 and 2001:2::/24 share a common prefix. WEll no, they are different prefixes, as implemented by IP stacks, as considered by the routing tables and their lookup algorithms, as considered by the ND tables. > Better use 2001:1::/32 and 2001:2::/32 or longer, e.g. /64. Why 32 instead of 24? > On your presso: > I would not use same ssid on APs in all vehicles. (slide 2, essid: "V3"). Thanks for the comment. It would indeed be good to have different ESSIDs within vehicles, in order to prevent potential interference. > And I dislike the address spoofing mode, suggested in slide 4. > So it so +1 on others remarks. > > Teco. > > > Op 22 jul 2010, om 23:01 heeft Alexandru Petrescu het volgende geschreven: > >> Addressing model we use, pdf 300Kb: >> >> http://dl.free.fr/m95j1Km7a >> (the username is left empty and password is 'password', without >> quotes. File stays there for 30 days.) >> >> Teco asked whether my draft contains an addressing model... true - it doesn't show so obviously >> (http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00). >> >> I said that there is an addressing model in this figure of the draft: >>> egress| |egress >>> ---- ---- ---- ---- ---- ---- >>> | LFN| |LFN | | MR | | MR | |LFN | |LFN | >>> ---- ---- ---- ---- ---- ---- >>> | | ingress| |ingress | | >>> --------------------- --------------------- >>> 2001:1::/24 2001:2::/24 >> >> ThomasC and Chris also expressed doubts with respect to LFN--MR--MR--LFN >> topology and link-local addresses; let me explain further. >> >> We are using this addressing model on several moving networks. See the pdf at the beginning of this email. They show MR-to-MR with a single addressing scheme, then with a double addressing scheme; (double is necessary for our plan.) >> >> And then a slide shows MR-to-MR-to-MR addressing model. >> >> There are some scalability remarks and a route propagation model (pencil >> and paper). >> >> The mechanism has been prototyped and demoed since about one year now, >> on three Mobile Routers and a bunch of LFNs, which shows it may work. We >> have great plans for demoing on vehicles. >> >> This is an addressing model we consider strongly. It needs later to >> auto-configure some prefixes, because currently MNPs are pre-configured >> in each moving network (this is the case in some deployments). >> >> This addressing model is important to us, and uses link-local addresses. >> >> Alex >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From alexandru.petrescu@gmail.com Fri Jul 23 05:10:34 2010 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 C8AEA3A683F for ; Fri, 23 Jul 2010 05:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.099, 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 9zPtMAt8TmtX for ; Fri, 23 Jul 2010 05:10:34 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 77F913A680A for ; Fri, 23 Jul 2010 05:10:33 -0700 (PDT) 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 o6NCAonQ032576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 14:10:50 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6NCAoVJ004400; Fri, 23 Jul 2010 14:10:50 +0200 (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 o6NCAnQn013906; Fri, 23 Jul 2010 14:10:50 +0200 Message-ID: <4C4986C9.7060706@gmail.com> Date: Fri, 23 Jul 2010 14:10:49 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Teco Boot References: <4C2A6BB7.1000900@piuha.net> <4C4899AD.4030808@gmail.com> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com> <4C495164.4080604@gmail.com> <08631826-F740-4FDD-8642-41E1D507D12B@inf-net.nl> In-Reply-To: <08631826-F740-4FDD-8642-41E1D507D12B@inf-net.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org autoconf@ietf.org" Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 23 Jul 2010 12:10:34 -0000 Le 23/07/2010 12:54, Teco Boot a écrit : > Op 23 jul 2010, om 10:23 heeft Alexandru Petrescu het volgende geschreven: > >>> And even worse, consider a setting where routers actually move in an >>> unknown patterns (i.e. are "mobile"); how would you update ESSIDs >>> and channels? >> >> Does such a setting really exist (pure random movements like in >> Brownian)? Example? >> >> For some wireless deployments studies have been performed to identify >> patterns: vehicular, urban citizen, more. For each there are possible >> plans on which WiFi would work good. >> >> Even the most arbitrary movements like in a battlefield have a very high >> degree of planning - the command and control is very centralized. > > Sorry, you disqualified yourself here. ? as if I tried to qualify myself to some form of competition?? Alex > > Teco. > > From alexandru.petrescu@gmail.com Fri Jul 23 05:15:32 2010 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 E36E33A694E for ; Fri, 23 Jul 2010 05:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.096, 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 078o49Aq++2c for ; Fri, 23 Jul 2010 05:15:30 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id CB7393A69ED for ; Fri, 23 Jul 2010 05:15:27 -0700 (PDT) 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 o6NCFfVj024549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 14:15:41 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6NCFeVd005672; Fri, 23 Jul 2010 14:15:40 +0200 (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 o6NCFeD3002176; Fri, 23 Jul 2010 14:15:40 +0200 Message-ID: <4C4987EC.3000500@gmail.com> Date: Fri, 23 Jul 2010 14:15:40 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Teco Boot References: <4C48B1AE.2030408@gmail.com> <672CA84A-1850-4B17-922F-AE75D4CF961B@inf-net.nl> In-Reply-To: <672CA84A-1850-4B17-922F-AE75D4CF961B@inf-net.nl> Content-Type: multipart/mixed; boundary="------------080602070808070200070205" Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Another addressing model for AUTOCONF 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, 23 Jul 2010 12:15:33 -0000 This is a multi-part message in MIME format. --------------080602070808070200070205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Le 23/07/2010 12:58, Teco Boot a écrit : > Alex, > > Quick comments: > Your example 2001:1::/24 and 2001:2::/24 share a common prefix. WEll no, they are different prefixes, as implemented by IP stacks, as considered by the routing tables and their lookup algorithms, as considered by the ND tables. > Better use 2001:1::/32 and 2001:2::/32 or longer, e.g. /64. Why 32 instead of 24? > On your presso: > I would not use same ssid on APs in all vehicles. (slide 2, essid: "V3"). Thanks for the comment. It would indeed be good to have different ESSIDs within vehicles, in order to prevent potential interference. However, we have noticed that within a vehicle there is little chance that WiFi signal gets outside, because of shielding - hence no risk of interference. > And I dislike the address spoofing mode, suggested in slide 4. WEll no, I don't suggest any address spoofing mode. What in slide4 makes you think so? I could explain. (see jpg attached). > So it so +1 on others remarks. It's still -1 on my side :-) Alex > > Teco. > > > Op 22 jul 2010, om 23:01 heeft Alexandru Petrescu het volgende geschreven: > >> Addressing model we use, pdf 300Kb: >> >> http://dl.free.fr/m95j1Km7a >> (the username is left empty and password is 'password', without >> quotes. File stays there for 30 days.) >> >> Teco asked whether my draft contains an addressing model... true - it doesn't show so obviously >> (http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00). >> >> I said that there is an addressing model in this figure of the draft: >>> egress| |egress >>> ---- ---- ---- ---- ---- ---- >>> | LFN| |LFN | | MR | | MR | |LFN | |LFN | >>> ---- ---- ---- ---- ---- ---- >>> | | ingress| |ingress | | >>> --------------------- --------------------- >>> 2001:1::/24 2001:2::/24 >> >> ThomasC and Chris also expressed doubts with respect to LFN--MR--MR--LFN >> topology and link-local addresses; let me explain further. >> >> We are using this addressing model on several moving networks. See the pdf at the beginning of this email. They show MR-to-MR with a single addressing scheme, then with a double addressing scheme; (double is necessary for our plan.) >> >> And then a slide shows MR-to-MR-to-MR addressing model. >> >> There are some scalability remarks and a route propagation model (pencil >> and paper). >> >> The mechanism has been prototyped and demoed since about one year now, >> on three Mobile Routers and a bunch of LFNs, which shows it may work. We >> have great plans for demoing on vehicles. >> >> This is an addressing model we consider strongly. It needs later to >> auto-configure some prefixes, because currently MNPs are pre-configured >> in each moving network (this is the case in some deployments). >> >> This addressing model is important to us, and uses link-local addresses. >> >> Alex >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > --------------080602070808070200070205 Content-Type: image/jpeg; name="slide4.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slide4.jpg" /9j/4AAQSkZJRgABAAEAYABgAAD//gAfTEVBRCBUZWNobm9sb2dpZXMgSW5jLiBWMS4wMQD/ 2wBDACAWGBwYFCAcGhwkIiAmMFE1MCwsMGNHSztRdmh8enRocnCCkrufgoqxjHByo96lscHH 0tTSfp3m9uTM9LvO0sn/xADSAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgsQAAIBAwMC BAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBka JSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqS k5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq 8fLz9PX29/j5+v/AAAsIAfIChgEBEQD/2gAIAQEAAD8A6CiiiiiiiiiiiiiiiiiiiuW1OF7j WrhUY7kTcuPYA1uaRdfa7CN2OXX5W+oq7XK6s7X09zKGPk22FX0Jzj/Gug0sk6bbknJ2CsW6 tkvfEckErMFI/hPP3asTaEtvE0tlcTJKoyMt19uMVb0W9e9s90vMiHaT6+9aNFZej3k9zNdr M+4RvheAMDmtSiiiisfxMSNPQA9ZBn8jUGiu9nfPZSMSrqHjz9M/5+lb9ZWuzuIo7SE/vJ2x x6VV8Op5V5eRAkhDj8ian8TEjT056yD+RqODw/ayW8chkmDMoPBHXH0pLKa4sdW+wTStLG/3 C3UVu0Vl6jeTwalZxRvhJDhhgHPNalFFFFIfumuNtjLAPt0bN+7lAb3BrsY3WWNZEOVYZBps 8qwQPK/3UBJrk8Stc215Ix3zykj2AIrqL8kWFwQcHy2/lWDpGj299Z+bK8obcRhSMfyqS6jm 0OWKSCZ3t2OCjmuhUhlDDoRmlooooooooooooooooooooooooooooooooooooooorCj/AORq l/3P/ZRRpx+wazPZniOX5k/n/n6Vo6pdfZLCSQH5iNq/U1ly2v2bwywYfO5Dt+JFaulf8gy3 /wBwVi3N0ln4kkmkDFQMYXr92rM2urcoYLOGQzSfKN+Bj9avaTYmws/Lcgux3Nir1Vr6yjv4 RFKzqoO75Tiuf0vSoLyW5WR5AImwu0j39vatuZ49J0s7MsIxhdx5JNZ9rpkmpwi4v7iU7+VR TgAUy6in0N45beZ5LcnDI5rfjcSRq68qwBFOrH8Tf8g9P+ug/kah1aNoYbO+i+9EFB+nb/Pv W3DKs0KSoflYAisiy/0/Wpro8xQfIn1/zmm6J/yFL/8A3j/M1J4m/wCQen/XQfyNRw+IbWK3 jQxzFlUDoMdPrTtPgmvtQGpTqETH7tQc1tUh5GK5i/0uC31C1gR5Csx+YkjI57cVtWGlQWEj PE8jFhg7iP8ACqDy3GrahJbwzNDbRfeK9Wp0mgrBG0lncTJKBkZbr7cYq1ot897akS/62M4Y +vvWjSN90/Sue0S3F1p17Cf4jx7HHFXPD1wXtWt5PvwNjHtSa9K0nk2MX35mGfYf5/lVfWY1 hn02NBhUOB+YrX1D/kH3H/XNv5Vg6RrFvY2fkypKW3E5UDH86mkeTX5kWJPLtomyzMRk/hW+ AAAB0FLRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRWHF/yNcn+7/wCyineIImjEF7H9 +JgD9O3+feormddX1C1gjOYlHmP/AIf0/Gruv/8AIJl+q/zFT6V/yDLf/cFZif8AI2P9P/Za ua1ZLc2bSKv76MblI6/Sn6RdfbdPUucuvyvVb/hHLP8A56T/APfQ/wAK0bO1SztxDEWKgk5Y 81l+H/8Aj4vv9/8Aqam8RqW0wkdFcE1c011k063ZTkbAPyFUfErqunqhPzM4wKmOnJd6ZbQT s67FU/Kcc4qKPw9aRyK6yTZUgjLD/Cm+Jv8AkHp/10H8jV5oBc6YIW6PGB+OKw7bUjbaRPbO cTxkog78/wCHNbOkWv2TT40Iw7fM31NUNE/5Cl//ALx/mak8Tf8AIPT/AK6D+RrQgjSWwiSR QymMZBHtWVpbNYarNYMT5bcx5/z6fyq7faRb30wlleUMBt+UjH8qLLR7exn86J5S2MYYjH8q qax/yGNP/wB4fzFbdYPh0hLq8iY/Pu6fQnNbrMFUsxwAMk1h+HE3m7k5COwA/X/Gpf8AhHLP /npP/wB9D/CtC0tUs7XyYixUZOWPNZfhj/U3H++P5U2cjTdfWUnbDcD5j2Hr+tP0z/TtWuL0 8pH8kf8An/PWk1//AI/bD/e/qK1NQ/5B9x/1zb+VUfDfOmEH++f6VWvk/srVorqIbYZeHA6e /wDjW8CCMjpS0UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUVnJp8q6096WTy2XGOc9MV cuYVuLaSFujrj6VQ0bS20/zGlZGkbgFewqzqdq95YvBGVDNjBbp1qSyha3s4oXILIoBI6VUX TpRrbXu5PLIxjJz0xWieRg1m6bp01jdzkOht5OVUZyPStOisaTSryC7kn0+5SMSHLK46foa0 Y7dms/Iun84kEOcYzWaulX9mSLC8VYyc7ZB0/Q1JDpMklwtxqFx57r0UDCitaiqGsWMl/arF EyqwcN83SrkSlIkQ9VUCsm40UzaqLncvkkhmU9c1s1nadp8tpeXUzshWU5ULnPUnmnaxZSX9 qsUTIrB93zHjoatwIYoI4yclVAOPpVDU9OlubmC4tnRJYzyWyMj8K06Kz9V043yxtHJ5csZy pp1hBfxuzXtysgxhVUfr0FQ3ukmW5+1Wkxgn7nHBqJtO1O5Ux3d8nlHqIx1/QVp2ttHaQLDC MKP196mpDyCKz9HsJbCOVZWRi7ZG3NO1ewN/bBEKrIrZUt096l060FlZpDkFhyxHc1Bqeny3 lxbSRsgETZbdn1HT8quXURmtZYlIBdCoz7iq2k2cljZ+VKys24n5elO1Sy+3WbRAgODlSexq Sxilhs44p2VnQYJXp7VYoooooooooooooooooooooooooooooooooooooooooooooooooooo oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooq tJKy3RULIcR/LhTtJ+vTt+tVBNd/Z9ztKCxP3IiWXA6cqP1H41YtY2a5kllcu6gIMgccAnHH qaaxnM/HmbJJPf5Qv9Dg1Er3c0ZMjyx5kUYRDleeeq9Pz+tPSW8MuwqwXJGSo7Hr+I4oie6k AG6RQ5UEmPG08lsZHTpyaktPNEkxlDKNxK8feHTJ9+OlRwSshBKyEtFv+VCQWPJ56dhSfvkj kSXewSIgE9HLdPqe1X0BCKDyQKdRRRRRRRRRRRRRSMcKTjOB0FZkYuoVO9pSXK5ZQW2ggngH POePT2qSNrs+WzM/AUFSg5OCTnj6CovtF2Y3ZTIxyoIMeChIJOAFJ9OxqxcNci02nqdo8xAx b3O0AEfgfypqGdSEQymPZncVOS2M/wAWT37+mKZE90rxpulKKgYl0OX45B+X+oP1pd93GgV3 lbJGWWMEj5c8DHrjrTUW4VAF3oQo3MEBJwuT1HqakjluGu0R2dfVdnykbeucep7Urm4847RI Vkftn5Qv9Dg1FG13LGhleVN0gBCIcrx7r0zj1+tPSW8abaVYLkgEr6Hr+I4oie6kAG6QByoJ MeNp5LYBHTpyafZmZEmaUMMEsAR1B7/X2qExTsYSrOFUKXK7huLHk8Ht75pUWWQynfMHd9oG 112jPucdB2FPjaV3j8wMGMvAPYBcE/TP86v0UUUUUUUUUUVRlnmX7R5aSFwwC5RsBeMkHBz3 6ZpnmXe6JS8mflJIj4IJ5ySOMD6UsMTfZCyuxkncEuAAQCfUD0pjy3nGFdC7YLbSduAB0weC c/405mukZzG0rM0hXDL8qjbwRx0zQ0t2Y1P7xGdSVAjzzxgHjgdTSz/amXcAzfveE28Ko7+p 5FTTkiSNeW2Iz9OWIxjj8ai8yXyoXQSt5SZYFSC54GMHr3qS1D+b85JZYlDk/wB7k/5+tW6K KKKKKKKKKKKKKZJIkSbnOBUfmTvykIUesjYP5DNGbr+7D+Z/wpqLcRrtSOBR6Akf0p2br+7D +Z/wozdf3YfzP+FGbr+7D+Z/wozdf3YfzP8AhRm6/uw/mf8ACkAuVACpAAOgBP8AhQRcnGUg ODnkn/Clzdf3YfzP+FGbr+7D+Z/wozdf3YfzP+FGbr+7D+Z/wozdf3YfzP8AhRm6/uw/mf8A CjN1/dh/M/4UZuv7sP5n/CgG67rD/wB9H/Cg3DR/6+PYP76nco/w/Kp+vSiiimSypCm5zgdg Bkn6DvUfmXD8pCqj/po3P5DP86M3X92H8z/hQftRGCsOPqf8KZHHPEu2KK3RfRcgfyp+br+7 D+Z/wozdf3YfzP8AhRm6/uw/mf8ACjN1/dh/M/4UZuv7sP5n/CmLHMsjSLFbh2+8wzk/U4p+ br+7D+Z/wozdf3YfzP8AhRm6/uw/mf8ACjN1/dh/M/4Uf6V/dh/M/wCFIPtIAAWAAdACf8KX N1/dh/M/4UmLndu2QZxjOT/hSg3XdYf++j/hSfaChAuIzHn+IHK5+vb8QKsUUUUhIUEkgAdS agFw8v8AqIty/wB9ztB+nc/lS5uv7sP/AH0f8KM3X92H8z/hRm6/uw/mf8KM3X92H8z/AIUZ uv7sP5n/AApGW5dSrpAynggkkH9KB9qAwFhAHuf8KXN1/dh/M/4UZuv7sP5n/CjN1/dh/M/4 UZuv7sP5n/Ckxc5B2QZHQ5P+FLm6/uw/mf8ACkAuRnCQDJycE/4Uubr+7D+Z/wAKM3X92H8z /hRm6/uw/mf8KM3X92H8z/hQZZk5khyvrG279MD9M1KjrIgZGDKe4p1FFFFFFFFV4B5zfaGO Qf8AVjsF9fxqBb5ysm5VUhwE91Jxn9DUjXvyZWGTcdu0NgbgTjPWpZJXW4ijVBtfOWJ6YHp+ VTUUVE8pRsbc+nNIJjnGzoQG56c4p3m/KWKkYJFMWc+Y4ZCAuPw+vNOjlMgJ2H8KUSHy9+w9 M4zSs5Cbtp6Zpom5IYAY/U0+Nt6BsYz2p1FFFFV4x5E3lD/VuMoP7p7j6d/zqxRSEgAk9BVe EbgbqUckEqD/AAr/AI+tRQ3rtFGZVVH3HzB6LjOf5U83uWVFhcOzAYbHQ556+xp1zNLGwCbA OMBhkufQc8fWrNFFRNMVcrt+nNIsxJxs6Haee9OEvyBip5OMfjimLcHLbkIA/TkjmnRyl1J2 HjsPp70vmHy1cL1GeTgCjzD5e7Yemaas3XIHH6mpEbeitjGRnFOooopCAQQRkHsaghzDMYCc oRujz2Hcfhx+dWKKKrsPtE5Q8xR9R/ebr+Q/z0qJ710kuF2rhB+7P94jGR+ZFSPdqjEFHIHB cYxnGcdaUzSfZEl2rGxALFzwg9TzT7aRpYFdsZPcdD71LRUckhjxhcj600TscAIMkZHPanLJ uJwp+6CPfNMM53qFQkH9aVZ9z4CnHb8qeHJZhtPBpEkLEgoQR2BpvnfMBgc+vpnFPSQOWwOB 39afRRRRVeUeRIJl4ViBIP8A2arFFFFFFFFQ3jmOzncdVjYj8qkQARqo4AGBiq7WELCINu/d KVHPUEY5ojsY4wMM2QwOcKOnbgVOYwZlkOcqCB6c4/wp9FFMMSEk4PzdeTR5SAg46e9V7udb cMDGWyNwAb73OD/OmGWIBnCA8nGXPzYIGfzNTW7KzEDZwAfkct6j09qm2KBjtjGM0FFOOvGO 57UnlISSVzn16UqqqLtUYHpTqKa0iLnc6jAycnpTWmiXO6RBjrlhxTkkRxlHVvoc1Fc4Hktj kSDHtnj+tT0VBe/8ecvupFLI0MkLIZFCsh5DDp61DLFaNMWeVQzR+Xt3gZFOhs4o9jq5JB3b sKM8Y7DHen/Zv9JMwmkBOMrhcY9Omf1qeiimeUmTweevJoESKQQOR71Xu51twVMZbjcoDYyc 8/zzUZmiUFgi43YBaQgHnGTx6k1YgKtnG3IAPyuW/WpDEhUKQcDpyaXYpxnPHuaTykySVzn1 5pyqEUKowB2paKaZEBwXUHOMZ7+lNM0QGTKgA7lh/ntTkdJBlGVh6g5qOcfvYCOCH/8AZTU1 FFV7Fi0DMeplk/8AQyKY8Fs6KGl4V/NB3D1/lTHtrQSOXmCl88ZUYJ644zVhovMRNkzrt6Mm Of0xUkaLGgRegGBTqKayKzAnOR0wSKb5KYxj9TTZmWEBiOCQpOcYFVoZ45tp8ooT1y5+XnAH 86fbSpLsIWMbhwFkJI4+nBq1tGT79eaRY1XpkfiaPKTjjoMDmlVEQkqoBPXFOooooqO4UPby KehUj9KdGS0ak9SBTqKKKKKKr6h/yDrn/rk38jU6/dH0paKKKKKKKrzpC9xB5hw4LbB68c1W 2RJGkcOdsYK72PHJB/HpThMRIXEibiADkHH+easxXAZgjjax6dwaVJ43fYpOeRypA4681LRR RVO9tnuJIwB+7IKyc9uo/UVGlvcGOPflWJ3Pgjg7gf5VbjV1lfcxZcDBP45pt192L/rqv86n oqC9/wCPST6VT+xTebuwMeZt6/8ALPOf58VYjhm813ZmX5cdQc8t/QirEQYRIH+8FGc+tPoo oooqvMkElzEJG/eIGZR6jof51WVYljjEG7bGOGc4HXNPWYiRnEqbjgHKnFWIrgMwRxtY9O4N LHPHI21Cc4zypGR+NS0UUVQu7aWS4LxqCoXcOf4x0/nTlt5gI1ywChckEcHnP8xViFXVpN5J BYbST2wP65pJ/vw/9dP6GpqKKraf/wAex/66Sf8AobVV+xTebuwMeZt6/wDLPOf58VaSKX7Q zszKvOMEHPNSwhhEofO7HOTmpKKKKKgvBE1syzsVjbAJHbnj9ahdIo5ZPLDGRirMM8DHSo1f Ysa+av7sYXgntirCXOBmQDb/AHl6VI08aPsYnPH8Jxz056VLRRRRRRTJf9U/+6aIv9Un+6Kf RRRRRRVfUP8AkHXP/XJv5Gp1+6PpS0UUUUUUVUvYy7RMOoJA+p/yaq+X15yDnBz2FQr5bSPE gUFMFh/dz3qfYxfcPlIzgA9x1q3awnaJHYkkswHYZOas0UUVWuZpY5FWMoBxncpPVgPX3qFr 2VR0QsB9wA5br059qjW9lEzBXjkBIwR0PTgc9fzq5dfdi/66r/Op6Kgvf+PST6VB9pnDEnyy u7GApzjdjrmo3vZDGw8yJRtJ34OM4+716/5xU1pcySylGAwAfqMHHPPfr2q5RRRRRVO8iLSx yA8/cH41VMfuOc4OewqKPy3Z0j2/u2G4D+EnvU+xt+QNpGcAHuOtXLWLaiOWZjtwM9AKsUUU VWnmlWYJGUAwv3lJ6nHrUH26XAOI84+7g5HGd30/zmkS8kEpUMkgL9R0PQYHP+NW5/vw/wDX T+hqaiiq2n/8ex/66Sf+htUZuZhIf9Xt3EY2nONwHr7037bITgtEoPViDhOvB568UafdSTCN GwRs59e3J57/AEq/RRRRUF5H5tsynGOCc+gOapFTnJ+bIBIz3PT+dQv5aTJGcF5Mgf7QFS7f lXgAAZJB7f5zViCFnZvMc4Uhdo7kGrtFFFFFFMl/1T/7poi/1Sf7op9FFFFFFV9Q/wCQdc/9 cm/kanX7o+lLRRRRRRRUN0D5YYDOxg1VCoGRgkDPTuvY1Ths447t5hIxZ+oz1ye3FXSSMluo 3E/U8Yq7EuyJV7gc0+iiioJ7qOB0V8/N05H+P8qYl4GdwRsGwMgfALZz7+1It8uwFo3DAZYY HAwDnr7025uFaNX2OFWQHJHBwe1QyTSyN85YcZ8tDjA9zUa8E7FIP/TOXJ/LvUj3LNbPHIQw YfK47+x96s/bozIY1VmcHAAI5/Xjp3povcwxOoDliQyrjI4J9fan/bUyAEc7jhTgfMfQc1Or blDYIz2PUU6iiiiobnIjDDnYwbFVCoHy9cZ6d17GqdvZxw3EkiyOS/Udjk544q6T1LYyNxP1 ParsK7IlXoQOafRRRUE93HBIqPnLd8j/ABzUf2ziXK7Cq5QPjLcH3pwvFxzG4I+8OPl6c9fe myXCt5blWVA+dxHBGDyKgluJJT1ZVPKohwSPUntUKj5jtX5v9iUbv/r1at7oqVWRt6McByME H0NS6f8A8ex/66Sf+htQb2PzWiCsXBxgEc/rx+NNF4THGQoLliGQY3Ac+/tTvtseAQj7T0OB yfTr71Ojb1ztZfZutOooopsi7o2UdSCKockDtkDH+8OMVTns45buOYu6smMD+7g59KuAZUL0 yMDPpnJNWrXlXfGN7Ej6VPRRRRRRTJf9U/8AumiL/VJ/uin0UUUUUVX1D/kHXP8A1yb+Rqdf uj6UtFFFRR3EcjbVJyRkZUjP504SoVDbgAemeKVHSRdyMrD1U5p1IRkYPSqsluy/cG5eoGcF fpUKhzK4AkJ4yOh/GrENuQQzgADoo7VZooooqKW3jlbLgk+zEfyojt4o92xSNwAOWJ49P1rO S6tptWezKjaFwGDHlh1HXpgDj2qS/VIHiKrwWyQST0//AFmoCcgA8k4Jz3Y9z+FTzWrRFMsp 3sFyFClT2PFQMd0TE/xIH/ENjNXZYraKBrhwwCru++3HfjniotJuIr6yQ7ADGSpXJ4/yDVr7 JDnOw+3zHj6enSpUVUUKowB0p1RRXEcpAQnkbhlSMj8aXzo9gfeoUjcCTjj1pysrqGRgwPcH NOpCMjB6VVkt2X7g3KOQM4K/Q1AgdpJABITnBweeg6ntVmG3IIZwAB0Udqs0UUUVFJbxStud STx0YjOOlVNQeHT7CaRR8zjaAzE5PbqaktPs97bx3AXlxkgMevGQfypt3BEvlIqkb5ADyTxz +XWqpYlCx53Auw9ecAfSpZrYxQiR2RhxuAUD8jUWCQQxyWDK3uV5zVzSyWsVJ6l3P/j5qnBc 20+rzW2DhfuMHP3s5bHP+cVqLDGqKgXhDkcn/PemfZIB/AemMbj/AJzx1qVEWNdqjA+uaYbi MSFCTkEL904z9elO8xPm+YDacHPGD/k0LIjsVR1Yr1AOcU+iq81uSS0YBz95T0NVmDCRARID zgdT+FSpbs5+YFFPXJyzVbAAAA4ApaKKKKKKZL/qn/3TRF/qk/3RT6KKKKKKr6h/yDrn/rk3 8jU6/dH0paKKjnmS3iMj5wOw6mqVp5kqRywvkoCrJJxt5BxwPT609rKU7CXQ4UqQQeMg9Dmk sbtGlaDLZydmSWBx2BPJq/RRUEX/AB9z/Rf61PRRRRRRRVNIoxqkpEa5ESEcd9zUaiAEjkIz scceoqmVAAXIIxhSeA6/XsRQSx5dzx0LyA7foO5pJOIyACMrgA9lHOT9TWuyqy7WUFfQjiq2 moq2aFVAJzkgdeTVuiormdLeLe+euAB1JqnZiR4YpYXD7U2Mr8YPHHA/zxStYyYT50YKm0gg jjA6EHjpTrC8SUmLLbhkqScgjPY9T+NXqKKrWv8Ax83n/XQf+gLVmiiiiiiqupKrafcblBxE xGR04NTxIqRgIoUegGKgv93lxlBlg4I/AE1RO3AwQF52FuhB6qaMt0LcL93fICB/jSgE7VQH LDagPU56tVzTV22YUdBJIP8Ax802CKManc4jUYSMjA6feq7RSEhQSTgDkms2GUXcsvkuyner qrjAYAAZ9f8AIqaS0mlBLPGrFw23BIyAPp6VElwlrdmJycHrtYsoJOec9OvatKiioJf+PuD6 N/Sp6KKKKKKKKZL/AKp/900Rf6pP90U+iiiiiiq+of8AIOuf+uTfyNTr90fSlooqhq/+pi9B J/Q1HpG7zJz/AA/L+fOf6Vovkxtjrg4rAtmCSW7L0UggD0A5/TNaTXkrbgsYQhSeT1PGOo96 kFzIZFyqBd2xgDkg5I68fyq3WUt5I0srom3coIz6bWI7e1WDdy8jailBlh1z06dPWrtFFFFF FVk/5Ccv/XFP/Qmp1192L/rov86jks+SYWCA8lCMqfwqNLKUN96JPdVyf1p88CQ2cuMliOWP U1cqtp//AB5R/j/M1ZorO1fOIPTcfzx/+ujSPuTY6b/1wP8A61W7wMbOcJ94xtt+uKxreQR3 EMgBIXJwPTaa0Wu5icLGFIIGCTz8wHcdMGnrcyNJHwoRjtIHJBwe/wD9arTHapJ7c1lR3cm+ 7ZEClju57fuxjt7VaN1LuI2ouwjcOucnHB4q5RRRRRVfUP8AkHXP/XJv5Gp1+6PpUU/34f8A rp/Q0yWzDMWibYW6jGVP4VCtlKGzmFfcLn9DVmC3WElslnPVm60zT/8Aj2P/AF0k/wDQ2psP /ITuv+ucf/s1W6Kr34JsZx/sHP071m6f/wAf0ePQ5+mP/wBVbVc/ef6653/3jn+n6YrSF5Id qiPnIG455wwB7ULdTmEYVPMChuudw57cc8VcRt6K3qAaoXd0yXYCJkoHAJ9doNSC6lDbCFBZ yFYnP8WORx61ZgcyRKzYz3x0qSiiiiiimS/6p/8AdNEX+qT/AHRT6KKKKKKr6h/yDrn/AK5N /I1Ov3R9KWiiobi3W4TY/So4rJIU2ocDOT70/wCz/wC1+lRJp0SSGRTzz9BThZRjoqD/AICK X7Gm4Nhdw77eaF3R3kcYbKtG7EY7grj+ZpsUMX2qceUmPlONo681YMUZIJjUkHIJHenBgSQC MjtS0UUUUVWT/kJy/wDXFP8A0Jqddfdi/wCuq/zqeioL3/j0k+lT1W0//jyj/H+ZqzRUNzbL coFfoOaZFZrEgRDgfSnfZ/8Aa/Soo9OhjYle4xg8gD0p4soxjAUY6fL0oFmgYMAu4dDt5pYm CXEkJI+VVbOfUt/hUVrHD9ou12R4EowMD+4tWjFGWDFFJByDjpTgwOcEHHWlooooqvqH/IOu f+uTfyNTr90fSop/vw/9dP6GpqKKraf/AMex/wCukn/obU2H/kJ3X/XOP/2ardFNkXehU96q w6fHCSUJyeOecCpfs/8AtfpUT6dE8okY/Nx9Din/AGKPJOFyevy9aDZRkYIUj0K02dGgRHR8 HzEXp2LAH9DSzRRteQkopLKwJI6jipzFGRgxpj02inABQAoAA6AUtFFFFFFMl/1T/wC6aIv9 Un+6KfRRRRRRVfUP+Qdc/wDXJv5Gp1+6PpS0UUUUUUVzs9zMtywM0oUs+cORjB4qBbmYkO0z hwMAFznk8jr7CrMM0pmX97MMSKDmQnPIrWukneRPKLBR6HocjryP61CltKpLBXyABjf1GWz3 9xVizjMcbZj8sk528YHHbBqxRRRRVZAf7SlOOPJTn8Wp1192L/rqv86noqC9/wCPST6VPWXE JVhjdA2QpGQucfNz2NKxu2OcybtvAAIzwefT04xmrMJIVvmmVMnblSTjA9RnrmofszGH/Vx5 aTvFzjd355qQW3+k52RbVRf+WfGcnpzxRp6bIlBQK20Z/dFT+JPWoLyKUyXCojlZhtJA6YGf 15FJGk/71zGwE65wM5GOgI7HFTlcIxtkeJQ6HAXbu554x6Vz5kZizNtL5Yu20cnnFSxnZPGU AyJFxlOc59OK3JkuHmQjcq4GQDwD3zz/AI1EltMkX+rcnABTzMZGzHr61btYzHFgrsJJO3AA H0wTU1FFFV78E6fcgDJMTcfganX7o+lRT/fh/wCun9DU1FFVtP8A+PY/9dJP/Q2qCRGa9uMA 4Pk9B1+Y0xmu3j+YuvrhW4ODxwAcZxU0Xm+ZlzMp53dSO2Mdvy96XyTJds5AZQo5kj56t06f 5xUSWreRbAxx5yM5i6fKevPNSLGFuzlE/hwfJJ7dj2pb4SLLDLGjOY8nCjr0GKqQQzxyI3ls RC5BJyC24ncQMc9RVqNB5oHlOJtzZkAxgc856Htx/hVLUnlWGIF3yELYJIyQeCapG7mLDE8g GByZDwfzpwuZsA+dKRnG4SN61taazNZqXZmO5hljk9TVuiiiiiimS/6p/wDdNEX+qT/dFPoo ooooqOeMSwSRno6lfzFEDiSBHHGR09KkooooooorGl0ueR3JWMgsSMuehOfSk/su4wRsj56/ Of8AClXTJyw3JEVLAsN2cjj2oWKCNwn2S3bLHrGMn5iOOe2KakUJj+eO3HGdwjQ84+70/TrV i4tLUwgCC23FgNqoFP3gOo/I0i6bbfaSv2SHCopI3Hjk+3NRLY2y2cLvbQjcVySx547nHFWW srP7E7JbQfcOCoDfris9oISyRi3j3bTDgIAS2Rk/lzVhbayaOIXEEUYCsrHaFyw45I/E1NZJ ClyPJEanbhhsVTjAOOOc9/Src5DSwx9y278B3/PH51PRUVyhktpFX7xU4+tPjdZI1dTlWGRU P2Cz/wCfSD/v2KPsFn/z6Qf9+xR9gs/+fSD/AL9ij7BZ/wDPpB/37FH2Cz/59IP+/Yo+wWf/ AD6Qf9+xR9gs/wDn0g/79iqey2Zgq2EABbAJjHIzj0pI4oTAhaxtt2UDHaOjY56dajfS5RJJ sjh2FiQM44/KgaXM0iGRISoYE5OeM/Sm+XDHEqi0t2bZnmMEnOeRz2pVhgxzFb5BO3EaEOeO M4569v6VPPZ2rBVWC2Yl8YVQvr3H+eKT+zrbz2H2SHCop6ng8+3P41F9htUhty9tAu/qWcgH 5T3xxVmextPsEhS3gB8s4ZVBxx2NUWghd9oto9xTysCMD5sjJH5/pUi21m0YFxDHGUTAwoBL AkH6npx71asUhW6cwiIYBB2oqkc9OOfrmrMx3XMEYPQlzx2Ax/Mj8qnooqvaAIJYu6yMf++j u/rTpLS2lcvJbxOx6syAk037BZ/8+kH/AH7FH2Cz/wCfSD/v2KPsFn/z6Qf9+xR9gs/+fSD/ AL9ij7BZ/wDPpB/37FH2Cz/59IP+/Yqrcx2kLlFsIWwASfLHGeB2qMRQDO6ztQDjDFBhTtz6 dKSTT2lCtDBDGCCGAXZnng4qMaVODkJEOc/fP+FL/ZVxnOyPP++f8K0rGF4LYRyY3ZJ4Oepq xRRRRRRUV02y3fH3iNq/U8CpFG1Qo7DFLRRRRRRRVdt1u5dVLRMcsFGSp9QPSpo5EkXcjBh6 g06iiiiiiiiiiiiiimGMFt2Wz/vHH5U+io5Zki4OWc9EXkmmwxtuaWXHmNxgdFHpU1FFVjut XJ2loGOflGSh+np/n6To6yKGRgynuDmnUUUUUVH5MWSfLTJOT8o5NO8tAMbFxx29OlOooooo opgjAbdls/7xxT6KilnWM7Rl5D0Rep/wpIImUtJLjzX+9joB2AqaiioZkdXE0QywGGX+8P8A GnRTRy5Cn5h1U8EfUVJRRRRRTGjjdgzIrMOhI5FIYIiu0xIV9NoxTkRUXaihR6AYp1FFFFFF FFMkkSJdzsFHvUSK08qyyAqi8oh6k+p/w/yLFFFFFFFFFFRPbwu+9o13/wB7GD+dJ9mj/wBv /vtv8aPs0f8At/8Afbf40fZo/wDb/wC+2/xo+zR/7f8A323+NH2aP/b/AO+2/wAaPs0f+3/3 23+NH2aP/b/77b/Gj7NH/t/99t/jR9mj/wBv/vtv8aPs0f8At/8Afbf40fZo/wDb/wC+2/xo +zR/7f8A323+NH2aP/b/AO+2/wAaPs0f+3/323+NH2aP/b/77b/Gj7NH/t/99t/jR9mj/wBv /vtv8aPs0Xox+rn/ABp8cUcQIjRUz1wMZp9FFFFRNbQs5cxqGPVhwT+NJ9mj/wBv/vtv8aPs 0f8At/8Afbf40fZo/wDb/wC+2/xo+zR/7f8A323+NH2aP/b/AO+2/wAaPs0f+3/323+NH2aP /b/77b/Gj7NH/t/99t/jR9mj/wBv/vtv8aPs0f8At/8Afbf40fZo/wDb/wC+2/xo+zR/7f8A 323+NH2aP/b/AO+2/wAaPs0f+3/323+NH2aP/b/77b/Gj7NH/t/99t/jR9mj/wBv/vtv8aPs 0XcMfq5P9afHFHEMRoqDrhRin0UUUUySGOXHmRqxHQkdKZ9mi9GH0c/40fZo/wDb/wC+2/xo +zR/7f8A323+NH2aP/b/AO+2/wAaPs0f+3/323+NH2aP/b/77b/Gj7NH/t/99t/jR9mj/wBv /vtv8aPs0f8At/8Afbf40fZo/wDb/wC+2/xo+zR/7f8A323+NH2aP/b/AO+2/wAaPs0f+3/3 23+NH2aP/b/77b/Gj7NH/t/99t/jR9mj/wBv/vtv8aPs0f8At/8Afbf40fZov9v/AL7b/GnJ BFG+9Y1DdN2OfzqSiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiqMmsWEUjRvPhlOC NjHn8qlttQtLo7YZ1Zv7vQ/kas0UUUUUUUUUUUUUUUVUn1CG3vIrZw++ToQOB9at0UUUUUUU UUUUUUUh4Gaqabf/ANoRPII/L2ttxuzmrlFMlfy4nfGdoJxUGnXn261E3l+XkkYzmrVVNTvP sNoZFAZydqA9zViEyGFDKAJCBuC9M0+iiiiiiiiiqt9qENgqGYMd5wAoyaW+uxZ2bXBXdjGF zjOalt5DNbxyldhdQ23OcZqSiiiiiiiqSX4fU3slj+4u4vu/p+NXaKKKKKKKKKKKKgvZJYbS SSAKXQZAYcH1osrkXdpHMONw5Hoe9ZGkQQz39/50SSYk43qDjk07XbGCC2F1bosMkbD7gxmt FLwJpiXcoOPLDMF61DPrdpBHGzFyXUMEUDIB9eat/aoRbC4ZwsRUNluODWe3iGyD7QJSP7wX j+ea0La5huovMgcOv8qjbUIEu3t3JVkTeWP3cVU/4SCx83ZmTH9/bx/j+lacbrIiujBlYZBH eqV3q9paOUdy7jqqDJH9KLPV7S8cRxsyyHorjBNW5po4ImklcIi9SazG8RWSsQEmYeoUc/rV mw1WC/laOJJFKjJ3Af41Hc65ZW7lNzSMDgiMZx+NTWWpW18SIWIcDJRhg1T1+/iit3tCr+ZI oIIHHX/61M0vWbcRW9oUl8zATOBjP51fuLi2jv4IpYt0z/cfaDt/GrMsscEZklcIg6k1mN4h sg+0CUj+8F4/nmtC2uYbqLzIHDr/ACpk19FBdR277g0gJB4wMetVJNfsUl2Auw/vqvFaMM0c 8SyRMGRuhFPqo+oQR3b27kqyJvLH7uKrLr9iZdmZAP75Xj/Gp7zVbSzA8x9zEZCpycU6x1G3 vgfJYhh1VhgirEsscEZklcIg6k1mN4hsg+0CUj+8F4/nmtC2uYbqLzIHDr/KkuruGzi8yd9q 9B6mqcGuWdw/lgvGTwN4wDUPhn/j0m/66f0FXr3Ubax4mf5iMhFGTUNrrVndSCMM0bE4AcYz Vy6/49Zf9w/yqh4d/wCQWP8AfNalY2oH7TrdpbdUT5yP8/StmqQ1S2zPuYosDbWZhwT7etQw a7ZTTCIF0JOAzLgGtOs251yyt3KbmkYHB8sZx+NWLLULe+UmFjkdVYYIpZb6GG7S3fO5lLZ4 woHr+VVH1+xSXYC7D++q8VpI6yIroQysMgjvVS91W1sm2SOWf+4gyaSy1W1vX2RMyv12uMGn XFxbfbYbWWLzJW+ZSVBC+/P0qn4iYvFb24PMsn+f51rqoVQo6AYFLWdd61Z2shjZmkccEIM4 o/tm0MSOhZy7BdgHzAn2q3dXCWtu80mdq9cdaqz6zaW8aM7MWZQ2wDLDPr2FTWN/BfIWhJyv VWGCKluLmK1iMkzhFHr3qjDr1lNLsy8fOAzjANQ6L++vr656hn2qfb/OK2arS30UV2ls27ey ls8YA9/yqo+v2KS7AXYf31XitKORJY1kjYMjDII71TvdVtbJtkjFn/uIMkVGuuWTW7TBm+XG Ux81XmmVLczsCFC7iD1AxVNtYtEtUncsu8EqhHzH8KfY6rbXzFIiyuOdrjBq3JIkSF5GCqvJ JPSsx/ENir7R5rD+8F4/U5rQt54rmISwsGQ96rHVrVTPvZlELbSSOp9B+VPsb6HUY3aJXCqc EOKpaE3kzXdmekT5X6f5xVGzvJrS/vfJtHuN0hzszxyfY1Zmjv8AWGRJIDa24OTuPJq9qqLH o8yKMKqAAUzQraOKwjlAzJKMsx6/Sq2rj7RqVnZE4jJ3MB3/AM4NbCxRrH5aooTGNoHFY1kg s/EM1vHxFIuQvYd/8abcW8d14l8uUZQIGx64FbE9tFNbNAyLsIwBjp9KzfDUjGykjYk+W+B7 VLPfabp0r8DzicsEXJJ9zWXe6hb3t9aSW8bo6uNxYAZ5Hoa0PEYP2aEkExLIN+PSpp73TjYs vmwtHs4QEZ/Km+H1kGlr5mcEkqD6UxtT0zTsxQjJB5ES5/WqMd5Dda/bzWyMgIw24AZPPpWr rf8AyCZ/oP5ipNK/5Blv/uCqOo/8h6w/z3pNY/0nUrOzJ/dk7mHr/nBrXWKNY/LVFCYxtA4r GskFn4hmt4+IpFyF7Dv/AI0mswrcavZxPnawwcfWtc20P2cweWoixjbjiszw0T9kmTOQsnH5 Vs1g3FvHdeJfLlGUCBseuBWhq8Mb6XMCo+Rdy8dMVBoFtElik4XMsmcseuM4xUEiiHxRF5Y2 +YmWx34P+FO1j/SdSs7Mn92TuYev+cGtdYo1j8tUUJjG0DisayQWfiGa3j4ikXIXsO/+NF0o vPEccEozHEmdp6HjP+Fat1bQ3MBilQMuOPb6Vm+GeLOb/rp/QVn2epW0V9Pc3UckkrN8hAB2 j8TT9V1WzvrbakUolBBRmUDH61tRu0mkB3zuaHJz9Kr+Hf8AkFj/AHzWpWJF83imXPZOPyFb LsERmPRRmsHQbMXBku5xuG8lFPTPc1N4mVfscTYG8PgH2wafrd29tpscakiSUBSfbHNV7HVb G2hWG2tp2fHJCDLH86n0u3nk1Ca/lh8hXGFQ9e3+FV5YP7R8QSoxPlRKA2D1Hp+dX9ZWKLR5 VCKFAAUAdDmmwSmx0BJT95Y8jPqen86boVoq2wupBunmJbceoFaJgiM6zGNfNUYDY5rKg/0j xLM/VYU2j/P4mi7/ANI8RWsXURLuPt3/AMK2ao6xdG00+R0OHb5VPuaTR7JLWzQ7f3sg3O3f 6VRvIIn8R2yIgBwHcjvjJ/pU3iNyLFIl5aVwMf5/CrenWKWcAGN0rD53PUmqGjqG1a/kQYQH HHTr/wDWpGUanrzJJ80FsPu9if8A9f8AKtHUUhOnzeailFQkD09MVW8PReXpitjl2Lf0/pWp XPvB/aPiGVWJ8qIANg9QO351qahFEulzpsUIsZwAOBxxVLTJza+HjM38O4rn68frT9BtQtv9 rkG6aYk7j1AqDXoY5LyzjVB5kjYJHXGRV3XJPJ0qUDjdhR+NN0awW2tklkG6Z1BJPVR2Aqrd KB4mtvLGGK5bH4/0qLXbxDfxW0u7yEw0gTqT6VMNYheAxWVjK/GAuwbR+WasaPayWGnuZ8Bi S5HpxVLQLMTtJeTDd852A9M9zW/gCsS2JXxHeAHqn+FO0P8A4/8AUf8Arp/U1tVS1j/kFXH+ 7/Wl0j/kF2/+7VLXIpY57e+hUt5J+YD0/wA5qZdesDHuMjBsfc2HP+FQ6VHJd6hNqMiFEYbY wfSq95O9t4iMqRGXag3KOuMc1buNetBbMYWZ5SMKu0jmpNCtHtbD94CHkO4g9vSs7TLm3sLq 5W+BSYt98qTSalfJfXNqYEYxRygeYRgEnHH6Vd8QZWO3lYBoUky6E/e/zzVFbzRPND/YpASe 44H4Z/pWzHdRXtnL9jcEhSAOhBxxWVo19Z2MDR3H7qcMdxKEk/lSG6F5rtpMkbLFyqsw+9jP P61ratG0umTogyducD25qnpOqWv2S3t2cibhNu09frSaj/yHrD/PejXIpY57e+hUt5J+YD0/ zmpl16wMe4yMGx9zYc/4VDpUcl3qE2oyIURhtjB9KNR/5D1h/nvWwelY/hv/AFFx/wBdP6Vs 1jD/AJGk/wDXL+lXtU/5Blz/ANczUeh/8gmD8f5mqlz/AMjRbf8AXP8AoaXXIpY57e+hUt5J +YD0/wA5qZdesDHuMjBsfc2HP+FQ6VHJd6hNqMiFEYbYwfSmanusNXiv9hMTDa+PyqxJrVu6 7LQNPM3CoFI/PNReG1K2s6sMESkEfhUNtONGvZ4blWEMrbkcDNXX13T1XIlLn0CH+tXLghrO Rh0MZP6VR8O/8gsf75rUrFl/ceJ4mPAmTH6f/Wq7rEvk6ZO3crtH48Vn6VqdtaWaW9zuhZRk ZUncDznikLHW9RjZFItIDkkjG41J4gV0e0uQpZIXy2PqP8KsjXNP2584g+mw5/lVu3uEuLcT IGCHJG4Y49azPD481ru5P/LSTj+f9aXxExaCC3U8yyD/AD+tWNXt2fSZIogSVAwB6CqunazZ x2MUcshR0XaRtJzj6Vo2d4t3C0yoyRg4Ut/EPWs/w+PMN3cnrJJ/9f8ArSab+/1y9n7J8g/l /StqsnxHE76eGUZCOGb6UJrlr9nQR73mwAIlU5zVbR0ml1m5muMeYowQOxPapdS/f63ZW/ZP nP8An8K15nEULyHoqk1l+HEIsnlbrLIT/n9aq2lzHpur3i3WUEhyGwT3z/WjWNQa8s2FsrfZ wQGkIxuPYCtqyi8myhj/ALqAGpicAk9BXN6VqMdvcXE1wrKk7nEmMgHrj9asahfjUgtlYZcu fnfBAAq1qFoU0NreEE7FHTvg5NV7DWbSHT4kdmEiLt2BSSfp2qG28+68QpJcLsKpvCf3R2/n U3iRyUt4FBZnfO0d8f8A66nTXbEQ5ZmRwOY9pzn09Ki0mCW5vJNSnXbv4jU+nrUU0w07xA89 wpEUq4DAZxwP8KunXLD+CVnY9FVDk/nUmry+Vpc7dCV2j8eKNHi8rS4F7ldx/HmrtYulDz9Y vp/4Qdo/P/61a6QxRszRxohY5YqoGfrT6a6LIhR1DKeoIyDQiKihUUKo6ADAFOqH7JbeZ5n2 eLf/AHtgzU1Yw/5Gk/8AXL+lagt4Fk8wQxiQ/wAQUZ/Opajlghmx5sSSY6blBoaGJlVWiQhT lQVHB9qytail+1W1wITPDEfmQc0v/CQ2zfILecv027R+XWl0W2mW4uLuSLyFl+7H6VpSW0Er BpIY3YdCygmnGKNmVjGpZPukjlfpT6iW3gWTzFhjEn94KM/nTmijeRZGjRnX7rFRkfQ0+ofs lt5nmfZ4t/8Ae2DNTUxoo3kWRo0Z1+6xUZH0NPpkcUcQIijRATk7VAyafTPKj83zfLTzMY37 RnH1pzKrqVdQynggjINIiJGgSNQqjoFGAKQxRmUSmNDIOAxUZH40+ofslt5nmfZ4t/8Ae2DN TUhAYEMAQexpkUEMOfJiSPPXaoFLHFHFny0VNxydoxk+tK6JIpV1VlPUMMio47W3iOY4IkPq qAVKQCCCMg9QabHHHEmyJFRfRRgU+srXYW8qK7iHz27bvwqHXZxPYWyxc+e4I+n+SK1TbQvG iSRI4QADcoOKlVVVQqgADoAKCARg8iohaWyvvW3iDf3ggzUuARgjj0pscUcS7YkVF9FGBQ8U cjKzxozLypKgkfSn1CbW3aTzDBEX/vFBn86lwMYxx6U2OKOJdsSKi+ijAojiji3eXGqbjk7R jJp9FRx28MTFo4Y0Y9SqgE0qRRxszJGqljliBjP1o8qPzfN8tfMxjfjnH1pzKrqVYBlIwQRk GkREjQJGqoo6BRgCmywQzY82JJMdNyg0rwxOgR40ZR0UqCBT6q6lL5Onzv0IQgfU8VX0a3Ua RGsiKwfLEMMg5q/FDHCu2KNIx6KoFPqIW8CyGRYYxIerBRn86cIoxIZBGokYYLAcn8aybj9/ 4lgTqsKbj/n8q1GtoGk8xoYy4/iKjP51LTXRJFKyIrKezDIpkVtBCcxQxofVUAp0kccqbJUV 19GGRTgAAABgDoBUF9cC1s5Zj1VePr2qtolsbawUv/rJTvbP6Vo0UUUUUUUU358n7uO1J+82 /wAOaX5tx6be1J+82/w7v0pfm3dtv60n7zb/AA5pfn3D7uO9J+8wfu57Uvz5H3cd6T95g/dz 2pfn4+770fPz932o+fj7vvR8+T93Hak/eYH3c96X58n7uMcUn7zb/Dml+fcfu7f1pP3m3+HO aX5t3bb+tJ+82/w5pfn3D7uO9J+8wfu57Uvz5H3cd6T95g/dz2pfn4+770fPz932o+fj7vvR 8+T93Hak/eYH3c96X58n7uO1J+82/wAOaX59x+7t/Wk/ebf4c5pfn3D7u39aT95t/hzS/PuH 3cd6T95g/dz2pfnyPu470fPz932o+fj7vvR8/P3faj5+Pu+9Hz5P3cdqT95gfdz3pfn3H7uO 1J+82/w5pfm3dtv60n7zb/DnNL827tt/Wk/ebf4c0vz7h93Hek/eYP3c9qX58j7uO9Hz8/d9 qPn4+770fPz932o+fj7vvR8+T93Hak/eYH3c96X59x+7jtSfvNv8OaX59x+7t/Wk/ebf4c5p wznnGKWiiiiiiiiiiiiiiiiik3DdtyM9cUtFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFRp/rpPwqSiiiio4po5S4RgTG21vY1J RRRRRRUcc0crOEYExttb2NSUVHFNHMpMbBgrFTj1FSUUUUUUVHFNHNu8tg2xirY7EVJRUcM0 c6b4mDLkjI9jipKKKKKKjE0ZnMO4eYF3bfapKKjWaN5niVgXjxuHpmpKKKKKKjkmjiaNXbBk bavuakoqN5o0ljjZgHkztHripKKKKKKZLKkMTSSHCIMk05WDKGU5BGQRS0UUUUUUUUUUUUUU UUUVFPMYduInk3HHy44/MiozfQrgOxBIzwrEfninLeW7tKqyAmH74APFDXcKuU3fNz/Ccd++ PY06GZZg20MNpwcgjn29aVP9bJ+FSUUUUjAlSAcHHB9KzdKsTazXDidnBbaQR175/U1aF05n mjEJKxj7wJ5OAcdMd/WpUmRgmSFZ1DBc1JRSEhRkkADuarfbC1wI40Dpt3F8kAdfbHb1qWCR 5oA5Xy2Occ5H1qhpNkba5um85n+faQR14Bz+talNkUtGyq20kYDelZ2i2n2WOYiVmUyMuCO4 YjP6VYa7cPOBCMR9GLEAn06fyzU6SqxVW+VyoOwnkVJRSEhRliAB3NVjdsbgRxx71K7t+T7+ 3t60+CVrm2LD92xyPXB/ECqek2P2R5yJmcFsEMO/r+tadMmQyQuiuULDG4dqoaLa/ZrZwJCy s7DBHTDEf0qZr2QCciDIiOActzz/ALv8s/hVhJkfADDcQDjNSUVVnu/LKiFPNJbaQCePyBp1 vdpcSyohU+WezZ/Tt0qotiw1prjz23bdxGOMdMVp0Vl2dg0OqTzeezMeWBHBzVua6MVwI/Ly m3cz8/KPyx29RRb3kU8YfcgyxAw2f1qzRUFxcrCjEYZwPuZ9/YGmLcymaFXt9qSD7xbo3PGM Z7VU1WxNzdWrmZk+faoA+7wTn9BWoMgDJye5pay72wM+pwTeeykDKgDpirt3cNbqhSPzCzYx z6ewNIly3myrNEIlTBVi2dw9fapwQRkEEHuKWmtIiEBmAJOAPWqQ1BvLVmgK7mwD82Mev3f/ AK3vS6xAZ9NmG8qFUucDrgZxU1lAba1SEyFwo4JHarFFFFFFFFFFFFFFFFFFFNZQ2MjODkUw 20RXaU4xjqfTFAt4wHGGxJ94bjj8Bnj8KatpAoICk565YknknqT7mpEiSMsUBG45PJpsYCyy Y74NS02SRI0LSMFUdyah+2Qf3z/3yf8ACj7ZB/fP/fJ/wo+2Qf3z/wB8n/CorW6hLyrvALSH GRjPAqY2kDKyspIb7wLHn9aibTotyhMpGoxtFW1UKoUZwPU5pahuLdLhcMSMdMGo4rKNItr5 Y9CdxGR9M09Y7ezTcMRr7scVWtbqES3RLHmXI+U/3Vqx9sg/vn/vk/4UfbIP75/75P8AhUFh cwlGQyAM00mAeM5Y1O9lbupV0LKeSCxIP61GdPiMikEqigAKDVsDAAHalqG4tkuFwxII6EGm JZxLGFbLHGCdxGf1pwS3s0zny16AFjj8qgt7uEGbLHmQn7p9B7VN9sg/vn/vk/4UfbIP75/7 5P8AhUGn3ELQeXvAZpJMA8Z+c9Kneyt3Qo8ZZSc4LEjP50w2EbTbyzBRjC5/rVoDAxTZY1lQ o2cH0OKghsY485LNzxyRj8qk8mKMmTkY5JLn/Gq4u4PtpYPkeWBkKfU1N9sg/vn/AL5P+FH2 yD++f++T/hUMd3ALqYmTAIXkggd6sm3iZi/zZPcOf8ahlsY5NoBKgEk8k5/OrMcaxoEXOB6n NKRkYqqthGspbLFT/Dnv9ak+yQ79+078Y3bzn+dV7u5hE1qA4OybnGTj5Gqf7ZB/fP8A3yf8 KPtkH98/98n/AAqGS7g+1QnccANn5T7e1WNkNwFkB3DsVY/0qN7GHY4jXYz8k5PP19akt7dL dcKWOeuTU1VZbJJJRIGYHIJ56082cDAAoSF6AseP1qDUJIYbG4i3/MYmwuST0NSreQbR856f 3T/hS/bIP75/75P+FH2yD++f++T/AIVJFPHNny3DY6juKkooooooooooooooooooooqNP9bJ +FSVUuubq3U8j5m/EY/xNSZpizxu7IkiMy9QGBIpyurDKsCOnBqBo/3M6vghyT+lW4GLQRsT klQSfwqSiiiiqlzzewA9Ajtj3yoz+ppIUMbzMSMSPuGPTaB/SnLPE5YJKjFfvAMDj60qSpIu 6N1ZfVTkVWaHZZTo+Dku4x2ySRWghyik9SKdRRRRVWbBvY8/wxsR7cikiUoZMkfM5YYoW4ic MUlRgv3sMDj605JEkUMjBlPQqciq8ieXYurYJXLAjsc5BrRooooqtfDdHGp+60gyPXv/AEpu 0/aDJkY2bf1pfPj8zy/MTzOu3dz+VO8xdxXcNwGSM80xUxNIxwVcAYp9h/x6KOwLAfQMQKsU UUVHOSsEhBwQpIP4VUEQMdtswBGQ2P8AgJH9aleeOMgSSIhbpubGaDPEJBGZEEh6LuGfypHU tNG4IwoOfxpbXAuLgDgEq2PfH/1qtUUUUVnNGZba6Rcb5C65P4gVO0iRR7pHVFHUscCgzxrG JGkQIf4iwx+dPDZGQajGPt0TDqUYH3HFW6KKKKKKKKKKKKKKKKKKKKaExIWyeRyKdVO7OLu3 /wB1/wClLuqrBGwLNIflVnKrt55J6+tPs3BRgFZfnJwyFeM+9SyH92/0NWLb/j2i/wBwfyqW iiiiqd0cX0H/AFzk/mlLuqpCjIhkl5C7sIE5wT+tS2zBg7gMCzZIZSvb3FOnP+jyf7p/lV2P /VJ9BTqKKKKqXBxeJ/1zP8xRuqpDGywh5CchSAFTkDPvnJqW1JCNncQWyGYYJ9yKW6P+jS/7 prQooooqtffdi/66D+Rpu6q3lu9xISQI8qcbeSR70kAmW6YyIgyvLKxOTn6Va3U+w/49R/vP /wChGrFFFFR3H/HtL/uH+VVoz+7T6CoZ1d7iPYQBsYMSufSm8x3AETSZ4DKV+XHrnHX8atbq LTm4n+i/1q3RRRRVCI/6z/ro/wDM0263tGoj+9vU5IzjmoZUaMxkO4+8SyJn5ifTB96tRsxj XeAGwM49aEObyL/db+lXaKKKKKKKKKKKKKKKKKKKKjXmZzk8AADPFSVUvkfdFKiF9mQQvXB7 /pVb7R/0xuP+/Lf4UfaP+mNx/wB+W/wo+0f9Mbj/AL8t/hSGR5FKRwTbiMDdGVH5kVpxp5ca pnO0AU6iiiiqd6jiWKZELhAysF5ODjnH4VX+0f8ATG4/78t/hR9o/wCmNx/35b/Cj7R/0xuP +/Lf4UjvJMjRxQyhmGAWjKgZ781qKNqgDsMUtFFFFU71XWVJlRnUKVYKMkdOcVX+0f8ATG4/ 78t/hR9o/wCmNx/35b/Cj7R/0xuP+/Lf4UjF7hTFHDKC3GXjKgD15rVooooqvexu8IMY3MjB gvr7VT+0Y/5Y3H/flv8ACj7R/wBMbj/vy3+FH2j/AKY3H/flv8KPPJ4EE5PYeUw/mKvWkbRW yI+N3JOOxJz/AFqaiiimyJvidM43AjNZiyvGoSSCYMowdsbMPzApftH/AExuP+/Lf4UfaP8A pjcf9+W/wo+0f9Mbj/vy3+FWbFHzJI6lN5G0HrgetW6KKKKzX328kgaKRlZiysiFs557U37R /wBMbj/vy3+FH2j/AKY3H/flv8KPtH/TG4/78t/hUtqHluRJ5boiKRl12kk47Gr9FFFFFFFF FFFFFFFRyzww482VI89NzAZp6kMMjOPcYpaQnAz6UKwYZBzTE/1sn4VJRRRRVe1vIrp5ljPM T7T7+/8AP8qsUUUUUUVXtryK5kmSM8xNtP8Aj/P8qsUVXtLuK8RniOQrFT+FWKKKKKKKgtbu K7EhiOfLcqanpCQBk9Khs7uO8hMsR+UMV/Kp6KKKKKri7iN6bTP7wJuqxRVeO7ilu5bZT88Q BP41Yoooooqvc3kVtJCkhwZW2j29/wCX51YoqvNdxQ3MMDn55c4qxRRRRRUV1cJa27zSfdQZ x6+1OikWWJZEOVYZBp9FFFFFFFFFFFFFFFFFFMkTft5xtYGqr6dG4G4gsBgMV5HH+PNKliEa 5IcZn74OR9ecfoKb/Z+WLySKZD/EExjkk4596sW9uIDJjbh23cLg9O/rSxgiWTJzyO1S0UUU jDcpGSMjHFZ+m2EFrLM8QYHcVwW4xxWjRRRTJJUiXdIwUVUF5JJP+7CiHbkswHB59/b0/Gpb SY3FvlyA5yDt47/U/wAzVbTLKG2uLpo9wKybOW7bVP8AM1pU2RBJGyEkBhg4ODVDSbSK2jla MEZkdTk8YDECnSXkqfaXPlCOMfIWOMn8+fyFWPtcG9V8wfMAQ2eD+NT0UyWWOFcyMFqo14/n ZRQ0ITcePm7+/t0xUtrN9qtjv4YllIAKnGcd+ag02xgtZJ2hDD5tv3s8cVoUyWNZomjbO1hg 4OOKpaRaxW9u7R5G52ByeOGIH6USXsqJO7NEiK2Iyw6nOP7368VZW7i3hGdQSAc54P41PTWZ UXcxAA7mqkt6zFRagMS2DuHbH1H+e1Ptp5HmmSVoiFPyGM9ueD71AthANWM4DeZt353d8kfy rRorOtbCCHUZpUDbxg53dc5zU8txIt2I02eWFy5Pbr7/ANPyqO21BGhVpWXJYjKjjj8T/M1d VgwBUgg9xS1UuL1VVlgIaQdOMjr9R/OmpdyfaY4pAq5XLEY68+/HT3qLUrKC4ubV5AxLPs4Y jjax/mK0QMADrj1pazruwgn1CGSQMXIPIY8YxirF5NJEIxCFLs2MN6YPuKjjvwZZg4IWMDHy kE8kHr1q1HKkq7o2DCn0UVT1aBJ9Om35+RGcYOOQDiprSBLa3WKLOwdATnFTUUUUUUUUUUUU UUUUUUUUUUUVGn+tk/CpKjmmSBQXz8xwoAySai+1H/n2m/8AHf8AGl+1H/n2m/8AHf8AGj7U f+fab/x3/GoLe7VDMZI5EUyHLEDA4HXBq/RRRTJYo5VxIoIpsdtFGgUIDjuRzSSPDb4OwBmO AFXk1VtbkiW6/wBHlOZc8bePlX3qx9qP/PtN/wCO/wCNH2o/8+03/jv+NVrK6VInEkbopmf5 iBgZc9cVe8qP/nmn/fNRtaQtLvKA8Yx2qYDAwOlLUcsMcy4kUGkS3iRAoRTjuRzSSPFb4+T5 m4CovJqvb3JBm/0eU5kJ/h9B71N9qP8Az7Tf+O/40faj/wA+03/jv+NV7G5VYAskboGkfDMO OXNXfKj/AOeaf981GbSEy7ygJ9O1TDgYFI6K67XUMPQ1HHawxbtqAgnPPOKWTyYUMjKqhe+2 qouT9sJEEv8Aqx2Hqfep/tR/59pv/Hf8aPtR/wCfab/x3/GoI7rbczM0EoGFzwDjr6GrarFI odVRg3IOOtMktYZCu5AAOw4zUqoqLtRQo9BTuvBqAWkKy+YEA4xjtUnlR/8APNPyFUbm6V5L UxxyMol4IAAPyt0yas/aj/z7Tf8Ajv8AjR9qP/PtN/47/jUMlyftUJ+zy8BuPl9verEbRXAL BQSDghl5B9KWS3idCpQDPcDmlihjhGI1C1JRRVHUblfsl1Equ5EbBio4XjuakW6O0f6NN0/2 f8ad9qP/AD7Tf+O/40faj/z7Tf8Ajv8AjTorhZWKbWRwM7WHOPWpqKKKKKKKKKKKKKKKKKKK KYqsJWOBtIHOafVS6OLy3+j/ANKfmokuY3ZlBOVznKkDjryetPSVZF3IcjOKjKBYpu4fJP5V at/+PaL/AHB/KpKKKKKqXB/06D/rnJ/NaSNBG0rA58xtx9uAP6UiXUTlgGPy5zlSOnpnrTo5 llUlCeDggggj8DUTxiO0nTOQ29uffJ/rV6M5jUnrgU6iiiiqk3/H6h/6Zn+YojXYX5zubdTU uonBIJ49VIz9PWnxyrIu5CcdOQQR+BqGVBHYyJnOFNaFFFFFVr37sP8A10H9abt/fGTP8O3F IbiMS+WSd3+6cfn0pRMhkaMH5lGSKFXbK75+9jj6U+w/49R/vN/6EasUUUVHcf8AHvL/ALh/ lVUIHSA9PLIYflj+tOluI4iocnLdMKT/ACo+0IZfLG4t7KSPz6UrLulR8/dzx9aW2/4+Z/8A gP8AI1aoooorP2CWC4iJwHZ1JHuSKleVYYwzk44HAJP5CkNzGIw+SQegCkn8utSBsjNMHN5D /ut/SrdFFFFFFFFFFFFFFFFFFFFFFUrw4u7f/df+lLuqvBEyFncsSGYqvGBknp/9enWpcKwe Nk+YkZI7n2NSSH9230NWbb/j2i/3B/KpaKKKKpXRxfQf9c5P5pS7qrQxtEhc7ncbtqZHGT2/ +vUluTtYtGyMTk7sc/kTSzn/AEeT/dP8qvR/6pPoKdRRRRVO4OLxP+uZ/mKN1Voomjiy293w QFyBgHsCKfbBkQggqCcgMckD3Pelum/0aT/dNaNFFFFVb77sX/XQfyNN3VB5Rad3Zm2EgheM Ejv602GOaO4LO6Mu3qFwSc/WrO6n2H/HqP8Aef8A9CNWaKKKjuP+PaX/AHD/ACqrGf3a/QVF NG0k8ZDMqhWBK45zjjmmlCJ1MaOuMZbd8pHpjP8ASrO6ltDm4n/4D/WrdFFFFUIjgyf9dH/m abcq0kYVCQdwORjI596ilhIKFRI4GQdr7Tk45zkelWIywjUOcsAMn1NKhzeRf7rf0q7RRRRR RRRRRRRRRRRRRRRUaAefIcDPAzUlVbyGSQxyRAF4yeCcZB61Xxdf8+rf99r/AI0Yuv8An1b/ AL7X/GjF1/z6t/32v+NBiupAU8ny9wxuZgcflWgihEVR0UYFOooooqreQyO0csQBZAQVJxkH H+Aqvi6/59W/77X/ABoxdf8APq3/AH2v+NGLr/n1b/vtf8aRobqZTH5PlBuCzMDgfhWkAAAB 0FLRRRRVW7hkZ0liAYqCCpOMg+lV8XX/AD6t/wB9r/jRi6/59W/77X/GjF1/z6t/32v+NBhu Zh5bQ+WrcMxYHj2xWlRRRRUF3C00OEIDqQy56ZFVMXX/AD6n/vtf8aMXX/Pq3/fa/wCNGLr/ AJ9W/wC+1/xo23Z4Ftg+pcYq7bReRAsZOSOSfUnk1LRRRTXUOjIejDBrPEd1GAnkeZt43KwA P50Yuv8An1b/AL7X/GjF1/z6t/32v+NGLr/n1b/vtf8AGrNnC8e95cB3I+UdgKs0UUUVnyQ3 EUr+XH5qMxYYYAjPXrTcXX/Pq3/fa/40Yuv+fVv++1/xoxdf8+rf99r/AI1LbQzGcSyqIwqk Kuck57/pV2iiiiiiiiiiiiiiiopp0g279/zHA2oW/kKT7VAMB5URj0VnGaeJYyXAkQlPvDd9 360jTxK20yJu5wu4ZNEU0cu7y2DFThgD0NCf62T8Kkooooqjp+ox30k6Jx5bfL7r61eooooo oqlYajHeyzomP3bYH+0vrV2kJCgknAHJNU9N1BL9JCowUYjHt2NXaKKKKKQkAZPSqen6hHfe bs4MbYA9R2NXaa7rGjO5AVRkk9hVXTb5b+AyKNpViCvp6fpVyiiiiiqS6jGdUay7hc5/2vT8 qu0VSt9Rjn1Ca1XrGOD6nvV2iiiiiqN/qUdlNBG+P3jfN/sr6/n/AFq9RVK51GO3voLZusnU /wB30/WrtFFFFFVr+6FnZyTHkqPlHqe1SW06XNuk0f3XGfp7VLRRRRRRRRRRRRRRRRRRTXQP tzngg1CbOJl2kt0I7ehH9aRLKJDNtJHnfe4HH44z+eaQWKAHc7sT1Y4z1J7D3qaKIRbsMxDH OD2pIxtlk5J5B5NS0UUUhAYEEZB4IqpY20EUkzRxIjByMgY4wOKuUUUVFcXCW65fPPQAVSEs k0vnq5QBMKh3YJ56449O1T2TM0Hlzcvls5JbIz6kCmWFtDFPdNHEilZdoIGMDapxV6muquhR wGUjBB71U0yCKKORo41UmWRcgY4DnAq7RRRUNxcJbrl8knoAKqFzNN53mSInl42Jnk89Ocen aprLBtvKkLv1yJTliPc0ljbwxPM0cSId5XKjHHHFXKa6LIhR1DKeoPQ1U0yGKG3Z0jVCXcEg dQHOKhdpFSdxJKzOfkRc8DPucflirH2+MShWVgCBzjpVoHIyKbLIsSF3zgegqjJObspsdoVV uSM5Ix7H/Gn2cknnTCUk7m+UnP8AifbsKVbW3GolxCgbZuzt5zk81doqlBa26X0rrCisoUgh eRnOaJiTeBxI4RF+6N3zHnjrj9KjgvPIgQSJJkschzkgfXJzV+ORZUDocg06iiqN/bQSXFq0 kSMWl2klc5G1jiroAAAAwBS1SuLWCS9hZ4UZmDZJXrjGKdfbn8tEkaP5ssRnpg+hFQpcNFNc OQ5TjaGJ59ccnH6fSrlvcJcLlM8dQR0qWiiqmpxJJp8+9FbbGzLkdDg81PBFHDEFiRUXrhRg VJRRRRRRRRRRRRRRRRRRRRRRRUaf62T8KkqKebygoCl3c4VQcVF513/zwh/7/H/4mjzrv/nh D/3+P/xNHnXf/PCH/v8AH/4moIbmaLznkhXYHJYo+SOB2wM1oAggEHINLRRSEBhhgCD2NIiL GoVBhR2qOefyiqqm936DOPqTVO2luRLdYhiJMvOZTwdq/wCzVjzrv/nhD/3+P/xNHnXf/PCH /v8AH/4mq1pcyQwSPLEojErlmV8kfMc8YHArTooopGUMCGAIPY0iqEUKowB0FRzzmNlRE3yN kgZwAB3JqrbzXQM2IIT+8Ocyn0H+zU3nXf8Azwh/7/H/AOJo867/AOeEP/f4/wDxNV7O4kht 8yxKIzIxLK+SMse2OnNaVM8tPM37Ru9afRTEjSPOxQueTiknmEERcgt2CjqT2FU/OufthIgi z5Y4Mp9T/s1N513/AM8If+/x/wDiaPOu/wDnhD/3+P8A8TUMc1yLmYmCM8LkLKc9+ny1dikW aJZEzhh3oeNHKl1DbemafRRSEhQSTgDkms24uJpHtXSFQvm5Xe+CflbqMHFWfOu/+eEP/f4/ /E0edd/88If+/wAf/iahkmuftUJMEOcNgeafb/Zq1BP5wYFSjocMpqR1V1KsMg9RSqoUYUAA dhS0UVn6hcO9pdJFGGVUZWdmx2Occc/pUqzXe0fuIen/AD2P/wATS+dd/wDPCH/v8f8A4mjz rv8A54Q/9/j/APE06K4ZpfKljCORkYbIPrzxViiiiiiiiiiiiiiiiiiiiimBSJGbIwR0xT6q XRxeW/8Auv8A0p2agjuWZ8NGApLBSGyTj1GOKkhlMiEldpDEYznoaRlCRyY/iyT+VWLb/j2i /wBwfyqWiiiiqlwcX8H/AFyk/mlCKqFyvV23H64A/pUUdy7tgxgZztw2c4OOeOKfDKzhg6hW U4ODkfnTZEWO1mVRwQzH6nJNXY/9Un0FOooooqrMcXqf9cz/ADFCgJux/EcmoEu2KkvGq5Us vz8YHrxxUlvN50e/CjnHytkH6GmTqI7ORV6bTWhRRRRVa96Q/wDXQfyNJtHmb/4sYqFrllmK 7BsBClt3OT7Y/rT0n3ztGF4AyGz1p4UB2cdWxn8KdY/8eo/3n/8AQjViiiio7j/j2l/3D/Kq yqrxxE/w4I+uKbPO8bqqIrZBY5bGAMe3vTVu99x5QCAYB+Z8N0/u4qcqC6ueq5x+NFtzcz/R f61aooooqgqrJFNG/wB1ndT9CTTppWijBRQxJCgE4HP4VE96FjUkIrkkYd8KMHB5xVkNkA00 HN5F/ut/SrdFFFFFFFFFFFFFFFFFFFFRqP3znJ4AHWpKpXhxd2/+6/8ASl3VDFCsW8qF3sSS 23k5PeiBHiVg7q2WJ+VcdfxNPkb9230NWrb/AI9ov9wfyqWiiiiqV2cXsH/XOT+aUu6oI4RF G4j2rI2Tv29/f1p8IdEw7Kx9VUj+ponP7iT/AHT/ACq9H/qk+gp1FFFFU7k4vE/65n+YpN1R RQrDEVj2qx6sF6n3p0SmMNuYFmOSQMD8qS6b/RpP901o0UUUVVvvuRf9dB/I03dUQiQTtKVU uehxyPxpsVukUu9Gf7uMFyf5mp91PsP+PUf7z/8AoRqzRRRUdz/x7S/7h/lVSNv3a/QU2SFJ ZUdwrbAcAjPPHP6UOjvICzrsUghQvOfrn+lS7qWzObif/gP9at0UUUVnxHBk/wCuj/zNE0az IEbBXIJBGQcU14slDEVQqCB8uRg+34VJGBHGqDoowKIzm8i/3W/pV6iiiiiiiiiiiiiiio5Z 4YcebKkeem5gM09SGGRnHuMUtITgZ9KFYMMg5pif62T8KkqC6tzOFKPskQ5BIyPoarfZrz+9 B+tH2a8/vQfrR9mvP70H60fY7mQFZJI1Q8EoDnHtV9QFUADAHAFLRRRRVe6tzMUdGCyJnBIy CD1B/IVX+zXn96D9aPs15/eg/Wj7Nef3oP1oNlcSjZLJGIzw2wHJHpzWhRRRRRVa6tmlZHjc JIuRyMgg9j+VQfZrz+9B+tH2a8/vQfrR9mvP70H60os55DtmkjEfcIDk+1X6KKKKiuYBPEU3 bTkFWHYiqv2a7/vwn8DSfZrz+9B+tH2a8/vQfrS/Zbs8GSFfcAnFW4IlghWNckKOp7+9SUUU UjKGUqwyCMEVQ+yXKfKkkbKOhYEHFH2a8/vQfrR9mvP70H60fZrz+9B+tWbW3MCsWbe7nLHG B9BU9FFFFUpbSUSM0Dptc5KuDwfY0z7Nef3oP1o+zXn96D9aPs15/eg/Wpra1dJfNmdWYDCh RgD1/lVqiiiiiiiiiiiiiiimSJv2842sDVV9OjcDcQWAwGK8jj/HmlSxCNckOMz98HI+vOP0 FN/s/LF5JFMh/iCYxyScc+9WLe3EBkxtw7buFwenf1pYwRLJk56VLRRRSEhQSTgDkms3StUF 9cTxnjB3R+69P8/WtOiiiiikJCgknAHJNZmlaoL64njPGDuj91/z/OtSmySLFG0jnCqMk1n6 PqX29ZQ/DqxIH+yelaVFFFFFNdgiFmOFUZJrO0jVBftMjYDqxKj/AGa06jnlWCF5XOFQZNUt H1A38D78CRGOR7Hp/h+FaNFFFFFZaasray1pkeXjaD/t/wCeK1KKy7TVluNVmtsjZ0jPqR1/ z7VqUUUUUVmarqgsbiCMc5O6T2Xp/n6VpAhgCDkHkGlrLvtWW21KC3BG3P70+men+NalFFFF FU9VvPsVi8inDn5U+tSWN0t5aRzLxuHI9D3qxRRRRRRRRRRRRRRRRRRRRRRRUaf62T8Kkooo oqC2+9P/ANdT/IVPRRRUNzM0KbljL/ToKoojXD/aZIWc7NoC4APXv171ZsEMECw+SYwMkDOQ OemeppbT/XXf/Xb/ANkWrVFVrD/Uyf8AXaT/ANDNWaKKKgup3gTKxl/fsKpmJ7h/tBRw5j2q VC9eefXvVnT1kigEUkZQjJ/hx+mP5U+2+9P/ANdT/IVPRVbT/wDj2P8A10k/9DarNFFFFFQD /j+P/XIfzNT0VBF/x9z/AEX+tQzRF7wTGKQ7FwuNvJ579RUSTz20MavBtO48bt2R9avxuXQM UKE9jT6KKrXf+utP+u3/ALI1WaKgl/4+4Po39KjvoftHloY3ZVbcSoU9j61AGmge4m+zBN2M MCOceo9auW0zTR7mjKfXoamooqvqH/IOuf8Ark38jU6/dH0paKKKKKKKKKKKKKKKKKKKKKKK YqsJWPG04+tPqC5mdCkcQXzHzgt0AHU+9M/0j/nuv/fv/wCvR/pH/Pdf+/f/ANej/SP+e6/9 +/8A69V43uIhO6skgVyWXbgngdDnitFWDqGXoRkUtFFFIABwBioLiZ0dIotu98nLcgAYzx36 iqtr5/m3WJlB83n5Ovyr71Y/0j/nuv8A37/+vR/pH/Pdf+/f/wBeqttLPDbySBkdFlkLLtwT 8xzg5/StMHIyOlLRRRSAY6VBcSyLIkUO0OwJLMMgAe3frVe38/M2JlH7w/wew96m/wBI/wCe 6/8Afv8A+vR/pH/Pdf8Av3/9eq1tJNb23mFkePezMu3BwWPIOa06KKKKiuZTDFlV3OxCqD0y aqD7R9sOZk3eWOkfHU+9Tf6R/wA91/79/wD16P8ASP8Anuv/AH7/APr1An2kXMxWVC2F+8nB 6+9XYJfOhWTG3PUeh70/AznHIpaKKRmCIWPQDJrNme4ke1csiAy5Chc7flbqc81Z/wBI/wCe 6/8Afv8A+vR/pH/Pdf8Av3/9eoZPP+0w/vlzhsfJ9PerNtK8m9JQA6Hkr0IPcVMRnrS0UUVm 30sstrd7CqRKjryMlsA578VOv2jaP369P+ef/wBel/0j/nuv/fv/AOvR/pH/AD3X/v3/APXp YZZRMIpirbgSrKMdOxH41ZooooooooooooooooooooooqndHF5b/AO6/9KfmqsF08kzLujbD MNqjBXB4zz3qaCVnQl8ZDEcexpXwscmABkEmp7b/AI9ov9wfyqWiiiiqlycX0H/XKT+aUoCq SQACxycdzVWC6kldlDRsfm4Ufcwe/NTwSOwYSbSVbG5RgH8KSYKttKFAAKsePU1cj/1SfQU6 iiiiqkxxep/1zP8AMUowucADJyaqwXckgb5o34J+RT8nseTk1NbStJGSxBIOOFK/oelJcYW0 kCgAbTwKv0UUUVWvekP/AF0H8jScbt2BnGM1Wa5YXRjDRkAgbMfMc9+v9KkjnZ52XA2bcqe5 5qUYDEgDJ6mnWP8Ax6j/AHn/APQjViiiio7j/j2l/wBw/wAqrpgxx5AOACKhurlopEUPGgYE /OOuMcDn3oFxIbgK2EQgYBjPPH97OKsHBYEgZHQ0Wv8Ax8z/AEX+tWqKKKKoxgMkqsAVLuCD 35NJdTGGHcrInIG5xwOfqKia7cRpggM2fmCFgQD1AHNWlfcoIIIIzkU0HN5F/ut/SrlFFFFF FFFFFFFFFFFFFFFMD5kK44A60+qV5xd259n/AKUbqYihEKqTySc/U5pIY/JBHmO+Tn5sf0Ap 0jfu3+hq3bf8e0X+4P5VJRRRRVK74vYP+ub/AM1o3UwIFiMasy5zyOozREpiXaZGf03AcfkB SXDAW8pJwNh/lV+PiNfoKdRRRRVO5OLxP+uZ/mKTdTAgWIRqzADoR1ojURg/MWJOSx6mm3Tf 6NJ/umtKiiiiqt+cJEf+mg/rTN1NUBWZhnLdajjt4YpfMjjRGxj5VAqbdUmn82i/7zf+hGrN FFFR3P8Ax7S/7h/lVSNv3a/QUFQZFfJyoI/PH+FNZN0gZnYqOQnGM/lmpN1Oszm4n/4D/Wrd FFFFZ8R5k/66P/M0rgOACTwQePamyIJCCGZGHdcdPTmnrhFCrwAMCiM5vYv91v6Veooooooo oooooooooooooqNP9bJ+FSVDcW63CAMWUqcqy9Qah+xN/wA/D/8AfIo+xN/z8P8A98ij7E3/ AD8P/wB8ig2G7iSZ2TuuAM+xq5RRRRRUNxbrOFyWVlOVZeoqH7E3/Pw//fIo+xN/z8P/AN8i j7E3/Pw//fIo+wBiBLM7r3XgA/WrlFFFFFQ3Fss+0lmR1+6y9RUP2Jv+fh/++RR9ib/n4f8A 75FH2Jv+fh/++RSixBZTJM7qDnbgAH68VbooooqOaFJ4jHIPlPp1HvVcWLDj7S5+qr/hR9ib /n4f/vkUfYm/5+H/AO+RQbFiMG5kx7AA/wAqtRxrFGqIMKowBTqKKKOtUxYbeI55FXspAOPb pR9ib/n4f/vkUfYm/wCfh/8AvkUfYm/5+H/75FT28C26FVLMScszdSalooooqrJZBpTIkjxl vvAYIJ9eab9ib/n4f/vkUfYm/wCfh/8AvkUfYm/5+H/75FSQWqwyGQu0jkYy3YewFWKKKKKK KKKKKKKKKKguVkbZ5crp82DtAOR+INQNLdqoKIuAOjIxJOM9c/hTknuS1zujUBP9WArZP9D+ FN+0XLklYj5eO8bBjyR+HQVPatKfMEvZvl+UjjHr3p0bbpZMAjBA5GKlooopCcAnk49KzNKu LqW4uRcxOql8qSPu+35YrUoooophljEgjMiByMhS3OPpQsqPHvjYOvqpzms7Sbm6muLlbiJl Xflc/wAP+z+WK1KbIxSNmCliBnA6ms7Rp7mVJhdRsCHJUnp15H4GtOiiiiikY7VLYJwM4Hes 3R57uRp1uo2X5yVJ6D/ZrTpkztHC7qhdgMhR3NUdFnuJbZxcowZXOGPfnn8jmtGiiiiistLm 6Otshhf7OV2jj/x7861KKy7S5un1adZIXEBAC5H3cdPz5rUooooorL1W5uori2W2iZhvy2P4 uD8v5ZrTByAeRn1pay765u01O3WGFzCv3sD73r+VaMkscQBkkVATgFjjJpwYEkAgkdfalooo qlq8ssWnSmBWLkYyP4R3P5VLYySy2kbToUlxhgR39asUUUUUUUUUUUUUUUUUUUUUUUVGn+tk /CpKKKKKgtvvT/8AXU/yFT0UUVDcmcJ+4VSe+etU0tpp0LyDLMpX5nII6846d6tWkc0MYSQq wHfcSf1/xpLT/XXf/Xb/ANkWrNFVrD/Uyf8AXaT/ANDNWaKKKKKKgtvvT/8AXU/yFT0VW0// AI9j/wBdJP8A0Nqs0UUUUVAP+P4/9ch/M1PRUEX/AB9z/Rf61PRRRRRVa7/11p/12/8AZGqz RUEv/H3B9G/pTbqB5ygwpRTk/OVJ4Ixx9ahaO6iEzgRAMQQIwcj/ABqzbNOyfv1APbHWpqKK r6h/yDrn/rk38jU6/dH0paKKKKKKKKKKKKKKKKKKKKKKKjQjzpBnnipKrXUjh44kbYXySw6g D0/Om+T/ANNpv++zR5P/AE2m/wC+zR5P/Tab/vs1XjSRFneKZwyuSAxyDwOtaMbb41ccBgDT qKKKKrXTv50UKOU3hmZgOcDHA/MVVtosy3P72UYl7OeflWrHk/8ATab/AL7NHk/9Npv++zVS 3EkVtLLFK+UkkO1jkNhjWqDkAjoaWiiiiq1yzmZIUcopUszDr24FV7eLJm/eyj94f4z6CpvJ /wCm03/fZo8n/ptN/wB9mq0AeC082OVztZmKscgjcc1qUUUUVBdSPHEBHw7sFB9PeqoiP2wg zSk+WOd2O5qbyf8AptN/32aPJ/6bTf8AfZqFIj9pm2zSqQFwd2fX1q5ayNLArsAG5Bx6g4/p UtFFFNkbZGz4ztBNZsySSG1eSVyTJk7TgL8p6VZ8n/ptN/32aPJ/6bTf99moZIv9JhHmy9G5 3/SrNq7lpIpG3FCMN3IPrViiiiisy9LzWl2zSMqqrqqLx0B61OsPyj99N0/vml8n/ptN/wB9 mjyf+m03/fZoiLx3KxmRnR1JG7qpGKt0UUUUUUUUUUUUUUUUUUUUmBnOOaWqd1xeW/8Auv8A 0p+ap28sryt87sNzAhkwq4PGDjn86nt3Zkbe2SGYZxjvTpD+6f6Gp7b/AI9ov9wfyqWiiiiq dycX0H/XOT+aU/NU7eWWRm/eOR8wJZMBeeMcDP61Nbs+1tzlwD8rHGSPw/GnXB/0eT/dP8qt x/6pPoKdRRRRVSc4vU/65n+Ypc1Tt5ZnUkPI2QckoBg+g4GantpGZCHLFlbB3AZH1xx+VF0f 9Fl/3TV+iiiiq1792H/roP5GjNVGlk+1squ5wR8u35cd+cf1ogu1muWVZkZduQoIyOat5pbH /j1H+8//AKEasUUUVHcf8e0v+4f5VXjP7pPoKgupXWaNVd1yCcIm7J4xng8UeZKtwDKZFQ4A C7ducdD361azSWv/AB8z/Rf61aooooqlCf8AWf8AXR/5mmXcjJCCrMuWAyq5OM+mDUTTTbET 95uOTlQoYgH0PHerUcgeNWU5BGQaRTm8i/3W/pVyiiiiiiiiiiiiiiiiiiiiiiqV7xc257YY fjx/hSbqaoVVKrwCSevrSRRpCCE3YJydzE/zpZXAick4AU1cgBW3jBGCFGfyqSiiiiqV4cXk B7bHH6r/AIUm6m7E8sx4IU5yAfWiNFiXClsf7TFv5024cLbyk9Np/lWggIRQeoAp1FFFFUro 4vI894zj8xSbqbtTy/Lx8vpmiNVjXauce5yT+Jpl03+jSD1XFadFFFFVb84jjY9BIMn9Kj3U gADFgOW60YG/dj5sYzS7ql0/mzU9iWI+hY1ZoooqO4BNvIAMkqf5VTicGJCDkbRSkKXD4+YA gGmlEMnmHcT7scfl0p+6nWRzPcEdto/HH/16uUUUUVnRt80o7iRv505grABhnBzSSIkmN2eO mCR/KnAgAAcAdKIjm9iH+yx/lV6iiiiiiiiiiiiiiiiiiiiiiqupgGwlJAJUZHsfWuP+13P/ AD8S/wDfZo+13P8Az8S/99mj7Xc/8/Ev/fZq5pMsk+oxJNI8iE/ddiRXXUUUUUVS1YD+z5G7 rgg+hrkvtdz/AM/Ev/fZo+13P/PxL/32aPtdz/z8S/8AfZq/ossk+oIs0jSL1w5yM11dFFFF FZ+t8abI44ZeVPcfSuV+13P/AD8S/wDfZo+13P8Az8S/99mj7Xc/8/Ev/fZrR0OWSbUFE0jS AcgOc4NdTRRRRTJlDQurAEFTwRXEvdXAdgJ5QAegc0n2u5/5+Jf++zR9ruf+fiX/AL7NSW9x PJcIjzSMpOCCxINdqAFAAAAHAApaKKKK5DVZpYNQlSGR40B4VGIFVPtdz/z8S/8AfZo+13P/ AD8S/wDfZo+13P8Az8S/99muw00AWEJAAyuT7mrVFFFFc94jd4biNomaMsvzFTjNY32u5/5+ Jf8Avs0fa7n/AJ+Jf++zR9ruf+fiX/vs10Xh0l7V5HO5y2Cx5OPrWxRRRRRRRRRX/9k= --------------080602070808070200070205-- From ulrich@herberg.name Fri Jul 23 05:19:09 2010 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 9BBCC3A67D0 for ; Fri, 23 Jul 2010 05:19:09 -0700 (PDT) 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 8ZICBBT4A2-N for ; Fri, 23 Jul 2010 05:19:08 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 5B9C43A696E for ; Fri, 23 Jul 2010 05:19:08 -0700 (PDT) Received: by bwz7 with SMTP id 7so1786998bwz.31 for ; Fri, 23 Jul 2010 05:19:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.53.211 with SMTP id n19mr2487830bkg.66.1279887565669; Fri, 23 Jul 2010 05:19:25 -0700 (PDT) Received: by 10.204.163.5 with HTTP; Fri, 23 Jul 2010 05:19:25 -0700 (PDT) In-Reply-To: <4C4986C0.1060003@gmail.com> References: <4C48B1AE.2030408@gmail.com> <672CA84A-1850-4B17-922F-AE75D4CF961B@inf-net.nl> <4C4986C0.1060003@gmail.com> Date: Fri, 23 Jul 2010 14:19:25 +0200 Message-ID: From: Ulrich Herberg To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Another addressing model for AUTOCONF 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, 23 Jul 2010 12:19:09 -0000 Alex, On Fri, Jul 23, 2010 at 2:10 PM, Alexandru Petrescu wrote: > > Le 23/07/2010 12:58, Teco Boot a =E9crit : >> >> Alex, >> >> Quick comments: >> Your example 2001:1::/24 and 2001:2::/24 share a common prefix. > > WEll no, they are different prefixes, as implemented by IP stacks, as con= sidered by the routing tables and their lookup algorithms, as considered by= the ND tables. 2001:1::/24 and 2001:2::/24 are short forms for 2001:0001::/24 and 2001:0002::/24 (as defined in rfc2373) So, I have to agree with Teco. Maybe you meant 2001:100::/24 and 2001:200:= :/24? Ulrich > >> Better use 2001:1::/32 and 2001:2::/32 or longer, e.g. /64. > > Why 32 instead of 24? > >> On your presso: >> I would not use same ssid on APs in all vehicles. (slide 2, essid: "V3")= . > > Thanks for the comment. =A0It would indeed be good to have different ESSI= Ds within vehicles, in order to prevent potential interference. > > >> And I dislike the address spoofing mode, suggested in slide 4. >> So it so +1 on others remarks. >> >> Teco. >> >> >> Op 22 jul 2010, om 23:01 heeft Alexandru Petrescu het volgende geschreve= n: >> >>> Addressing model we use, pdf 300Kb: >>> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://dl.free.fr/m95j1Km7a >>> (the username is left empty and password is 'password', without >>> quotes. =A0File stays there for 30 days.) >>> >>> Teco asked whether my draft contains an addressing model... true - it d= oesn't show so obviously >>> (http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00= ). >>> >>> I said that there is an addressing model in this figure of the draft: >>>> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 egress| =A0 =A0 = =A0 =A0 =A0 =A0 =A0|egress >>>> =A0 =A0 =A0 =A0 =A0 =A0 ---- =A0 =A0 ---- =A0 =A0---- =A0 =A0 =A0 =A0 = =A0 =A0 =A0---- =A0 =A0 ---- =A0 =A0---- >>>> =A0 =A0 =A0 =A0 =A0 =A0| LFN| =A0 |LFN | =A0| MR | =A0 =A0 =A0 =A0 =A0= =A0| MR | =A0 |LFN | =A0|LFN | >>>> =A0 =A0 =A0 =A0 =A0 =A0 ---- =A0 =A0 ---- =A0 =A0---- =A0 =A0 =A0 =A0 = =A0 =A0 =A0---- =A0 =A0 ---- =A0 =A0---- >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0| ingress| =A0 =A0 =A0 = =A0 =A0 =A0 =A0|ingress =A0 | =A0 =A0 =A0| >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0--------------------- =A0 =A0 =A0 =A0 =A0 = =A0 --------------------- >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2001:1::/24 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 2001:2::/24 >>> >>> ThomasC and Chris also expressed doubts with respect to LFN--MR--MR--LF= N >>> topology and link-local addresses; let me explain further. >>> >>> We are using this addressing model on several moving networks. See the = pdf at the beginning of this email. They show MR-to-MR with a single addres= sing scheme, then with a double addressing scheme; (double is necessary for= our plan.) >>> >>> And then a slide shows MR-to-MR-to-MR addressing model. >>> >>> There are some scalability remarks and a route propagation model (penci= l >>> and paper). >>> >>> The mechanism has been prototyped and demoed since about one year now, >>> on three Mobile Routers and a bunch of LFNs, which shows it may work. W= e >>> have great plans for demoing on vehicles. >>> >>> This is an addressing model we consider strongly. It needs later to >>> auto-configure some prefixes, because currently MNPs are pre-configured >>> in each moving network (this is the case in some deployments). >>> >>> This addressing model is important to us, and uses link-local addresses= . >>> >>> Alex >>> _______________________________________________ >>> 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 Fri Jul 23 05:26:13 2010 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 0E70D3A6828 for ; Fri, 23 Jul 2010 05:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.093, 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 1o4-FTL05j+X for ; Fri, 23 Jul 2010 05:26:12 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id D49693A681A for ; Fri, 23 Jul 2010 05:26:11 -0700 (PDT) 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 o6NCQSnu002049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 14:26:28 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6NCQSH1009024; Fri, 23 Jul 2010 14:26:28 +0200 (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 o6NCQRd2019967; Fri, 23 Jul 2010 14:26:28 +0200 Message-ID: <4C498A73.4000005@gmail.com> Date: Fri, 23 Jul 2010 14:26:27 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Ulrich Herberg References: <4C48B1AE.2030408@gmail.com> <672CA84A-1850-4B17-922F-AE75D4CF961B@inf-net.nl> <4C4986C0.1060003@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] Another addressing model for AUTOCONF 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, 23 Jul 2010 12:26:13 -0000 Le 23/07/2010 14:19, Ulrich Herberg a écrit : > Alex, > > On Fri, Jul 23, 2010 at 2:10 PM, Alexandru Petrescu > wrote: >> >> Le 23/07/2010 12:58, Teco Boot a écrit : >>> >>> Alex, >>> >>> Quick comments: Your example 2001:1::/24 and 2001:2::/24 share a >>> common prefix. >> >> WEll no, they are different prefixes, as implemented by IP stacks, >> as considered by the routing tables and their lookup algorithms, >> as considered by the ND tables. > > > 2001:1::/24 and 2001:2::/24 are short forms for 2001:0001::/24 and > 2001:0002::/24 (as defined in rfc2373) > > So, I have to agree with Teco. Maybe you meant 2001:100::/24 and > 2001:200::/24? Ah right... wrong notation in the slide. (fyi in implementation we have 2002:0:8::/64 and then 9 and 10 instead of 8 - it's that /64 distinguishing them). Thanks for the remark I will update them. Alex > > Ulrich > >> >>> Better use 2001:1::/32 and 2001:2::/32 or longer, e.g. /64. >> >> Why 32 instead of 24? >> >>> On your presso: I would not use same ssid on APs in all >>> vehicles. (slide 2, essid: "V3"). >> >> Thanks for the comment. It would indeed be good to have different >> ESSIDs within vehicles, in order to prevent potential >> interference. >> >> >>> And I dislike the address spoofing mode, suggested in slide 4. >>> So it so +1 on others remarks. >>> >>> Teco. >>> >>> >>> Op 22 jul 2010, om 23:01 heeft Alexandru Petrescu het volgende >>> geschreven: >>> >>>> Addressing model we use, pdf 300Kb: >>>> >>>> http://dl.free.fr/m95j1Km7a (the username is left empty and >>>> password is 'password', without quotes. File stays there for >>>> 30 days.) >>>> >>>> Teco asked whether my draft contains an addressing model... >>>> true - it doesn't show so obviously >>>> (http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00). >>>> >>>> >>>> >>>> I said that there is an addressing model in this figure of the draft: >>>>> >>>>> egress| |egress ---- ---- ---- ---- >>>>> ---- ---- | LFN| |LFN | | MR | | MR | |LFN >>>>> | |LFN | ---- ---- ---- ---- ---- >>>>> ---- | | ingress| |ingress | | >>>>> --------------------- --------------------- >>>>> 2001:1::/24 2001:2::/24 >>>> >>>> ThomasC and Chris also expressed doubts with respect to >>>> LFN--MR--MR--LFN topology and link-local addresses; let me >>>> explain further. >>>> >>>> We are using this addressing model on several moving networks. >>>> See the pdf at the beginning of this email. They show MR-to-MR >>>> with a single addressing scheme, then with a double addressing >>>> scheme; (double is necessary for our plan.) >>>> >>>> And then a slide shows MR-to-MR-to-MR addressing model. >>>> >>>> There are some scalability remarks and a route propagation >>>> model (pencil and paper). >>>> >>>> The mechanism has been prototyped and demoed since about one >>>> year now, on three Mobile Routers and a bunch of LFNs, which >>>> shows it may work. We have great plans for demoing on >>>> vehicles. >>>> >>>> This is an addressing model we consider strongly. It needs >>>> later to auto-configure some prefixes, because currently MNPs >>>> are pre-configured in each moving network (this is the case in >>>> some deployments). >>>> >>>> This addressing model is important to us, and uses link-local >>>> addresses. >>>> >>>> Alex _______________________________________________ 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 Fri Jul 23 06:22:45 2010 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 B0A4A3A69FF for ; Fri, 23 Jul 2010 06:22:45 -0700 (PDT) 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 xdfbQxgCAZv9 for ; Fri, 23 Jul 2010 06:22:45 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id A871A3A69FC for ; Fri, 23 Jul 2010 06:22:44 -0700 (PDT) Received: by eyb7 with SMTP id 7so42540eyb.31 for ; Fri, 23 Jul 2010 06:23:02 -0700 (PDT) Received: by 10.213.28.204 with SMTP id n12mr604135ebc.30.1279891382346; Fri, 23 Jul 2010 06:23:02 -0700 (PDT) Received: from [10.128.0.173] ([77.61.241.196]) by mx.google.com with ESMTPS id v59sm374662eeh.16.2010.07.23.06.23.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 23 Jul 2010 06:23:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4C4987EC.3000500@gmail.com> Date: Fri, 23 Jul 2010 15:23:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7760A358-F35E-4868-9580-9F2324B07F11@inf-net.nl> References: <4C48B1AE.2030408@gmail.com> <672CA84A-1850-4B17-922F-AE75D4CF961B@inf-net.nl> <4C4987EC.3000500@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Another addressing model for AUTOCONF 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, 23 Jul 2010 13:22:45 -0000 Op 23 jul 2010, om 14:15 heeft Alexandru Petrescu het volgende = geschreven: >> And I dislike the address spoofing mode, suggested in slide 4. >=20 > WEll no, I don't suggest any address spoofing mode. What in slide4 = makes you think so? I could explain. (see jpg attached). You depict multiple addresses with FE80::FFFE_MAC1 and FE80::FFFE_MAC2. You have dup L2 addresses (please destroy your stuff), or you spoof = addresses (please don't). Teco= From alexandru.petrescu@gmail.com Fri Jul 23 06:34:20 2010 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 C2E383A6861 for ; Fri, 23 Jul 2010 06:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.112, 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 Jgj-RnGjr9DF for ; Fri, 23 Jul 2010 06:34:19 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id AFDE73A686B for ; Fri, 23 Jul 2010 06:33:57 -0700 (PDT) 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 o6NDYE6r026582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 15:34:14 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6NDYDUX029265; Fri, 23 Jul 2010 15:34:14 +0200 (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 o6NDYDqF012119; Fri, 23 Jul 2010 15:34:13 +0200 Message-ID: <4C499A55.6080103@gmail.com> Date: Fri, 23 Jul 2010 15:34:13 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Teco Boot References: <4C48B1AE.2030408@gmail.com> <672CA84A-1850-4B17-922F-AE75D4CF961B@inf-net.nl> <4C4987EC.3000500@gmail.com> <7760A358-F35E-4868-9580-9F2324B07F11@inf-net.nl> In-Reply-To: <7760A358-F35E-4868-9580-9F2324B07F11@inf-net.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Another addressing model for AUTOCONF 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, 23 Jul 2010 13:34:20 -0000 Le 23/07/2010 15:23, Teco Boot a écrit : > > Op 23 jul 2010, om 14:15 heeft Alexandru Petrescu het volgende > geschreven: > >>> And I dislike the address spoofing mode, suggested in slide 4. >> >> WEll no, I don't suggest any address spoofing mode. What in >> slide4 makes you think so? I could explain. (see jpg attached). > > You depict multiple addresses with FE80::FFFE_MAC1 and > FE80::FFFE_MAC2. You have dup L2 addresses (please destroy your > stuff), or you spoof addresses (please don't). Ah yes sorry. It is again wrong notation on my side. "FE80::FFFE_MAC1" is abbreviation to mean the link local address derived from that interface's MAC address. I do not mean to spoof any address from any interface to any other, sorry for misunderstanding. I could further explain if needed. And I can change the slide if I ever present in AUTOCONF... I am still unaware of any agenda and time is short now. Alex > > Teco From teco@inf-net.nl Fri Jul 23 06:55:37 2010 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 7CA5D3A67B5 for ; Fri, 23 Jul 2010 06:55:37 -0700 (PDT) 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 MCP0hP2qJOhO for ; Fri, 23 Jul 2010 06:55:36 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 728A73A66B4 for ; Fri, 23 Jul 2010 06:55:35 -0700 (PDT) Received: by ewy22 with SMTP id 22so97465ewy.31 for ; Fri, 23 Jul 2010 06:55:53 -0700 (PDT) Received: by 10.213.3.83 with SMTP id 19mr3202020ebm.55.1279893353431; Fri, 23 Jul 2010 06:55:53 -0700 (PDT) Received: from [10.128.0.173] ([77.61.241.196]) by mx.google.com with ESMTPS id z55sm425109eeh.3.2010.07.23.06.55.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 23 Jul 2010 06:55:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4C499A55.6080103@gmail.com> Date: Fri, 23 Jul 2010 15:55:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <279CC75B-84C2-4646-82E0-023DDED29C15@inf-net.nl> References: <4C48B1AE.2030408@gmail.com> <672CA84A-1850-4B17-922F-AE75D4CF961B@inf-net.nl> <4C4987EC.3000500@gmail.com> <7760A358-F35E-4868-9580-9F2324B07F11@inf-net.nl> <4C499A55.6080103@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Another addressing model for AUTOCONF 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, 23 Jul 2010 13:55:37 -0000 Op 23 jul 2010, om 15:34 heeft Alexandru Petrescu het volgende = geschreven: >> You depict multiple addresses with FE80::FFFE_MAC1 and >> FE80::FFFE_MAC2. You have dup L2 addresses (please destroy your >> stuff), or you spoof addresses (please don't). >=20 > Ah yes sorry. It is again wrong notation on my side. = "FE80::FFFE_MAC1" > is abbreviation to mean the link local address derived from that > interface's MAC address. >=20 > I do not mean to spoof any address from any interface to any other, > sorry for misunderstanding. >=20 > I could further explain if needed. And I can change the slide if I = ever > present in AUTOCONF... I am still unaware of any agenda and time is > short now. OK, now you cleared up your proposal. I think it is not new, and in line with IPv6 address architecture. Your proposal highly relate to MEXT, MNP is provided with mechanisms = defined in MEXT, isn't it? So better leave it there. Back to Autoconf: we are looking for solutions for configuring addresses = / prefixes for nodes that require multi-hop communication, without = restrictions for packet relaying via same interface, either for isolated = MANETs and / or for MANETs connected to the Internet. Teco. From alexandru.petrescu@gmail.com Fri Jul 23 07:05:22 2010 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 43FC33A6876 for ; Fri, 23 Jul 2010 07:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.109, 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 Vo8VlZulknrK for ; Fri, 23 Jul 2010 07:05:20 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 581363A686B for ; Fri, 23 Jul 2010 07:05:19 -0700 (PDT) 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 o6NE5bRr018568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 16:05:37 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6NE5bcY006556; Fri, 23 Jul 2010 16:05:37 +0200 (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 o6NE5aWX024036; Fri, 23 Jul 2010 16:05:37 +0200 Message-ID: <4C49A1B0.2010204@gmail.com> Date: Fri, 23 Jul 2010 16:05:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Teco Boot References: <4C48B1AE.2030408@gmail.com> <672CA84A-1850-4B17-922F-AE75D4CF961B@inf-net.nl> <4C4987EC.3000500@gmail.com> <7760A358-F35E-4868-9580-9F2324B07F11@inf-net.nl> <4C499A55.6080103@gmail.com> <279CC75B-84C2-4646-82E0-023DDED29C15@inf-net.nl> In-Reply-To: <279CC75B-84C2-4646-82E0-023DDED29C15@inf-net.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Another addressing model for AUTOCONF 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, 23 Jul 2010 14:05:22 -0000 Le 23/07/2010 15:55, Teco Boot a écrit : > > Op 23 jul 2010, om 15:34 heeft Alexandru Petrescu het volgende > geschreven: > >>> You depict multiple addresses with FE80::FFFE_MAC1 and >>> FE80::FFFE_MAC2. You have dup L2 addresses (please destroy your >>> stuff), or you spoof addresses (please don't). >> >> Ah yes sorry. It is again wrong notation on my side. >> "FE80::FFFE_MAC1" is abbreviation to mean the link local address >> derived from that interface's MAC address. >> >> I do not mean to spoof any address from any interface to any other, >> sorry for misunderstanding. >> >> I could further explain if needed. And I can change the slide if >> I ever present in AUTOCONF... I am still unaware of any agenda and >> time is short now. > > OK, now you cleared up your proposal. I think it is not new, and in > line with IPv6 address architecture. WEll it is indeed not new, but different than the current addressing model draft. > Your proposal highly relate to MEXT, MNP is provided with mechanisms > defined in MEXT, isn't it? Well no, not for the moment. The MNP is provided I don't know how. But however provides that MNP must update routing. > So better leave it there. I will present there. > Back to Autoconf: we are looking for solutions for configuring > addresses / prefixes for nodes that require multi-hop communication, > without restrictions for packet relaying via same interface, either > for isolated MANETs and / or for MANETs connected to the Internet. Ok, deserves another thread, but I don't understand your "without restrictions for packet relaying via same interface". My mechanism does not relay packets via the same interface. Alex > > Teco. > > From hrogge@googlemail.com Fri Jul 23 07:15:32 2010 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 EA8F43A687B for ; Fri, 23 Jul 2010 07:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 xyjFhF5FPQ8T for ; Fri, 23 Jul 2010 07:15:31 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 1D6D73A657C for ; Fri, 23 Jul 2010 07:15:30 -0700 (PDT) Received: by eyb7 with SMTP id 7so56856eyb.31 for ; Fri, 23 Jul 2010 07:15:48 -0700 (PDT) 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=wK5jhwHhegQQz02Q4rP6drj3MtK+v1rx5q+rzILyn/8=; b=YgOQH7JxXDXU+yjSPK7d5EgRf6sAPF5ztQUI4wwE/1YExAg+gakpXc50yWZdSvwNcg mRBxEyCrDGi6NX2fATLyY1HSY90rpJvVMrimorYsR4lXspEPgoybJNCcwD4Ky04kUIYh GFLh/yKyUj+iTJs831IaYwuunOWXMhhCGiEVk= 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=o3gWzmulfn3EDoTjS5/HZlK0fSjVnErocPmy23LETsy9OrZOiLABinSqzDTMCbtnYt iLk5XCRoepAe1VP7TTY1vD+h5t7Prm4WIoQ0RlUBVhtryNV72rcX2MXvJJzO964rmHc7 HmkthTTW+H8vNN6s37DiJ8MKNqgfa4zYYMEmU= Received: by 10.213.31.143 with SMTP id y15mr2599389ebc.38.1279894548028; Fri, 23 Jul 2010 07:15:48 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id x54sm442835eeh.23.2010.07.23.07.15.46 (version=SSLv3 cipher=RC4-MD5); Fri, 23 Jul 2010 07:15:46 -0700 (PDT) From: Henning Rogge To: autoconf@ietf.org Date: Fri, 23 Jul 2010 16:14:25 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.34-gentoo-r2; KDE/4.4.5; x86_64; ; ) References: <4C48B1AE.2030408@gmail.com> <279CC75B-84C2-4646-82E0-023DDED29C15@inf-net.nl> <4C49A1B0.2010204@gmail.com> In-Reply-To: <4C49A1B0.2010204@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1382141.7I2PaQmG56"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201007231615.45447.hrogge@googlemail.com> Subject: Re: [Autoconf] Another addressing model for AUTOCONF 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, 23 Jul 2010 14:15:33 -0000 --nextPart1382141.7I2PaQmG56 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Am Freitag 23 Juli 2010, 16:05:36 schrieb Alexandru Petrescu: > > Back to Autoconf: we are looking for solutions for configuring > > addresses / prefixes for nodes that require multi-hop communication, > > without restrictions for packet relaying via same interface, either > > for isolated MANETs and / or for MANETs connected to the Internet. >=20 > Ok, deserves another thread, but I don't understand your "without > restrictions for packet relaying via same interface". My mechanism does > not relay packets via the same interface. You need "relaying via the same interface" for MANET autoconfiguration. Man= y=20 MANET nodes only have a single interface. Henning Rogge =2D-=20 1) You can't win. 2) You can't break even. 3) You can't leave the game. =E2=80=94 The Laws of Thermodynamics, summarized --nextPart1382141.7I2PaQmG56 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEABECAAYFAkxJo/gACgkQcenvcwAcHWdwCACeKkAMIEX30DP2ZjW2LYt712a2 o18An1NDK9mZyxcjBXUtrmy7yFPtRykB =vpCz -----END PGP SIGNATURE----- --nextPart1382141.7I2PaQmG56-- From teco@inf-net.nl Fri Jul 23 07:25:56 2010 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 D8CA03A66B4 for ; Fri, 23 Jul 2010 07:25:56 -0700 (PDT) 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 aN--gQ8woFRO for ; Fri, 23 Jul 2010 07:25:56 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id C27A53A657C for ; Fri, 23 Jul 2010 07:25:55 -0700 (PDT) Received: by ewy22 with SMTP id 22so111599ewy.31 for ; Fri, 23 Jul 2010 07:26:13 -0700 (PDT) Received: by 10.213.22.201 with SMTP id o9mr3359812ebb.71.1279895173436; Fri, 23 Jul 2010 07:26:13 -0700 (PDT) Received: from [10.128.0.173] ([77.61.241.196]) by mx.google.com with ESMTPS id v8sm468187eeh.2.2010.07.23.07.26.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 23 Jul 2010 07:26:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4C49A1B0.2010204@gmail.com> Date: Fri, 23 Jul 2010 16:26:12 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <4C48B1AE.2030408@gmail.com> <672CA84A-1850-4B17-922F-AE75D4CF961B@inf-net.nl> <4C4987EC.3000500@gmail.com> <7760A358-F35E-4868-9580-9F2324B07F11@inf-net.nl> <4C499A55.6080103@gmail.com> <279CC75B-84C2-4646-82E0-023DDED29C15@inf-net.nl> <4C49A1B0.2010204@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Another addressing model for AUTOCONF 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, 23 Jul 2010 14:25:56 -0000 Op 23 jul 2010, om 16:05 heeft Alexandru Petrescu het volgende geschreven: > >> Back to Autoconf: we are looking for solutions for configuring >> addresses / prefixes for nodes that require multi-hop communication, >> without restrictions for packet relaying via same interface, either >> for isolated MANETs and / or for MANETs connected to the Internet. > > Ok, deserves another thread, but I don't understand your "without > restrictions for packet relaying via same interface". My mechanism does > not relay packets via the same interface. Here our interests divide. Teco From ryuji.wakikawa@gmail.com Wed Jul 28 04:55:17 2010 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 8AC3D28C15A for ; Wed, 28 Jul 2010 04:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 bjRU-JnfaSxD for ; Wed, 28 Jul 2010 04:55:16 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 5C81C28C0F6 for ; Wed, 28 Jul 2010 04:55:16 -0700 (PDT) Received: by ewy22 with SMTP id 22so1871273ewy.31 for ; Wed, 28 Jul 2010 04:55:38 -0700 (PDT) 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=8Jix3d/NURfmFogcoqa7mHd/XPBe6KQWjOn07GknSX0=; b=SA4D6Nxk87Dx6YnYvWIrs5izM7tlPmZ6HQGGDWwo3yyrUyNefrSbobwBD+zYVXkw6B h7z4O1TTdVR5TN1Xmf88Y660UItqGSkCR7BXZUfU5sAwK8dzlci6pQLDUR/5LYqGtFyS rdb2DafvQMZtIR/xeFAAcP4Os4G27mWEnU63Q= 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=m5Iw/oO8jRouHeUDY4kUj4kkpIjkQ4rootDh7RYeoVmE3ZliZnZrBBM3JEYJoh0piF 6fUyhtqhAw+Lr03Gk2FJR43ysrcuRNWRr3pxIq2sDF4i138tScN48/0id0V2We30vd9x XDgXuJW9S6zvm7FKerG/pUfjQIiiHuAzgC4vI= Received: by 10.14.119.67 with SMTP id m43mr2144656eeh.81.1280318138719; Wed, 28 Jul 2010 04:55:38 -0700 (PDT) Received: from dhcp-81f0.meeting.ietf.org (dhcp-81f0.meeting.ietf.org [130.129.129.240]) by mx.google.com with ESMTPS id v8sm9392500eeh.2.2010.07.28.04.55.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 28 Jul 2010 04:55:37 -0700 (PDT) From: Ryuji Wakikawa Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Jul 2010 13:55:36 +0200 Message-Id: <521C476C-B9C5-49B1-9EC9-BCF956204969@gmail.com> To: "autoconf@ietf.org autoconf@ietf.org" Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [Autoconf] IETF78 agenda is now up 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, 28 Jul 2010 11:55:17 -0000 Hi all, Here is our agenda. see you on Friday.=20 http://www.ietf.org/proceedings/78/agenda/autoconf.txt = --------------------------------------------------------------------------= - Ad-Hoc Network Autoconfiguration (autoconf) = --------------------------------------------------------------------------= -- FRIDAY, July 30, 2010 0900-1130 Morning Session I = --------------------------------------------------------------------------= -- - Notes takers, blue sheets, agenda bash 5 min, Chairs - WG status update 5 min, Chairs - RFC5889 update 20min - New Charter discussion, as much as we want, Chairs - "Survey of IP address autoconfiguration mechanisms for MANETs", 15min, = Calros=20 http://tools.ietf.org/html/draft-bernardos-manet-autoconf-survey-05 - "Router Advertisements for Routing between Moving Networks", 15min = Alex http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 = --------------------------------------------------------------------------= --= From erik.nordmark@oracle.com Thu Jul 29 04:49:48 2010 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 A46C73A6980 for ; Thu, 29 Jul 2010 04:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.284 X-Spam-Level: X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[AWL=0.315, 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 CwE1DCOBAUTK for ; Thu, 29 Jul 2010 04:49:47 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 0772128C153 for ; Thu, 29 Jul 2010 04:49:46 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6TBo7PF032758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Jul 2010 11:50:09 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6TBo3r0032003; Thu, 29 Jul 2010 11:50:04 GMT Received: from abhmt007.oracle.com by acsmt355.oracle.com with ESMTP id 448166991280404173; Thu, 29 Jul 2010 04:49:33 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jul 2010 04:49:33 -0700 Message-ID: <4C516AC9.8030803@oracle.com> Date: Thu, 29 Jul 2010 04:49:29 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jari Arkko References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <4C4706D8.5040904@piuha.net> In-Reply-To: <4C4706D8.5040904@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4C516AED.0351:SCFMA4539814,ss=1,fgs=0 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) 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, 29 Jul 2010 11:49:48 -0000 On 07/21/10 07:40 AM, Jari Arkko wrote: > Erik, > >> I do think the document is misleading and confused. >> That starts with the discrepancy between the title >> IP Addressing Model in Ad Hoc Networks >> and the abstract, which limits itself to configuring IP addresses for >> router interfaces and not for the whole of an ad hoc network. >> >> I was under the impression that the WG was looking at a document that >> addressed the scope that is implied by the title. > > OK, though I suspect that Section 1 paragraph 3 and Section 6.1 bullet 2 > still says almost everything there is to say about the rest, too. > Nevertheless, there is a proposal for title change. Perhaps a critical > issue was not making it clear enough in the document that its not just > about router addressing, but also just _a_ model, not _the_ model. I > asked the working group to document one practical model for addressing > rather than cover all possible options, as their work in trying to do > the latter had stalled. OK >> I find the more limited scope odd, since we existing routing protocols >> like IS-IS that can operate (exchange routing information, forward IP >> packets) without any IP addresses configured on the routers' >> interfaces. (Even though a router needs some IP addresses to be >> manageable with SNMP and to be able to send ICMP errors.) >> >> The implied conclusion that IPv6-link local addresses are undesirable >> for router's interfaces is even odder, since RIPng and OSPFv3 both >> require routers to use IPv6 link-local addresses for the routing >> protocol exchanges. > > This may have been an issue in the document as approved, but I do not > think there is an implication left in the text with the proposed changes > folded in. Apart from the issue below related to link-locals that are globally unique. > More importantly, as the document correctly states there are differences > in the requirements that routing protocols place on available addresses. > I think the document makes a very pragmatic model choice in this light. > >> The document seems to assume that the uniqueness scope of link-local >> addresses is limited to a single link, when it is the routability >> scope which is limited to the link. There is a class of link-local >> addresses with U=1 (those derived from EUI-64) that are globally >> unique - but still is not routable outside of the link. > > I agree about the distinction, of course. But I re-read the document > today but cannot see where the document claims otherwise. It does say Note that while link-local addresses are assumed to be "on link", the utility of link-local addresses is limited as described in Section 6. and later o There is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, hence they cannot be used to reliably identify routers (it is often desirable to identify a router with an IP address). If we strike out the first cited paragraph, and clarify the second cited one to say: o In general there is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, however link-local addresses using an IID that is of the modified EUI-64 form is globally unique. Thus if link-local addresses are used to reliably identify routers then they must be of the modified EUI-64 form. >> The result is that the document can easily be construed as >> discouraging approaches that make a lot of sense, which seems >> counterproductive. >> An example of such an approach is a routing protocol which uses IEEE >> MAC addresses as router ids, assigns IPv6 link-local addresses to the >> router's interfaces and uses that in the routing protocol exchanges, >> and configures global addresses for use by applications. > > Again, I do not believe that the changed document can be construed as > discouraging. I disagree. My proposed edit above would take care of the issue though. >> I suggest the wording >> Routing protocols that do not require unique IP addresses within the >> routing domain utilize a separate unique identifier within the routing >> protocol itself; such identifiers could be based on factory assignment >> or configuration. > > We can make this change. OK > There is a difference between an intent to create addresses with a > particular scope, and our ability to test that they really are unique. > The text says "no mechanism to ensure" and I take that it means the > testing part. This seems correct, though I do agree that it might have > been confusing. Which mechanism do we have to test that a global IPv6 address is in fact globally unique? I certainly don't know of one. We rely on assumptions that the IPv6 prefixes are uniquely delegated by the IANA, RIRs, site subnet number allocating admin, etc down to each host. For the EUI-64 we rely on the assumption that the IEEE RAC and the vendors uniquely allocate EUI-64s. In neither case do we have a test. >> This paragraph seems like a non seqiteur: >> o Routers cannot forward any packets with link-local source or >> destination addresses to other links (as per [RFC4291]) while most >> of the time, routers need to be able to forward packets to/from >> different links. >> Clearly the application traffic needs to use non-link-local addresses >> to work across multiple links, but that has nothing to do with what IP >> addresses are configured on the interfaces of routers as we see from >> the requirement for RIPng and OSPFv3 to use IPv6 link-locals on router >> interfaces. >> >> Instead the issue is that link-local addresses are not useful for >> applications *other than routing protocols*, and that is the >> motivation for the subsequent paragraph: > > This section talks about the limited utility of link-local addresses. I > agree that the paragraph above is relevant in an application context. >>> OLD: >>> Therefore, autoconfiguration solutions should be encouraged to >>> primarily focus on configuring IP addresses that are not IPv6 link- >>> local. >>> NEW: >>> Therefore, an autoconfiguration solution which provides a mechanism for >>> assigning addresses with a wider scope than IPv6 link-local alone will >>> be more generally useful than one that does not. >> >> That misses the point. It is the motivation for this recommendation >> which is confused and misleading, and not the conclusion itself. The >> motivation is that applications (other than routing protocols) most >> likely desire to communicate across the whole Ad Hoc network, if not >> across the whole Internet, which makes link-local addresses of limited >> use. > > We agree so far. > >> But they can still be quite useful as for the purposes of routing >> protocols, and bootstrapping address autoconfiguration protocols. > > And no one is disputing that. However, as stated in the document there > are routing protocols that _do_ require non-link local addresses. So > while I agree with your "can be still quite useful" claim I do not see a > basis for claiming that link local addresses should be the one and only > form of address configuration for routing protocols, or even that such > addresses must be available as part of an addressing model. As I said, I have no issue with the final recommendation that Therefore, autoconfiguration solutions should be encouraged to primarily focus on configuring IP addresses that are not IPv6 link- local. But the text that makes that argument is fundamentally confused about the uniqueness issues around link-locals, and also tries to argue things from a router perspective when the main argument is that applications want something wider than link locals. I suggest splitting this item into two. FROM o Routers cannot forward any packets with link-local source or destination addresses to other links (as per [RFC4291]) while most of the time, routers need to be able to forward packets to/from different links. TO o Routers often need to be reachable at a global address for management purposes. o Routers cannot forward any packets with link-local source or destination addresses to other links (as per [RFC4291]) while most of the time, applications assume that routers can forward packets to/from different links. If you don't want to add the "management" bullet that is fine with me. But the second bullet should be about applications. Erik From erik.nordmark@oracle.com Thu Jul 29 05:04:57 2010 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 7ABA928C142 for ; Thu, 29 Jul 2010 05:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.296 X-Spam-Level: X-Spam-Status: No, score=-6.296 tagged_above=-999 required=5 tests=[AWL=0.303, 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 2MkXB7PkQ8X3 for ; Thu, 29 Jul 2010 05:04:56 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 6AD2F3A6836 for ; Thu, 29 Jul 2010 05:04:56 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6TC5I86016197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Jul 2010 12:05:20 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6TAo01V022000; Thu, 29 Jul 2010 12:05:18 GMT Received: from abhmt021.oracle.com by acsmt353.oracle.com with ESMTP id 467560901280405113; Thu, 29 Jul 2010 05:05:13 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jul 2010 05:05:12 -0700 Message-ID: <4C516E75.2010405@oracle.com> Date: Thu, 29 Jul 2010 05:05:09 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jari Arkko References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <4C4706D8.5040904@piuha.net> <4C516AC9.8030803@oracle.com> In-Reply-To: <4C516AC9.8030803@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4C516E7E.0123:SCFMA4539814,ss=1,fgs=0 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] RFC 5889 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, 29 Jul 2010 12:04:57 -0000 I talked to Jari about this earlier in the week, and in the interest of trying to close this issue I've gathered together the earlier suggested changes, added the suggested title change, and included the edits I suggested a few minutes ago. Note that I'm not particularly wedded to the title change. Erik Change the title FROM IP Addressing Model in Ad Hoc Networks TO A Router Addressing Model in Ad Hoc Networks In section 4 REMOVE Note that while link-local addresses are assumed to be "on link", the utility of link-local addresses is limited as described in Section 6. In section 5: OLD: Routing protocols running on a router may exhibit different requirements for uniqueness of interface addresses; some have no such requirements, others have requirements ranging from local uniqueness only, to uniqueness within, at least, the routing domain (as defined in [RFC1136]). Configuring an IP address that is unique within the routing domain satisfies the less stringent uniqueness requirements of local uniqueness, while also enabling protocols which have the most stringent requirements of uniqueness within the routing domain. This suggests the following principle: o an IP address assigned to an interface that connects to a link with undetermined connectivity properties should be unique, at least within the routing domain. NEW: Routing protocols running on a router may exhibit different requirements for uniqueness of interface addresses; some have no such requirements, others have requirements ranging from local uniqueness only, to uniqueness within, at least, the routing domain (as defined in [RFC1136]). Routing protocols that do not require unique IP addresses within the routing domain utilize a separate unique identifier within the routing protocol itself; such identifiers could be based on factory assignment or configuration. Nevertheless, configuring an IP address that is unique within the routing domain satisfies the less stringent uniqueness requirements of local uniqueness, while also enabling protocols which have the most stringent requirements of uniqueness within the routing domain. As a result, the following principle allows for IP autoconfiguration to apply to the widest array of routing protocols: o an IP address assigned to an interface that connects to a link with undetermined connectivity properties should be unique, at least within the routing domain. In Section 6.1: OLD: o There is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, hence they cannot be used to reliably identify routers (it is often desirable to identify a router with an IP address). NEW: o In general there is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, however link-local addresses using an IID that is of the modified EUI-64 form is globally unique. Thus if link-local addresses are used to reliably identify routers then they must be of the modified EUI-64 form. OLD: Therefore, autoconfiguration solutions should be encouraged to primarily focus on configuring IP addresses that are not IPv6 link- local. NEW: Therefore, an autoconfiguration solution which provides a mechanism for assigning addresses with a wider scope than IPv6 link-local alone will be more generally useful than one that does not. --- From erik.nordmark@oracle.com Thu Jul 29 05:07:03 2010 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 19F853A69A2 for ; Thu, 29 Jul 2010 05:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.308 X-Spam-Level: X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[AWL=0.291, 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 I5ILCfjuHO1I for ; Thu, 29 Jul 2010 05:06:59 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id E967F3A68B2 for ; Thu, 29 Jul 2010 05:06:58 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6TC7LLp020447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Jul 2010 12:07:22 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6TC0uE9007042; Thu, 29 Jul 2010 12:07:20 GMT Received: from abhmt005.oracle.com by acsmt355.oracle.com with ESMTP id 467566471280405233; Thu, 29 Jul 2010 05:07:13 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jul 2010 05:07:12 -0700 Message-ID: <4C516EEE.8080504@oracle.com> Date: Thu, 29 Jul 2010 05:07:10 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jari Arkko References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <4C4706D8.5040904@piuha.net> <4C516AC9.8030803@oracle.com> <4C516E75.2010405@oracle.com> In-Reply-To: <4C516E75.2010405@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4C516EF8.028F:SCFMA4539814,ss=1,fgs=0 Cc: "autoconf@ietf.org" Subject: [Autoconf] Forgot one [Was: RFC 5889 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, 29 Jul 2010 12:07:03 -0000 [I lost one of the suggested edits. This is the complete list.] I talked to Jari about this earlier in the week, and in the interest of trying to close this issue I've gathered together the earlier suggested changes, added the suggested title change, and included the edits I suggested a few minutes ago. Note that I'm not particularly wedded to the title change. Erik Change the title FROM IP Addressing Model in Ad Hoc Networks TO A Router Addressing Model in Ad Hoc Networks In section 4 REMOVE Note that while link-local addresses are assumed to be "on link", the utility of link-local addresses is limited as described in Section 6. In section 5: OLD: Routing protocols running on a router may exhibit different requirements for uniqueness of interface addresses; some have no such requirements, others have requirements ranging from local uniqueness only, to uniqueness within, at least, the routing domain (as defined in [RFC1136]). Configuring an IP address that is unique within the routing domain satisfies the less stringent uniqueness requirements of local uniqueness, while also enabling protocols which have the most stringent requirements of uniqueness within the routing domain. This suggests the following principle: o an IP address assigned to an interface that connects to a link with undetermined connectivity properties should be unique, at least within the routing domain. NEW: Routing protocols running on a router may exhibit different requirements for uniqueness of interface addresses; some have no such requirements, others have requirements ranging from local uniqueness only, to uniqueness within, at least, the routing domain (as defined in [RFC1136]). Routing protocols that do not require unique IP addresses within the routing domain utilize a separate unique identifier within the routing protocol itself; such identifiers could be based on factory assignment or configuration. Nevertheless, configuring an IP address that is unique within the routing domain satisfies the less stringent uniqueness requirements of local uniqueness, while also enabling protocols which have the most stringent requirements of uniqueness within the routing domain. As a result, the following principle allows for IP autoconfiguration to apply to the widest array of routing protocols: o an IP address assigned to an interface that connects to a link with undetermined connectivity properties should be unique, at least within the routing domain. In Section 6.1: OLD: o There is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, hence they cannot be used to reliably identify routers (it is often desirable to identify a router with an IP address). NEW: o In general there is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, however link-local addresses using an IID that is of the modified EUI-64 form is globally unique. Thus if link-local addresses are used to reliably identify routers then they must be of the modified EUI-64 form. In section 6.1 FROM o Routers cannot forward any packets with link-local source or destination addresses to other links (as per [RFC4291]) while most of the time, routers need to be able to forward packets to/from different links. TO o Routers often need to be reachable at a global address for management purposes. o Routers cannot forward any packets with link-local source or destination addresses to other links (as per [RFC4291]) while most of the time, applications assume that routers can forward packets to/from different links. Also in section 6.1 OLD: Therefore, autoconfiguration solutions should be encouraged to primarily focus on configuring IP addresses that are not IPv6 link- local. NEW: Therefore, an autoconfiguration solution which provides a mechanism for assigning addresses with a wider scope than IPv6 link-local alone will be more generally useful than one that does not. --- From Chris.Dearlove@baesystems.com Thu Jul 29 05:40:42 2010 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 D7C013A69D5 for ; Thu, 29 Jul 2010 05:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.828 X-Spam-Level: X-Spam-Status: No, score=-6.828 tagged_above=-999 required=5 tests=[AWL=-0.229, 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 U89HxnYRNdSC for ; Thu, 29 Jul 2010 05:40:23 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id E5B203A6A00 for ; Thu, 29 Jul 2010 05:40:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,280,1278284400"; d="scan'208";a="79133023" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 29 Jul 2010 13:39:34 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o6TCdXCv022870; Thu, 29 Jul 2010 13:39:33 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Jul 2010 13:39:33 +0100 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, 29 Jul 2010 13:39:32 +0100 Message-ID: In-Reply-To: <4C516E75.2010405@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] RFC 5889 thread-index: AcsvFlVYAHrkTsYOSVewQC8QPc+LKwAA6DiA References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net><4C378C29.2040302@oracle.com> <4C4706D8.5040904@piuha.net><4C516AC9.8030803@oracle.com> <4C516E75.2010405@oracle.com> From: "Dearlove, Christopher (UK)" To: "Erik Nordmark" , "Jari Arkko" X-OriginalArrivalTime: 29 Jul 2010 12:39:33.0766 (UTC) FILETIME=[18D89260:01CB2F1B] Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 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, 29 Jul 2010 12:40:43 -0000 > NEW: > o In general there is no mechanism to ensure that IPv6 link-local > addresses are unique across multiple links, however link-local > addresses using an IID that is of the modified EUI-64 form is > globally unique. Thus if link-local addresses are used to reliably > identify routers then they must be of the modified EUI-64 form. That's a change in substance from something being discouraged (see the following OLD quote) to telling you how to do that very something. > OLD: > Therefore, autoconfiguration solutions should be encouraged to > primarily focus on configuring IP addresses that are not IPv6 link- > local. > > NEW: > Therefore, an autoconfiguration solution which provides a mechanism for > assigning addresses with a wider scope than IPv6 link-local alone will > be more generally useful than one that does not. That's more than an AUTH-48 error correction, it's a substantial change in the document's intent. Or so it appears to me. -- 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 ******************************************************************** 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 erik.nordmark@oracle.com Thu Jul 29 05:45:57 2010 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 429EC28C1D2 for ; Thu, 29 Jul 2010 05:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.329 X-Spam-Level: X-Spam-Status: No, score=-6.329 tagged_above=-999 required=5 tests=[AWL=0.270, 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 hC80pTyLwTNq for ; Thu, 29 Jul 2010 05:45:55 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 65B1428C149 for ; Thu, 29 Jul 2010 05:45:55 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6TCkGcf018389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Jul 2010 12:46:18 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6TCjJUs013651; Thu, 29 Jul 2010 12:45:29 GMT Received: from abhmt020.oracle.com by acsmt354.oracle.com with ESMTP id 467660011280407449; Thu, 29 Jul 2010 05:44:09 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jul 2010 05:44:08 -0700 Message-ID: <4C517795.1080001@oracle.com> Date: Thu, 29 Jul 2010 05:44:05 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net><4C378C29.2040302@oracle.com> <4C4706D8.5040904@piuha.net><4C516AC9.8030803@oracle.com> <4C516E75.2010405@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4C517800.0295:SCFMA4539814,ss=1,fgs=0 Cc: autoconf@ietf.org Subject: Re: [Autoconf] RFC 5889 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, 29 Jul 2010 12:45:57 -0000 On 07/29/10 05:39 AM, Dearlove, Christopher (UK) wrote: >> NEW: >> o In general there is no mechanism to ensure that IPv6 link-local >> addresses are unique across multiple links, however link-local >> addresses using an IID that is of the modified EUI-64 form is >> globally unique. Thus if link-local addresses are used to reliably >> identify routers then they must be of the modified EUI-64 form. > > That's a change in substance from something being discouraged (see the > following OLD quote) to telling you how to do that very something. Your observation is correct. However, the recommendation of the draft doesn't change as a result of this. The arguments leading up to the recommendation were flawed IMHO, but the recommendation is fine. >> OLD: >> Therefore, autoconfiguration solutions should be encouraged to >> primarily focus on configuring IP addresses that are not IPv6 link- >> local. >> >> NEW: >> Therefore, an autoconfiguration solution which provides a mechanism > for >> assigning addresses with a wider scope than IPv6 link-local alone > will >> be more generally useful than one that does not. > > That's more than an AUTH-48 error correction, it's a substantial change > in the document's intent. Or so it appears to me. FWIW I didn't suggest that change; it might have been Jari. Erik From alexandru.petrescu@gmail.com Thu Jul 29 16:09:59 2010 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 2CC4A3A67C3 for ; Thu, 29 Jul 2010 16:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=0.265, 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 IaH19WAvEzaO for ; Thu, 29 Jul 2010 16:09:58 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 1C2883A679C for ; Thu, 29 Jul 2010 16:09:57 -0700 (PDT) Received: by bwz7 with SMTP id 7so585568bwz.31 for ; Thu, 29 Jul 2010 16:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=pvYJU5pVpQMNt8sQQhqv8ftXNbNeiVu79xymWHMOJMA=; b=jMEhtVMTac6fYygPVd/5+RJ038z7lQKjvr6SQ+hSPvtHdiM/6yZ9U99V0sZluVtdRm Oirci6cqIscI/aNtRJHxuIwh5FnoMURC25pCg/VO1SEVbj8cLnK260Hil4x/3k8itoAl kHqhXwc5BkcmQL8IW1G0TwcNWWmhH+ZFt0s+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=qoqaoDTQJSgMkqhSl3oMDN30uMX+GETwk/M04Op3AaJKCbUzHqwcLFGcdxsD0MUzWZ PHx0TNG2hpPiiUwFbviYKZwDngLUv6fwkQnFwPLJ1lVBLkPMJYizLcMq87SNim8Qs/yB p7wD4xOxx4EyI3D/v7OXmXTxnYpG2xXgt/ziE= MIME-Version: 1.0 Received: by 10.204.1.139 with SMTP id 11mr524150bkf.174.1280445021805; Thu, 29 Jul 2010 16:10:21 -0700 (PDT) Received: by 10.204.47.228 with HTTP; Thu, 29 Jul 2010 16:10:21 -0700 (PDT) Date: Fri, 30 Jul 2010 01:10:21 +0200 Message-ID: From: Alexandru Petrescu To: autoconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Autoconf] Slides for AUTOCONF presentation "Router Advertisements for Routing between Moving 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: Thu, 29 Jul 2010 23:09:59 -0000 URL for slides of my presentation tomorrow : "Router Advertisements for Routing between Moving Networks" draft-petrescu-autoconf-ra-based-routing-00 http://dl.free.fr/qZ4KN9tSP (username left empty, password is 'password' w/o quotes, the button to press is "T=E9l=E9charger ce fichier" in the middle of the page, file stays there for 30 days). Alex From erik.nordmark@oracle.com Fri Jul 30 01:14:18 2010 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 0C89B3A6A76 for ; Fri, 30 Jul 2010 01:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, 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 4pX3K4aCt5Io for ; Fri, 30 Jul 2010 01:14:14 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 469173A69BD for ; Fri, 30 Jul 2010 01:14:14 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6U8Ebpj031180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 30 Jul 2010 08:14:38 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6U6mNnc017917 for ; Fri, 30 Jul 2010 08:14:34 GMT Received: from abhmt020.oracle.com by acsmt355.oracle.com with ESMTP id 451609581280477567; Fri, 30 Jul 2010 01:12:47 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Jul 2010 01:12:47 -0700 Message-ID: <4C528979.7010006@oracle.com> Date: Fri, 30 Jul 2010 01:12:41 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: autoconf@ietf.org References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <4C4706D8.5040904@piuha.net> <4C516AC9.8030803@oracle.com> <4C516E75.2010405@oracle.com> <4C516EEE.8080504@oracle.com> In-Reply-To: <4C516EEE.8080504@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4C5289EC.0022:SCFMA4539814,ss=1,fgs=0 Subject: Re: [Autoconf] Forgot one [Was: RFC 5889 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, 30 Jul 2010 08:14:18 -0000 Please double-check this, but I think it has all the list of changes that Jari said verbally. Erik ---- Change the title FROM IP Addressing Model in Ad Hoc Networks TO A Router Addressing Model in Ad Hoc Networks In section 5: OLD: Routing protocols running on a router may exhibit different requirements for uniqueness of interface addresses; some have no such requirements, others have requirements ranging from local uniqueness only, to uniqueness within, at least, the routing domain (as defined in [RFC1136]). Configuring an IP address that is unique within the routing domain satisfies the less stringent uniqueness requirements of local uniqueness, while also enabling protocols which have the most stringent requirements of uniqueness within the routing domain. This suggests the following principle: o an IP address assigned to an interface that connects to a link with undetermined connectivity properties should be unique, at least within the routing domain. NEW: Routing protocols running on a router may exhibit different requirements for uniqueness of interface addresses; some have no such requirements, others have requirements ranging from local uniqueness only, to uniqueness within, at least, the routing domain (as defined in [RFC1136]). Routing protocols that do not require unique IP addresses within the routing domain utilize a separate unique identifier within the routing protocol itself; such identifiers could be based on factory assignment or configuration. Nevertheless, configuring an IP address that is unique within the routing domain satisfies the less stringent uniqueness requirements of local uniqueness, while also enabling protocols which have the most stringent requirements of uniqueness within the routing domain. As a result, the following principle allows for IP autoconfiguration to apply to the widest array of routing protocols: o an IP address assigned to an interface that connects to a link with undetermined connectivity properties should be unique, at least within the routing domain. In Section 6.1: OLD: o There is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, hence they cannot be used to reliably identify routers (it is often desirable to identify a router with an IP address). NEW: o In general there is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, however link-local addresses using an IID that are of the modified EUI-64 form are globally unique. Thus if link-local addresses are used to reliably identify routers then they must be of the modified EUI-64 form. --- From Chris.Dearlove@baesystems.com Fri Jul 30 02:19:10 2010 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 DC7E028C2A9 for ; Fri, 30 Jul 2010 02:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.823 X-Spam-Level: X-Spam-Status: No, score=-6.823 tagged_above=-999 required=5 tests=[AWL=-0.224, 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 F76nH6ruy2Df for ; Fri, 30 Jul 2010 02:19:09 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 5433928C24E for ; Fri, 30 Jul 2010 02:19:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,286,1278284400"; d="scan'208";a="79307092" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 30 Jul 2010 10:19:33 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o6U9JXoY019452; Fri, 30 Jul 2010 10:19:33 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Jul 2010 10:19:33 +0100 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, 30 Jul 2010 10:19:30 +0100 Message-ID: In-Reply-To: <4C528979.7010006@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] Forgot one [Was: RFC 5889 thread-index: Acsvv0oGDuDl1unJQ52kYHRub+aBagABaoag References: <4C2A6BB7.1000900@piuha.net><4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com><4C4706D8.5040904@piuha.net> <4C516AC9.8030803@oracle.com><4C516E75.2010405@oracle.com> <4C516EEE.8080504@oracle.com> <4C528979.7010006@oracle.com> From: "Dearlove, Christopher (UK)" To: "Erik Nordmark" , X-OriginalArrivalTime: 30 Jul 2010 09:19:33.0053 (UTC) FILETIME=[5246D6D0:01CB2FC8] Subject: Re: [Autoconf] Forgot one [Was: RFC 5889 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, 30 Jul 2010 09:19:10 -0000 I was trying to work out if this left the link local address references coherent or not. These are, I believe, all the paragraphs that discuss them. I think the first is irrelevant to this discussion, but I've included it for completeness. OLD: Note that routers may ultimately need additional IP prefixes for the diverse applications that could run directly on the routers themselves, or for assignment to attached hosts or networks. For IPv6, these addresses may be global [RFC3587], Unique-Local [RFC4193] or Link-Local [RFC4291]. For IPv4, the addresses may be global (i.e., public) or private [RFC1918]. In general, global scope is desired over local scope, though it is understood that this may not always be achievable via automatic configuration mechanisms. In this document however, automatic configuration of the prefixes used for general applications is considered as a problem that is separable from that of automatic configuration of addresses and prefixes necessary for routing protocols to function. This document thus focuses on the latter: the type of IP address and subnet mask configuration necessary for routing protocols and data packet forwarding to function. OLD: Note that while link-local addresses are assumed to be "on link", the utility of link-local addresses is limited as described in Section 6. NOTE: The next four paragraphs (all but the last) are consecutive. OLD: Note that while an IPv6 link-local address is assigned to each interface as per [RFC4291], in general link-local addresses are of limited utility on links with undetermined connectivity, as connectivity to neighbors may be constantly changing. The known limitations are: NEW: o In general there is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, however link-local addresses using an IID that are of the modified EUI-64 form are globally unique. Thus if link-local addresses are used to reliably identify routers then they must be of the modified EUI-64 form. OLD: o Routers cannot forward any packets with link-local source or destination addresses to other links (as per [RFC4291]) while most of the time, routers need to be able to forward packets to/from different links. Therefore, autoconfiguration solutions should be encouraged to primarily focus on configuring IP addresses that are not IPv6 link- local. OLD: Note that the use of IPv4 link-local addresses [RFC3927] in this context should be discouraged for most applications, as the limitations outlined in Section 6.1 for IPv6 link-local addresses also concern IPv4 link-local addresses. These limitations are further exacerbated by the smaller pool of IPv4 link-local addresses to choose from and thus increased reliance on Duplicate Address Detection (DAD). The text before the bullet points indicates that they are about "The known weaknesses are". The recommendation "Thus if link-local addresses are used to reliably identify routers then they must be of the modified EUI-64 form." doesn't really fit that, and also is a bad fit with the primary focus referred to after the bullet points. What is appropriate to say, that EUI-64 addresses are globally unique is said in the previous sentence. I think the document would be more internally consistent, and not adding a change in recommendations, if that sentence were deleted from the new paragraph, which would be left as: NEW: o In general there is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, however link-local addresses using an IID that are of the modified EUI-64 form are globally unique. (Personally, I'd modify that a little further, to: o In general there is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, however link-local addresses using an IID that are of the modified EUI-64 form ahould be globally unique. but this is not the point of this email.) -- 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 ******************************************************************** 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 teco@inf-net.nl Fri Jul 30 04:57:24 2010 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 B1FCD3A6936 for ; Fri, 30 Jul 2010 04:57:24 -0700 (PDT) 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 jSPffDtd5VqC for ; Fri, 30 Jul 2010 04:57:23 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id CAEA93A68E3 for ; Fri, 30 Jul 2010 04:57:22 -0700 (PDT) Received: by ewy22 with SMTP id 22so630293ewy.31 for ; Fri, 30 Jul 2010 04:57:46 -0700 (PDT) Received: by 10.213.114.67 with SMTP id d3mr1097791ebq.73.1280491066355; Fri, 30 Jul 2010 04:57:46 -0700 (PDT) Received: from dhcp-61f2.meeting.ietf.org (dhcp-61f2.meeting.ietf.org [130.129.97.242]) by mx.google.com with ESMTPS id a48sm3019612eei.1.2010.07.30.04.57.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 30 Jul 2010 04:57:45 -0700 (PDT) From: Teco Boot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Jul 2010 13:57:43 +0200 Message-Id: To: "autoconf@ietf.org autoconf@ietf.org" Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64 interfaces? 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, 30 Jul 2010 11:57:24 -0000 RFC3315: ... The client MUST use a link-local address assigned to the interface for which it is requesting configuration information as the source address in the header of the IP datagram. Question: can we get around a MUST in a standards track RFC? I don't think so. The to be posted proposed text for to be RFC5889 would say that if = link-locals are used, there are potential problems when using other than = modified EUI-64 IIDs, and therefore must be based on modified EUI-64 = IIDs. Second question, on first item in charter: do we limit ourself to MANET = routers that has modified EUI-64 link-locals? I think: better think twice. Opinions? Teco. From Chris.Dearlove@baesystems.com Fri Jul 30 06:52:28 2010 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 6C3493A69C5 for ; Fri, 30 Jul 2010 06:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.818 X-Spam-Level: X-Spam-Status: No, score=-6.818 tagged_above=-999 required=5 tests=[AWL=-0.219, 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 Y7iX1Mn5r6ij for ; Fri, 30 Jul 2010 06:52:21 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 7B87C3A693B for ; Fri, 30 Jul 2010 06:52:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,287,1278284400"; d="scan'208";a="79384762" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 30 Jul 2010 14:52:42 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o6UDqgfM004281; Fri, 30 Jul 2010 14:52:42 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Jul 2010 14:52:42 +0100 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, 30 Jul 2010 14:52:39 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64interfaces? thread-index: Acsv3nC9JwRqDHGBSyy8/El4C4NDYgADYbzw References: From: "Dearlove, Christopher (UK)" To: "Teco Boot" , X-OriginalArrivalTime: 30 Jul 2010 13:52:42.0501 (UTC) FILETIME=[7B262350:01CB2FEE] Subject: Re: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64interfaces? 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, 30 Jul 2010 13:52:28 -0000 Teco > Question: can we get around a MUST in a standards track RFC? > I don't think so. There is the "don't use that RFC, use another one - or none" approach. > Second question, on first item in charter: do we limit ourself > to MANET routers that has modified EUI-64 link-locals? Definitely not. There are issues with EUI-64. One of these is privacy/security. If I use a device today, and use the same device at a different time and in a different place, it's still clearly identified as the same device. That can be a problem. There's a discussion in RFC 3041. That's obsoleted by RFC 4941. I mention the older version as someone was concered enough to write draft-dupont-ipv6-rfc3041harmful-05.txt that argued against RFC 3041 (but never made it to RFC). My point is, there are issues, and people of goodwill and expertise disagree on the subject. Probably because of different backgrounds and assumptions. One size does not fit all. -- 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 ******************************************************************** 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 Fred.L.Templin@boeing.com Fri Jul 30 08:40:20 2010 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 6D91A3A6A0E for ; Fri, 30 Jul 2010 08:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.96 X-Spam-Level: X-Spam-Status: No, score=-5.96 tagged_above=-999 required=5 tests=[AWL=0.639, 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 XwmAsogjgcmk for ; Fri, 30 Jul 2010 08:40:19 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 5446C3A68F9 for ; Fri, 30 Jul 2010 08:40:19 -0700 (PDT) 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.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o6UFecbx015890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Jul 2010 08:40:39 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o6UFebFh006170; Fri, 30 Jul 2010 10:40:37 -0500 (CDT) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o6UFebPf006159 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 30 Jul 2010 10:40:37 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Fri, 30 Jul 2010 08:40:36 -0700 From: "Templin, Fred L" To: Teco Boot , "autoconf@ietf.org autoconf@ietf.org" Date: Fri, 30 Jul 2010 08:40:35 -0700 Thread-Topic: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64interfaces? Thread-Index: Acsv3nCFZKLFKv20QIOKGSEDlgq1fgAHr6nQ Message-ID: References: In-Reply-To: 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 Subject: Re: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64interfaces? 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, 30 Jul 2010 15:40:20 -0000 Teco, > -----Original Message----- > From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Beh= alf Of Teco Boot > Sent: Friday, July 30, 2010 4:58 AM > To: autoconf@ietf.org autoconf@ietf.org > Subject: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64i= nterfaces? >=20 > RFC3315: > ... The client > MUST use a link-local address assigned to the interface for which it > is requesting configuration information as the source address in the > header of the IP datagram. >=20 > Question: can we get around a MUST in a standards track RFC? > I don't think so. If the MANET router only behaves as a client on an internal link (e.g., a loopback) but behaves as a relay on its MANET interfaces, then link-locals need not be exposed for DHCPv6 purposes. There are other reasons why link-locals might need to be considered for MANETs, but I'm not sure this is one of them. Fred fred.l.templin@boeing.com =20 > The to be posted proposed text for to be RFC5889 would say that if link-l= ocals are used, there are > potential problems when using other than modified EUI-64 IIDs, and theref= ore must be based on > modified EUI-64 IIDs. >=20 > Second question, on first item in charter: do we limit ourself to MANET r= outers that has modified > EUI-64 link-locals? > I think: better think twice. >=20 > Opinions? >=20 > Teco. >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From teco@inf-net.nl Sat Jul 31 04:19:03 2010 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 7B3D43A6885 for ; Sat, 31 Jul 2010 04:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] 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 JMYXyxUxB5RC for ; Sat, 31 Jul 2010 04:19:02 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 51D523A67B7 for ; Sat, 31 Jul 2010 04:19:01 -0700 (PDT) Received: by ewy22 with SMTP id 22so1016254ewy.31 for ; Sat, 31 Jul 2010 04:19:26 -0700 (PDT) Received: by 10.213.28.145 with SMTP id m17mr728268ebc.66.1280575166351; Sat, 31 Jul 2010 04:19:26 -0700 (PDT) Received: from [192.168.2.190] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id a48sm4958990eei.18.2010.07.31.04.19.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 31 Jul 2010 04:19:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Sat, 31 Jul 2010 13:19:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9ED0AF66-FB65-485C-B418-E25200A0DE88@inf-net.nl> References: To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64interfaces? 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, 31 Jul 2010 11:19:03 -0000 Chris, thanks for sharing your opinion. On using DHCP, the draft charter, workitem 1, specifies usage of DHCPv6. When thinking on how this could work, I want to know what requirements = are. Did I catch "un-touched DHCPv6" at the meeting? On RFC 3091 and dupont-ipv6-rfc3041harmful, the recommendations are in = RFC 4901. The change on site duplicates for well generated CGA or private IIDs is = close=20 to zero. I think duplicate address problems with DHCP servers on CPE = devices=20 are far larger than self-generated IIDs because reboots and non-volatile = storage=20 or lazy write. Using DHCP provided addresses could provide more efficient compression = with=20 RFC 5444. EUI-64 needs 3 (same OUI in homogenous MANET) or 8 octets. CGA or private IIDs needs 8 octets. Centrally managed addresses could result in less, with 1 octet at a = minimum. This would be a good reason to use the more centralized approach. Teco. Op 30 jul 2010, om 15:52 heeft Dearlove, Christopher (UK) het volgende = geschreven: > Teco >> Question: can we get around a MUST in a standards track RFC? >> I don't think so. >=20 > There is the "don't use that RFC, use another one - or none" > approach. >=20 >> Second question, on first item in charter: do we limit ourself >> to MANET routers that has modified EUI-64 link-locals? >=20 > Definitely not. There are issues with EUI-64. One of these is > privacy/security. If I use a device today, and use the same > device at a different time and in a different place, it's still > clearly identified as the same device. That can be a problem. >=20 > There's a discussion in RFC 3041. That's obsoleted by RFC 4941. > I mention the older version as someone was concered enough to > write draft-dupont-ipv6-rfc3041harmful-05.txt that argued against > RFC 3041 (but never made it to RFC). My point is, there are issues, > and people of goodwill and expertise disagree on the subject. > Probably because of different backgrounds and assumptions. One > size does not fit all. >=20 > --=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 >=20 > 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 >=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 From teco@inf-net.nl Sat Jul 31 06:56:38 2010 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 5B0513A69A6 for ; Sat, 31 Jul 2010 06:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 xrvQFK8B+5vQ for ; Sat, 31 Jul 2010 06:56:36 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 0099D3A69B2 for ; Sat, 31 Jul 2010 06:56:35 -0700 (PDT) Received: by ewy22 with SMTP id 22so1038303ewy.31 for ; Sat, 31 Jul 2010 06:57:00 -0700 (PDT) Received: by 10.213.31.141 with SMTP id y13mr1773104ebc.70.1280584620558; Sat, 31 Jul 2010 06:57:00 -0700 (PDT) Received: from [192.168.2.190] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id z55sm5171794eeh.21.2010.07.31.06.56.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 31 Jul 2010 06:56:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Sat, 31 Jul 2010 15:56:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Templin, Fred L" X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org autoconf@ietf.org" Subject: Re: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64interfaces? 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, 31 Jul 2010 13:56:38 -0000 Fred, Do you mean DHCP relay can be used on a node, that request an address=20 for itself? I think it could work this way: 1) Node queries with link-local to All_DHCP_Relay_Agents_and_Servers. 2a) Node acts as also relay and queries with ULA (site-local) to = All_DHCP_Servers. 2b) If node is provisioned with DHCP server unicast address, it could = use that=20 instead of All_DHCP_Servers. I think this is in line with your RFC 5558. Drawback of 1: it can result in high number of relayed DHCP packets, in = case=20 of many neighbors. Another drawback of 1: there is a timeout delay when there is no relay = or server at one hop. For 2a: the network needs multicast support. Could be SMF. For both 2a and 2b: a temporally used unicast address must be routable. = So this=20 DHCP mechanism can only be used as a second step, moving from the = self-generated=20 address to a centrally managed address. Teco Op 30 jul 2010, om 17:40 heeft Templin, Fred L het volgende geschreven: > Teco, >=20 >> -----Original Message----- >> From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On = Behalf Of Teco Boot >> Sent: Friday, July 30, 2010 4:58 AM >> To: autoconf@ietf.org autoconf@ietf.org >> Subject: [Autoconf] Using DHCPv6 without link-local? Support only = EUI-64interfaces? >>=20 >> RFC3315: >> ... The client >> MUST use a link-local address assigned to the interface for which = it >> is requesting configuration information as the source address in = the >> header of the IP datagram. >>=20 >> Question: can we get around a MUST in a standards track RFC? >> I don't think so. >=20 > If the MANET router only behaves as a client on an internal > link (e.g., a loopback) but behaves as a relay on its MANET > interfaces, then link-locals need not be exposed for DHCPv6 > purposes. There are other reasons why link-locals might need > to be considered for MANETs, but I'm not sure this is one > of them. >=20 > Fred > fred.l.templin@boeing.com >=20 >> The to be posted proposed text for to be RFC5889 would say that if = link-locals are used, there are >> potential problems when using other than modified EUI-64 IIDs, and = therefore must be based on >> modified EUI-64 IIDs. >>=20 >> Second question, on first item in charter: do we limit ourself to = MANET routers that has modified >> EUI-64 link-locals? >> I think: better think twice. >>=20 >> Opinions? >>=20 >> Teco. >>=20 >>=20 >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf