From Chris.Dearlove@baesystems.com Mon Aug 2 01:37:39 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 27C943A6B2F for ; Mon, 2 Aug 2010 01:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.513 X-Spam-Level: X-Spam-Status: No, score=-5.513 tagged_above=-999 required=5 tests=[AWL=-1.514, 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 7bk6FpAYEPmO for ; Mon, 2 Aug 2010 01:36:57 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id A3A093A6B0F for ; Mon, 2 Aug 2010 01:36:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,302,1278284400"; d="scan'208";a="79593867" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 02 Aug 2010 09:35:47 +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 o728ZlqL032745; Mon, 2 Aug 2010 09:35:47 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Aug 2010 09:35:47 +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: Mon, 2 Aug 2010 09:35:45 +0100 Message-ID: In-Reply-To: <9ED0AF66-FB65-485C-B418-E25200A0DE88@inf-net.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64interfaces? thread-index: Acswoj7LFOqjLu+bTimqsxJy7o89kgBemVDQ References: <9ED0AF66-FB65-485C-B418-E25200A0DE88@inf-net.nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" X-OriginalArrivalTime: 02 Aug 2010 08:35:47.0298 (UTC) FILETIME=[B471AC20:01CB321D] 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: Mon, 02 Aug 2010 08:37:39 -0000 > Chris, thanks for sharing your opinion. Actually I mis-read what you wrote, so part of what I wrote I'd want to modify myself. But the privacy/security point I would repeat unchanged. > On RFC 3091 and dupont-ipv6-rfc3041harmful, the recommendations are in RFC 4901. Is that the number you meant? That's titled "Protocol Extensions for Header Compression over MPLS" Without reading it, that's not the title of an RFC that I'd read to discuss the issues of EUI-64 addresses and the issues I referenced. > 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. Please note that I have never said that centralised addresses are unsuitable for anyone. But they are unsuitable for everyone, as issues you don't discuss are important (or more) some people's considerations. -- 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 Mon Aug 2 01:51: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 372AE3A6B1D for ; Mon, 2 Aug 2010 01:51:28 -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 Y-5cYRwvhskD for ; Mon, 2 Aug 2010 01:51:26 -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 C202B3A6B1C for ; Mon, 2 Aug 2010 01:51:25 -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 o728ppXH003869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Aug 2010 10:51:51 +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 o728ppQs003923; Mon, 2 Aug 2010 10:51:51 +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 o728poFH005303; Mon, 2 Aug 2010 10:51:51 +0200 Message-ID: <4C568726.1020307@gmail.com> Date: Mon, 02 Aug 2010 10:51: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: Teco Boot References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org autoconf@ietf.org" Subject: Re: [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: Mon, 02 Aug 2010 08:51:28 -0000 Le 30/07/2010 13:57, Teco Boot a écrit : > 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. I think it wouldn't be good to get around that MUST. I was thinking about the same thing as you say: if RFC5889 forbids link local addresses and new Charter wants DHCP then how could both work? Maybe RFC5889 just discourages the AUTOCONF mechanism from configuring link-local addresses. I.e. let DHCP configure global addresses, even though during the initial DHCP exchanges the link-local addresses are used. (wondering...) > 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. I wouldn't go that far with requiring modified EUI-64 IIDs - why do you think rfc5889 requires use of modified IIDs? Let's see first what is the recommendation of RFC5889-to-be with respect to link-local addresses, and following the WG meeting discussion. > 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. I am trying to see where the modified EUI64 ideas come from, I don't see currently... Alex > > Opinions? > > Teco. > > > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > From alexandru.petrescu@gmail.com Mon Aug 2 02:00: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 5E9283A6B1B for ; Mon, 2 Aug 2010 02:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.102, 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 aQJm0A9MhM40 for ; Mon, 2 Aug 2010 02:00: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 0722A3A6B2F for ; Mon, 2 Aug 2010 02:00: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 o7290ZH4007627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Aug 2010 11:00:35 +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 o7290ZKr006475; Mon, 2 Aug 2010 11:00:35 +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 o7290Y0R008493; Mon, 2 Aug 2010 11:00:35 +0200 Message-ID: <4C568932.2020806@gmail.com> Date: Mon, 02 Aug 2010 11:00:34 +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: <9ED0AF66-FB65-485C-B418-E25200A0DE88@inf-net.nl> In-Reply-To: <9ED0AF66-FB65-485C-B418-E25200A0DE88@inf-net.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: Mon, 02 Aug 2010 09:00:10 -0000 Le 31/07/2010 13:19, Teco Boot a écrit : > 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. Right, me too, I think a good question is whether we agree the DHCP Server sits on a sort of a fixed Gateway to which nodes attach: ---------- ---------- | Fixed | | Fixed | |DHCPServer| |DHCPServer| ---------- ---------- | | | Fixed Network O Or is it: | ---------- o nodes o | Fixed | |DHCPRelay | o o o ---------- | | O o nodes o o o o > Did I catch "un-touched DHCPv6" at the meeting? I think I did hear that too... I think it could be good idea. Alex > 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 to zero. I think duplicate address problems with DHCP > servers on CPE devices are far larger than self-generated IIDs > because reboots and non-volatile storage or lazy write. > > Using DHCP provided addresses could provide more efficient > compression with 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. >> >> 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. >> ******************************************************************** >> > >> >> > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > From teco@inf-net.nl Mon Aug 2 05:03: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 B085F3A6BE2 for ; Mon, 2 Aug 2010 05:03: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=[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 xTvKLx80BrPX for ; Mon, 2 Aug 2010 05:03:17 -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 A5B103A6A07 for ; Mon, 2 Aug 2010 05:03:16 -0700 (PDT) Received: by eyb7 with SMTP id 7so1408444eyb.31 for ; Mon, 02 Aug 2010 05:03:43 -0700 (PDT) Received: by 10.213.32.74 with SMTP id b10mr4091429ebd.13.1280750623658; Mon, 02 Aug 2010 05:03:43 -0700 (PDT) Received: from [172.16.4.99] ([77.61.241.196]) by mx.google.com with ESMTPS id z55sm8712115eeh.15.2010.08.02.05.03.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 05:03:42 -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, 2 Aug 2010 14:03:41 +0200 Content-Transfer-Encoding: 7bit Message-Id: <47C9A85F-0920-4EED-A605-3BEB99C4BA9B@inf-net.nl> References: <9ED0AF66-FB65-485C-B418-E25200A0DE88@inf-net.nl> 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: Mon, 02 Aug 2010 12:03:17 -0000 >> On RFC 3091 and dupont-ipv6-rfc3041harmful, the recommendations are in > RFC 4901. > > Is that the number you meant? That's titled "Protocol Extensions for > Header > Compression over MPLS" Without reading it, that's not the title of an > RFC > that I'd read to discuss the issues of EUI-64 addresses and the issues I > referenced. Sorry, typo. RFC 4941 obsoletes RFC 3041. RFC 4941 adopted recommendations in dupont-ipv6-rfc3041harmful. Teco. From teco@inf-net.nl Mon Aug 2 05:07: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 5302B3A6AB4 for ; Mon, 2 Aug 2010 05:07:08 -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 knOXadC-Oi83 for ; Mon, 2 Aug 2010 05:07:07 -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 2B3FB3A6BFC for ; Mon, 2 Aug 2010 05:07:07 -0700 (PDT) Received: by eyb7 with SMTP id 7so1409424eyb.31 for ; Mon, 02 Aug 2010 05:07:34 -0700 (PDT) Received: by 10.213.31.129 with SMTP id y1mr3819695ebc.21.1280750854165; Mon, 02 Aug 2010 05:07:34 -0700 (PDT) Received: from [172.16.4.99] ([77.61.241.196]) by mx.google.com with ESMTPS id z55sm8716002eeh.21.2010.08.02.05.07.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 05:07:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4C568726.1020307@gmail.com> Date: Mon, 2 Aug 2010 14:07:32 +0200 Content-Transfer-Encoding: 7bit Message-Id: <26410CAF-6B3A-4AAF-B194-1C1F989F4E27@inf-net.nl> References: <4C568726.1020307@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org autoconf@ietf.org" Subject: Re: [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: Mon, 02 Aug 2010 12:07:08 -0000 Op 2 aug 2010, om 10:51 heeft Alexandru Petrescu het volgende geschreven: > I was thinking about the same thing as you say: if RFC5889 forbids link > local addresses and new Charter wants DHCP then how could both work? The document doesn't say "forbid". Teco From alexandru.petrescu@gmail.com Mon Aug 2 05: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 948043A69FB for ; Mon, 2 Aug 2010 05:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.095, 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 5+7KZrtPBZ1m for ; Mon, 2 Aug 2010 05:29:11 -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 76FB83A687D for ; Mon, 2 Aug 2010 05:29:11 -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 o72CTcST032689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Aug 2010 14:29:38 +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 o72CTbeZ015455; Mon, 2 Aug 2010 14:29:38 +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 o72CTbaZ009348; Mon, 2 Aug 2010 14:29:37 +0200 Message-ID: <4C56BA31.6040203@gmail.com> Date: Mon, 02 Aug 2010 14:29:37 +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: <4C568726.1020307@gmail.com> <26410CAF-6B3A-4AAF-B194-1C1F989F4E27@inf-net.nl> In-Reply-To: <26410CAF-6B3A-4AAF-B194-1C1F989F4E27@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] 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: Mon, 02 Aug 2010 12:29:12 -0000 Le 02/08/2010 14:07, Teco Boot a écrit : > Op 2 aug 2010, om 10:51 heeft Alexandru Petrescu het volgende > geschreven: > >> I was thinking about the same thing as you say: if RFC5889 forbids >> link local addresses and new Charter wants DHCP then how could both >> work? > > The document doesn't say "forbid". Right, RFC5889-to-be does not say "forbid". 5889-to-be: > 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. Ok, DHCPv6 could leave with this, thinking that the utility of link-local addresses is only during the initial DHCP exchanges (Solicit-Advertise I believe). 5889-to-be (without WG discussion Maastricht): > 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: > > 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). > > 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. Although DHCP Relay sits on a router, DHCP is not "most of the time" in that a DHCP Relay will use its global address although the Client sent a Solicit using its link-local address - Relay duplicates the packet. > Therefore, autoconfiguration solutions should be encouraged to > primarily focus on configuring IP addresses that are not IPv6 link- > local. This is fine, because DHCP would configure an IP address on Client which is not link-local but global. Of course this DHCPv6-LL analysis should change when we get the more final RFC5889-to-be text. Alex From Chris.Dearlove@baesystems.com Mon Aug 2 05:44: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 801FF3A6898 for ; Mon, 2 Aug 2010 05:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.78 X-Spam-Level: X-Spam-Status: No, score=-6.78 tagged_above=-999 required=5 tests=[AWL=-0.181, 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 W3wGKolC+kV1 for ; Mon, 2 Aug 2010 05:44:51 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 24C993A6878 for ; Mon, 2 Aug 2010 05:44:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,302,1278284400"; d="scan'208";a="79674019" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 02 Aug 2010 13:45:18 +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 o72CjHMH015843; Mon, 2 Aug 2010 13:45:18 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Aug 2010 13:45:18 +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: Mon, 2 Aug 2010 13:45:15 +0100 Message-ID: In-Reply-To: <47C9A85F-0920-4EED-A605-3BEB99C4BA9B@inf-net.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] Using DHCPv6 without link-local? Support onlyEUI-64interfaces? thread-index: AcsyOsWpL1wfPa0iRDGL8nPHeTvJcQABSBMw References: <9ED0AF66-FB65-485C-B418-E25200A0DE88@inf-net.nl> <47C9A85F-0920-4EED-A605-3BEB99C4BA9B@inf-net.nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" X-OriginalArrivalTime: 02 Aug 2010 12:45:18.0019 (UTC) FILETIME=[8FB06930:01CB3240] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Using DHCPv6 without link-local? Support onlyEUI-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: Mon, 02 Aug 2010 12:44:52 -0000 Essentially RFC 3941 is generating random interface IDs. (There are practical issues, but really they are about what should be random working and not e.g. having two nodes use the same PRNG and repeatedly clash.) It is a solution that is not using EUI-64 (except as a part of a seed for the random process) to ensure uniqueness. And all I said was that the EUI-64 solution isn't acceptable in some cases. -- 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: 02 August 2010 13:04 To: Dearlove, Christopher (UK) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Using DHCPv6 without link-local? Support onlyEUI-64interfaces? *** 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 RFC 3091 and dupont-ipv6-rfc3041harmful, the recommendations are in > RFC 4901. > > Is that the number you meant? That's titled "Protocol Extensions for > Header > Compression over MPLS" Without reading it, that's not the title of an > RFC > that I'd read to discuss the issues of EUI-64 addresses and the issues I > referenced. Sorry, typo. RFC 4941 obsoletes RFC 3041. RFC 4941 adopted recommendations in dupont-ipv6-rfc3041harmful. Teco. _______________________________________________ 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 Aug 2 05:46: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 7961D3A69E3 for ; Mon, 2 Aug 2010 05:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.776 X-Spam-Level: X-Spam-Status: No, score=-6.776 tagged_above=-999 required=5 tests=[AWL=-0.177, 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 RDKsxZIUASp0 for ; Mon, 2 Aug 2010 05:46:13 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 260A83A68B2 for ; Mon, 2 Aug 2010 05:46:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,302,1278284400"; d="scan'208";a="79674546" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 02 Aug 2010 13:46:40 +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 o72CkePQ016928; Mon, 2 Aug 2010 13:46:40 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Aug 2010 13:46:39 +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: Mon, 2 Aug 2010 13:46:37 +0100 Message-ID: In-Reply-To: <26410CAF-6B3A-4AAF-B194-1C1F989F4E27@inf-net.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64interfaces? thread-index: AcsyO015zSSYVuIDRLekb8ptW4j8twABUmPw References: <4C568726.1020307@gmail.com> <26410CAF-6B3A-4AAF-B194-1C1F989F4E27@inf-net.nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Alexandru Petrescu" X-OriginalArrivalTime: 02 Aug 2010 12:46:39.0983 (UTC) FILETIME=[C08B1FF0:01CB3240] 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: Mon, 02 Aug 2010 12:46:14 -0000 I recall Dave Thaler tiptoeing through this minefield in an autoconf meeting, maybe Stockholm. He seemed to negotiate it. -- 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: 02 August 2010 13:08 To: Alexandru Petrescu Cc: autoconf@ietf.org autoconf@ietf.org Subject: Re: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64interfaces? *** 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. Op 2 aug 2010, om 10:51 heeft Alexandru Petrescu het volgende geschreven: > I was thinking about the same thing as you say: if RFC5889 forbids link > local addresses and new Charter wants DHCP then how could both work? The document doesn't say "forbid". Teco _______________________________________________ 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 Fred.L.Templin@boeing.com Mon Aug 2 09:39: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 D8BEA3A6ACB for ; Mon, 2 Aug 2010 09:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.006 X-Spam-Level: X-Spam-Status: No, score=-6.006 tagged_above=-999 required=5 tests=[AWL=0.593, 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 gk-Tc3KHOIGi for ; Mon, 2 Aug 2010 09:39:04 -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 990A83A6A33 for ; Mon, 2 Aug 2010 09:39:04 -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 o72GdKfN017993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Aug 2010 09:39:25 -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 o72GdK7v021590; Mon, 2 Aug 2010 11:39:20 -0500 (CDT) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o72GdJVP021557 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 2 Aug 2010 11:39:20 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Mon, 2 Aug 2010 09:39:16 -0700 From: "Templin, Fred L" To: Teco Boot Date: Mon, 2 Aug 2010 09:39:17 -0700 Thread-Topic: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64interfaces? Thread-Index: AcswuEHaEjA36XEhSW23H225Tf14MQBp8MgQ 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 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: Mon, 02 Aug 2010 16:39:06 -0000 Hi Teco, > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: Saturday, July 31, 2010 6:57 AM > To: Templin, Fred L > Cc: autoconf@ietf.org autoconf@ietf.org > Subject: Re: [Autoconf] Using DHCPv6 without link-local? Support only EUI= -64interfaces? >=20 > Fred, >=20 > Do you mean DHCP relay can be used on a node, that request an address > for itself? I mean that the client function on a node sends a DHCP request that is intercepted by a relay function on that same node. The relay forwards the DHCP request to a DHCP server, which then sends a reply via the same relay. The relay then forwards the reply to the client on the same node, and the client does the appropriate thing. > 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 > instead of All_DHCP_Servers. > I think this is in line with your RFC 5558. >=20 > Drawback of 1: it can result in high number of relayed DHCP packets, in c= ase > of many neighbors. > Another drawback of 1: there is a timeout delay when there is no relay or= server > at one hop. Right, but that's not the scenario I was describing. > For 2a: the network needs multicast support. Could be SMF. Ack. > For both 2a and 2b: a temporally used unicast address must be routable. S= o this > DHCP mechanism can only be used as a second step, moving from the self-ge= nerated > address to a centrally managed address. That's what VET is essentially saying, yes. Thanks - Fred fred.l.templin@boeing.com > Teco >=20 >=20 >=20 >=20 > Op 30 jul 2010, om 17:40 heeft Templin, Fred L het volgende geschreven: >=20 > > Teco, > > > >> -----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? > >> > >> 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. > > > > 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 > > > >> The to be posted proposed text for to be RFC5889 would say that if lin= k-locals are used, there are > >> potential problems when using other than modified EUI-64 IIDs, and the= refore must be based on > >> modified EUI-64 IIDs. > >> > >> Second question, on first item in charter: do we limit ourself to MANE= T routers that has modified > >> EUI-64 link-locals? > >> I think: better think twice. > >> > >> Opinions? > >> > >> Teco. > >> > >> > >> _______________________________________________ > >> Autoconf mailing list > >> Autoconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/autoconf From ulrich@herberg.name Mon Aug 2 09:54: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 F3E3D3A6902 for ; Mon, 2 Aug 2010 09:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.054 X-Spam-Level: X-Spam-Status: No, score=-1.054 tagged_above=-999 required=5 tests=[AWL=0.923, 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 8pHzE7idmk6l for ; Mon, 2 Aug 2010 09:54:50 -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 C32283A6965 for ; Mon, 2 Aug 2010 09:54:49 -0700 (PDT) Received: by bwz7 with SMTP id 7so2314472bwz.31 for ; Mon, 02 Aug 2010 09:55:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.101.72 with SMTP id b8mr4192650bko.192.1280768116801; Mon, 02 Aug 2010 09:55:16 -0700 (PDT) Received: by 10.204.163.5 with HTTP; Mon, 2 Aug 2010 09:55:16 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 Aug 2010 18:55:16 +0200 Message-ID: From: Ulrich Herberg To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Mon, 02 Aug 2010 16:54:51 -0000 Teco, On Sat, Jul 31, 2010 at 3:56 PM, Teco Boot wrote: > Fred, > > Do you mean DHCP relay can be used on a node, that request an address > for itself? I have tried that a while ago. It works with some limitations (see below). > > 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. Do you mean that a node is DHCP client and relay in the same time? That is not possible according to RFC3315, which says (i) in section 15.13 "clients MUST discard any received Relay-forward messages" and (ii) section 15.3 "servers and relay agents MUST discard any received Advertise messages". Also, the relay would need to have a direct unicast connection to the central node or use other relaying mechanisms such as SMF (as you mentioned below), because multiple relaying is not really feasible in DHCPv6 itself: Relaying uses encapsulation, so packets would be encapsulated at every hop, quickly increasing overhead. And I also don't think that DHCP relaying allows duplicate packet detection. > 2b) If node is provisioned with DHCP server unicast address, it could use= that > =A0 =A0instead of All_DHCP_Servers. Sure, that is possible if a unicast routing protocol is used. > I think this is in line with your RFC 5558. > > Drawback of 1: it can result in high number of relayed DHCP packets, in c= ase > of many neighbors. True. > Another drawback of 1: there is a timeout delay when there is no relay or= server > at one hop. But I guess this timeout can be set dynamically? > > For 2a: the network needs multicast support. Could be SMF. Yes, that could be a possibility. > > For both 2a and 2b: a temporally used unicast address must be routable. S= o this > DHCP mechanism can only be used as a second step, moving from the self-ge= nerated > address to a centrally managed address. Yes, that seems possible (but I have to re-read the DHCPv6 RFC after my vacations ;-) Ulrich > > Teco > > > > > Op 30 jul 2010, om 17:40 heeft Templin, Fred L het volgende geschreven: > >> Teco, >> >>> -----Original Message----- >>> From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On B= ehalf 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-6= 4interfaces? >>> >>> RFC3315: >>> =A0 ... =A0 =A0 The client >>> =A0 MUST use a link-local address assigned to the interface for which i= t >>> =A0 is requesting configuration information as the source address in th= e >>> =A0 header of the IP datagram. >>> >>> 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 >> >>> 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 ther= efore 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. >>> >>> >>> _______________________________________________ >>> 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 Fred.L.Templin@boeing.com Mon Aug 2 10:30: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 DFE7C3A69CC for ; Mon, 2 Aug 2010 10:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.554, 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 6c7T+29ielHh for ; Mon, 2 Aug 2010 10:30:44 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 6302C3A6AB6 for ; Mon, 2 Aug 2010 10:30:44 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o72HV6mJ025677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Aug 2010 10:31:08 -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 o72HV6rm021119; Mon, 2 Aug 2010 12:31:06 -0500 (CDT) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o72HV5ox021084 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 2 Aug 2010 12:31:06 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Mon, 2 Aug 2010 10:31:06 -0700 From: "Templin, Fred L" To: Ulrich Herberg , Teco Boot Date: Mon, 2 Aug 2010 10:31:05 -0700 Thread-Topic: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64interfaces? Thread-Index: AcsyY5uQdm7XeRDYTlWNLgzUQ5ICgQAAtIeQ 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Mon, 02 Aug 2010 17:30:46 -0000 Ulrich, > -----Original Message----- > From: Ulrich Herberg [mailto:ulrich@herberg.name] > Sent: Monday, August 02, 2010 9:55 AM > To: Teco Boot > Cc: Templin, Fred L; autoconf@ietf.org autoconf@ietf.org > Subject: Re: [Autoconf] Using DHCPv6 without link-local? Support only EUI= -64interfaces? >=20 > Teco, >=20 > On Sat, Jul 31, 2010 at 3:56 PM, Teco Boot wrote: > > Fred, > > > > Do you mean DHCP relay can be used on a node, that request an address > > for itself? >=20 > I have tried that a while ago. It works with some limitations (see below)= . >=20 > > > > 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_DH= CP_Servers. >=20 > Do you mean that a node is DHCP client and relay in the same time? > That is not possible according to RFC3315, which says (i) in section > 15.13 "clients MUST discard any received Relay-forward messages" The client function would never see a Relay-forward, because that is generated by the relay function and sent to either the unicast address of a server or All-DHCP-Servers multicast. Maybe you meant section 15.14 "Clients and servers MUST discard any received Relay-reply messages"? But, it is the node's relay function (and not the client function) that gets the Relay-reply so this is not in violation of the spec. > and > (ii) section 15.3 "servers and relay agents MUST discard any received > Advertise messages". The node's client function (and not the relay function) is the one that gets the Advertise message when 4-message exchange is used; the relay function sees only the Relay-reply and then forwards the Advertise on to the client function. Also, in 2-message exchange there is no Advertise message. Fred fred.l.templin@boeing.com > Also, the relay would need to have a direct unicast connection to the > central node or use other relaying mechanisms such as SMF (as you > mentioned below), because multiple relaying is not really feasible in > DHCPv6 itself: Relaying uses encapsulation, so packets would be > encapsulated at every hop, quickly increasing overhead. And I also > don't think that DHCP relaying allows duplicate packet detection. >=20 > > 2b) If node is provisioned with DHCP server unicast address, it could u= se that > > =A0 =A0instead of All_DHCP_Servers. >=20 > Sure, that is possible if a unicast routing protocol is used. >=20 > > 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 > > of many neighbors. >=20 > True. >=20 > > Another drawback of 1: there is a timeout delay when there is no relay = or server > > at one hop. >=20 > But I guess this timeout can be set dynamically? >=20 > > > > For 2a: the network needs multicast support. Could be SMF. >=20 > Yes, that could be a possibility. >=20 >=20 > > > > For both 2a and 2b: a temporally used unicast address must be routable.= So this > > DHCP mechanism can only be used as a second step, moving from the self-= generated > > address to a centrally managed address. >=20 > Yes, that seems possible (but I have to re-read the DHCPv6 RFC after > my vacations ;-) >=20 > Ulrich >=20 > > > > Teco > > > > > > > > > > Op 30 jul 2010, om 17:40 heeft Templin, Fred L het volgende geschreven: > > > >> Teco, > >> > >>> -----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? > >>> > >>> RFC3315: > >>> =A0 ... =A0 =A0 The client > >>> =A0 MUST use a link-local address assigned to the interface for which= it > >>> =A0 is requesting configuration information as the source address in = the > >>> =A0 header of the IP datagram. > >>> > >>> 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 > >> > >>> The to be posted proposed text for to be RFC5889 would say that if li= nk-locals are used, there > are > >>> potential problems when using other than modified EUI-64 IIDs, and th= erefore must be based on > >>> modified EUI-64 IIDs. > >>> > >>> Second question, on first item in charter: do we limit ourself to MAN= ET routers that has modified > >>> EUI-64 link-locals? > >>> I think: better think twice. > >>> > >>> Opinions? > >>> > >>> Teco. > >>> > >>> > >>> _______________________________________________ > >>> 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 ulrich@herberg.name Mon Aug 2 10:44:11 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 4D86D3A67D4 for ; Mon, 2 Aug 2010 10:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.094 X-Spam-Level: X-Spam-Status: No, score=-1.094 tagged_above=-999 required=5 tests=[AWL=0.883, 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 f-D3WsClLkJl for ; Mon, 2 Aug 2010 10:44:10 -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 219A13A6A33 for ; Mon, 2 Aug 2010 10:44:09 -0700 (PDT) Received: by bwz7 with SMTP id 7so2337253bwz.31 for ; Mon, 02 Aug 2010 10:44:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.84.37 with SMTP id h37mr4268711bkl.201.1280771076766; Mon, 02 Aug 2010 10:44:36 -0700 (PDT) Received: by 10.204.163.5 with HTTP; Mon, 2 Aug 2010 10:44:36 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 Aug 2010 19:44:36 +0200 Message-ID: From: Ulrich Herberg To: "Templin, Fred L" Content-Type: text/plain; charset=ISO-8859-1 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: Mon, 02 Aug 2010 17:44:11 -0000 Fred, On Mon, Aug 2, 2010 at 7:31 PM, Templin, Fred L wrote: >[...] >> >> I have tried that a while ago. It works with some limitations (see below). >> >> > >> > 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. >> >> Do you mean that a node is DHCP client and relay in the same time? >> That is not possible according to RFC3315, which says (i) in section >> 15.13 "clients MUST discard any received Relay-forward messages" > > The client function would never see a Relay-forward, because > that is generated by the relay function and sent to either the > unicast address of a server or All-DHCP-Servers multicast. Maybe > you meant section 15.14 "Clients and servers MUST discard any > received Relay-reply messages"? But, it is the node's relay > function (and not the client function) that gets the > Relay-reply so this is not in violation of the spec. Thanks for that clarification. If this demultiplexing is possible, than it should indeed not be a problem. Is that explicitly mentioned in the RFC? > >> and >> (ii) section 15.3 "servers and relay agents MUST discard any received >> Advertise messages". > > The node's client function (and not the relay function) is the > one that gets the Advertise message when 4-message exchange is > used; the relay function sees only the Relay-reply and then > forwards the Advertise on to the client function. Same comment as above. > Also, in > 2-message exchange there is no Advertise message. > > Fred > fred.l.templin@boeing.com Ulrich >[..] From teco@inf-net.nl Mon Aug 2 10:56: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 CF1A53A6B0F for ; Mon, 2 Aug 2010 10:56: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=[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 H6fl8kxFri08 for ; Mon, 2 Aug 2010 10:56: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 8DB4A3A6B9D for ; Mon, 2 Aug 2010 10:56:14 -0700 (PDT) Received: by ewy22 with SMTP id 22so1566589ewy.31 for ; Mon, 02 Aug 2010 10:56:42 -0700 (PDT) Received: by 10.213.35.6 with SMTP id n6mr4481482ebd.0.1280771802231; Mon, 02 Aug 2010 10:56:42 -0700 (PDT) Received: from [172.16.4.99] ([77.61.241.196]) by mx.google.com with ESMTPS id a48sm9227157eei.7.2010.08.02.10.56.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 10:56:41 -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, 2 Aug 2010 19:56:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ulrich Herberg 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: Mon, 02 Aug 2010 17:56:16 -0000 Op 2 aug 2010, om 18:55 heeft Ulrich Herberg het volgende geschreven: > Teco, >=20 > On Sat, Jul 31, 2010 at 3:56 PM, Teco Boot wrote: >> Fred, >>=20 >> Do you mean DHCP relay can be used on a node, that request an address >> for itself? >=20 > I have tried that a while ago. It works with some limitations (see = below). >=20 >>=20 >> 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. >=20 > Do you mean that a node is DHCP client and relay in the same time? > That is not possible according to RFC3315, which says (i) in section > 15.13 "clients MUST discard any received Relay-forward messages" and > (ii) section 15.3 "servers and relay agents MUST discard any received > Advertise messages". I don't think there is such limitation. A node that combines client and relay would not send out a packet that = does not conform to the spec. > Also, the relay would need to have a direct unicast connection to the > central node or use other relaying mechanisms such as SMF (as you > mentioned below), because multiple relaying is not really feasible in > DHCPv6 itself: Relaying uses encapsulation, so packets would be > encapsulated at every hop, quickly increasing overhead. Yes, relaying and encap on every hop is a bad idea, I think. But we don't have a standard track multicast protocol for MANETs. We also don't have a protocol for service discovery, for learning the DHCP server address. This makes our work experimental. > And I also > don't think that DHCP relaying allows duplicate packet detection. Why not? SMF hashing should work. Each packet has a random transaction ID. Or include a SMF-DPD header option. >=20 >> 2b) If node is provisioned with DHCP server unicast address, it could = use that >> instead of All_DHCP_Servers. >=20 > Sure, that is possible if a unicast routing protocol is used. >=20 >> I think this is in line with your RFC 5558. >>=20 >> Drawback of 1: it can result in high number of relayed DHCP packets, = in case >> of many neighbors. >=20 > True. >=20 >> Another drawback of 1: there is a timeout delay when there is no = relay or server >> at one hop. >=20 > But I guess this timeout can be set dynamically? When 1 is used as a first try, looking for a DHCP-server at one hop, the = node=20 should wait some time for a response. If no response arrives, it could = go to step 2. The timeout would be a configured parameter, I think. Maybe it is better to skip such a mechanism. Needs more thoughts. >> For 2a: the network needs multicast support. Could be SMF. >=20 > Yes, that could be a possibility. >=20 >=20 >>=20 >> For both 2a and 2b: a temporally used unicast address must be = routable. So this >> DHCP mechanism can only be used as a second step, moving from the = self-generated >> address to a centrally managed address. >=20 > Yes, that seems possible (but I have to re-read the DHCPv6 RFC after > my vacations ;-) Not _during_ your vacation ?? :-)) Teco From alexandru.petrescu@gmail.com Mon Aug 2 12:37: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 2DF0E3A6866 for ; Mon, 2 Aug 2010 12:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.650, 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 hJLMX6d9Z1aT for ; Mon, 2 Aug 2010 12:37:37 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 626533A6BA1 for ; Mon, 2 Aug 2010 12:37:35 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 09CBB94011D for ; Mon, 2 Aug 2010 21:37:58 +0200 (CEST) Message-ID: <4C571E93.7050007@gmail.com> Date: Mon, 02 Aug 2010 21:37:55 +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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100802-1, 02/08/2010), Outbound message X-Antivirus-Status: Clean 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: Mon, 02 Aug 2010 19:37:38 -0000 Le 02/08/2010 18:55, Ulrich Herberg a écrit : > Teco, > > On Sat, Jul 31, 2010 at 3:56 PM, Teco Boot wrote: >> Fred, >> >> Do you mean DHCP relay can be used on a node, that request an >> address for itself? > > I have tried that a while ago. It works with some limitations (see > below). > >> >> 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. > > Do you mean that a node is DHCP client and relay in the same time? > That is not possible according to RFC3315, which says (i) in section > 15.13 "clients MUST discard any received Relay-forward messages" and > (ii) section 15.3 "servers and relay agents MUST discard any > received Advertise messages". Ah! This is seem to contradict something in MEXT context where draft-ietf-mext-nemo-pd-05 proposes "This relay agent function is co-located in the MR with the DHCPv6 client function (see Figure 2)." > Also, the relay would need to have a direct unicast connection to the > central node or use other relaying mechanisms such as SMF (as you > mentioned below), because multiple relaying is not really feasible in > DHCPv6 itself: Relaying uses encapsulation, so packets would be ^^^^^^^^^^^^^^^^ Clarification: yes, relaying implies encapsulation when Relay relays to another Relay, but when Relay to Server - it's non-encapsualted. > encapsulated at every hop, quickly increasing overhead. And I also > don't think that DHCP relaying allows duplicate packet detection. Duplicate packet detection? What is it for? Alex >> 2b) If node is provisioned with DHCP server unicast address, it >> could use that instead of All_DHCP_Servers. > > Sure, that is possible if a unicast routing protocol is used. > >> 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 of many neighbors. > > True. > >> Another drawback of 1: there is a timeout delay when there is no >> relay or server at one hop. > > But I guess this timeout can be set dynamically? > >> >> For 2a: the network needs multicast support. Could be SMF. > > Yes, that could be a possibility. > > >> >> For both 2a and 2b: a temporally used unicast address must be >> routable. So this DHCP mechanism can only be used as a second >> step, moving from the self-generated address to a centrally >> managed address. > > Yes, that seems possible (but I have to re-read the DHCPv6 RFC after > my vacations ;-) > > Ulrich > >> >> Teco >> >> >> >> >> Op 30 jul 2010, om 17:40 heeft Templin, Fred L het volgende >> geschreven: >> >>> Teco, >>> >>>> -----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? >>>> >>>> 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. >>> >>> 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 >>> >>>> 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. >>>> >>>> >>>> _______________________________________________ Autoconf >>>> mailing list Autoconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/autoconf >> >> _______________________________________________ Autoconf mailing >> list Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > From ulrich@herberg.name Mon Aug 2 14:46:23 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 F245D3A69DA for ; Mon, 2 Aug 2010 14:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[AWL=0.846, 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 8faTR2Tosk8k for ; Mon, 2 Aug 2010 14:46:22 -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 888D73A686B for ; Mon, 2 Aug 2010 14:46:21 -0700 (PDT) Received: by bwz7 with SMTP id 7so2441974bwz.31 for ; Mon, 02 Aug 2010 14:46:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.54.72 with SMTP id p8mr4515801bkg.163.1280785607479; Mon, 02 Aug 2010 14:46:47 -0700 (PDT) Received: by 10.204.163.5 with HTTP; Mon, 2 Aug 2010 14:46:47 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 Aug 2010 23:46:47 +0200 Message-ID: From: Ulrich Herberg To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Mon, 02 Aug 2010 21:46:23 -0000 Teco, On Mon, Aug 2, 2010 at 7:56 PM, Teco Boot wrote: [..] >>> >>> 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_DH= CP_Servers. >> >> Do you mean that a node is DHCP client and relay in the same time? >> That is not possible according to RFC3315, which says (i) in section >> 15.13 "clients MUST discard any received Relay-forward messages" and >> (ii) section 15.3 "servers and relay agents MUST discard any received >> Advertise messages". > > I don't think there is such limitation. > A node that combines client and relay would not send out a packet that do= es > not conform to the spec. Fred pointed that out. I wonder whether that demultiplexing is clearly pointed out in the DHCPv6 RFC. But well, too late to change it ;-) I assume that major DHCPv6 implementations do not implement that demultiplexing (they'd need to share the UDP port, demultiplex messsages etc.) (-- I know, that's not so much a problem of the standardization process.. just wondering here) >> Also, the relay would need to have a direct unicast connection to the >> central node or use other relaying mechanisms such as SMF (as you >> mentioned below), because multiple relaying is not really feasible in >> DHCPv6 itself: Relaying uses encapsulation, so packets would be >> encapsulated at every hop, quickly increasing overhead. > > Yes, relaying and encap on every hop is a bad idea, I think. > But we don't have a standard track multicast protocol for MANETs. > We also don't have a protocol for service discovery, for learning the > DHCP server address. > This makes our work experimental. Indeed. It would make life easier to have such protocols as RFCs already :-) With SMF, we have at least a protocol which is not so far from being published as RFC. > > >> =A0 =A0And I also >> don't think that DHCP relaying allows duplicate packet detection. > > Why not? > SMF hashing should work. Each packet has a random transaction ID. > Or include a SMF-DPD header option. True. But that is defined in SMF, not in DHCPv6 relaying. >>> 2b) If node is provisioned with DHCP server unicast address, it could u= se that >>> =A0 =A0instead of All_DHCP_Servers. >> >> Sure, that is possible if a unicast routing protocol is used. >> >>> 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 >>> of many neighbors. >> >> True. >> >>> Another drawback of 1: there is a timeout delay when there is no relay = or server >>> at one hop. >> >> But I guess this timeout can be set dynamically? > > When 1 is used as a first try, looking for a DHCP-server at one hop, the = node > should wait some time for a response. If no response arrives, it could go= to step 2. > The timeout would be a configured parameter, I think. > Maybe it is better to skip such a mechanism. Needs more thoughts. Yes, I also have to think more about it. >>> For 2a: the network needs multicast support. Could be SMF. >> >> Yes, that could be a possibility. >> >> >>> >>> For both 2a and 2b: a temporally used unicast address must be routable.= So this >>> DHCP mechanism can only be used as a second step, moving from the self-= generated >>> address to a centrally managed address. >> >> Yes, that seems possible (but I have to re-read the DHCPv6 RFC after >> my vacations ;-) > > Not _during_ your vacation ?? =A0:-)) hehe, well, my boss would like that ;-) Ulrich From ryuji.wakikawa@gmail.com Mon Aug 2 17:13: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 AE2933A6A11 for ; Mon, 2 Aug 2010 17:13:42 -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 UWkRICRRU5U5 for ; Mon, 2 Aug 2010 17:13:41 -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 51C013A69E5 for ; Mon, 2 Aug 2010 17:13:41 -0700 (PDT) Received: by pzk6 with SMTP id 6so1728751pzk.31 for ; Mon, 02 Aug 2010 17:14:09 -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 :references:to:x-mailer; bh=Ukotrwstr8h3w0a7f9LhmK3Iv4wErV643bdDs32dyBc=; b=jyIsHiFMrZ501XPjBmKS0aRygfXp9xDnnlMj1ReWX6+M7ZOf0YNtHjjO0eZOjA5BrC S8X7olldvngIgdhsIq21E9ykGOwf9NRA+RU01YXopKBWgTHdJGrfozQ9vQSzqyBt9a3I zm1pjrdTeB3cs/7njcm1tv0Qxc4A9AhmLX4rc= 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:references:to:x-mailer; b=or/TYjDgWme/2EYK+zROFr8vG5uw/nkgD2k33QfZQ+8yLhiSHbNIFWgWbncZYYMhTs X/jx/LsTg9FqipxcFllY1j4UcrbXLlj4K8Po8ItzMkgV3gHmcl7WU93UGvZA0fM3vZRu o01CaWAwUYrXFP+rRgqGidIxiULQoit30WN1E= Received: by 10.114.103.7 with SMTP id a7mr8165102wac.184.1280794449290; Mon, 02 Aug 2010 17:14:09 -0700 (PDT) Received: from [192.168.18.100] (adsl-99-49-9-50.dsl.pltn13.sbcglobal.net [99.49.9.50]) by mx.google.com with ESMTPS id 33sm12402535wad.6.2010.08.02.17.14.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 17:14:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Ryuji Wakikawa Date: Mon, 2 Aug 2010 17:14:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C528979.7010006@oracle.com> To: "autoconf@ietf.org autoconf@ietf.org" X-Mailer: Apple Mail (2.1081) Cc: Autoconf Chairs , Ralph Droms Subject: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: 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: Tue, 03 Aug 2010 00:13:42 -0000 Hello all, At the IETF78 meeting, we had the rough consensus to adapt=20 the Erik's modification for RFC5889 in the room.=20 To confirm our consensus on the list, we ask the WG consensus call=20 for adaption of Erik's modification for RFC5889. The detailed modifications can be found at the attached email below. = Thanks Erik. Please vote for your opinion before "Aug 9th 12:00PM (PST)".=20 If you have any objections, please give us clear reason and propose your = text. thanks in advance, Thomas, ryuji Begin forwarded message: > From: Erik Nordmark > Date: 2010/07/30 01:12:41GMT-07:00 > To: autoconf@ietf.org > Subject: Re: [Autoconf] Forgot one [Was: RFC 5889 >=20 >=20 > Please double-check this, but I think it has all the list of changes = that Jari said verbally. >=20 > Erik >=20 > ---- >=20 > Change the title > FROM > IP Addressing Model in Ad Hoc Networks > TO > A Router Addressing Model in Ad Hoc Networks >=20 > 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]). >=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; 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 > 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. >=20 > --- > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From henning.rogge@fkie.fraunhofer.de Mon Aug 2 22:25: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 3B9E13A685C for ; Mon, 2 Aug 2010 22:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[AWL=-2.888, 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 pzoM9k1PFqBC for ; Mon, 2 Aug 2010 22:25:12 -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 761F63A67FC for ; Mon, 2 Aug 2010 22:25:04 -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 1OgA0I-0006bg-5j; Tue, 03 Aug 2010 07:25:30 +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 1OgA0H-0003GX-SL; Tue, 03 Aug 2010 07:25:29 +0200 From: Henning Rogge To: autoconf@ietf.org Date: Tue, 3 Aug 2010 07:25:07 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-24-generic; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3590206.I7vC8hIQRq"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201008030725.23669.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11487/Tue Aug 3 04:16:15 2010) by mailguard.fgan.de X-Scan-Signature: b1467e4067045b82e2ed93aca61069d0 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: Tue, 03 Aug 2010 05:25:19 -0000 --nextPart3590206.I7vC8hIQRq Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, is there a reason why we cannot place an DHCPv6-relay on every node for its= =20 neighbors ? Each node requesting an address/prefix will send out an IP=20 datagram with an anycast destination an a linklocal source, which will be=20 forwarded by its neighbors (with a unicast) to the DHCPv6-server. After a node has it's address it switch from DHCP-client to DHCP-relay mode= ,=20 to allow other nodes to connect through this node to the server. 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 --nextPart3590206.I7vC8hIQRq 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) iEYEABECAAYFAkxXqDQACgkQRIfGfFXsz+CQAQCgqSk38n8ToR5TcALoESvxxe8w By8Anjw6GmIesZ/DeraPmu94WFZnAZNi =EhCP -----END PGP SIGNATURE----- --nextPart3590206.I7vC8hIQRq-- From ulrich@herberg.name Tue Aug 3 01:28: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 641BA3A690C for ; Tue, 3 Aug 2010 01:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.042 X-Spam-Level: X-Spam-Status: No, score=0.042 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_40=-0.185, 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 a8-ra1NKUm5U for ; Tue, 3 Aug 2010 01:28:37 -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 E622C3A686C for ; Tue, 3 Aug 2010 01:28:36 -0700 (PDT) Received: by bwz7 with SMTP id 7so2630481bwz.31 for ; Tue, 03 Aug 2010 01:29:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.150.92 with SMTP id x28mr4966517bkv.132.1280824139788; Tue, 03 Aug 2010 01:28:59 -0700 (PDT) Received: by 10.204.163.5 with HTTP; Tue, 3 Aug 2010 01:28:59 -0700 (PDT) In-Reply-To: <201008030725.23669.henning.rogge@fkie.fraunhofer.de> References: <201008030725.23669.henning.rogge@fkie.fraunhofer.de> Date: Tue, 3 Aug 2010 10:28:59 +0200 Message-ID: From: Ulrich Herberg To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Tue, 03 Aug 2010 08:28:38 -0000 Hi Henning, On Tue, Aug 3, 2010 at 7:25 AM, Henning Rogge wrote: > Hello, > > is there a reason why we cannot place an DHCPv6-relay on every node for i= ts > neighbors ? Each node requesting an address/prefix will send out an IP > datagram with an anycast destination an a linklocal source, which will be > forwarded by its neighbors (with a unicast) to the DHCPv6-server. Sure, that works. DHCP clients would typically send their messages to the All_DHCP_Relay_Agents_and_Servers multicast address. However, that necessitates the use of a unicast routing protocol, because the relay has to have a route towards the DHCP server. The question is, do we want to depend on that? I think we should also have a running autoconf mechanism in cases when there is no unicast routing protocol in place. Ulrich > After a node has it's address it switch from DHCP-client to DHCP-relay mo= de, > to allow other nodes to connect through this node to the server. > > Henning Rogge > > -- > 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, =A0 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 > From jari.arkko@piuha.net Tue Aug 3 01:36: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 A1E5C3A68FC for ; Tue, 3 Aug 2010 01:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, 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 VL8X6zMgcG31 for ; Tue, 3 Aug 2010 01:36:05 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id AA40C3A686B for ; Tue, 3 Aug 2010 01:36:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E8A312CCC0; Tue, 3 Aug 2010 11:36:32 +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 GqyXa4mdhCJt; Tue, 3 Aug 2010 11:36:32 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 93E1F2CC62; Tue, 3 Aug 2010 11:36:32 +0300 (EEST) Message-ID: <4C57D510.7090404@piuha.net> Date: Tue, 03 Aug 2010 11:36:32 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Ryuji Wakikawa References: <4C528979.7010006@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "autoconf@ietf.org autoconf@ietf.org" , Autoconf Chairs , Ralph Droms Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: 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: Tue, 03 Aug 2010 08:36:06 -0000 These changes look good to me. Thanks for collecting the right text, Erik. Jari From henning.rogge@fkie.fraunhofer.de Tue Aug 3 01:36:44 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 CB71E3A68C7 for ; Tue, 3 Aug 2010 01:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.343 X-Spam-Level: X-Spam-Status: No, score=-1.343 tagged_above=-999 required=5 tests=[AWL=-2.599, 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 Mi6HQWy4UR4Y for ; Tue, 3 Aug 2010 01:36:43 -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 A0D1E3A686B for ; Tue, 3 Aug 2010 01:36:42 -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 1OgCzl-0007Xq-3e; Tue, 03 Aug 2010 10:37:09 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fgan.de with esmtp (Exim 4.69) (envelope-from ) id 1OgCzk-00044q-Rr; Tue, 03 Aug 2010 10:37:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Aug 2010 10:37:08 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000A_01CB32F7.D1FE83A0" Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64interfaces? Thread-Index: Acsy5fT9nFHJ0l6pRT6swicgKc4GjAAALoyA References: <201008030725.23669.henning.rogge@fkie.fraunhofer.de> From: "Rogge Henning" To: "Ulrich Herberg" X-Virus-Scanned: yes (ClamAV 0.96.1/11487/Tue Aug 3 04:16:15 2010) by mailguard.fgan.de X-Scan-Signature: 3323e5da4f65bad0ae85b235b9833247 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: Tue, 03 Aug 2010 08:36:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000A_01CB32F7.D1FE83A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Von: Ulrich Herberg [mailto:ulrich@herberg.name]=20 >=20 > Hi Henning, >=20 > Sure, that works. DHCP clients would typically send their=20 > messages to the All_DHCP_Relay_Agents_and_Servers multicast=20 > address. However, that necessitates the use of a unicast=20 > routing protocol, I would say we could live with the dependency of a unicast route to the DHCPv6 server on all addresses which have been sucessfully configured by this server. > because the relay has to have a route=20 > towards the DHCP server. The question is, do we want to=20 > depend on that? I think we should also have a running=20 > autoconf mechanism in cases when there is no unicast routing=20 > protocol in place. Are you sure DHCPv6 is a good sollution for this networks ? What kind of mesh networks use no unicast capable routing protocol ? Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr=20 Kommunikation, Informationsverarbeitung und Ergonomie FKIE=20 Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg,=20 Germany Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685=20 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0=20 ------=_NextPart_000_000A_01CB32F7.D1FE83A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYAzCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQuMIIDFqADAgECAgIBDDANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDcxMjA1 MTUxODU4WhcNMTkwNjMwMjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2Zl cjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFJvb3QgQ0EgMjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMM9HslljVuIN/c+ wSG2VN6wOlcbGhzumAh0AVpvtd82VytERc7zRhNldpWYVMeohRVuEqQX6AvhIacxPSnd/6PWT9K0 if1jStqrU+9ZBbRP4jsqkZnAy2VXgaMwk5AOyb39FTIyCKRIfFYF8rs2ieJIwm9LkgwlRb6tPtTH Ae2xyBK0MAhup29/eiCnu7TlNYBULBmP2UvAHatD+GEUlPuwHV23kexiwJHRXt2nC7MtH2Y5GDyu BBTl0n022bLNpxOwzEWdVgRRcTM2XC9dUROeT0iQDpdaS3DbuXnZodaUyJLQpftgvy2tnnEAF4bA /UhmnRRMBU5M0XFEC9B6D7ECAwEAAaOB2TCB1jAfBgNVHSMEGDAWgBQxw3kbuvVT1xfgiXotF2wK syudMzAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFC9FQh4xBYDVcNj4HVfLW3rVPZz3MBIGA1Ud EwEB/wQIMAYBAf8CAQEwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2Nn aS1iaW4vc2VydmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vl cj1EVF9ST09UX0NBXzIwDQYJKoZIhvcNAQEFBQADggEBABq3THo85d3CY7LehiVORWJM9PKPX13X 5Y3ODtf1lOGLkzE2p5oj52fhUsFaGNaZ4YBkOA9KNTNdZnoo3Dh/N3LNUnVuEI5sfYz3Ket3wrkZ BdS3PWG66AUS1FBiU+8iVGL8TQHDXtQNg3RpUdU8nqzbpCt8bYSW03FNz9UtcaOSxD9Vz5s9I3cH V+nIzh2XtjP7kZdglg/39t5vJZASqxlH1UQjrsGSNSi/KkNeD+oHXdJE0IWC4xK8R+osrfjwQVJ9 Nroin3qgMu9LvPk6B7Ypxn04XzVVfjjyP3yz7i1uIXhfuRPP795lgMgl9WYtVEqtztkuDjDPgDOn ixly6kEwggTGMIIDrqADAgECAgphHTMZAAAAAAADMA0GCSqGSIb3DQEBBQUAMGcxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQ S0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIgUm9vdCBDQSAyMDA3MB4XDTA3MTIxMjE0NDkzNVoXDTE5 MDYzMDIzNTk1OVowZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsT GEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDCdBBRy3XRgfErNZ1agjqvkq7NAvyu yPsgdw7/aBIVkEmnZ3xoJF/6DiYaZT5KngkK04dPMxGKa1WiS02lT1Yb48d4efijC95VRmSH2owP PU6JYS8JPppdvVW6leZy4Ta0sHWctee2+nQruSX38b6TucFwp/eWf0y8i3XrsYFR7PzJ4XM75gWw UUvjsPVKCp/j2b8mJlBHTh4PHAOTxhWkT/avPKu9+FZ5SPluPsuwaDecLbqla6lm26TkNrB2KPa4 r92/seVnbDK1YnihgKUP3Tb4Aeb7rgHIUZ7ADWR4KQIjwsz+/0BWGKpNrp3XMRF8D4KO9qInwd7k Gd8Rzlf3AgMBAAGjggFyMIIBbjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRPHa+Iym24 qhwJ+cXREe1ZtJP6CzAOBgNVHQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUL0VCHjEFgNVw2PgdV8tb etU9nPcwdQYDVR0fBG4wbDBqoGigZoYxaHR0cDovL2NybC5wa2kuZnJhdW5ob2Zlci5kZS9maGct cm9vdC1jYS0yMDA3LmNybIYxaHR0cDovL2NybC5mcmF1bmhvZmVyLXBraS5kZS9maGctcm9vdC1j YS0yMDA3LmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LnBr aS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMD4GCCsGAQUFBzAChjJodHRwOi8v Y2VydC5mcmF1bmhvZmVyLXBraS5kZS9maGctcm9vdC1jYS0yMDA3LmNlcjANBgkqhkiG9w0BAQUF AAOCAQEAAHdsjDP57lcEJcrLiDnmTkykzsKWSxmGTbhEV8KVqRA37DBVMV/1nrW7tWtaoXfseksl 2OFdQs3BQzhhd8AO28iFf+ncgudyPZbmU48vc41LIy2bnA+I3jY2t0BLt/bELGLLhNzE3xRSYK/z XgBTB1ZJBxsd5VV2/hdyd/vcXlx5P8Af8iCnf0SIjDE0+Pmvq2tjEwrGAHuJICdL89k12BjfLbo4 woLFFG8HyQvcKzogiTDSTNYu7FFalSiKLMFu4eUKVlDbtROEQLAxM+3XqVwmGgCMD6axCJK9HROt 86h4ZjOHoEu4hpgXzUKIVDuoyTljXCfXSManNHP+FlB4PDCCBagwggSQoAMCAQICCjQb63gAAAAA uucwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAf BgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2Vy IENBIDIwMDcwHhcNMTAwMjAxMTE0MDM0WhcNMTYwMTMxMTE0MDM0WjBaMQswCQYDVQQGEwJERTET MBEGA1UEChMKRnJhdW5ob2ZlcjENMAsGA1UECxMERktJRTEPMA0GA1UECxMGUGVvcGxlMRYwFAYD VQQDEw1IZW5uaW5nIFJvZ2dlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxsgT9VRl hiEraBMqzI0g5nkPrSTp7j5TS/GTjKhiwmyr4hZ6VuurgDhTMulz7JRLZJMXJqEwjEBqPiHoGTEk gHl166P/lx2Or+j9XiHPYPxJjDOvRkWsrw+SWuiyacbroSTaDwz7nA38R27jXUSEKyi0SmhXYiBU Ihh1/sEf/uDmi9oBhfj6gOjzM/vLM7NJqi70CE6UMa0Ph8R7H+rwYXhQlVWZzUnKvt6OJFJ4HLJv m6xHreiOrU97kPlwi3YQZUxC439gYPY0wmFEmddNHOQ2fjtkoQYR9IgGWfP3vbQ8nXxUTIlOhS5x 9sSaSU/pTYBJv7xYyjPrS9SIGl5bqQIDAQABo4ICYTCCAl0wDgYDVR0PAQH/BAQDAgbAMCsGA1Ud EQQkMCKBIGhlbm5pbmcucm9nZ2VAZmtpZS5mcmF1bmhvZmVyLmRlMB0GA1UdDgQWBBQBfgSrsBku X2mKj92DUbzW0i0r8zAfBgNVHSMEGDAWgBRPHa+Iym24qhwJ+cXREe1ZtJP6CzB1BgNVHR8EbjBs MGqgaKBmhjFodHRwOi8vY3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy11c2VyLWNhLTIwMDcuY3Js hjFodHRwOi8vY3JsLmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11c2VyLWNhLTIwMDcuY3JsMIIBCgYI KwYBBQUHAQEEgf0wgfowPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LnBraS5mcmF1bmhvZmVyLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMD4GCCsGAQUFBzAChjJodHRwOi8vY2VydC5mcmF1bmhvZmVy LXBraS5kZS9maGctdXNlci1jYS0yMDA3LmNlcjA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2Vy LWNhLTIwMDcub2NzcC5wa2kuZnJhdW5ob2Zlci5kZS8wOwYIKwYBBQUHMAGGL2h0dHA6Ly9maGct dXNlci1jYS0yMDA3Lm9jc3AuZnJhdW5ob2Zlci1wa2kuZGUvMBMGA1UdJQQMMAoGCCsGAQUFBwME MEQGA1UdIAQ9MDswOQYLKwYBBAGGClADAQEwKjAoBggrBgEFBQcCARYcaHR0cDovL3BraS5mcmF1 bmhvZmVyLmRlL2NwLzANBgkqhkiG9w0BAQUFAAOCAQEAOayOZLk0fQfhQ7I0Qzn6KzuD4ixrzteS XITHu1RJ9/3xebplEm6YI/jwMLNFnfglXq+9I+rGjE/PxSOW6qK8CA31DIo8qXhsxvvfF3yrFzHL zgyCcWdoxer2YvfKpJJfx0BKPGMvuAeTJp5L+PuWcGkvmDb/wRwAJOfjNSokNdc27k3T+HTtXNsM rQzGWeIZFnK+pSQm/gWoDX7dNZE592/Dq8Rp83jedwl5CDBKd0B6PDCM7vsEA9P+9L9/142H/1u6 gYVNlR7GhsjCjUtsvpDZrMPNAd2wVAPoqiJ0WrfG/IEuA5SySue+aeflbvMxDT1cWFnighiatWYb xwNmPDCCBbQwggScoAMCAQICCjQb6OgAAAAAuuYwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMC REUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBL STEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcwHhcNMTAwMjAxMTE0MDM0WhcNMTYw MTMxMTE0MDM0WjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjENMAsGA1UECxME RktJRTEPMA0GA1UECxMGUGVvcGxlMRYwFAYDVQQDEw1IZW5uaW5nIFJvZ2dlMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAosulW1xdX1xuHoX36m/A69SfDwvfsXmrYgI0qhSDgovRnWxT 64dxCK2+vU+LskPno1m0RJTRbKgVo6O8j1/oU/OBVpi82DM97mWMUxYEpweKLdq+ROTZPUwFY8Qf z8EJ/cZjyrEBYs8NxAfRPFRWGd+BrkKNIvB9mr77PQa/rA+qEuNTmKY0Nbl4VAgwmGV37RFA2CLz 38wc44uloJJKyYIA7CbIMae3kjUKy9YY55kyjgCY3c21/YV4ruOEwBu9yfEBmxx0E1P0/fB7G3+7 d6kBL+avP/QhwYmdJjFsarYSmUpXp9P1+c8HFTw5TYGULtj8f/FWQlmRjWDzSct4eQIDAQABo4IC bTCCAmkwDgYDVR0PAQH/BAQDAgQwMCsGA1UdEQQkMCKBIGhlbm5pbmcucm9nZ2VAZmtpZS5mcmF1 bmhvZmVyLmRlMB0GA1UdDgQWBBRir/+EBYAUW6PBp6sYHmuGX1+fsjAfBgNVHSMEGDAWgBRPHa+I ym24qhwJ+cXREe1ZtJP6CzB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8vY3JsLnBraS5mcmF1bmhv ZmVyLmRlL2ZoZy11c2VyLWNhLTIwMDcuY3JshjFodHRwOi8vY3JsLmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY3JsMIIBCgYIKwYBBQUHAQEEgf0wgfowPgYIKwYBBQUHMAKGMmh0 dHA6Ly9jZXJ0LnBraS5mcmF1bmhvZmVyLmRlL2ZoZy11c2VyLWNhLTIwMDcuY2VyMD4GCCsGAQUF BzAChjJodHRwOi8vY2VydC5mcmF1bmhvZmVyLXBraS5kZS9maGctdXNlci1jYS0yMDA3LmNlcjA7 BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNhLTIwMDcub2NzcC5wa2kuZnJhdW5ob2Zlci5k ZS8wOwYIKwYBBQUHMAGGL2h0dHA6Ly9maGctdXNlci1jYS0yMDA3Lm9jc3AuZnJhdW5ob2Zlci1w a2kuZGUvMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQGCCsGAQUFBwMEMEQGA1UdIAQ9MDswOQYLKwYB BAGGClADAQEwKjAoBggrBgEFBQcCARYcaHR0cDovL3BraS5mcmF1bmhvZmVyLmRlL2NwLzANBgkq hkiG9w0BAQUFAAOCAQEABPYI1Hbqips/0o+2m6Guww7ys/5F++qSYPq6w4CtlyuPupLZdKzEVuZ2 n1fopZuEndTyCTq8DUJwZXKPEIYKQGhkbFNy3IDaHB5VHaX0JsqV4DsgD6Xa2jnEBQpiy8RxMKP5 mY5NRS4jO6J+bFjrMiKbjDlzvJJxy6kqy8efjxH6RdMjGxQRcMS4EUTs7DRu38A81XEGaqqtjcwN 3n3EvJUVcBzXn63Bmb4bgv1U6DYXFMSMcksssapmsdL0EPXKAWBRcswouetjRBXIFfu1xKFINtwy ax6RCZycAEXddFC6j/3BVvi6iNFSE1VVQx+HQz1EhGBcp80W3qnIvoO1UjGCA3YwggNyAgEBMHUw ZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIg Q29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb63gAAAAA uucwCQYFKw4DAhoFAKCCAdYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTAwODAzMDgzNzA3WjAjBgkqhkiG9w0BCQQxFgQUMtPrPvsNvhQzyy139bLQW/7vEeQwZwYJ KoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVu aG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb 6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJh dW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1 bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0BAQEFAASCAQAm2IU/ZtGr ZakahMjEVzGHzzAJCQCHWDzkx+xTLEs1i0oZmehYYCGMPYoOUAfabFL6gCj5Pkj1Koqu5N7KCGZ7 UCOLaUImpEDKk6HgQ4bmW4SzELx2si34QbfodEgvUR+P/UV1brsD3ttUjEYeLRshzd99IDEpXrFz bqZ4BII8dgTSfVT0C5uz6h8hYdqx2jhVGVVUI6yb6qMkRxsPhZUjx/MmAfxfG7GafbEAYhB3LhpV fdUgD9TRH3sMOR1leOfooxfZNMSLEDRnQHKm7Qi/rRg/5NHl2Mf02vKErwcijuFE/xQsMSwAj/oN pte4uTBfjTiNiD5k1guN4WdmYt9XAAAAAAAA ------=_NextPart_000_000A_01CB32F7.D1FE83A0-- From charles.perkins@earthlink.net Tue Aug 3 10:56: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 CB4A53A6950 for ; Tue, 3 Aug 2010 10:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, 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 r+JQPz119IpX for ; Tue, 3 Aug 2010 10:56:03 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id D7D383A693A for ; Tue, 3 Aug 2010 10:56:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=AMiwYxtfJst80PSQnKCuqZoclvdsNgZELizSYX5vWn1hoDTerqaJWhVCOi4VPlmp; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.154]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OgLj5-0001mE-0t; Tue, 03 Aug 2010 13:56:31 -0400 Message-ID: <4C58584D.2010604@earthlink.net> Date: Tue, 03 Aug 2010 10:56:29 -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.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Ryuji Wakikawa References: <4C528979.7010006@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5278a1931cf0d85af84e993a3a0fd6cf65350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org, Autoconf Chairs Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [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: Tue, 03 Aug 2010 17:56:03 -0000 Hello folks, I disagree that the addressing model and the implications upon link-local addressability are any less valid for hosts than they are for routers. The danger I see is that the title change could at any time be cited as justification for restricting the work of [autoconf] so that only routers can get addresses. This sort of political device is often able to overcome any objection that the earlier language in previous documents was having unintentional side-effects (once they are published). The point was raised during the meeting that any router could pretend to be a host by simply setting willingness == 0. It was not explained why an energy-constrained device should have to implement thousands of lines of code just so it could have the privilege of being called a router when it should never ever be configured to forward packets. But perhaps I digress from the point of the consensus call. Regards, Charlie P. On 8/2/2010 5:14 PM, Ryuji Wakikawa wrote: > Hello all, > > At the IETF78 meeting, we had the rough consensus to adapt > the Erik's modification for RFC5889 in the room. > > To confirm our consensus on the list, we ask the WG consensus call > for adaption of Erik's modification for RFC5889. > > The detailed modifications can be found at the attached email below. Thanks Erik. > > Please vote for your opinion before "Aug 9th 12:00PM (PST)". > If you have any objections, please give us clear reason and propose your text. > > thanks in advance, > Thomas, ryuji From henning.rogge@fkie.fraunhofer.de Tue Aug 3 22:27: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 A159C3A6BD6 for ; Tue, 3 Aug 2010 22:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=-1.122, 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 R8Gc9M2FwwKp for ; Tue, 3 Aug 2010 22:27:24 -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 D03413A6819 for ; Tue, 3 Aug 2010 22:27:23 -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 1OgWVy-0005PP-W8; Wed, 04 Aug 2010 07:27:43 +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 1OgWVy-0007Gv-DR; Wed, 04 Aug 2010 07:27:42 +0200 From: Henning Rogge To: autoconf@ietf.org Date: Wed, 4 Aug 2010 07:27:33 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-24-generic; KDE/4.4.5; i686; ; ) References: <4C528979.7010006@oracle.com> <4C58584D.2010604@earthlink.net> In-Reply-To: <4C58584D.2010604@earthlink.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1328561.m3BLToiteE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201008040727.39245.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11493/Wed Aug 4 05:08:50 2010) by mailguard.fgan.de X-Scan-Signature: e39b0b635d2099d1d28d84c0f3b7851d Cc: Autoconf Chairs Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [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: Wed, 04 Aug 2010 05:27:25 -0000 --nextPart1328561.m3BLToiteE Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue August 3 2010 19:56:29 Charles E. Perkins wrote: > The point was raised during the meeting that > any router could pretend to be a host by simply > setting willingness =3D=3D 0. This would still be a node sending out HELLO (and maybe even TC messages if= it=20 has an attached network), so I would still consider it a router, just with = a=20 special configuration. > It was not explained why an energy-constrained > device should have to implement thousands of lines > of code just so it could have the privilege of > being called a router when it should never ever > be configured to forward packets. I think the problem is that the scope of the address model has no clear=20 border. It should be done on the routers (but MANETs can and have been run= =20 with different address models), and it could be used for hosts closely=20 attached to a MANET, but it's not necessary to do so. But in my opinion it is still better it's still better to restrict the titl= e=20 as suggested in the WG meeting consensus that to make it too generic. 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 --nextPart1328561.m3BLToiteE 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) iEYEABECAAYFAkxY+kYACgkQRIfGfFXsz+DpNgCgniXl8XLVPavSmJg3io04qUHs sYQAoJMREaudovKLfn/enNuYGO9ER8SQ =Pkgo -----END PGP SIGNATURE----- --nextPart1328561.m3BLToiteE-- From henning.rogge@fkie.fraunhofer.de Tue Aug 3 22:29: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 893EE3A6817 for ; Tue, 3 Aug 2010 22:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=-1.073, 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 gI4tD0ZcdBfd for ; Tue, 3 Aug 2010 22:29:26 -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 F0F673A67FE for ; Tue, 3 Aug 2010 22:29:24 -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 1OgWY4-0005R1-88; Wed, 04 Aug 2010 07:29:52 +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 1OgWY3-0007HF-VE; Wed, 04 Aug 2010 07:29:52 +0200 From: Henning Rogge To: autoconf@ietf.org Date: Wed, 4 Aug 2010 07:29:48 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-24-generic; KDE/4.4.5; i686; ; ) References: <4C528979.7010006@oracle.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3769930.EHjSIurDIb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201008040729.48958.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11493/Wed Aug 4 05:08:50 2010) by mailguard.fgan.de X-Scan-Signature: a8e2f18599482a3592288cf2106a6f9f Cc: Autoconf Chairs , Ralph Droms Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: 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: Wed, 04 Aug 2010 05:29:28 -0000 --nextPart3769930.EHjSIurDIb Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue August 3 2010 02:14:05 Ryuji Wakikawa wrote: > Hello all, >=20 > At the IETF78 meeting, we had the rough consensus to adapt > the Erik's modification for RFC5889 in the room. >=20 > To confirm our consensus on the list, we ask the WG consensus call > for adaption of Erik's modification for RFC5889. >=20 > The detailed modifications can be found at the attached email below. Than= ks > Erik. >=20 > Please vote for your opinion before "Aug 9th 12:00PM (PST)". > If you have any objections, please give us clear reason and propose your > text. Same as on the WG meeting in Maastricht, I vote for the change. 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 --nextPart3769930.EHjSIurDIb 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) iEYEABECAAYFAkxY+swACgkQRIfGfFXsz+CRJQCdHju9nkt0w4yKthjFex/IncB9 qrwAn1ucOloCpFOiYP7VAMjF/y04ZXt/ =MoCP -----END PGP SIGNATURE----- --nextPart3769930.EHjSIurDIb-- From charles.perkins@earthlink.net Tue Aug 3 22:40: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 6D3D83A682D for ; Tue, 3 Aug 2010 22:40: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 R+TIYQI6Tifg for ; Tue, 3 Aug 2010 22:40:36 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 244DE3A6817 for ; Tue, 3 Aug 2010 22:40:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=reUDJ7OVUbegPWIALvOMZKQkbrLOYnX/LOIDlUBFsnbE5HRoYvKX0IEH976hheVw; 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 [24.6.171.143] (helo=[192.168.1.105]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OgWiu-0005zv-Om for autoconf@ietf.org; Wed, 04 Aug 2010 01:41:05 -0400 Message-ID: <4C58FD6D.3050802@earthlink.net> Date: Tue, 03 Aug 2010 22:41:01 -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.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "autoconf@ietf.org" References: <4C528979.7010006@oracle.com> <4C58584D.2010604@earthlink.net> <201008040727.39245.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <201008040727.39245.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f524ccb835a6b9d67e133d0c1f868c49a4c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.6.171.143 Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [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: Wed, 04 Aug 2010 05:40:37 -0000 Hello Henning, On 8/3/2010 10:27 PM, Henning Rogge wrote: > On Tue August 3 2010 19:56:29 Charles E. Perkins wrote: >> The point was raised during the meeting that >> any router could pretend to be a host by simply >> setting willingness == 0. > This would still be a node sending out HELLO (and maybe even TC messages if it > has an attached network), so I would still consider it a router, just with a > special configuration. This is beside the point. Hosts need addresses, and if the only way they can get them is to be routers, then something is wrong. > >> It was not explained why an energy-constrained >> device should have to implement thousands of lines >> of code just so it could have the privilege of >> being called a router when it should never ever >> be configured to forward packets. > I think the problem is that the scope of the address model has no clear > border. The scope is difficult to define -- that's the problem. The ad hoc network could be defined as the union of the ranges of the nodes in it, and then the border to be the border of that set (neglecting certain details). This still does not materially explain why a host should implement all that code. > It should be done on the routers (but MANETs can and have been run > with different address models), and it could be used for hosts closely > attached to a MANET, but it's not necessary to do so. What is "it"? > But in my opinion it is still better it's still better to restrict the title > as suggested in the WG meeting consensus that to make it too generic. I can't imagine any non-political reason whatsoever for this. Regards, Charlie P. From henning.rogge@fkie.fraunhofer.de Tue Aug 3 22:55: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 1B6AC3A682D for ; Tue, 3 Aug 2010 22:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=-1.029, 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 UYsbRFEUeiYQ for ; Tue, 3 Aug 2010 22:55:40 -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 6FD3E3A6817 for ; Tue, 3 Aug 2010 22:55:40 -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 1OgWxU-0006Hn-F4; Wed, 04 Aug 2010 07:56:08 +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 1OgWxU-0007Mi-6l; Wed, 04 Aug 2010 07:56:08 +0200 From: Henning Rogge To: autoconf@ietf.org Date: Wed, 4 Aug 2010 07:55:58 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-24-generic; KDE/4.4.5; i686; ; ) References: <4C528979.7010006@oracle.com> <201008040727.39245.henning.rogge@fkie.fraunhofer.de> <4C58FD6D.3050802@earthlink.net> In-Reply-To: <4C58FD6D.3050802@earthlink.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1491998.AFSVff5617"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201008040756.04650.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11493/Wed Aug 4 05:08:50 2010) by mailguard.fgan.de X-Scan-Signature: 613e361f9d855afea217a25ae32b219c Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [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: Wed, 04 Aug 2010 05:55:42 -0000 --nextPart1491998.AFSVff5617 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Wed August 4 2010 07:41:01 Charles E. Perkins wrote: > Hello Henning, >=20 > On 8/3/2010 10:27 PM, Henning Rogge wrote: > > On Tue August 3 2010 19:56:29 Charles E. Perkins wrote: > >> The point was raised during the meeting that > >> any router could pretend to be a host by simply > >> setting willingness =3D=3D 0. > >=20 > > This would still be a node sending out HELLO (and maybe even TC messages > > if it has an attached network), so I would still consider it a router, > > just with a special configuration. >=20 > This is beside the point. Hosts need addresses, > and if the only way they can get them is to be > routers, then something is wrong. If you run a part of the routing protocol to connect the "host" to the MANE= T,=20 it's a router in my oppinion (Ripple would call it a leaf node for example). If the node just use DHCP or similar protocols to get it's address without= =20 being modified to work with the MANET, it's no router (and don't need the=20 autoconf address model). The autoconf model is NOT the only way for a host to get an address for=20 connection to a MANET. > >> It was not explained why an energy-constrained > >> device should have to implement thousands of lines > >> of code just so it could have the privilege of > >> being called a router when it should never ever > >> be configured to forward packets. > >=20 > > I think the problem is that the scope of the address model has no clear > > border. >=20 > The scope is difficult to define -- that's the > problem. The ad hoc network could be defined as the > union of the ranges of the nodes in it, and then > the border to be the border of that set (neglecting > certain details). This still does not materially > explain why a host should implement all that code. I don't remember that anyone demands that such "leaf nodes" have to run the= =20 complete routing daemon. If you have a router with a policy that limits the routers functionality (i= n=20 terms of the routing protocol), you could just write a compact/optimized=20 version of the needed software part for it. > > It should be done on the routers (but MANETs can and have been run > > with different address models), and it could be used for hosts closely > > attached to a MANET, but it's not necessary to do so. >=20 > What is "it"? The autoconf address model should be used on routers (but you could use a=20 different one) and it (the address model) could be used on hosts attached t= o a=20 MANET, but it's not necessary to use the autoconf address model on hosts. =20 > > But in my opinion it is still better it's still better to restrict the > > title as suggested in the WG meeting consensus that to make it too > > generic. >=20 > I can't imagine any non-political reason whatsoever for this. If we do otherwise we could have the same problems. People would say "you=20 demand that any computer attached to your MANET use the autoconf address=20 model. But we have to use DHCP, so your address model is wrong." (I don't say they are right, but we will get people with strange comments o= n=20 the address model with both titles) 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 --nextPart1491998.AFSVff5617 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) iEYEABECAAYFAkxZAO8ACgkQRIfGfFXsz+BJ6QCePcZZA5Hw6aoMdmVReFplsjdF /iwAoIjq2LByFm4wbIDQu9Z5LtFZXLx3 =+kOI -----END PGP SIGNATURE----- --nextPart1491998.AFSVff5617-- From teco@inf-net.nl Tue Aug 3 23:10: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 C1D1D3A6BE7 for ; Tue, 3 Aug 2010 23:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 byXsEd6r-Ksm for ; Tue, 3 Aug 2010 23:10:03 -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 38BE93A69FA for ; Tue, 3 Aug 2010 23:10:03 -0700 (PDT) Received: by ewy22 with SMTP id 22so2117457ewy.31 for ; Tue, 03 Aug 2010 23:10:31 -0700 (PDT) Received: by 10.213.22.18 with SMTP id l18mr1620889ebb.58.1280902231427; Tue, 03 Aug 2010 23:10:31 -0700 (PDT) Received: from [192.168.2.196] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id a48sm12158143eei.6.2010.08.03.23.10.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Aug 2010 23:10:30 -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, 4 Aug 2010 08:10:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7D235582-112C-4217-A646-34139CAB49F9@inf-net.nl> References: To: Ulrich Herberg 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: Wed, 04 Aug 2010 06:10:04 -0000 Op 2 aug 2010, om 23:46 heeft Ulrich Herberg het volgende geschreven: >>> Do you mean that a node is DHCP client and relay in the same time? >>> That is not possible according to RFC3315, which says (i) in section >>> 15.13 "clients MUST discard any received Relay-forward messages" and >>> (ii) section 15.3 "servers and relay agents MUST discard any = received >>> Advertise messages". >>=20 >> I don't think there is such limitation. >> A node that combines client and relay would not send out a packet = that does >> not conform to the spec. >=20 > Fred pointed that out. I wonder whether that demultiplexing is clearly > pointed out in the DHCPv6 RFC. But well, too late to change it ;-) > I assume that major DHCPv6 implementations do not implement that > demultiplexing (they'd need to share the UDP port, demultiplex > messsages etc.) (-- I know, that's not so much a problem of the > standardization process.. just wondering here) I don't see the problem. >>> Also, the relay would need to have a direct unicast connection to = the >>> central node or use other relaying mechanisms such as SMF (as you >>> mentioned below), because multiple relaying is not really feasible = in >>> DHCPv6 itself: Relaying uses encapsulation, so packets would be >>> encapsulated at every hop, quickly increasing overhead. >>=20 >> Yes, relaying and encap on every hop is a bad idea, I think. >> But we don't have a standard track multicast protocol for MANETs. >> We also don't have a protocol for service discovery, for learning the >> DHCP server address. >> This makes our work experimental. >=20 > Indeed. It would make life easier to have such protocols as RFCs > already :-) With SMF, we have at least a protocol which is not so far > from being published as RFC. SMF is experimental. Teco= From teco@inf-net.nl Tue Aug 3 23:20: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 204A43A6BD9 for ; Tue, 3 Aug 2010 23:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 xaaqsQ4RugCa for ; Tue, 3 Aug 2010 23:20:46 -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 EABB13A6A46 for ; Tue, 3 Aug 2010 23:20:45 -0700 (PDT) Received: by ewy22 with SMTP id 22so2119209ewy.31 for ; Tue, 03 Aug 2010 23:21:14 -0700 (PDT) Received: by 10.14.53.70 with SMTP id f46mr3319908eec.19.1280902874134; Tue, 03 Aug 2010 23:21:14 -0700 (PDT) Received: from [192.168.2.196] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id v59sm12176412eeh.22.2010.08.03.23.21.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Aug 2010 23:21:13 -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, 4 Aug 2010 08:21:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <29650CDE-A6A8-40C9-B626-FA8E58CA0345@inf-net.nl> References: <201008030725.23669.henning.rogge@fkie.fraunhofer.de> To: Ulrich Herberg 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: Wed, 04 Aug 2010 06:20:47 -0000 Op 3 aug 2010, om 10:28 heeft Ulrich Herberg het volgende geschreven: > Hi Henning, >=20 > On Tue, Aug 3, 2010 at 7:25 AM, Henning Rogge > wrote: >> Hello, >>=20 >> is there a reason why we cannot place an DHCPv6-relay on every node = for its >> neighbors ? Each node requesting an address/prefix will send out an = IP >> datagram with an anycast destination an a linklocal source, which = will be >> forwarded by its neighbors (with a unicast) to the DHCPv6-server. >=20 > Sure, that works. DHCP clients would typically send their messages to > the All_DHCP_Relay_Agents_and_Servers multicast address. However, that > necessitates the use of a unicast routing protocol, because the relay > has to have a route towards the DHCP server. The question is, do we > want to depend on that? I think we should also have a running autoconf > mechanism in cases when there is no unicast routing protocol in place. This is the 2b scenario. A problem is that all neighbors relay the DHCP request. In a dense = network, (to) many neighbors will relay. One can think of a backpressure = mechanism.=20 Another problem is the discovery of the DHCP server(s). Easy to solve, solutions are around (BRDP is just one of them). But in many solutions, the MANET protocol is adjusted for service discovery support. (BRDP is = not a MANET protocol, it is an RA extension). I don't think the need for a routing protocol for forwarding packages is = a problem. There are no functional MANETs without.=20 Teco. From henning.rogge@fkie.fraunhofer.de Tue Aug 3 23:29:23 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 049463A69DC for ; Tue, 3 Aug 2010 23:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=-0.987, 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 MKPeMNOTd-jX for ; Tue, 3 Aug 2010 23:29:21 -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 71DA73A6781 for ; Tue, 3 Aug 2010 23:29:21 -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 1OgXU5-0007FN-8H; Wed, 04 Aug 2010 08:29:49 +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 1OgXU4-0007Sx-Vs; Wed, 04 Aug 2010 08:29:49 +0200 From: Henning Rogge To: Teco Boot Date: Wed, 4 Aug 2010 08:29:34 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-24-generic; KDE/4.4.5; i686; ; ) References: <29650CDE-A6A8-40C9-B626-FA8E58CA0345@inf-net.nl> In-Reply-To: <29650CDE-A6A8-40C9-B626-FA8E58CA0345@inf-net.nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7718863.3sI0CBcDWu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201008040829.45561.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11493/Wed Aug 4 05:08:50 2010) by mailguard.fgan.de X-Scan-Signature: 33310ad9788a957f7423ac134a469312 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: Wed, 04 Aug 2010 06:29:23 -0000 --nextPart7718863.3sI0CBcDWu Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Wed August 4 2010 08:21:11 Teco Boot wrote: > Op 3 aug 2010, om 10:28 heeft Ulrich Herberg het volgende geschreven: > > Hi Henning, > >=20 > > On Tue, Aug 3, 2010 at 7:25 AM, Henning Rogge > >=20 > > wrote: > >> Hello, > >>=20 > >> is there a reason why we cannot place an DHCPv6-relay on every node for > >> its neighbors ? Each node requesting an address/prefix will send out an > >> IP datagram with an anycast destination an a linklocal source, which > >> will be forwarded by its neighbors (with a unicast) to the > >> DHCPv6-server. > >=20 > > Sure, that works. DHCP clients would typically send their messages to > > the All_DHCP_Relay_Agents_and_Servers multicast address. However, that > > necessitates the use of a unicast routing protocol, because the relay > > has to have a route towards the DHCP server. The question is, do we > > want to depend on that? I think we should also have a running autoconf > > mechanism in cases when there is no unicast routing protocol in place. >=20 > This is the 2b scenario. > A problem is that all neighbors relay the DHCP request. In a dense networ= k, > (to) many neighbors will relay. One can think of a backpressure mechanism. > Another problem is the discovery of the DHCP server(s). Easy to solve, > solutions are around (BRDP is just one of them). But in many solutions, > the MANET protocol is adjusted for service discovery support. (BRDP is not > a MANET protocol, it is an RA extension). Does a DHCP-reply from a relay contain the address of the DHCP-server ? > I don't think the need for a routing protocol for forwarding packages is a > problem. There are no functional MANETs without. I agree with this. 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 --nextPart7718863.3sI0CBcDWu 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) iEYEABECAAYFAkxZCM4ACgkQRIfGfFXsz+CnQwCdG4iGyGW9fvTcuoXoZeR0OAre vHMAoKWMYKR5/ZQiVZ2pcGA3hBeIy5uV =T5RX -----END PGP SIGNATURE----- --nextPart7718863.3sI0CBcDWu-- From teco@inf-net.nl Tue Aug 3 23:48: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 3C9BA3A6B8F for ; Tue, 3 Aug 2010 23:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 61G+NQrLggqt for ; Tue, 3 Aug 2010 23:48: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 F2A2F3A69FA for ; Tue, 3 Aug 2010 23:48:14 -0700 (PDT) Received: by ewy22 with SMTP id 22so2123909ewy.31 for ; Tue, 03 Aug 2010 23:48:43 -0700 (PDT) Received: by 10.14.47.6 with SMTP id s6mr3315075eeb.44.1280904523362; Tue, 03 Aug 2010 23:48:43 -0700 (PDT) Received: from [192.168.2.197] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id a48sm12210549eei.6.2010.08.03.23.48.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Aug 2010 23:48:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4C58584D.2010604@earthlink.net> Date: Wed, 4 Aug 2010 08:48:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <379B3F32-224C-46C0-8599-913AD85A803E@inf-net.nl> References: <4C528979.7010006@oracle.com> <4C58584D.2010604@earthlink.net> To: Charles E. Perkins X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org, Autoconf Chairs Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [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: Wed, 04 Aug 2010 06:48:21 -0000 Charlie, I see it this way: What makes a node a router? (mentioned in meeting, maybe incomplete = lsit) a) The device MAY forward packets. Even the case if it actually doesn't,=20= e.g. the topology is such that no packet is sent to it for forwarding. = Many=20 OSses have a "Forwarding" config flag. When on, it is a router. This has=20= nothing to do with routing protocols. b) The device sends out a routing protocol packet. The intention of the device is arranging topology state, for itself or for neighbors. Hosts = may use a passive mode (often used with RIP). There are some corner cases, = like management boxes that get topology from OSPF/ISIS or BGP by adjacency = with real router. But often, such adjacency leads to topology change and thus = the=20 management box is a router. c) The device sends out an RA. Hosts MAY NOT do this. Why is this important? Especially on b): Lets say router with reactive protocol sends RREQs but not RREPs. The router will be part of the topology, but never will receive a packet = for forwarding. But still, it is a router. Willingness=3D0 is example for an = proactive=20 protocol. If a host uses tobe-RFC5889 and only uses a /128 prefix, and other = nearby nodes also use /128's, there is no connectivity. 1-hop neighbors can't know = that the host is reachable. I experienced this problem during maintenance or = outage of the routing protocol, I couldn't remotely repair. That is why I use = another=20 addressing model, that doesn't has this shortcoming. It supports all = types of=20 nodes. A big, big difference. This is why I support the title change. Regards, Teco Op 3 aug 2010, om 19:56 heeft Charles E. Perkins het volgende = geschreven: >=20 > Hello folks, >=20 > I disagree that the addressing model and the > implications upon link-local addressability > are any less valid for hosts than they are > for routers. >=20 > The danger I see is that the title change > could at any time be cited as justification > for restricting the work of [autoconf] > so that only routers can get addresses. > This sort of political device is often able > to overcome any objection that the earlier > language in previous documents was having > unintentional side-effects (once they are > published). >=20 > The point was raised during the meeting that > any router could pretend to be a host by simply > setting willingness =3D=3D 0. >=20 > It was not explained why an energy-constrained > device should have to implement thousands of lines > of code just so it could have the privilege of > being called a router when it should never ever > be configured to forward packets. >=20 > But perhaps I digress from the point of the > consensus call. >=20 > Regards, > Charlie P. >=20 >=20 > On 8/2/2010 5:14 PM, Ryuji Wakikawa wrote: >> Hello all, >>=20 >> At the IETF78 meeting, we had the rough consensus to adapt >> the Erik's modification for RFC5889 in the room. >>=20 >> To confirm our consensus on the list, we ask the WG consensus call >> for adaption of Erik's modification for RFC5889. >>=20 >> The detailed modifications can be found at the attached email below. = Thanks Erik. >>=20 >> Please vote for your opinion before "Aug 9th 12:00PM (PST)". >> If you have any objections, please give us clear reason and propose = your text. >>=20 >> thanks in advance, >> Thomas, ryuji > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From teco@inf-net.nl Wed Aug 4 00:39: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 DBC8E3A67A1 for ; Wed, 4 Aug 2010 00:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 3HfaeYexlfdK for ; Wed, 4 Aug 2010 00:39:13 -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 0E80C3A696F for ; Wed, 4 Aug 2010 00:39:11 -0700 (PDT) Received: by eyb7 with SMTP id 7so2116672eyb.31 for ; Wed, 04 Aug 2010 00:39:40 -0700 (PDT) Received: by 10.213.30.15 with SMTP id s15mr6417925ebc.48.1280907580587; Wed, 04 Aug 2010 00:39:40 -0700 (PDT) Received: from [192.168.2.197] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id v8sm12283327eeh.8.2010.08.04.00.39.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Aug 2010 00:39:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <201008040829.45561.henning.rogge@fkie.fraunhofer.de> Date: Wed, 4 Aug 2010 09:39:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <29650CDE-A6A8-40C9-B626-FA8E58CA0345@inf-net.nl> <201008040829.45561.henning.rogge@fkie.fraunhofer.de> To: Henning Rogge 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: Wed, 04 Aug 2010 07:39:15 -0000 Op 4 aug 2010, om 08:29 heeft Henning Rogge het volgende geschreven: >=20 >> Another problem is the discovery of the DHCP server(s). Easy to = solve, >> solutions are around (BRDP is just one of them). But in many = solutions, >> the MANET protocol is adjusted for service discovery support. (BRDP = is not >> a MANET protocol, it is an RA extension). > Does a DHCP-reply from a relay contain the address of the DHCP-server = ? We have RFCs that document our protocols. Is RFC3315 unclear on this? Relay simply relays the DHCP-reply from server to client (or to = downstream relay), after stripped the Relay Message option. When no relay adds a Relay Agent Option, server may send Server Unicast = Option. Clients may ask for the Server Unicast Option. Teco From teco@inf-net.nl Wed Aug 4 02:00: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 6F5B53A6846 for ; Wed, 4 Aug 2010 02:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 CEZOwedYDCT4 for ; Wed, 4 Aug 2010 02:00:43 -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 995393A6A43 for ; Wed, 4 Aug 2010 02:00:41 -0700 (PDT) Received: by ewy22 with SMTP id 22so2151476ewy.31 for ; Wed, 04 Aug 2010 02:01:11 -0700 (PDT) Received: by 10.213.26.13 with SMTP id b13mr6492458ebc.67.1280912470836; Wed, 04 Aug 2010 02:01:10 -0700 (PDT) Received: from [192.168.2.197] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id v8sm12394777eeh.14.2010.08.04.02.01.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Aug 2010 02:01:10 -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, 4 Aug 2010 11:01:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0306B415-E08D-427B-B01C-2366C52EBF57@inf-net.nl> References: <4C528979.7010006@oracle.com> To: Ryuji Wakikawa X-Mailer: Apple Mail (2.1081) Cc: "Christopher \(UK\) Dearlove" , Ralph Droms , Autoconf Chairs , "autoconf@ietf.org autoconf@ietf.org" Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: 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: Wed, 04 Aug 2010 09:00:47 -0000 One problem and proposal for correction. I don't want to delay the = process,=20 so accepting or rejecting it is acceptable (RFC is informational, so=20 I can ignore all what it says). I suggest authors, ADs, chairs and Erik=20= decide. The NEW text says: "must be of the modified EUI-64 form". There can be other mechanisms that assure uniqueness. Other text says:=20= "such identifiers could be based on factory assignment or = configuration". The new text will bring a consistency problem in the document. A _should_ helps: NEWER: 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 should be of the modified EUI-64 form. ------ Christopher Dearlove brought up same issue:=20 http://www.ietf.org/mail-archive/web/autoconf/current/msg02736.html He suggests removing the last text sentence completely: 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 With correction "ahould" to "should", I support this last proposal. Less text is better. Teco Op 3 aug 2010, om 02:14 heeft Ryuji Wakikawa het volgende geschreven: > Hello all, >=20 > At the IETF78 meeting, we had the rough consensus to adapt=20 > the Erik's modification for RFC5889 in the room.=20 >=20 > To confirm our consensus on the list, we ask the WG consensus call=20 > for adaption of Erik's modification for RFC5889. >=20 > The detailed modifications can be found at the attached email below. = Thanks Erik. >=20 > Please vote for your opinion before "Aug 9th 12:00PM (PST)".=20 > If you have any objections, please give us clear reason and propose = your text. >=20 > thanks in advance, > Thomas, ryuji >=20 >=20 >=20 >=20 > Begin forwarded message: >=20 >> From: Erik Nordmark >> Date: 2010/07/30 01:12:41GMT-07:00 >> To: autoconf@ietf.org >> Subject: Re: [Autoconf] Forgot one [Was: RFC 5889 >>=20 >>=20 >> Please double-check this, but I think it has all the list of changes = that Jari said verbally. >>=20 >> Erik >>=20 >> ---- >>=20 >> Change the title >> FROM >> IP Addressing Model in Ad Hoc Networks >> TO >> A Router Addressing Model in Ad Hoc Networks >>=20 >> 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]). >>=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; 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 >> 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. >>=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 From alexandru.petrescu@gmail.com Wed Aug 4 03:00: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 141593A6A76 for ; Wed, 4 Aug 2010 03:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.088, 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 YGa7HFp-3NsG for ; Wed, 4 Aug 2010 03:00: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 562643A6A75 for ; Wed, 4 Aug 2010 03:00: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 o74A0YUt011639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 4 Aug 2010 12:00:34 +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 o74A0Yf5022425 for ; Wed, 4 Aug 2010 12:00:34 +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 o74A0Xn4019059 for ; Wed, 4 Aug 2010 12:00:34 +0200 Message-ID: <4C593A41.9050206@gmail.com> Date: Wed, 04 Aug 2010 12:00:33 +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: <4C528979.7010006@oracle.com> <0306B415-E08D-427B-B01C-2366C52EBF57@inf-net.nl> In-Reply-To: <0306B415-E08D-427B-B01C-2366C52EBF57@inf-net.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: 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: Wed, 04 Aug 2010 10:00:08 -0000 I'd capitalize "Modified EUI-64", as RFC4291 puts it. Le 04/08/2010 11:01, Teco Boot a écrit : > One problem and proposal for correction. I don't want to delay the process, > so accepting or rejecting it is acceptable (RFC is informational, so > I can ignore all what it says). I suggest authors, ADs, chairs and Erik > decide. > > The NEW text says: "must be of the modified EUI-64 form". > There can be other mechanisms that assure uniqueness. Other text says: > "such identifiers could be based on factory assignment or configuration". Hmmm... would this factory assignment be in agreement with the 'u' and 'g' bits of the Modified EUI-64 format? If yes, then there wouldn't be a need to mention such identifiers. If no - then we don't talk Modified EUI-64, and we can't say that the global uniqueness could be guaranteed by factory assignment, I think. Alex > The new text will bring a consistency problem in the document. > A _should_ helps: > > NEWER: > 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 should be of the modified EUI-64 form. > ------ > > Christopher Dearlove brought up same issue: > http://www.ietf.org/mail-archive/web/autoconf/current/msg02736.html > He suggests removing the last text sentence completely: > > > 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 > > > > With correction "ahould" to "should", I support this last proposal. > Less text is better. > > Teco > > > Op 3 aug 2010, om 02:14 heeft Ryuji Wakikawa het volgende geschreven: > >> Hello all, >> >> At the IETF78 meeting, we had the rough consensus to adapt >> the Erik's modification for RFC5889 in the room. >> >> To confirm our consensus on the list, we ask the WG consensus call >> for adaption of Erik's modification for RFC5889. >> >> The detailed modifications can be found at the attached email below. Thanks Erik. >> >> Please vote for your opinion before "Aug 9th 12:00PM (PST)". >> If you have any objections, please give us clear reason and propose your text. >> >> thanks in advance, >> Thomas, ryuji >> >> >> >> >> Begin forwarded message: >> >>> From: Erik Nordmark >>> Date: 2010/07/30 01:12:41GMT-07:00 >>> To: autoconf@ietf.org >>> Subject: Re: [Autoconf] Forgot one [Was: RFC 5889 >>> >>> >>> 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. >>> >>> --- >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From teco@inf-net.nl Wed Aug 4 03:35: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 6D8F83A6984 for ; Wed, 4 Aug 2010 03:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 UvxzsSHQfMdi for ; Wed, 4 Aug 2010 03:35:30 -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 913FC3A69BC for ; Wed, 4 Aug 2010 03:35:28 -0700 (PDT) Received: by ewy22 with SMTP id 22so2172765ewy.31 for ; Wed, 04 Aug 2010 03:35:58 -0700 (PDT) Received: by 10.14.36.87 with SMTP id v63mr3644295eea.0.1280918157994; Wed, 04 Aug 2010 03:35:57 -0700 (PDT) Received: from [192.168.2.197] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id v8sm12532152eeh.8.2010.08.04.03.35.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Aug 2010 03:35:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <4C593A41.9050206@gmail.com> Date: Wed, 4 Aug 2010 12:35:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4E208E95-19C5-4865-BE46-DDEB3468222A@inf-net.nl> References: <4C528979.7010006@oracle.com> <0306B415-E08D-427B-B01C-2366C52EBF57@inf-net.nl> <4C593A41.9050206@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: 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: Wed, 04 Aug 2010 10:35:31 -0000 You mix things up. If you read the text, you'll see the first text is for router = identifiers. The message is that what can be done for router identifiers can be done = for link locals also. Let's be consistent. Teco Op 4 aug 2010, om 12:00 heeft Alexandru Petrescu het volgende = geschreven: > I'd capitalize "Modified EUI-64", as RFC4291 puts it. >=20 > Le 04/08/2010 11:01, Teco Boot a =E9crit : >> One problem and proposal for correction. I don't want to delay the = process, >> so accepting or rejecting it is acceptable (RFC is informational, so >> I can ignore all what it says). I suggest authors, ADs, chairs and = Erik >> decide. >>=20 >> The NEW text says: "must be of the modified EUI-64 form". >> There can be other mechanisms that assure uniqueness. Other text = says: >> "such identifiers could be based on factory assignment or = configuration". >=20 > Hmmm... would this factory assignment be in agreement with the 'u' and = 'g' bits of the Modified EUI-64 format? If yes, then there wouldn't be = a need to mention such identifiers. >=20 > If no - then we don't talk Modified EUI-64, and we can't say that the = global uniqueness could be guaranteed by factory assignment, I think. >=20 > Alex >=20 >=20 >> The new text will bring a consistency problem in the document. >> A _should_ helps: >>=20 >> NEWER: >> 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 should be of the modified EUI-64 form. >> ------ >>=20 >> Christopher Dearlove brought up same issue: >> http://www.ietf.org/mail-archive/web/autoconf/current/msg02736.html >> He suggests removing the last text sentence completely: >> >>=20 >> 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. >>=20 >> (Personally, I'd modify that a little further, to: >>=20 >> 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 >>=20 >> >>=20 >> With correction "ahould" to "should", I support this last proposal. >> Less text is better. >>=20 >> Teco >>=20 >>=20 >> Op 3 aug 2010, om 02:14 heeft Ryuji Wakikawa het volgende geschreven: >>=20 >>> Hello all, >>>=20 >>> At the IETF78 meeting, we had the rough consensus to adapt >>> the Erik's modification for RFC5889 in the room. >>>=20 >>> To confirm our consensus on the list, we ask the WG consensus call >>> for adaption of Erik's modification for RFC5889. >>>=20 >>> The detailed modifications can be found at the attached email below. = Thanks Erik. >>>=20 >>> Please vote for your opinion before "Aug 9th 12:00PM (PST)". >>> If you have any objections, please give us clear reason and propose = your text. >>>=20 >>> thanks in advance, >>> Thomas, ryuji >>>=20 >>>=20 >>>=20 >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: Erik Nordmark >>>> Date: 2010/07/30 01:12:41GMT-07:00 >>>> To: autoconf@ietf.org >>>> Subject: Re: [Autoconf] Forgot one [Was: RFC 5889 >>>>=20 >>>>=20 >>>> Please double-check this, but I think it has all the list of = changes that Jari said verbally. >>>>=20 >>>> Erik >>>>=20 >>>> ---- >>>>=20 >>>> Change the title >>>> FROM >>>> IP Addressing Model in Ad Hoc Networks >>>> TO >>>> A Router Addressing Model in Ad Hoc Networks >>>>=20 >>>> 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]). >>>>=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; 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 >>>> 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. >>>>=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 >> _______________________________________________ >> 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 charles.perkins@earthlink.net Wed Aug 4 06:07: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 1D6B63A69D9 for ; Wed, 4 Aug 2010 06:07: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 dEIvMHtNTePB for ; Wed, 4 Aug 2010 06:07:18 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id E0E603A6978 for ; Wed, 4 Aug 2010 06:07:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=lVCYXpkYdnKopXT6oJGJXv/jekMF56ZShKigmdXt7bbl/zYKKDoNi8l8CbegAHtd; 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 [24.6.171.143] (helo=[192.168.1.107]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OgdhC-0005Lz-QE; Wed, 04 Aug 2010 09:07:47 -0400 Message-ID: <4C596602.1060308@earthlink.net> Date: Wed, 04 Aug 2010 06:07: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.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Henning Rogge References: <4C528979.7010006@oracle.com> <201008040727.39245.henning.rogge@fkie.fraunhofer.de> <4C58FD6D.3050802@earthlink.net> <201008040756.04650.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <201008040756.04650.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5203ca4987d58e284d9dc9ebeec63157c4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.6.171.143 Cc: autoconf@ietf.org Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [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: Wed, 04 Aug 2010 13:07:19 -0000 Hello Henning, On 8/3/2010 10:55 PM, Henning Rogge wrote: > If you run a part of the routing protocol to connect the "host" to the MANET, > it's a router in my oppinion (Ripple would call it a leaf node for example). What if your host gets an address by running "autoconf.exe", which is not a routing program? > If the node just use DHCP or similar protocols to get it's address without > being modified to work with the MANET, it's no router (and don't need the > autoconf address model). What if the host does not? Or, do you mean to say that this discussion is a way to legislate that all hosts must use DHCP? > The autoconf model is NOT the only way for a host to get an address for > connection to a MANET. The autoconf model for getting addresses doesn't exist. I sure hope it isn't the only way to get an address. But suppose at some point there is an autoconf.exe. It should be a way for a host to get an address. Its connection to the MANET would, presumably allow it to use this address. Or, do you mean to say that "address allocation" == "connection"? > If you have a router with a policy that limits the routers functionality (in > terms of the routing protocol), you could just write a compact/optimized > version of the needed software part for it. main() { system ("get_address"); if (routing) fail(); /* My compact routing code */ } Am I a router? >>> It should be done on the routers (but MANETs can and have been run >>> with different address models), and it could be used for hosts closely >>> attached to a MANET, but it's not necessary to do so. >> >> What is "it"? > The autoconf address model should be used on routers (but you could use a > different one) and it (the address model) could be used on hosts attached to a > MANET, but it's not necessary to use the autoconf address model on hosts. It's necessary for hosts to adhere to the considerations detailed in the address model document. I'm not sure if this is the same as "using" it. >>> But in my opinion it is still better it's still better to restrict the >>> title as suggested in the WG meeting consensus that to make it too >>> generic. >> >> I can't imagine any non-political reason whatsoever for this. > If we do otherwise we could have the same problems. People would say "you > demand that any computer attached to your MANET use the autoconf address > model. But we have to use DHCP, so your address model is wrong." This is a political argument not based on the needs of the addressability, connectivity, or goals of making an ad hoc network. Insofar as you may be nonetheless correct, I begin to believe that I have zero insight into the technical goals of the discussion. > (I don't say they are right, but we will get people with strange comments on > the address model with both titles) Please tell me if my comments are "strange". Regards, Charlie P. From charles.perkins@earthlink.net Wed Aug 4 06:18: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 B2D243A6767 for ; Wed, 4 Aug 2010 06:18:18 -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 e-bD-dDS5waV for ; Wed, 4 Aug 2010 06:18:17 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 92D0A3A63C9 for ; Wed, 4 Aug 2010 06:18:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=retfwENvL9D+0B/lfGlPYo0wNqOH1frYnDoAJeenpq3EZeVMbvNhNydzD96udFUi; 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 [24.6.171.143] (helo=[192.168.1.107]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ogdrq-0000U5-H4; Wed, 04 Aug 2010 09:18:46 -0400 Message-ID: <4C596894.5050004@earthlink.net> Date: Wed, 04 Aug 2010 06:18:12 -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.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Teco Boot References: <4C528979.7010006@oracle.com> <4C58584D.2010604@earthlink.net> <379B3F32-224C-46C0-8599-913AD85A803E@inf-net.nl> In-Reply-To: <379B3F32-224C-46C0-8599-913AD85A803E@inf-net.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52c5e4e8962ff5c8bab16d1e088ecd93e4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.6.171.143 Cc: autoconf@ietf.org Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [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: Wed, 04 Aug 2010 13:18:18 -0000 Hello Teco, On 8/3/2010 11:48 PM, Teco Boot wrote: > What makes a node a router? (mentioned in meeting, maybe incomplete lsit) > > a) The device MAY forward packets. Even the case if it actually doesn't, > e.g. the topology is such that no packet is sent to it for forwarding. Many > OSses have a "Forwarding" config flag. When on, it is a router. This has > nothing to do with routing protocols. Check. > b) The device sends out a routing protocol packet. ... Check. > c) The device sends out an RA. Hosts MAY NOT do this. Check. ... > If a host uses tobe-RFC5889 and only uses a /128 prefix, and other nearby nodes > also use /128's, there is no connectivity. What about point-to-point links? > 1-hop neighbors can't know that the > host is reachable. What about point-to-point links? > I experienced this problem during maintenance or outage of > the routing protocol, I couldn't remotely repair. That is why I use another > addressing model, that doesn't has this shortcoming. It supports all types of > nodes. A big, big difference. I never experienced this with AODV, which could use all point-to-point links. > This is why I support the title change. I'm still mystified, unless (as Henning opines) we've strayed into the magical land of politics. Regards, Charlie P. From cjbc@it.uc3m.es Wed Aug 4 06: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 89EA93A6A62 for ; Wed, 4 Aug 2010 06:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZB1Q9H8u2Zm for ; Wed, 4 Aug 2010 06:30:56 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id EB7003A67B3 for ; Wed, 4 Aug 2010 06:30:54 -0700 (PDT) X-uc3m-safe: yes Received: from [192.168.0.10] (82.158.121.254.dyn.user.ono.com [82.158.121.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 9B58D8442EA; Wed, 4 Aug 2010 15:31:22 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <4C571E93.7050007@gmail.com> References: <4C571E93.7050007@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ZbenHQ7gYa1gIdyt+V/9" Organization: Universidad Carlos III de Madrid Date: Wed, 04 Aug 2010 15:27:37 +0200 Message-ID: <1280928457.2889.40.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17548.007 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 Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 13:31:02 -0000 --=-ZbenHQ7gYa1gIdyt+V/9 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Alex, On Mon, 2010-08-02 at 21:37 +0200, Alexandru Petrescu wrote: > Le 02/08/2010 18:55, Ulrich Herberg a =E9crit : > > Teco, > > > > On Sat, Jul 31, 2010 at 3:56 PM, Teco Boot wrote: > >> Fred, > >> > >> Do you mean DHCP relay can be used on a node, that request an > >> address for itself? > > > > I have tried that a while ago. It works with some limitations (see > > below). > > > >> > >> 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. > > > > Do you mean that a node is DHCP client and relay in the same time? > > That is not possible according to RFC3315, which says (i) in section > > 15.13 "clients MUST discard any received Relay-forward messages" and > > (ii) section 15.3 "servers and relay agents MUST discard any > > received Advertise messages". >=20 > Ah! This is seem to contradict something in MEXT context where > draft-ietf-mext-nemo-pd-05 proposes "This relay agent function is > co-located in the MR with the DHCPv6 client function (see Figure 2)." I don't think it contradicts it. As Fred mentioned in his e-mail: "client function would never see a Relay-forward, because that is generated by the relay function and sent to either the unicast address of a server or All-DHCP-Servers multicast." Thanks, Carlos >=20 > > Also, the relay would need to have a direct unicast connection to the > > central node or use other relaying mechanisms such as SMF (as you > > mentioned below), because multiple relaying is not really feasible in > > DHCPv6 itself: Relaying uses encapsulation, so packets would be > ^^^^^^^^^^^^^^^^ > Clarification: yes, relaying implies encapsulation when Relay relays to > another Relay, but when Relay to Server - it's non-encapsualted. >=20 > > encapsulated at every hop, quickly increasing overhead. And I also > > don't think that DHCP relaying allows duplicate packet detection. >=20 > Duplicate packet detection? What is it for? >=20 > Alex >=20 > >> 2b) If node is provisioned with DHCP server unicast address, it > >> could use that instead of All_DHCP_Servers. > > > > Sure, that is possible if a unicast routing protocol is used. > > > >> 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 of many neighbors. > > > > True. > > > >> Another drawback of 1: there is a timeout delay when there is no > >> relay or server at one hop. > > > > But I guess this timeout can be set dynamically? > > > >> > >> For 2a: the network needs multicast support. Could be SMF. > > > > Yes, that could be a possibility. > > > > > >> > >> For both 2a and 2b: a temporally used unicast address must be > >> routable. So this DHCP mechanism can only be used as a second > >> step, moving from the self-generated address to a centrally > >> managed address. > > > > Yes, that seems possible (but I have to re-read the DHCPv6 RFC after > > my vacations ;-) > > > > Ulrich > > > >> > >> Teco > >> > >> > >> > >> > >> Op 30 jul 2010, om 17:40 heeft Templin, Fred L het volgende > >> geschreven: > >> > >>> Teco, > >>> > >>>> -----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? > >>>> > >>>> 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. > >>> > >>> 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 > >>> > >>>> 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. > >>>> > >>>> > >>>> _______________________________________________ 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 > > >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-ZbenHQ7gYa1gIdyt+V/9 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) iEYEABECAAYFAkxZaskACgkQNdy6TdFwT2c71QCfX6gjXEmYLTkuM2S/v+fFoFHY EVAAoMFlUTUV9zjoPaG7OR93DXrZ4F/J =AGUI -----END PGP SIGNATURE----- --=-ZbenHQ7gYa1gIdyt+V/9-- From alexandru.petrescu@gmail.com Wed Aug 4 07:23: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 D65593A6892 for ; Wed, 4 Aug 2010 07:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.094, 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 7hFUQsmBEuJw for ; Wed, 4 Aug 2010 07:23:11 -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 66A383A63D3 for ; Wed, 4 Aug 2010 07:23: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 o74ENbfV027422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Aug 2010 16:23: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 o74ENbs3008211; Wed, 4 Aug 2010 16:23: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 o74ENac0027886; Wed, 4 Aug 2010 16:23:37 +0200 Message-ID: <4C5977E8.1070105@gmail.com> Date: Wed, 04 Aug 2010 16:23: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: cjbc@it.uc3m.es References: <4C571E93.7050007@gmail.com> <1280928457.2889.40.camel@acorde.it.uc3m.es> In-Reply-To: <1280928457.2889.40.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit 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: Wed, 04 Aug 2010 14:23:13 -0000 Le 04/08/2010 15:27, Carlos Jesús Bernardos Cano a écrit : > Hi Alex, > > On Mon, 2010-08-02 at 21:37 +0200, Alexandru Petrescu wrote: >> Le 02/08/2010 18:55, Ulrich Herberg a écrit : >>> Teco, >>> >>> On Sat, Jul 31, 2010 at 3:56 PM, Teco Boot wrote: >>>> Fred, >>>> >>>> Do you mean DHCP relay can be used on a node, that request an >>>> address for itself? >>> >>> I have tried that a while ago. It works with some limitations (see >>> below). >>> >>>> >>>> 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. >>> >>> Do you mean that a node is DHCP client and relay in the same time? >>> That is not possible according to RFC3315, which says (i) in section >>> 15.13 "clients MUST discard any received Relay-forward messages" and >>> (ii) section 15.3 "servers and relay agents MUST discard any >>> received Advertise messages". >> >> Ah! This is seem to contradict something in MEXT context where >> draft-ietf-mext-nemo-pd-05 proposes "This relay agent function is >> co-located in the MR with the DHCPv6 client function (see Figure 2)." > > I don't think it contradicts it. As Fred mentioned in his e-mail: > "client function would never see a Relay-forward, because that is > generated by the relay function and sent to either the unicast address > of a server or All-DHCP-Servers multicast." I guess that can be understood so, provided there being two DHCP processes: one Relay and one Client. Alex > > Thanks, > > Carlos > >> >>> Also, the relay would need to have a direct unicast connection to the >>> central node or use other relaying mechanisms such as SMF (as you >>> mentioned below), because multiple relaying is not really feasible in >>> DHCPv6 itself: Relaying uses encapsulation, so packets would be >> ^^^^^^^^^^^^^^^^ >> Clarification: yes, relaying implies encapsulation when Relay relays to >> another Relay, but when Relay to Server - it's non-encapsualted. >> >>> encapsulated at every hop, quickly increasing overhead. And I also >>> don't think that DHCP relaying allows duplicate packet detection. >> >> Duplicate packet detection? What is it for? >> >> Alex >> >>>> 2b) If node is provisioned with DHCP server unicast address, it >>>> could use that instead of All_DHCP_Servers. >>> >>> Sure, that is possible if a unicast routing protocol is used. >>> >>>> 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 of many neighbors. >>> >>> True. >>> >>>> Another drawback of 1: there is a timeout delay when there is no >>>> relay or server at one hop. >>> >>> But I guess this timeout can be set dynamically? >>> >>>> >>>> For 2a: the network needs multicast support. Could be SMF. >>> >>> Yes, that could be a possibility. >>> >>> >>>> >>>> For both 2a and 2b: a temporally used unicast address must be >>>> routable. So this DHCP mechanism can only be used as a second >>>> step, moving from the self-generated address to a centrally >>>> managed address. >>> >>> Yes, that seems possible (but I have to re-read the DHCPv6 RFC after >>> my vacations ;-) >>> >>> Ulrich >>> >>>> >>>> Teco >>>> >>>> >>>> >>>> >>>> Op 30 jul 2010, om 17:40 heeft Templin, Fred L het volgende >>>> geschreven: >>>> >>>>> Teco, >>>>> >>>>>> -----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? >>>>>> >>>>>> 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. >>>>> >>>>> 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 >>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> _______________________________________________ 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 >>> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > From teco@inf-net.nl Wed Aug 4 08:39: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 3D37A3A67B2 for ; Wed, 4 Aug 2010 08:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 SJmf0XSFuwsZ for ; Wed, 4 Aug 2010 08:39:39 -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 F311F3A6C04 for ; Wed, 4 Aug 2010 08:37:50 -0700 (PDT) Received: by ewy22 with SMTP id 22so2290462ewy.31 for ; Wed, 04 Aug 2010 08:37:05 -0700 (PDT) Received: by 10.213.25.143 with SMTP id z15mr2143298ebb.6.1280936224973; Wed, 04 Aug 2010 08:37:04 -0700 (PDT) Received: from [192.168.2.197] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id v59sm12976144eeh.22.2010.08.04.08.37.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Aug 2010 08:37:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4C596894.5050004@earthlink.net> Date: Wed, 4 Aug 2010 17:37:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <28D40890-32BE-4925-94DD-049E54B71B43@inf-net.nl> References: <4C528979.7010006@oracle.com> <4C58584D.2010604@earthlink.net> <379B3F32-224C-46C0-8599-913AD85A803E@inf-net.nl> <4C596894.5050004@earthlink.net> To: Charles E. Perkins X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [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: Wed, 04 Aug 2010 15:39:42 -0000 Op 4 aug 2010, om 15:18 heeft Charles E. Perkins het volgende = geschreven: >> If a host uses tobe-RFC5889 and only uses a /128 prefix, and other = nearby nodes >> also use /128's, there is no connectivity. >=20 > What about point-to-point links? Even then, a host would not use this link if it is not mentioned in the = routing table. You could say a host with one p2p link could set the default gateway = automatically. But how can the opposite node learn the topology? If it is a single-homed host, this small setup of only two hosts would = work. Any other case results in nothing. >> 1-hop neighbors can't know that the >> host is reachable. >=20 > What about point-to-point links? >=20 >> I experienced this problem during maintenance or outage of >> the routing protocol, I couldn't remotely repair. That is why I use = another >> addressing model, that doesn't has this shortcoming. It supports all = types of >> nodes. A big, big difference. >=20 > I never experienced this with AODV, which > could use all point-to-point links. So you stop AODV, and AODV still operates??? Can't be. >> This is why I support the title change. >=20 > I'm still mystified, unless (as Henning opines) > we've strayed into the magical land of politics. A node that runs AODV is a router, because AODV is a routing protocol. More detailed answer: in AODV, the subnet router is responsible for=20 reachability for the subnet. In our addressing model, with /128 subnet,=20= there is only one node in the subnet, that is the subnet router. So the document applies only to routers in ad hoc networks. Demystified ? We can discuss wrongly used _host_ in HIP, DHCP, Host Route etc., if = time permits. Not for today. Teco From charles.perkins@earthlink.net Wed Aug 4 09:17: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 277543A6A27 for ; Wed, 4 Aug 2010 09:17:04 -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 7AG56wXxWyMk for ; Wed, 4 Aug 2010 09:17:02 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id DAFAD3A6961 for ; Wed, 4 Aug 2010 09:16:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=smavWyG+gZj7ZHSCkUNDMHuBTcmkVpSLuW/ei85ga1DSVJ33Kq7uJJxhEsixIMd+; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.159]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Oggei-0001wP-LD; Wed, 04 Aug 2010 12:17:24 -0400 Message-ID: <4C599292.9090507@earthlink.net> Date: Wed, 04 Aug 2010 09:17:22 -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.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Teco Boot References: <4C528979.7010006@oracle.com> <4C58584D.2010604@earthlink.net> <379B3F32-224C-46C0-8599-913AD85A803E@inf-net.nl> <4C596894.5050004@earthlink.net> <28D40890-32BE-4925-94DD-049E54B71B43@inf-net.nl> In-Reply-To: <28D40890-32BE-4925-94DD-049E54B71B43@inf-net.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5203a4cc69b0abe4abb360524137592795350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [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: Wed, 04 Aug 2010 16:17:04 -0000 Hello Teco, Comments below: On 8/4/2010 8:37 AM, Teco Boot wrote: >> What about point-to-point links? > > Even then, a host would not use this link if it is not mentioned in the routing table. Every host has a routing table. Do you say otherwise? If so, we have no vocabulary. IPv6 hosts can even have multiple routers in their routing table. > You could say a host with one p2p link could set the default gateway automatically. > But how can the opposite node learn the topology? Are we getting into solution space? I didn't even say that a host had to have a default router. > If it is a single-homed host, this small setup of only two hosts would work. > Any other case results in nothing. Without presenting solutions, I cannot convince you otherwise. For this discussion, suffice it to say that I am 100% certain your statement is incorrect. >> I never experienced this with AODV, which >> could use all point-to-point links. > > So you stop AODV, and AODV still operates??? > Can't be. I'm sorry, but I cannot understand what you meant. Anyway, I wouldn't have "stopped AODV" unless I broadcast a directive to all nodes that they must cease operation. >> I'm still mystified, unless (as Henning opines) >> we've strayed into the magical land of politics. > > A node that runs AODV is a router, because AODV is a routing protocol. I mentioned AODV as a counterexample to your statement about the infeasibility of running a network over /128 links. It does not mean that I say "AODV" to every question you might ask. In particular, I claim that hosts in an ad hoc network often must adhere to the developed address model. Of course they don't run AODV if they're not routers. > More detailed answer: in AODV, the subnet router is responsible for > reachability for the subnet. Where's the subnet? > In our addressing model, with /128 subnet, > there is only one node in the subnet, that is the subnet router. > So the document applies only to routers in ad hoc networks. Is there some weird magic that requires every /128 subnet to have an AODV subnet router? If not, then your conclusion is false. > Demystified ? Actually, I am further mystified -- especially to think that point-to-point routes get so little respect in this forum, and that anyone might claim that hosts don't have routing tables. Do you claim that any program that utilizes #include is a router? > We can discuss wrongly used _host_ in HIP, DHCP, Host Route etc., if time permits. > Not for today. Sounds like fun. Regards, Charlie P. From teco@inf-net.nl Wed Aug 4 11:11: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 AB8E03A6A49 for ; Wed, 4 Aug 2010 11:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_21=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 7u7fZOy8eLKl for ; Wed, 4 Aug 2010 11:11:24 -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 59C4C3A6A74 for ; Wed, 4 Aug 2010 11:11:14 -0700 (PDT) Received: by eyb7 with SMTP id 7so2351153eyb.31 for ; Wed, 04 Aug 2010 11:11:39 -0700 (PDT) Received: by 10.213.30.15 with SMTP id s15mr6942831ebc.48.1280945499787; Wed, 04 Aug 2010 11:11:39 -0700 (PDT) Received: from [192.168.2.197] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id a48sm13198982eei.12.2010.08.04.11.11.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Aug 2010 11:11:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4C599292.9090507@earthlink.net> Date: Wed, 4 Aug 2010 20:11:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C528979.7010006@oracle.com> <4C58584D.2010604@earthlink.net> <379B3F32-224C-46C0-8599-913AD85A803E@inf-net.nl> <4C596894.5050004@earthlink.net> <28D40890-32BE-4925-94DD-049E54B71B43@inf-net.nl> <4C599292.9090507@earthlink.net> To: "Charles E. Perkins" X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [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: Wed, 04 Aug 2010 18:11:32 -0000 Hi Charlie, Op 4 aug 2010, om 18:17 heeft Charles E. Perkins het volgende = geschreven: > Hello Teco, >=20 > Comments below: >=20 > On 8/4/2010 8:37 AM, Teco Boot wrote: >=20 >>> What about point-to-point links? >>=20 >> Even then, a host would not use this link if it is not mentioned in = the routing table. >=20 > Every host has a routing table. Do you say > otherwise? If so, we have no vocabulary. > IPv6 hosts can even have multiple routers > in their routing table. Check. >> You could say a host with one p2p link could set the default gateway = automatically. >> But how can the opposite node learn the topology? >=20 > Are we getting into solution space? No. We are getting out-of-scope. The document is about link with undetermined characteristics. P2P links are not in that category. > I didn't even say that a host had to have > a default router. Then, that host does not send packets. (Assuming empty routing table and /128 (v6) or /32 (v4) address prefix).=20= (Host learning more specific routes via p2p links could be exception) >> If it is a single-homed host, this small setup of only two hosts = would work. >> Any other case results in nothing. >=20 > Without presenting solutions, I cannot > convince you otherwise. For this discussion, > suffice it to say that I am 100% certain your > statement is incorrect. I think I would call your solution topology exchange, thus routing. Just guessing, of course. >>> I never experienced this with AODV, which >>> could use all point-to-point links. >>=20 >> So you stop AODV, and AODV still operates??? >> Can't be. >=20 > I'm sorry, but I cannot understand what > you meant. Anyway, I wouldn't have > "stopped AODV" unless I broadcast a > directive to all nodes that they must > cease operation. It is not "all or nothing". A router could stop acting as router. Think of maintenance, bugs etc. Sure, before quitting, the router may advertise it's routing protocol=20 is gonna die. I don't see why routing protocols on other nodes would=20 cease operation. A bit too DOS friendly, I say. >>> I'm still mystified, unless (as Henning opines) >>> we've strayed into the magical land of politics. >>=20 >> A node that runs AODV is a router, because AODV is a routing = protocol. >=20 > I mentioned AODV as a counterexample to your > statement about the infeasibility of running > a network over /128 links. It does not mean > that I say "AODV" to every question you might > ask. Check. > In particular, I claim that hosts in an ad hoc > network often must adhere to the developed > address model. Of course they don't run AODV > if they're not routers. OK, now were are there. How can the routers know the host is there? When the host belongs to a subnet, with a "subnet router" as gateway to the rest of the network, I am OK. But this cannot happen, with the current addressing model.=20 >> More detailed answer: in AODV, the subnet router is responsible for >> reachability for the subnet. >=20 > Where's the subnet? Somewhere in the network. Optionally with hosts. And a router, = connecting the subnet to the rest of the network. >> In our addressing model, with /128 subnet, >> there is only one node in the subnet, that is the subnet router. >> So the document applies only to routers in ad hoc networks. >=20 > Is there some weird magic that requires every > /128 subnet to have an AODV subnet router? > If not, then your conclusion is false. There is no magic. Point is: with /128, there are no hosts. Not on links with undetermined characteristics. >> Demystified ? >=20 > Actually, I am further mystified -- especially > to think that point-to-point routes get so little > respect in this forum, and that anyone might > claim that hosts don't have routing tables. 1) P2P is out-of-scope, as we assume nothing for our links. 2) hosts have routing tables. > Do you claim that any program that utilizes > #include is a router? No, not at all. But if this piece of code sends out a routing packet, then yes, for = sure. With IPv6, we could support hosts in our links with undetermined=20 characteristics. Router sends RA with PIO (/64), with L-bit is 0. Nearby hosts can configure own address (SLAAC) and use the router as gateway. This only works for satellite hosts. This model is=20 suggested multiple times (Templin, in't Velt, others). There was rough consensus not to support this addressing model. Teco >> We can discuss wrongly used _host_ in HIP, DHCP, Host Route etc., if = time permits. >> Not for today. >=20 > Sounds like fun. >=20 > Regards, > Charlie P. From charles.perkins@earthlink.net Wed Aug 4 12:37: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 83B823A6915 for ; Wed, 4 Aug 2010 12:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, J_CHICKENPOX_21=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 9gf48O7uxgMc for ; Wed, 4 Aug 2010 12:37:40 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 560C33A693F for ; Wed, 4 Aug 2010 12:37:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=JvSUL5aK0qWFAVMmrVi2ACSRZQYBkziQo1InimILds/td2GqXJlq0RN82ns5ts0m; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.159]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ogjmy-0001Ag-EX; Wed, 04 Aug 2010 15:38:09 -0400 Message-ID: <4C59C19B.4070101@earthlink.net> Date: Wed, 04 Aug 2010 12:38:03 -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.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Teco Boot References: <4C528979.7010006@oracle.com> <4C58584D.2010604@earthlink.net> <379B3F32-224C-46C0-8599-913AD85A803E@inf-net.nl> <4C596894.5050004@earthlink.net> <28D40890-32BE-4925-94DD-049E54B71B43@inf-net.nl> <4C599292.9090507@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52847c8b393ddc2769ad6ab7484e5b4d8e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [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: Wed, 04 Aug 2010 19:37:41 -0000 Hello Teco, On 8/4/2010 11:11 AM, Teco Boot wrote: >>> You could say a host with one p2p link could set the default gateway automatically. >>> But how can the opposite node learn the topology? >> >> Are we getting into solution space? > > No. We are getting out-of-scope. > The document is about link with undetermined characteristics. > P2P links are not in that category. I definitely don't agree with this conclusion. The links with undetermined characteristics can support time-bounded P2P links. There is no reason to declare P2P links out of scope. >> I didn't even say that a host had to have >> a default router. > > Then, that host does not send packets. > (Assuming empty routing table and /128 (v6) or /32 (v4) address prefix). Bad assumption! > (Host learning more specific routes via p2p links could be exception) This isn't necessary. Shall I make an example? One trivial example would be to just run in promiscuous mode, listen for addresses, and pretend that some neighbor is a router. I have other examples that are more normal :-) >> Without presenting solutions, I cannot >> convince you otherwise. For this discussion, >> suffice it to say that I am 100% certain your >> statement is incorrect. > > I think I would call your solution topology exchange, thus routing. > Just guessing, of course. I am not claiming that the other solutions are mine -- but there are numerous examples in the literature. As far as a host is concerned, topology exchange isn't necessary -- unless you call the simple fact of link establishment to be "topology exchange". And then our discussion fails, because we have so little vocabulary. >> In particular, I claim that hosts in an ad hoc >> network often must adhere to the developed >> address model. Of course they don't run AODV >> if they're not routers. > > OK, now were are there. How can the routers know the host is there? If the host transmits a packet, the routers can know. > When the host belongs to a subnet, with a "subnet router" as gateway > to the rest of the network, I am OK. But this cannot happen, with the > current addressing model. Why not? If I remember correctly, the current addressing model does not legislate that all links have to be /128. It just says that SOME links appear to be /128, so that without additional information, protocols may not make too many assumptions about the connectivity properties of the link. As many have pointed out, this world is not so black and white. >>> More detailed answer: in AODV, the subnet router is responsible for >>> reachability for the subnet. >> >> Where's the subnet? > > Somewhere in the network. Optionally with hosts. And a router, connecting > the subnet to the rest of the network. Optionally. And, a node can forward packets based only on P2P routes. Such a node is, I claim, a router. No subnets are needed. >> Is there some weird magic that requires every >> /128 subnet to have an AODV subnet router? >> If not, then your conclusion is false. > > There is no magic. > Point is: with /128, there are no hosts. Not on links with undetermined > characteristics. Teco -- this is just wrong. Just because a network interface has undetermined properties doesn't mean that the host utilizing that network interface can't transmit or receive packets. Otherwise, what would be the point of powering the interface? >> Actually, I am further mystified -- especially >> to think that point-to-point routes get so little >> respect in this forum, and that anyone might >> claim that hosts don't have routing tables. > > 1) P2P is out-of-scope, as we assume nothing for our links. We do assume that hosts can transmit packets. At least I do. Hosts that can transmit packets can support P2P links. Why not?? > 2) hosts have routing tables. Well, I'm glad you cleared that up. > With IPv6, we could support hosts in our links with undetermined > characteristics. Router sends RA with PIO (/64), with L-bit is 0. > Nearby hosts can configure own address (SLAAC) and use the router > as gateway. This only works for satellite hosts. This model is > suggested multiple times (Templin, in't Velt, others). > There was rough consensus not to support this addressing model. What if the router sends out RA with /128, and hosts receiving the RA configure P2P route table entries to the router? That would work. But it's not the only way, of course. Regards, Charlie P. From teco@inf-net.nl Thu Aug 5 01:27: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 7A1C93A682A for ; Thu, 5 Aug 2010 01:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_21=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 gvPCbED56Gjw for ; Thu, 5 Aug 2010 01:27:01 -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 83AC33A68CF for ; Thu, 5 Aug 2010 01:27:00 -0700 (PDT) Received: by ewy22 with SMTP id 22so2564706ewy.31 for ; Thu, 05 Aug 2010 01:27:30 -0700 (PDT) Received: by 10.213.12.196 with SMTP id y4mr2921173eby.61.1280996850211; Thu, 05 Aug 2010 01:27:30 -0700 (PDT) Received: from [192.168.2.197] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id a48sm14335147eei.19.2010.08.05.01.27.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Aug 2010 01:27:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4C59C19B.4070101@earthlink.net> Date: Thu, 5 Aug 2010 10:27:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0E35FDFA-F73F-4005-8354-87ECB7A4E12D@inf-net.nl> References: <4C528979.7010006@oracle.com> <4C58584D.2010604@earthlink.net> <379B3F32-224C-46C0-8599-913AD85A803E@inf-net.nl> <4C596894.5050004@earthlink.net> <28D40890-32BE-4925-94DD-049E54B71B43@inf-net.nl> <4C599292.9090507@earthlink.net> <4C59C19B.4070101@earthlink.net> To: Charles E. Perkins X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [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, 05 Aug 2010 08:27:02 -0000 Hi Charlie, Op 4 aug 2010, om 21:38 heeft Charles E. Perkins het volgende = geschreven: >=20 > Hello Teco, >=20 > On 8/4/2010 11:11 AM, Teco Boot wrote: >=20 >>>> You could say a host with one p2p link could set the default = gateway automatically. >>>> But how can the opposite node learn the topology? >>>=20 >>> Are we getting into solution space? >>=20 >> No. We are getting out-of-scope. >> The document is about link with undetermined characteristics. >> P2P links are not in that category. >=20 > I definitely don't agree with this conclusion. > The links with undetermined characteristics can > support time-bounded P2P links. There is no > reason to declare P2P links out of scope. At least P2P is a special case. Has this to do with our discussion? Can you come up with something other than p2p? >>> I didn't even say that a host had to have >>> a default router. >>=20 >> Then, that host does not send packets. >> (Assuming empty routing table and /128 (v6) or /32 (v4) address = prefix). >=20 > Bad assumption! Then, what is in the routing table? And what mechanism takes care? If it is a routing protocol, the node is router. It it learns an on-link prefix, it is not using the=20 proposed addressing model. If it learns an off-link prefix, and use the provider of=20 this prefix (router sending RA) as default gateway, I am OK. If it learns other routing info, I am also OK. I still wonder how two hosts with off-link prefixes on same link can=20 communicate. >> (Host learning more specific routes via p2p links could be exception) >=20 > This isn't necessary. Shall I make an example? This may help. > One trivial example would be to just run in > promiscuous mode, listen for addresses, and > pretend that some neighbor is a router. Data plane populating routing table ?? What about uni-directional link test ?? > I have other examples that are more normal :-) Please do so, previous one frightened me.=20 >>> Without presenting solutions, I cannot >>> convince you otherwise. For this discussion, >>> suffice it to say that I am 100% certain your >>> statement is incorrect. >>=20 >> I think I would call your solution topology exchange, thus routing. >> Just guessing, of course. >=20 > I am not claiming that the other solutions are > mine -- but there are numerous examples in the > literature. Refs are OK. Or describe one. > As far as a host is concerned, topology > exchange isn't necessary -- unless you call > the simple fact of link establishment to be > "topology exchange". And then our discussion > fails, because we have so little vocabulary. We may end up in discussing the width of the grey zone between=20 host and router, and the exact borderlines. We agreed on three indications for classifying node a router. Now on indications for hosts: Oldie, RFC1122: (c) Routing complexity should be in the gateways. Routing is a complex and difficult problem, and ought to be performed by the gateways, not the hosts. An important objective is to insulate host software from changes caused by the inevitable evolution of the Internet routing architecture And: The host IP layer has two basic functions: (1) choose the "next hop" gateway or host for outgoing IP datagrams and (2) reassemble incoming IP datagrams.=20 And the whole 3.3.1 section. RFC5942 is also relevant. Now I say: there are protocols for host-router relations, so host will=20= know on-line prefix and default gateway, or more specific routes. But what about getting knowledge on routers for links to hosts, where=20 hosts have off-link prefixes? If there are protocols for such (and done = in=20 a clean fashion), I call it routing. This, because hosts do not = advertise=20 themselves to routers as part of the topology. This is where routing=20 complexity starts. Complexity is increased with RFC5942, with our RFC5889 in mind. We don't configure on-link prefixes on our interfaces. RFC5942 Host Behavior (3.1): In IPv6, an address is on-link (with respect to a specific link), if the address has been assigned to an interface attached to that link. So one could say we do not comply to RFC5942. Luckily, RFC5942 is for=20 hosts. >>> In particular, I claim that hosts in an ad hoc >>> network often must adhere to the developed >>> address model. Of course they don't run AODV >>> if they're not routers. >>=20 >> OK, now were are there. How can the routers know the host is there? >=20 > If the host transmits a packet, the routers can know. IMHO mix data plane and routing control plane is bad. >> When the host belongs to a subnet, with a "subnet router" as gateway >> to the rest of the network, I am OK. But this cannot happen, with the >> current addressing model. >=20 > Why not? >=20 > If I remember correctly, the current addressing model does > not legislate that all links have to be /128. It just > says that SOME links appear to be /128, so that without > additional information, protocols may not make too many > assumptions about the connectivity properties of the link. It says no on-link subnet prefix is configured. As a result, hosts are not supported. Some mechanism is needed making the router aware that other nodes are reachable via this interface. I call this routing. > As many have pointed out, this world is not so black and > white. Indeed. But it is quite dark for hosts, using this addressing model. Routing enlighten. >>>> More detailed answer: in AODV, the subnet router is responsible for >>>> reachability for the subnet. >>>=20 >>> Where's the subnet? >>=20 >> Somewhere in the network. Optionally with hosts. And a router, = connecting >> the subnet to the rest of the network. >=20 > Optionally. And, a node can forward packets > based only on P2P routes. Such a node is, > I claim, a router. No subnets are needed. Back to subject: addressing model is for routers. You disagreed with title change. I expect some argumentation. I did't see such. >>> Is there some weird magic that requires every >>> /128 subnet to have an AODV subnet router? >>> If not, then your conclusion is false. >>=20 >> There is no magic. >> Point is: with /128, there are no hosts. Not on links with = undetermined >> characteristics. >=20 > Teco -- this is just wrong. >=20 > Just because a network interface has undetermined > properties doesn't mean that the host utilizing > that network interface can't transmit or receive > packets. Otherwise, what would be the point of > powering the interface? You miss the point. When some say routers, they don't intent the node MUST forward packets. The intention is that routing protocols are involved getting the routing tables populated. And bypass limitations for hosts. This is allowed, because=20 routers understand the complexity. >>> Actually, I am further mystified -- especially >>> to think that point-to-point routes get so little >>> respect in this forum, and that anyone might >>> claim that hosts don't have routing tables. >>=20 >> 1) P2P is out-of-scope, as we assume nothing for our links. >=20 > We do assume that hosts can transmit packets. > At least I do. Hosts that can transmit packets > can support P2P links. Why not?? We need populated routing tables getting packets around. Without on-link prefixes, hosts have difficulties. >> 2) hosts have routing tables. >=20 > Well, I'm glad you cleared that up. >=20 >=20 >> With IPv6, we could support hosts in our links with undetermined >> characteristics. Router sends RA with PIO (/64), with L-bit is 0. >> Nearby hosts can configure own address (SLAAC) and use the router >> as gateway. This only works for satellite hosts. This model is >> suggested multiple times (Templin, in't Velt, others). >> There was rough consensus not to support this addressing model. >=20 > What if the router sends out RA with /128, and hosts > receiving the RA configure P2P route table entries to > the router? That would work. Maybe. Any valid received RA info is reflected in default router list. But how can a host without on-link addresses populate the router=20 routing table? Regards, Teco > But it's not the only way, of course. >=20 > Regards, > Charlie P. From henning.rogge@fkie.fraunhofer.de Thu Aug 5 01:38: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 226FC3A6A1B for ; Thu, 5 Aug 2010 01:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=-0.949, 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 qJ1L7ZUFuMm2 for ; Thu, 5 Aug 2010 01:38:38 -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 09D0C3A6803 for ; Thu, 5 Aug 2010 01:38: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 1Ogvyk-0001ry-JM; Thu, 05 Aug 2010 10:39:06 +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 1Ogvyk-00049z-Av; Thu, 05 Aug 2010 10:39:06 +0200 From: Henning Rogge To: "Charles E. Perkins" Date: Thu, 5 Aug 2010 10:38:57 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-24-generic; KDE/4.4.5; i686; ; ) References: <4C528979.7010006@oracle.com> <201008040756.04650.henning.rogge@fkie.fraunhofer.de> <4C596602.1060308@earthlink.net> In-Reply-To: <4C596602.1060308@earthlink.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3038014.DXJvR9nlCd"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201008051039.03011.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11501/Thu Aug 5 07:36:49 2010) by mailguard.fgan.de X-Scan-Signature: b17092e937cef22d8bf42b2c04946c57 Cc: autoconf@ietf.org Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [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, 05 Aug 2010 08:38:40 -0000 --nextPart3038014.DXJvR9nlCd Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Wed August 4 2010 15:07:14 Charles E. Perkins wrote: > Hello Henning, >=20 > On 8/3/2010 10:55 PM, Henning Rogge wrote: > > If you run a part of the routing protocol to connect the "host" to the > > MANET, it's a router in my oppinion (Ripple would call it a leaf node > > for example). >=20 > What if your host gets an address by running > "autoconf.exe", which is not a routing program? Does your host set up a route towards the next router and maintains it if t= he=20 topology data from the router changes ? If yes I would say it's a primitive= =20 router too. If no, it's not. > > If the node just use DHCP or similar protocols to get it's address > > without being modified to work with the MANET, it's no router (and don't > > need the autoconf address model). >=20 > What if the host does not? Or, do you mean to say > that this discussion is a way to legislate that all > hosts must use DHCP? I don't think I ever said this. I just presented an example that the addres= s=20 model is not necessary for running a node in a MANET that use the autoconf= =20 address model. Yes, you CAN use it... but you don't need to. > > The autoconf model is NOT the only way for a host to get an address for > > connection to a MANET. >=20 > The autoconf model for getting addresses doesn't exist. > I sure hope it isn't the only way to get an address. >=20 > But suppose at some point there is an autoconf.exe. > It should be a way for a host to get an address. > Its connection to the MANET would, presumably allow > it to use this address. Or, do you mean to say that > "address allocation" =3D=3D "connection"? I don't see any reason why an autoconfiguration protocol developed by this= =20 group would only run on interfaces of routers. > > If you have a router with a policy that limits the routers functionality > > (in terms of the routing protocol), you could just write a > > compact/optimized version of the needed software part for it. >=20 > main() > { > system ("get_address"); > if (routing) fail(); /* My compact routing code */ > } >=20 > Am I a router? I don't see any routing code of a routing protocol. But I don't see your=20 problem too. > >>> It should be done on the routers (but MANETs can and have been run > >>> with different address models), and it could be used for hosts closely > >>> attached to a MANET, but it's not necessary to do so. > >>=20 > >> What is "it"? > >=20 > > The autoconf address model should be used on routers (but you could use= a > > different one) and it (the address model) could be used on hosts attach= ed > > to a MANET, but it's not necessary to use the autoconf address model on > > hosts. >=20 > It's necessary for hosts to adhere to the > considerations detailed in the address model > document. I'm not sure if this is the same > as "using" it. It might be necessary, depending on what software the host is running. > >>> But in my opinion it is still better it's still better to restrict the > >>> title as suggested in the WG meeting consensus that to make it too > >>> generic. > >>=20 > >> I can't imagine any non-political reason whatsoever for this. > >=20 > > If we do otherwise we could have the same problems. People would say "y= ou > > demand that any computer attached to your MANET use the autoconf address > > model. But we have to use DHCP, so your address model is wrong." >=20 > This is a political argument not based on the needs > of the addressability, connectivity, or goals of > making an ad hoc network. Insofar as you may be > nonetheless correct, I begin to believe that I have > zero insight into the technical goals of the discussion. >=20 > > (I don't say they are right, but we will get people with strange commen= ts > > on the address model with both titles) >=20 > Please tell me if my comments are "strange". I think the problem you stated is that people can say "the title says it's= =20 only for routers, so it is not enough for my usecase and I need something=20 different". If we not change the title we might get "the title says it's for all nodes,= =20 but I cannot force my users to install a special interface configuration on= =20 their smartphones, so I need something different." There are nodes in MANET that are a grey area between host and router. Beca= use=20 of this we cannot make a clear statement on what nodes the autoconf address= =20 model should be used. Most of the WG seems to think it's better to restrict the scope a little bi= t=20 more and let people use it for other things than the defined scope if they= =20 think it's right (at least that's how I understand the consensus of the=20 group). 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 --nextPart3038014.DXJvR9nlCd 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) iEYEABECAAYFAkxaeKIACgkQRIfGfFXsz+BZSwCfbIlcLs8DwfiVHF19SI27inIi RXsAnA1VdFrRyBLyXvujat20jw5KJUGo =eikQ -----END PGP SIGNATURE----- --nextPart3038014.DXJvR9nlCd-- From Chris.Dearlove@baesystems.com Thu Aug 5 01:51: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 EE8BD3A6A9F for ; Thu, 5 Aug 2010 01:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.773 X-Spam-Level: X-Spam-Status: No, score=-6.773 tagged_above=-999 required=5 tests=[AWL=-0.174, 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 1vsh0eVVPCDe for ; Thu, 5 Aug 2010 01:51:11 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 27BAB3A6829 for ; Thu, 5 Aug 2010 01:51:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,320,1278284400"; d="scan'208";a="80313044" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 05 Aug 2010 09:51:40 +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 o758pdei017792; Thu, 5 Aug 2010 09:51:40 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Aug 2010 09:51:39 +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, 5 Aug 2010 09:51:13 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [Was: RFC 5889) thread-index: AcsyoM8Fzb1XfR13RxuXNahMedRmGAB2cAAA References: <4C528979.7010006@oracle.com> From: "Dearlove, Christopher (UK)" To: "Ryuji Wakikawa" , X-OriginalArrivalTime: 05 Aug 2010 08:51:39.0718 (UTC) FILETIME=[6B5EAE60:01CB347B] Cc: Autoconf Chairs , Ralph Droms Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [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, 05 Aug 2010 08:51:13 -0000 This looks slightly different from the last set I saw. But I haven't checked. I really don't want us to hold things up any more. But mandating EUI-64 under the circumstances noted is I think wrong, and doubly wrong as what is supposed to be an AUTH-48 error correction, not a revisit the WG and change things process (and are the IESG now going to demand to re-confirm the document also?) Ignoring the procedural issues, I could live with changing that "must" to "may" (I think even "should" is too strong). Or dropping that (last sugggested new) sentence. -- 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 Ryuji Wakikawa Sent: 03 August 2010 01:14 To: autoconf@ietf.org autoconf@ietf.org Cc: Autoconf Chairs; Ralph Droms Subject: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [Was: RFC 5889) *** 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. Hello all, At the IETF78 meeting, we had the rough consensus to adapt the Erik's modification for RFC5889 in the room. To confirm our consensus on the list, we ask the WG consensus call for adaption of Erik's modification for RFC5889. The detailed modifications can be found at the attached email below. Thanks Erik. Please vote for your opinion before "Aug 9th 12:00PM (PST)". If you have any objections, please give us clear reason and propose your text. thanks in advance, Thomas, ryuji Begin forwarded message: > From: Erik Nordmark > Date: 2010/07/30 01:12:41GMT-07:00 > To: autoconf@ietf.org > Subject: Re: [Autoconf] Forgot one [Was: RFC 5889 > > > 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. > > --- > _______________________________________________ > 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 alexandru.petrescu@gmail.com Thu Aug 5 02:21: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 0FF253A6AEE for ; Thu, 5 Aug 2010 02:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.086, 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 aqEBiDUv0LMK for ; Thu, 5 Aug 2010 02:21:08 -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 4F9B93A6ADF for ; Thu, 5 Aug 2010 02:21: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 o759LcLx005503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 5 Aug 2010 11:21:38 +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 o759Lb5d025981 for ; Thu, 5 Aug 2010 11:21: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 o759Lbsg016682 for ; Thu, 5 Aug 2010 11:21:37 +0200 Message-ID: <4C5A82A1.9000806@gmail.com> Date: Thu, 05 Aug 2010 11:21:37 +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: <4C528979.7010006@oracle.com> <201008040756.04650.henning.rogge@fkie.fraunhofer.de> <4C596602.1060308@earthlink.net> <201008051039.03011.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <201008051039.03011.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Autoconf] what's a router (was: WC consensus call for RFC5889 modifications ) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 09:21:10 -0000 Le 05/08/2010 10:38, Henning Rogge a écrit : > On Wed August 4 2010 15:07:14 Charles E. Perkins wrote: >> Hello Henning, >> >> On 8/3/2010 10:55 PM, Henning Rogge wrote: >>> If you run a part of the routing protocol to connect the "host" to the >>> MANET, it's a router in my oppinion (Ripple would call it a leaf node >>> for example). >> >> What if your host gets an address by running >> "autoconf.exe", which is not a routing program? > > Does your host set up a route towards the next router and maintains it if the > topology data from the router changes ? If yes I would say it's a primitive > router too. If no, it's not. To me a router is a device and its software doing this: - has a routing table called such. - does longest-prefix match algorithm to search in it. This operation is not specified (no RFC) but it is there everywhere in every router, thanks BSD. - includes that route.h I believe as CP said. - has multiple interfaces. In a sense every other host (my Windows PC) is a router because it does all these things. My PDA, my cell phone, are all routers. From this perspective, it is difficult to define what a Host is because everything seems to be a router to me - once it's connected to the Internet it is a router. A supercomputer is a router too, though it won't route as a DFZ 192-processor router would route. Alex > >>> If the node just use DHCP or similar protocols to get it's address >>> without being modified to work with the MANET, it's no router (and don't >>> need the autoconf address model). >> >> What if the host does not? Or, do you mean to say >> that this discussion is a way to legislate that all >> hosts must use DHCP? > > I don't think I ever said this. I just presented an example that the address > model is not necessary for running a node in a MANET that use the autoconf > address model. > > Yes, you CAN use it... but you don't need to. > >>> The autoconf model is NOT the only way for a host to get an address for >>> connection to a MANET. >> >> The autoconf model for getting addresses doesn't exist. >> I sure hope it isn't the only way to get an address. >> >> But suppose at some point there is an autoconf.exe. >> It should be a way for a host to get an address. >> Its connection to the MANET would, presumably allow >> it to use this address. Or, do you mean to say that >> "address allocation" == "connection"? > I don't see any reason why an autoconfiguration protocol developed by this > group would only run on interfaces of routers. > >>> If you have a router with a policy that limits the routers functionality >>> (in terms of the routing protocol), you could just write a >>> compact/optimized version of the needed software part for it. >> >> main() >> { >> system ("get_address"); >> if (routing) fail(); /* My compact routing code */ >> } >> >> Am I a router? > I don't see any routing code of a routing protocol. But I don't see your > problem too. > >>>>> It should be done on the routers (but MANETs can and have been run >>>>> with different address models), and it could be used for hosts closely >>>>> attached to a MANET, but it's not necessary to do so. >>>> >>>> What is "it"? >>> >>> The autoconf address model should be used on routers (but you could use a >>> different one) and it (the address model) could be used on hosts attached >>> to a MANET, but it's not necessary to use the autoconf address model on >>> hosts. >> >> It's necessary for hosts to adhere to the >> considerations detailed in the address model >> document. I'm not sure if this is the same >> as "using" it. > It might be necessary, depending on what software the host is running. > >>>>> But in my opinion it is still better it's still better to restrict the >>>>> title as suggested in the WG meeting consensus that to make it too >>>>> generic. >>>> >>>> I can't imagine any non-political reason whatsoever for this. >>> >>> If we do otherwise we could have the same problems. People would say "you >>> demand that any computer attached to your MANET use the autoconf address >>> model. But we have to use DHCP, so your address model is wrong." >> >> This is a political argument not based on the needs >> of the addressability, connectivity, or goals of >> making an ad hoc network. Insofar as you may be >> nonetheless correct, I begin to believe that I have >> zero insight into the technical goals of the discussion. >> >>> (I don't say they are right, but we will get people with strange comments >>> on the address model with both titles) >> >> Please tell me if my comments are "strange". > I think the problem you stated is that people can say "the title says it's > only for routers, so it is not enough for my usecase and I need something > different". > > If we not change the title we might get "the title says it's for all nodes, > but I cannot force my users to install a special interface configuration on > their smartphones, so I need something different." > > There are nodes in MANET that are a grey area between host and router. Because > of this we cannot make a clear statement on what nodes the autoconf address > model should be used. > > Most of the WG seems to think it's better to restrict the scope a little bit > more and let people use it for other things than the defined scope if they > think it's right (at least that's how I understand the consensus of the > group). > > Henning Rogge > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From henning.rogge@fkie.fraunhofer.de Thu Aug 5 02:34: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 5C0ED3A6B0A for ; Thu, 5 Aug 2010 02:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=-0.914, 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 UVQ86iUX4BoB for ; Thu, 5 Aug 2010 02:34:19 -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 13D573A6B06 for ; Thu, 5 Aug 2010 02:33:25 -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 1OgwpU-0002Bc-2L; Thu, 05 Aug 2010 11:33:36 +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 1OgwpT-0004O4-Ps; Thu, 05 Aug 2010 11:33:35 +0200 From: Henning Rogge To: autoconf@ietf.org Date: Thu, 5 Aug 2010 11:33:32 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-24-generic; KDE/4.4.5; i686; ; ) References: <4C528979.7010006@oracle.com> <201008051039.03011.henning.rogge@fkie.fraunhofer.de> <4C5A82A1.9000806@gmail.com> In-Reply-To: <4C5A82A1.9000806@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart75355463.0heZJKQVej"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201008051133.32630.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11503/Thu Aug 5 10:57:17 2010) by mailguard.fgan.de X-Scan-Signature: 6350b614948b1ffc5b5d2395905c4275 Subject: Re: [Autoconf] what's a router (was: WC consensus call for RFC5889 modifications ) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 09:34:21 -0000 --nextPart75355463.0heZJKQVej Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Thu August 5 2010 11:21:37 Alexandru Petrescu wrote: > To me a router is a device and its software doing this: one of them or all of them ? > - has a routing table called such. > - does longest-prefix match algorithm to search in it. This operation > is not specified (no RFC) but it is there everywhere in every router, > thanks BSD. > - includes that route.h I believe as CP said. > - has multiple interfaces. 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 --nextPart75355463.0heZJKQVej 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) iEYEABECAAYFAkxahWwACgkQRIfGfFXsz+C9WwCdGqeVx/4RdY7GEuqA5eOJShiQ JnkAn3XQrAFuCbNLn8p6CO8ALznxxfAe =IJZ0 -----END PGP SIGNATURE----- --nextPart75355463.0heZJKQVej-- From alexandru.petrescu@gmail.com Thu Aug 5 02:39: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 8DB193A68B5 for ; Thu, 5 Aug 2010 02:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.083, 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 K67u7AS2RI6u for ; Thu, 5 Aug 2010 02:39:29 -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 DA7BB3A6847 for ; Thu, 5 Aug 2010 02:39:28 -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 o759dfZ1031194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Aug 2010 11:39: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 o759dfaJ029913; Thu, 5 Aug 2010 11:39:41 +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 o759dfEl017174; Thu, 5 Aug 2010 11:39:41 +0200 Message-ID: <4C5A86DD.1050907@gmail.com> Date: Thu, 05 Aug 2010 11:39: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: Henning Rogge References: <4C528979.7010006@oracle.com> <201008051039.03011.henning.rogge@fkie.fraunhofer.de> <4C5A82A1.9000806@gmail.com> <201008051133.32630.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <201008051133.32630.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] what's a router X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 09:39:31 -0000 Le 05/08/2010 11:33, Henning Rogge a écrit : > On Thu August 5 2010 11:21:37 Alexandru Petrescu wrote: >> To me a router is a device and its software doing this: > > one of them or all of them ? Right, both of them, IMHO. Alex > >> - has a routing table called such. >> - does longest-prefix match algorithm to search in it. This operation >> is not specified (no RFC) but it is there everywhere in every router, >> thanks BSD. >> - includes that route.h I believe as CP said. >> - has multiple interfaces. > > Henning Rogge From henning.rogge@fkie.fraunhofer.de Thu Aug 5 02:42: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 A32EA3A68F6 for ; Thu, 5 Aug 2010 02:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=-0.882, 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 5cTzmzlNTghT for ; Thu, 5 Aug 2010 02:42:23 -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 AE3183A6924 for ; Thu, 5 Aug 2010 02:42:22 -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 1OgwyS-0005IU-D4; Thu, 05 Aug 2010 11:42:52 +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 1OgwyS-0004QQ-3P; Thu, 05 Aug 2010 11:42:52 +0200 From: Henning Rogge To: Alexandru Petrescu Date: Thu, 5 Aug 2010 11:42:47 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-24-generic; KDE/4.4.5; i686; ; ) References: <4C528979.7010006@oracle.com> <201008051133.32630.henning.rogge@fkie.fraunhofer.de> <4C5A86DD.1050907@gmail.com> In-Reply-To: <4C5A86DD.1050907@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1483401.sVMx0KZTXl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201008051142.48619.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11503/Thu Aug 5 10:57:17 2010) by mailguard.fgan.de X-Scan-Signature: ff96b43a3b0bdca915144ec1b58e50d3 Cc: autoconf@ietf.org Subject: Re: [Autoconf] what's a router X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 09:42:24 -0000 --nextPart1483401.sVMx0KZTXl Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Thu August 5 2010 11:39:41 Alexandru Petrescu wrote: > Le 05/08/2010 11:33, Henning Rogge a =E9crit : > > On Thu August 5 2010 11:21:37 Alexandru Petrescu wrote: > >> To me a router is a device and its software doing this: > >> - has a routing table called such. > >> - does longest-prefix match algorithm to search in it. This operation > >>=20 > >> is not specified (no RFC) but it is there everywhere in every > >> router, thanks BSD. > >>=20 > >> - includes that route.h I believe as CP said. > >> - has multiple interfaces. > > one of them or all of them ? >=20 > Right, both of them, IMHO. That make no sense for a MANET, most MANET routers have only a single=20 interface. And you don't need any header files like route.h on a router, just on your= =20 development system. I don't think you will find many embedded routers (DSL,= =20 MANET, ...) with header files on them. 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 --nextPart1483401.sVMx0KZTXl 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) iEYEABECAAYFAkxah5gACgkQRIfGfFXsz+DjeACaAjNgqIflvxkPm5r9t2HEZN9E OLUAoKkO6RB9uhFkRzrZX/8xJhRKuIhS =nwoz -----END PGP SIGNATURE----- --nextPart1483401.sVMx0KZTXl-- From emmanuel.baccelli@gmail.com Thu Aug 5 02:47: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 52DBE3A693A for ; Thu, 5 Aug 2010 02:47:47 -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 Rfvq5bk-AXRb for ; Thu, 5 Aug 2010 02:47:45 -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 B18CB3A6A0B for ; Thu, 5 Aug 2010 02:47:44 -0700 (PDT) Received: by ewy22 with SMTP id 22so2582608ewy.31 for ; Thu, 05 Aug 2010 02:48:14 -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=0wB1opHoCbvukK8UlAVdwIjoliybD9450u9KwEjb40s=; b=w54L7f8NZ+wjy/V32RFEpjpVGfUZWi3WdY4yxKsLfgtCA2ZJP5vxO1bqbKkOxfuUMc lMQUTQJd6Dn4QjGTsK10ERayptJLEa5whQRwkzt4UJZy4/AVVrxS2kBYfnq47/hh0yWW yht5xFGuBwlL2eKvW1rkZnV1NU8wz/xOnLJIE= 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=cZpvSy+16NqN7WGP3vVAJSvLScRyauy4dVa6RDm0E65WbSR5YkGwxRQM3fgSSWNn9y c9xn1RhwOe3R93W1dLemayjGohlvovUv/mEc29M2WMxbiXukFk9XrJxVMdIwdoq0bZQD SbudrXpedPo7Onf0gK9er9bV+lcxyBQBhAoIk= Received: by 10.14.119.133 with SMTP id n5mr2578309eeh.79.1281001693335; Thu, 05 Aug 2010 02:48:13 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.14.119.143 with HTTP; Thu, 5 Aug 2010 02:47:53 -0700 (PDT) In-Reply-To: <201008051039.03011.henning.rogge@fkie.fraunhofer.de> References: <4C528979.7010006@oracle.com> <201008040756.04650.henning.rogge@fkie.fraunhofer.de> <4C596602.1060308@earthlink.net> <201008051039.03011.henning.rogge@fkie.fraunhofer.de> From: Emmanuel Baccelli Date: Thu, 5 Aug 2010 11:47:53 +0200 X-Google-Sender-Auth: SX5qMdxmP94hKpCKaRuWcP9mVzM Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=90e6ba5bbad5e35a6a048d107254 Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [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, 05 Aug 2010 09:47:47 -0000 --90e6ba5bbad5e35a6a048d107254 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I share the opinion that this discussion polluted by the unanswered questio= n "what is the definition of a router?". There are too many different answers to this question (Thomas mentioned some of them in Maastricht, and other definitions exist, I'm sure). Maybe it would be easier to focus on the counterpart instead, and consider the question "what is the definition of a host?". It seems to me that the devices we are aiming to configure are typically capable of things that hosts can't do (including, for instance, forwarding traffic on behalf of other devices, if necessary). So the immediate conclusion that most folks make, is: "if it is not a host, then it is a router". Difficult to blame anyone for making such a deduction= , as the IETF defined a world where you only have these two choices. So I think, in that sense, we are indeed configuring routers. Now, if I understand Charlie's point correctly, he raises the question: "what of the special case where the device we are configuring is really a host?". This question was already raised some time ago in this working grou= p (at least while we were discussing the late MANET architecture draft). If I remember correctly, the rough consensus at that point in time was: "hosts are considered to be connected to a MANET only through a router, and thus, the MANET can be considered as comprising of only routers". This architectural consideration thus separated the issue of "configuring routers" from the issue of "configuring hosts" in this context, and the rough consensus was that we would first focus on configuring routers. Which lead us to where we are now. However, in the end, Charlie is right: we do want to configure the hosts to= o ;) So do we want to stick to the original plan (i.e. focus first on router configuration) or do we want to address instead both router and host configuration, all at once? I guess this is what it boils down to at this point. As far as I am concerned, I think it makes sense to consider the issue of "configuring routers" from the issue of "configuring hosts" separately because hosts are and routers have very different capabilities. I'm also fine with sticking with the original plan, i.e. focus first on router configuration. But on the way towards solutions for router configuration, I think we should be careful not to forget the big picture: in the end we wan= t to also configure hosts. In particular, this means that if an efficient router configuration solution can easily be extended to become an efficient host configuration solution, all the better ;) Emmanuel On Thu, Aug 5, 2010 at 10:38 AM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > On Wed August 4 2010 15:07:14 Charles E. Perkins wrote: > > Hello Henning, > > > > On 8/3/2010 10:55 PM, Henning Rogge wrote: > > > If you run a part of the routing protocol to connect the "host" to th= e > > > MANET, it's a router in my oppinion (Ripple would call it a leaf node > > > for example). > > > > What if your host gets an address by running > > "autoconf.exe", which is not a routing program? > Does your host set up a route towards the next router and maintains it if > the > topology data from the router changes ? If yes I would say it's a primiti= ve > router too. If no, it's not. > > > > If the node just use DHCP or similar protocols to get it's address > > > without being modified to work with the MANET, it's no router (and > don't > > > need the autoconf address model). > > > > What if the host does not? Or, do you mean to say > > that this discussion is a way to legislate that all > > hosts must use DHCP? > I don't think I ever said this. I just presented an example that the > address > model is not necessary for running a node in a MANET that use the autocon= f > address model. > > Yes, you CAN use it... but you don't need to. > > > > The autoconf model is NOT the only way for a host to get an address f= or > > > connection to a MANET. > > > > The autoconf model for getting addresses doesn't exist. > > I sure hope it isn't the only way to get an address. > > > > But suppose at some point there is an autoconf.exe. > > It should be a way for a host to get an address. > > Its connection to the MANET would, presumably allow > > it to use this address. Or, do you mean to say that > > "address allocation" =3D=3D "connection"? > I don't see any reason why an autoconfiguration protocol developed by thi= s > group would only run on interfaces of routers. > > > > If you have a router with a policy that limits the routers > functionality > > > (in terms of the routing protocol), you could just write a > > > compact/optimized version of the needed software part for it. > > > > main() > > { > > system ("get_address"); > > if (routing) fail(); /* My compact routing code */ > > } > > > > Am I a router? > I don't see any routing code of a routing protocol. But I don't see your > problem too. > > > >>> It should be done on the routers (but MANETs can and have been run > > >>> with different address models), and it could be used for hosts > closely > > >>> attached to a MANET, but it's not necessary to do so. > > >> > > >> What is "it"? > > > > > > The autoconf address model should be used on routers (but you could u= se > a > > > different one) and it (the address model) could be used on hosts > attached > > > to a MANET, but it's not necessary to use the autoconf address model = on > > > hosts. > > > > It's necessary for hosts to adhere to the > > considerations detailed in the address model > > document. I'm not sure if this is the same > > as "using" it. > It might be necessary, depending on what software the host is running. > > > >>> But in my opinion it is still better it's still better to restrict > the > > >>> title as suggested in the WG meeting consensus that to make it too > > >>> generic. > > >> > > >> I can't imagine any non-political reason whatsoever for this. > > > > > > If we do otherwise we could have the same problems. People would say > "you > > > demand that any computer attached to your MANET use the autoconf > address > > > model. But we have to use DHCP, so your address model is wrong." > > > > This is a political argument not based on the needs > > of the addressability, connectivity, or goals of > > making an ad hoc network. Insofar as you may be > > nonetheless correct, I begin to believe that I have > > zero insight into the technical goals of the discussion. > > > > > (I don't say they are right, but we will get people with strange > comments > > > on the address model with both titles) > > > > Please tell me if my comments are "strange". > I think the problem you stated is that people can say "the title says it'= s > only for routers, so it is not enough for my usecase and I need something > different". > > If we not change the title we might get "the title says it's for all node= s, > but I cannot force my users to install a special interface configuration = on > their smartphones, so I need something different." > > There are nodes in MANET that are a grey area between host and router. > Because > of this we cannot make a clear statement on what nodes the autoconf addre= ss > model should be used. > > Most of the WG seems to think it's better to restrict the scope a little > bit > more and let people use it for other things than the defined scope if the= y > think it's right (at least that's how I understand the consensus of the > group). > > Henning Rogge > -- > 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 > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > --90e6ba5bbad5e35a6a048d107254 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I share the opinion that this discussion polluted by the unanswered questio= n "what is the definition of a router?". There are too many diffe= rent answers to this question (Thomas mentioned some of them in Maastricht,= and other definitions exist, I'm sure).

Maybe it would be easier to focus on the counterpart instead= , and consider the question "what is the definition of a host?". = It seems to me that the devices we are aiming to configure are typically ca= pable of things that hosts can't do (including, for instance, forwardin= g traffic on behalf of other devices, if necessary).

So the immediate conclusion that most folks make, is: &= quot;if it is not a host, then it is a router". Difficult to blame any= one for making such a deduction, as the IETF defined a world where you only= have these two choices. So I think, in that sense, we are indeed configuri= ng routers.

Now, if I understand Charlie's point correctly, he = raises the question: "what of the special case where the device we are= configuring is really a host?". This question was already raised some= time ago in this working group (at least while we were discussing the late= MANET architecture draft). If I remember correctly, the rough consensus at= that point in time was: "hosts are considered to be connected to a MA= NET only through a router, and thus, the MANET can be considered as compris= ing of only routers".=A0

This architectural consideration thus separated the iss= ue of "configuring routers" from the issue of "configuring h= osts" in this context, and the rough consensus was that we would first= focus on configuring routers. Which lead us to where we are now.

However, in the end, Charlie is right: we do want to co= nfigure the hosts too ;) So do we want to stick to the original plan (i.e. = focus first on router configuration) or do we want to address instead both = router and host configuration, all at once? I guess this is what it boils d= own to at this point.

As far as I am concerned, I think it makes sense to con= sider=A0the issue of "configuring routers" from the issue of &quo= t;configuring hosts" separately because hosts are and routers have ver= y different capabilities.=A0I'm also fine with sticking with the origin= al plan,=A0i.e. focus first on router configuration. But on the way towards= solutions for router configuration, I think we should be careful not to fo= rget the big picture: in the end we want to also configure hosts. In partic= ular, this means that if an efficient router configuration solution can eas= ily be extended to become an efficient host configuration solution, all the= better ;)


Emmanuel







On Thu, Aug 5, 2010 at 10:38 AM, Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote:
On Wed August 4 2010 15:07:14 Charles E= . Perkins wrote:
> Hello Henning,
>
> On 8/3/2010 10:55 PM, Henning Rogge wrote:
> > If you run a part of the routing protocol to connect the "ho= st" to the
> > MANET, it's a router in my oppinion (Ripple would call it a l= eaf node
> > for example).
>
> What if your host gets an address by running
> "autoconf.exe", which is not a routing program?
Does your host set up a route towards the next router and maintains i= t if the
topology data from the router changes ? If yes I would say it's a primi= tive
router too. If no, it's not.

> > If the node just use DHCP or similar protocols to get it's ad= dress
> > without being modified to work with the MANET, it's no router= (and don't
> > need the autoconf address model).
>
> What if the host does not? =A0Or, do you mean to say
> that this discussion is a way to legislate that all
> hosts must use DHCP?
I don't think I ever said this. I just presented an example that = the address
model is not necessary for running a node in a MANET that use the autoconf<= br> address model.

Yes, you CAN use it... but you don't need to.

> > The autoconf model is NOT the only way for a host to get an addre= ss for
> > connection to a MANET.
>
> The autoconf model for getting addresses doesn't exist.
> I sure hope it isn't the only way to get an address.
>
> But suppose at some point there is an autoconf.exe.
> It should be a way for a host to get an address.
> Its connection to the MANET would, presumably allow
> it to use this address. =A0Or, do you mean to say that
> "address allocation" =3D=3D "connection"?
I don't see any reason why an autoconfiguration protocol develope= d by this
group would only run on interfaces of routers.

> > If you have a router with a policy that limits the routers functi= onality
> > (in terms of the routing protocol), you could just write a
> > compact/optimized version of the needed software part for it.
>
> main()
> {
> =A0 =A0 =A0 system ("get_address");
> =A0 =A0 =A0 if (routing) fail(); =A0 /* My compact routing code */
> }
>
> Am I a router?
I don't see any routing code of a routing protocol. But I don'= ;t see your
problem too.

> >>> It should be done on the routers (but MANETs can and have= been run
> >>> with different address models), and it could be used for = hosts closely
> >>> attached to a MANET, but it's not necessary to do so.=
> >>
> >> What is "it"?
> >
> > The autoconf address model should be used on routers (but you cou= ld use a
> > different one) and it (the address model) could be used on hosts = attached
> > to a MANET, but it's not necessary to use the autoconf addres= s model on
> > hosts.
>
> It's necessary for hosts to adhere to the
> considerations detailed in the address model
> document. =A0I'm not sure if this is the same
> as "using" it.
It might be necessary, depending on what software the host is running= .

> >>> But in my opinion it is still better it's still bette= r to restrict the
> >>> title as suggested in the WG meeting consensus that to ma= ke it too
> >>> generic.
> >>
> >> I can't imagine any non-political reason whatsoever for t= his.
> >
> > If we do otherwise we could have the same problems. People would = say "you
> > demand that any computer attached to your MANET use the autoconf = address
> > model. But we have to use DHCP, so your address model is wrong.&q= uot;
>
> This is a political argument not based on the needs
> of the addressability, connectivity, or goals of
> making an ad hoc network. =A0Insofar as you may be
> nonetheless correct, I begin to believe that I have
> zero insight into the technical goals of the discussion.
>
> > (I don't say they are right, but we will get people with stra= nge comments
> > on the address model with both titles)
>
> Please tell me if my comments are "strange".
I think the problem you stated is that people can say "the title= says it's
only for routers, so it is not enough for my usecase and I need something different".

If we not change the title we might get "the title says it's for a= ll nodes,
but I cannot force my users to install a special interface configuration on=
their smartphones, so I need something different."

There are nodes in MANET that are a grey area between host and router. Beca= use
of this we cannot make a clear statement on what nodes the autoconf address=
model should be used.

Most of the WG seems to think it's better to restrict the scope a littl= e bit
more and let people use it for other things than the defined scope if they<= br> think it's right (at least that's how I understand the consensus of= the
group).

Henning Rogge
--
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, =A0 Fax +49 228 9435 685
mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

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


--90e6ba5bbad5e35a6a048d107254-- From alexandru.petrescu@gmail.com Thu Aug 5 02:59: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 9C2FA3A6955 for ; Thu, 5 Aug 2010 02:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.082, 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 AkdKPDzPrQgj for ; Thu, 5 Aug 2010 02:59:30 -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 80E223A6781 for ; Thu, 5 Aug 2010 02:59:30 -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 o759xtcG018026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Aug 2010 11:59:55 +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 o759xtrH000964; Thu, 5 Aug 2010 11:59:55 +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 o759xs8g026437; Thu, 5 Aug 2010 11:59:55 +0200 Message-ID: <4C5A8B9A.90904@gmail.com> Date: Thu, 05 Aug 2010 11:59: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: Henning Rogge References: <4C528979.7010006@oracle.com> <201008051133.32630.henning.rogge@fkie.fraunhofer.de> <4C5A86DD.1050907@gmail.com> <201008051142.48619.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <201008051142.48619.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] what's a router X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 09:59:31 -0000 Le 05/08/2010 11:42, Henning Rogge a écrit : > On Thu August 5 2010 11:39:41 Alexandru Petrescu wrote: >> Le 05/08/2010 11:33, Henning Rogge a écrit : >>> On Thu August 5 2010 11:21:37 Alexandru Petrescu wrote: >>>> To me a router is a device and its software doing this: - has >>>> a routing table called such. - does longest-prefix match >>>> algorithm to search in it. This operation >>>> >>>> is not specified (no RFC) but it is there everywhere in every >>>> router, thanks BSD. >>>> >>>> - includes that route.h I believe as CP said. - has multiple >>>> interfaces. >>> one of them or all of them ? >> >> Right, both of them, IMHO. > That make no sense for a MANET, most MANET routers have only a single > interface. Well, are MANET routers 'routers' at all? Does a MANET router execute the longest-prefix match algorithm? Does a MANET router select an output interface depending on the result of that agorithm? Or is it just doing it with always the same result? > And you don't need any header files like route.h on a router, just > on your development system. I don't think you will find many > embedded routers (DSL, MANET, ...) with header files on them. WEll... the /usr/include stuff is there everywhere in the deployed routers running binaries. E.g. linux phones. I think a device that boots a kernel has a file system and that should have a /usr/include. Alex > > Henning Rogge From teco@inf-net.nl Thu Aug 5 03:20: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 810FB3A6A7A for ; Thu, 5 Aug 2010 03:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 IXhdF2VaYx0X for ; Thu, 5 Aug 2010 03:20:39 -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 108E03A6AAA for ; Thu, 5 Aug 2010 03:20:38 -0700 (PDT) Received: by eyb7 with SMTP id 7so2573968eyb.31 for ; Thu, 05 Aug 2010 03:21:08 -0700 (PDT) Received: by 10.14.29.6 with SMTP id h6mr2518289eea.15.1281003667895; Thu, 05 Aug 2010 03:21:07 -0700 (PDT) Received: from [192.168.2.197] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id a48sm9915eei.7.2010.08.05.03.21.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Aug 2010 03:21:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4C5A8B9A.90904@gmail.com> Date: Thu, 5 Aug 2010 12:21:05 +0200 Content-Transfer-Encoding: 7bit Message-Id: <8983D881-73CA-4C3B-AEAF-2AFBB5E58751@inf-net.nl> References: <4C528979.7010006@oracle.com> <201008051133.32630.henning.rogge@fkie.fraunhofer.de> <4C5A86DD.1050907@gmail.com> <201008051142.48619.henning.rogge@fkie.fraunhofer.de> <4C5A8B9A.90904@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org autoconf@ietf.org" Subject: Re: [Autoconf] what's a router X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 10:20:40 -0000 Op 5 aug 2010, om 11:59 heeft Alexandru Petrescu het volgende geschreven: > Well, are MANET routers 'routers' at all? Yes. > Does a MANET router execute the longest-prefix match algorithm? Yes. Every router MUST. This is Router Requirement (RFC 1812, page 75) And many other RFCs. Dig yourself. Also applies to hosts. > Does a MANET router select an output interface depending on the result > of that agorithm? Or is it just doing it with always the same result? Also RFC 1812. >> And you don't need any header files like route.h on a router, just >> on your development system. I don't think you will find many >> embedded routers (DSL, MANET, ...) with header files on them. > > WEll... the /usr/include stuff is there everywhere in the deployed > routers running binaries. E.g. linux phones. I think a device that > boots a kernel has a file system and that should have a /usr/include. Pure non-info. Teco. > Alex > >> >> Henning Rogge > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From henning.rogge@fkie.fraunhofer.de Thu Aug 5 03:25: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 26ECC3A6A6B for ; Thu, 5 Aug 2010 03:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.266 X-Spam-Level: X-Spam-Status: No, score=-1.266 tagged_above=-999 required=5 tests=[AWL=-1.781, BAYES_20=-0.74, 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 6DP8ho1gvnH7 for ; Thu, 5 Aug 2010 03:25: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 AF3113A6A72 for ; Thu, 5 Aug 2010 03:25:38 -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 1OgxeK-0002UZ-44; Thu, 05 Aug 2010 12:26:08 +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 1OgxeJ-0004bG-S6; Thu, 05 Aug 2010 12:26:07 +0200 From: Henning Rogge To: Alexandru Petrescu Date: Thu, 5 Aug 2010 12:25:48 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-24-generic; KDE/4.4.5; i686; ; ) References: <4C528979.7010006@oracle.com> <201008051142.48619.henning.rogge@fkie.fraunhofer.de> <4C5A8B9A.90904@gmail.com> In-Reply-To: <4C5A8B9A.90904@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1699168.sYExe2zFZb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201008051226.04921.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11503/Thu Aug 5 10:57:17 2010) by mailguard.fgan.de X-Scan-Signature: 14a0c07cd84b051fadb649c67c803b4c Cc: autoconf@ietf.org Subject: Re: [Autoconf] what's a router X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 10:25:40 -0000 --nextPart1699168.sYExe2zFZb Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Thu August 5 2010 11:59:54 Alexandru Petrescu wrote: > > That make no sense for a MANET, most MANET routers have only a single > > interface. >=20 > Well, are MANET routers 'routers' at all? Yes. =20 > Does a MANET router execute the longest-prefix match algorithm? Most MANET routers I'm working with are linux systems... mostly on embedded= =20 hardware. So the answer is "yes" for the systems I know. =20 > Does a MANET router select an output interface depending on the result > of that agorithm? Or is it just doing it with always the same result? Yes... difficult choice between the localhost interface and the only physic= al=20 outgoing interface wlan0. > > And you don't need any header files like route.h on a router, just > > on your development system. I don't think you will find many > > embedded routers (DSL, MANET, ...) with header files on them. >=20 > WEll... the /usr/include stuff is there everywhere in the deployed > routers running binaries. E.g. linux phones. I think a device that > boots a kernel has a file system and that should have a /usr/include. Maybe you should check your facts before you post stuff like this. I just opened the console of my android smartphone (linux based !) and I wa= s=20 not surprised that there are no include files on the device. Include files are necessary to COMPILE code... not to run it. They are a wa= ste=20 of space on embedded linux systems, because you don't have a compiler on th= em.=20 Noone creating a sane distribution for an embedded linux system would add a= n=20 include file to it. I would bet that neither a windows smartphone, nor a webos palm one, nor an= =20 iphone has any include header files on it's flash. Unless the user installe= d=20 it afterwards. 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 --nextPart1699168.sYExe2zFZb 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) iEYEABECAAYFAkxakawACgkQRIfGfFXsz+DnzACffL5Feq4N0J9M3qGy/xldOjmV F8gAniRNmwWSYVIhMty5D4m2TJmsxqmf =YtfZ -----END PGP SIGNATURE----- --nextPart1699168.sYExe2zFZb-- From ulrich@herberg.name Thu Aug 5 03:28: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 864883A69BE for ; Thu, 5 Aug 2010 03:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.209 X-Spam-Level: X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[AWL=0.768, 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 f0zGxHvKNC8S for ; Thu, 5 Aug 2010 03:28:50 -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 ABC0A3A6837 for ; Thu, 5 Aug 2010 03:28:50 -0700 (PDT) Received: by vws10 with SMTP id 10so5385153vws.31 for ; Thu, 05 Aug 2010 03:29:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.76.200 with SMTP id d8mr7114371vck.261.1281004160574; Thu, 05 Aug 2010 03:29:20 -0700 (PDT) Received: by 10.220.183.73 with HTTP; Thu, 5 Aug 2010 03:29:20 -0700 (PDT) In-Reply-To: <4C5A82A1.9000806@gmail.com> References: <4C528979.7010006@oracle.com> <201008040756.04650.henning.rogge@fkie.fraunhofer.de> <4C596602.1060308@earthlink.net> <201008051039.03011.henning.rogge@fkie.fraunhofer.de> <4C5A82A1.9000806@gmail.com> Date: Thu, 5 Aug 2010 12:29:20 +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] what's a router (was: WC consensus call for RFC5889 modifications ) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 10:28:51 -0000 Alex, >[...] > To me a router is a device and its software doing this: > - has a routing table called such. > - does longest-prefix match algorithm to search in it. =A0This operation > =A0is not specified (no RFC) but it is there everywhere in every router, > =A0thanks BSD. > - includes that route.h I believe as CP said. > - has multiple interfaces. > > In a sense every other host (my Windows PC) is a router because it does a= ll these things. =A0My PDA, my cell phone, are all routers. Well, that seems like a strange definition of a router. In a recent mail of Teco, he summarized the three typical definitions of routers. And as Henning said, MANET routers may have a single interface and still perform routing (in the sense of receiving an incoming IP packet not destined to the receiving router itself, looking up the next hop from the routing table using longest-prefix match, and retransmission on the appropriate network interface). Ulrich From teco@inf-net.nl Thu Aug 5 04:05: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 84BD93A696D for ; Thu, 5 Aug 2010 04:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 iWuyAUlXQUVO for ; Thu, 5 Aug 2010 04:05:52 -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 699F53A6926 for ; Thu, 5 Aug 2010 04:05:52 -0700 (PDT) Received: by ewy22 with SMTP id 22so2600669ewy.31 for ; Thu, 05 Aug 2010 04:06:22 -0700 (PDT) Received: by 10.213.80.204 with SMTP id u12mr3055737ebk.57.1281006382118; Thu, 05 Aug 2010 04:06:22 -0700 (PDT) Received: from [192.168.2.197] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id a48sm72812eei.7.2010.08.05.04.06.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Aug 2010 04:06:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Thu, 5 Aug 2010 13:06:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C528979.7010006@oracle.com> <201008040756.04650.henning.rogge@fkie.fraunhofer.de> <4C596602.1060308@earthlink.net> <201008051039.03011.henning.rogge@fkie.fraunhofer.de> <4C5A82A1.9000806@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org autoconf@ietf.org" Subject: Re: [Autoconf] what's a router (was: WC consensus call for RFC5889 modifications ) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 11:05:53 -0000 Alex, I guess this mail leads to nothing. But I give it a try. >> To me a router is a device and its software doing this: >> - has a routing table called such. All nodes have such. Including hosts. >> - does longest-prefix match algorithm to search in it. This = operation >> is not specified (no RFC) but it is there everywhere in every = router, >> thanks BSD. All nodes have such. Including hosts. Yes, described in RFCs. Started in RFC 1122 (or before), extended in = many RFC's.=20 Thanks IETF members. >> - includes that route.h I believe as CP said. Nonsense. >> - has multiple interfaces. All nodes may have such. Including hosts. >> In a sense every other host (my Windows PC) is a router because it = does all these things. My PDA, my cell phone, are all routers. Nonsense. Regards, Teco= From alexandru.petrescu@gmail.com Thu Aug 5 04:17: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 D1AB23A6853 for ; Thu, 5 Aug 2010 04:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_20=-0.74, 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 W5GreCDmTs4g for ; Thu, 5 Aug 2010 04:17:32 -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 6910C3A67FB for ; Thu, 5 Aug 2010 04:17:32 -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 o75BHvjI005874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Aug 2010 13:17:57 +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 o75BHuxx011918; Thu, 5 Aug 2010 13:17:57 +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 o75BHu8W009132; Thu, 5 Aug 2010 13:17:56 +0200 Message-ID: <4C5A9DE4.5030207@gmail.com> Date: Thu, 05 Aug 2010 13:17:56 +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: <4C528979.7010006@oracle.com> <201008051142.48619.henning.rogge@fkie.fraunhofer.de> <4C5A8B9A.90904@gmail.com> <201008051226.04921.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <201008051226.04921.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] what's a router X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 11:17:33 -0000 Le 05/08/2010 12:25, Henning Rogge a écrit : > On Thu August 5 2010 11:59:54 Alexandru Petrescu wrote: >>> That make no sense for a MANET, most MANET routers have only a >>> single interface. >> >> Well, are MANET routers 'routers' at all? > > Yes. > >> Does a MANET router execute the longest-prefix match algorithm? > > Most MANET routers I'm working with are linux systems... mostly on > embedded hardware. So the answer is "yes" for the systems I know. > > >> Does a MANET router select an output interface depending on the >> result of that agorithm? Or is it just doing it with always the >> same result? > > Yes... difficult choice between the localhost interface and the only > physical outgoing interface wlan0. So a MANET Router actually has at least two interfaces, which makes it more of a router indeed, in my reading. >>> And you don't need any header files like route.h on a router, >>> just on your development system. I don't think you will find >>> many embedded routers (DSL, MANET, ...) with header files on >>> them. >> >> WEll... the /usr/include stuff is there everywhere in the deployed >> routers running binaries. E.g. linux phones. I think a device >> that boots a kernel has a file system and that should have a >> /usr/include. > > Maybe you should check your facts before you post stuff like this. > > I just opened the console of my android smartphone (linux based !) > and I was not surprised that there are no include files on the > device. Good to know, I haven't tried android linux. > Include files are necessary to COMPILE code... not to run it. They Compile with static or dynamic link edition? > are a waste of space on embedded linux systems, because you don't > have a compiler on them. Noone creating a sane distribution for an > embedded linux system would add an include file to it. > > I would bet that neither a windows smartphone, nor a webos palm one, > nor an iphone has any include header files on it's flash. Unless the > user installed it afterwards. Libraries .so, .dll, modules .ko and kernel images may need .h at run time... Alex > Henning Rogge From alexandru.petrescu@gmail.com Thu Aug 5 04:25: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 6EFE33A68C1 for ; Thu, 5 Aug 2010 04:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.094, 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 yFmC8gFvEuin for ; Thu, 5 Aug 2010 04:25:14 -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 025363A6912 for ; Thu, 5 Aug 2010 04:25:13 -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 o75BPgDg032023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Aug 2010 13:25: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 o75BPgKb012874; Thu, 5 Aug 2010 13:25: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 o75BPgEU010419; Thu, 5 Aug 2010 13:25:42 +0200 Message-ID: <4C5A9FB6.1000508@gmail.com> Date: Thu, 05 Aug 2010 13:25:42 +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: <4C528979.7010006@oracle.com> <201008040756.04650.henning.rogge@fkie.fraunhofer.de> <4C596602.1060308@earthlink.net> <201008051039.03011.henning.rogge@fkie.fraunhofer.de> <4C5A82A1.9000806@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] what's a router X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 11:25:15 -0000 Le 05/08/2010 12:29, Ulrich Herberg a écrit : > Alex, > >> [...] To me a router is a device and its software doing this: - has >> a routing table called such. - does longest-prefix match algorithm >> to search in it. This operation is not specified (no RFC) but it >> is there everywhere in every router, thanks BSD. - includes that >> route.h I believe as CP said. - has multiple interfaces. >> >> In a sense every other host (my Windows PC) is a router because it >> does all these things. My PDA, my cell phone, are all routers. > > Well, that seems like a strange definition of a router. In a recent > mail of Teco, he summarized the three typical definitions of > routers. And as Henning said, MANET routers may have a single > interface and still perform routing (in the sense of receiving an > incoming IP packet not destined to the receiving router itself, > looking up the next hop from the routing table using longest-prefix > match, and retransmission on the appropriate network interface). If the 'appropriate' network interface is always the same interface becuase there's only one, then... why the need to look it up in a routing table? Why the need to select among other routes? Or is it simply because the longest-prefix match algorithm is there everywhere, works with any socket () program setting the dst IP address field, and with a default route set there. Just because the longest-prefix match algo is called everytime a packet is sent does not mean to me it _should_ be called. An optimizer human looking at a router with a single interface and a single-entry routing table would surely get rid of this latter including its algo. Because this happens at each packet and takes unnecessary time. And removing this table and algo makes it a no-router. Alex > > Ulrich > From henning.rogge@fkie.fraunhofer.de Thu Aug 5 04:39: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 347F23A6841 for ; Thu, 5 Aug 2010 04:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.836 X-Spam-Level: X-Spam-Status: No, score=-0.836 tagged_above=-999 required=5 tests=[AWL=-2.092, 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 T0fTV8ZcUZOb for ; Thu, 5 Aug 2010 04:39:21 -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 3B4F53A67FC for ; Thu, 5 Aug 2010 04:39:20 -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 1Ogynd-0007Zt-Bn; Thu, 05 Aug 2010 13:39:49 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fgan.de with esmtp (Exim 4.69) (envelope-from ) id 1Ogynd-0004rd-3Y; Thu, 05 Aug 2010 13:39:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Aug 2010 13:39:48 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CB34A3.A4D112F0" Message-ID: In-Reply-To: <4C5A9DE4.5030207@gmail.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] what's a router Thread-Index: Acs0j9/FA8mtEOqsSGek1iiHBO5cJQAADrIg References: <4C528979.7010006@oracle.com> <201008051142.48619.henning.rogge@fkie.fraunhofer.de> <4C5A8B9A.90904@gmail.com> <201008051226.04921.henning.rogge@fkie.fraunhofer.de> <4C5A9DE4.5030207@gmail.com> From: "Rogge Henning" To: "Alexandru Petrescu" X-Virus-Scanned: yes (ClamAV 0.96.1/11503/Thu Aug 5 10:57:17 2010) by mailguard.fgan.de X-Scan-Signature: a92cd3ae807afda4389f93ede93df287 Cc: autoconf@ietf.org Subject: Re: [Autoconf] what's a router X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 11:39:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01CB34A3.A4D112F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Urspr=FCngliche Nachricht----- > Von: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 >=20 > > Yes... difficult choice between the localhost interface and=20 > > the only physical outgoing interface wlan0. >=20 > So a MANET Router actually has at least two interfaces, which=20 > makes it more of a router indeed, in my reading. WTF ? So a computer with two localhost interfaces is a router in your oppinion = ? Funny idea to forwarding a packet with a nexthop on a localhost = interface. > >>> And you don't need any header files like route.h on a=20 > router, just=20 > >>> on your development system. I don't think you will find many=20 > >>> embedded routers (DSL, MANET, ...) with header files on them. > >> > >> WEll... the /usr/include stuff is there everywhere in the deployed=20 > >> routers running binaries. E.g. linux phones. I think a=20 > device that=20 > >> boots a kernel has a file system and that should have a=20 > /usr/include. > > > > Maybe you should check your facts before you post stuff like this. > > > > I just opened the console of my android smartphone (linux=20 > based !) and=20 > > I was not surprised that there are no include files on the device. >=20 > Good to know, I haven't tried android linux. >=20 > > Include files are necessary to COMPILE code... not to run it. They >=20 > Compile with static or dynamic link edition? Both of them. Header files DO NOT MATTER except for the compiler. =20 > > are a waste of space on embedded linux systems, because you=20 > don't have=20 > > a compiler on them. Noone creating a sane distribution for=20 > an embedded=20 > > linux system would add an include file to it. > > > > I would bet that neither a windows smartphone, nor a webos=20 > palm one, =20 > > nor an iphone has any include header files on it's flash.=20 > Unless the =20 > > user installed it afterwards. >=20 > Libraries .so, .dll, modules .ko and kernel images may need=20 > .h at run time... Good luck finding a header file on your windows machine. Alexandru, please take a break and read some good books about C, = operation systems and compilers. I think you have proven that you need to do some research. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr=20 Kommunikation, Informationsverarbeitung und Ergonomie FKIE=20 Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg,=20 Germany Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685=20 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0=20 ------=_NextPart_000_0000_01CB34A3.A4D112F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYAzCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQuMIIDFqADAgECAgIBDDANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDcxMjA1 MTUxODU4WhcNMTkwNjMwMjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2Zl cjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFJvb3QgQ0EgMjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMM9HslljVuIN/c+ wSG2VN6wOlcbGhzumAh0AVpvtd82VytERc7zRhNldpWYVMeohRVuEqQX6AvhIacxPSnd/6PWT9K0 if1jStqrU+9ZBbRP4jsqkZnAy2VXgaMwk5AOyb39FTIyCKRIfFYF8rs2ieJIwm9LkgwlRb6tPtTH Ae2xyBK0MAhup29/eiCnu7TlNYBULBmP2UvAHatD+GEUlPuwHV23kexiwJHRXt2nC7MtH2Y5GDyu BBTl0n022bLNpxOwzEWdVgRRcTM2XC9dUROeT0iQDpdaS3DbuXnZodaUyJLQpftgvy2tnnEAF4bA /UhmnRRMBU5M0XFEC9B6D7ECAwEAAaOB2TCB1jAfBgNVHSMEGDAWgBQxw3kbuvVT1xfgiXotF2wK syudMzAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFC9FQh4xBYDVcNj4HVfLW3rVPZz3MBIGA1Ud EwEB/wQIMAYBAf8CAQEwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2Nn aS1iaW4vc2VydmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vl cj1EVF9ST09UX0NBXzIwDQYJKoZIhvcNAQEFBQADggEBABq3THo85d3CY7LehiVORWJM9PKPX13X 5Y3ODtf1lOGLkzE2p5oj52fhUsFaGNaZ4YBkOA9KNTNdZnoo3Dh/N3LNUnVuEI5sfYz3Ket3wrkZ BdS3PWG66AUS1FBiU+8iVGL8TQHDXtQNg3RpUdU8nqzbpCt8bYSW03FNz9UtcaOSxD9Vz5s9I3cH V+nIzh2XtjP7kZdglg/39t5vJZASqxlH1UQjrsGSNSi/KkNeD+oHXdJE0IWC4xK8R+osrfjwQVJ9 Nroin3qgMu9LvPk6B7Ypxn04XzVVfjjyP3yz7i1uIXhfuRPP795lgMgl9WYtVEqtztkuDjDPgDOn ixly6kEwggTGMIIDrqADAgECAgphHTMZAAAAAAADMA0GCSqGSIb3DQEBBQUAMGcxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQ S0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIgUm9vdCBDQSAyMDA3MB4XDTA3MTIxMjE0NDkzNVoXDTE5 MDYzMDIzNTk1OVowZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsT GEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDCdBBRy3XRgfErNZ1agjqvkq7NAvyu yPsgdw7/aBIVkEmnZ3xoJF/6DiYaZT5KngkK04dPMxGKa1WiS02lT1Yb48d4efijC95VRmSH2owP PU6JYS8JPppdvVW6leZy4Ta0sHWctee2+nQruSX38b6TucFwp/eWf0y8i3XrsYFR7PzJ4XM75gWw UUvjsPVKCp/j2b8mJlBHTh4PHAOTxhWkT/avPKu9+FZ5SPluPsuwaDecLbqla6lm26TkNrB2KPa4 r92/seVnbDK1YnihgKUP3Tb4Aeb7rgHIUZ7ADWR4KQIjwsz+/0BWGKpNrp3XMRF8D4KO9qInwd7k Gd8Rzlf3AgMBAAGjggFyMIIBbjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRPHa+Iym24 qhwJ+cXREe1ZtJP6CzAOBgNVHQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUL0VCHjEFgNVw2PgdV8tb etU9nPcwdQYDVR0fBG4wbDBqoGigZoYxaHR0cDovL2NybC5wa2kuZnJhdW5ob2Zlci5kZS9maGct cm9vdC1jYS0yMDA3LmNybIYxaHR0cDovL2NybC5mcmF1bmhvZmVyLXBraS5kZS9maGctcm9vdC1j YS0yMDA3LmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LnBr aS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMD4GCCsGAQUFBzAChjJodHRwOi8v Y2VydC5mcmF1bmhvZmVyLXBraS5kZS9maGctcm9vdC1jYS0yMDA3LmNlcjANBgkqhkiG9w0BAQUF AAOCAQEAAHdsjDP57lcEJcrLiDnmTkykzsKWSxmGTbhEV8KVqRA37DBVMV/1nrW7tWtaoXfseksl 2OFdQs3BQzhhd8AO28iFf+ncgudyPZbmU48vc41LIy2bnA+I3jY2t0BLt/bELGLLhNzE3xRSYK/z XgBTB1ZJBxsd5VV2/hdyd/vcXlx5P8Af8iCnf0SIjDE0+Pmvq2tjEwrGAHuJICdL89k12BjfLbo4 woLFFG8HyQvcKzogiTDSTNYu7FFalSiKLMFu4eUKVlDbtROEQLAxM+3XqVwmGgCMD6axCJK9HROt 86h4ZjOHoEu4hpgXzUKIVDuoyTljXCfXSManNHP+FlB4PDCCBagwggSQoAMCAQICCjQb63gAAAAA uucwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAf BgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2Vy IENBIDIwMDcwHhcNMTAwMjAxMTE0MDM0WhcNMTYwMTMxMTE0MDM0WjBaMQswCQYDVQQGEwJERTET MBEGA1UEChMKRnJhdW5ob2ZlcjENMAsGA1UECxMERktJRTEPMA0GA1UECxMGUGVvcGxlMRYwFAYD VQQDEw1IZW5uaW5nIFJvZ2dlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxsgT9VRl hiEraBMqzI0g5nkPrSTp7j5TS/GTjKhiwmyr4hZ6VuurgDhTMulz7JRLZJMXJqEwjEBqPiHoGTEk gHl166P/lx2Or+j9XiHPYPxJjDOvRkWsrw+SWuiyacbroSTaDwz7nA38R27jXUSEKyi0SmhXYiBU Ihh1/sEf/uDmi9oBhfj6gOjzM/vLM7NJqi70CE6UMa0Ph8R7H+rwYXhQlVWZzUnKvt6OJFJ4HLJv m6xHreiOrU97kPlwi3YQZUxC439gYPY0wmFEmddNHOQ2fjtkoQYR9IgGWfP3vbQ8nXxUTIlOhS5x 9sSaSU/pTYBJv7xYyjPrS9SIGl5bqQIDAQABo4ICYTCCAl0wDgYDVR0PAQH/BAQDAgbAMCsGA1Ud EQQkMCKBIGhlbm5pbmcucm9nZ2VAZmtpZS5mcmF1bmhvZmVyLmRlMB0GA1UdDgQWBBQBfgSrsBku X2mKj92DUbzW0i0r8zAfBgNVHSMEGDAWgBRPHa+Iym24qhwJ+cXREe1ZtJP6CzB1BgNVHR8EbjBs MGqgaKBmhjFodHRwOi8vY3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy11c2VyLWNhLTIwMDcuY3Js hjFodHRwOi8vY3JsLmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11c2VyLWNhLTIwMDcuY3JsMIIBCgYI KwYBBQUHAQEEgf0wgfowPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LnBraS5mcmF1bmhvZmVyLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMD4GCCsGAQUFBzAChjJodHRwOi8vY2VydC5mcmF1bmhvZmVy LXBraS5kZS9maGctdXNlci1jYS0yMDA3LmNlcjA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2Vy LWNhLTIwMDcub2NzcC5wa2kuZnJhdW5ob2Zlci5kZS8wOwYIKwYBBQUHMAGGL2h0dHA6Ly9maGct dXNlci1jYS0yMDA3Lm9jc3AuZnJhdW5ob2Zlci1wa2kuZGUvMBMGA1UdJQQMMAoGCCsGAQUFBwME MEQGA1UdIAQ9MDswOQYLKwYBBAGGClADAQEwKjAoBggrBgEFBQcCARYcaHR0cDovL3BraS5mcmF1 bmhvZmVyLmRlL2NwLzANBgkqhkiG9w0BAQUFAAOCAQEAOayOZLk0fQfhQ7I0Qzn6KzuD4ixrzteS XITHu1RJ9/3xebplEm6YI/jwMLNFnfglXq+9I+rGjE/PxSOW6qK8CA31DIo8qXhsxvvfF3yrFzHL zgyCcWdoxer2YvfKpJJfx0BKPGMvuAeTJp5L+PuWcGkvmDb/wRwAJOfjNSokNdc27k3T+HTtXNsM rQzGWeIZFnK+pSQm/gWoDX7dNZE592/Dq8Rp83jedwl5CDBKd0B6PDCM7vsEA9P+9L9/142H/1u6 gYVNlR7GhsjCjUtsvpDZrMPNAd2wVAPoqiJ0WrfG/IEuA5SySue+aeflbvMxDT1cWFnighiatWYb xwNmPDCCBbQwggScoAMCAQICCjQb6OgAAAAAuuYwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMC REUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBL STEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcwHhcNMTAwMjAxMTE0MDM0WhcNMTYw MTMxMTE0MDM0WjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjENMAsGA1UECxME RktJRTEPMA0GA1UECxMGUGVvcGxlMRYwFAYDVQQDEw1IZW5uaW5nIFJvZ2dlMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAosulW1xdX1xuHoX36m/A69SfDwvfsXmrYgI0qhSDgovRnWxT 64dxCK2+vU+LskPno1m0RJTRbKgVo6O8j1/oU/OBVpi82DM97mWMUxYEpweKLdq+ROTZPUwFY8Qf z8EJ/cZjyrEBYs8NxAfRPFRWGd+BrkKNIvB9mr77PQa/rA+qEuNTmKY0Nbl4VAgwmGV37RFA2CLz 38wc44uloJJKyYIA7CbIMae3kjUKy9YY55kyjgCY3c21/YV4ruOEwBu9yfEBmxx0E1P0/fB7G3+7 d6kBL+avP/QhwYmdJjFsarYSmUpXp9P1+c8HFTw5TYGULtj8f/FWQlmRjWDzSct4eQIDAQABo4IC bTCCAmkwDgYDVR0PAQH/BAQDAgQwMCsGA1UdEQQkMCKBIGhlbm5pbmcucm9nZ2VAZmtpZS5mcmF1 bmhvZmVyLmRlMB0GA1UdDgQWBBRir/+EBYAUW6PBp6sYHmuGX1+fsjAfBgNVHSMEGDAWgBRPHa+I ym24qhwJ+cXREe1ZtJP6CzB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8vY3JsLnBraS5mcmF1bmhv ZmVyLmRlL2ZoZy11c2VyLWNhLTIwMDcuY3JshjFodHRwOi8vY3JsLmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY3JsMIIBCgYIKwYBBQUHAQEEgf0wgfowPgYIKwYBBQUHMAKGMmh0 dHA6Ly9jZXJ0LnBraS5mcmF1bmhvZmVyLmRlL2ZoZy11c2VyLWNhLTIwMDcuY2VyMD4GCCsGAQUF BzAChjJodHRwOi8vY2VydC5mcmF1bmhvZmVyLXBraS5kZS9maGctdXNlci1jYS0yMDA3LmNlcjA7 BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNhLTIwMDcub2NzcC5wa2kuZnJhdW5ob2Zlci5k ZS8wOwYIKwYBBQUHMAGGL2h0dHA6Ly9maGctdXNlci1jYS0yMDA3Lm9jc3AuZnJhdW5ob2Zlci1w a2kuZGUvMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQGCCsGAQUFBwMEMEQGA1UdIAQ9MDswOQYLKwYB BAGGClADAQEwKjAoBggrBgEFBQcCARYcaHR0cDovL3BraS5mcmF1bmhvZmVyLmRlL2NwLzANBgkq hkiG9w0BAQUFAAOCAQEABPYI1Hbqips/0o+2m6Guww7ys/5F++qSYPq6w4CtlyuPupLZdKzEVuZ2 n1fopZuEndTyCTq8DUJwZXKPEIYKQGhkbFNy3IDaHB5VHaX0JsqV4DsgD6Xa2jnEBQpiy8RxMKP5 mY5NRS4jO6J+bFjrMiKbjDlzvJJxy6kqy8efjxH6RdMjGxQRcMS4EUTs7DRu38A81XEGaqqtjcwN 3n3EvJUVcBzXn63Bmb4bgv1U6DYXFMSMcksssapmsdL0EPXKAWBRcswouetjRBXIFfu1xKFINtwy ax6RCZycAEXddFC6j/3BVvi6iNFSE1VVQx+HQz1EhGBcp80W3qnIvoO1UjGCA3YwggNyAgEBMHUw ZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIg Q29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb63gAAAAA uucwCQYFKw4DAhoFAKCCAdYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTAwODA1MTEzOTM1WjAjBgkqhkiG9w0BCQQxFgQUmqWoRKKbnGilL3Gvx86K3Q93JsIwZwYJ KoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVu aG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb 6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJh dW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1 bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0BAQEFAASCAQBsmIURm8JT oFmYdo/vYig+aFBJkaTrUGzOgwNNLJifQt/tH/ZGMNC/YHJE2Xpgi2nO3edXU40DSbxYe1qk4zHV IWfJm6uY//7lzrVk5vWA8CqEeQkdOBeWuUUJueAFUX/U9qnhQ+eK3KncyWlSlwdN6W6frloDg3h1 R0vpSNCQIXyqXdLJC3o+wxbVymgKNOpXxfabcCuZRFhOYIx1PHuP4AJr5X2PeruoBSBIOE/t3NGc EeL8SYkB6YRSQaQrW0lplQ1pYm4w76kgvJg1YPcTmNoncwWSt6eIC2l6fVSHixpnsCL/ZoTP4Eim rgucDxBoJimfrGdLg7nqn85Oo3AmAAAAAAAA ------=_NextPart_000_0000_01CB34A3.A4D112F0-- From alexandru.petrescu@gmail.com Thu Aug 5 04:44: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 0BE613A6912 for ; Thu, 5 Aug 2010 04:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.092, 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 6CQxNpKP3cp3 for ; Thu, 5 Aug 2010 04:44: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 D4CFE3A686B for ; Thu, 5 Aug 2010 04:43:59 -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 o75BiT0f017026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Aug 2010 13:44:29 +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 o75BiTKi015792; Thu, 5 Aug 2010 13:44:29 +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 o75BiTbe013930; Thu, 5 Aug 2010 13:44:29 +0200 Message-ID: <4C5AA41D.8070801@gmail.com> Date: Thu, 05 Aug 2010 13:44:29 +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: <4C528979.7010006@oracle.com> <201008051133.32630.henning.rogge@fkie.fraunhofer.de> <4C5A86DD.1050907@gmail.com> <201008051142.48619.henning.rogge@fkie.fraunhofer.de> <4C5A8B9A.90904@gmail.com> <8983D881-73CA-4C3B-AEAF-2AFBB5E58751@inf-net.nl> In-Reply-To: <8983D881-73CA-4C3B-AEAF-2AFBB5E58751@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] what's a router X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 11:44:01 -0000 Le 05/08/2010 12:21, Teco Boot a écrit : > > Op 5 aug 2010, om 11:59 heeft Alexandru Petrescu het volgende > geschreven: > >> Well, are MANET routers 'routers' at all? > > Yes. > > >> Does a MANET router execute the longest-prefix match algorithm? > > Yes. Every router MUST. This is Router Requirement (RFC 1812, page > 75) And many other RFCs. Dig yourself. > > Also applies to hosts. Hmmm the rfc1812 title says "Reqs for IPv4 Routers" (not hosts)... >> Does a MANET router select an output interface depending on the >> result of that agorithm? Or is it just doing it with always the >> same result? > > Also RFC 1812. Are MANET Routers referring to RFC1812? BEcause RFC1812 says: > (1) If a host has only a single constituent-network interface, it > should not act as a router. To me that reads that if a device has a single interface then it can't act as a router. Also rfc1812 says: > An Internet router performs the following functions: [...] > (2) Interfaces to two or more packet networks. Since MANET is so vaguely defined, because of the undetermined link connectivity properties, one wouldn't say that a MANET Router is an Internet Router. >>> And you don't need any header files like route.h on a router, >>> just on your development system. I don't think you will find >>> many embedded routers (DSL, MANET, ...) with header files on >>> them. >> >> WEll... the /usr/include stuff is there everywhere in the deployed >> routers running binaries. E.g. linux phones. I think a device >> that boots a kernel has a file system and that should have a >> /usr/include. > > Pure non-info. WEll. There are file systems and dynamically compressed file systems. There are off-the-shelf kernels and home-brewed re-compiled kernels. Few things are pure :-) Alex > > > Teco. > > >> Alex >> >>> >>> Henning Rogge >> >> >> _______________________________________________ Autoconf mailing >> list Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From alexandru.petrescu@gmail.com Thu Aug 5 04:59: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 C9D913A6A77 for ; Thu, 5 Aug 2010 04:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.858 X-Spam-Level: X-Spam-Status: No, score=-0.858 tagged_above=-999 required=5 tests=[AWL=-1.209, 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 c6nh7v-mekCg for ; Thu, 5 Aug 2010 04:59:36 -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 705633A695B for ; Thu, 5 Aug 2010 04:59:36 -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 o75C03OT031564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Aug 2010 14:00: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 o75C02QK018258; Thu, 5 Aug 2010 14:00: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 o75C020f013204; Thu, 5 Aug 2010 14:00:02 +0200 Message-ID: <4C5AA7C2.5030909@gmail.com> Date: Thu, 05 Aug 2010 14:00: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: Rogge Henning References: <4C528979.7010006@oracle.com> <201008051142.48619.henning.rogge@fkie.fraunhofer.de> <4C5A8B9A.90904@gmail.com> <201008051226.04921.henning.rogge@fkie.fraunhofer.de> <4C5A9DE4.5030207@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] what's a router X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 11:59:37 -0000 Le 05/08/2010 13:39, Rogge Henning a écrit : >> -----Ursprüngliche Nachricht----- >> Von: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> >>> Yes... difficult choice between the localhost interface and >>> the only physical outgoing interface wlan0. >> >> So a MANET Router actually has at least two interfaces, which >> makes it more of a router indeed, in my reading. > WTF ? > > So a computer with two localhost interfaces is a router in your oppinion ? > Funny idea to forwarding a packet with a nexthop on a localhost interface. Funny indeed... it would still route between localhost interfaces, there would be choice for tht algo. >>>>> And you don't need any header files like route.h on a >> router, just >>>>> on your development system. I don't think you will find many >>>>> embedded routers (DSL, MANET, ...) with header files on them. >>>> >>>> WEll... the /usr/include stuff is there everywhere in the deployed >>>> routers running binaries. E.g. linux phones. I think a >> device that >>>> boots a kernel has a file system and that should have a >> /usr/include. >>> >>> Maybe you should check your facts before you post stuff like this. >>> >>> I just opened the console of my android smartphone (linux >> based !) and >>> I was not surprised that there are no include files on the device. >> >> Good to know, I haven't tried android linux. >> >>> Include files are necessary to COMPILE code... not to run it. They >> >> Compile with static or dynamic link edition? > Both of them. Header files DO NOT MATTER except for the compiler. > >>> are a waste of space on embedded linux systems, because you >> don't have >>> a compiler on them. Noone creating a sane distribution for >> an embedded >>> linux system would add an include file to it. >>> >>> I would bet that neither a windows smartphone, nor a webos >> palm one, >>> nor an iphone has any include header files on it's flash. >> Unless the >>> user installed it afterwards. >> >> Libraries .so, .dll, modules .ko and kernel images may need >> .h at run time... > Good luck finding a header file on your windows machine. > > Alexandru, please take a break and read some good books about C, operation > systems and compilers. I think you have proven that you need to do some > research. Ok, good advice in general. I will have to look closer at this. I do like the idea of router.h representing a router software though. Alex > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) Neuenahrer Straße 20, 53343 Wachtberg, > Germany Telefon +49 228 9435-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 From alexandru.petrescu@gmail.com Thu Aug 5 05:05: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 9DFDA3A687B for ; Thu, 5 Aug 2010 05:05:35 -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 Ottspm6b1idm for ; Thu, 5 Aug 2010 05:05: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 27C123A696E for ; Thu, 5 Aug 2010 05:05:33 -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 o75C63w6024484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Aug 2010 14:06:04 +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 o75C63m8020360; Thu, 5 Aug 2010 14:06: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 o75C635t015996; Thu, 5 Aug 2010 14:06:03 +0200 Message-ID: <4C5AA92B.3010700@gmail.com> Date: Thu, 05 Aug 2010 14:06:03 +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: <4C528979.7010006@oracle.com> <201008040756.04650.henning.rogge@fkie.fraunhofer.de> <4C596602.1060308@earthlink.net> <201008051039.03011.henning.rogge@fkie.fraunhofer.de> <4C5A82A1.9000806@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org autoconf@ietf.org" Subject: Re: [Autoconf] what's a router X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 12:05:35 -0000 Le 05/08/2010 13:06, Teco Boot a écrit : > Alex, > > I guess this mail leads to nothing. But I give it a try. > >>> To me a router is a device and its software doing this: - has a >>> routing table called such. > All nodes have such. Including hosts. > >>> - does longest-prefix match algorithm to search in it. This >>> operation is not specified (no RFC) but it is there everywhere >>> in every router, thanks BSD. > > All nodes have such. Including hosts. Yes, described in RFCs. > Started in RFC 1122 (or before), extended in many RFC's. Thanks IETF > members. If you mean rfc1812. That "longest match" algo: - is not the longest-prefix match algo - talks IPv4 only, - doesn't say how it "examines": it doesn't say bitwise compare - doesn't treat the fairly common case of multiple entries of same prefix same length, - does not treat the special default route - has no licensing scheme - and more. As written there it's hardly implementable in an interoperable manner (as compared to a much better of e.g. segment processing of IPv6 rfc2460 pp 16, or the C in rfc3174 SHA1). That spec works well by example: it gives good examples, although not any counter example. Alex > >>> - includes that route.h I believe as CP said. > Nonsense. > >>> - has multiple interfaces. > All nodes may have such. Including hosts. > >>> In a sense every other host (my Windows PC) is a router because >>> it does all these things. My PDA, my cell phone, are all >>> routers. > Nonsense. > > > Regards, Teco From alexandru.petrescu@gmail.com Thu Aug 5 05:22: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 227003A699A for ; Thu, 5 Aug 2010 05:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.935 X-Spam-Level: X-Spam-Status: No, score=-0.935 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_40=-0.185, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfiQ9iTbbGf5 for ; Thu, 5 Aug 2010 05:22:43 -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 88D1B3A6987 for ; Thu, 5 Aug 2010 05:22:42 -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 o75CNBXT010932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 5 Aug 2010 14:23:11 +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 o75CNA2X025046 for ; Thu, 5 Aug 2010 14:23:11 +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 o75CN7Df021806 for ; Thu, 5 Aug 2010 14:23:09 +0200 Message-ID: <4C5AAD2B.3070508@gmail.com> Date: Thu, 05 Aug 2010 14:23: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: autoconf@ietf.org References: <4C528979.7010006@oracle.com> <201008040756.04650.henning.rogge@fkie.fraunhofer.de> <4C596602.1060308@earthlink.net> <201008051039.03011.henning.rogge@fkie.fraunhofer.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [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, 05 Aug 2010 12:22:46 -0000 Le 05/08/2010 11:47, Emmanuel Baccelli a écrit : > I share the opinion that this discussion polluted by the unanswered > question "what is the definition of a router?". There are too many > different answers to this question (Thomas mentioned some of them in > Maastricht, and other definitions exist, I'm sure). > > Maybe it would be easier to focus on the counterpart instead, and > consider the question "what is the definition of a host?". That is a good question, looking at it the other way around. > It seems to me that the devices we are aiming to configure are > typically capable of things that hosts can't do (including, for > instance, forwarding traffic on behalf of other devices, if > necessary). > > So the immediate conclusion that most folks make, is: "if it is not a > host, then it is a router". Difficult to blame anyone for making such > a deduction, I agree. I think this logic "if it is not a host then it is a router" is not a right logic. It could be, for example, a multi-homed device, not routing, yet multiple interfaces, etc. If it is not a host then it could be a multi-homed host, a router, and probably more. > as the IETF defined a world where you only have these two choices. > So I think, in that sense, we are indeed configuring routers. > > Now, if I understand Charlie's point correctly, he raises the > question: "what of the special case where the device we are > configuring is really a host?". This question was already raised some > time ago in this working group (at least while we were discussing the > late MANET architecture draft). If I remember correctly, the rough > consensus at that point in time was: "hosts are considered to be > connected to a MANET only through a router, and thus, the MANET can > be considered as comprising of only routers". > > This architectural consideration thus separated the issue of > "configuring routers" from the issue of "configuring hosts" in this > context, and the rough consensus was that we would first focus on > configuring routers. Which lead us to where we are now. > > However, in the end, Charlie is right: we do want to configure the > hosts too ;) :-) sounds good. How about us wanting to configure an "AUTOCONF node"? (a little bit of a Router, of a Host, and of a MANET Router). > So do we want to stick to the original plan (i.e. focus first on > router configuration) or do we want to address instead both router > and host configuration, all at once? I guess this is what it boils > down to at this point. I will be happier if it boiled down to defining an "AUTOCONF node" or entity, or so. > > As far as I am concerned, I think it makes sense to consider the > issue of "configuring routers" from the issue of "configuring hosts" > separately because hosts are and routers have very different > capabilities. I'm also fine with sticking with the original plan, > i.e. focus first on router configuration. But on the way towards > solutions for router configuration, I think we should be careful not > to forget the big picture: in the end we want to also configure > hosts. In particular, this means that if an efficient router > configuration solution can easily be extended to become an efficient > host configuration solution, all the better ;) Reads good. Alex > > > Emmanuel > > > > > > > > On Thu, Aug 5, 2010 at 10:38 AM, Henning Rogge > > wrote: > > On Wed August 4 2010 15:07:14 Charles E. Perkins wrote: >> Hello Henning, >> >> On 8/3/2010 10:55 PM, Henning Rogge wrote: >>> If you run a part of the routing protocol to connect the "host" > to the >>> MANET, it's a router in my oppinion (Ripple would call it a > leaf node >>> for example). >> >> What if your host gets an address by running "autoconf.exe", which >> is not a routing program? > Does your host set up a route towards the next router and maintains > it if the topology data from the router changes ? If yes I would say > it's a primitive router too. If no, it's not. > >>> If the node just use DHCP or similar protocols to get it's >>> address without being modified to work with the MANET, it's no >>> router > (and don't >>> need the autoconf address model). >> >> What if the host does not? Or, do you mean to say that this >> discussion is a way to legislate that all hosts must use DHCP? > I don't think I ever said this. I just presented an example that the > address model is not necessary for running a node in a MANET that use > the autoconf address model. > > Yes, you CAN use it... but you don't need to. > >>> The autoconf model is NOT the only way for a host to get an > address for >>> connection to a MANET. >> >> The autoconf model for getting addresses doesn't exist. I sure hope >> it isn't the only way to get an address. >> >> But suppose at some point there is an autoconf.exe. It should be a >> way for a host to get an address. Its connection to the MANET >> would, presumably allow it to use this address. Or, do you mean to >> say that "address allocation" == "connection"? > I don't see any reason why an autoconfiguration protocol developed by > this group would only run on interfaces of routers. > >>> If you have a router with a policy that limits the routers > functionality >>> (in terms of the routing protocol), you could just write a >>> compact/optimized version of the needed software part for it. >> >> main() { system ("get_address"); if (routing) fail(); /* My >> compact routing code */ } >> >> Am I a router? > I don't see any routing code of a routing protocol. But I don't see > your problem too. > >>>>> It should be done on the routers (but MANETs can and have > been run >>>>> with different address models), and it could be used for > hosts closely >>>>> attached to a MANET, but it's not necessary to do so. >>>> >>>> What is "it"? >>> >>> The autoconf address model should be used on routers (but you > could use a >>> different one) and it (the address model) could be used on > hosts attached >>> to a MANET, but it's not necessary to use the autoconf address > model on >>> hosts. >> >> It's necessary for hosts to adhere to the considerations detailed >> in the address model document. I'm not sure if this is the same as >> "using" it. > It might be necessary, depending on what software the host is > running. > >>>>> But in my opinion it is still better it's still better to > restrict the >>>>> title as suggested in the WG meeting consensus that to make > it too >>>>> generic. >>>> >>>> I can't imagine any non-political reason whatsoever for this. >>> >>> If we do otherwise we could have the same problems. People > would say "you >>> demand that any computer attached to your MANET use the > autoconf address >>> model. But we have to use DHCP, so your address model is wrong." >> >> This is a political argument not based on the needs of the >> addressability, connectivity, or goals of making an ad hoc network. >> Insofar as you may be nonetheless correct, I begin to believe that >> I have zero insight into the technical goals of the discussion. >> >>> (I don't say they are right, but we will get people with > strange comments >>> on the address model with both titles) >> >> Please tell me if my comments are "strange". > I think the problem you stated is that people can say "the title says > it's only for routers, so it is not enough for my usecase and I need > something different". > > If we not change the title we might get "the title says it's for all > nodes, but I cannot force my users to install a special interface > configuration on their smartphones, so I need something different." > > There are nodes in MANET that are a grey area between host and > router. Because of this we cannot make a clear statement on what > nodes the autoconf address model should be used. > > Most of the WG seems to think it's better to restrict the scope a > little bit more and let people use it for other things than the > defined scope if they think it's right (at least that's how I > understand the consensus of the group). > > Henning Rogge -- Diplom-Informatiker Henning Rogge , > Fraunhofer-Institut für Kommunikation, Informationsverarbeitung und > Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Straße 20, > 53343 Wachtberg, Germany Telefon +49 228 9435-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 > > _______________________________________________ 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 Thu Aug 5 05:23: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 9B4C13A697B for ; Thu, 5 Aug 2010 05:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 JPalmUxobKUV for ; Thu, 5 Aug 2010 05:22:59 -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 0A91C3A6987 for ; Thu, 5 Aug 2010 05:22:58 -0700 (PDT) Received: by ewy22 with SMTP id 22so2619678ewy.31 for ; Thu, 05 Aug 2010 05:23:28 -0700 (PDT) Received: by 10.213.64.76 with SMTP id d12mr3161589ebi.8.1281011008238; Thu, 05 Aug 2010 05:23:28 -0700 (PDT) Received: from [192.168.2.197] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id a48sm190069eei.0.2010.08.05.05.23.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Aug 2010 05:23:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4C5AA41D.8070801@gmail.com> Date: Thu, 5 Aug 2010 14:23:25 +0200 Content-Transfer-Encoding: 7bit Message-Id: <8310F008-0DB4-4BC1-92AC-FE77FAB3073F@inf-net.nl> References: <4C528979.7010006@oracle.com> <201008051133.32630.henning.rogge@fkie.fraunhofer.de> <4C5A86DD.1050907@gmail.com> <201008051142.48619.henning.rogge@fkie.fraunhofer.de> <4C5A8B9A.90904@gmail.com> <8983D881-73CA-4C3B-AEAF-2AFBB5E58751@inf-net.nl> <4C5AA41D.8070801@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org autoconf@ietf.org" Subject: Re: [Autoconf] what's a router X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 12:23:03 -0000 Alex, Again, I don't think this mail helps. Nevertheless, another attempt. >>> Does a MANET router execute the longest-prefix match algorithm? >> >> Yes. Every router MUST. This is Router Requirement (RFC 1812, page >> 75) And many other RFCs. Dig yourself. > > >> Also applies to hosts. > > Hmmm the rfc1812 title says "Reqs for IPv4 Routers" (not hosts)... Your question was on routers. So RFC 1812 applies. Longest match also applies to hosts. RFC 1122 starts with "best next hop". Then, we had VLSM and CIDR. All we ask, do a little research yourself and don't bother us. >>> Does a MANET router select an output interface depending on the >>> result of that agorithm? Or is it just doing it with always the >>> same result? >> >> Also RFC 1812. > > Are MANET Routers referring to RFC1812? BEcause RFC1812 says: >> (1) If a host has only a single constituent-network interface, it >> should not act as a router. > > To me that reads that if a device has a single interface then it can't > act as a router. Hmm. You quote from "2.2.8 Notable Oddities". And it is a "should". One way to circumvent is sending an icmp redirect, so next packets are send directly to a better gateway. More important: ask Fred himself on this. He worked on point-to-multipoint, which works similar to what MANET routers do. Appendix C (15) discuss future directions with "Multiple logical (sub)nets on the same wire." Thats where we are. Also, the "lolly-pop router" or "router on a stick" are well known by now. Isn't MIP HA an example? So yes, a RFC1812-bis should use other wording. > Also rfc1812 says: >> An Internet router performs the following functions: > [...] >> (2) Interfaces to two or more packet networks. > > Since MANET is so vaguely defined, because of the undetermined link > connectivity properties, one wouldn't say that a MANET Router is an > Internet Router. See previous remark on future directions. Regards, Teco >>>> And you don't need any header files like route.h on a router, >>>> just on your development system. I don't think you will find >>>> many embedded routers (DSL, MANET, ...) with header files on >>>> them. >>> >>> WEll... the /usr/include stuff is there everywhere in the deployed >>> routers running binaries. E.g. linux phones. I think a device >>> that boots a kernel has a file system and that should have a >>> /usr/include. >> >> Pure non-info. > > WEll. There are file systems and dynamically compressed file systems. > There are off-the-shelf kernels and home-brewed re-compiled kernels. > > Few things are pure :-) > > Alex > >> >> >> Teco. >> >> >>> Alex >>> >>>> >>>> Henning Rogge >>> >>> >>> _______________________________________________ Autoconf mailing >>> list Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >> >> > > From charles.perkins@earthlink.net Thu Aug 5 10:32:58 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 C86D43A69A8 for ; Thu, 5 Aug 2010 10:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.911 X-Spam-Level: X-Spam-Status: No, score=-0.911 tagged_above=-999 required=5 tests=[AWL=-0.912, 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 Nx0s8+Z71L+r for ; Thu, 5 Aug 2010 10:32:56 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id D74FD3A68B8 for ; Thu, 5 Aug 2010 10:32:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Uxmkg76kd7dCDwQ6Mu0+rMmy8sTz0I0t339GPN791kLZbKc2d8HTWRkChQoYg2L4; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.158]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Oh4Jm-0001tD-8f; Thu, 05 Aug 2010 13:33:23 -0400 Message-ID: <4C5AF5DD.8020409@earthlink.net> Date: Thu, 05 Aug 2010 10:33:17 -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.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Teco Boot References: <4C528979.7010006@oracle.com> <4C58584D.2010604@earthlink.net> <379B3F32-224C-46C0-8599-913AD85A803E@inf-net.nl> <4C596894.5050004@earthlink.net> <28D40890-32BE-4925-94DD-049E54B71B43@inf-net.nl> <4C599292.9090507@earthlink.net> <4C59C19B.4070101@earthlink.net> <0E35FDFA-F73F-4005-8354-87ECB7A4E12D@inf-net.nl> In-Reply-To: <0E35FDFA-F73F-4005-8354-87ECB7A4E12D@inf-net.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52551987018c06da3a2ce8551c02591b49350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [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, 05 Aug 2010 17:32:58 -0000 Hello Teco, Comments below. On 8/5/2010 1:27 AM, Teco Boot wrote: >>> No. We are getting out-of-scope. >>> The document is about link with undetermined characteristics. >>> P2P links are not in that category. >> >> I definitely don't agree with this conclusion. >> The links with undetermined characteristics can >> support time-bounded P2P links. There is no >> reason to declare P2P links out of scope. > > At least P2P is a special case. > Has this to do with our discussion? AODV often connects an ad hoc network with 100% P2P links. Are networks using AODV out of scope? > Can you come up with something other than p2p? For what purpose? >>>> I didn't even say that a host had to have >>>> a default router. >>> >>> Then, that host does not send packets. >>> (Assuming empty routing table and /128 (v6) or /32 (v4) address prefix). >> >> Bad assumption! > > Then, what is in the routing table? Whatever the host puts there. > And what mechanism takes care? Promiscuous mode can work, along with other approaches. > I still wonder how two hosts with off-link prefixes on same link can > communicate. 802.11 doesn't care about prefixes. What's the problem? >> One trivial example would be to just run in >> promiscuous mode, listen for addresses, and >> pretend that some neighbor is a router. > > Data plane populating routing table ?? Not unusual. Even DSR did this. > What about uni-directional link test ?? Life is hard, and then we die. >> I have other examples that are more normal :-) > > Please do so, previous one frightened me. Fear naught. >> I am not claiming that the other solutions are >> mine -- but there are numerous examples in the >> literature. > > Refs are OK. Or describe one. Your bait is lovely, but the adult in me demands that I not go there just now. >> As far as a host is concerned, topology >> exchange isn't necessary -- unless you call >> the simple fact of link establishment to be >> "topology exchange". And then our discussion >> fails, because we have so little vocabulary. > > We may end up in discussing the width of the grey zone between > host and router, and the exact borderlines. Or not, because I'm out of time and don't see much reward. > We agreed on three indications for classifying node a router. > Now on indications for hosts: Check. > Now I say: there are protocols for host-router relations, so host will > know on-line prefix and default gateway, or more specific routes. > But what about getting knowledge on routers for links to hosts, where > hosts have off-link prefixes? You're stuck on prefixes. It's a nasty affliction, but very widespread. > If there are protocols for such (and done in > a clean fashion), I call it routing. This, because hosts do not advertise > themselves to routers as part of the topology. This is where routing > complexity starts. This paragraph is full of holes. First, you have declared nodes using BGP to not be routers because BGP is not clean. Second, hosts don't advertise _anything_ as "part of the topology". Third, routing complexity arises from quite a few sources. Need I mention "policy"? Fourth, a router can route without running any routing protocol. Of course such a device would be quite cumbersome to deploy in the Internet, requiring human intervention to adapt to changes. But, as one tiny example, this is exactly how I first tested Mobile IP. Sometimes I'm not sure if you're serious when making these assertions. > Complexity is increased with RFC5942, with our RFC5889 in mind. > We don't configure on-link prefixes on our interfaces. > RFC5942 Host Behavior (3.1): > In IPv6, an address is on-link (with respect to a specific link), if > the address has been assigned to an interface attached to that link. > So one could say we do not comply to RFC5942. Luckily, RFC5942 is for > hosts. I'll be just as happy not to go there at all. >>>> In particular, I claim that hosts in an ad hoc >>>> network often must adhere to the developed >>>> address model. Of course they don't run AODV >>>> if they're not routers. >>> >>> OK, now were are there. How can the routers know the host is there? >> >> If the host transmits a packet, the routers can know. > > IMHO mix data plane and routing control plane is bad. IP is bad? There are numerous counterexamples. For instance, many liveness strategies readily utilize information about data plane traffic (instead of, say, keepalives). Again I am left wondering if you are tweaking me. >> If I remember correctly, the current addressing model does >> not legislate that all links have to be /128. It just >> says that SOME links appear to be /128, so that without >> additional information, protocols may not make too many >> assumptions about the connectivity properties of the link. > > It says no on-link subnet prefix is configured. > As a result, hosts are not supported. Some mechanism > is needed making the router aware that other nodes > are reachable via this interface. I call this routing. I call it chocolate syrup. Which is approximately equally valid until we know what "it" is. >> As many have pointed out, this world is not so black and >> white. > > Indeed. But it is quite dark for hosts, using this addressing model. > Routing enlighten. Teco, I can't really go on with this. Of course routing enlightens. Providing valid information is always enlightening (as opposed to, say, some discussions in this thread). You want to say that X is a router, even if it MUST NEVER forward any packets. I think this is nonsense, pure and simple. Maybe _also_ sophistry, and maybe _also_ a waste of time due to lack of entertainment value. >> Optionally. And, a node can forward packets >> based only on P2P routes. Such a node is, >> I claim, a router. No subnets are needed. > > Back to subject: addressing model is for routers. > You disagreed with title change. Do I _really_ have to unwind this thread for you? I was responding to _your_ digression. > I expect some argumentation. I did't see such. Please look again. Or I will save you the trouble: i) hosts must obey the considerations in the draft ii) [autoconf] producing a protocol that does not enable hosts to get addresses is plain silly. From these basic (invisible to you?) statements on my part, we started traveling through the twilight zone where routers don't forward packets and, as a sort of very strange converse, P2P route table entries get no respect even though ALL manet routing protocols use them. Traveling through this twilight zone, many people in this group have acquired an ability to profess that it's easier to configure routers than hosts, regardless of 30 years of evidence to the contrary. You might very well rightfully ask why I even try to make any correction to the situation. I know I am asking myself that question. >>>> Is there some weird magic that requires every >>>> /128 subnet to have an AODV subnet router? >>>> If not, then your conclusion is false. >>> >>> There is no magic. >>> Point is: with /128, there are no hosts. Not on links with undetermined >>> characteristics. >> >> Teco -- this is just wrong. >> >> Just because a network interface has undetermined >> properties doesn't mean that the host utilizing >> that network interface can't transmit or receive >> packets. Otherwise, what would be the point of >> powering the interface? > > You miss the point. > When some say routers, they don't intent the node MUST > forward packets. When some say routers, they mean boxes with multiple interfaces. When some say routers, they include boxes that MUST NEVER forward packets. When some say routers, they mean <... ding! time's up! game over ...> > The intention is that routing protocols > are involved getting the routing tables populated. And > bypass limitations for hosts. This is allowed, because > routers understand the complexity. Routers don't understand anything. They're machines, operating as programmed. Oh, you meant that a routing protocol is a program of higher complexity than <... what? ...>. Of course it's far more complex than {} [{} == ]. > Maybe. > Any valid received RA info is reflected in default router list. > But how can a host without on-link addresses populate the router > routing table? Here's my challenge to you. Find a grad student in networking who could NOT figure this out. Of course, I am assuming that you do NOT mean what you stated -- namely that the host must populate the router's routing table. If somehow the authors of 5942 have legislated that hosts cannot transmit packets over wireless interfaces with legal IP addresses, I send my regrets but I can't fight that battle right now. Regards, Charlie P. From charles.perkins@earthlink.net Thu Aug 5 10:57: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 0EB213A6B36 for ; Thu, 5 Aug 2010 10:57:36 -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.502, 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 JY-nBn7RPpfB for ; Thu, 5 Aug 2010 10:57:35 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id CF44F3A6A7D for ; Thu, 5 Aug 2010 10:57:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Ubvk+lQGudu4giKYPWD7k9NUqm2HiAfPMggxanqpmnHTBOjrxATylPW0nIEK8Yht; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.158]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Oh4he-0007Hq-VD; Thu, 05 Aug 2010 13:58:04 -0400 Message-ID: <4C5AFB9F.3040206@earthlink.net> Date: Thu, 05 Aug 2010 10:57:51 -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.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Henning Rogge References: <4C528979.7010006@oracle.com> <201008040756.04650.henning.rogge@fkie.fraunhofer.de> <4C596602.1060308@earthlink.net> <201008051039.03011.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <201008051039.03011.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5236d1d18acb711b6850ba8845406fe08c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [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, 05 Aug 2010 17:57:36 -0000 Hello Henning, Comments/follow-up below... On 8/5/2010 1:38 AM, Henning Rogge wrote: >> What if your host gets an address by running >> "autoconf.exe", which is not a routing program? > Does your host set up a route towards the next router and maintains it if the > topology data from the router changes ? If yes I would say it's a primitive > router too. If no, it's not. What if it treats a particular route table entry as a point-to-point link? What if it treats a particular route table entry as a default route? What if it hears a RA message from a neighbor? Seems to me we're having to bend over backwards to call things "routers" in order to justify making a wrong name for the document. >> What if the host does not? Or, do you mean to say >> that this discussion is a way to legislate that all >> hosts must use DHCP? > I don't think I ever said this. I just presented an example that the address > model is not necessary for running a node in a MANET that use the autoconf > address model. > > Yes, you CAN use it... but you don't need to. I'm glad to hear that. But some hosts are still going to have to abide by the autoconf addressing model, unless unnecessary restrictions are put into place. Changing the name of the document, it seems to me, increases the danger that these unnecessary restrictions _will_ be enacted. >> ... suppose at some point there is an autoconf.exe. >> It should be a way for a host to get an address. >> Its connection to the MANET would, presumably allow >> it to use this address. Or, do you mean to say that >> "address allocation" == "connection"? > I don't see any reason why an autoconfiguration protocol developed by this > group would only run on interfaces of routers. I'm glad to hear that. So why make the restriction on the document name?? > >>> If you have a router with a policy that limits the routers functionality >>> (in terms of the routing protocol), you could just write a >>> compact/optimized version of the needed software part for it. >> >> main() >> { >> system ("get_address"); >> if (routing) fail(); /* My compact routing code */ >> } >> >> Am I a router? > I don't see any routing code of a routing protocol. But I don't see your > problem too. I'm sorry you don't like my routing code. Wasn't it claimed that a node can be a router even if it always advertised willingness == 0? My problem is that in order to justify the restrictive title, some people are bending over backwards to call darned near anything a router. >> This is a political argument not based on the needs >> of the addressability, connectivity, or goals of >> making an ad hoc network. Insofar as you may be >> nonetheless correct, I begin to believe that I have >> zero insight into the technical goals of the discussion. >> >>> (I don't say they are right, but we will get people with strange comments >>> on the address model with both titles) >> >> Please tell me if my comments are "strange". > I think the problem you stated is that people can say "the title says it's > only for routers, so it is not enough for my usecase and I need something > different". _my_ usecase?? My usecase is that hosts should be able to get addresses. Do you think this is a corner case? > If we not change the title we might get "the title says it's for all nodes, > but I cannot force my users to install a special interface configuration on > their smartphones, so I need something different." Using this argument, we must immediately destroy the great majority of IETF protocol specifications. > There are nodes in MANET that are a grey area between host and router. Because > of this we cannot make a clear statement on what nodes the autoconf address > model should be used. As far as I can recall, no one has made ANY nonpolitical argument to indicate why hosts do not adhere to the addressing model for [autoconf]. Do you remember any? > Most of the WG seems to think it's better to restrict the scope a little bit > more and let people use it for other things than the defined scope if they > think it's right (at least that's how I understand the consensus of the > group). I still think it's silly to make an [autoconf] protocol that is prohibited for use by hosts. Of course, any host that wanted to use it would have to actually execute the code -- isn't that a tautology? So the smartphone point has absolutely zero force in making this determination. I do not understand the consensus of the group. I only speak for myself, and I'm honestly trying to see if there is even an iota of technical justification for this change. I might be wrong! But until you or someone enlightens me I'll still need to try to understand the relevance of your points. Regards, Charlie P. From joseph.macker@nrl.navy.mil Thu Aug 5 11:21: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 AA4783A6912 for ; Thu, 5 Aug 2010 11:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 1ZEi6uAZJjcI for ; Thu, 5 Aug 2010 11:21:31 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id DCD073A6A7D for ; Thu, 5 Aug 2010 11:21:30 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id o75ILrNd023583; Thu, 5 Aug 2010 14:21:53 -0400 Received: from vpn217206.nrl.navy.mil ([132.250.217.206]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2010080514215329493 ; Thu, 05 Aug 2010 14:21:53 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Joe Macker In-Reply-To: <201008030725.23669.henning.rogge@fkie.fraunhofer.de> Date: Thu, 5 Aug 2010 14:21:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4FFB9EE3-FF8A-45FD-AA6E-8CBDED612C74@nrl.navy.mil> References: <201008030725.23669.henning.rogge@fkie.fraunhofer.de> To: Henning Rogge 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: Thu, 05 Aug 2010 18:21:32 -0000 We hacked something like this many years ago in working manet stub = networks and it worked but had some performance limitations.=20 I presented a slide somewhere in manet many years ago and the basic = description was in a few reports and a book chapter. The unicast autoconf builds out naturally at the connected edges for the = stub area case which was the nice feature. On Aug 3, 2010, at 1:25 AM, Henning Rogge wrote: > Hello, >=20 > is there a reason why we cannot place an DHCPv6-relay on every node = for its=20 > neighbors ? Each node requesting an address/prefix will send out an IP=20= > datagram with an anycast destination an a linklocal source, which will = be=20 > forwarded by its neighbors (with a unicast) to the DHCPv6-server. >=20 > After a node has it's address it switch from DHCP-client to DHCP-relay = mode,=20 > to allow other nodes to connect through this node to the server. >=20 > Henning Rogge >=20 > --=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 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From charles.perkins@earthlink.net Thu Aug 5 15:16: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 9D09E3A6999 for ; Thu, 5 Aug 2010 15:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.401, 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 Cl4Bqk5UIGpB for ; Thu, 5 Aug 2010 15:16:31 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 443AB3A687F for ; Thu, 5 Aug 2010 15:16:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=FEX+uZHhJkimGn2KQnH8kd+2mVZ3/hbsY6BLIBMnvFoxq4DVLjOQSr6V0UV2BvuS; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.158]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Oh8kH-0008Ux-AX; Thu, 05 Aug 2010 18:17:01 -0400 Message-ID: <4C5B3854.3050706@earthlink.net> Date: Thu, 05 Aug 2010 15:16:52 -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.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Emmanuel Baccelli References: <4C528979.7010006@oracle.com><201008040756.04650.henning.rogge@fkie.fraunhofer.de> <4C596602.1060308@earthlink.net><201008051039.03011.henning.rogge@fkie.fraunhofer.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f526857921bea0441b29a9cdeb34832a54b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd:Forgotone [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, 05 Aug 2010 22:16:32 -0000 Hello Emmanuel, > Maybe it would be easier to focus on the counterpart instead, and > consider the question "what is the definition of a host?". It seems to > me that the devices we are aiming to configure are typically capable of > things that hosts can't do (including, for instance, forwarding traffic > on behalf of other devices, if necessary). I don't think so. If a device is a host and not a router, it shouldn't be forwarding packets. I'm sure that there are going to be non-routing hosts in wireless ad hoc networks. From previous design work, I know that it is absolutely straightforward to allow a host to request an address and get one (if available). You might check [from year 2001]: www.cs.ucsb.edu/~ebelding/txt/autoconf.txt We seemed to know more on average in 2001, than has been displayed here lately in the autoconf WG. A node does NOT have to forward packets to request an address! > "hosts are considered to be connected to a MANET only through > a router, and thus, the MANET can be considered as comprising of only > routers". Do you _really_ want to exclude hosts from your network? Where will the applications reside? Hmmm... a network without hosts... Seems like a niche market. But, ad hoc networks are still a niche market, so this would be a niche niche market. > This architectural consideration thus separated the issue of > "configuring routers" from the issue of "configuring hosts" in this > context, and the rough consensus was that we would first focus on > configuring routers. Which lead us to where we are now. When was this rough consensus? Do you mean in Maastricht? Or, before? If the latter, I surely missed it. Regards, Charlie P. From thomas@thomasclausen.org Fri Aug 6 08:52: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 BF3CC3A67A2 for ; Fri, 6 Aug 2010 08:52: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=[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 gPrkRcrFsiLg for ; Fri, 6 Aug 2010 08:52: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 C22D228C0E9 for ; Fri, 6 Aug 2010 08:52:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 7E3553236DB1; Fri, 6 Aug 2010 08:53:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from static-host.sme (AMontsouris-552-1-15-16.w86-212.abo.wanadoo.fr [86.212.102.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 5F2083228449; Fri, 6 Aug 2010 08:53:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Thomas Heide Clausen In-Reply-To: <4C5B3854.3050706@earthlink.net> Date: Fri, 6 Aug 2010 17:53:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C528979.7010006@oracle.com><201008040756.04650.henning.rogge@fkie.fraunhofer.de> <4C596602.1060308@earthlink.net><201008051039.03011.henning.rogge@fkie.fraunhofer.de> <4C5B3854.3050706@earthlink.net> To: "Charles E. Perkins" X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd:Forgotone [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, 06 Aug 2010 15:52:36 -0000 On Aug 6, 2010, at 00:16 , Charles E. Perkins wrote: >> "hosts are considered to be connected to a MANET only through >> a router, and thus, the MANET can be considered as comprising of only >> routers". >=20 > Do you _really_ want to exclude hosts from your network? > Where will the applications reside? Hmmm... a network without > hosts... Seems like a niche market. But, ad hoc networks > are still a niche market, so this would be a niche niche > market. User applications (regular user applications) reside on hosts. Hosts are = accessing the network by way of being connected to (i.e. one IP hop away = from) a router.=20 The connectivity between a host and a router is a "classic IP link", and = there are already excellent protocols in existence for managing also = autoconfiguration of addresses for hosts on classic IP links.=20 The connectivity between routers is.....who knows? Maybe a MANET, maybe = an OSPF network, maybe an ISIS network, and maybe links between routers = have "undetermined connectivity properties" -- or not, they may be of = NBMA or P2P or telepathic nature. However, that's a matter for routers = to figure out and manage; hosts are exposed to a classic IP link and are = isolated by an IP hop from any specific connectivity properties of the = connectivity/links between routers. Of course, there *may* be applications (for example, the routing demon) = running on routers and exposed to the specific connectivity properties = of the connectivity/links between routers. These, and only these = (non-user) applications should be sufficiently aware of these properties = to operate correctly. User-applications reside on hosts, separated by an = IP hop from any "strangeness" between routers, and exposed to = well-defined properties of a classic IP link. That is analogous to how the Internet otherwise work. >> This architectural consideration thus separated the issue of >> "configuring routers" from the issue of "configuring hosts" in this >> context, and the rough consensus was that we would first focus on >> configuring routers. Which lead us to where we are now. >=20 > When was this rough consensus? Do you mean in Maastricht? > Or, before? If the latter, I surely missed it. Now, you made me go look it up exactly... This particular point was discussed - at length - at IETF'67 in 2006 in = San Diego, where it received (in my recollection) wide consensus; in = part because of its analogy with the "regular Internet". Sincerely yours, Thomas= From charles.perkins@earthlink.net Fri Aug 6 09:56: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 E42533A67D1 for ; Fri, 6 Aug 2010 09:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.365, 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 Fcs78pgwCDcp for ; Fri, 6 Aug 2010 09:56:11 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 9EEAA3A67C3 for ; Fri, 6 Aug 2010 09:56:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=UWIwwrrlHdIjQ5qDP4d/8PPjqtXyOZ6Us1nk80kE+F3R6qbdA/sOCeZTfFZDJJGx; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.137]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OhQDp-0008Ay-VO; Fri, 06 Aug 2010 12:56:42 -0400 Message-ID: <4C5C3EC8.50009@earthlink.net> Date: Fri, 06 Aug 2010 09:56:40 -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.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Thomas Heide Clausen References: <4C528979.7010006@oracle.com><201008040756.04650.henning.rogge@fkie.fraunhofer.de> <4C596602.1060308@earthlink.net><201008051039.03011.henning.rogge@fkie.fraunhofer.de> <4C5B3854.3050706@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5254521046cf5b6b75a02ea55e7e4db714350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd:Forgotone [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, 06 Aug 2010 16:56:13 -0000 Hello Thomas, I said: >> Do you _really_ want to exclude hosts from your network? >> Where will the applications reside? You said: > User applications (regular user applications) reside on hosts. Hosts are > accessing the network by way of being connected to (i.e. one IP hop away > from) a router. Of course I do not have a problem with running applications on MANET routers. I have proposed this for many years -- and in fact I do not in any way require that the applications reside on hosts that are one hop away from a router. My question was partly in jest -- but I do fully expect that non-routing hosts will be found in many or perhaps even most ad hoc networks. For instance, we will have sensor fields and transmit-only data aggregators (both of which do not need to be routers, but are likely to need addresses). I keep thinking this is totally obvious! > The connectivity between a host and a router is a "classic IP link", > and there are already excellent protocols in existence for managing > also autoconfiguration of addresses for hosts on classic IP links. My objection has been to disqualify non-routing hosts from receiving addresses by way of an [autoconf] protocol. There are of course known protocols (excellent or not, does not matter here) for configuring "classic hosts" on "classic IP links". I reckon we mean the same thing by those terms. My point is that there are almost certainly going to be non-routing hosts in I would have just said "MANETs", but now we have so little agreement that we don't even know what a MANET is any more. > The connectivity between routers is.....who knows? Maybe a MANET, > maybe an OSPF network, maybe an ISIS network, and maybe links between > routers have "undetermined connectivity properties" -- or not, they > may be of NBMA or P2P or telepathic nature. However, that's a matter > for routers to figure out and manage; hosts are exposed to a classic > IP link and are isolated by an IP hop from any specific connectivity > properties of the connectivity/links between routers. Here I have to disagree. A host may have an 802.11 link to a router, and be subject to every single last problem of indeterminate range, interference, link-local ambiguity, and the other concepts which have proved so difficult for [autoconf] to resolve (regardless of so much reputable research available). And, moreover, it's not up to the "routers". It's up to "us", because we're designing the routers (at least in [manet] wg, not in [autoconf]). Moreover, if a MANET router can work better by transacting new protocol with a host, then (a) the host may then considered to be something besides a "classic host", and (b) why not? Let's figure it out. But this does NOT mean that a network of the abovementioned variety has to REQUIRE changes to classic hosts; as an example, NEMO has made a lot of changes but still allows "classic" hosts to reside on mobile networks. Our situation is a bit different, insofar as mobile wireless hosts still must pay due respect to the realities of wireless. > Of course, there *may* be applications (for example, the routing demon) > running on routers and exposed to the specific connectivity properties > of the connectivity/links between routers. These, and only these > (non-user) applications should be sufficiently aware of these properties > to operate correctly. User-applications reside on hosts, separated by > an IP hop from any "strangeness" between routers, and exposed to > well-defined properties of a classic IP link. I also disagree with this. Numerous studies have shown that applications can benefit from knowledge of bit-error rate, link capacity, jitter, and so on. Of course we'd prefer that applications not have to pay attention to CDMA vs. 802.11, etc. Nevertheless, I am sure that in a face-to-face meeting on this subject we would quickly find that we are in substantially complete agreement. >>> >> This architectural consideration thus separated the issue of >>> >> "configuring routers" from the issue of "configuring hosts" in this >>> >> context, and the rough consensus was that we would first focus on >>> >> configuring routers. Which lead us to where we are now. ... > This particular point was discussed - at length - at IETF'67 in 2006 in > San Diego, where it received (in my recollection) wide consensus; in part > because of its analogy with the "regular Internet". Surely, "configuring" routers and hosts should be done differently. This does NOT imply: (a) hosts should be barred from using the address allocation protocol established for MANET routers, or (b) hosts should run useless router code in order to make use of said address allocation protocol, or (c) the [autoconf] address allocation protocol design should proceed on the assumption that non-routing hosts are out of scope. Regards, Charlie P. From thomas@thomasclausen.org Fri Aug 6 10:22:58 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 932533A6892 for ; Fri, 6 Aug 2010 10:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.376 X-Spam-Level: * X-Spam-Status: No, score=1.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQEmzCmK+doj for ; Fri, 6 Aug 2010 10:22:57 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 435003A6879 for ; Fri, 6 Aug 2010 10:22:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 13B5B3236DB7; Fri, 6 Aug 2010 10:23:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.225.71.210] (unknown [90.84.146.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id DE5783236DB8; Fri, 6 Aug 2010 10:23:27 -0700 (PDT) References: <4C528979.7010006@oracle.com> <201008040756.04650.henning.rogge@fkie.fraunhofer.de> <4C596602.1060308@earthlink.net> <201008051039.03011.henning.rogge@fkie.fraunhofer.de> <4C5B3854.3050706@earthlink.net> <4C5C3EC8.50009@earthlink.net> In-Reply-To: <4C5C3EC8.50009@earthlink.net> Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <8C0A8E8A-B26C-4330-9173-94530FEDD350@thomasclausen.org> X-Mailer: iPhone Mail (8A293) From: Thomas Heide Clausen Date: Fri, 6 Aug 2010 19:22:32 +0200 To: "Charles E. Perkins" Cc: "autoconf@ietf.org" , Emmanuel Baccelli Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd:Forgotone [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, 06 Aug 2010 17:22:58 -0000 Charlie, You suggest a face-to-face meeting. As you know I will be in your neck of th= e woods next week, so let's discuss, then ... Wg-chair-hat-on:=20 If we do that, we do owe it to the wg to report both the arguments and the o= utcome of the discussions here on the list, as I believe that both are valua= ble for the wg. Although (still wearing that hat) I would very much like for= as much of the discussions to be in public (ie on the list).... Wg-chair-hat-off: I'll respond in more details later, but I have suitcases to pack ... --=20 Thomas Clausen http://www.thomasclausen.org/ On 6 ao=C3=BBt 2010, at 18:56, "Charles E. Perkins" wrote: > Hello Thomas, >=20 > I said: >=20 >>> Do you _really_ want to exclude hosts from your network? >>> Where will the applications reside? >=20 > You said: >=20 >> User applications (regular user applications) reside on hosts. Hosts are >> accessing the network by way of being connected to (i.e. one IP hop away >> from) a router. >=20 > Of course I do not have a problem with running applications > on MANET routers. I have proposed this for many years -- > and in fact I do not in any way require that the applications > reside on hosts that are one hop away from a router. >=20 > My question was partly in jest -- but I do fully > expect that non-routing hosts will be found in many > or perhaps even most ad hoc networks. For instance, > we will have sensor fields and transmit-only data > aggregators (both of which do not need to be routers, > but are likely to need addresses). I keep thinking > this is totally obvious! >=20 >=20 >> The connectivity between a host and a router is a "classic IP link", >> and there are already excellent protocols in existence for managing >> also autoconfiguration of addresses for hosts on classic IP links. >=20 > My objection has been to disqualify non-routing hosts from receiving > addresses by way of an [autoconf] protocol. There are of course known > protocols (excellent or not, does not matter here) for configuring > "classic hosts" on "classic IP links". I reckon we mean the same > thing by those terms. >=20 > My point is that there are almost certainly going to be non-routing > hosts in > I would have just said "MANETs", but now we have so little agreement > that we don't even know what a MANET is any more. >=20 >=20 >> The connectivity between routers is.....who knows? Maybe a MANET, >> maybe an OSPF network, maybe an ISIS network, and maybe links between >> routers have "undetermined connectivity properties" -- or not, they >> may be of NBMA or P2P or telepathic nature. However, that's a matter >> for routers to figure out and manage; hosts are exposed to a classic >> IP link and are isolated by an IP hop from any specific connectivity >> properties of the connectivity/links between routers. >=20 > Here I have to disagree. A host may have an 802.11 link to a router, > and be subject to every single last problem of indeterminate range, > interference, link-local ambiguity, and the other concepts which have > proved so difficult for [autoconf] to resolve (regardless of so much > reputable research available). >=20 > And, moreover, it's not up to the "routers". It's up to "us", > because we're designing the routers (at least in [manet] wg, > not in [autoconf]). Moreover, if a MANET router can work better > by transacting new protocol with a host, then (a) the host may > then considered to be something besides a "classic host", and > (b) why not? Let's figure it out. But this does NOT mean that > a network of the abovementioned variety has to REQUIRE changes > to classic hosts; as an example, NEMO has made a lot of changes > but still allows "classic" hosts to reside on mobile networks. > Our situation is a bit different, insofar as mobile wireless hosts > still must pay due respect to the realities of wireless. >=20 >=20 >> Of course, there *may* be applications (for example, the routing demon) >> running on routers and exposed to the specific connectivity properties >> of the connectivity/links between routers. These, and only these >> (non-user) applications should be sufficiently aware of these properties >> to operate correctly. User-applications reside on hosts, separated by >> an IP hop from any "strangeness" between routers, and exposed to >> well-defined properties of a classic IP link. >=20 >=20 > I also disagree with this. Numerous studies have shown that > applications can benefit from knowledge of bit-error rate, > link capacity, jitter, and so on. Of course we'd prefer that > applications not have to pay attention to CDMA vs. 802.11, > etc. Nevertheless, I am sure that in a face-to-face meeting > on this subject we would quickly find that we are in substantially > complete agreement. >=20 >=20 >>>> >> This architectural consideration thus separated the issue of >>>> >> "configuring routers" from the issue of "configuring hosts" in this >>>> >> context, and the rough consensus was that we would first focus on >>>> >> configuring routers. Which lead us to where we are now. >=20 > ... >=20 >> This particular point was discussed - at length - at IETF'67 in 2006 in >> San Diego, where it received (in my recollection) wide consensus; in part= >> because of its analogy with the "regular Internet". >=20 > Surely, "configuring" routers and hosts should be > done differently. This does NOT imply: > (a) hosts should be barred from using the address > allocation protocol established for MANET routers, or > (b) hosts should run useless router code in order to > make use of said address allocation protocol, or > (c) the [autoconf] address allocation protocol design > should proceed on the assumption that non-routing > hosts are out of scope. >=20 >=20 > Regards, > Charlie P. >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From jch@pps.jussieu.fr Mon Aug 9 09: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 8135B3A6968 for ; Mon, 9 Aug 2010 09:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34qBrnqkSkFt for ; Mon, 9 Aug 2010 09:05:31 -0700 (PDT) Received: from witko.kerneis.info (witko.kerneis.info [213.186.56.95]) by core3.amsl.com (Postfix) with ESMTP id 7702D3A6850 for ; Mon, 9 Aug 2010 09:05:31 -0700 (PDT) Received: from [188.33.111.54] (helo=trurl.pps.jussieu.fr) by witko.kerneis.info with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1OiUrB-0007Kc-JS for autoconf@ietf.org; Mon, 09 Aug 2010 18:05:46 +0200 Received: from jch by trurl.pps.jussieu.fr with local (Exim 4.72) (envelope-from ) id 1OiUqn-000292-5N for autoconf@ietf.org; Mon, 09 Aug 2010 18:05:21 +0200 From: Juliusz Chroboczek To: "autoconf\@ietf.org" Date: Mon, 09 Aug 2010 18:05:21 +0200 Message-ID: <87fwynsrem.fsf@trurl.pps.jussieu.fr> MIME-Version: 1.0 Content-Type: text/plain X-SA-Exim-Connect-IP: 188.33.111.54 X-SA-Exim-Mail-From: jch@pps.jussieu.fr X-SA-Exim-Scanned: No (on witko.kerneis.info); SAEximRunCond expanded to false Subject: [Autoconf] draft-chroboczek-ahcp-00 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 16:05:32 -0000 Dear list, I have just submitted draft-chroboczek-ahcp-00 to the Internet-Drafts repository. http://www.ietf.org/id/draft-chroboczek-ahcp-00.txt Abstract The Ad Hoc Configuration Protocol is a protocol for automatically configuring nodes in a multihop mesh network. It is designed to replace DHCPv4, DHCPv6 and IPv6 Router Advertisements in networks where these protocols are difficult or impossible to deploy. AHCP has been shown to be a robust and flexible protocol for autoconfiguring nodes in ad-hoc mesh networks. While I am not proposing it as it stands as a standards-track protocol, I would like to suggest that the experience of AHCP should be taken into account by this group. Regards, Juliusz Chroboczek From emmanuel.baccelli@gmail.com Mon Aug 9 10:29: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 4E85B3A694A for ; Mon, 9 Aug 2010 10:29: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 waHiixT44GJx for ; Mon, 9 Aug 2010 10:29: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 C063828C10D for ; Mon, 9 Aug 2010 10:29:17 -0700 (PDT) Received: by eyb7 with SMTP id 7so4012847eyb.31 for ; Mon, 09 Aug 2010 10:29:51 -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=h0BQU4wz8s8bQBImeCMr2FiverRN2aiZSEhgNhUP8UM=; b=pIawzyfMevASzbsOYnU8iv1cyFd69Ifr3ehMl2Bk+sxFJJZozKHhmqnvBWfCQYlFUe 8LKgkJpTMQpvFYc3rfPBRcFyYFW/3TPfEVlIhxJLM05ukfa+Jg1JneXNj0NIyGRm8ybl WrD/MrjrfELLSgpUAz3SE6aF3LBJidNMUOcQk= 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=L7kMUTFyTwYupA+Ax5555Uy4i1p6USaHbcOHRusS3ddd4LwVpjPrtvJPmAjLu8ZHTg 0CwiyWDTqO7ntFDD/XCu0KRkjmVyQFbZqTgSlDGCMPCw8Rv8EHKTZPUgpI9hJOWUvPxD fqBtuJftx/fgxmikE7DiQTQjLhitf49Mm26Pk= Received: by 10.213.4.16 with SMTP id 16mr11756316ebp.17.1281374991542; Mon, 09 Aug 2010 10:29:51 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.14.37.4 with HTTP; Mon, 9 Aug 2010 10:29:30 -0700 (PDT) In-Reply-To: <4C5C3EC8.50009@earthlink.net> References: <4C528979.7010006@oracle.com> <201008040756.04650.henning.rogge@fkie.fraunhofer.de> <4C596602.1060308@earthlink.net> <201008051039.03011.henning.rogge@fkie.fraunhofer.de> <4C5B3854.3050706@earthlink.net> <4C5C3EC8.50009@earthlink.net> From: Emmanuel Baccelli Date: Mon, 9 Aug 2010 19:29:30 +0200 X-Google-Sender-Auth: KCggLE7XOPztKWHWeq4P37azNJQ Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=0015174a0fa231ec9d048d675d7a Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd:Forgotone [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: Mon, 09 Aug 2010 17:29:19 -0000 --0015174a0fa231ec9d048d675d7a Content-Type: text/plain; charset=ISO-8859-1 Hi Charlie, On Fri, Aug 6, 2010 at 6:56 PM, Charles E. Perkins < charles.perkins@earthlink.net> wrote: > > > Surely, "configuring" routers and hosts should be > done differently. We are in agreement here ;) > This does NOT imply: > (a) hosts should be barred from using the address > allocation protocol established for MANET routers, or > we are also in agreement here. > (b) hosts should run useless router code in order to > make use of said address allocation protocol, or > same as above: violent agreement. > (c) the [autoconf] address allocation protocol design > should proceed on the assumption that non-routing > hosts are out of scope. > > here on the other hand, I think I disagree. It is a priori more difficult to provide autoconfiguration for nodes which have heterogeneous capabilities, rather than to provide an autoconfiguration solution for nodes which have homogeneous capabilities -- especially if nodes all have the most capabilities, i.e. they are all routers. So at this point, either (i) there is priori art that provides autoconfiguration for nodes which have heterogeneous capabilities, and then let's consider it, or (ii) there is no prior art and then let's do the easiest step first: focus on providing an autoconfiguration solution for routers. Provided that your points (a) and (b) are agreed on, does this make sense to you? I remember you mentioning that there is indeed prior art. The way I understand it, this prior art is something that the effort stemming from second item in the proposed charter should seriously consider. regards, Emmanuel --0015174a0fa231ec9d048d675d7a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Charlie,


On Fri, Aug 6, 2010 at 6= :56 PM, Charles E. Perkins <charles.perkins@earthlink.net> wrote:<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;">

Surely, "configuring" routers and hosts should be
done differently.


We are in= agreement here ;)

=A0
=A0This does NOT imply:
(a) hosts should be barred from using the address
=A0 =A0allocation protocol established for MANET routers, or
=A0

we are also in agreement here.

=A0
(b) hosts should run useless router code in order to
=A0 =A0make use of said address allocation protocol, or


same as above: violent agreement.

=A0
(c) the [autoconf] address allocation protocol design
=A0 =A0should proceed on the assumption that non-routing
=A0 =A0hosts are out of scope.



here on the other hand,= I think I disagree. It is a priori more difficult to provide autoconfigura= tion for nodes which have heterogeneous capabilities, rather than to provid= e=A0an autoconfiguration solution for nodes which have homogeneous capabili= ties -- especially if nodes all have the most capabilities, i.e. they are a= ll routers.=A0

So at this point, either (i) there is priori art that p= rovides=A0autoconfiguration=A0for nodes which have heterogeneous capabiliti= es, and then let's consider it, or (ii) there is no prior art and then = let's do the easiest step first: focus on=A0providing an autoconfigurat= ion solution for routers. Provided that your points (a) and (b) are agreed = on, does this make sense to you?=A0

I remember you mentioning that there is indeed prior ar= t. The way I understand it, this prior art is something that the effort ste= mming from second item in the proposed charter should seriously consider. = =A0

regards,

Emmanuel
<= br> --0015174a0fa231ec9d048d675d7a-- From charles.perkins@earthlink.net Mon Aug 9 10:54: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 469D328C121 for ; Mon, 9 Aug 2010 10:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.057 X-Spam-Level: X-Spam-Status: No, score=-1.057 tagged_above=-999 required=5 tests=[AWL=-0.872, 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 15u4O6WODsl7 for ; Mon, 9 Aug 2010 10:54:32 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 6048F28C11D for ; Mon, 9 Aug 2010 10:54:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=rahCrvuSmpBAwesTJMcrxvxgrpMOP6mZNdFU95xXwDrCsOpd2+IDbhgs8SjYVBEr; 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.108]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OiWZ0-0000zo-Bl; Mon, 09 Aug 2010 13:55:06 -0400 Message-ID: <4C6040F6.2020109@earthlink.net> Date: Mon, 09 Aug 2010 10:55:02 -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.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Emmanuel Baccelli References: <4C528979.7010006@oracle.com><201008040756.04650.henning.rogge@fkie.fraunhofer.de> <4C596602.1060308@earthlink.net><201008051039.03011.henning.rogge@fkie.fraunhofer.de> <4C5B3854.3050706@earthlink.net> <4C5C3EC8.50009@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52a0bfeb044ff03748e4df8dcf22e3fef3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications(Fwd:Forgotone [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: Mon, 09 Aug 2010 17:54:34 -0000 Hello Emmanuel, To answer your implied request: On 8/9/2010 10:29 AM, Emmanuel Baccelli wrote: > (c) the [autoconf] address allocation protocol design > should proceed on the assumption that non-routing > hosts are out of scope. > > > > here on the other hand, I think I disagree. ... > So at this point, either (i) there is priori art that > provides autoconfiguration for nodes which have heterogeneous > capabilities, and then let's consider it, ... > I remember you mentioning that there is indeed prior art. Here is a link to prior art, which I mentioned in a previous email to you on this list: > ....... You might check [from year 2001]: > www.cs.ucsb.edu/~ebelding/txt/autoconf.txt What do you think about that? But, maybe more to the point, I know I have seen a good half-dozen distinct approaches to this problem. They have various advantages and disadvantages, but they share one trait: - they all provide addresses for both forwarding nodes and non-forwarding nodes. Right now I can't think of a good approach that actually does disqualify hosts. Of course it's not a democracy, and the other authors are not in the IETF. I guess they don't like to have five-year debates about what is a router and what is a link. But they are very sharp people. I would have thought that their insight, experience, development, and testing might count for _something_. Regards, Charlie P. From emmanuel.baccelli@gmail.com Wed Aug 11 04:51: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 0ACF13A6844 for ; Wed, 11 Aug 2010 04:51:12 -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 tkiXhy7VNVJq for ; Wed, 11 Aug 2010 04:51:10 -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 42DF93A682A for ; Wed, 11 Aug 2010 04:51:09 -0700 (PDT) Received: by eyb7 with SMTP id 7so4914314eyb.31 for ; Wed, 11 Aug 2010 04:51:45 -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=kzsweyI5iICMQGZVeglgnKTKvDluiyVhEuqBHPTCnU0=; b=DpV47uzbFKuuMahtDpxxY80/7j2mhg5nLIiV5fXGD5B7FXhT5F9GxhU2ijbIk7Tmn5 A6TUSkksDzU9UYt5lje8T7hV1tpDGH2MP+uFgim6pbJ0rn54tylW/lIkeS/P9xaQgaGb n10vbmpbsvpCy+iMa2Qrz69XTsyzDX/9Afnkg= 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=dkcSQeoK3x/Euz624u1AJlC5Yat5jrg97FdEMGvo3Dz9fUCCvvifyp2LZ8xPP36t+i UJIT3kTNnpeUznUNk47MYsDnUH/ybLYWpUtQP0PXGtSnIBpKkr+MHcFq0BWnqyMMJ+Jf FREpnZ5S0Tq5K7Z7hNOVJoINeRSrtT5ETBcz0= Received: by 10.213.62.206 with SMTP id y14mr5722812ebh.34.1281527505577; Wed, 11 Aug 2010 04:51:45 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.14.37.4 with HTTP; Wed, 11 Aug 2010 04:51:25 -0700 (PDT) In-Reply-To: <4C6040F6.2020109@earthlink.net> References: <4C528979.7010006@oracle.com> <201008040756.04650.henning.rogge@fkie.fraunhofer.de> <4C596602.1060308@earthlink.net> <201008051039.03011.henning.rogge@fkie.fraunhofer.de> <4C5B3854.3050706@earthlink.net> <4C5C3EC8.50009@earthlink.net> <4C6040F6.2020109@earthlink.net> From: Emmanuel Baccelli Date: Wed, 11 Aug 2010 13:51:25 +0200 X-Google-Sender-Auth: Zj9OiJ4A6x1u0238gmVoWbwJFho Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=00c09f8c1c7cbd6987048d8adff5 Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications(Fwd:Forgotone [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: Wed, 11 Aug 2010 11:51:12 -0000 --00c09f8c1c7cbd6987048d8adff5 Content-Type: text/plain; charset=ISO-8859-1 Hi Charlie, On Mon, Aug 9, 2010 at 7:55 PM, Charles E. Perkins < charles.perkins@earthlink.net> wrote: > Hello Emmanuel, > > > ....... You might check [from year 2001]: >> >> www.cs.ucsb.edu/~ebelding/txt/autoconf.txt >> > > What do you think about that? > > But, maybe more to the point, I know I have seen a > good half-dozen distinct approaches to this problem. > I think this approach is interesting and should definitely be considered with the half-dozen others you hint at, in parallel of the DHCP-based approach that is aimed at. As far as I understood, this is the spirit of the second item in the proposed charter. Emmanuel --00c09f8c1c7cbd6987048d8adff5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Charlie,

On Mon, Aug 9, 2010 at 7:55 P= M, Charles E. Perkins <charles.perkins@earthlink.net> wrote:
Hello Emmanuel,


=A0....... =A0 =A0 =A0 =A0 You might check [from year 2001]:

=A0 =A0www.cs.ucsb.edu/~ebelding/txt/autoconf.txt

What do you think about that?
=A0
But, maybe more to the point, I know I have seen a
good half-dozen distinct approaches to this problem.
<= br>
I think this approach is interesting and should definitely be= considered with the half-dozen others you hint at,=A0in parallel=A0of the = DHCP-based approach that is aimed at. As far as I understood, this is the s= pirit of the second item in the proposed charter.

Emmanuel
=A0
--00c09f8c1c7cbd6987048d8adff5-- From emmanuel.baccelli@gmail.com Wed Aug 11 05:08: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 8D33A3A6829 for ; Wed, 11 Aug 2010 05:08:50 -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 8hUxQYbtLxwy for ; Wed, 11 Aug 2010 05:08: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 D2E3B3A6828 for ; Wed, 11 Aug 2010 05:08:48 -0700 (PDT) Received: by eyb7 with SMTP id 7so4920173eyb.31 for ; Wed, 11 Aug 2010 05:09:24 -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=d/GDZggb7Ra0qvKcWUaxeZY9/pJZM4jz089cBYhIB0M=; b=YSLWTgy3IIMOBCWLTo+/lNW3b3fIOJ68ub8yUzxQGRbPGb6p2k+ZdybEelkhClzGHG uNlRQzXl1ngxZ8HgqjjhxacNOYsxkRH66ZVQ/sNydrmmRSAsOvVxKnbik5msu3c7hiNT HnEb0RyOP+MCAZFBnZrT3FmnwNeLIFiN5S58o= 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=Txa1fF4YnUSKQcCRnt5uREDrfFt1NcNe+jApP8501iQ8tqGVLNLzkQkEeY72rZPg3r Eg0wnrx8hZLBaQ6GenVC1bUbLFe98yqTd5iCQpUDoTwIgY3WGpHQydv9fi1QlQt8ZOoU lX1Ie5fobBdv7pPRAkEncbMIaAqHXOT02C7wU= Received: by 10.213.20.132 with SMTP id f4mr15071033ebb.19.1281528564228; Wed, 11 Aug 2010 05:09:24 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.14.37.4 with HTTP; Wed, 11 Aug 2010 05:01:17 -0700 (PDT) In-Reply-To: References: <4C528979.7010006@oracle.com> From: Emmanuel Baccelli Date: Wed, 11 Aug 2010 14:01:17 +0200 X-Google-Sender-Auth: fnhtXlSByal_6G_DGAEU9X0iLrk Message-ID: To: Ryuji Wakikawa Content-Type: multipart/alternative; boundary=0015174c409ad7246b048d8b1e0e Cc: "autoconf@ietf.org autoconf@ietf.org" , Autoconf Chairs , Ralph Droms Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: 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: Wed, 11 Aug 2010 12:08:50 -0000 --0015174c409ad7246b048d8b1e0e Content-Type: text/plain; charset=ISO-8859-1 Hi Ryuji, I support the proposed changes, although I'm not particularly keen on altering the title (actually I have not noticed anybody who is, I just noticed some people who oppose it ;) and I would prefer to simply skip the last sentence about EUI-64. Cheers Emmanuel On Tue, Aug 3, 2010 at 2:14 AM, Ryuji Wakikawa wrote: > Hello all, > > At the IETF78 meeting, we had the rough consensus to adapt > the Erik's modification for RFC5889 in the room. > > To confirm our consensus on the list, we ask the WG consensus call > for adaption of Erik's modification for RFC5889. > > The detailed modifications can be found at the attached email below. Thanks > Erik. > > Please vote for your opinion before "Aug 9th 12:00PM (PST)". > If you have any objections, please give us clear reason and propose your > text. > > thanks in advance, > Thomas, ryuji > > > > > Begin forwarded message: > > > From: Erik Nordmark > > Date: 2010/07/30 01:12:41GMT-07:00 > > To: autoconf@ietf.org > > Subject: Re: [Autoconf] Forgot one [Was: RFC 5889 > > > > > > 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. > > > > --- > > _______________________________________________ > > 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 > --0015174c409ad7246b048d8b1e0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ryuji,

I support the proposed changes, although I'= ;m not particularly keen on altering the title (actually I have not noticed= anybody who is, I just noticed some people who oppose it ;) and I would pr= efer to simply skip the last sentence about EUI-64.

Cheers

Emmanuel

=

On Tue, Aug 3, 2010 at 2:14 AM, R= yuji Wakikawa <ryuji.wakikawa@gmail.com> wrote:
Hello all,

At the IETF78 meeting, we had the rough consensus to adapt
the Erik's modification for RFC5889 in the room.

To confirm our consensus on the list, we ask the WG consensus call
for adaption of Erik's modification for RFC5889.

The detailed modifications can be found at the attached email below. Thanks= Erik.

Please vote for your opinion before "Aug 9th 12:00PM (PST)".
If you have any objections, please give us clear reason and propose your te= xt.

thanks in advance,
Thomas, ryuji




Begin forwarded message:

> From: Erik Nordmark <er= ik.nordmark@oracle.com>
> Date: 2010/07/30 01:12:41GMT-07:00
> To: autoconf@ietf.org
> Subject: Re: [Autoconf] Forgot one [Was: RFC 5889
>
>
> Please double-check this, but I think it has all the list of changes t= hat Jari said verbally.
>
> =A0Erik
>
> ----
>
> Change the title
> FROM
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IP Addressing Model in Ad Hoc Networks<= br> > TO
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A Router Addressing Model in Ad Hoc Net= works
>
> In section 5:
> OLD:
> Routing protocols running on a router may exhibit different
> requirements for uniqueness of interface addresses; some have no such<= br> > 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. =A0Thi= s
> suggests the following principle:
>
> o =A0an IP address assigned to an interface that connects to a link > =A0 with undetermined connectivity properties should be unique, at
> =A0 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<= br> > 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 rout= ing
> 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. =A0As = a result, the following principle allows for IP autoconfiguration to
> apply to the widest array of routing protocols:
>
> o =A0an IP address assigned to an interface that connects to a link > =A0 with undetermined connectivity properties should be unique, at
> =A0 least within the routing domain.
>
> In Section 6.1:
> OLD:
> o =A0There is no mechanism to ensure that IPv6 link-local addresses ar= e
> =A0 unique across multiple links, hence they cannot be used to
> =A0 reliably identify routers (it is often desirable to identify a
> =A0 router with an IP address).
> NEW:
> o =A0In general there is no mechanism to ensure that IPv6 link-local > =A0 addresses are unique across multiple links, however link-local
> =A0 addresses using an IID that are of the modified EUI-64 form are > =A0 globally unique. Thus if link-local addresses are used to reliably=
> =A0 identify routers then they must be of the modified EUI-64 form. >
> ---
> _______________________________________________
> 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

--0015174c409ad7246b048d8b1e0e-- From teco@inf-net.nl Fri Aug 13 03:05: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 163863A6982 for ; Fri, 13 Aug 2010 03:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 vEg4NtrzIUJI for ; Fri, 13 Aug 2010 03:05:11 -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 5AF633A6994 for ; Fri, 13 Aug 2010 03:05:11 -0700 (PDT) Received: by eyb7 with SMTP id 7so1228867eyb.31 for ; Fri, 13 Aug 2010 03:05:48 -0700 (PDT) Received: by 10.213.89.196 with SMTP id f4mr548126ebm.3.1281693947809; Fri, 13 Aug 2010 03:05:47 -0700 (PDT) Received: from [192.168.2.197] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id v59sm3893002eeh.16.2010.08.13.03.05.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Aug 2010 03:05:47 -0700 (PDT) From: Teco Boot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Aug 2010 12:05:45 +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] DAD Proxy draft X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 10:05:13 -0000 The following draft may be of interest for Autoconf: http://tools.ietf.org/html/draft-costa-6man-dad-proxy-00 For in a MANET and with little adjustments, DAD is extended from 1 hop = to 2-hop scope. It relies on unique Link-Layer addresses. Teco From wassim.haddad@ericsson.com Sat Aug 14 22:46: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 8FFA63A682F for ; Sat, 14 Aug 2010 22:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.776 X-Spam-Level: X-Spam-Status: No, score=-103.776 tagged_above=-999 required=5 tests=[AWL=-1.177, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NdVZTzXsrSq for ; Sat, 14 Aug 2010 22:46:16 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 9C1AD3A681A for ; Sat, 14 Aug 2010 22:46:16 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o7F5kqND005788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 15 Aug 2010 00:46:52 -0500 Received: from [164.48.125.82] (147.117.20.213) by eusaamw0712.eamcs.ericsson.se (147.117.20.182) with Microsoft SMTP Server id 8.2.234.1; Sun, 15 Aug 2010 01:46:51 -0400 From: Wassim Haddad Content-Type: multipart/signed; boundary="Apple-Mail-5-748813869"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Sat, 14 Aug 2010 22:46:48 -0700 Message-ID: To: Autoconf MIME-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Cc: Wassim Haddad Subject: [Autoconf] New Charter? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 05:46:17 -0000 --Apple-Mail-5-748813869 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Is it possible to take a look at the list of items suggested in the new = (and supposedly still under debate) charter? In an email sent on Jult 19th, Ruyji mentioned the following list of = "opinions": - 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 Is there any update? Regards, Wassim H. --Apple-Mail-5-748813869 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIENDCCBDAw ggMYoAMCAQICEQDYVPUywOyjtwh/x6nlhfS/MA0GCSqGSIb3DQEBBQUAMDkxETAPBgNVBAoMCEVy aWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDEwHhcNMDkxMDI5MTU1 ODU3WhcNMTIxMDI5MTU1ODU0WjBoMREwDwYDVQQKDAhFcmljc3NvbjEWMBQGA1UEAwwNV2Fzc2lt IEhhZGRhZDEQMA4GA1UEBRMHZXdhc2hhZDEpMCcGCSqGSIb3DQEJARYad2Fzc2ltLmhhZGRhZEBl cmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJnf3T/nroDokwgzv1ob54nr EQ2qce7b8P0j9dhnGFPhfROZzOb8Uuo1MPaSpDLVObZgSisoJ5JU0euu6pVcofmLQPZzdWzooCBa s3Y2tuRtkvFgcZoDKJoo7sorV6yyeRwA+QZpvyS1A7cpsqxjB7jevoXrIFhjs79safz+/Ou/AgMB AAGjggGGMIIBgjCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0LnRlbGlh LmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVzdC50ZWxp YS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nzb24/Y2Vy dGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAlBgNVHREEHjAcgRp3YXNzaW0uaGFk ZGFkQGVyaWNzc29uLmNvbTBGBgNVHSAEPzA9MDsGBiqFcGsBATAxMC8GCCsGAQUFBwIBFiNodHRw Oi8vd3d3LmVyaWNzc29uLmNvbS9sZWdhbC5zaHRtbDAdBgNVHQ4EFgQUiY5imSIHErhSp2V+9kdO JARmWScwHwYDVR0jBBgwFoAUlifDuN6lX11EPjlS5UWxdl9jMJswDgYDVR0PAQH/BAQDAgWgMA0G CSqGSIb3DQEBBQUAA4IBAQBIXqbs40JZUFTT/PWl6A0c3S85eU48TVXuwP2wkVhrBUz+45qAo0Yo FV3gDreoDoFGRFlHS5UiID7OUUyY4JJ0BCoqTPU6DGFjruZVNWk6gaL0WiFgqp0ro4CtysRmV1r1 no3JAaVcvZ4Hf7kOx2SxvresNlGlcDqk7eEABucmHNeQdDLCr61Ssrv3/Z6nMlI1IVLydpvqwgB8 7a0tqeejE3+QpTF0mLZWp1YYKz8hYSMX7MyJug372fN3MgWl7KiV0TOPMSn+yJZemwGl3xVmoT7j N/1/J6ApI5bLJrLNUT2UYjnBAyw3RIrzYoMuHJZu9L0f1gBPC8tLC0FsDEjAMYICFTCCAhECAQEw TjA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QTAxAhEA2FT1MsDso7cIf8ep5YX0vzAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA4MTUwNTQ2NDhaMCMGCSqGSIb3DQEJBDEWBBQWiHav ZF9lmq0oL3SuedpFyDEkwDBdBgkrBgEEAYI3EAQxUDBOMDkxETAPBgNVBAoMCEVyaWNzc29uMSQw IgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEQDYVPUywOyjtwh/x6nlhfS/MF8G CyqGSIb3DQEJEAILMVCgTjA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhEA2FT1MsDso7cIf8ep5YX0vzANBgkqhkiG9w0BAQEFAASBgATW WGI1POAgR1k2+0f0/dfAR6fAJiUldROA5SeWSqbA/DoPDEAdCOpD+Dpwqpc6eL4np8RMYlrIvaNw hZi+ZYpL3SfpgryjnZM0x0e86RfaK+KvfAy881fV7/JnUBGZaqNWb1+XCi/pk2so7/9XS/ASnTqv AHQHkKHdqlQ2lGuZAAAAAAAA --Apple-Mail-5-748813869-- From ryuji.wakikawa@gmail.com Tue Aug 17 10:06: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 01B513A6AAA for ; Tue, 17 Aug 2010 10:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.532 X-Spam-Level: X-Spam-Status: No, score=-100.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HlYVl6tC8wg for ; Tue, 17 Aug 2010 10:06:47 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id EBBA73A6A0B for ; Tue, 17 Aug 2010 10:06:46 -0700 (PDT) Received: by gwb20 with SMTP id 20so19221gwb.31 for ; Tue, 17 Aug 2010 10:07:22 -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=KmHXfSh/diCKvC6BYPHZmFQRpukA8lk/sMg9dZF+wFk=; b=AVkdw0VmRhZACax13J9o2cQv4gGNWTY7ggiVufAyK3JqN6TGRVZyEnhQKukpx9z8qW B6/pfKXM3Jcl3doMjJpV6vXfAC3lwYecZ+7v3A9kzxS1joLPfolUgJ1NHZm/1m4RPDnZ w0wBmFJzSwqCQAuuA8M9iVrrsm8RW0WiCmFFs= 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=JGo8xluBEFZncJdchAaM5PVRG32my46R1dww4+nf6WI8fsFGo21IY3LMc8JIF6gJO4 hV5wjteVaHkmCHvywOC9f4dDWbOS+nbQXsyT6mYMg8tpdFys51nK2lSXQc0kpE1EkGZU IBsLULcPAJCU0hfD/lXQLvf2DPRgjCCJS3YAo= Received: by 10.101.182.32 with SMTP id j32mr7947931anp.153.1282064841867; Tue, 17 Aug 2010 10:07:21 -0700 (PDT) Received: from 68.24.224.10.in-addr.arpa (m1c0436d0.tmodns.net [208.54.4.28]) by mx.google.com with ESMTPS id u14sm12558860ann.20.2010.08.17.10.07.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Aug 2010 10:07:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ryuji Wakikawa In-Reply-To: Date: Tue, 17 Aug 2010 10:06:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <98AA0508-8D70-4C77-AB42-6487CC09B33C@gmail.com> References: To: Wassim Haddad X-Mailer: Apple Mail (2.1081) Cc: Autoconf Subject: Re: [Autoconf] New Charter? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 17:06:48 -0000 Hello Wassim, I just sent the WGLC for the proposed new charter. You will find our = charter items in there. At Maastricht, we had good support for the new charter.=20 thanks, ryuji On 2010/08/14, at 22:46, Wassim Haddad wrote: > Hi, >=20 > Is it possible to take a look at the list of items suggested in the = new (and supposedly still under debate) charter? > In an email sent on Jult 19th, Ruyji mentioned the following list of = "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 >=20 > Is there any update? >=20 >=20 > Regards, >=20 > Wassim H. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From wassim.haddad@ericsson.com Tue Aug 17 13:25: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 919D73A687A for ; Tue, 17 Aug 2010 13:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.58 X-Spam-Level: X-Spam-Status: No, score=-103.58 tagged_above=-999 required=5 tests=[AWL=-0.981, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCfdnT5edgtE for ; Tue, 17 Aug 2010 13:25:46 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 3FC8A3A677D for ; Tue, 17 Aug 2010 13:25:46 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o7HKUQOg028029; Tue, 17 Aug 2010 15:30:33 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.134]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 17 Aug 2010 16:26:14 -0400 From: Wassim Haddad To: Ryuji Wakikawa Date: Tue, 17 Aug 2010 16:26:14 -0400 Thread-Topic: [Autoconf] New Charter? Thread-Index: Acs+LqpQWpAD5taQQMKBA97BdooaVAAG6X2g Message-ID: <2991246A29623A4082EB2B06A2B891A42BC1B5D48F@EUSAACMS0703.eamcs.ericsson.se> References: <98AA0508-8D70-4C77-AB42-6487CC09B33C@gmail.com> In-Reply-To: <98AA0508-8D70-4C77-AB42-6487CC09B33C@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Autoconf , Wassim Haddad Subject: Re: [Autoconf] New Charter? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 20:25:47 -0000 Hi Ryuji, Am sorry but I don't see your email or am I missing something? Thanks, Wassim H.=20 -----Original Message----- From: Ryuji Wakikawa [mailto:ryuji.wakikawa@gmail.com]=20 Sent: Tuesday, August 17, 2010 10:06 AM To: Wassim Haddad Cc: Autoconf Subject: Re: [Autoconf] New Charter? Hello Wassim, I just sent the WGLC for the proposed new charter. You will find our charte= r items in there. At Maastricht, we had good support for the new charter.=20 thanks, ryuji On 2010/08/14, at 22:46, Wassim Haddad wrote: > Hi, >=20 > Is it possible to take a look at the list of items suggested in the new (= and supposedly still under debate) charter? > In an email sent on Jult 19th, Ruyji mentioned the following list of "opi= nions": >=20 > - Centralized and/or De-centerized > - Existing protocols (DHCP and/or ND) vs. new autoconf protocols > - SIngle or Multiple AUTOCONF protocol(s) > - Security issue > - Informational link characteristics document >=20 > Is there any update? >=20 >=20 > Regards, >=20 > Wassim H. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From teco@inf-net.nl Wed Aug 18 13:55: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 C0D8F3A67FB for ; Wed, 18 Aug 2010 13:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 TvDDZkZMTIGD for ; Wed, 18 Aug 2010 13:55:19 -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 9A4253A6405 for ; Wed, 18 Aug 2010 13:55:18 -0700 (PDT) Received: by eyd10 with SMTP id 10so782403eyd.31 for ; Wed, 18 Aug 2010 13:55:53 -0700 (PDT) Received: by 10.213.15.82 with SMTP id j18mr2563165eba.78.1282164953678; Wed, 18 Aug 2010 13:55:53 -0700 (PDT) Received: from [192.168.2.189] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id a48sm1201546eei.19.2010.08.18.13.55.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 13:55:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <2991246A29623A4082EB2B06A2B891A42BC1B5D48F@EUSAACMS0703.eamcs.ericsson.se> Date: Wed, 18 Aug 2010 22:55:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <30B447B0-654D-45A3-AD5A-4CCAA5CD0B77@inf-net.nl> References: <98AA0508-8D70-4C77-AB42-6487CC09B33C@gmail.com> <2991246A29623A4082EB2B06A2B891A42BC1B5D48F@EUSAACMS0703.eamcs.ericsson.se> To: Ryuji Wakikawa X-Mailer: Apple Mail (2.1081) Cc: Autoconf Subject: Re: [Autoconf] New Charter? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 20:55:20 -0000 Hi Ryuji, I didn't see it either. So what are our charter items? Are few issues fixed? Regards, Teco Op 17 aug 2010, om 22:26 heeft Wassim Haddad het volgende geschreven: > Hi Ryuji, >=20 > Am sorry but I don't see your email or am I missing something? >=20 >=20 > Thanks, > Wassim H.=20 >=20 > -----Original Message----- > From: Ryuji Wakikawa [mailto:ryuji.wakikawa@gmail.com]=20 > Sent: Tuesday, August 17, 2010 10:06 AM > To: Wassim Haddad > Cc: Autoconf > Subject: Re: [Autoconf] New Charter? >=20 > Hello Wassim, >=20 > I just sent the WGLC for the proposed new charter. You will find our = charter items in there. > At Maastricht, we had good support for the new charter.=20 >=20 > thanks, > ryuji >=20 > On 2010/08/14, at 22:46, Wassim Haddad wrote: >=20 >> Hi, >>=20 >> Is it possible to take a look at the list of items suggested in the = new (and supposedly still under debate) charter? >> In an email sent on Jult 19th, Ruyji mentioned the following list of = "opinions": >>=20 >> - Centralized and/or De-centerized >> - Existing protocols (DHCP and/or ND) vs. new autoconf protocols >> - SIngle or Multiple AUTOCONF protocol(s) >> - Security issue >> - Informational link characteristics document >>=20 >> Is there any update? >>=20 >>=20 >> Regards, >>=20 >> Wassim H. >>=20 >>=20 >>=20 >>=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 From reshmi.engg@gmail.com Thu Aug 19 21:23: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 1A7493A69D4 for ; Thu, 19 Aug 2010 21:23:07 -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 9eeub+y+xN4y for ; Thu, 19 Aug 2010 21:23:05 -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 CF9A83A67F8 for ; Thu, 19 Aug 2010 21:23:04 -0700 (PDT) Received: by wwi17 with SMTP id 17so2841007wwi.13 for ; Thu, 19 Aug 2010 21:23:38 -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; bh=h5R69zgtLNgskal4S9BDWAwB4mQysqKzIBvo7sLmLHs=; b=Zy0vSz9051jrmkVk9DVRzXaXEYJPPAHgqJLe5bJhIQUI0fLzZxmc2jp6CURNDAs1EH c6mKA/gPkkrhOrlocFwCVeUSVoSsPC7uUiytbIBc1lkVgeaaR5vR6mcDLo4sh2FdZ6Ta Y9JblcEMpH5TZ1m4ZfnpciR/p6wlrZDV9ZGys= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=NAgQ2+KAzkkeEqon5YpS7hEU/qpq6XFlgu5KzBbmNFbpQhAFNlGHIMvreVXrbb1fnL IKavpjZgkCWJGto1lxt7EoUjMdDoUdCl8iFsNLvUEXDReD4uGMrODeqxkGgcM8JeIk0k KY2nu+ji9k8C/Wt4iQ7dP2d3IFf74duWHY204= MIME-Version: 1.0 Received: by 10.227.141.84 with SMTP id l20mr657204wbu.119.1282278218768; Thu, 19 Aug 2010 21:23:38 -0700 (PDT) Received: by 10.227.40.210 with HTTP; Thu, 19 Aug 2010 21:23:38 -0700 (PDT) Date: Fri, 20 Aug 2010 09:53:38 +0530 Message-ID: From: reshmi r To: autoconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Autoconf] New Charter- security issues?? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Aug 2010 04:23:07 -0000 Hi, Is it possible to know the various security issues suggested??? Do we mean to start addressing it from router at first and then to addressing methods and then to the protocols??? is this the right order??? any suggestion... Regards, Reshmi. following the mail............. Hi, Is it possible to take a look at the list of items suggested in the new (and supposedly still under debate) charter? In an email sent on Jult 19th, Ruyji mentioned the following list of "opinions": - Centralized and/or De-centerized - Existing protocols (DHCP and/or ND) vs. new autoconf protocols - SIngle or Multiple AUTOCONF protocol(s) - Security issue - Informational link characteristics document From ietf@thomasclausen.org Fri Aug 20 22:50: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 9514C3A6A40 for ; Fri, 20 Aug 2010 22:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSPDqczHXF+M for ; Fri, 20 Aug 2010 22:50:39 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 9DABE3A6A34 for ; Fri, 20 Aug 2010 22:50:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 1E8D53236DB6 for ; Fri, 20 Aug 2010 22:50:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.190.4] (unknown [221.232.139.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 05F813236DB2 for ; Fri, 20 Aug 2010 22:50:49 -0700 (PDT) From: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=Apple-Mail-6--880060345 Date: Sat, 21 Aug 2010 07:50:17 +0200 References: <61114C29-AE94-432F-A678-E81DAF050931@gmail.com> To: autoconf@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [Autoconf] Fwd: WGLC for the AUTOCONF charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 21 Aug 2010 05:50:45 -0000 --Apple-Mail-6--880060345 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear All, (sorry, traveling and so only catching up on mails now) It appears that this email made it to me, but not onto the 'list - for = which we apologize.=20 The original WGLC deadline was set to August 26, in view of the message = not making it last time around, the new WGLC deadline is August 30, 2010 = (Ryuji, I have edited your email to that effect). Kindly provide your feedback, even if it is to express agreement with = the proposed charter. Sincerely yours, Thomas Begin forwarded message: > From: Ryuji Wakikawa > Date: August 17, 2010 19:05:04 GMT+02:00 > Subject: WGLC for the AUTOCONF charter >=20 > Hi all,=20 >=20 > This is another WGLC for our new charter.=20 > We had good consensus at the meeting, but will confirm the consensus = on the list again. >=20 > The deadline for this WGLC is going to be Aug 30. >=20 > Please give us your opinion. >=20 > regards, > ryuji >=20 > ps. We'll send out the summary of the another WGLC for RFC5889.=20 >=20 >=20 > Ad-Hoc Network Autoconfiguration (autoconf) > ------------------------------------------- >=20 > Current Status: Active >=20 > Chairs: > Ryuji Wakikawa > Thomas Clausen >=20 > Internet Area Directors: > Ralph Droms > Jari Arkko >=20 > Internet Area Advisor: > Jari Arkko >=20 > Mailing Lists: > General Discussion: autoconf@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf > Archive: = http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html >=20 > Description of Working Group: >=20 > RFC 5889 presents one possible IPv6 addressing model for ad hoc > nodes. In this model the ad hoc routers need to configure their > network interface(s) with addresses valid in the ad hoc network, and > may configure additional prefixes for use by attached nodes. >=20 > After completing the work on RFC 5889, the main purpose of the > AUTOCONF WG is to standardize how existing IPv6 address configuration > tools can be used for address configuration.=20 >=20 > 1. DHCPv6 operation over MANET, including:=20 >=20 > - A DHCPv6-based mechanism for configuring required interface > addresses for the routers in the ad hoc network. This mechanism > is expected to produce addresses with properties outlined in RFC > 5889. This mechanism uses the existing DHCPv6 protocol unchanged, > and assumes a central node that can allocate addresses on a > first-come-first-served basis. Other nodes in the ad hoc network > will relay messages to the central node in order to help a new > node get an address for itself. This mechanism is only suitable > for deployments were a central node can be set up. It should be > noted that many existing deployments employ Internet gateways > that can act as such a central node as well. Future extensions > such as central node election may make this mechanism suitable > for also for stand-alone ad hoc networks. >=20 > - A DHCPv6-based mechanism for delegating a prefix(es) to each > router for use by applications running on the routers themselves, > or for configuration of attached hosts/networks. This mechanism > works in a similar manner to the one above, but allocates > prefixes instead of addresses. >=20 > Both mechanisms should be independent from operation of any specific > MANET routing protocol, although may exploit information maintained by > such a routing protocol, if available. >=20 > The working group will adapt and/or reuse existing protocols whenever > reasonable and possible. No new duplicate address detection mechanisms > are will be specified; it is expected that address uniqueness is > guaranteed by the central node alone. >=20 > 2. Analysis of Problem Space for distributed address configuration and > service discovery. >=20 >=20 > The working group plans to establish design teams for rapidly = advancing > towards initial submissions for these two work items.=20 >=20 > Goals and Milestones: >=20 > -Dec 2010 First working group draft of the "DHCPv6 operation over = MANET" > -Dec 2010 First working group draft of the "Analysis of Problem Space" > -Sep 2011 Submission of the "DHCPv6 operation over MANET" to the IESG = for > publication as BCP > -Sep 2011 Submission of the "Analysis of Problem Space" the IESG for > publication as Informational RFC > -Sep 2011 Rechartering or Closing WG=20 >=20 --Apple-Mail-6--880060345 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = All,

(sorry, traveling and so only catching up on = mails now)

It appears that this email made it = to me, but not onto the 'list - for which we = apologize. 

The original WGLC deadline was = set to August 26, in view of the message not making it last time around, = the new WGLC deadline is August 30, 2010 (Ryuji, I have edited your = email to that effect).

Kindly provide your = feedback, even if it is to express agreement with the proposed = charter.

Sincerely = yours,

Thomas

Begin forwarded = message:

From: Ryuji Wakikawa <ryuji.wakikawa@gmail.com><= br>
Date: August 17, 2010 19:05:04 = GMT+02:00
Subject: WGLC for the AUTOCONF = charter

Hi all,

This is another WGLC = for our new charter.
We had good consensus at the meeting, but will = confirm the consensus on the list again.

The deadline for this = WGLC is going to be Aug 30.

Please give us your = opinion.

regards,
ryuji

ps. We'll send out the summary = of the another WGLC for RFC5889.


Ad-Hoc Network = Autoconfiguration = (autoconf)
-------------------------------------------

Current = Status: Active

Chairs:
Ryuji Wakikawa <ryuji.wakikawa@gmail.com><= br>Thomas Clausen <T.Clausen@computer.org>
<= br>Internet Area Directors:
Ralph Droms <rdroms.ietf@gmail.com>
Jar= i Arkko <jari.arkko@piuha.net>

I= nternet Area Advisor:
Jari Arkko <jari.arkko@piuha.net>

M= ailing Lists:
General Discussion: autoconf@ietf.org
To Subscribe: = https://www.ietf.o= rg/mailman/listinfo/autoconf
Archive: http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html=

Description of Working Group:

RFC 5889 presents one = possible IPv6 addressing model for ad hoc
nodes. In this model the ad = hoc routers need to configure their
network interface(s) with = addresses valid in the ad hoc network, and
may configure additional = prefixes for use by attached nodes.

After completing the work on = RFC 5889, the main purpose of the
AUTOCONF WG is to standardize how = existing IPv6 address configuration
tools can be used for address = configuration.

1. DHCPv6 operation over MANET, including: =

 - A DHCPv6-based mechanism for configuring required = interface
   addresses for the routers in the ad hoc = network. This mechanism
   is expected to produce = addresses with properties outlined in RFC
   5889. = This mechanism uses the existing DHCPv6 protocol unchanged,
=    and assumes a central node that can allocate addresses = on a
   first-come-first-served basis. Other nodes in = the ad hoc network
   will relay messages to the = central node in order to help a new
   node get an = address for itself. This mechanism is only suitable
=    for deployments were a central node can be set up. It = should be
   noted that many existing deployments = employ Internet gateways
   that can act as such a = central node as well. Future extensions
   such as = central node election may make this mechanism suitable
=    for also for stand-alone ad hoc networks.

=  - A DHCPv6-based mechanism for delegating a prefix(es) to each
=    router for use by applications running on the routers = themselves,
   or for configuration of attached = hosts/networks. This mechanism
   works in a similar = manner to the one above, but allocates
   prefixes = instead of addresses.

Both mechanisms should be independent from = operation of any specific
MANET routing protocol, although may = exploit information maintained by
such a routing protocol, if = available.

The working group will adapt and/or reuse existing = protocols whenever
reasonable and possible. No new duplicate address = detection mechanisms
are will be specified; it is expected that = address uniqueness is
guaranteed by the central node alone.

2. = Analysis of Problem Space for distributed address configuration and
=  service discovery.


The working group plans to establish = design teams for rapidly advancing
towards initial submissions for = these two work items.

Goals and Milestones:

-Dec 2010 = First working group draft of the "DHCPv6 operation over MANET"
-Dec = 2010 First working group draft of the "Analysis of Problem = Space"
-Sep 2011 Submission of the "DHCPv6 operation over MANET" to = the IESG for
publication as BCP
-Sep 2011 Submission of the = "Analysis of Problem Space" the IESG for
publication as Informational = RFC
-Sep 2011 Rechartering or Closing WG =


= --Apple-Mail-6--880060345-- From thomas@thomasclausen.org Fri Aug 20 23:53: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 DE89F3A6839 for ; Fri, 20 Aug 2010 23:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPnHdXfOk6fp for ; Fri, 20 Aug 2010 23:53:30 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id CC9C63A67BE for ; Fri, 20 Aug 2010 23:53:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 3A5343236DB5; Fri, 20 Aug 2010 23:54:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.190.4] (unknown [221.232.139.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 479BB3236DB4; Fri, 20 Aug 2010 23:54:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Thomas Heide Clausen Date: Sat, 21 Aug 2010 08:53:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4ED032D0-72EB-42D4-BEA9-16F678FC30A8@thomasclausen.org> To: autoconf@ietf.org X-Mailer: Apple Mail (2.1081) Cc: Emmanuel Baccelli , Ralph Droms Subject: [Autoconf] Closing summary on consensus-call for RFC5889 modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 21 Aug 2010 06:53:32 -0000 All, The consensus call on the last-round-changes to this document closed on = August 9.=20 Special thanks to Erik for providing the summary of changes for the = last-call, and to everybody who have made their opinions known on the = list. I note that there wasn't a storm of opinions or opposition to the = proposed changes, which I interpret as that most in the WG are fine with = the changes.=20 Still, there was some discussion and some suggestions for changes to the = proposal -- reiterated below with, the resolution to each item also = indicated: > Change the title > FROM > IP Addressing Model in Ad Hoc Networks > TO > A Router Addressing Model in Ad Hoc Networks There were no strong opinions expressed in favor of the change, and a = some fairly strong objections raised against the change. =3D=3D> We therefore gauge that there is consensus for RETAINING the = title as "IP 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]). >=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. >=20 >=20 > 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]). >=20 > 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. There were no objections raised against the proposed changes. =3D=3D> We therefore gauge that there is consensus for CHANGING section = 5 as proposed by the text below "NEW" in the above. > 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). >=20 > 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. There were some opinions expressed regarding the last sentence, notably = that "must" (even if not capitalized as per RFC2119) is too strong. Christopher Dearlove and Teco Boot suggested/supported the following = text, supported by Emmanuel Baccelli, and to which no opposition was = expressed: > NEWER: >=20 > 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 > should be globally unique =3D=3D> We therefore gauge that there is consensus for CHANGING section = 6 as proposed by the text below "NEWER" in the above. As the document is in the hands of the RFC Editor, we hereby ask our ADs = (Ralph and Jari) for guidance as to if an updated I-D is appropriate, or = if they will produce and forward the above as a note to the RFC Editor = such that we can progress this document towards publication.=20 Again, thanks to all for your efforts on this matter! Sincerely yours, Thomas From jari.arkko@piuha.net Sat Aug 21 05:39: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 384DB3A6927 for ; Sat, 21 Aug 2010 05:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.34 X-Spam-Level: X-Spam-Status: No, score=-102.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnlEoX3oxjsL for ; Sat, 21 Aug 2010 05:39:30 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 2439C3A6822 for ; Sat, 21 Aug 2010 05:39:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5B3082CCC1; Sat, 21 Aug 2010 15:40:01 +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 OVguO3yyNAx9; Sat, 21 Aug 2010 15:40:00 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id E21782CC62; Sat, 21 Aug 2010 15:39:58 +0300 (EEST) Message-ID: <4C6FC91E.7050400@piuha.net> Date: Sat, 21 Aug 2010 08:39:58 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4ED032D0-72EB-42D4-BEA9-16F678FC30A8@thomasclausen.org> In-Reply-To: <4ED032D0-72EB-42D4-BEA9-16F678FC30A8@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org, Emmanuel Baccelli , Ralph Droms Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889 modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 21 Aug 2010 12:39:31 -0000 Thanks, Thomas. We do not need a new ID. I do need the final list of OLD/NEW though, and I will send it to the RFC-Editor as soon as I have them. After that there will be some final proofreading by the authors, and the RFC will come in a few days. Jari From thomas@thomasclausen.org Sat Aug 21 07:21: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 DDE933A681F for ; Sat, 21 Aug 2010 07:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1rYOY8pluYa for ; Sat, 21 Aug 2010 07:21:53 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id E047D3A6768 for ; Sat, 21 Aug 2010 07:21:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 4AEF73236DB2; Sat, 21 Aug 2010 07:22:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.190.4] (unknown [221.232.139.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 3D41C32280DD; Sat, 21 Aug 2010 07:22:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Thomas Heide Clausen In-Reply-To: <4C6FC91E.7050400@piuha.net> Date: Sat, 21 Aug 2010 16:21:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <19CCB3DD-2295-41E1-9E09-B1A9D7B2A1C5@thomasclausen.org> References: <4ED032D0-72EB-42D4-BEA9-16F678FC30A8@thomasclausen.org> <4C6FC91E.7050400@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org, Emmanuel Baccelli , Ralph Droms Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889 modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 21 Aug 2010 14:21:55 -0000 Jari, You're welcome - as you see, I anticipated your need ;) Hope you're having fun...don't break anything other than speed = records.... Thomas On Aug 21, 2010, at 14:39 , Jari Arkko wrote: > Thanks, Thomas. >=20 > We do not need a new ID. I do need the final list of OLD/NEW though, = and I will send it to the RFC-Editor as soon as I have them. After that = there will be some final proofreading by the authors, and the RFC will = come in a few days. >=20 > Jari >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From teco@inf-net.nl Sun Aug 22 23:19: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 B9EC23A67A1 for ; Sun, 22 Aug 2010 23:19:56 -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 q9GOd4AGZgez for ; Sun, 22 Aug 2010 23:19:55 -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 A7CCC3A6886 for ; Sun, 22 Aug 2010 23:19:54 -0700 (PDT) Received: by eyd10 with SMTP id 10so3286352eyd.31 for ; Sun, 22 Aug 2010 23:20:27 -0700 (PDT) Received: by 10.213.7.135 with SMTP id d7mr2347172ebd.97.1282544426978; Sun, 22 Aug 2010 23:20:26 -0700 (PDT) Received: from [10.128.0.157] ([77.61.241.196]) by mx.google.com with ESMTPS id u9sm10354040eeh.11.2010.08.22.23.20.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Aug 2010 23:20:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4ED032D0-72EB-42D4-BEA9-16F678FC30A8@thomasclausen.org> Date: Mon, 23 Aug 2010 08:20:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0ADB9520-AB23-4C61-A650-53B176B991B5@inf-net.nl> References: <4ED032D0-72EB-42D4-BEA9-16F678FC30A8@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org, Emmanuel Baccelli , Ralph Droms Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889 modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Aug 2010 06:19:56 -0000 Hi Thomas, On the title change, I remember in Maastricht all accept one=20 preferred the title change. On the list as well. There are two arguments. 1) it is _a_ model 2) the model doesn't support hosts, or at least not very well On the latter, there was a discussion without outcome. Regards, Teco Op 21 aug 2010, om 08:53 heeft Thomas Heide Clausen het volgende = geschreven: > All, >=20 > The consensus call on the last-round-changes to this document closed = on August 9.=20 >=20 > Special thanks to Erik for providing the summary of changes for the = last-call, and to everybody who have made their opinions known on the = list. I note that there wasn't a storm of opinions or opposition to the = proposed changes, which I interpret as that most in the WG are fine with = the changes.=20 >=20 > Still, there was some discussion and some suggestions for changes to = the proposal -- reiterated below with, the resolution to each item also = indicated: >=20 >> Change the title >> FROM >> IP Addressing Model in Ad Hoc Networks >> TO >> A Router Addressing Model in Ad Hoc Networks >=20 >=20 > There were no strong opinions expressed in favor of the change, and a = some fairly strong objections raised against the change. >=20 > =3D=3D> We therefore gauge that there is consensus for RETAINING the = title as "IP Addressing Model in Ad Hoc Networks". >=20 >> 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]). >>=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. >>=20 >>=20 >> 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]). >>=20 >> 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 >=20 > There were no objections raised against the proposed changes. >=20 > =3D=3D> We therefore gauge that there is consensus for CHANGING = section 5 as proposed by the text below "NEW" in the above. >=20 >> 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). >>=20 >> 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. >=20 >=20 > There were some opinions expressed regarding the last sentence, = notably that "must" (even if not capitalized as per RFC2119) is too = strong. >=20 > Christopher Dearlove and Teco Boot suggested/supported the following = text, supported by Emmanuel Baccelli, and to which no opposition was = expressed: >=20 >> NEWER: >>=20 >> 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 >> should be globally unique >=20 > =3D=3D> We therefore gauge that there is consensus for CHANGING = section 6 as proposed by the text below "NEWER" in the above. >=20 > As the document is in the hands of the RFC Editor, we hereby ask our = ADs (Ralph and Jari) for guidance as to if an updated I-D is = appropriate, or if they will produce and forward the above as a note to = the RFC Editor such that we can progress this document towards = publication.=20 >=20 > Again, thanks to all for your efforts on this matter! >=20 > Sincerely yours, >=20 > Thomas >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From cjbc@it.uc3m.es Mon Aug 23 00:17: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 C449D3A67CC for ; Mon, 23 Aug 2010 00:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaZ+LSzmu2OW for ; Mon, 23 Aug 2010 00:17:46 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 01EA13A6988 for ; Mon, 23 Aug 2010 00:17:45 -0700 (PDT) X-uc3m-safe: yes Received: from [192.168.4.76] (24.Red-80-36-142.staticIP.rima-tde.net [80.36.142.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 18061843660; Mon, 23 Aug 2010 09:18:14 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Thomas Heide Clausen In-Reply-To: References: <61114C29-AE94-432F-A678-E81DAF050931@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-SeDNXFIK0YGrTPQSaUJV" Organization: Universidad Carlos III de Madrid Date: Mon, 23 Aug 2010 09:19:50 +0200 Message-ID: <1282547990.9202.3.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17588.003 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Fwd: WGLC for the AUTOCONF charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 07:17:47 -0000 --=-SeDNXFIK0YGrTPQSaUJV Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi all, I generally agree with the proposed charter, with the comment I mentioned in the meeting: - Opening the door for service discovery, in addition to address autoconfiguration, might be a bit too much, especially given our performance in the past. Thanks, Carlos On Sat, 2010-08-21 at 07:50 +0200, Thomas Heide Clausen wrote: > Dear All, >=20 >=20 > (sorry, traveling and so only catching up on mails now) >=20 >=20 > It appears that this email made it to me, but not onto the 'list - for > which we apologize.=20 >=20 >=20 > The original WGLC deadline was set to August 26, in view of the > message not making it last time around, the new WGLC deadline is > August 30, 2010 (Ryuji, I have edited your email to that effect). >=20 >=20 > Kindly provide your feedback, even if it is to express agreement with > the proposed charter. >=20 >=20 > Sincerely yours, >=20 >=20 > Thomas >=20 > Begin forwarded message: >=20 > > From: Ryuji Wakikawa > >=20 > > Date: August 17, 2010 19:05:04 GMT+02:00 > >=20 > > Subject: WGLC for the AUTOCONF charter > >=20 > > Hi all,=20 > >=20 > > This is another WGLC for our new charter.=20 > > We had good consensus at the meeting, but will confirm the consensus > > on the list again. > >=20 > > The deadline for this WGLC is going to be Aug 30. > >=20 > > Please give us your opinion. > >=20 > > regards, > > ryuji > >=20 > > ps. We'll send out the summary of the another WGLC for RFC5889.=20 > >=20 > >=20 > > Ad-Hoc Network Autoconfiguration (autoconf) > > ------------------------------------------- > >=20 > > Current Status: Active > >=20 > > Chairs: > > Ryuji Wakikawa > > Thomas Clausen > >=20 > > Internet Area Directors: > > Ralph Droms > > Jari Arkko > >=20 > > Internet Area Advisor: > > Jari Arkko > >=20 > > Mailing Lists: > > General Discussion: autoconf@ietf.org > > To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf > > Archive: > > http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html > >=20 > > Description of Working Group: > >=20 > > RFC 5889 presents one possible IPv6 addressing model for ad hoc > > nodes. In this model the ad hoc routers need to configure their > > network interface(s) with addresses valid in the ad hoc network, and > > may configure additional prefixes for use by attached nodes. > >=20 > > After completing the work on RFC 5889, the main purpose of the > > AUTOCONF WG is to standardize how existing IPv6 address > > configuration > > tools can be used for address configuration.=20 > >=20 > > 1. DHCPv6 operation over MANET, including:=20 > >=20 > > - A DHCPv6-based mechanism for configuring required interface > > addresses for the routers in the ad hoc network. This mechanism > > is expected to produce addresses with properties outlined in RFC > > 5889. This mechanism uses the existing DHCPv6 protocol unchanged, > > and assumes a central node that can allocate addresses on a > > first-come-first-served basis. Other nodes in the ad hoc network > > will relay messages to the central node in order to help a new > > node get an address for itself. This mechanism is only suitable > > for deployments were a central node can be set up. It should be > > noted that many existing deployments employ Internet gateways > > that can act as such a central node as well. Future extensions > > such as central node election may make this mechanism suitable > > for also for stand-alone ad hoc networks. > >=20 > > - A DHCPv6-based mechanism for delegating a prefix(es) to each > > router for use by applications running on the routers themselves, > > or for configuration of attached hosts/networks. This mechanism > > works in a similar manner to the one above, but allocates > > prefixes instead of addresses. > >=20 > > Both mechanisms should be independent from operation of any specific > > MANET routing protocol, although may exploit information maintained > > by > > such a routing protocol, if available. > >=20 > > The working group will adapt and/or reuse existing protocols > > whenever > > reasonable and possible. No new duplicate address detection > > mechanisms > > are will be specified; it is expected that address uniqueness is > > guaranteed by the central node alone. > >=20 > > 2. Analysis of Problem Space for distributed address configuration > > and > > service discovery. > >=20 > >=20 > > The working group plans to establish design teams for rapidly > > advancing > > towards initial submissions for these two work items.=20 > >=20 > > Goals and Milestones: > >=20 > > -Dec 2010 First working group draft of the "DHCPv6 operation over > > MANET" > > -Dec 2010 First working group draft of the "Analysis of Problem > > Space" > > -Sep 2011 Submission of the "DHCPv6 operation over MANET" to the > > IESG for > > publication as BCP > > -Sep 2011 Submission of the "Analysis of Problem Space" the IESG for > > publication as Informational RFC > > -Sep 2011 Rechartering or Closing WG=20 > >=20 > >=20 >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-SeDNXFIK0YGrTPQSaUJV 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) iEYEABECAAYFAkxyIPUACgkQNdy6TdFwT2fvvQCeN+BB4FXXcvSS8TeG5vknkp+z KDkAoNVme/s+5KupVwnlD/2G7flSgsVG =PFIM -----END PGP SIGNATURE----- --=-SeDNXFIK0YGrTPQSaUJV-- From emmanuel.baccelli@gmail.com Mon Aug 23 00:59: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 773823A69B0 for ; Mon, 23 Aug 2010 00:59:09 -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 4dk4-xGHoKaU for ; Mon, 23 Aug 2010 00:59:08 -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 575A13A69A1 for ; Mon, 23 Aug 2010 00:59:07 -0700 (PDT) Received: by eyd10 with SMTP id 10so3307488eyd.31 for ; Mon, 23 Aug 2010 00:59:40 -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=FB1OKAWlyaHoto14LHQ81VF+ITNUaWXymtv709HU8l0=; b=j0J2ltLdU0bmHFfC4zdjglIhb9D/ACVyD8uV+zeU5M6nxfZpeCWBOrA1zdxVXWrej0 xhCWS7CwMrlGSDO+cx+2SSDG8ueUsTWvXjpoLTw03V7/rdWQtHuuSxHMxPqABTuWJ0zh Mf1qjrMGgk7Lu40Q5yRe7qwFhUBI8jWNAZA2o= 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=SY8wexmH4B/zOr22hncp4fZUdlEHLR+7IhP7I/YFdOHOezJrlX4YBU48My22vYJjKb FiApVUyy+n40JDzgufgNqwFRYewW4p/gSbrVUSWgojFVyMBbjWa/deypLrbvOohsQB5E lLAMx6BGxpBFaMDLUH7P8r+pdIDlBm0fLbgWU= Received: by 10.213.27.141 with SMTP id i13mr3318532ebc.5.1282550380229; Mon, 23 Aug 2010 00:59:40 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.14.37.16 with HTTP; Mon, 23 Aug 2010 00:59:20 -0700 (PDT) In-Reply-To: <0ADB9520-AB23-4C61-A650-53B176B991B5@inf-net.nl> References: <4ED032D0-72EB-42D4-BEA9-16F678FC30A8@thomasclausen.org> <0ADB9520-AB23-4C61-A650-53B176B991B5@inf-net.nl> From: Emmanuel Baccelli Date: Mon, 23 Aug 2010 09:59:20 +0200 X-Google-Sender-Auth: qznUgRlp4nihAiWuzHwP-TSXIYI Message-ID: To: Teco Boot Content-Type: multipart/alternative; boundary=0015174bddacd1f617048e79074a Cc: autoconf@ietf.org, Thomas Heide Clausen , Ralph Droms Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889 modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Aug 2010 07:59:09 -0000 --0015174bddacd1f617048e79074a Content-Type: text/plain; charset=ISO-8859-1 Hi Teco, actually in Maastricht, the title change was proposed. A few opposed the change, while others mostly did not care that much. This reads to me as no real support for the change, and some opposition. So I think the chairs gauged this right: no need to change the title. Regards, Emmanuel On Mon, Aug 23, 2010 at 8:20 AM, Teco Boot wrote: > Hi Thomas, > > On the title change, I remember in Maastricht all accept one > preferred the title change. On the list as well. > There are two arguments. > 1) it is _a_ model > 2) the model doesn't support hosts, or at least not very well > On the latter, there was a discussion without outcome. > > Regards, Teco > > Op 21 aug 2010, om 08:53 heeft Thomas Heide Clausen het volgende > geschreven: > > > All, > > > > The consensus call on the last-round-changes to this document closed on > August 9. > > > > Special thanks to Erik for providing the summary of changes for the > last-call, and to everybody who have made their opinions known on the list. > I note that there wasn't a storm of opinions or opposition to the proposed > changes, which I interpret as that most in the WG are fine with the changes. > > > > Still, there was some discussion and some suggestions for changes to the > proposal -- reiterated below with, the resolution to each item also > indicated: > > > >> Change the title > >> FROM > >> IP Addressing Model in Ad Hoc Networks > >> TO > >> A Router Addressing Model in Ad Hoc Networks > > > > > > There were no strong opinions expressed in favor of the change, and a > some fairly strong objections raised against the change. > > > > ==> We therefore gauge that there is consensus for RETAINING the title as > "IP 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. > > > > > > There were no objections raised against the proposed changes. > > > > ==> We therefore gauge that there is consensus for CHANGING section 5 as > proposed by the text below "NEW" in the above. > > > >> 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. > > > > > > There were some opinions expressed regarding the last sentence, notably > that "must" (even if not capitalized as per RFC2119) is too strong. > > > > Christopher Dearlove and Teco Boot suggested/supported the following > text, supported by Emmanuel Baccelli, and to which no opposition was > expressed: > > > >> NEWER: > >> > >> 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 > >> should be globally unique > > > > ==> We therefore gauge that there is consensus for CHANGING section 6 as > proposed by the text below "NEWER" in the above. > > > > As the document is in the hands of the RFC Editor, we hereby ask our ADs > (Ralph and Jari) for guidance as to if an updated I-D is appropriate, or if > they will produce and forward the above as a note to the RFC Editor such > that we can progress this document towards publication. > > > > Again, thanks to all for your efforts on this matter! > > > > Sincerely yours, > > > > Thomas > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www.ietf.org/mailman/listinfo/autoconf > > --0015174bddacd1f617048e79074a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Teco,
actually in Maastricht, the title change was proposed. A few o= pposed the change, while others mostly did not care that much. This reads t= o me as no real support for the change, and some opposition. So I think the= chairs gauged this right: no need to change the title.
Regards,
Emmanuel

On Mon, = Aug 23, 2010 at 8:20 AM, Teco Boot <teco@inf-net.nl> wrote:
Hi Thomas,

On the title change, I remember in Maastricht all accept one
preferred the title change. On the list as well.
There are two arguments.
1) it is _a_ model
2) the model doesn't support hosts, or at least not very well
On the latter, there was a discussion without outcome.

Regards, Teco

Op 21 aug 2010, om 08:53 heeft Thomas Heide Clausen het volgende geschreven= :

> All,
>
> The consensus call on the last-round-changes to this document closed o= n August 9.
>
> Special thanks to Erik for providing the summary of changes for the la= st-call, and to everybody who have made their opinions known on the list. I= note that there wasn't a storm of opinions or opposition to the propos= ed changes, which I interpret as that most in the WG are fine with the chan= ges.
>
> Still, there was some discussion and some suggestions for changes to t= he proposal -- reiterated below with, the resolution to each item also indi= cated:
>
>> Change the title
>> FROM
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0IP Addressing Model in Ad Hoc Networks<= br> >> TO
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0A Router Addressing Model in Ad Hoc Net= works
>
>
> There were no strong opinions expressed in favor of the change, and a = some fairly strong objections raised against the change.
>
> =3D=3D> We therefore gauge that there is consensus for RETAINING th= e title as "IP 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 s= uch
>> requirements, others have requirements ranging from local uniquene= ss
>> only, to uniqueness within, at least, the routing domain (as defin= ed
>> 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. = =A0This
>> suggests the following principle:
>>
>> o =A0an IP address assigned to an interface that connects to a lin= k
>> 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 s= uch
>> requirements, others have requirements ranging from local uniquene= ss
>> only, to uniqueness within, at least, the routing domain (as defin= ed
>> in [RFC1136]).
>>
>> Routing protocols that do not require unique IP addresses within t= he
>> routing domain utilize a separate unique identifier within the rou= ting
>> protocol itself; such identifiers could be based on factory assign= ment
>> or configuration.
>>
>> Nevertheless, configuring an IP address that is unique within the = routing
>> domain satisfies the less stringent uniqueness requirements of loc= al
>> 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 autoconfigurati= on to
>> apply to the widest array of routing protocols:
>>
>> o =A0an IP address assigned to an interface that connects to a lin= k
>> with undetermined connectivity properties should be unique, at
>> least within the routing domain.
>
>
> There were no objections raised against the proposed changes.
>
> =3D=3D> We therefore gauge that there is consensus for CHANGING sec= tion 5 as proposed by the text below "NEW" in the above.
>
>> In Section 6.1:
>> OLD:
>> o =A0There is no mechanism to ensure that IPv6 link-local addresse= s 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 =A0In general there is no mechanism to ensure that IPv6 link-loc= al
>> 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. >
>
> There were some opinions expressed regarding the last sentence, notabl= y that "must" (even if not capitalized as per RFC2119) is too str= ong.
>
> Christopher Dearlove and Teco Boot suggested/supported the following t= ext, supported by Emmanuel Baccelli, and to which no opposition was express= ed:
>
>> NEWER:
>>
>> o =A0In general there is no mechanism to ensure that IPv6 link-loc= al
>> =A0 =A0addresses are unique across multiple links, however link-lo= cal
>> =A0 =A0addresses using an IID that are of the modified EUI-64 form=
>> =A0 =A0should be globally unique
>
> =3D=3D> We therefore gauge that there is consensus for CHANGING sec= tion 6 as proposed by the text below "NEWER" in the above.
>
> As the document is in the hands of the RFC Editor, we hereby ask our A= Ds (Ralph and Jari) for guidance as to if an updated I-D is appropriate, or= if they will produce and forward the above as a note to the RFC Editor suc= h that we can progress this document towards publication.
>
> Again, thanks to all for your efforts on this matter!
>
> Sincerely yours,
>
> Thomas
>
> ________________________= _______________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf


--0015174bddacd1f617048e79074a-- From emmanuel.baccelli@gmail.com Mon Aug 23 01:51: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 8A8C93A6979 for ; Mon, 23 Aug 2010 01:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=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 U9lIiEUrOoHD for ; Mon, 23 Aug 2010 01:51: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 035AB3A684C for ; Mon, 23 Aug 2010 01:51:07 -0700 (PDT) Received: by ewy22 with SMTP id 22so3339699ewy.31 for ; Mon, 23 Aug 2010 01:51:40 -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=HUkdL2OIKBbfcz/SFtN40oaqVt+m8qJVVbttZrOgI3U=; b=hIwsk4SSGEdElCtJGcJw3wty+nZdwMOhAM7l5cQnkdOOEZJ5hdkUNn9bMSPB1jn6lH NgXYPhOlrcHM6UHKmEKuIh2Y7E5K1yEQzFZMF5/+HL0gFZ5lE6aNFZQjRIQvQ95i70lJ 1dmHLIY1Zhmtb7eJh9B5DjEAFEhXDHh/7oysA= 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=wDEz+c7sqlj2BqFiJf+sQbO7ttFO7+beJXe1yDniGngSNi5FdI3sJ+XdHG6dBdpWPt k5xC8f+WpDirDfeJAmxSOHnWDQEanPxgkPnOYtUjCeKD96pmC8/J5ZFrkCa52zs29RFJ I7vhWtJ0JKy/mi7FBbEhkTrzZxXRftdoQ/Ags= Received: by 10.213.77.75 with SMTP id f11mr3262440ebk.15.1282553499332; Mon, 23 Aug 2010 01:51:39 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.14.37.16 with HTTP; Mon, 23 Aug 2010 01:51:19 -0700 (PDT) In-Reply-To: <1282547990.9202.3.camel@acorde.it.uc3m.es> References: <61114C29-AE94-432F-A678-E81DAF050931@gmail.com> <1282547990.9202.3.camel@acorde.it.uc3m.es> From: Emmanuel Baccelli Date: Mon, 23 Aug 2010 10:51:19 +0200 X-Google-Sender-Auth: dOzyM1rLlhFfQOW3k2N5sEAxQ3U Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=00c09f7b25efbbb2af048e79c140 Subject: Re: [Autoconf] Fwd: WGLC for the AUTOCONF charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Aug 2010 08:51:10 -0000 --00c09f7b25efbbb2af048e79c140 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carlos, I was about to send the exact same email to the list ;) I also think the charter is OK, but would scrap service discovery. cheers Emmanuel 2010/8/23 Carlos Jes=FAs Bernardos Cano > Hi all, > > I generally agree with the proposed charter, with the comment I > mentioned in the meeting: > > - Opening the door for service discovery, in addition to address > autoconfiguration, might be a bit too much, especially given our > performance in the past. > > Thanks, > > Carlos > > On Sat, 2010-08-21 at 07:50 +0200, Thomas Heide Clausen wrote: > > Dear All, > > > > > > (sorry, traveling and so only catching up on mails now) > > > > > > It appears that this email made it to me, but not onto the 'list - for > > which we apologize. > > > > > > The original WGLC deadline was set to August 26, in view of the > > message not making it last time around, the new WGLC deadline is > > August 30, 2010 (Ryuji, I have edited your email to that effect). > > > > > > Kindly provide your feedback, even if it is to express agreement with > > the proposed charter. > > > > > > Sincerely yours, > > > > > > Thomas > > > > Begin forwarded message: > > > > > From: Ryuji Wakikawa > > > > > > Date: August 17, 2010 19:05:04 GMT+02:00 > > > > > > Subject: WGLC for the AUTOCONF charter > > > > > > Hi all, > > > > > > This is another WGLC for our new charter. > > > We had good consensus at the meeting, but will confirm the consensus > > > on the list again. > > > > > > The deadline for this WGLC is going to be Aug 30. > > > > > > Please give us your opinion. > > > > > > regards, > > > ryuji > > > > > > ps. We'll send out the summary of the another WGLC for RFC5889. > > > > > > > > > Ad-Hoc Network Autoconfiguration (autoconf) > > > ------------------------------------------- > > > > > > Current Status: Active > > > > > > Chairs: > > > Ryuji Wakikawa > > > Thomas Clausen > > > > > > Internet Area Directors: > > > Ralph Droms > > > Jari Arkko > > > > > > Internet Area Advisor: > > > Jari Arkko > > > > > > Mailing Lists: > > > General Discussion: autoconf@ietf.org > > > To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf > > > Archive: > > > http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html > > > > > > Description of Working Group: > > > > > > RFC 5889 presents one possible IPv6 addressing model for ad hoc > > > nodes. In this model the ad hoc routers need to configure their > > > network interface(s) with addresses valid in the ad hoc network, and > > > may configure additional prefixes for use by attached nodes. > > > > > > After completing the work on RFC 5889, the main purpose of the > > > AUTOCONF WG is to standardize how existing IPv6 address > > > configuration > > > tools can be used for address configuration. > > > > > > 1. DHCPv6 operation over MANET, including: > > > > > > - A DHCPv6-based mechanism for configuring required interface > > > addresses for the routers in the ad hoc network. This mechanism > > > is expected to produce addresses with properties outlined in RFC > > > 5889. This mechanism uses the existing DHCPv6 protocol unchanged, > > > and assumes a central node that can allocate addresses on a > > > first-come-first-served basis. Other nodes in the ad hoc network > > > will relay messages to the central node in order to help a new > > > node get an address for itself. This mechanism is only suitable > > > for deployments were a central node can be set up. It should be > > > noted that many existing deployments employ Internet gateways > > > that can act as such a central node as well. Future extensions > > > such as central node election may make this mechanism suitable > > > for also for stand-alone ad hoc networks. > > > > > > - A DHCPv6-based mechanism for delegating a prefix(es) to each > > > router for use by applications running on the routers themselves, > > > or for configuration of attached hosts/networks. This mechanism > > > works in a similar manner to the one above, but allocates > > > prefixes instead of addresses. > > > > > > Both mechanisms should be independent from operation of any specific > > > MANET routing protocol, although may exploit information maintained > > > by > > > such a routing protocol, if available. > > > > > > The working group will adapt and/or reuse existing protocols > > > whenever > > > reasonable and possible. No new duplicate address detection > > > mechanisms > > > are will be specified; it is expected that address uniqueness is > > > guaranteed by the central node alone. > > > > > > 2. Analysis of Problem Space for distributed address configuration > > > and > > > service discovery. > > > > > > > > > The working group plans to establish design teams for rapidly > > > advancing > > > towards initial submissions for these two work items. > > > > > > Goals and Milestones: > > > > > > -Dec 2010 First working group draft of the "DHCPv6 operation over > > > MANET" > > > -Dec 2010 First working group draft of the "Analysis of Problem > > > Space" > > > -Sep 2011 Submission of the "DHCPv6 operation over MANET" to the > > > IESG for > > > publication as BCP > > > -Sep 2011 Submission of the "Analysis of Problem Space" the IESG for > > > publication as Informational RFC > > > -Sep 2011 Rechartering or Closing WG > > > > > > > > > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www.ietf.org/mailman/listinfo/autoconf > > -- > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > --00c09f7b25efbbb2af048e79c140 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carlos,

I was about to send the exact same email to t= he list ;) I also think the charter is OK, but would scrap service discover= y.

cheers
Emmanuel


2010/8/23 Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>= ;
Hi all,

I generally agree with the proposed charter, with the comment I
mentioned in the meeting:

- Opening the door for service discovery, in addition to address
autoconfiguration, might be a bit too much, especially given our
performance in the past.

Thanks,

Carlos

On Sat, 2010-08-21 at 07:50 +0200, Thomas Heide Clausen wrote:
> Dear All,
>
>
> (sorry, traveling and so only catching up on mails now)
>
>
> It appears that this email made it to me, but not onto the 'list -= for
> which we apologize.
>
>
> The original WGLC deadline was set to August 26, in view of the
> message not making it last time around, the new WGLC deadline is
> August 30, 2010 (Ryuji, I have edited your email to that effect).
>
>
> Kindly provide your feedback, even if it is to express agreement with<= br> > the proposed charter.
>
>
> Sincerely yours,
>
>
> Thomas
>
> Begin forwarded message:
>
> > From: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
> >
> > Date: August 17, 2010 19:05:04 GMT+02:00
> >
> > Subject: WGLC for the AUTOCONF charter
> >
> > Hi all,
> >
> > This is another WGLC for our new charter.
> > We had good consensus at the meeting, but will confirm the consen= sus
> > on the list again.
> >
> > The deadline for this WGLC is going to be Aug 30.
> >
> > Please give us your opinion.
> >
> > regards,
> > ryuji
> >
> > ps. We'll send out the summary of the another WGLC for RFC588= 9.
> >
> >
> > Ad-Hoc Network Autoconfiguration (autoconf)
> > -------------------------------------------
> >
> > Current Status: Active
> >
> > Chairs:
> > Ryuji Wakikawa <ry= uji.wakikawa@gmail.com>
> > Thomas Clausen <T.Cl= ausen@computer.org>
> >
> > Internet Area Directors:
> > Ralph Droms <rdroms.i= etf@gmail.com>
> > Jari Arkko <jari.arkko= @piuha.net>
> >
> > Internet Area Advisor:
> > Jari Arkko <jari.arkko= @piuha.net>
> >
> > Mailing Lists:
> > General Discussion: autoconf= @ietf.org
> > To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf
> > Archive:
> > http://www.ietf.org/mail-archive/web/autoc= onf/current/maillist.html
> >
> > Description of Working Group:
> >
> > RFC 5889 presents one possible IPv6 addressing model for ad hoc > > nodes. In this model the ad hoc routers need to configure their > > network interface(s) with addresses valid in the ad hoc network, = and
> > may configure additional prefixes for use by attached nodes.
> >
> > After completing the work on RFC 5889, the main purpose of the > > AUTOCONF WG is to standardize how existing IPv6 address
> > configuration
> > tools can be used for address configuration.
> >
> > 1. DHCPv6 operation over MANET, including:
> >
> > =A0- A DHCPv6-based mechanism for configuring required interface<= br> > > =A0 =A0addresses for the routers in the ad hoc network. This mech= anism
> > =A0 =A0is expected to produce addresses with properties outlined = in RFC
> > =A0 =A05889. This mechanism uses the existing DHCPv6 protocol unc= hanged,
> > =A0 =A0and assumes a central node that can allocate addresses on = a
> > =A0 =A0first-come-first-served basis. Other nodes in the ad hoc n= etwork
> > =A0 =A0will relay messages to the central node in order to help a= new
> > =A0 =A0node get an address for itself. This mechanism is only sui= table
> > =A0 =A0for deployments were a central node can be set up. It shou= ld be
> > =A0 =A0noted that many existing deployments employ Internet gatew= ays
> > =A0 =A0that can act as such a central node as well. Future extens= ions
> > =A0 =A0such as central node election may make this mechanism suit= able
> > =A0 =A0for also for stand-alone ad hoc networks.
> >
> > =A0- A DHCPv6-based mechanism for delegating a prefix(es) to each=
> > =A0 =A0router for use by applications running on the routers them= selves,
> > =A0 =A0or for configuration of attached hosts/networks. This mech= anism
> > =A0 =A0works in a similar manner to the one above, but allocates<= br> > > =A0 =A0prefixes instead of addresses.
> >
> > Both mechanisms should be independent from operation of any speci= fic
> > MANET routing protocol, although may exploit information maintain= ed
> > by
> > such a routing protocol, if available.
> >
> > The working group will adapt and/or reuse existing protocols
> > whenever
> > reasonable and possible. No new duplicate address detection
> > mechanisms
> > are will be specified; it is expected that address uniqueness is<= br> > > guaranteed by the central node alone.
> >
> > 2. Analysis of Problem Space for distributed address configuratio= n
> > and
> > =A0service discovery.
> >
> >
> > The working group plans to establish design teams for rapidly
> > advancing
> > towards initial submissions for these two work items.
> >
> > Goals and Milestones:
> >
> > -Dec 2010 First working group draft of the "DHCPv6 operation= over
> > MANET"
> > -Dec 2010 First working group draft of the "Analysis of Prob= lem
> > Space"
> > -Sep 2011 Submission of the "DHCPv6 operation over MANET&quo= t; to the
> > IESG for
> > publication as BCP
> > -Sep 2011 Submission of the "Analysis of Problem Space"= the IESG for
> > publication as Informational RFC
> > -Sep 2011 Rechartering or Closing WG
> >
> >
>
>
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
--
Carlos Jes=FAs Bernardos Cano =A0 =A0 http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA =A04D55 35DC BA4D D170 4F67

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


--00c09f7b25efbbb2af048e79c140-- From reshmi.engg@gmail.com Mon Aug 23 21:44: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 AD31E3A685E for ; Mon, 23 Aug 2010 21:44:12 -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 he5s5zyrv0Br for ; Mon, 23 Aug 2010 21:44:10 -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 B32E33A67C3 for ; Mon, 23 Aug 2010 21:44:06 -0700 (PDT) Received: by wwe15 with SMTP id 15so953113wwe.13 for ; Mon, 23 Aug 2010 21:44:39 -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; bh=aPUFkCmeBCtvjd+9IRpupoAU24UmwJTuurA0vwb2P6A=; b=DpbyYnYVii26b+/zlYxklDJ3CZR0N2dZM0SxUJxUD9lO6fJTaXWR7EbMWt1XOjDeoH KnLbTadnjeJg17esfvC+kfYvueZQf89/53N7y00jBmGIMjEATRU8MrlSu/mdejCjFkha xToUS0p+NZawFQ2EEFv4osBdh7zLq82Xn/KkI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=peZDiBpw792XvU+o8119im7ReLi0VLgzOryQNOulbGZVGNa5bJKkkZw7dz+Yfo42fX ZAJ8KT3jkTZGkEHDrwA5u1UcExQkNCIYgvsFozE6gWr6pwZriY8GCUDDCXHADY40OGjy pM2WZ4FOn/eKhqCyX+kT0puEh8bhRy0hS1w3o= MIME-Version: 1.0 Received: by 10.227.136.146 with SMTP id r18mr5400902wbt.53.1282625079461; Mon, 23 Aug 2010 21:44:39 -0700 (PDT) Received: by 10.227.40.210 with HTTP; Mon, 23 Aug 2010 21:44:39 -0700 (PDT) Date: Tue, 24 Aug 2010 10:14:39 +0530 Message-ID: From: reshmi r To: autoconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889 modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Aug 2010 04:44:13 -0000 Hi Teco, Do they really mean a model for the autoconfiguration and is there is no role for host in autoconfiguration??........the topic goes in to real debate. what was the final outcome of the discussion???. Hi All, Can anyone finalise the suggested outcomes of the discussion??Do you all really mean that the routers only need to do the autoconfiguration and the nodes have no role in it??? If so how can we believe a router to be genuine and how can we ensure that the router will never become selfish??? so there should be some role in hosts to monitor the traffic behaviour of router and the host should be able to notify with some protocol mechanism. do you all really mean to change the title??? I strongly disagree with this. Rgds, Reshmi. Hi Thomas, On the title change, I remember in Maastricht all accept one preferred the title change. On the list as well. There are two arguments. 1) it is _a_ model 2) the model doesn't support hosts, or at least not very well On the latter, there was a discussion without outcome. Regards, Teco From Chris.Dearlove@baesystems.com Tue Aug 24 01:55:23 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 814583A6767 for ; Tue, 24 Aug 2010 01:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.403 X-Spam-Level: X-Spam-Status: No, score=-5.403 tagged_above=-999 required=5 tests=[AWL=-1.404, 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 0KtorabOPvMj for ; Tue, 24 Aug 2010 01:55:22 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 378023A6782 for ; Tue, 24 Aug 2010 01:55:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,262,1280703600"; d="scan'208";a="83525955" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 24 Aug 2010 09:55:54 +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 o7O8trpU028841; Tue, 24 Aug 2010 09:55:54 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Aug 2010 09:55:53 +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: Tue, 24 Aug 2010 09:55:53 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Closing summary on consensus-call for RFC5889modifications Thread-Index: ActDRxfR4YzF8cZTTl+KHn3/Ir3/bAAIaUig References: From: "Dearlove, Christopher (UK)" To: "reshmi r" , X-OriginalArrivalTime: 24 Aug 2010 08:55:53.0915 (UTC) FILETIME=[28BB50B0:01CB436A] Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Aug 2010 08:55:23 -0000 I think there's a misunderstanding here. All the way back to RFC 2501, a node has been defined as a router plus possible hosts. If you've got a wireless device that wants to participate in a MANET it needs to be running an ad hoc routing protocol, i.e. it's a router. It may perform only a limited subset of routing functions - consider for example an OLSR node that does not wish to be a relay, only an endpoint. It can do that by setting WILLINGNESS equal to zero, and if it is built only to take such a role it can then throw away large chunks of OLSR code (for example it never sends TC messages). But the node still has some router functions. This is the model of both RFC 2501 and 5889-to-be. The host can then get its addresses in any non-MANET-specific way on that node. -- Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability 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 reshmi r Sent: 24 August 2010 05:45 To: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications *** 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. Hi Teco, Do they really mean a model for the autoconfiguration and is there is no role for host in autoconfiguration??........the topic goes in to real debate. what was the final outcome of the discussion???. Hi All, Can anyone finalise the suggested outcomes of the discussion??Do you all really mean that the routers only need to do the autoconfiguration and the nodes have no role in it??? If so how can we believe a router to be genuine and how can we ensure that the router will never become selfish??? so there should be some role in hosts to monitor the traffic behaviour of router and the host should be able to notify with some protocol mechanism. do you all really mean to change the title??? I strongly disagree with this. Rgds, Reshmi. Hi Thomas, On the title change, I remember in Maastricht all accept one preferred the title change. On the list as well. There are two arguments. 1) it is _a_ model 2) the model doesn't support hosts, or at least not very well On the latter, there was a discussion without outcome. Regards, Teco _______________________________________________ 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 reshmi.engg@gmail.com Tue Aug 24 03:07: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 D1FDF3A67CC for ; Tue, 24 Aug 2010 03:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_62=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 Iv8b7u4UCHNX for ; Tue, 24 Aug 2010 03:07:25 -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 C17B63A6767 for ; Tue, 24 Aug 2010 03:07:24 -0700 (PDT) Received: by wyi11 with SMTP id 11so318439wyi.31 for ; Tue, 24 Aug 2010 03:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9NQWRW7wjXkAD4KJFKtVhTuN4QXJZT9f78c/czpZQes=; b=rzZ+2rCDwpuFn65J4LSAROyDUmxlM0gx8sYRH6/an/xOESxafc/066VcfB6Ri7kOgD 4JjKMJVM7fO/Q1MuNswyV7WDDLsqGpSLMANSr8Cgv27ZvLi43cCQbqFVf8DK+iLuiXzQ tQyuKmig1zYMMu7rf3TMHZTSBg0D/69S6GNUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oRxwWDghdYT3f9NTdiTp2GbXQbjC1dcLJLVwJR6EkeB4fVrxSLU2AouJgsgs93hlrK iRVzrp/JMSp5Qy6FkR1GXv34tx66knFQ9tvaiwBIQahQHK5rcgB2h2GD4/bSJjgWjt2w hftYqd/n2ltELH0KffguEMwBss/24TC3GN7k4= MIME-Version: 1.0 Received: by 10.227.142.132 with SMTP id q4mr5702325wbu.90.1282644477409; Tue, 24 Aug 2010 03:07:57 -0700 (PDT) Received: by 10.227.40.210 with HTTP; Tue, 24 Aug 2010 03:07:57 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 Aug 2010 15:37:57 +0530 Message-ID: From: reshmi r To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Aug 2010 10:07:27 -0000 Hi Christopher, Thank you for your immediate reply. Hi All, But i still have some questions to get it clarified. I understood all the nodes has the capacity to act as router and some may be ready to do it. 1. The nodes themself has the capacity to make it act as router(by setting WILLINGNESS to non zero). But in most of the cases all nodes are selfish and they does not want to parcipate in routing. So almost every node will be busy in their host functions alone. so who will take care of autoconfiguration? Imagine a network with no router!!!!!! 2. There will be more security threats if the node it self has the capacity to configure its WILLINGNESS . The malicious node can easily get in and set the WILLINGNESS to non zero and participate in routing functions. 3. If suppose we have a method to select the hosts which can act as router and set WILLINGNESS manually. What will be the criteria for router selection??? Is it based on resources, traffic etc etc.. Once again thank you for your reply. Regards, Reshmi.T.R. Reseach Scholar, Ramanujan Computing center, Anna University- Chennai India Tue, Aug 24, 2010 at 2:25 PM, Dearlove, Christopher (UK) wrote > I think there's a misunderstanding here. All the way back to RFC 2501, > a node has been defined as a router plus possible hosts. If you've got > a wireless device that wants to participate in a MANET it needs to be > running an ad hoc routing protocol, i.e. it's a router. It may perform > only a limited subset of routing functions - consider for example an > OLSR node that does not wish to be a relay, only an endpoint. It can > do that by setting WILLINGNESS equal to zero, and if it is built only > to take such a role it can then throw away large chunks of OLSR code > (for example it never sends TC messages). But the node still has some > router functions. This is the model of both RFC 2501 and 5889-to-be. > The host can then get its addresses in any non-MANET-specific way on > that node. > > -- > Christopher Dearlove > Technology Leader, Communications Group > Communications and Networks Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 =A0Fax: +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 reshmi r > Sent: 24 August 2010 05:45 > To: autoconf@ietf.org > Subject: Re: [Autoconf] Closing summary on consensus-call for > RFC5889modifications > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*** WARNING *** > > =A0This message has originated outside your organisation, > =A0either from an external partner or the Global Internet. > =A0 =A0 =A0Keep this in mind if you answer this message. > > > Hi Teco, > > Do they really mean a model for the autoconfiguration and is there is > no role for host in autoconfiguration??........the topic goes in to > real debate. what was the final outcome of the discussion???. > > Hi All, > > Can anyone finalise the suggested outcomes of the discussion??Do you > all really mean that the routers only need to do the autoconfiguration > and the nodes have no role in it??? If so how can we believe a router > to be genuine and how can we ensure that the router will never become > selfish??? so there should be some role in hosts to monitor the > traffic behaviour of router and the host should be able to notify with > some protocol mechanism. do you all really mean to change the title??? > I strongly disagree with this. > > > Rgds, > Reshmi. > > > Hi Thomas, > > On the title change, I remember in Maastricht all accept one > preferred the title change. On the list as well. > There are two arguments. > 1) it is _a_ model > 2) the model doesn't support hosts, or at least not very well > On the latter, there was a discussion without outcome. > > Regards, Teco > _______________________________________________ > 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 wassim.haddad@ericsson.com Tue Aug 24 03:11: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 9EB933A6981 for ; Tue, 24 Aug 2010 03:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.035 X-Spam-Level: X-Spam-Status: No, score=-103.035 tagged_above=-999 required=5 tests=[AWL=-1.036, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiOjz8rHgjf9 for ; Tue, 24 Aug 2010 03:11:01 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id F3B593A684C for ; Tue, 24 Aug 2010 03:10:55 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o7OAH33M016479 for ; Tue, 24 Aug 2010 05:17:04 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.134]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 24 Aug 2010 06:11:17 -0400 From: Wassim Haddad To: "autoconf@ietf.org" Date: Tue, 24 Aug 2010 06:11:16 -0400 Thread-Topic: [Autoconf] Fwd: WGLC for the AUTOCONF charter Thread-Index: ActCoHNjI0iSCFejS5apyhgcVq3ShAA02U30 Message-ID: <2991246A29623A4082EB2B06A2B891A42BC16E1FF6@EUSAACMS0703.eamcs.ericsson.se> References: <61114C29-AE94-432F-A678-E81DAF050931@gmail.com> <1282547990.9202.3.camel@acorde.it.uc3m.es>, 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Wassim Haddad Subject: Re: [Autoconf] Fwd: WGLC for the AUTOCONF charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Aug 2010 10:11:13 -0000 Hi, I think the charter is OK.=20 Is there any interest in taking a closer look at the security side of the a= ddressing=20 mechanisms and service discovery? Regards, Wassim H. ________________________________________ From: autoconf-bounces@ietf.org [autoconf-bounces@ietf.org] On Behalf Of Em= manuel Baccelli [Emmanuel.Baccelli@inria.fr] Sent: Monday, August 23, 2010 01:51 To: autoconf@ietf.org Subject: Re: [Autoconf] Fwd: WGLC for the AUTOCONF charter Hi Carlos, I was about to send the exact same email to the list ;) I also think the ch= arter is OK, but would scrap service discovery. cheers Emmanuel 2010/8/23 Carlos Jes=FAs Bernardos Cano > Hi all, I generally agree with the proposed charter, with the comment I mentioned in the meeting: - Opening the door for service discovery, in addition to address autoconfiguration, might be a bit too much, especially given our performance in the past. Thanks, Carlos On Sat, 2010-08-21 at 07:50 +0200, Thomas Heide Clausen wrote: > Dear All, > > > (sorry, traveling and so only catching up on mails now) > > > It appears that this email made it to me, but not onto the 'list - for > which we apologize. > > > The original WGLC deadline was set to August 26, in view of the > message not making it last time around, the new WGLC deadline is > August 30, 2010 (Ryuji, I have edited your email to that effect). > > > Kindly provide your feedback, even if it is to express agreement with > the proposed charter. > > > Sincerely yours, > > > Thomas > > Begin forwarded message: > > > From: Ryuji Wakikawa > > > > > Date: August 17, 2010 19:05:04 GMT+02:00 > > > > Subject: WGLC for the AUTOCONF charter > > > > Hi all, > > > > This is another WGLC for our new charter. > > We had good consensus at the meeting, but will confirm the consensus > > on the list again. > > > > The deadline for this WGLC is going to be Aug 30. > > > > Please give us your opinion. > > > > regards, > > ryuji > > > > ps. We'll send out the summary of the another WGLC for RFC5889. > > > > > > Ad-Hoc Network Autoconfiguration (autoconf) > > ------------------------------------------- > > > > Current Status: Active > > > > Chairs: > > Ryuji Wakikawa > > > Thomas Clausen > > > > > Internet Area Directors: > > Ralph Droms > > > Jari Arkko > > > > > Internet Area Advisor: > > Jari Arkko > > > > > Mailing Lists: > > General Discussion: autoconf@ietf.org > > To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf > > Archive: > > http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html > > > > Description of Working Group: > > > > RFC 5889 presents one possible IPv6 addressing model for ad hoc > > nodes. In this model the ad hoc routers need to configure their > > network interface(s) with addresses valid in the ad hoc network, and > > may configure additional prefixes for use by attached nodes. > > > > After completing the work on RFC 5889, the main purpose of the > > AUTOCONF WG is to standardize how existing IPv6 address > > configuration > > tools can be used for address configuration. > > > > 1. DHCPv6 operation over MANET, including: > > > > - A DHCPv6-based mechanism for configuring required interface > > addresses for the routers in the ad hoc network. This mechanism > > is expected to produce addresses with properties outlined in RFC > > 5889. This mechanism uses the existing DHCPv6 protocol unchanged, > > and assumes a central node that can allocate addresses on a > > first-come-first-served basis. Other nodes in the ad hoc network > > will relay messages to the central node in order to help a new > > node get an address for itself. This mechanism is only suitable > > for deployments were a central node can be set up. It should be > > noted that many existing deployments employ Internet gateways > > that can act as such a central node as well. Future extensions > > such as central node election may make this mechanism suitable > > for also for stand-alone ad hoc networks. > > > > - A DHCPv6-based mechanism for delegating a prefix(es) to each > > router for use by applications running on the routers themselves, > > or for configuration of attached hosts/networks. This mechanism > > works in a similar manner to the one above, but allocates > > prefixes instead of addresses. > > > > Both mechanisms should be independent from operation of any specific > > MANET routing protocol, although may exploit information maintained > > by > > such a routing protocol, if available. > > > > The working group will adapt and/or reuse existing protocols > > whenever > > reasonable and possible. No new duplicate address detection > > mechanisms > > are will be specified; it is expected that address uniqueness is > > guaranteed by the central node alone. > > > > 2. Analysis of Problem Space for distributed address configuration > > and > > service discovery. > > > > > > The working group plans to establish design teams for rapidly > > advancing > > towards initial submissions for these two work items. > > > > Goals and Milestones: > > > > -Dec 2010 First working group draft of the "DHCPv6 operation over > > MANET" > > -Dec 2010 First working group draft of the "Analysis of Problem > > Space" > > -Sep 2011 Submission of the "DHCPv6 operation over MANET" to the > > IESG for > > publication as BCP > > -Sep 2011 Submission of the "Analysis of Problem Space" the IESG for > > publication as Informational RFC > > -Sep 2011 Rechartering or Closing WG > > > > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf -- Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From Chris.Dearlove@baesystems.com Tue Aug 24 03:50: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 51FA73A6982 for ; Tue, 24 Aug 2010 03:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.378 X-Spam-Level: X-Spam-Status: No, score=-6.378 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, 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 E6KB6WKybs8u for ; Tue, 24 Aug 2010 03:50:17 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 25BD93A6767 for ; Tue, 24 Aug 2010 03:50:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,262,1280703600"; d="scan'208";a="83570853" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 24 Aug 2010 11:50:49 +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 o7OAom7S015362; Tue, 24 Aug 2010 11:50:48 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Aug 2010 11:50:48 +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: Tue, 24 Aug 2010 11:50:48 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Closing summary on consensus-call for RFC5889modifications Thread-Index: ActDdDvbREAWRk7kSMSh1jlWcwlvjAAAvsxA References: From: "Dearlove, Christopher (UK)" To: "reshmi r" X-OriginalArrivalTime: 24 Aug 2010 10:50:48.0433 (UTC) FILETIME=[362F4610:01CB437A] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Aug 2010 10:50:18 -0000 First note that OLSR is just an example. As a further example, I haven't checked if AODV and/or DYMO have documented equivalent features, but they very easily could implement them (don't forward RREQs). Of course if every router (or just too many routers) is selfish the ad hoc network will fail. That's inherent in the whole concept of an ad hoc network. OLSRv2 points this out when allowing the concept. But this is not an autoconf or RFC 5889-to-be problem. I don't see that a node being able to set its own willingness to zero in any way adds to the threat. A hostile node is more dangerous with high willingness than with low. But that's not an authconf/RFC 5889-to-be issue, it's a routing security problem. Again, your last point is about routing and management. That's not to say it and the others aren't good questions when planning an ad hoc network (not quite an oxymoron) or for research. But they aren't the issue here. --=20 Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability 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: reshmi r [mailto:reshmi.engg@gmail.com]=20 Sent: 24 August 2010 11:08 To: Dearlove, Christopher (UK) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for = RFC5889modifications *** 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 Hi Christopher, Thank you for your immediate reply. Hi All, But i still have some questions to get it clarified. I understood all the nodes has the capacity to act as router and some may be ready to do it. 1. The nodes themself has the capacity to make it act as router(by setting WILLINGNESS to non zero). But in most of the cases all nodes are selfish and they does not want to parcipate in routing. So almost every node will be busy in their host functions alone. so who will take care of autoconfiguration? Imagine a network with no router!!!!!! 2. There will be more security threats if the node it self has the capacity to configure its WILLINGNESS . The malicious node can easily get in and set the WILLINGNESS to non zero and participate in routing functions. 3. If suppose we have a method to select the hosts which can act as router and set WILLINGNESS manually. What will be the criteria for router selection??? Is it based on resources, traffic etc etc.. Once again thank you for your reply. Regards, Reshmi.T.R. Reseach Scholar, Ramanujan Computing center, Anna University- Chennai India Tue, Aug 24, 2010 at 2:25 PM, Dearlove, Christopher (UK) wrote > I think there's a misunderstanding here. All the way back to RFC 2501, > a node has been defined as a router plus possible hosts. If you've got > a wireless device that wants to participate in a MANET it needs to be > running an ad hoc routing protocol, i.e. it's a router. It may perform > only a limited subset of routing functions - consider for example an > OLSR node that does not wish to be a relay, only an endpoint. It can > do that by setting WILLINGNESS equal to zero, and if it is built only > to take such a role it can then throw away large chunks of OLSR code > (for example it never sends TC messages). But the node still has some > router functions. This is the model of both RFC 2501 and 5889-to-be. > The host can then get its addresses in any non-MANET-specific way on > that node. > > -- > Christopher Dearlove > Technology Leader, Communications Group > Communications and Networks Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 =A0Fax: +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 reshmi r > Sent: 24 August 2010 05:45 > To: autoconf@ietf.org > Subject: Re: [Autoconf] Closing summary on consensus-call for > RFC5889modifications > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*** WARNING *** > > =A0This message has originated outside your organisation, > =A0either from an external partner or the Global Internet. > =A0 =A0 =A0Keep this in mind if you answer this message. > > > Hi Teco, > > Do they really mean a model for the autoconfiguration and is there is > no role for host in autoconfiguration??........the topic goes in to > real debate. what was the final outcome of the discussion???. > > Hi All, > > Can anyone finalise the suggested outcomes of the discussion??Do you > all really mean that the routers only need to do the autoconfiguration > and the nodes have no role in it??? If so how can we believe a router > to be genuine and how can we ensure that the router will never become > selfish??? so there should be some role in hosts to monitor the > traffic behaviour of router and the host should be able to notify with > some protocol mechanism. do you all really mean to change the title??? > I strongly disagree with this. > > > Rgds, > Reshmi. > > > Hi Thomas, > > On the title change, I remember in Maastricht all accept one > preferred the title change. On the list as well. > There are two arguments. > 1) it is _a_ model > 2) the model doesn't support hosts, or at least not very well > On the latter, there was a discussion without outcome. > > Regards, Teco > _______________________________________________ > 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 teco@inf-net.nl Tue Aug 24 04:09: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 AD6E13A6936 for ; Tue, 24 Aug 2010 04:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 Pko5mBZE+yBC for ; Tue, 24 Aug 2010 04:09:01 -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 5D1A43A68DE for ; Tue, 24 Aug 2010 04:09:00 -0700 (PDT) Received: by eyd10 with SMTP id 10so3518544eyd.31 for ; Tue, 24 Aug 2010 04:09:33 -0700 (PDT) Received: by 10.213.17.195 with SMTP id t3mr4072356eba.63.1282648172178; Tue, 24 Aug 2010 04:09:32 -0700 (PDT) Received: from [10.128.0.157] ([77.61.241.196]) by mx.google.com with ESMTPS id z55sm12572149eeh.3.2010.08.24.04.09.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Aug 2010 04:09:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Tue, 24 Aug 2010 13:09:29 +0200 Content-Transfer-Encoding: 7bit Message-Id: <83F56946-B762-4DC1-A037-E5F8A7296EE4@inf-net.nl> References: To: reshmi r X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889 modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Aug 2010 11:09:02 -0000 Reshmi, The outcome was we didn't agree on what makes a node a router or a host. And time is too costly to find out. Some say we only have routers attached to links with undetermined characteristics. Others say hosts run OADV. In IPv6, there are some rules for hosts, e.g. RFC 5942: | In IPv6, an address is on-link (with respect to a specific link), if | the address has been assigned to an interface attached to that | link. Now we have an addressing model that says: | No on-link subnet prefix is configured on this interface. We have to find out how hosts can use the addressing model. And how routers deal with such hosts. At least it is not clear to me right now. Regards, Teco Op 24 aug 2010, om 06:44 heeft reshmi r het volgende geschreven: > Hi Teco, > > Do they really mean a model for the autoconfiguration and is there is > no role for host in autoconfiguration??........the topic goes in to > real debate. what was the final outcome of the discussion???. > > Hi All, > > Can anyone finalise the suggested outcomes of the discussion??Do you > all really mean that the routers only need to do the autoconfiguration > and the nodes have no role in it??? If so how can we believe a router > to be genuine and how can we ensure that the router will never become > selfish??? so there should be some role in hosts to monitor the > traffic behaviour of router and the host should be able to notify with > some protocol mechanism. do you all really mean to change the title??? > I strongly disagree with this. > > > Rgds, > Reshmi. > > > Hi Thomas, > > On the title change, I remember in Maastricht all accept one > preferred the title change. On the list as well. > There are two arguments. > 1) it is _a_ model > 2) the model doesn't support hosts, or at least not very well > On the latter, there was a discussion without outcome. > > Regards, Teco > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From Juliusz.Chroboczek@pps.jussieu.fr Tue Aug 24 10:10:43 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 987F33A6B76 for ; Tue, 24 Aug 2010 10:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6noWLq9N+LgR for ; Tue, 24 Aug 2010 10:10:38 -0700 (PDT) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by core3.amsl.com (Postfix) with ESMTP id F37A13A6B92 for ; Tue, 24 Aug 2010 10:10:34 -0700 (PDT) Received: from hydrogene.pps.jussieu.fr (hydrogene.pps.jussieu.fr [134.157.168.1]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id o7OHB2ec038787 ; Tue, 24 Aug 2010 19:11:03 +0200 (CEST) X-Ids: 166 Received: from lanthane.pps.jussieu.fr (lanthane.pps.jussieu.fr [134.157.168.57]) by hydrogene.pps.jussieu.fr (8.13.4/jtpda-5.4) with ESMTP id o7OHB1lk010788 ; Tue, 24 Aug 2010 19:11:01 +0200 Received: from jch by lanthane.pps.jussieu.fr with local (Exim 4.72) (envelope-from ) id 1Onx1Z-0001oL-5E; Tue, 24 Aug 2010 19:11:01 +0200 From: Juliusz Chroboczek To: "Dearlove\, Christopher \(UK\)" References: Date: Tue, 24 Aug 2010 19:11:01 +0200 In-Reply-To: (Christopher Dearlove's message of "Tue, 24 Aug 2010 09:55:53 +0100") Message-ID: <7ir5hoc4wq.fsf@lanthane.pps.jussieu.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Miltered: at jchkmail.jussieu.fr with ID 4C73FD26.009 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4C73FD26.009/134.157.168.1/hydrogene.pps.jussieu.fr/hydrogene.pps.jussieu.fr/ Cc: autoconf@ietf.org, reshmi r Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Aug 2010 17:10:43 -0000 > consider for example an OLSR node that does not wish to be a relay, > only an endpoint. It can do that by setting WILLINGNESS equal to zero, > and if it is built only to take such a role it can then throw away > large chunks of OLSR code (for example it never sends TC messages). What you're describing is not a router. It's a host that's snooping on a routing protocol. Juliusz From charles.perkins@earthlink.net Tue Aug 24 12:34: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 1F9BC3A69D4 for ; Tue, 24 Aug 2010 12:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.439, 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 eoPoEPJGRDeZ for ; Tue, 24 Aug 2010 12:33:58 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id B45493A6A0A for ; Tue, 24 Aug 2010 12:33:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=FT+guz78MT7P/h3h0Yd6IsVf4Z9AN0sK2I9CbzfYzfdGoSuPbiihHa5zsfroNg5o; 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.63]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OnzGJ-0001bw-Sk; Tue, 24 Aug 2010 15:34:24 -0400 Message-ID: <4C741EBB.8060909@earthlink.net> Date: Tue, 24 Aug 2010 12:34:19 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5272d2c486eab8a7ec928bcf7c9f45af6d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Aug 2010 19:34:25 -0000 Hello Chris, A node can easily participate in an ad hoc network without running OLSR or DYMO or any routing protocol. Why make the restriction? I don't understand the value proposition of disenfranchising so many users and invalidating so many use cases. On 8/24/2010 1:55 AM, Dearlove, Christopher (UK) wrote: > a node has been defined as a router plus possible hosts. If you've got > a wireless device that wants to participate in a MANET it needs to be > running an ad hoc routing protocol, i.e. it's a router. Well, opinions vary here, to say the least. > It may perform > only a limited subset of routing functions - consider for example an > OLSR node that does not wish to be a relay, only an endpoint. I can agree, because the null set is a subset of any set. Do you call a node that implements a null subset of the routing functions to be a router? > It can > do that by setting WILLINGNESS equal to zero, and if it is built only > to take such a role it can then throw away large chunks of OLSR code > (for example it never sends TC messages). But the node still has some > router functions. For instance, could you name one? > This is the model of both RFC 2501 and 5889-to-be. > The host can then get its addresses in any non-MANET-specific way on > that node. You didn't say why the node has to be a router, except by pure dint of the logic that it has to be a router. I don't find that terribly convincing -- and, I do find it pretty harmful to the prospects of ad hoc networks. RFC 2501 says: > .... a set > of nodes--which may be combined routers and hosts--themselves form > the network routing infrastructure in an ad hoc fashion. Let's take it as given that the routers in a MANET are the nodes that establish the network connectivity (when possible). Where does it say that a node that DOES NOT do this is then disqualified for residence in an ad hoc network? Regards, Charlie P. From teco@inf-net.nl Tue Aug 24 12:36: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 3C6D03A6A77 for ; Tue, 24 Aug 2010 12:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 w6xKbNI76GBM for ; Tue, 24 Aug 2010 12:34:26 -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 8A4043A69E6 for ; Tue, 24 Aug 2010 12:34:06 -0700 (PDT) Received: by eyd10 with SMTP id 10so3935435eyd.31 for ; Tue, 24 Aug 2010 12:34:32 -0700 (PDT) Received: by 10.213.22.133 with SMTP id n5mr5937136ebb.64.1282678472387; Tue, 24 Aug 2010 12:34:32 -0700 (PDT) Received: from [192.168.2.166] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id u9sm674929eeh.5.2010.08.24.12.34.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Aug 2010 12:34:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <7ir5hoc4wq.fsf@lanthane.pps.jussieu.fr> Date: Tue, 24 Aug 2010 21:34:29 +0200 Content-Transfer-Encoding: 7bit Message-Id: <09E9600F-B654-4533-901A-6CA1EEA100DF@inf-net.nl> References: <7ir5hoc4wq.fsf@lanthane.pps.jussieu.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" , reshmi r Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Aug 2010 19:36:02 -0000 You enter the twilight zone here. I say nodes that run routing protocols, and send routing protocol packets, are routers. Others say these are hosts, if the nodes don't forward packets. Snooping the routing protocol is a corner case, I am OK if host could do this. The problem here is, when a host has no on-link prefix, how can other nodes know the host is reachable? Teco Op 24 aug 2010, om 19:11 heeft Juliusz Chroboczek het volgende geschreven: >> consider for example an OLSR node that does not wish to be a relay, >> only an endpoint. It can do that by setting WILLINGNESS equal to zero, >> and if it is built only to take such a role it can then throw away >> large chunks of OLSR code (for example it never sends TC messages). > > What you're describing is not a router. It's a host that's snooping on > a routing protocol. > > Juliusz > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From teco@inf-net.nl Tue Aug 24 13:16: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 36EDC3A694C for ; Tue, 24 Aug 2010 13:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 nSwghwIM1jV3 for ; Tue, 24 Aug 2010 13:15:58 -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 AAF3B3A694E for ; Tue, 24 Aug 2010 13:15:56 -0700 (PDT) Received: by ewy22 with SMTP id 22so3987812ewy.31 for ; Tue, 24 Aug 2010 13:16:29 -0700 (PDT) Received: by 10.213.63.142 with SMTP id b14mr5970936ebi.33.1282680989038; Tue, 24 Aug 2010 13:16:29 -0700 (PDT) Received: from [192.168.2.166] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id u9sm733019eeh.23.2010.08.24.13.16.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Aug 2010 13:16:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-22--568892277 From: Teco Boot In-Reply-To: Date: Tue, 24 Aug 2010 22:16:25 +0200 Message-Id: <8825A5B9-822A-4121-AEA0-9B741A2AEA3A@inf-net.nl> References: <61114C29-AE94-432F-A678-E81DAF050931@gmail.com> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Fwd: WGLC for the AUTOCONF charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Aug 2010 20:16:03 -0000 --Apple-Mail-22--568892277 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am happy with the dual approach. Some remarks on the draft text: It says that "other nodes will relay messages to the central node". On the list is was discussed the relay function could be co-located on = the node itself. Is such a method rejected? Typo: No new duplicate address detection mechanisms are will be = specified "are" or "will be". This is duplicate already :-) I have problems with: >> it is expected that address uniqueness is >> guaranteed by the central node alone. 1) DHCPv6 doesn't work this way. Addresses are managed by the requesting = node unique token, the DUID. 2) I have seen many DHCP implementations that use (link-local) probing = for duplicate detection. This is for some guarantee for non-duplicates = after a reboot and NV-storage. Quite often, CPE devices don't have = volatile storage. 3) RFC 3315 specifies usage of DAD by the clients (18.1.8), e.g. for = conflict resolving as result of point 2 above.=20 So the expectation is built on quicksand. Still, I think it is the right approach. Maybe just remove this = sentence? =20 Teco Op 21 aug 2010, om 07:50 heeft Thomas Heide Clausen het volgende = geschreven: > Dear All, >=20 > (sorry, traveling and so only catching up on mails now) >=20 > It appears that this email made it to me, but not onto the 'list - for = which we apologize.=20 >=20 > The original WGLC deadline was set to August 26, in view of the = message not making it last time around, the new WGLC deadline is August = 30, 2010 (Ryuji, I have edited your email to that effect). >=20 > Kindly provide your feedback, even if it is to express agreement with = the proposed charter. >=20 > Sincerely yours, >=20 > Thomas >=20 > Begin forwarded message: >=20 >> From: Ryuji Wakikawa >> Date: August 17, 2010 19:05:04 GMT+02:00 >> Subject: WGLC for the AUTOCONF charter >>=20 >> Hi all,=20 >>=20 >> This is another WGLC for our new charter.=20 >> We had good consensus at the meeting, but will confirm the consensus = on the list again. >>=20 >> The deadline for this WGLC is going to be Aug 30. >>=20 >> Please give us your opinion. >>=20 >> regards, >> ryuji >>=20 >> ps. We'll send out the summary of the another WGLC for RFC5889.=20 >>=20 >>=20 >> Ad-Hoc Network Autoconfiguration (autoconf) >> ------------------------------------------- >>=20 >> Current Status: Active >>=20 >> Chairs: >> Ryuji Wakikawa >> Thomas Clausen >>=20 >> Internet Area Directors: >> Ralph Droms >> Jari Arkko >>=20 >> Internet Area Advisor: >> Jari Arkko >>=20 >> Mailing Lists: >> General Discussion: autoconf@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf >> Archive: = http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html >>=20 >> Description of Working Group: >>=20 >> RFC 5889 presents one possible IPv6 addressing model for ad hoc >> nodes. In this model the ad hoc routers need to configure their >> network interface(s) with addresses valid in the ad hoc network, and >> may configure additional prefixes for use by attached nodes. >>=20 >> After completing the work on RFC 5889, the main purpose of the >> AUTOCONF WG is to standardize how existing IPv6 address configuration >> tools can be used for address configuration.=20 >>=20 >> 1. DHCPv6 operation over MANET, including:=20 >>=20 >> - A DHCPv6-based mechanism for configuring required interface >> addresses for the routers in the ad hoc network. This mechanism >> is expected to produce addresses with properties outlined in RFC >> 5889. This mechanism uses the existing DHCPv6 protocol unchanged, >> and assumes a central node that can allocate addresses on a >> first-come-first-served basis. Other nodes in the ad hoc network >> will relay messages to the central node in order to help a new >> node get an address for itself. This mechanism is only suitable >> for deployments were a central node can be set up. It should be >> noted that many existing deployments employ Internet gateways >> that can act as such a central node as well. Future extensions >> such as central node election may make this mechanism suitable >> for also for stand-alone ad hoc networks. >>=20 >> - A DHCPv6-based mechanism for delegating a prefix(es) to each >> router for use by applications running on the routers themselves, >> or for configuration of attached hosts/networks. This mechanism >> works in a similar manner to the one above, but allocates >> prefixes instead of addresses. >>=20 >> Both mechanisms should be independent from operation of any specific >> MANET routing protocol, although may exploit information maintained = by >> such a routing protocol, if available. >>=20 >> The working group will adapt and/or reuse existing protocols whenever >> reasonable and possible. No new duplicate address detection = mechanisms >> are will be specified; it is expected that address uniqueness is >> guaranteed by the central node alone. >>=20 >> 2. Analysis of Problem Space for distributed address configuration = and >> service discovery. >>=20 >>=20 >> The working group plans to establish design teams for rapidly = advancing >> towards initial submissions for these two work items.=20 >>=20 >> Goals and Milestones: >>=20 >> -Dec 2010 First working group draft of the "DHCPv6 operation over = MANET" >> -Dec 2010 First working group draft of the "Analysis of Problem = Space" >> -Sep 2011 Submission of the "DHCPv6 operation over MANET" to the IESG = for >> publication as BCP >> -Sep 2011 Submission of the "Analysis of Problem Space" the IESG for >> publication as Informational RFC >> -Sep 2011 Rechartering or Closing WG=20 >>=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --Apple-Mail-22--568892277 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On the = list is was discussed the relay function could be co-located on the node = itself.
Is such a method = rejected?

Typo: No new duplicate address = detection mechanisms are will be specified
"are" or =  "will be". This is duplicate already = :-)

I have problems with:
it is expected that address uniqueness = is
guaranteed by the central node = alone.
1) = DHCPv6 doesn't work this way. Addresses are managed by the requesting = node unique token, the DUID.
2) I have seen many DHCP = implementations that use (link-local) probing for duplicate detection. = This is for some guarantee for non-duplicates after a reboot and = NV-storage. Quite often, CPE devices don't have volatile = storage.
3) RFC 3315 specifies usage of DAD by the clients = (18.1.8), e.g. for conflict resolving as result of point 2 = above. 
So the expectation is built on = quicksand.
Still, I think it is the right approach. Maybe just = remove this = sentence?
   

Teco
=


Op 21 aug 2010, om 07:50 heeft Thomas = Heide Clausen het volgende geschreven:

Dear = All,

(sorry, traveling and so only catching up on = mails now)

It appears that this email made it = to me, but not onto the 'list - for which we = apologize. 

The original WGLC deadline was = set to August 26, in view of the message not making it last time around, = the new WGLC deadline is August 30, 2010 (Ryuji, I have edited your = email to that effect).

Kindly provide your = feedback, even if it is to express agreement with the proposed = charter.

Sincerely = yours,

Thomas

Begin forwarded = message:

From: Ryuji Wakikawa <ryuji.wakikawa@gmail.com><= br>
Date: August 17, 2010 19:05:04 = GMT+02:00
Subject: WGLC for the AUTOCONF = charter

Hi all,

This is another WGLC = for our new charter.
We had good consensus at the meeting, but will = confirm the consensus on the list again.

The deadline for this = WGLC is going to be Aug 30.

Please give us your = opinion.

regards,
ryuji

ps. We'll send out the summary = of the another WGLC for RFC5889.


Ad-Hoc Network = Autoconfiguration = (autoconf)
-------------------------------------------

Current = Status: Active

Chairs:
Ryuji Wakikawa <ryuji.wakikawa@gmail.com><= br>Thomas Clausen <T.Clausen@computer.org>
<= br>Internet Area Directors:
Ralph Droms <rdroms.ietf@gmail.com>
Jar= i Arkko <jari.arkko@piuha.net>

I= nternet Area Advisor:
Jari Arkko <jari.arkko@piuha.net>

M= ailing Lists:
General Discussion: autoconf@ietf.org
To Subscribe: = https://www.ietf.o= rg/mailman/listinfo/autoconf
Archive: http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html=

Description of Working Group:

RFC 5889 presents one = possible IPv6 addressing model for ad hoc
nodes. In this model the ad = hoc routers need to configure their
network interface(s) with = addresses valid in the ad hoc network, and
may configure additional = prefixes for use by attached nodes.

After completing the work on = RFC 5889, the main purpose of the
AUTOCONF WG is to standardize how = existing IPv6 address configuration
tools can be used for address = configuration.

1. DHCPv6 operation over MANET, including: =

 - A DHCPv6-based mechanism for configuring required = interface
   addresses for the routers in the ad hoc = network. This mechanism
   is expected to produce = addresses with properties outlined in RFC
   5889. = This mechanism uses the existing DHCPv6 protocol unchanged,
=    and assumes a central node that can allocate addresses = on a
   first-come-first-served basis. Other nodes in = the ad hoc network
   will relay messages to the = central node in order to help a new
   node get an = address for itself. This mechanism is only suitable
=    for deployments were a central node can be set up. It = should be
   noted that many existing deployments = employ Internet gateways
   that can act as such a = central node as well. Future extensions
   such as = central node election may make this mechanism suitable
=    for also for stand-alone ad hoc networks.

=  - A DHCPv6-based mechanism for delegating a prefix(es) to each
=    router for use by applications running on the routers = themselves,
   or for configuration of attached = hosts/networks. This mechanism
   works in a similar = manner to the one above, but allocates
   prefixes = instead of addresses.

Both mechanisms should be independent from = operation of any specific
MANET routing protocol, although may = exploit information maintained by
such a routing protocol, if = available.

The working group will adapt and/or reuse existing = protocols whenever
reasonable and possible. No new duplicate address = detection mechanisms
are will be specified; it is expected that = address uniqueness is
guaranteed by the central node alone.

2. = Analysis of Problem Space for distributed address configuration and
=  service discovery.


The working group plans to establish = design teams for rapidly advancing
towards initial submissions for = these two work items.

Goals and Milestones:

-Dec 2010 = First working group draft of the "DHCPv6 operation over MANET"
-Dec = 2010 First working group draft of the "Analysis of Problem = Space"
-Sep 2011 Submission of the "DHCPv6 operation over MANET" to = the IESG for
publication as BCP
-Sep 2011 Submission of the = "Analysis of Problem Space" the IESG for
publication as Informational = RFC
-Sep 2011 Rechartering or Closing WG =


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

= --Apple-Mail-22--568892277-- From Chris.Dearlove@baesystems.com Wed Aug 25 01:41: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 D195A3A6359 for ; Wed, 25 Aug 2010 01:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.671 X-Spam-Level: X-Spam-Status: No, score=-6.671 tagged_above=-999 required=5 tests=[AWL=-0.072, 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 rZtTGj-mQGcg for ; Wed, 25 Aug 2010 01:41:20 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 573833A67C3 for ; Wed, 25 Aug 2010 01:41:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,267,1280703600"; d="scan'208";a="83758090" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 25 Aug 2010 09:41:51 +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 o7P8fp6i008200; Wed, 25 Aug 2010 09:41:51 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 09:41:51 +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: Wed, 25 Aug 2010 09:41:50 +0100 Message-ID: In-Reply-To: <7ir5hoc4wq.fsf@lanthane.pps.jussieu.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Closing summary on consensus-call for RFC5889modifications Thread-Index: ActDr1o2or4gH9KuR3mDDnk2B1e3nAAgc3rw References: <7ir5hoc4wq.fsf@lanthane.pps.jussieu.fr> From: "Dearlove, Christopher (UK)" To: "Juliusz Chroboczek" X-OriginalArrivalTime: 25 Aug 2010 08:41:51.0309 (UTC) FILETIME=[5CE997D0:01CB4431] Cc: autoconf@ietf.org, reshmi r Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Aug 2010 08:41:25 -0000 It's running the routing protocol, and not just listening to it, but engaging actively in it - sending necessary routing protocol messages. It's a router. -- Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability 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: Juliusz Chroboczek [mailto:Juliusz.Chroboczek@pps.jussieu.fr] Sent: 24 August 2010 18:11 To: Dearlove, Christopher (UK) Cc: reshmi r; autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications *** 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. > consider for example an OLSR node that does not wish to be a relay, > only an endpoint. It can do that by setting WILLINGNESS equal to zero, > and if it is built only to take such a role it can then throw away > large chunks of OLSR code (for example it never sends TC messages). What you're describing is not a router. It's a host that's snooping on a routing protocol. Juliusz ******************************************************************** 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 Wed Aug 25 01:44: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 AF4B13A67F0 for ; Wed, 25 Aug 2010 01:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.67 X-Spam-Level: X-Spam-Status: No, score=-6.67 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 vAGKsMZFWGMu for ; Wed, 25 Aug 2010 01:44:36 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 6D30F3A67C3 for ; Wed, 25 Aug 2010 01:44:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,267,1280703600"; d="scan'208";a="83759200" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 25 Aug 2010 09:45:09 +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 o7P8j8jn010810; Wed, 25 Aug 2010 09:45:08 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 09:45:08 +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: Wed, 25 Aug 2010 09:45:07 +0100 Message-ID: In-Reply-To: <4C741EBB.8060909@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Closing summary on consensus-call for RFC5889modifications Thread-Index: ActDw2ELbPsrydRhRyCW1SDKRfqxBQAbgnBw References: <4C741EBB.8060909@earthlink.net> From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" X-OriginalArrivalTime: 25 Aug 2010 08:45:08.0417 (UTC) FILETIME=[D265E310:01CB4431] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Aug 2010 08:44:37 -0000 I didn't make the definition, go back to RFC 2501. If the node is to be mobile, attaching at different points, available as a destination to others, it has to be running something. -- Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability 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: Charles E. Perkins [mailto:charles.perkins@earthlink.net] Sent: 24 August 2010 20:34 To: Dearlove, Christopher (UK) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications *** 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. Hello Chris, A node can easily participate in an ad hoc network without running OLSR or DYMO or any routing protocol. Why make the restriction? I don't understand the value proposition of disenfranchising so many users and invalidating so many use cases. On 8/24/2010 1:55 AM, Dearlove, Christopher (UK) wrote: > a node has been defined as a router plus possible hosts. If you've got > a wireless device that wants to participate in a MANET it needs to be > running an ad hoc routing protocol, i.e. it's a router. Well, opinions vary here, to say the least. > It may perform > only a limited subset of routing functions - consider for example an > OLSR node that does not wish to be a relay, only an endpoint. I can agree, because the null set is a subset of any set. Do you call a node that implements a null subset of the routing functions to be a router? > It can > do that by setting WILLINGNESS equal to zero, and if it is built only > to take such a role it can then throw away large chunks of OLSR code > (for example it never sends TC messages). But the node still has some > router functions. For instance, could you name one? > This is the model of both RFC 2501 and 5889-to-be. > The host can then get its addresses in any non-MANET-specific way on > that node. You didn't say why the node has to be a router, except by pure dint of the logic that it has to be a router. I don't find that terribly convincing -- and, I do find it pretty harmful to the prospects of ad hoc networks. RFC 2501 says: > .... a set > of nodes--which may be combined routers and hosts--themselves form > the network routing infrastructure in an ad hoc fashion. Let's take it as given that the routers in a MANET are the nodes that establish the network connectivity (when possible). Where does it say that a node that DOES NOT do this is then disqualified for residence in an ad hoc network? Regards, Charlie P. ******************************************************************** 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 Wed Aug 25 03:04:39 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 2A2C13A6AB4 for ; Wed, 25 Aug 2010 03:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.116, 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 JQHpxbuUfTnB for ; Wed, 25 Aug 2010 03:04:38 -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 BDEE53A6AAB for ; Wed, 25 Aug 2010 03:04:37 -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 o7PA59tC020604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 25 Aug 2010 12:05:10 +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 o7PA59O7023455 for ; Wed, 25 Aug 2010 12:05:09 +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 o7PA594n012288 for ; Wed, 25 Aug 2010 12:05:09 +0200 Message-ID: <4C74EAD5.7060300@gmail.com> Date: Wed, 25 Aug 2010 12:05:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: autoconf@ietf.org References: <7ir5hoc4wq.fsf@lanthane.pps.jussieu.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Aug 2010 10:04:39 -0000 Le 25/08/2010 10:41, Dearlove, Christopher (UK) a écrit : > It's running the routing protocol, and not just listening > to it, but engaging actively in it - sending necessary > routing protocol messages. It's a router. And a router doesn't necessarily have to run a dynamic routing protocol. A router with static routes (no routing protocol messages) is a router too. Alex > From teco@inf-net.nl Wed Aug 25 06:21: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 593CD3A67F8 for ; Wed, 25 Aug 2010 06:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 ToVKm5xx6vHr for ; Wed, 25 Aug 2010 06:20:59 -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 02C683A697A for ; Wed, 25 Aug 2010 06:20:58 -0700 (PDT) Received: by ewy22 with SMTP id 22so240614ewy.31 for ; Wed, 25 Aug 2010 06:21:30 -0700 (PDT) Received: by 10.213.28.209 with SMTP id n17mr2381856ebc.64.1282742490790; Wed, 25 Aug 2010 06:21:30 -0700 (PDT) Received: from [192.168.2.150] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id z55sm2103817eeh.15.2010.08.25.06.21.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Aug 2010 06:21:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <4C74EAD5.7060300@gmail.com> Date: Wed, 25 Aug 2010 15:21:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <90FAFCBF-7DEA-419E-8B0D-514EE8021B0B@inf-net.nl> References: <7ir5hoc4wq.fsf@lanthane.pps.jussieu.fr> <4C74EAD5.7060300@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Aug 2010 13:21:00 -0000 Alex, Your statement is not accurate. You say: "A router with [whatever] is a router to. Would someone doubt on that? If you intended to say: > A node with static routes (no routing protocol messages) is a router = too. This is definitely not true. Every host may have static routes. I call a node a router if it: - may forward packets; - may send routing protocol packets; - may send router advertisements. Reworded: a host=20 - may not forward packets; - may not send routing protocol packets; - may not send router advertisements. I have device here on my desk. It is called a Wireless-N Home Router. I use it as WiFi AP, Ethernet switch and DHCP server. I don't use it for forwarding packets, because on the yellow marked port it does some nasty NAPT operations, which I can't use in my setup. Shall I bring it back to the shop, and ask for a Wireless-N Home Host? It: - may forward packets, but I disabled it; - may send routing protocol packets, but I disabled it; - may send router advertisements, but I doubt if it supports IPv6. By the way, if I use packet forwarding, NAPT and MAC NAT, it acts as a = host=20 on the Internet port. Providers can't detect it is a router, it is all = hidden. Powerful feature, for where providers don't allow routers connected to = their=20 networks. Teco Op 25 aug 2010, om 12:05 heeft Alexandru Petrescu het volgende = geschreven: > Le 25/08/2010 10:41, Dearlove, Christopher (UK) a =E9crit : >> It's running the routing protocol, and not just listening >> to it, but engaging actively in it - sending necessary >> routing protocol messages. It's a router. >=20 > And a router doesn't necessarily have to run a dynamic routing = protocol. A router with static routes (no routing protocol messages) is = a router too. >=20 > Alex >=20 >>=20 >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From charles.perkins@earthlink.net Wed Aug 25 08: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 5007D3A6B2A for ; Wed, 25 Aug 2010 08: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 FO7tiaq6wIVM for ; Wed, 25 Aug 2010 08:02:08 -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 4F2823A6B32 for ; Wed, 25 Aug 2010 08:02:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=aUiTdy17s2qbGvqKFnNhFjxxucQsWjoqXGPwFOryIPxTVUd0a/akHO9i9dNiDMaI; 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 [24.6.171.143] (helo=[192.168.1.56]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OoHUu-0001sf-PO; Wed, 25 Aug 2010 11:02:41 -0400 Message-ID: <4C75308C.1090506@earthlink.net> Date: Wed, 25 Aug 2010 08:02:36 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" References: <4C741EBB.8060909@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f524e4cb90dc504903dcbe630e3c4d15bac350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.6.171.143 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Aug 2010 15:02:09 -0000 Hello Chris, Follow-up below... On 8/25/2010 1:45 AM, Dearlove, Christopher (UK) wrote: > I didn't make the definition, go back to RFC 2501. I did. I even quoted 2501 in part of my message to you that you didn't answer. > If the node is to be mobile, attaching at different points, > available as a destination to others, it has to be running > something. Mobile nodes do this today and they aren't classified as routers. You can even do it without running Mobile IP to some extent. Regards, Charlie P. On 8/25/2010 1:45 AM, Dearlove, Christopher (UK) wrote: > I didn't make the definition, go back to RFC 2501. > > If the node is to be mobile, attaching at different points, > available as a destination to others, it has to be running > something. > From Chris.Dearlove@baesystems.com Wed Aug 25 08:17: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 EFE613A6A4F for ; Wed, 25 Aug 2010 08:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.669 X-Spam-Level: X-Spam-Status: No, score=-6.669 tagged_above=-999 required=5 tests=[AWL=-0.070, 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 wd6txYkOehLr for ; Wed, 25 Aug 2010 08:17:24 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 4A81C3A6A01 for ; Wed, 25 Aug 2010 08:17:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,268,1280703600"; d="scan'208";a="83892611" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 25 Aug 2010 16:17:56 +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 o7PFHuHr028338; Wed, 25 Aug 2010 16:17:56 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 16:17:56 +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: Wed, 25 Aug 2010 16:17:55 +0100 Message-ID: In-Reply-To: <4C75308C.1090506@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Closing summary on consensus-call for RFC5889modifications Thread-Index: ActEZpjIWZcNHgQxQlSXOnYrBE1zPAAARwoA References: <4C741EBB.8060909@earthlink.net> <4C75308C.1090506@earthlink.net> From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" X-OriginalArrivalTime: 25 Aug 2010 15:17:56.0150 (UTC) FILETIME=[B1DC8D60:01CB4468] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Aug 2010 15:17:28 -0000 I didn't have time to pick up all your points (and I don't really have time even for this, so it will be brief). You asked what router functions the example I gave satisfied: - It's running a routing protocol, and actively participating in it. For example running OLSR it picks MPRs and communicates them. - When a host on that node sends a packet, it chooses which neighbour is to be the next hop (possibly even which interface to use to do that) in order to route correctly. That'll do to be going on from. As for what my mobile is running to pick different points of attachment, it's running an entire UMTS protocol stack (and a GSM one) to select between base stations. And it's a much more asymmetric relationship than any in an ad hoc network. -- Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability 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: Charles E. Perkins [mailto:charles.perkins@earthlink.net] Sent: 25 August 2010 16:03 To: Dearlove, Christopher (UK) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications *** 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. Hello Chris, Follow-up below... On 8/25/2010 1:45 AM, Dearlove, Christopher (UK) wrote: > I didn't make the definition, go back to RFC 2501. I did. I even quoted 2501 in part of my message to you that you didn't answer. > If the node is to be mobile, attaching at different points, > available as a destination to others, it has to be running > something. Mobile nodes do this today and they aren't classified as routers. You can even do it without running Mobile IP to some extent. Regards, Charlie P. On 8/25/2010 1:45 AM, Dearlove, Christopher (UK) wrote: > I didn't make the definition, go back to RFC 2501. > > If the node is to be mobile, attaching at different points, > available as a destination to others, it has to be running > something. > ******************************************************************** 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 Wed Aug 25 09:02: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 945783A6AD0 for ; Wed, 25 Aug 2010 09:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.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 xotRa09Qczfd for ; Wed, 25 Aug 2010 09:02:48 -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 1C4623A68AE for ; Wed, 25 Aug 2010 09:02:47 -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 o7PG3JL4027729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Aug 2010 18:03:19 +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 o7PG3JHd030099; Wed, 25 Aug 2010 18:03:19 +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 o7PG3JwE007573; Wed, 25 Aug 2010 18:03:19 +0200 Message-ID: <4C753EC6.40800@gmail.com> Date: Wed, 25 Aug 2010 18:03:18 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Teco Boot References: <7ir5hoc4wq.fsf@lanthane.pps.jussieu.fr> <4C74EAD5.7060300@gmail.com> <90FAFCBF-7DEA-419E-8B0D-514EE8021B0B@inf-net.nl> In-Reply-To: <90FAFCBF-7DEA-419E-8B0D-514EE8021B0B@inf-net.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Aug 2010 16:02:49 -0000 Le 25/08/2010 15:21, Teco Boot a écrit : > Alex, > > Your statement is not accurate. You say: "A router with [whatever] > is a router to. Would someone doubt on that? Right, a router is a router - always valid. A "machine" with static routes is a router too. > If you intended to say: >> A node with static routes (no routing protocol messages) is a >> router too. > > This is definitely not true. Every host may have static routes. Right. That's why I tend to accept that there are no Hosts in this world and they're all routers, because they all execute longest prefix match searches in their routing tables, they all have at least two interfaces (lo is one), they all have entries in their routing tables. They're all routers, Hosts don't exist. > I call a node a router if it: - may forward packets; - may send > routing protocol packets; - may send router advertisements. > > Reworded: a host - may not forward packets; - may not send routing > protocol packets; - may not send router advertisements. Ah "may" makes it impossible to really distinguish. > I have device here on my desk. It is called a Wireless-N Home Router. > I use it as WiFi AP, Ethernet switch and DHCP server. I don't use it > for forwarding packets, because on the yellow marked port it does > some nasty NAPT operations, which I can't use in my setup. Shall I > bring it back to the shop, and ask for a Wireless-N Home Host? HA haha!! I doubt shop vendor understands "Host" because s/he never sells Hosts to anyone! S/he could sell Routers, Switches, Desktops, Servers ; or it could Host your website if you wish. But never sell you a Host. Who sells Hosts? > It: - may forward packets, but I disabled it; - may send routing > protocol packets, but I disabled it; - may send router > advertisements, but I doubt if it supports IPv6. But that Access Point does have routing table entries, does execute the longest prefix match algorithm, hence it's a Router. > By the way, if I use packet forwarding, NAPT and MAC NAT, it acts as > a host on the Internet port. In a sense. What do you mean it "acts as a Host on the Internet port"? What does NAPT does as algorithm, data structures, which a Router does not, on the Internet port? > Providers can't detect it is a router, it is all hidden. Powerful > feature, for where providers don't allow routers connected to their > networks. Hmm... I think also, as you say, that it is good to distinguish it based on sending RA or NA: if it sends RA then it's a Router, otherwise it's a Host; but disabling RAs on a Router doesn't make it a Host :-) - it makes it an IPv4 Router (another Router :-) Alex > > Teco > > > > Op 25 aug 2010, om 12:05 heeft Alexandru Petrescu het volgende > geschreven: > >> Le 25/08/2010 10:41, Dearlove, Christopher (UK) a écrit : >>> It's running the routing protocol, and not just listening to it, >>> but engaging actively in it - sending necessary routing protocol >>> messages. It's a router. >> >> And a router doesn't necessarily have to run a dynamic routing >> protocol. A router with static routes (no routing protocol >> messages) is a router too. >> >> Alex >> >>> >> >> >> _______________________________________________ Autoconf mailing >> list Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From alexandru.petrescu@gmail.com Wed Aug 25 09:14: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 EA2D33A6B36 for ; Wed, 25 Aug 2010 09:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.113, 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 UoS1VzTpoQrf for ; Wed, 25 Aug 2010 09:14:32 -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 5D4BB3A689F for ; Wed, 25 Aug 2010 09:14:32 -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 o7PGF4nU011354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 25 Aug 2010 18:15:04 +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 o7PGF4Ku031818 for ; Wed, 25 Aug 2010 18:15:04 +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 o7PGF4Jg014309 for ; Wed, 25 Aug 2010 18:15:04 +0200 Message-ID: <4C754187.4090301@gmail.com> Date: Wed, 25 Aug 2010 18:15:03 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: autoconf@ietf.org References: <4C741EBB.8060909@earthlink.net> <4C75308C.1090506@earthlink.net> In-Reply-To: <4C75308C.1090506@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Aug 2010 16:14:34 -0000 Le 25/08/2010 17:02, Charles E. Perkins a écrit : > Hello Chris, > > Follow-up below... > > On 8/25/2010 1:45 AM, Dearlove, Christopher (UK) wrote: > >> I didn't make the definition, go back to RFC 2501. > > I did. I even quoted 2501 in part of my message to you that you > didn't answer. > >> If the node is to be mobile, attaching at different points, >> available as a destination to others, it has to be running >> something. > > Mobile nodes do this today and they aren't classified as routers. Charlie - a Node is a Host "or" a Router - this makes all Mobile Nodes routers... I have a hard time seeing Hosts anywhere actually. I agree that a smartphone with a huge IP stack can do many dynamic addressing and routing things without running dynamic routing protocols, w/o running Mobile IP. And that smartphone is a "Host" in the sense that it is the end of the application (end-to-end), TCP), end of IPsec, has GUI to human fingers and eyes, browses the Web as a Client for entertainment -- all being run sometimes by Routers too... they're all Routers in the end. Maybe we could distinguish them better based on the data structures and algos. Maybe a Host is a machine whose main goal is to run TCP, whereas a Router's main goal is to run longest-prefix match. During one identifiable second a machine doing more MIPS for TCP than for longest-prefix match, is a Host, otherwise it's a Router. A machine with more bytes in the routing table than in the TCP structures, at a given time, is a Host. Or so... Alex You can even do it without running Mobile IP > to some extent. > > Regards, Charlie P. > > > On 8/25/2010 1:45 AM, Dearlove, Christopher (UK) wrote: >> I didn't make the definition, go back to RFC 2501. >> >> If the node is to be mobile, attaching at different points, >> available as a destination to others, it has to be running >> something. >> > > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > From reshmi.engg@gmail.com Wed Aug 25 21:17: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 EC1FA3A6A7B for ; Wed, 25 Aug 2010 21:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 owfbMaBFG9ht for ; Wed, 25 Aug 2010 21:17:50 -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 82C353A695B for ; Wed, 25 Aug 2010 21:17:50 -0700 (PDT) Received: by wwb28 with SMTP id 28so767066wwb.13 for ; Wed, 25 Aug 2010 21:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UsuT65X0Fog8my46hlQJv+aukTjZTWKCx/1MIvnEiko=; b=r/lSQ9CD+1M2xNcCaPCatkdHSpf4fcD2Bk/k6OnYkiVdDv5qQErE57337M1UFffnRZ rapghaHf3BFeUEp3qJv8gqhu1LbmHxlbZjsBPZpPtnZxrdfw24JC7MvOx65bkOGbfmaf HjVacEXUHqRtCADveLk++jQJOoSK49UK3lrJ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=INlvsXdY3u5s2bW8ohYt1rXc3e3vMGEn1blJsObBd1umldppu2vwDyfFhFS9+zp0L+ WncUOoOmi1fVmIqGBogJ/KugDLkoyfQq6DCdIs5K3rkvgLaeayJkhvJovR8NPTxBZQPU MZVoGloggber9W/yStNX1F9O1Xgn25eipOKNc= MIME-Version: 1.0 Received: by 10.227.146.213 with SMTP id i21mr8399707wbv.99.1282796302292; Wed, 25 Aug 2010 21:18:22 -0700 (PDT) Received: by 10.227.40.210 with HTTP; Wed, 25 Aug 2010 21:18:22 -0700 (PDT) In-Reply-To: References: <7ir5hoc4wq.fsf@lanthane.pps.jussieu.fr> Date: Thu, 26 Aug 2010 09:48:22 +0530 Message-ID: From: reshmi r To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Aug 2010 04:17:52 -0000 Christopher, So it mean almost all the nodes replying to the routing messages will be mentioned as router. For eg: As we were discussing before, only some routing protocols like OLSR support Multicast so only in that case you will have much difference for a router and a node. In other cases all the nodes helps in message unicasts and broadcasts so they all have to be mentioned as router. I may define a router as the node which runs a routing protocol in it, then updates the routing information and send the routing informations to other nodes. So here In those protocols which doesnot support multicast every node acts as router. Reshmi.T.R Research Scholar, Ramanujan Computing Center, Anna University- Chennai, Chennai, India On Wed, Aug 25, 2010 at 2:11 PM, Dearlove, Christopher (UK) wrote: > It's running the routing protocol, and not just listening > to it, but engaging actively in it - sending necessary > routing protocol messages. It's a router. > > -- > Christopher Dearlove > Technology Leader, Communications Group > Communications and Networks Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 =A0Fax: +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: Juliusz Chroboczek [mailto:Juliusz.Chroboczek@pps.jussieu.fr] > Sent: 24 August 2010 18:11 > To: Dearlove, Christopher (UK) > Cc: reshmi r; autoconf@ietf.org > Subject: Re: [Autoconf] Closing summary on consensus-call for > RFC5889modifications > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*** WARNING *** > > =A0This message has originated outside your organisation, > =A0either from an external partner or the Global Internet. > =A0 =A0 =A0Keep this in mind if you answer this message. > > >> consider for example an OLSR node that does not wish to be a relay, >> only an endpoint. It can do that by setting WILLINGNESS equal to zero, >> and if it is built only to take such a role it can then throw away >> large chunks of OLSR code (for example it never sends TC messages). > > What you're describing is not a router. =A0It's a host that's snooping on > a routing protocol. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0Juliusz > > > ******************************************************************** > 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 Aug 26 05:31: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 9FE1B3A6873 for ; Thu, 26 Aug 2010 05:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 ngVbQG5g3ssI for ; Thu, 26 Aug 2010 05:30:57 -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 10F233A6AE5 for ; Thu, 26 Aug 2010 05:30:52 -0700 (PDT) Received: by eyd10 with SMTP id 10so1292127eyd.31 for ; Thu, 26 Aug 2010 05:31:25 -0700 (PDT) Received: by 10.213.54.140 with SMTP id q12mr6895375ebg.71.1282825883250; Thu, 26 Aug 2010 05:31:23 -0700 (PDT) Received: from [10.128.0.165] ([77.61.241.196]) by mx.google.com with ESMTPS id a48sm3979978eei.7.2010.08.26.05.31.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Aug 2010 05:31:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <4C753EC6.40800@gmail.com> Date: Thu, 26 Aug 2010 14:31:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <61F3EA79-9B63-46A9-856F-45478EA22043@inf-net.nl> References: <7ir5hoc4wq.fsf@lanthane.pps.jussieu.fr> <4C74EAD5.7060300@gmail.com> <90FAFCBF-7DEA-419E-8B0D-514EE8021B0B@inf-net.nl> <4C753EC6.40800@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Aug 2010 12:31:04 -0000 Alex, You could take some time for research, on hosts having a routing table. Take a start with host requirements (RFC 1122): | As an extra feature, a host IP layer MAY implement a table | of "static routes". Teco Op 25 aug 2010, om 18:03 heeft Alexandru Petrescu het volgende = geschreven: > Le 25/08/2010 15:21, Teco Boot a =E9crit : >> Alex, >>=20 >> Your statement is not accurate. You say: "A router with [whatever] >> is a router to. Would someone doubt on that? >=20 > Right, a router is a router - always valid. >=20 > A "machine" with static routes is a router too. >=20 >> If you intended to say: >>> A node with static routes (no routing protocol messages) is a >>> router too. >>=20 >> This is definitely not true. Every host may have static routes. >=20 > Right. That's why I tend to accept that there are no Hosts in this > world and they're all routers, because they all execute longest prefix > match searches in their routing tables, they all have at least two > interfaces (lo is one), they all have entries in their routing tables. >=20 > They're all routers, Hosts don't exist. >=20 >> I call a node a router if it: - may forward packets; - may send >> routing protocol packets; - may send router advertisements. >>=20 >> Reworded: a host - may not forward packets; - may not send routing >> protocol packets; - may not send router advertisements. >=20 > Ah "may" makes it impossible to really distinguish. >=20 >> I have device here on my desk. It is called a Wireless-N Home Router. >> I use it as WiFi AP, Ethernet switch and DHCP server. I don't use it >> for forwarding packets, because on the yellow marked port it does >> some nasty NAPT operations, which I can't use in my setup. Shall I >> bring it back to the shop, and ask for a Wireless-N Home Host? >=20 > HA haha!! I doubt shop vendor understands "Host" because s/he never > sells Hosts to anyone! S/he could sell Routers, Switches, Desktops, > Servers ; or it could Host your website if you wish. But never sell = you > a Host. Who sells Hosts? >=20 >> It: - may forward packets, but I disabled it; - may send routing >> protocol packets, but I disabled it; - may send router >> advertisements, but I doubt if it supports IPv6. >=20 > But that Access Point does have routing table entries, does execute = the > longest prefix match algorithm, hence it's a Router. >=20 >> By the way, if I use packet forwarding, NAPT and MAC NAT, it acts as >> a host on the Internet port. >=20 > In a sense. What do you mean it "acts as a Host on the Internet = port"? > What does NAPT does as algorithm, data structures, which a Router does > not, on the Internet port? >=20 >> Providers can't detect it is a router, it is all hidden. Powerful >> feature, for where providers don't allow routers connected to their >> networks. >=20 > Hmm... >=20 > I think also, as you say, that it is good to distinguish it based on > sending RA or NA: if it sends RA then it's a Router, otherwise it's a > Host; but disabling RAs on a Router doesn't make it a Host :-) - it > makes it an IPv4 Router (another Router :-) >=20 > Alex >=20 >>=20 >> Teco >>=20 >>=20 >>=20 >> Op 25 aug 2010, om 12:05 heeft Alexandru Petrescu het volgende >> geschreven: >>=20 >>> Le 25/08/2010 10:41, Dearlove, Christopher (UK) a =E9crit : >>>> It's running the routing protocol, and not just listening to it, >>>> but engaging actively in it - sending necessary routing protocol >>>> messages. It's a router. >>>=20 >>> And a router doesn't necessarily have to run a dynamic routing >>> protocol. A router with static routes (no routing protocol >>> messages) is a router too. >>>=20 >>> Alex >>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ Autoconf mailing >>> list Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >>=20 >>=20 >=20 >=20 From alexandru.petrescu@gmail.com Thu Aug 26 06:56: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 4F4A33A687B for ; Thu, 26 Aug 2010 06:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=0.120, 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 1bC6ZcLYP1F9 for ; Thu, 26 Aug 2010 06:56:45 -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 AC01B3A6876 for ; Thu, 26 Aug 2010 06:56:44 -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 o7QDvFUw016764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Aug 2010 15:57:15 +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 o7QDvFr1031763; Thu, 26 Aug 2010 15:57:15 +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 o7QDvFNi006711; Thu, 26 Aug 2010 15:57:15 +0200 Message-ID: <4C7672BB.2080608@gmail.com> Date: Thu, 26 Aug 2010 15:57:15 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Teco Boot References: <7ir5hoc4wq.fsf@lanthane.pps.jussieu.fr> <4C74EAD5.7060300@gmail.com> <90FAFCBF-7DEA-419E-8B0D-514EE8021B0B@inf-net.nl> <4C753EC6.40800@gmail.com> <61F3EA79-9B63-46A9-856F-45478EA22043@inf-net.nl> In-Reply-To: <61F3EA79-9B63-46A9-856F-45478EA22043@inf-net.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Aug 2010 13:56:46 -0000 Le 26/08/2010 14:31, Teco Boot a écrit : > Alex, > > You could take some time for research, on hosts having a routing > table. Take a start with host requirements (RFC 1122): | As an > extra feature, a host IP layer MAY implement a table | of "static > routes". Ah well spot. In practice that is actually a MUST - every IP stack has a table of routes, be it ran by Hosts or by Routers. There's no IP stack without routing table. This is one reason why I think it's difficult to identify a Host which is not a Router, nor a Router which is not a Host. Probably one could call a Host a Host if it does more TCP instructions during 1 second, than routing instructions. Alex > > Teco > > Op 25 aug 2010, om 18:03 heeft Alexandru Petrescu het volgende > geschreven: > >> Le 25/08/2010 15:21, Teco Boot a écrit : >>> Alex, >>> >>> Your statement is not accurate. You say: "A router with >>> [whatever] is a router to. Would someone doubt on that? >> >> Right, a router is a router - always valid. >> >> A "machine" with static routes is a router too. >> >>> If you intended to say: >>>> A node with static routes (no routing protocol messages) is a >>>> router too. >>> >>> This is definitely not true. Every host may have static routes. >> >> Right. That's why I tend to accept that there are no Hosts in this >> world and they're all routers, because they all execute longest >> prefix match searches in their routing tables, they all have at >> least two interfaces (lo is one), they all have entries in their >> routing tables. >> >> They're all routers, Hosts don't exist. >> >>> I call a node a router if it: - may forward packets; - may send >>> routing protocol packets; - may send router advertisements. >>> >>> Reworded: a host - may not forward packets; - may not send >>> routing protocol packets; - may not send router advertisements. >> >> Ah "may" makes it impossible to really distinguish. >> >>> I have device here on my desk. It is called a Wireless-N Home >>> Router. I use it as WiFi AP, Ethernet switch and DHCP server. I >>> don't use it for forwarding packets, because on the yellow >>> marked port it does some nasty NAPT operations, which I can't use >>> in my setup. Shall I bring it back to the shop, and ask for a >>> Wireless-N Home Host? >> >> HA haha!! I doubt shop vendor understands "Host" because s/he >> never sells Hosts to anyone! S/he could sell Routers, Switches, >> Desktops, Servers ; or it could Host your website if you wish. >> But never sell you a Host. Who sells Hosts? >> >>> It: - may forward packets, but I disabled it; - may send routing >>> protocol packets, but I disabled it; - may send router >>> advertisements, but I doubt if it supports IPv6. >> >> But that Access Point does have routing table entries, does >> execute the longest prefix match algorithm, hence it's a Router. >> >>> By the way, if I use packet forwarding, NAPT and MAC NAT, it >>> acts as a host on the Internet port. >> >> In a sense. What do you mean it "acts as a Host on the Internet >> port"? What does NAPT does as algorithm, data structures, which a >> Router does not, on the Internet port? >> >>> Providers can't detect it is a router, it is all hidden. Powerful >>> feature, for where providers don't allow routers connected to >>> their networks. >> >> Hmm... >> >> I think also, as you say, that it is good to distinguish it based >> on sending RA or NA: if it sends RA then it's a Router, otherwise >> it's a Host; but disabling RAs on a Router doesn't make it a Host >> :-) - it makes it an IPv4 Router (another Router :-) >> >> Alex >> >>> >>> Teco >>> >>> >>> >>> Op 25 aug 2010, om 12:05 heeft Alexandru Petrescu het volgende >>> geschreven: >>> >>>> Le 25/08/2010 10:41, Dearlove, Christopher (UK) a écrit : >>>>> It's running the routing protocol, and not just listening to >>>>> it, but engaging actively in it - sending necessary routing >>>>> protocol messages. It's a router. >>>> >>>> And a router doesn't necessarily have to run a dynamic routing >>>> protocol. A router with static routes (no routing protocol >>>> messages) is a router too. >>>> >>>> Alex >>>> >>>>> >>>> >>>> >>>> _______________________________________________ Autoconf >>>> mailing list Autoconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/autoconf >>> >>> >> >> > > From charles.perkins@earthlink.net Thu Aug 26 06:59: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 BBC743A6876 for ; Thu, 26 Aug 2010 06:59:34 -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 KP1+VVhW2QOI for ; Thu, 26 Aug 2010 06:59:30 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 396D33A687D for ; Thu, 26 Aug 2010 06:59:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=fjikwgsrPuuYBqiQyO7IV19lGkFMGf2nI0j1tj+sKTXjndIpUr28MgC7DF90YXjW; 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 [207.74.239.6] (helo=[10.150.0.248]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ooczq-0001we-MK; Thu, 26 Aug 2010 10:00:02 -0400 Message-ID: <4C767360.7050805@earthlink.net> Date: Thu, 26 Aug 2010 07:00:00 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" References: <4C741EBB.8060909@earthlink.net> <4C75308C.1090506@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f522a1a10624c732f7517c5f3c3795f351e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 207.74.239.6 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Aug 2010 13:59:34 -0000 Hello Christopher, I didn't ask what functions YOUR routers performed. I asked what functions a node would be REQUIRED to perform in order to communicate in an ad hoc network. A host does NOT have to pick MPRs in order to forward packets to a default router. A host does NOT have to run a routing protocol in order to identify one or more default routers. A host does NOT have to run a routing protocol in order to select among network interfaces for delivering packets to one of its possibly several default routers. Surely it must be possible to have a discussion about this without meandering afar from the point. Regards, Charlie P. On 8/25/2010 8:17 AM, Dearlove, Christopher (UK) wrote: > I didn't have time to pick up all your points (and I don't > really have time even for this, so it will be brief). > > You asked what router functions the example I gave satisfied: > > - It's running a routing protocol, and actively participating in > it. For example running OLSR it picks MPRs and communicates > them. > > - When a host on that node sends a packet, it chooses which > neighbour is to be the next hop (possibly even which interface > to use to do that) in order to route correctly. > > That'll do to be going on from. > > As for what my mobile is running to pick different points of > attachment, it's running an entire UMTS protocol stack (and > a GSM one) to select between base stations. And it's a much > more asymmetric relationship than any in an ad hoc network. > From charles.perkins@earthlink.net Thu Aug 26 07:06: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 0DB973A69A6 for ; Thu, 26 Aug 2010 07:06: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 98hZEixRYIMS for ; Thu, 26 Aug 2010 07:06:01 -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 AC3ED3A699E for ; Thu, 26 Aug 2010 07:06:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Ngv8aWs1tp3S/nVf0vD9x1QttaMDZ3+Qq5jcyAqhwlvUIN6IO1M4frEzD0qmLG9n; 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 [207.74.239.6] (helo=[10.150.0.248]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ood69-0003pU-6B; Thu, 26 Aug 2010 10:06:33 -0400 Message-ID: <4C7674E7.1010703@earthlink.net> Date: Thu, 26 Aug 2010 07:06:31 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Teco Boot References: <7ir5hoc4wq.fsf@lanthane.pps.jussieu.fr><4C74EAD5.7060300@gmail.com><90FAFCBF-7DEA-419E-8B0D-514EE8021B0B@inf-net.nl><4C753EC6.40800@gmail.com> <61F3EA79-9B63-46A9-856F-45478EA22043@inf-net.nl> In-Reply-To: <61F3EA79-9B63-46A9-856F-45478EA22043@inf-net.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52036464c33c89deecb303ec684d8acc87350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 207.74.239.6 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call forRFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Aug 2010 14:06:03 -0000 Hello Teco, I'd like to propose how we can distinguish routers from hosts, as follows: - If a node forwards packets as an intermediate node in a routing path, it is a "router". - Otherwise, it is "host". As one example, suppose network entity X runs a routing protocol and exchanges routing tables. Furthermore, suppose X drops every packet that it receives unless the destination address is X's IP address. I do not call X a router. Suppose instead that X forwards every other packet. I call X a defective router. You might instead prefer to call X a router if it exchanges routing tables with its neighbors. That is also workable, I think, but less convenient and vulnerable to arguments related to the use of SNMP. Anyway, for all those who cannot tell the difference between routers and hosts by any definition whatsoever, I can't see how it matters what terminology the proposed RFC might use. Regards, Charlie P. On 8/26/2010 5:31 AM, Teco Boot wrote: > Alex, > > You could take some time for research, on hosts having a routing table. > Take a start with host requirements (RFC 1122): > | As an extra feature, a host IP layer MAY implement a table > | of "static routes". > > Teco > > Op 25 aug 2010, om 18:03 heeft Alexandru Petrescu het volgende geschreven: > >> Le 25/08/2010 15:21, Teco Boot a écrit : >>> Alex, >>> >>> Your statement is not accurate. You say: "A router with [whatever] >>> is a router to. Would someone doubt on that? >> >> Right, a router is a router - always valid. >> >> A "machine" with static routes is a router too. >> >>> If you intended to say: >>>> A node with static routes (no routing protocol messages) is a >>>> router too. >>> >>> This is definitely not true. Every host may have static routes. >> >> Right. That's why I tend to accept that there are no Hosts in this >> world and they're all routers, because they all execute longest prefix >> match searches in their routing tables, they all have at least two >> interfaces (lo is one), they all have entries in their routing tables. >> >> They're all routers, Hosts don't exist. >> >>> I call a node a router if it: - may forward packets; - may send >>> routing protocol packets; - may send router advertisements. >>> >>> Reworded: a host - may not forward packets; - may not send routing >>> protocol packets; - may not send router advertisements. >> >> Ah "may" makes it impossible to really distinguish. >> >>> I have device here on my desk. It is called a Wireless-N Home Router. >>> I use it as WiFi AP, Ethernet switch and DHCP server. I don't use it >>> for forwarding packets, because on the yellow marked port it does >>> some nasty NAPT operations, which I can't use in my setup. Shall I >>> bring it back to the shop, and ask for a Wireless-N Home Host? >> >> HA haha!! I doubt shop vendor understands "Host" because s/he never >> sells Hosts to anyone! S/he could sell Routers, Switches, Desktops, >> Servers ; or it could Host your website if you wish. But never sell you >> a Host. Who sells Hosts? >> >>> It: - may forward packets, but I disabled it; - may send routing >>> protocol packets, but I disabled it; - may send router >>> advertisements, but I doubt if it supports IPv6. >> >> But that Access Point does have routing table entries, does execute the >> longest prefix match algorithm, hence it's a Router. >> >>> By the way, if I use packet forwarding, NAPT and MAC NAT, it acts as >>> a host on the Internet port. >> >> In a sense. What do you mean it "acts as a Host on the Internet port"? >> What does NAPT does as algorithm, data structures, which a Router does >> not, on the Internet port? >> >>> Providers can't detect it is a router, it is all hidden. Powerful >>> feature, for where providers don't allow routers connected to their >>> networks. >> >> Hmm... >> >> I think also, as you say, that it is good to distinguish it based on >> sending RA or NA: if it sends RA then it's a Router, otherwise it's a >> Host; but disabling RAs on a Router doesn't make it a Host :-) - it >> makes it an IPv4 Router (another Router :-) >> >> Alex >> >>> >>> Teco >>> >>> >>> >>> Op 25 aug 2010, om 12:05 heeft Alexandru Petrescu het volgende >>> geschreven: >>> >>>> Le 25/08/2010 10:41, Dearlove, Christopher (UK) a écrit : >>>>> It's running the routing protocol, and not just listening to it, >>>>> but engaging actively in it - sending necessary routing protocol >>>>> messages. It's a router. >>>> >>>> And a router doesn't necessarily have to run a dynamic routing >>>> protocol. A router with static routes (no routing protocol >>>> messages) is a router too. >>>> >>>> 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 Chris.Dearlove@baesystems.com Thu Aug 26 07:20: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 0B59A3A69CC for ; Thu, 26 Aug 2010 07:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.667 X-Spam-Level: X-Spam-Status: No, score=-6.667 tagged_above=-999 required=5 tests=[AWL=-0.068, 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 gRalShsl49Dc for ; Thu, 26 Aug 2010 07:20:58 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id BD34A3A683C for ; Thu, 26 Aug 2010 07:20:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,273,1280703600"; d="scan'208";a="84112578" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 26 Aug 2010 15:21:28 +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 o7QELRr5028039; Thu, 26 Aug 2010 15:21:27 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Aug 2010 15:21:27 +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, 26 Aug 2010 15:21:27 +0100 Message-ID: In-Reply-To: <4C767360.7050805@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Closing summary on consensus-call for RFC5889modifications Thread-Index: ActFJvxhJVV4i5zaQ0GEywDfRN5ioAAAcYGQ References: <4C741EBB.8060909@earthlink.net> <4C75308C.1090506@earthlink.net> <4C767360.7050805@earthlink.net> From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" X-OriginalArrivalTime: 26 Aug 2010 14:21:27.0713 (UTC) FILETIME=[F89BD910:01CB4529] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Aug 2010 14:20:59 -0000 This started from the specific example, so that is clearly quite to the point. You may now be discussing other cases, but that's another matter. If by a node we mean a physically separate entity (in a wireless network) and if we allow that node to be independently mobile and to connect to other nodes (otherwise it's not really an ad hoc node) and it is to be unicast reachable from elsewhere in the network via one of those other nodes, then it has to be running something. It's for you to indicate what that something is and why that isn't a routing protocol, despite having some (agreed, not all) routing functions, and how it will work in a MANET with wireless links (with the usual non-transitive properties). Otherwise you are asking me to prove a negative, and we know how easy that is. -- Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability 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: Charles E. Perkins [mailto:charles.perkins@earthlink.net] Sent: 26 August 2010 15:00 To: Dearlove, Christopher (UK) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications *** 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. Hello Christopher, I didn't ask what functions YOUR routers performed. I asked what functions a node would be REQUIRED to perform in order to communicate in an ad hoc network. A host does NOT have to pick MPRs in order to forward packets to a default router. A host does NOT have to run a routing protocol in order to identify one or more default routers. A host does NOT have to run a routing protocol in order to select among network interfaces for delivering packets to one of its possibly several default routers. Surely it must be possible to have a discussion about this without meandering afar from the point. Regards, Charlie P. On 8/25/2010 8:17 AM, Dearlove, Christopher (UK) wrote: > I didn't have time to pick up all your points (and I don't > really have time even for this, so it will be brief). > > You asked what router functions the example I gave satisfied: > > - It's running a routing protocol, and actively participating in > it. For example running OLSR it picks MPRs and communicates > them. > > - When a host on that node sends a packet, it chooses which > neighbour is to be the next hop (possibly even which interface > to use to do that) in order to route correctly. > > That'll do to be going on from. > > As for what my mobile is running to pick different points of > attachment, it's running an entire UMTS protocol stack (and > a GSM one) to select between base stations. And it's a much > more asymmetric relationship than any in an ad hoc network. > ******************************************************************** 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 Aug 26 11:06: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 70BC53A686B for ; Thu, 26 Aug 2010 11:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 OYdB2Yx3njgy for ; Thu, 26 Aug 2010 11:06:44 -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 7211C3A6892 for ; Thu, 26 Aug 2010 11:06:36 -0700 (PDT) Received: by ewy22 with SMTP id 22so1609493ewy.31 for ; Thu, 26 Aug 2010 11:07:08 -0700 (PDT) Received: by 10.213.76.16 with SMTP id a16mr7477979ebk.90.1282846028560; Thu, 26 Aug 2010 11:07:08 -0700 (PDT) Received: from [192.168.2.150] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id a48sm4463134eei.0.2010.08.26.11.07.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Aug 2010 11:07:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <4C7672BB.2080608@gmail.com> Date: Thu, 26 Aug 2010 20:07:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4A2DBD8D-953F-4C02-9FEE-EC91D22E9588@inf-net.nl> References: <7ir5hoc4wq.fsf@lanthane.pps.jussieu.fr> <4C74EAD5.7060300@gmail.com> <90FAFCBF-7DEA-419E-8B0D-514EE8021B0B@inf-net.nl> <4C753EC6.40800@gmail.com> <61F3EA79-9B63-46A9-856F-45478EA22043@inf-net.nl> <4C7672BB.2080608@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Aug 2010 18:06:45 -0000 Alex, In my environment, host don't use TCP very often. My apps use UDP. Internet core routers often use BGP, which run on TCP. Let's stick on more commonly used differentiators. Like forwarding packets, sending RA or sending routing protocol packets. Teco Op 26 aug 2010, om 15:57 heeft Alexandru Petrescu het volgende = geschreven: > Le 26/08/2010 14:31, Teco Boot a =E9crit : >> Alex, >>=20 >> You could take some time for research, on hosts having a routing >> table. Take a start with host requirements (RFC 1122): | As an >> extra feature, a host IP layer MAY implement a table | of "static >> routes". >=20 > Ah well spot. In practice that is actually a MUST - every IP stack = has > a table of routes, be it ran by Hosts or by Routers. There's no IP > stack without routing table. >=20 > This is one reason why I think it's difficult to identify a Host which > is not a Router, nor a Router which is not a Host. >=20 > Probably one could call a Host a Host if it does more TCP instructions > during 1 second, than routing instructions. >=20 > Alex >=20 >>=20 >> Teco >>=20 >> Op 25 aug 2010, om 18:03 heeft Alexandru Petrescu het volgende >> geschreven: >>=20 >>> Le 25/08/2010 15:21, Teco Boot a =E9crit : >>>> Alex, >>>>=20 >>>> Your statement is not accurate. You say: "A router with >>>> [whatever] is a router to. Would someone doubt on that? >>>=20 >>> Right, a router is a router - always valid. >>>=20 >>> A "machine" with static routes is a router too. >>>=20 >>>> If you intended to say: >>>>> A node with static routes (no routing protocol messages) is a >>>>> router too. >>>>=20 >>>> This is definitely not true. Every host may have static routes. >>>=20 >>> Right. That's why I tend to accept that there are no Hosts in this >>> world and they're all routers, because they all execute longest >>> prefix match searches in their routing tables, they all have at >>> least two interfaces (lo is one), they all have entries in their >>> routing tables. >>>=20 >>> They're all routers, Hosts don't exist. >>>=20 >>>> I call a node a router if it: - may forward packets; - may send >>>> routing protocol packets; - may send router advertisements. >>>>=20 >>>> Reworded: a host - may not forward packets; - may not send >>>> routing protocol packets; - may not send router advertisements. >>>=20 >>> Ah "may" makes it impossible to really distinguish. >>>=20 >>>> I have device here on my desk. It is called a Wireless-N Home >>>> Router. I use it as WiFi AP, Ethernet switch and DHCP server. I >>>> don't use it for forwarding packets, because on the yellow >>>> marked port it does some nasty NAPT operations, which I can't use >>>> in my setup. Shall I bring it back to the shop, and ask for a >>>> Wireless-N Home Host? >>>=20 >>> HA haha!! I doubt shop vendor understands "Host" because s/he >>> never sells Hosts to anyone! S/he could sell Routers, Switches, >>> Desktops, Servers ; or it could Host your website if you wish. >>> But never sell you a Host. Who sells Hosts? >>>=20 >>>> It: - may forward packets, but I disabled it; - may send routing >>>> protocol packets, but I disabled it; - may send router >>>> advertisements, but I doubt if it supports IPv6. >>>=20 >>> But that Access Point does have routing table entries, does >>> execute the longest prefix match algorithm, hence it's a Router. >>>=20 >>>> By the way, if I use packet forwarding, NAPT and MAC NAT, it >>>> acts as a host on the Internet port. >>>=20 >>> In a sense. What do you mean it "acts as a Host on the Internet >>> port"? What does NAPT does as algorithm, data structures, which a >>> Router does not, on the Internet port? >>>=20 >>>> Providers can't detect it is a router, it is all hidden. Powerful >>>> feature, for where providers don't allow routers connected to >>>> their networks. >>>=20 >>> Hmm... >>>=20 >>> I think also, as you say, that it is good to distinguish it based >>> on sending RA or NA: if it sends RA then it's a Router, otherwise >>> it's a Host; but disabling RAs on a Router doesn't make it a Host >>> :-) - it makes it an IPv4 Router (another Router :-) >>>=20 >>> Alex >>>=20 >>>>=20 >>>> Teco >>>>=20 >>>>=20 >>>>=20 >>>> Op 25 aug 2010, om 12:05 heeft Alexandru Petrescu het volgende >>>> geschreven: >>>>=20 >>>>> Le 25/08/2010 10:41, Dearlove, Christopher (UK) a =E9crit : >>>>>> It's running the routing protocol, and not just listening to >>>>>> it, but engaging actively in it - sending necessary routing >>>>>> protocol messages. It's a router. >>>>>=20 >>>>> And a router doesn't necessarily have to run a dynamic routing >>>>> protocol. A router with static routes (no routing protocol >>>>> messages) is a router too. >>>>>=20 >>>>> Alex >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ Autoconf >>>>> mailing list Autoconf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/autoconf >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From teco@inf-net.nl Thu Aug 26 11: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 9CBB73A6A6F for ; Thu, 26 Aug 2010 11:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nLQNySzmzX4 for ; Thu, 26 Aug 2010 11:16:58 -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 875343A69F1 for ; Thu, 26 Aug 2010 11:16:57 -0700 (PDT) Received: by ewy22 with SMTP id 22so1619438ewy.31 for ; Thu, 26 Aug 2010 11:17:29 -0700 (PDT) Received: by 10.213.15.65 with SMTP id j1mr1112089eba.79.1282846649386; Thu, 26 Aug 2010 11:17:29 -0700 (PDT) Received: from [192.168.2.150] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id v8sm4474425eeh.8.2010.08.26.11.17.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Aug 2010 11:17:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4C767360.7050805@earthlink.net> Date: Thu, 26 Aug 2010 20:17:26 +0200 Content-Transfer-Encoding: 7bit Message-Id: <7E56B44F-80A1-4A19-9498-0AACAFC5B4D9@inf-net.nl> References: <4C741EBB.8060909@earthlink.net> <4C75308C.1090506@earthlink.net> <4C767360.7050805@earthlink.net> To: Charles E. Perkins X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Aug 2010 18:17:01 -0000 Charlie, Learning default gateways in a passive mode is well accepted behavior of hosts. It is mentioned in RFC 1122: | This technique depends upon the host passively | receiving ("wiretapping") the Interior Gateway Protocol | (IGP) datagrams that the gateways are broadcasting to | each other. But signaling from hosts to routers is another story. We have NDP or ARP for this. One could think of redistributing NDP / ARP learned routing info into the routing protocol. I am not sure we should go there. Teco Op 26 aug 2010, om 16:00 heeft Charles E. Perkins het volgende geschreven: > > Hello Christopher, > > I didn't ask what functions YOUR routers performed. > > I asked what functions a node would be REQUIRED to > perform in order to communicate in an ad hoc network. > > A host does NOT have to pick MPRs in order to > forward packets to a default router. A host does > NOT have to run a routing protocol in order to > identify one or more default routers. A host > does NOT have to run a routing protocol in order > to select among network interfaces for delivering > packets to one of its possibly several default > routers. > > Surely it must be possible to have a discussion > about this without meandering afar from the point. > > Regards, > Charlie P. > > > On 8/25/2010 8:17 AM, Dearlove, Christopher (UK) wrote: >> I didn't have time to pick up all your points (and I don't >> really have time even for this, so it will be brief). >> >> You asked what router functions the example I gave satisfied: >> >> - It's running a routing protocol, and actively participating in >> it. For example running OLSR it picks MPRs and communicates >> them. >> >> - When a host on that node sends a packet, it chooses which >> neighbour is to be the next hop (possibly even which interface >> to use to do that) in order to route correctly. >> >> That'll do to be going on from. >> >> As for what my mobile is running to pick different points of >> attachment, it's running an entire UMTS protocol stack (and >> a GSM one) to select between base stations. And it's a much >> more asymmetric relationship than any in an ad hoc network. >> > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Thu Aug 26 13:08: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 765B23A6AAE for ; Thu, 26 Aug 2010 13:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[AWL=0.637, 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 YrqXA8wManeo for ; Thu, 26 Aug 2010 13:08:33 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id E86463A697D for ; Thu, 26 Aug 2010 13:08:31 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 5166494016B; Thu, 26 Aug 2010 22:08:57 +0200 (CEST) Message-ID: <4C76C9C0.7090407@gmail.com> Date: Thu, 26 Aug 2010 22:08:32 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Teco Boot References: <7ir5hoc4wq.fsf@lanthane.pps.jussieu.fr> <4C74EAD5.7060300@gmail.com> <90FAFCBF-7DEA-419E-8B0D-514EE8021B0B@inf-net.nl> <4C753EC6.40800@gmail.com> <61F3EA79-9B63-46A9-856F-45478EA22043@inf-net.nl> <4C7672BB.2080608@gmail.com> <4A2DBD8D-953F-4C02-9FEE-EC91D22E9588@inf-net.nl> In-Reply-To: <4A2DBD8D-953F-4C02-9FEE-EC91D22E9588@inf-net.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100826-1, 26/08/2010), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 26 Aug 2010 20:08:34 -0000 Let's try to loop this Router-Host definition towards the original post intention, not immediately, but let's at least try. Le 26/08/2010 20:07, Teco Boot a écrit : > Alex, > > In my environment, host don't use TCP very often. My apps use UDP. > Internet core routers often use BGP, which run on TCP. Let's stick > on more commonly used differentiators. Like forwarding packets, > sending RA or sending routing protocol packets. If the distinguisher for Routers is "forward packets whose dst is not self, _instead of dropping_ " the distinguisher for Hosts could be "drop packets whose dst is not self, instead of forwarding". In this sense, sending or receiving routing protocol packets is actually a Host characteristic, because dst is self at reception. Remind the original topic problem? How do the different suggestions Host-Router we make could affect the use of "Router" vs the use of "Host" in the title? I could live with the RFC title saying this is about Routers, because people on this list seem to understand a Router to be a Host too and vice-versa. Nobody seems to be ready to actually list the things a computer does making it a Router (and not a Host). If so, why the struggle? If you want to list the things, let me start: An IPv6 Router (remark, not simply "a Router") does these things which an IPv6 Host does not: -MUST send RA (a Host MUST NOT). -MUST forward packets whose dst address is not assigned to any of its interfaces (a Host MUST drop packets whose dst is not assigned to any of its interfaces, and must further process and still not forward packets whose dst is assigned to at least one address assigned to one of its interfaces, _or_ part of a multicast group to which this host has previously subscribed). -MUST send ICMP Redirect (a Host MUST NOT) if the need is present. -MAY join a multicast group, in the perspective of using that group subscription later as a Host. -MUST decrement the Hop Limit (a Host MUST NOT). -MUST NOT process the IPsec headers (a Host MUST). -there are surely others - but are you willing to continue. Remark the sending of routing protocol messages is not part of this list, because it's actually a Host characteristic. And, if you find exception to any of these rules - feel free to do so, then please come up with some means to define them better, and continue on it. There is much lack of discussion synthesis here. Alex > > Teco > > > Op 26 aug 2010, om 15:57 heeft Alexandru Petrescu het volgende > geschreven: > >> Le 26/08/2010 14:31, Teco Boot a écrit : >>> Alex, >>> >>> You could take some time for research, on hosts having a routing >>> table. Take a start with host requirements (RFC 1122): | As an >>> extra feature, a host IP layer MAY implement a table | of >>> "static routes". >> >> Ah well spot. In practice that is actually a MUST - every IP >> stack has a table of routes, be it ran by Hosts or by Routers. >> There's no IP stack without routing table. >> >> This is one reason why I think it's difficult to identify a Host >> which is not a Router, nor a Router which is not a Host. >> >> Probably one could call a Host a Host if it does more TCP >> instructions during 1 second, than routing instructions. >> >> Alex >> >>> >>> Teco >>> >>> Op 25 aug 2010, om 18:03 heeft Alexandru Petrescu het volgende >>> geschreven: >>> >>>> Le 25/08/2010 15:21, Teco Boot a écrit : >>>>> Alex, >>>>> >>>>> Your statement is not accurate. You say: "A router with >>>>> [whatever] is a router to. Would someone doubt on that? >>>> >>>> Right, a router is a router - always valid. >>>> >>>> A "machine" with static routes is a router too. >>>> >>>>> If you intended to say: >>>>>> A node with static routes (no routing protocol messages) >>>>>> is a router too. >>>>> >>>>> This is definitely not true. Every host may have static >>>>> routes. >>>> >>>> Right. That's why I tend to accept that there are no Hosts in >>>> this world and they're all routers, because they all execute >>>> longest prefix match searches in their routing tables, they >>>> all have at least two interfaces (lo is one), they all have >>>> entries in their routing tables. >>>> >>>> They're all routers, Hosts don't exist. >>>> >>>>> I call a node a router if it: - may forward packets; - may >>>>> send routing protocol packets; - may send router >>>>> advertisements. >>>>> >>>>> Reworded: a host - may not forward packets; - may not send >>>>> routing protocol packets; - may not send router >>>>> advertisements. >>>> >>>> Ah "may" makes it impossible to really distinguish. >>>> >>>>> I have device here on my desk. It is called a Wireless-N Home >>>>> Router. I use it as WiFi AP, Ethernet switch and DHCP server. >>>>> I don't use it for forwarding packets, because on the yellow >>>>> marked port it does some nasty NAPT operations, which I can't >>>>> use in my setup. Shall I bring it back to the shop, and ask >>>>> for a Wireless-N Home Host? >>>> >>>> HA haha!! I doubt shop vendor understands "Host" because s/he >>>> never sells Hosts to anyone! S/he could sell Routers, >>>> Switches, Desktops, Servers ; or it could Host your website if >>>> you wish. But never sell you a Host. Who sells Hosts? >>>> >>>>> It: - may forward packets, but I disabled it; - may send >>>>> routing protocol packets, but I disabled it; - may send >>>>> router advertisements, but I doubt if it supports IPv6. >>>> >>>> But that Access Point does have routing table entries, does >>>> execute the longest prefix match algorithm, hence it's a >>>> Router. >>>> >>>>> By the way, if I use packet forwarding, NAPT and MAC NAT, it >>>>> acts as a host on the Internet port. >>>> >>>> In a sense. What do you mean it "acts as a Host on the >>>> Internet port"? What does NAPT does as algorithm, data >>>> structures, which a Router does not, on the Internet port? >>>> >>>>> Providers can't detect it is a router, it is all hidden. >>>>> Powerful feature, for where providers don't allow routers >>>>> connected to their networks. >>>> >>>> Hmm... >>>> >>>> I think also, as you say, that it is good to distinguish it >>>> based on sending RA or NA: if it sends RA then it's a Router, >>>> otherwise it's a Host; but disabling RAs on a Router doesn't >>>> make it a Host :-) - it makes it an IPv4 Router (another >>>> Router :-) >>>> >>>> Alex >>>> >>>>> >>>>> Teco >>>>> >>>>> >>>>> >>>>> Op 25 aug 2010, om 12:05 heeft Alexandru Petrescu het >>>>> volgende geschreven: >>>>> >>>>>> Le 25/08/2010 10:41, Dearlove, Christopher (UK) a écrit : >>>>>>> It's running the routing protocol, and not just >>>>>>> listening to it, but engaging actively in it - sending >>>>>>> necessary routing protocol messages. It's a router. >>>>>> >>>>>> And a router doesn't necessarily have to run a dynamic >>>>>> routing protocol. A router with static routes (no routing >>>>>> protocol messages) is a router too. >>>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ Autoconf >>>>>> mailing list Autoconf@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/autoconf >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > From charles.perkins@earthlink.net Thu Aug 26 20:26: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 1CF033A6966 for ; Thu, 26 Aug 2010 20:26:28 -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 Yh2Kg8EQWWXm for ; Thu, 26 Aug 2010 20:26:26 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 9B6493A684D for ; Thu, 26 Aug 2010 20:26:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gfYDUDq5E35rIZ8sYhq5Z6hauQDfZ7gNFRsE8/6O5ITpAD8LVuO9oMLbLwvy30D+; 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 [207.74.239.6] (helo=[10.150.0.248]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Oopak-0005P4-JV; Thu, 26 Aug 2010 23:26:58 -0400 Message-ID: <4C773080.8010601@earthlink.net> Date: Thu, 26 Aug 2010 20:26:56 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" References: <4C741EBB.8060909@earthlink.net> <4C75308C.1090506@earthlink.net> <4C767360.7050805@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52107029ea7d6d7f1f97ef16824093a6fd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 207.74.239.6 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Aug 2010 03:26:28 -0000 Hello Chris, I'm responding again, because I'd like to have a fruitful discussion. On 8/26/2010 7:21 AM, Dearlove, Christopher (UK) wrote: > This started from the specific example, so that is clearly quite > to the point. You may now be discussing other cases, but that's > another matter. Do you mean the specific example of your nodes running OLSR and identifying MPRs? I'm happy to agree that your nodes are routers. If I discussed other cases, it was only to reach the goal of identifying the boundary between hostness and routerness. Is that sufficiently to the point? > If by a node we mean a physically separate entity (in a > wireless network) and if we allow that node to be independently > mobile and to connect to other nodes (otherwise it's not really > an ad hoc node) and it is to be unicast reachable from elsewhere > in the network via one of those other nodes, then it has to be > running something. Obviously... it's running some computer programs. If a node runs ARP, is it a router? > It's for you to indicate what that something > is and why that isn't a routing protocol, despite having some > (agreed, not all) routing functions, and how it will work in a > MANET with wireless links (with the usual non-transitive > properties). I already mentioned several examples. Should I do it again? What about a node running ND? What about a node snooping the airwaves? What about a node running Mobile IP? I've just scratched the surface of examples. In fact I'll even play dirty and keep you in suspense to wait for a new Internet Draft I am co-authoring on this subject. > Otherwise you are asking me to prove a negative, and we know > how easy that is. I'm asking you to accept that a node can beneficially reside in an ad hoc network without being a router. What is negative about that? Unless I completely misunderstand your point of view, this is not in any way asking you to prove a negative. Of course it is possible to prove a negative proposition. But, I have not asked you to do so. Or, what negative proposition do you believe I have postulated for your consideration? If I put "not" in any point of discussion, have I exceeded my boundaries of feasible communication? Regards, Charlie P. From Chris.Dearlove@baesystems.com Fri Aug 27 01:26: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 62AFA3A6B6E for ; Fri, 27 Aug 2010 01:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.666 X-Spam-Level: X-Spam-Status: No, score=-6.666 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 BcL9S-cPdtrL for ; Fri, 27 Aug 2010 01:26:29 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id AD6043A699C for ; Fri, 27 Aug 2010 01:26:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,277,1280703600"; d="scan'208";a="84234501" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 27 Aug 2010 09:27: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 o7R8QxGA010316; Fri, 27 Aug 2010 09:27:00 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Aug 2010 09:26:59 +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, 27 Aug 2010 09:26:58 +0100 Message-ID: In-Reply-To: <4C773080.8010601@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Closing summary on consensus-call for RFC5889modifications Thread-Index: ActFl7YnX0ea92nMS465kqZlbAaEQQAKGXVQ References: <4C741EBB.8060909@earthlink.net> <4C75308C.1090506@earthlink.net> <4C767360.7050805@earthlink.net> <4C773080.8010601@earthlink.net> From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" X-OriginalArrivalTime: 27 Aug 2010 08:26:59.0629 (UTC) FILETIME=[9E4185D0:01CB45C1] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Aug 2010 08:26:30 -0000 I'm failing to see how any of the examples you quote (which I agree, would not make a node a router) are sufficient for all of the functionality I noted. I really would like (but I'll be unable to reply to for at least some days - it's a long weekend coming up) to know how you get the functionality. Ideally I'd like equivalent functionality to the OLSR example, what I wouldn't count is where a host node is permanently (albeit wirelessly) attached to a single other router node. How far from the latter and close to the former can you get? (I can see how to get from the one permanent point of attachment to occasionally changing that, with transients, using Mobile IP.) -- Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability 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: Charles E. Perkins [mailto:charles.perkins@earthlink.net] Sent: 27 August 2010 04:27 To: Dearlove, Christopher (UK) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications *** 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. Hello Chris, I'm responding again, because I'd like to have a fruitful discussion. On 8/26/2010 7:21 AM, Dearlove, Christopher (UK) wrote: > This started from the specific example, so that is clearly quite > to the point. You may now be discussing other cases, but that's > another matter. Do you mean the specific example of your nodes running OLSR and identifying MPRs? I'm happy to agree that your nodes are routers. If I discussed other cases, it was only to reach the goal of identifying the boundary between hostness and routerness. Is that sufficiently to the point? > If by a node we mean a physically separate entity (in a > wireless network) and if we allow that node to be independently > mobile and to connect to other nodes (otherwise it's not really > an ad hoc node) and it is to be unicast reachable from elsewhere > in the network via one of those other nodes, then it has to be > running something. Obviously... it's running some computer programs. If a node runs ARP, is it a router? > It's for you to indicate what that something > is and why that isn't a routing protocol, despite having some > (agreed, not all) routing functions, and how it will work in a > MANET with wireless links (with the usual non-transitive > properties). I already mentioned several examples. Should I do it again? What about a node running ND? What about a node snooping the airwaves? What about a node running Mobile IP? I've just scratched the surface of examples. In fact I'll even play dirty and keep you in suspense to wait for a new Internet Draft I am co-authoring on this subject. > Otherwise you are asking me to prove a negative, and we know > how easy that is. I'm asking you to accept that a node can beneficially reside in an ad hoc network without being a router. What is negative about that? Unless I completely misunderstand your point of view, this is not in any way asking you to prove a negative. Of course it is possible to prove a negative proposition. But, I have not asked you to do so. Or, what negative proposition do you believe I have postulated for your consideration? If I put "not" in any point of discussion, have I exceeded my boundaries of feasible communication? Regards, Charlie P. ******************************************************************** 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 Aug 27 02:52: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 6635B3A67F0 for ; Fri, 27 Aug 2010 02:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 l0y814vLpxMA for ; Fri, 27 Aug 2010 02:52:56 -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 AAB783A6B9A for ; Fri, 27 Aug 2010 02:52:55 -0700 (PDT) Received: by eyd10 with SMTP id 10so2056533eyd.31 for ; Fri, 27 Aug 2010 02:53:26 -0700 (PDT) Received: by 10.213.22.10 with SMTP id l10mr715796ebb.21.1282902806837; Fri, 27 Aug 2010 02:53:26 -0700 (PDT) Received: from [192.168.2.169] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id v8sm5789371eeh.14.2010.08.27.02.53.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Aug 2010 02:53:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <7E56B44F-80A1-4A19-9498-0AACAFC5B4D9@inf-net.nl> Date: Fri, 27 Aug 2010 11:53:23 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <4C741EBB.8060909@earthlink.net> <4C75308C.1090506@earthlink.net> <4C767360.7050805@earthlink.net> <7E56B44F-80A1-4A19-9498-0AACAFC5B4D9@inf-net.nl> To: "Charles E. Perkins" X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org autoconf@ietf.org" , "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Aug 2010 09:52:57 -0000 Hi Charlie, More thoughts on the grey zone, separating host and routers. You stick to the basic definition: routers forward packets, hosts do not. OK? We had discussion on routing protocol speakers. I said: sending routing protocol packets makes a node a router. But for routing protocol speakers, that: - do not forward packets - do not send RAs - do not advertise any willingness to forward packets Would that be routers? If you say: no, these are hosts, I can follow. But for accepting such, it should be made clear to other nodes, that the routing protocol speaker is a host, not a router. Some mechanisms: - passive mode / don't send routing protocol packets at all - OLSR willingness = WILL_NEVER (0) - not advertise any links - advertise links, but with "do not use" attribute / metric - only put reachability for itself in AODV / DYMO messages - never send BGP reachability with own address as next_hop Using this classification, a BGP route server is a nice example for a host being an active routing protocol speaker. draft-jasinska-ix-bgp-route-server-00: | Although a route server uses BGP to exchange | reachability information with each of its clients, it does not | forward traffic itself and is therefore not a router. If we agree on such classification, there is some advertorial work to do. Because many would say (ad hoc) routing protocol speakers are routers. E.g. we need errata on RFC's from MANET WG and update the active drafts. Also, draft-ietf-autoconf-adhoc-addr-model-03 needs a revision. Change /router/node/, but not global change (not in section 6.1, last bullet). RFC5998 is waiting for approval by Mark. Mark? And using Router-ID's on hosts? Hmmm. Regards, Teco Op 26 aug 2010, om 20:17 heeft Teco Boot het volgende geschreven: > Charlie, > > Learning default gateways in a passive mode is well accepted behavior > of hosts. It is mentioned in RFC 1122: > | This technique depends upon the host passively > | receiving ("wiretapping") the Interior Gateway Protocol > | (IGP) datagrams that the gateways are broadcasting to > | each other. > > But signaling from hosts to routers is another story. We have NDP or > ARP for this. One could think of redistributing NDP / ARP learned routing > info into the routing protocol. I am not sure we should go there. > > Teco From charles.perkins@earthlink.net Fri Aug 27 04: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 E3FBF3A6782 for ; Fri, 27 Aug 2010 04:28:29 -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 rilX5ep7jqJ0 for ; Fri, 27 Aug 2010 04:28:29 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 00D893A681D for ; Fri, 27 Aug 2010 04:28:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Q23NjbpC9VdbVhdNXBHLUIGzwieoZ5oUSJxso6I2QL8uboC+GkkaymQk9v7Viabz; 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 [207.74.239.6] (helo=[10.150.0.248]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Oox7E-0003JJ-Li; Fri, 27 Aug 2010 07:29:01 -0400 Message-ID: <4C77A17A.1090708@earthlink.net> Date: Fri, 27 Aug 2010 04:28:58 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" References: <4C741EBB.8060909@earthlink.net> <4C75308C.1090506@earthlink.net> <4C767360.7050805@earthlink.net> <4C773080.8010601@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52e1e9829af188f5961ef01f0f1eaff11d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 207.74.239.6 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Aug 2010 11:28:30 -0000 Hello Chris, The examples I gave DO NOT provide the functionality in your message. That _is_ the point. The point is that a node can beneficially reside in an ad hoc network without doing those things. ... and that we should not legislate otherwise. Regards, Charlie P. On 8/27/2010 1:26 AM, Dearlove, Christopher (UK) wrote: > I'm failing to see how any of the examples you quote (which I > agree, would not make a node a router) are sufficient for all > of the functionality I noted. I really would like (but I'll > be unable to reply to for at least some days - it's a long > weekend coming up) to know how you get the functionality. > Ideally I'd like equivalent functionality to the OLSR example, > what I wouldn't count is where a host node is permanently > (albeit wirelessly) attached to a single other router node. > How far from the latter and close to the former can you get? > (I can see how to get from the one permanent point of > attachment to occasionally changing that, with transients, > using Mobile IP.) > From Chris.Dearlove@baesystems.com Fri Aug 27 05:26: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 26F3F3A67F3 for ; Fri, 27 Aug 2010 05:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.665 X-Spam-Level: X-Spam-Status: No, score=-6.665 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 Gt4WIXfwhjNm for ; Fri, 27 Aug 2010 05:26:58 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id C96DD3A67B2 for ; Fri, 27 Aug 2010 05:26:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,278,1280703600"; d="scan'208";a="84304338" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 27 Aug 2010 13:27: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 o7RCRScq008694; Fri, 27 Aug 2010 13:27:29 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Aug 2010 13:27:28 +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, 27 Aug 2010 13:27:28 +0100 Message-ID: In-Reply-To: <4C77A17A.1090708@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Closing summary on consensus-call for RFC5889modifications Thread-Index: ActF2w0KmKzQ4oHURXeSS5uQK4GZdQAB4mRg References: <4C741EBB.8060909@earthlink.net> <4C75308C.1090506@earthlink.net> <4C767360.7050805@earthlink.net> <4C773080.8010601@earthlink.net> <4C77A17A.1090708@earthlink.net> From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" X-OriginalArrivalTime: 27 Aug 2010 12:27:28.0833 (UTC) FILETIME=[36BB5310:01CB45E3] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Aug 2010 12:26:59 -0000 There's a key question as to how much functionality. If a node just has a single point of attachment to an unchanging router, then router prefix autoconf is sufficient, as the host node can just get an address from its router. If we extend that so that it can now move, and use Mobile IP with its home location being the router it first attached to, ditto. The question is what is the case where the host node is doing something useful, but can't just get an address delegated to it by an autoconfed router? (I am not saying I don't think there is such a case. I'm just saying I haven't seen it - quite a different thing.) -- Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability 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: Charles E. Perkins [mailto:charles.perkins@earthlink.net] Sent: 27 August 2010 12:29 To: Dearlove, Christopher (UK) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications *** 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. Hello Chris, The examples I gave DO NOT provide the functionality in your message. That _is_ the point. The point is that a node can beneficially reside in an ad hoc network without doing those things. ... and that we should not legislate otherwise. Regards, Charlie P. On 8/27/2010 1:26 AM, Dearlove, Christopher (UK) wrote: > I'm failing to see how any of the examples you quote (which I > agree, would not make a node a router) are sufficient for all > of the functionality I noted. I really would like (but I'll > be unable to reply to for at least some days - it's a long > weekend coming up) to know how you get the functionality. > Ideally I'd like equivalent functionality to the OLSR example, > what I wouldn't count is where a host node is permanently > (albeit wirelessly) attached to a single other router node. > How far from the latter and close to the former can you get? > (I can see how to get from the one permanent point of > attachment to occasionally changing that, with transients, > using Mobile IP.) > ******************************************************************** 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 charles.perkins@earthlink.net Fri Aug 27 11:41: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 F21493A6A47 for ; Fri, 27 Aug 2010 11:41:18 -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 Du5-Ah3EDxRS for ; Fri, 27 Aug 2010 11:41:18 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id DAE283A69E9 for ; Fri, 27 Aug 2010 11:41:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=uCYtUvWCwMa1s6rbqJ9n86mufbdFFjxn4g1+Wqo7WaWfKrG4eJxkbgnKbEKDk8Jf; 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 [207.74.239.6] (helo=[10.150.0.248]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Op3s5-0007CY-O4; Fri, 27 Aug 2010 14:41:49 -0400 Message-ID: <4C7806EC.6000607@earthlink.net> Date: Fri, 27 Aug 2010 11:41:48 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" References: <4C741EBB.8060909@earthlink.net> <4C75308C.1090506@earthlink.net> <4C767360.7050805@earthlink.net> <4C773080.8010601@earthlink.net> <4C77A17A.1090708@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52ad4c17d28a2777d3424f8f076e1a37ee350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 207.74.239.6 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 27 Aug 2010 18:41:19 -0000 Hello Chris, On 8/27/2010 5:27 AM, Dearlove, Christopher (UK) wrote: > There's a key question as to how much functionality. This is an important point. The functionality needed by a host in order to connect to network depends on the functionality provided by the router that offers the netwok prefix. > If a node just has a single point of attachment to an unchanging > router, then router prefix autoconf is sufficient, as the host > node can just get an address from its router. If we extend that > so that it can now move, and use Mobile IP with its home location > being the router it first attached to, ditto. Check. > The question is what is the case where the host node is doing > something useful, but can't just get an address delegated to > it by an autoconfed router? > > (I am not saying I don't think there is such a case. I'm just > saying I haven't seen it - quite a different thing.) Well, there are such cases, and they should be allowed. Regards, Charlie P. From charles.perkins@earthlink.net Fri Aug 27 20:34: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 A1DF33A677E for ; Fri, 27 Aug 2010 20:34: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=[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 v5ql21sdWi1k for ; Fri, 27 Aug 2010 20:34:12 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 639493A677D for ; Fri, 27 Aug 2010 20:34:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=TvJI56n+YfGSpKjxZ6BoApHNJjFzrpyh0UIhZi5WzyoX3B5pah4pPvn6TBGXPoOa; 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 [207.74.239.6] (helo=[10.150.0.248]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OpCBm-0004oO-Os; Fri, 27 Aug 2010 23:34:43 -0400 Message-ID: <4C7883D0.20101@earthlink.net> Date: Fri, 27 Aug 2010 20:34:40 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Teco Boot References: <4C741EBB.8060909@earthlink.net> <4C75308C.1090506@earthlink.net> <4C767360.7050805@earthlink.net> <7E56B44F-80A1-4A19-9498-0AACAFC5B4D9@inf-net.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5235089839e53c07fdbfc664ef1bea6d39350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 207.74.239.6 Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 28 Aug 2010 03:34:13 -0000 Hello Teco, On 8/27/2010 2:53 AM, Teco Boot wrote: > Hi Charlie, > > More thoughts on the grey zone, separating host and routers. > You stick to the basic definition: routers forward packets, hosts do not. > OK? > > We had discussion on routing protocol speakers. I said: sending routing > protocol packets makes a node a router. > > But for routing protocol speakers, that: > - do not forward packets > - do not send RAs > - do not advertise any willingness to forward packets > Would that be routers? > > If you say: no, these are hosts, I can follow. These are hosts. Check. > But for accepting such, it should be made clear to other nodes, that > the routing protocol speaker is a host, not a router. Now you lost me. Why must such a host need to be mentioned to other nodes? If it were mentioned (e.g., by a proactive routing protocol) why would it have to be identified as a non-routing host? > Some mechanisms: > - passive mode / don't send routing protocol packets at all > - OLSR willingness = WILL_NEVER (0) > - not advertise any links > - advertise links, but with "do not use" attribute / metric > - only put reachability for itself in AODV / DYMO messages > - never send BGP reachability with own address as next_hop What mechanisms are these? Host mechanisms? How is "not advertising" a "mechanism" (for example)? > Using this classification, a BGP route server is a nice example for a > host being an active routing protocol speaker. The host is a router server, not a router. > draft-jasinska-ix-bgp-route-server-00: > | Although a route server uses BGP to exchange > | reachability information with each of its clients, it does not > | forward traffic itself and is therefore not a router. > > If we agree on such classification, there is some advertorial work to do. > Because many would say (ad hoc) routing protocol speakers are routers. Yes, people are saying this. I don't agree. It sounds to me like a way to wind up toy angels and get them to dance on the head of a pin, so to speak. > E.g. we need errata on RFC's from MANET WG and update the active drafts. I'd have to check on this. Regards, Charlie P. From alexandru.petrescu@gmail.com Sat Aug 28 06:51:39 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 D9FD83A688B for ; Sat, 28 Aug 2010 06:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[AWL=-0.672, 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 NFPJ76DlpO5D for ; Sat, 28 Aug 2010 06:51:39 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 01E6D3A6862 for ; Sat, 28 Aug 2010 06:51:37 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 9ECB4940011 for ; Sat, 28 Aug 2010 15:52:04 +0200 (CEST) Message-ID: <4C79147F.5050005@gmail.com> Date: Sat, 28 Aug 2010 15:51:59 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 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 100827-1, 27/08/2010), Outbound message X-Antivirus-Status: Clean Subject: [Autoconf] Could an AUTOCONF Router fail the Internet? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 28 Aug 2010 13:51:40 -0000 Could an AUTOCONF Router fail the Internet? How? If yes, then it'd be good to have a requirement in the Charter to avoid that situation. Such could be to _localize_ the AUTOCONF mechanism to an "end-system", more of a Host, or a hosty Node, rather than a Router. Or, the term "Router" is used throughout in the Charter. Typically Router means an entity whose failure would fail the Internet altogether. Charter text deadline - August 30th, 2010. Alex From alexandru.petrescu@gmail.com Sat Aug 28 06:53: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 3A9E43A68E9 for ; Sat, 28 Aug 2010 06:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.105 X-Spam-Level: X-Spam-Status: No, score=-0.105 tagged_above=-999 required=5 tests=[AWL=-0.870, BAYES_40=-0.185, HELO_EQ_FR=0.35, J_CHICKENPOX_82=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 x4PtGH9962HU for ; Sat, 28 Aug 2010 06:53:12 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 13A0A3A6862 for ; Sat, 28 Aug 2010 06:53:10 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 21D91940140 for ; Sat, 28 Aug 2010 15:53:37 +0200 (CEST) Message-ID: <4C7914DC.4030808@gmail.com> Date: Sat, 28 Aug 2010 15:53:32 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 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 100827-1, 27/08/2010), Outbound message X-Antivirus-Status: Clean Subject: [Autoconf] Current issue about proposed Charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 28 Aug 2010 13:53:13 -0000 Could we clarify the Charter, such that (1) it does talk Hosts not only Routers, end-systems, and (2) work does follow a requirement where the failure of the future AUTOCONF mechanisms would _not_ imply failure of the Internet. AUTOCONF Charter is being discussed - deadline August 30th, 2010. Charter. This is more important. It explicitely says that the two mechanisms to be designed in AUTOCONF are for Routers, doesn't say Hosts at all. There is one important issue with it: Hosts are the ones needing most to be autoconfigured, and less Routers. The issue is hard to understand knowing the difficulty to distinguish Hosts from Routers by simply listing their functionalities (routing table, number of interfaces, forwarding, send rt protocol messages). By many RFCs Most Routers often act as Hosts, and vice-versa! However, there is one simple picture to understand easily: that of End-systems facing the core network Internet plumbing Routers (private discussion). It is a very good design principle to keep the core network running despite the failure of the end-systems. Failure of AUTOCONF to correctly configure the end-system must not imply a failure of the core network. That's a good requirement to set on end-systems AUTOCONF. But it should mean that we configure the end-systems, not only the core routers. If we say that AUTOCONF does only Routers (core network) then we have no requirement on the behaviour of end-systems, thus no design principle to respect - it is bad. Finally, the distinction Router - Core Router is further blurred in MANET: MANET Routers are little devices moving around, whose failure has no influence on the Internet - actually disconnected from it. A NEMO Mobile Router is the same little device, connected to Internet but doing tunnelling and, although I'd like it AUTOCONF'ed, its failure would surely not imply route churn in the Internet thanks to that tunnelling. At this point one would like to idenfity what is the word "router" in the current Charter: is it an entity that _could_ break the Internet? Is it an "end system"? Mobile IP and ND talk "Nodes" ("a Host or a Router"). DHCP uses "DHCP Client" vs "DHCP Server". Do we mean more of "DHCP Client" rather than "DHCP Server"? IPsec uses Host, Router and Firewall. RFC0995 (authored by ISO) and SIP talk "End System", "Network" and "Intermediate System". If we clarify the Charter proposal, then the rfc5889 title (uses "Router") could be clarify accordingly, I believe. Alex From teco@inf-net.nl Mon Aug 30 23:43: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 363913A6909 for ; Mon, 30 Aug 2010 23:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 4RLl1GRQUxCU for ; Mon, 30 Aug 2010 23:43:26 -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 85F413A68AD for ; Mon, 30 Aug 2010 23:43:26 -0700 (PDT) Received: by ewy22 with SMTP id 22so3874091ewy.31 for ; Mon, 30 Aug 2010 23:43:56 -0700 (PDT) Received: by 10.213.22.6 with SMTP id l6mr132110ebb.38.1283237036792; Mon, 30 Aug 2010 23:43:56 -0700 (PDT) Received: from [10.128.0.195] ([77.61.241.196]) by mx.google.com with ESMTPS id u9sm13511246eeh.23.2010.08.30.23.43.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Aug 2010 23:43:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4C7883D0.20101@earthlink.net> Date: Tue, 31 Aug 2010 08:43:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <45722A95-9DC3-4C30-AB59-E6CD4631B906@inf-net.nl> References: <4C741EBB.8060909@earthlink.net> <4C75308C.1090506@earthlink.net> <4C767360.7050805@earthlink.net> <7E56B44F-80A1-4A19-9498-0AACAFC5B4D9@inf-net.nl> <4C7883D0.20101@earthlink.net> To: "Charles E. Perkins" X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Aug 2010 06:43:30 -0000 Hi Charlie, Op 28 aug 2010, om 05:34 heeft Charles E. Perkins het volgende = geschreven: >=20 > Hello Teco, >=20 > On 8/27/2010 2:53 AM, Teco Boot wrote: >> Hi Charlie, >>=20 >> More thoughts on the grey zone, separating host and routers. >> You stick to the basic definition: routers forward packets, hosts do = not. >> OK? >>=20 >> We had discussion on routing protocol speakers. I said: sending = routing >> protocol packets makes a node a router. >>=20 >> But for routing protocol speakers, that: >> - do not forward packets >> - do not send RAs >> - do not advertise any willingness to forward packets >> Would that be routers? >>=20 >> If you say: no, these are hosts, I can follow. >=20 > These are hosts. Check. >=20 >> But for accepting such, it should be made clear to other nodes, that >> the routing protocol speaker is a host, not a router. >=20 > Now you lost me. Why must such a host need to be mentioned > to other nodes? If it were mentioned (e.g., by a proactive > routing protocol) why would it have to be identified as a > non-routing host? If other nodes are not aware of this_node, they don't send packets to = it. If other nodes are not aware this_node does not forward packets, it = could be a black hole. This_node MUST NOT be the next hop for other = destinations. >> Some mechanisms: >> - passive mode / don't send routing protocol packets at all >> - OLSR willingness =3D WILL_NEVER (0) >> - not advertise any links >> - advertise links, but with "do not use" attribute / metric >> - only put reachability for itself in AODV / DYMO messages >> - never send BGP reachability with own address as next_hop >=20 > What mechanisms are these? Host mechanisms? These are mechanisms for making sure other nodes are aware this_node does not forward packets to other destinations. I am not sure how this may work for NHDP (in OLSR, appendix B.7.). > How is "not advertising" a "mechanism" (for example)? Example: in OSPF terms: not sending LSA. >> Using this classification, a BGP route server is a nice example for a >> host being an active routing protocol speaker. >=20 > The host is a router server, not a router. A host is not a router. I don't get your message.=20 >> draft-jasinska-ix-bgp-route-server-00: >> | Although a route server uses BGP to exchange >> | reachability information with each of its clients, it does not >> | forward traffic itself and is therefore not a router. >>=20 >> If we agree on such classification, there is some advertorial work to = do. >> Because many would say (ad hoc) routing protocol speakers are = routers. >=20 > Yes, people are saying this. I don't agree. My point is, if you do not agree, you could be more responsive to WGLCs = on this. Take for example the RFC5889-draft and the new charter. These are full = of term=20 "router", which if you were consistent, you would strongly disagree on. > It sounds to me like a way to wind up toy angels and > get them to dance on the head of a pin, so to speak. >=20 >> E.g. we need errata on RFC's from MANET WG and update the active = drafts. >=20 > I'd have to check on this. You better do. Charlie, I can support the idea MANET routing protools may run on hosts. But for this discussion, can we be somewhat to the point? It may help. And be less time consuming. Regards, Teco >=20 > Regards, > Charlie P. From Chris.Dearlove@baesystems.com Tue Aug 31 01: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 39B193A6783 for ; Tue, 31 Aug 2010 01:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.364 X-Spam-Level: X-Spam-Status: No, score=-5.364 tagged_above=-999 required=5 tests=[AWL=-1.365, 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 JB3Eb-aj0VMr for ; Tue, 31 Aug 2010 01:40:12 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 088643A67E4 for ; Tue, 31 Aug 2010 01:40:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,297,1280703600"; d="scan'208";a="84617104" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 31 Aug 2010 09:40:42 +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 o7V8ef4I026564; Tue, 31 Aug 2010 09:40:41 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Aug 2010 09:40:41 +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: Tue, 31 Aug 2010 09:40:04 +0100 Message-ID: In-Reply-To: <4C7806EC.6000607@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Closing summary on consensus-call for RFC5889modifications Thread-Index: ActGF4OVrSsKmK3fShO+yRM2i/vH0gC0EKtA References: <4C741EBB.8060909@earthlink.net> <4C75308C.1090506@earthlink.net> <4C767360.7050805@earthlink.net> <4C773080.8010601@earthlink.net> <4C77A17A.1090708@earthlink.net> <4C7806EC.6000607@earthlink.net> From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" X-OriginalArrivalTime: 31 Aug 2010 08:40:41.0297 (UTC) FILETIME=[31A91C10:01CB48E8] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Aug 2010 08:40:13 -0000 Can you outline such a case. It's not the simple use of Mobile IP noted below as for that router prefix autoconfiguration is sufficient. -- Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability 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: Charles E. Perkins [mailto:charles.perkins@earthlink.net] Sent: 27 August 2010 19:42 To: Dearlove, Christopher (UK) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications *** 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. Hello Chris, On 8/27/2010 5:27 AM, Dearlove, Christopher (UK) wrote: > There's a key question as to how much functionality. This is an important point. The functionality needed by a host in order to connect to network depends on the functionality provided by the router that offers the netwok prefix. > If a node just has a single point of attachment to an unchanging > router, then router prefix autoconf is sufficient, as the host > node can just get an address from its router. If we extend that > so that it can now move, and use Mobile IP with its home location > being the router it first attached to, ditto. Check. > The question is what is the case where the host node is doing > something useful, but can't just get an address delegated to > it by an autoconfed router? > > (I am not saying I don't think there is such a case. I'm just > saying I haven't seen it - quite a different thing.) Well, there are such cases, and they should be allowed. Regards, Charlie P. ******************************************************************** 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. ********************************************************************