From ryuji.wakikawa@gmail.com Mon Aug 10 11:35:54 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62183A68B9 for ; Mon, 10 Aug 2009 11:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMunAquDcCDK for ; Mon, 10 Aug 2009 11:35:54 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 0442A3A67EF for ; Mon, 10 Aug 2009 11:35:53 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id f9so878038rvb.49 for ; Mon, 10 Aug 2009 11:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date:cc :x-mailer; bh=DP6taA5RCGw7pKcx7mGea8F+8qu1Y8bqy6O7cCzfzco=; b=IKtOnmDrLZVzaMqzZ8stysLfTge8bDlD8OarO1ChAwcUzK3SIr342MdthN/yDzTJ/i FSm3iMg5YShMxxvllTXM07C6ndNwShTSqCilgX+GL2esovVvB+LQmI2Cm+MjVOajHrh0 7D1pxkQF2i14kmJWme0Z6ca7bm/au7AAGnGng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:cc:x-mailer; b=xCPNJeuw4hzcRztDV8hdLg/qGxJLWGKJrzXDRAFOPbAis0t6zhHNqWHwx4EAxqPne7 wRScW5h60YNcYM0SODpyw3Pf+vZzz0iVb1gPEBpYlCxHGRCnqiQNEgOPl8pRcApwkInO Pd2xgWIYk1PHkZ4XEGIzeNHGOBzv947tys/HQ= Received: by 10.140.187.10 with SMTP id k10mr1796497rvf.23.1249929355557; Mon, 10 Aug 2009 11:35:55 -0700 (PDT) Received: from macbookpro-ryuji.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id g14sm26487585rvb.10.2009.08.10.11.35.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Aug 2009 11:35:53 -0700 (PDT) Message-Id: <4A5B37EB-1A59-4B48-851D-C661FDA4436D@gmail.com> From: Ryuji Wakikawa To: autoconf@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 10 Aug 2009 11:35:45 -0700 X-Mailer: Apple Mail (2.936) Cc: Thomas Clausen Subject: [Autoconf] minutes from IETF75 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 10 Aug 2009 18:35:54 -0000 Hi all, Thanks for Chris and Ronald for taking minutes! The minutes is now available at the following link. http://www.ietf.org/proceedings/75/minutes/autoconf.txt We will issue the consensus call for the link-local address issue on the ML soon. thanks Thomas & ryuji From Chris.Dearlove@baesystems.com Tue Aug 11 01:11:51 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43FC73A6FA4 for ; Tue, 11 Aug 2009 01:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 XojR9iF5-dge for ; Tue, 11 Aug 2009 01:11:50 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 26A2E3A6F7E for ; Tue, 11 Aug 2009 01:11:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,359,1246834800"; d="scan'208";a="16598715" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 11 Aug 2009 09:11:47 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n7B8BlUN022913; Tue, 11 Aug 2009 09:11:47 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Aug 2009 09:11:46 +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, 11 Aug 2009 09:11:44 +0100 Message-ID: In-Reply-To: <4A5B37EB-1A59-4B48-851D-C661FDA4436D@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] minutes from IETF75 thread-index: AcoZ6XG7/IvsZW2FRJqdOhn2k84G3AAcZZkg References: <4A5B37EB-1A59-4B48-851D-C661FDA4436D@gmail.com> From: "Dearlove, Christopher (UK)" To: "Ryuji Wakikawa" , X-OriginalArrivalTime: 11 Aug 2009 08:11:46.0504 (UTC) FILETIME=[5E9AF480:01CA1A5B] Cc: Thomas Clausen Subject: Re: [Autoconf] minutes from IETF75 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Aug 2009 08:11:51 -0000 I had intended the chairs to take some action on my [] comments which are meant to be notes to touch up the minutes, possibly based on Ronald's notes and/or Jabber logs, rather than being comments to leave in the final minutes. -- 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: 10 August 2009 19:36 To: autoconf@ietf.org Cc: Thomas Clausen Subject: [Autoconf] minutes from IETF75 *** 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 all, Thanks for Chris and Ronald for taking minutes! The minutes is now available at the following link. http://www.ietf.org/proceedings/75/minutes/autoconf.txt We will issue the consensus call for the link-local address issue on the ML soon. thanks Thomas & ryuji _______________________________________________ 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 thomas@thomasclausen.org Tue Aug 11 05:42:56 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C24613A7124 for ; Tue, 11 Aug 2009 05:42:55 -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 pXJ8gmLv1Toq for ; Tue, 11 Aug 2009 05:42:54 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id D268C3A6F65 for ; Tue, 11 Aug 2009 05:42:54 -0700 (PDT) Received: from aste-genev-bois-153-1-18-123.w83-112.abo.wanadoo.fr ([83.112.198.123] helo=new-host-19.SME) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Maqfj-0003WE-K5; Tue, 11 Aug 2009 12:41:48 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.198.123 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18V6X7sQ6mp559Mt4qou5y6 Message-Id: <5B5F4E84-B5F2-4532-956E-F1AFC79AE70C@thomasclausen.org> From: Thomas Heide Clausen To: Christopher Dearlove In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 11 Aug 2009 14:41:44 +0200 References: <4A5B37EB-1A59-4B48-851D-C661FDA4436D@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] minutes from IETF75 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Aug 2009 12:42:57 -0000 Darn, I thought I'd actually caught them and expanded upon them. Goes to show...... Thanks for being vigilant, we'll fill in as best we can. Thomas On Aug 11, 2009, at 10:11 AM, Dearlove, Christopher (UK) wrote: > I had intended the chairs to take some action on my [] > comments which are meant to be notes to touch up the > minutes, possibly based on Ronald's notes and/or Jabber > logs, rather than being comments to leave in the > final minutes. > > -- > 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: 10 August 2009 19:36 > To: autoconf@ietf.org > Cc: Thomas Clausen > Subject: [Autoconf] minutes from IETF75 > > > *** 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 all, > > Thanks for Chris and Ronald for taking minutes! > The minutes is now available at the following link. > http://www.ietf.org/proceedings/75/minutes/autoconf.txt > > We will issue the consensus call for the link-local address issue on > the ML soon. > > thanks > Thomas & ryuji > > _______________________________________________ > 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. > ******************************************************************** > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From ryuji.wakikawa@gmail.com Mon Aug 31 02:59:50 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3062C3A6B12 for ; Mon, 31 Aug 2009 02:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 7yJrMKiWmejf for ; Mon, 31 Aug 2009 02:59:49 -0700 (PDT) Received: from mail-px0-f181.google.com (mail-px0-f181.google.com [209.85.216.181]) by core3.amsl.com (Postfix) with ESMTP id 554493A6DC0 for ; Mon, 31 Aug 2009 02:59:49 -0700 (PDT) Received: by pxi11 with SMTP id 11so8967pxi.17 for ; Mon, 31 Aug 2009 02:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=VVeHD/D2TyP08BhrONUxXoDo51zgM4e+UxiK/raFY2s=; b=W4MPDiY9ZJP+wGxjbxyoLWcPrtiI8iIqYg9QvwxX3wk7Y6xoBEM3XH1ih1N2Bs1LZN 8BthiyHvup+T7lwZKWjR6l+6Nxb02yY2L2nA/4a8i20S22iv9r3kRU7q+mze/pgJyGdP zJwfciA2AEUBFGzssSwtoR+khr84mRHkO8QjE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=VKFVYFkyzqEyWtKWmoOlidC3Y4664j0jkI/RHujD8s8aM8KrUbXhQ19rTxCkcqYKdS 6RORHtq5rAOlJv85RtnMA935lCu7YjoYKZ5pq4Opbr1CkleZTsWdonsnygFqDojWE02k fKvt4tsb2cgErFAUp7iF73E2DXaRXJdL0yV1E= Received: by 10.114.2.19 with SMTP id 19mr2400307wab.26.1251712795385; Mon, 31 Aug 2009 02:59:55 -0700 (PDT) Received: from ?10.0.0.30? (pc2.ghkyoto3-unet.ocn.ne.jp [219.166.9.154]) by mx.google.com with ESMTPS id n30sm4011027wag.41.2009.08.31.02.59.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 31 Aug 2009 02:59:54 -0700 (PDT) Message-Id: From: Ryuji Wakikawa To: autoconf@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 31 Aug 2009 18:59:35 +0900 X-Mailer: Apple Mail (2.936) Subject: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Aug 2009 09:59:50 -0000 Hi all, This is consensus call about the link-local address support in MANET. Please review the following call for consensus and vote your opinion by Sep10th. DT will update the document according to our consensus. thanks, Thomas & ryuji ------------------------------------------------------------------ CALL FOR CONSENSUS Deadline: 2009-09-10 6:00PM PST. Target ID: Design Team Document "IP Addressing Model in Ad Hoc Networks" http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model-01 Issue (cited from the above draft): - Use of Link Local Addresses - while the use of link local addresses on interfaces connecting to a MANET link is not prohibited, the semantics of "link local" in this context is yet to be defined, taking into account the unusual requirements that follow, concerning such addresses. These requirements include for example uniqueness within a scope spanning beyond a single IP hop. Some discussions can be found at the IETF75 AUTOCONF minutes http://www.ietf.org/proceedings/75/minutes/autoconf.txt Please vote your preference between the following two alternatives. If you have another alternative, please propose it and give your reasons why you prefer that alternative. a) The document shall support link-local addresses as required for nodes in a MANET in addition to unique-local and global addresses. b) Support unique-local and global addresses as required for MANET nodes. The document shall not prohibit using link-local addresses, but shall describe the difficulties inhibiting compliance in MANET with the standardized IPv6 properties that characterize the use of link-local addresses. ------------------------------------------------------------------ From Matthew.Anderson@us.elster.com Mon Aug 31 12:05:59 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970C628C4E6 for ; Mon, 31 Aug 2009 12:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.125 X-Spam-Level: X-Spam-Status: No, score=-5.125 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IktQoIvQKdiy for ; Mon, 31 Aug 2009 12:05:58 -0700 (PDT) Received: from mail54.messagelabs.com (mail54.messagelabs.com [216.82.241.131]) by core3.amsl.com (Postfix) with SMTP id 94C0B28C4C7 for ; Mon, 31 Aug 2009 12:05:58 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Matthew.Anderson@us.elster.com X-Msg-Ref: server-4.tower-54.messagelabs.com!1251745564!46214717!2 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 24127 invoked from network); 31 Aug 2009 19:06:05 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-4.tower-54.messagelabs.com with SMTP; 31 Aug 2009 19:06:05 -0000 Auto-Submitted: auto-generated From: Matthew.Anderson@us.elster.com To: autoconf@ietf.org Message-ID: Date: Mon, 31 Aug 2009 15:06:22 -0400 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5FP1|June 15, 2009) at 08/31/2009 03:04:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Autoconf] AUTO: Matthew Anderson is out of the office (returning 09/01/2009) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Aug 2009 19:05:59 -0000 I am out of the office until 09/01/2009. Please contact Jeff McCullough or Gerald Paprocki with any urgent issues. Note: This is an automated response to your message "Autoconf Digest, Vol 41, Issue 3" sent on 8/31/2009 3:00:04 PM. This is the only notification you will receive while this person is away. From ryuji.wakikawa@gmail.com Mon Aug 31 19:38:59 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 632A13A6E95 for ; Mon, 31 Aug 2009 19:38:59 -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 5pI0qI0daoL2 for ; Mon, 31 Aug 2009 19:38:56 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id B9A0C3A6A84 for ; Mon, 31 Aug 2009 19:38:56 -0700 (PDT) Received: by pzk38 with SMTP id 38so4469178pzk.5 for ; Mon, 31 Aug 2009 19:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=uNC8txVxL5bTUbiqd4rdTrrc8iONoLZVpH6GCVrxmRI=; b=JG0Y2Q8yIsnE4ep2/pL0XMIGKhr2ud2S+AD7ThOT3Kygzvt3cFfMTEcX+b2jfm3Cl6 wY8mQKwHDTia7GihEjCI/VqH5KGgnEHpBVG46ypQKaEY2vBe66mNBKZ9HK9kInsT0PHK z7aZ3l09/by/ExIIlakA5K7B3guvDkDlRds9M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=uCxx0BId3CwSpTF8wAOV7k2xnZDzm5prKMtJbsd4TBcd9W9ljDZEI7vsdDw5J1SS8q ggo7GMlf+kQNL7NuJM9amIEZZU8mCqwPQIaCX4464lwbH5fwtb7Hb2AzgtaCP+LGWSIJ viabffxedU3KlLirN/hP9MWFdGBydplpEpN3c= Received: by 10.140.187.11 with SMTP id k11mr1339793rvf.197.1251772262580; Mon, 31 Aug 2009 19:31:02 -0700 (PDT) Received: from ?192.168.25.206? (p3003-ipbfpfx02kyoto.kyoto.ocn.ne.jp [125.207.177.35]) by mx.google.com with ESMTPS id 22sm1397800pzk.10.2009.08.31.19.30.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 31 Aug 2009 19:31:01 -0700 (PDT) Message-Id: <61DF76BD-1C87-4D6F-A36B-9DC1DD89E558@gmail.com> From: Ryuji Wakikawa To: autoconf@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 1 Sep 2009 11:30:56 +0900 X-Mailer: Apple Mail (2.936) Subject: [Autoconf] Updated IETF 75 meeting minutes X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Sep 2009 02:38:59 -0000 Hi We revised the meeting minutes and updated it, however the proceeding of IETF75 has been already fixed. I attach the minutes updated by Ronald. You will find the detailed discussion of the link-local address support in the minutes. Thanks Ronald for your help. ryuji =========================================================== Working Group: Autoconf Date & Time: Monday 27th July 2009 15:20 to 16:50 Chairs: T.H. Clausen & R. Wakikawa Minute-taker: Christopher Dearlove (with additions by Ronald in 't Velt) Jabber-scribe: Thomas Clausen / Ulrich Herberg =========================================================== [Note: In the text below, DT stands for Design Team, not for Dave Thaler :-)] Ryuji Wakikawa: proposed agenda - Short update on WG status - Update from Design Team (main agenda item) - Short discussion on next steps No changes to the agenda brought forward Working group Status and Update (R.Wakikawa): Slides: http://www.ietf.org/proceedings/75/slides/autoconf-0.pdf DT planned -00 draft in April and WGLC July, actually -00 draft July, and still as individual submission. (draft-baccelli-autoconf-adhoc-addr-model-01) This meeting, principal agenda item is discussing this draft. Running slightly late w.r.t. charter. WG is supposed to finish this work by September. DT Presentation (Emmanuel Baccelli) I-D: draft-baccelli-autoconf-adhoc-addr-model-01 Slides: http://www.ietf.org/proceedings/75/slides/autoconf-1.pdf Two main topics covered by DT draft: 1 - What is an IP Subnet in a MANET? 2 - IP address configuration - Link level connectivity not stable, subnet reduced to single interface and address. - Recommended solution configure /32 or /128. - Addresses unique in routing domain (required by some routing protocols), - Addresses may need to be globally unique. - Configured addresses unique within routing domain. - Open questions + Configuration of additional addresses. + What is the "MANET Link Model". + Can we use Link Local addresses. + Do the addresses have to be globally unique. Discussion Dave Thaler - Consistency with RFC 4291 (in particular section 2.5.1). - Do you believe you have 64-bit interface identifiers that are unique within the subnet prefix? (the 64-bit part being a requirement for all unicast addresses that do not begin with binary '000'). - If the answer to previous question is 'no', do you require prefixes to start with binary '000'? - If that is not the case either, shouldn't the document say that the addressing model will not be compliant with RFC4291? Emmanuel Baccelli - Document does not specify which address ranges to use. Thomas Narten (on Jabber) - There is no reason why Autoconf should not use EUI-64-based interface identifiers. Dave Thaler - If you believe that you ARE compliant with RFC4291, the way to phrase it is, that you have a /64 subnet prefix, but it is only assigned to a single host. Mark Townsley - Aim to be consistent with RFCs. - Beyond scope of document, may need to go that far. Ralph Droms - Document uses same wording for IPv4 and IPv6: "subnet prefix configured on interface"; this is really IPv4 terminology, in IPv6 you have a list of prefixes and an indication of whether those prefixes are on-link or off-link. - Careful wording, to the effect that no prefixes are on-link, can solve the IPv6 case. - For the purposes of this document, adopt similar wording for the IPv4 case, even though this kind of formalism is not commonly used for IPv4. - Distinguish subnet and prefix. Fred Templin - Do we need an address other than link local on an interface? Propose obtaining an address and putting it on a virtual interfaces and have only link-locals on the MANET interfaces. Then we have what RFC1122 refers to as link layer multiplexing. This works for single physical interface as well as multiple physical interfaces attached to to same MANET. For IPv4, you can use link-locals per RFC3927 on the physical interfaces. - Will write this up on the Autoconf ML. Emmanuel Baccelli - Have read Fred's VET document, but deep architectural considerations were not the goal of DT document. Rather, provide a simple model for address configuration. Fred Templin - If DT document says use /32's and /128's, I may not want to do that on my MANETs. Might not fit all cases. - Can you have multiple interfaces on a router attached to the same MANET? Thomas Narten (Jabber) - What Fred Templin describes is what I thought the Autoconf model was for normal addresses. They are either on a virtual interface or on a separate real interface, like an Ethernet. Addresses on the MANET interface are only for making the MANET work. Mark Townsley - Right now just talking about addresses that make the MANET work. Should say this more clearly in the document. Fred Templin - Agree multiplexing does not need to be in this document, since it is already in RFC1122. Mark Townsley - As a general principle: Because you can do something doesn't mean you have to do it. More choices fixed, the easier the job is for the solution that AUTOCONF is to deliver in the end. Fred Templin - As long as you don't stipulate that I have to put a /32 or /128 global address on the MANET interface. Multiple ways to run a MANET. Mark Townsley - But there should be only one for autoconfiguration, lest one would end up with a very chattery protocol in order to try to figure our (for a new router) "which of the multiple ways is deployed in this network now?". Fred Templin - If there is only to be one way, prefers his approach. - Proposed /32 on VET interface. Has it been discussed by DT? Teco Boot - First simple case, MANET router with single interface. With multiple interfaces more complicated. Optimizations later, maybe in a separate document. Fred Templin - Disagrees his approach is complex. Thomas Clausen - There are some characteristics needed to make routing protocols work. There are several ways to satisfy this. Identify what are the requirements. Document does this. Agree with Mark Townsley that need to decide what to do. Applications should see things as normal, i.e. only a/the routing protocols should be even aware of the existence of a MANET. Henning Rogge - Don't think it's good idea to put multiple interfaces on one side as solution for single interface may not work for multiple interfaces, which are common. Not clear that link local addresses for interfaces can solve all problems. Emmanuel Baccelli - Much discussion within the DT on the use of link locals. No conclusion reached yet. Thomas Narten (Jabber) - Keeping all issues open will mean that WG will get nowhere. Choosing a baseline does not exclude other possibilities. Jari Arkko (on Jabber) - Yes, need one model. Think of it as an example. We don't outlaw other ways, but cannot cover all possibilities with a single model. Ralph Droms - Problem with link-local addresses is, that they are *assumed* to be on-link. - What about ULA? Or a reserved centrally-assigned ULA prefix that can be uniformly not marked as "on-link". Erik Nordmark - Two things to decide up front: 1. IF link local addresses are used, what would their semantics be? To me it seems that they should only be sent on the actual link. MANET routers should not forward them. Other people might have different opinions. Thomas Clausen - Isn't it defined that you should never forward LL's? Erik Nordmark - Unless back onto the same link. You could try to finesse that in the MANET space, but let's not do that. - 2. What are the addresses that you actually auto-configure? I think those are essentially non-link-local addresses, whether ULAs for IPv6 or anything else. We still have the issue of physical versus virtual interfaces. It would be good if an autoconf protocol were designed to cater for both. Thomas Clausen - Doesn't that depend on your assumptions with respect to the virtual interface? What the virtual interface will be used for, e.g. to bind applications to it? Erik Nordmark - Two different cases. The first one is like a loopback interface on a router; it only needs a single address. The other one is the interface behind you which has a full subnet prefix. That's actually not a virtual interface, but the question is whether the autoconf protocol can also be used to configure the prefix on that interface or whether you need a different mechanism for that. Emmanuel Baccelli - Interesting question, but beyond the scope of the DT document, which concentrates on what's needed to make the routing protocols work. Erik Nordmark - Intended as directions for the WG. People do want to do things differently, but we don't want a separate protocol for each possibility. Ralph Droms - My earlier point on link-locals was, that if you want to use addresses from a prefix that is not marked as on-link, you cannot use them, because they are assumed to be on-link by default. That's why I suggested using a reserved ULA. Mark Townsley - Can we make a decision? Don't see much value in a link local address. Rather have a global address. Hate to see MANET deployed and unable to get to an interface from outside the MANET. Link local only if easier. Thomas Narten (Jabber) - Ralph: There is more to this. I think (wonder?) if folk are making an assumption that if they have a link-local prefix in their routing table, then normal packet sending (involving LL addresses) just works. By saying use a /128 for "on-link", they prevent LL addresses that are not actually neighbors (because they are MANET addresses) from being routing. [sic] Which is good. But this is too simplistic. You can't just put a LL prefix in your routing table and make things work. If you have multiple interfaces, you can't tell from just looking at a LL address which interface to send the packet out on. Fred Templin - Some applications may need a Link local just as state on the interface, even if never used as source address. Not talking about routing protocols. - VET interface as virtual interface can encapsulate or not as required. Take a look at the draft. Thomas Clausen - Requests link to document on ML. However, not all in scope for Autoconf. Is it being discussed in INT Area?. Fred Templin - Document in RFC editor queue as individual submission, but now created a bis version, that has specifically this proposal. Now aiming for an INT Area submission. Dave Thaler - On the question whether you can use link-locals, I agree with what Ralph said: No, you would want ULAs or similar. In order to specify that, you'd have to be tricky, though. RFC4861 (like RFC2461 before) contains a statement that all interfaces on routers MUST have a link-local address. To still be conformant, you'd have to say that you *have* a link-local address, but that's different from using it. That's why I say you have to be tricky with what you specify to avoid having to revise other RFCs. Emmanuel Baccelli - Seems like we have more or less covered the open issues from the DT document. Mark Townsley - Question for room, should we target autoconfiguration of global addresses for interfaces for operation of the MANET? Should these adresses be global, local, both? Should these addresses be reachable from the Internet? Emmanuel Baccelli - Document concentrates on first phase, getting addresses for making the MANET routing work. Connectivity to/from the outside world comes later. However, if you get global addresses right away, you solve two problems at once. Thomas Clausen - Routing protocols can handle addresses of any scope. Just happen to have considerable experience with using /32's and /128's. - Let's make a decision. Christopher Dearlove - Do want to address nodes in the MANET from outside. - Hope we make a decision, then even those whose first choice it wasn't will work with it. Jari Arkko (Jabber) - I'm in the focus-on-globals camp. (If you are taking hand counts...) Dave Thaler - Have argued against link-local, but as to global or ULA - don't overspecify. Not concerned about individual interfaces not being "pingable" from the outside world. We already have that today with ISATAP and nobody is screaming. Fred Templin - Can use link-local for physical interface, global for virtual (VET) interfaces. Thomas Clausen - Disagree. Some routing protocols need to know which physical interface a packet was sent on. Mark Townsley - Agree with Dave Thaler. Don't specify global or ULA now. Teco Boot - I partly agree on not overspecifying what's being used by specific protocols. There *are* protocols that require link-locals also for MANET. For example, an ND Router Advertisement, which may be used in a MANET, MUST use a link-local source address; OSPF MUST use link-locals. I suggest that we do not break these protocols by specifying ULAs or globals. I am not saying, that we don't need ULAs or globals. Nobody disagrees with this. But let's not specify that we don't use link-locals anymore. They are very practical for some protocols and they can be used without problem. Thomas Clausen - It's not a matter of forbidding something, it's a matter of specifying *a* practical addressing model, as per the charter. Mark Townsley - The more things you have to configure, the more options you have, the harder it will be. Take some things of the table. Teco Boot - Let's take of the table whether or not to use link-locals for routing protocols. When there are routing protocols in place that use them and they work well, let's not prohibit that. Let's go forward, let's work on globals or ULAs, but if link-locals are there and they're being used, that's OK. Erik Nordmark - Is the suggestion that link-locals be configured in the way they're being done today in an IPv6 host or router just based on the MAC address; that they can sit around there and maybe something will use them, like sending RAs? Or is the suggestion that the autoconf protocol will be used to actually configure the link-local addresses? Those are two very different things. In one case you just pick it off of your MAC address. It is locally unique on your link with whoever happen to be your neighbours at that millisecond. You could use it to send packets, which will not be forwarded by any routers. It's a very local thing, this link-local. Thomas Clausen - At a later point, as the network evolves, your link-local may no longer be unique unless you do some magic. Erik Nordmark - The other way people *could* think of link-locals is something that could be used for a multi-hop MANET routing protocol, where I could look at something that came from a link-local source and know that that's 3 hops away. That's a very different model. Thomas Clausen - Nobody should think of link-locals as being visible more than 1 hop away. Erik Nordmark - Another aspect is, what are the uniqueness criteria? Thomas Clausen - That depends. If I want to run my MANET routing protocol, using as the endpoint identifiers link-local addressses, then the requirement is for those addresses to be unique. I cannot accept duplicates. Erik Nordmark - That depends on the routing protocol. Thomas Clausen - The routing protocols that the IETF has standardized or is in the process of standardizing, for MANET. Erik Nordmark - Other protocols like OSPF have a Router ID, that you get from somewhere else. Thomas Clausen - The current crop of MANET protocols do not have that. For link detection, to detect bi-directionality, I need both ends of a packet transmission to be able to identify over which interface the packet was sent and received. Unless I have a way of uniquely identifying those interfaces, the routing protocols won't be operating correctly. If that identifier is a link-local address, then that address has to have the property of uniqueness at least within a two-hop scope. Other protocols may have other requirements. Erik Nordmark - It's one of those zero-one-infinity things. It's one thing saying this is unique when I run DAD, a millisecond later it might not be unique. Whether you say I want this to be unique as the MANET evolves and other nodes come into reach OR you say I want it to be two hops instead of one. That's a completely different ballgame. Thomas Clausen - It needs to be unique within two hops AND it needs to be unique over time as well. Whether link local or not, it must have those properties. Otherwise you are going to break the MANET routing protocols. Teco Boot - Property only of OLSR, NHDP, not of DYMO, OSPF. It's not defined how to autoconfigure a Router ID for OSPF. Thomas Clausen - It is required that you can uniquely identify each interface, communications endpoint. Teco Boot - Only for those protocols, not for a bunch of others. Thomas Clausen - Even in OSPF you are able to uniquely identify a given interface. But you use a router ID and interface number. Teco Boot - For OSPF, this has nothing to do with link-locals. The interface ID is just a number local to the router. Your statement is true for OLSR, for NHDP, but not true for other protocols. Let's be accurate. Mark Townsley - If we are to have *one* autoconf protocol, we need to choose the lowest common denominator. If one protocol needs something, then need to provide it. Erik Nordmark - There is another point we should capture. You might want to send a Router Advertisement for whatever reason. There is no reason to forbid having a link-local address, as long as you state what the semantics of that address are. It is only unique on the link the moment you tested it. It might be non-unique a millisecond later. It means nothing beyond the first hop, ever, and packets with those addresses don't get forwarded by any router. As long as you state all that, somebody designing a new routing protocol can decide whether to use those addresses or not. It seems many routing protocols need something better than that. Fred Templin - Agree. IPv6 interfaces can have multiple addresses. No guarantee that link-locals stay unique. They can be probabilistically unique, if we do e.g. a CGA assignment or a MAC EUI-64 assignment. Just putting a link-local there, doesn't mean we are going to use it for a purpose that requires uniqueness. - Can put MANET local addresses, as previously considered, on physical interfaces and global address on the virtual interface. Thomas Clausen - Agree with the latter. Mark Townsley - Can allow link local - but only if doesn't make the autoconf protocol more complicated. Erik Nordmark - That's why I want to make sure we write this down in the document, even if it is a duplication of what is already written elsewhere. Uniqueness properties, the fact that they are not forwardedi, etc. Thomas Clausen - (Persuades Erik to contribute strawman text for the above on the Autoconf ML). Fred Templin - Minor point: with IPv6 you can have LLs and globals on the same interface. With IPv4, you're supposed to remove link-local addresses when you have addresses of greater scope. Emmanuel Baccelli - Can reference other RFCs; anything to make the DT document shorter. Erik Nordmark - It's more subtle than that; we have the link model issue. Some people might think a MANET is a link and so link-locals should work. That's the reason we want to state clearly that LLs don't work the way you might think. - What about IPv4 link-locals? Emmanuel Baccelli - Thinks concensus was to skip those. Mark Townsley - Can we sum it up and have nods: Link locals may be configured, warning text from Erik N. on scope issues, not used for routing. Teco Boot - Some protocols MUST have link local addresses. There are three experimental MANET extensions for OSPF out there. Some important players are working on this. Cannot ignore this. - We should continue working on ULA and global addresses. Why this urge to prohibit link- locals? Suresh Krishnan - Agree with Erik Nordmark, looks like link local address, but isn't really. It's more like "interface-local". You cannot use it as a source address for an RS or an NS. You don't even know if it is unique. Teco Boot - Link local only for single hop information, like for example resolving Layer 2 addresses of nodes in range. All multi-hop stuff done with ULAs or globals. - How to do DAD is "solution space", however don't see much difference in uniqueness detection etc. between link-locals and globals. Either we find some mechanism or we accept that there will be a very small chance to have duplicate addresses. Thomas Clausen - Clarifying comments on OLSR etc. can handle link local addresses, as long as they are unique within two hops away. Ryuji Wakikawa - Maybe we should just ask the WG how many people think link-locals are useful and whether the WG should look at the use of link-locals in the DT document. Fred Templin - Observes that a use case analysis seems to be missing. We all seem to have this notion of what a MANET is and what we use it for. But have we ever looked at automobiles, planes, use inside a corporate enterprise network? We all may have very different notions of what it means to do MANET networking. Haven't seen this addressed in this group yet. In some use cases, there's legitimate use of link-locals. Thomas Narten (Jabber) - Arguing again on what a link local address is? Deja vu, 20 times over. Ralph Droms (Jabber) - Not on the audio. I thought we concluded that LL address is incompatible with no prefix-based direct packet delivery? Alex Petrescu (Jabber) - Agrees with that. Not sure DT agrees with that. Ryuji Wakikawa - Need to agree in which direction the WG should go. Need to formulate some questions. Thomas Clausen - The first question is what would be more appropriate to recommend w.r.t. the addresses needed for routing protocol operation: the use of link-locals versus globals or ULAs? Mark Townsley - Thought we had agreement half an hour ago that link locals wouldn't even exist. Then they came back, but with so much warning text around them, that nobody in their right mind would use them, Then someone said, he would use them for the routing protocol anyway. Thomas Clausen - Dave Thaler observed that there RFCs mandating the existence of link-local addresses. Erik Nordmark suggested to put so much warning text around their usage, that nobody would. Then, let us as a group decide that the addresses we care about and will configure are globals or ULAs. Mark Townsley - Proposal: link locals exist, warning text, autoconf will work on configuring ULA/global addresses. CHAIRS CALL FOR CONSENSUS IN THE ROOM: shall AUTOCONF: - accept that link local addresses exist, but not configure those, warn against their properties being unguaranteed and work on the configuration of ULAs or globals for use within the MANET Hum is in favour of this - needs to be validated on the mailing list. Teco Boot - Don't know what the question was. Do we simply forbid the use of Router Advertisements in MANET? - that's a clear question. RAs mandate the use of link- locals. Thomas Clausen - Think that is a different question than the one that was asked. Ryuji Wakikawa - If a MANET protcol needs Routing Advertisements, we can extend the existing router neighbour discovery protocol for that; but that's a solution space discussion. Henning Rogge - Maybe we can just agree that we need a way to determine a mesh net- unique address. Maybe we just need it for the virtual interfaces for some routing protocols; for other protocols we might need it for the interface IPs. But we need a stable way to get these addresses. Some protocols might even have contradictory requirements for the attributes of their interface addresses, but most want at least one net-wide or globally unique address. Maybe a unique address from some kind of pool. The routing protocols could specify whether they run this algorithm for every interface or use link-locals to talk to their neighbours, while using the algorithm to get virtual interface addresses or router IDs. We need a method to autoconfigure an address that is unique over more than one hop and we want to get this address automatically from some pool; that's something that all routing protocols will have in common. Thomas Clausen - Are you are arguing for or against the outcome of the 'hum' we just had? There seemed to a consensus. Are you contesting that? Henning Rogge - My problem with the proposal is that it combined several things. One of them is the autoconfiguration of MANET-unique (or globally unique) addresses. In the Internet-Draft, I would not like to combine this in all cases with interface configuration, because there seem to be some routing protocols that must use link-locals. Emmanuel Baccelli - Beg to differ. Don't know any that do, not even OSPF. It just says you *can* use link-locals. Teco Boot - Thinks it's MUST for OSPF. Thomas Clausen - The important thing is to scope the problem down so we can make progress. Ryuji Wakikawa - In the document we may say that link-locals exist, but with some warnings attached. If you can live with those, you can go ahead and use them. - This WG will not discuss link-locals for the purpose of autoconfiguration. Fred Templin - It's fine to have text that says "not recommended", "should not". Consenting users can go ahead and do it, if they know they won't get themselves into trouble. We are not forbidding anything. - This comes down to use cases again. Whether globals are needed depends on whether an application are going to be hosted on the MANET router or not. Some MANET routers might not host any applications. Do we have the same answer for those types of MANET routers as for MANET routers that host applications? Alex Petrescu (Jabber) - The /128 recommendation forbids link-local addresses. Ralph Droms (Jabber) - Thought we were dropping that /128 condition as conflicting with existing RFCs. Alex Petrescu (Jabber) - This should be made very clear. Christopher Dearlove - I thought we simply were saying, let's configure ULA/global addresses, link local addresses are orthogonal to that. Thomas Clausen - That's consistent, but with the addition that if link-locals are generated, the caveats hold that Erik N. will provide text for. - We have to write this down and confirm it on the mailing list. Thomas Narten (Jabber) - IMO, /128 does not conflict with existing specs. We are blurring and confusing various issues. You can have a /128 for on-link prefixes and still have a 64-bit Interface IDs. Next Steps: CHAIRS CALL FOR CONSENSUS IN THE ROOM: shall AUTOCONF: - accept the DT I-D (draft-baccelli-autoconf-adhoc-addr-model-01) as WG document? Hum inconclusive, did not support adopting draft-baccelli-autoconf- adhoc-addr-model-01 as WG document. Chairs request: - comments from those whose hum did not support the I-D, in order to be able to incorporate those in the I-D and make progress - the DT to issue a -02, adapted taking the comments from the meeting into account. Chairs will call for consensus on such an updated document on the list. =========================================================== From teco@inf-net.nl Mon Aug 31 23:19:18 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 641D128C321 for ; Mon, 31 Aug 2009 23:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.228 X-Spam-Level: X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjekhU21YPTR for ; Mon, 31 Aug 2009 23:19:17 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 8422A28C31A for ; Mon, 31 Aug 2009 23:16:45 -0700 (PDT) Received: (qmail 20387 invoked from network); 1 Sep 2009 08:16:41 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 1 Sep 2009 08:16:41 +0200 From: "Teco Boot" To: References: In-Reply-To: Date: Tue, 1 Sep 2009 08:15:42 +0200 Message-ID: <000c01ca2acb$ba82ea70$2f88bf50$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoqIdBFCWKwmpW+RV6TGBdF5h+HbAAUAzsg Content-Language: nl Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Sep 2009 06:19:18 -0000 I go for A. I don't feel inhibited using link-local addresses in a MANET. Link-local addresses are mandatory [RFC4291], for sure for router interfaces [RFC4861]. The MANET extensions for OSPF [RFC5340] also make use of link-local addresses. The link-local multicast scope spans the same topological region as link-local unicast [RFC4291], and we use link-local multicast for our MANET protocols [RFC5498]. I think we follow the OSPF [RFC5498] interpretation of link-locals: > IPv6 routers do not forward IPv6 datagrams having > link-local source addresses This is slightly different than [RFC4291]: > Routers must not forward any packets with Link-Local > source or destination addresses to other links. Some have brought up their concerns: 1: Scope of link-local addresses is not clearly defined: I suggest using the OSPF interpretation above. 2: Duplicate address detection [RFC4682] fails in a MANET: RFC4682 mentions DAD may be disabled, where it is believed the overhead of performing DAD outweighs its benefits. I think this is applicable to MANETs. Also DAD is not required with modified EUI-64 tokens with the "u" bit set to universal [RFC4291]. Some have proposed passive DAD, where multi-hop uniqueness in a MANET segment is assisted by the MANET protocol. This could work for link-locals. 3: The current OLSRv2 / NHDP draft does not allow usage of link-local addresses: I am not sure this is true. There may be restrictions, which IMHO can be fixed. Ian Chakeres has expressed concerns on MANET ML on having multiple interfaces with same addresses. This is related to link-local addresses. I am not saying we need a new Autoconf mechanism for link-local addresses. I just say link-locals are part of the addressing model that applies to MANETs. Regards, Teco. |-----Oorspronkelijk bericht----- |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens |Ryuji Wakikawa |Verzonden: maandag 31 augustus 2009 12:00 |Aan: autoconf@ietf.org |Onderwerp: [Autoconf] call for consensus about link local address |support | |Hi all, | |This is consensus call about the link-local address support in MANET. |Please review the following call for consensus and vote your opinion |by Sep10th. | |DT will update the document according to our consensus. | |thanks, |Thomas & ryuji | |------------------------------------------------------------------ |CALL FOR CONSENSUS | |Deadline: 2009-09-10 6:00PM PST. | |Target ID: Design Team Document |"IP Addressing Model in Ad Hoc Networks" |http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model-01 | |Issue (cited from the above draft): |- Use of Link Local Addresses - while the use of link local addresses on | interfaces connecting to a MANET link is not prohibited, the semantics | of "link local" in this context is yet to be defined, taking into | account the unusual requirements that follow, concerning such | addresses. These requirements include for example uniqueness within a | scope spanning beyond a single IP hop. | |Some discussions can be found at the IETF75 AUTOCONF minutes |http://www.ietf.org/proceedings/75/minutes/autoconf.txt | |Please vote your preference between the following two alternatives. |If you have another alternative, please propose it and give your |reasons why you prefer that alternative. | |a) The document shall support link-local addresses as required | for nodes in a MANET in addition to unique-local and global | addresses. | |b) Support unique-local and global addresses as required for MANET | nodes. The document shall not prohibit using link-local addresses, | but shall describe the difficulties inhibiting compliance in MANET | with the standardized IPv6 properties that characterize the use of | link-local addresses. |------------------------------------------------------------------ |_______________________________________________ |Autoconf mailing list |Autoconf@ietf.org |https://www.ietf.org/mailman/listinfo/autoconf