From ryuji.wakikawa@gmail.com Thu Jun 3 15:06: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 06F8B3A69F3 for ; Thu, 3 Jun 2010 15:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_INVITATION=-2, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzHP5dHyV7aY for ; Thu, 3 Jun 2010 15:06:30 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 214BB3A6878 for ; Thu, 3 Jun 2010 15:06:30 -0700 (PDT) Received: by pwi8 with SMTP id 8so329235pwi.31 for ; Thu, 03 Jun 2010 15:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:references:to:message-id :mime-version:x-mailer; bh=N3eMhfnqbBG6eFLOtu677IGXpIaUy+xqSV1y//Z0ZqE=; b=nPcwqEk5OHx+riN48QbxKh5wKo2d3DlU9pTSC1ryH5Y/hRVbbwxBkOwQZHXKuW3UiI VM4wRuJcYFUDbyqietd2Sad96fL20buKJah/dhvPJbhaTN7BSKA3NPkYeWQ1g4kOCDl2 /+gnj9cPngvhNjo6ppIYZ5bi7K+I9tsBXdMbg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; b=iNKpCI9a2EaRZXmELe7ogPJDqc9+plphKtaxdt50hOOrQvUJibwQisGa8K5eeBfQQY RUGXPoo/h9HT6CFCkGHBdr6XEFbJvOFIAQQu1BfGNOnzxi2FVcDmNVy9eBZOSy7aIGLM B8zCXs/QI8gWFKuKkJEMgRyjQz5qQTXT30d7M= Received: by 10.115.100.15 with SMTP id c15mr7708570wam.11.1275602773696; Thu, 03 Jun 2010 15:06:13 -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 r20sm2610723wam.17.2010.06.03.15.06.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Jun 2010 15:06:12 -0700 (PDT) From: Ryuji Wakikawa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Jun 2010 15:06:10 -0700 References: <20100603195140.70B7D3A68E6@core3.amsl.com> To: "autoconf@ietf.org autoconf@ietf.org" Message-Id: <614EABF2-3B45-48DE-BE01-6198FC0BFDC3@gmail.com> Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [Autoconf] Fwd: IETF 78 - Meeting and Sponsorship Information X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 03 Jun 2010 22:06:32 -0000 FYI ryuji Begin forwarded message: > From: IETF Secretariat > Date: 2010/06/03 12:51:40GMT-07:00 > To: Working Group Chairs > Subject: IETF 78 - Meeting and Sponsorship Information=20 >=20 > Working Group Chairs, >=20 > Can you please forward this message to your individual working group > emails lists. We want to ensure that as many people as possible are = aware > of the sponsorship opportunities available at IETF meetings. >=20 > Thank you. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 78th IETF Meeting=20 > Maastricht, Netherlands > July 25-30, 2010=20 >=20 > 1. Sponsorship Opportunities > 2. Registration Types > 3. Visas and Letters of Invitation > 4. Accommodations & Breakfast Information > 5. IETF 79 (Beijing) Visa Information >=20 > 1) Sponsorship Opportunities > There are still sponsorship opportunities and benefits for high = profile > company/organizational exposure at the upcoming IETF meeting in > Maastricht, Netherlands from July 25-30, 2010. All sponsorship fees = go > directly to fund the operations of the IETF. See the options at: > http://www.ietf.org/meeting/78/index.html =84Sponsorship = Opportunities=89 > under =84General=89. Each of the sponsorship options provide extended = and > repeat exposure at this weeklong meeting. =20 >=20 > Please contact Drew Dvorshak, dvorshak@isoc.org, with any questions > and/or to reserve your organization=82s spot. Thanks in advance for > supporting the critical work of the IETF! >=20 > 2) Register online at: http://www.ietf.org/meetings/78/ >=20 > 3) Letters of Invitation and Visas=20 > Letters of Invitation > After you complete the meeting registration process, you will be given = the > option to request a letter of invitation. You can request the Letter = of > Invitation as soon as you finish registration, or at a later time by > following the link provided in the confirmation email. >=20 > Visas > Please check the Netherlands Ministry of Foreign Affairs site > (http://www.minbuza.nl/en/Services/Consular_Services/Visa) for list of > countries with visa exemptions. >=20 > We recommend you give yourself at least one month to complete the visa > process. >=20 > 4) Accommodations & Breakfast Information > http://www.ietf.org/meeting/78/hotel.html >=20 > 5) If you want to start planning for your trip to IETF 79 in Beijing, = we > have visa information online here: > http://www.ietf.org/meeting/79/visa.html >=20 > Only 52 days until IETF 78! >=20 From cjbc@it.uc3m.es Fri Jun 18 09:51: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 D286F3A695E for ; Fri, 18 Jun 2010 09:51:48 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [quoted-printable] for MIME type message/external-body 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 WUkx2gXodce5 for ; Fri, 18 Jun 2010 09:51:47 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 3C74C3A690F for ; Fri, 18 Jun 2010 09:51:47 -0700 (PDT) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id A87FFBE524D; Fri, 18 Jun 2010 18:51:45 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "autoconf@ietf.org" Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-7xt8CI2yH/l2jwNJfdrN" Organization: Universidad Carlos III de Madrid Date: Fri, 18 Jun 2010 18:52:39 +0200 Message-ID: <1276879959.4284.24.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.1.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17454.000 Cc: MOUSTAFA, Hassnaa RD-CORE-ISS Subject: [Autoconf] [Fwd: I-D Action:draft-bernardos-manet-autoconf-survey-05.txt] X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2010 16:51:48 -0000 --=-7xt8CI2yH/l2jwNJfdrN Content-Type: multipart/mixed; boundary="=-T6Tmk3iSNWt2h/+2PLdz" --=-T6Tmk3iSNWt2h/+2PLdz Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi, We have submitted an updated and revised version of our survey draft, including new solutions and removing references to old WG docs. The doc is available here: http://www.ietf.org/internet-drafts/draft-bernardos-manet-autoconf-survey-0= 5.txt Would there be interest in the working group to accept this as a working group document? Thanks, Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-T6Tmk3iSNWt2h/+2PLdz Content-Disposition: inline Content-Description: Forwarded message - I-D Action:draft-bernardos-manet-autoconf-survey-05.txt Content-Type: message/rfc822 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on antispam.uc3m.es X-Spam-Level: X-Spam-Status: No, score=1.0 required=3.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.7-deb X-Original-To: cjbc@it.uc3m.es Delivered-To: cjbc@correo02.uc3m.es Received: from smtp03.uc3m.es (pip-L02.uc3m.es [163.117.176.62]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by correo02.uc3m.es (Postfix) with ESMTPS id E24C9C397; Fri, 18 Jun 2010 18:32:26 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by smtp03.uc3m.es (Postfix) with ESMTP id 567D783EDA7; Fri, 18 Jun 2010 18:32:25 +0200 (CEST) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F12893A69B3; Fri, 18 Jun 2010 09:30:11 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-bernardos-manet-autoconf-survey-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100618163013.F12893A69B3@core3.amsl.com> Date: Fri, 18 Jun 2010 09:30:11 -0700 (PDT) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org --NextPart Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Survey of IP address autoconfiguration mechanisms for MA= NETs Author(s) : C. Bernardos, H. Moustafa Filename : draft-bernardos-manet-autoconf-survey-05.txt Pages : 57 Date : 2010-06-18 This Internet Draft provides a detailed description of most of the existing IP autoconfiguration solutions proposed so far. The main aim of this document is to serve as a general reference for the AUTOCONF solution space. We present most of the previously proposed IP AUTOCONF mechanisms in MANETs, showing their key characteristics. Furthermore, each solution is analysed based on a number of evaluation considerations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bernardos-manet-autoconf-survey-0= 5.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-bernardos-manet-autoconf-survey-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Content-ID: <2010-06-18092852.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- --=-T6Tmk3iSNWt2h/+2PLdz-- --=-7xt8CI2yH/l2jwNJfdrN 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) iEYEABECAAYFAkwbpFcACgkQNdy6TdFwT2dLiwCeONu2jKeeGAM+anxFXgmDOEpD VYkAnAg0tR28Ik17cKTT6JCsNJmnpw6a =V0yA -----END PGP SIGNATURE----- --=-7xt8CI2yH/l2jwNJfdrN-- From ryuji.wakikawa@gmail.com Mon Jun 28 21:20: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 74B733A682E for ; Mon, 28 Jun 2010 21:20:41 -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 oGGE9Sn2S+Tv for ; Mon, 28 Jun 2010 21:20:30 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id C0FE03A67A7 for ; Mon, 28 Jun 2010 21:20:24 -0700 (PDT) Received: by pwi9 with SMTP id 9so117052pwi.31 for ; Mon, 28 Jun 2010 21:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=ElhBPWnysP7yg1FLZbUROytR1CIwyBwiYGOSB8kwuGs=; b=I3mmKnloyCYVxY6byHWIRa3lfSjCxd5nOlp56phWrUca5Llu7KvEQLgPOsoqH/hbQQ QLEURhak0Dm4RuGisBdEMM82zmnl32Ln6R2atDiO0Q8RoI9nxPnJNt4jPb9CJ9tbZsTV tdz/lgCi/WTWBRLOd276sceuLTlp7P0xJlcpg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=qwRSBia3ePPkFJ/I4EhThb7nTAjNPRQe5sAHhDX/JpVAKxB5wFcd0VSFgsyHouVpiZ fMIshJ3tv4o4MjNnWEz74ejZuqx8tjn1JIDjI9KnwbcO+9kT4DcM+AH0eTbbm4cOIsHQ fCl+N29t5QWfBFNUOVj6ZB2Xmt6SyhtLLmJcs= Received: by 10.142.247.33 with SMTP id u33mr6929860wfh.44.1277785231457; Mon, 28 Jun 2010 21:20:31 -0700 (PDT) Received: from [10.0.1.2] (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id c15sm4417575rvi.11.2010.06.28.21.20.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 28 Jun 2010 21:20:30 -0700 (PDT) From: Ryuji Wakikawa Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Jun 2010 21:20:28 -0700 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] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 04:20:43 -0000 Hi all, Please find a proposal of a new AUTOCONF charter attached below. We need to define our new charter carefully to avoid yet-another 5 years = discussion. Jari and chairs agreed to narrow down the charter items and go straight = to solution space.=20 This charter is not the final version. Please review it and provide us = your comments. =20 The discussion before the coming IETF is very important to set our = charter ready soon. Please give us your feedback before July 9th.=20 thanks, ryuji 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. 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. 2. 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 on 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 as a part of the first item; it is expected that = address uniqueness is guaranteed by the central node alone. Goals and Milestones: Dec 2010 First working group draft of the address configuration = mechanism Apr 2011 First working group draft of the prefix configuration mechanism Sep 2011 Submission of the address configuration mechanism to the IESG = for publication as a Proposed Standard Sep 2011 Submission of the prefix configuration mechanism to the IESG = for publication as a Proposed Standard From henning.rogge@fkie.fraunhofer.de Mon Jun 28 23:03: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 302003A6966 for ; Mon, 28 Jun 2010 23:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[AWL=-0.309, 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 nA3UWEgfggbW for ; Mon, 28 Jun 2010 23:03:29 -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 9DE683A694C for ; Mon, 28 Jun 2010 23:03:28 -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 1OTTuz-0002cC-Jy; Tue, 29 Jun 2010 08:03:37 +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 1OTTuz-0003PG-BN; Tue, 29 Jun 2010 08:03:37 +0200 From: Henning Rogge To: autoconf@ietf.org Date: Tue, 29 Jun 2010 08:03:28 +0200 User-Agent: KMail/1.13.3 (Linux/2.6.32-22-generic; KDE/4.4.4; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart24575389.ZAUrvoIjuh"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11276/Tue Jun 29 03:59:38 2010) by mailguard.fgan.de X-Scan-Signature: 1e9a6bb74562192ca4a04316780810e4 Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 06:03:30 -0000 --nextPart24575389.ZAUrvoIjuh Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue June 29 2010 06:20:28 Ryuji Wakikawa wrote: > 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 > 1. 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. I don't think elections are a good way to add redundancy for an address=20 configuration system. The dependency of a single node in the whole network = to=20 configure the addresses will be a bottleneck for larger mesh networks. > 2. 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. I don't see a difference between 1 and 2, for IPv6 case 1 is just case 2 wi= th=20 a prefix length of 128 (or 64 if we use the IPv6 autoconf postfix). =2D------------- Does this proposal mean the autoconf group will not work on a distributed=20 address configuration scheme for mesh networks ? Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-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 --nextPart24575389.ZAUrvoIjuh 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) iEYEABECAAYFAkwpjLEACgkQRIfGfFXsz+AUZwCfeXD9g9fr55ceHBNFu8Lkvaxb JWIAnj1ehuB2Xel8juKWaDw2FUuNYVUp =SPAL -----END PGP SIGNATURE----- --nextPart24575389.ZAUrvoIjuh-- From Chris.Dearlove@baesystems.com Tue Jun 29 02:04: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 667303A69A1 for ; Tue, 29 Jun 2010 02:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdEBnUQpgt9D for ; Tue, 29 Jun 2010 02:04:16 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 3FC5D3A635F for ; Tue, 29 Jun 2010 02:04:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,503,1272841200"; d="scan'208";a="73388133" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 29 Jun 2010 10:04:25 +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 o5T94PsN027370; Tue, 29 Jun 2010 10:04:25 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 10:04:25 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit x-mimeole: Produced By Microsoft Exchange V6.5 Date: Tue, 29 Jun 2010 10:04:24 +0100 Message-ID: In-Reply-To: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] Call for comments to a new AUTOCONF charter proposal. thread-index: AcsXUOUY+MphkuPDQBWSVKoTb7N1zAAFy7HQ References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , X-OriginalArrivalTime: 29 Jun 2010 09:04:25.0560 (UTC) FILETIME=[12902580:01CB176A] Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 09:04:17 -0000 > Does this proposal mean the autoconf group will not work on a distributed > address configuration scheme for mesh networks ? Same question, except I'd stick with the terminology ad hoc network. A centralised distribution mechanism is a very poor fit to much of what's attractive about an ad hoc network, and a very poor fit (due to having a single point of failure) to many application areas for ad hoc networks. This is not the direction I for one had hoped that the Autoconf WG would go in. I note the reference to "future extensions", but first I assume that this is not chartered work, and second that forces decentralised work into a certain shape, rather than working from the problem more generally. I appreciate that the WG can only work on solutions that people are prepared to work on, and unfortunately I can't offer the effort needed to make a concrete alternative proposal. I think however I've put in at least my share of work in the Manet WG. Incidentally the charter refers to RFC 5889, which is not yet published. I see that is in AUTH48, but noted as on hold for a technical issue. AUTH48 seems rather late for a technical issue, unless meaning a publication technical issue rather than an engineering technical issue. ******************************************************************** 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 cjbc@it.uc3m.es Tue Jun 29 04:14: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 2B4D83A680E for ; Tue, 29 Jun 2010 04:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.374 X-Spam-Level: X-Spam-Status: No, score=-5.374 tagged_above=-999 required=5 tests=[AWL=0.325, 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 caKWlRusq9Ig for ; Tue, 29 Jun 2010 04:14:26 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id B14D63A6878 for ; Tue, 29 Jun 2010 04:14:25 -0700 (PDT) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id E5CC122D59; Tue, 29 Jun 2010 13:14:34 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Ryuji Wakikawa In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-h+tTQs7JsQoLU1ahpCwj" Organization: Universidad Carlos III de Madrid Date: Tue, 29 Jun 2010 13:15:32 +0200 Message-ID: <1277810132.4261.9.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.1.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17474.006 Cc: "autoconf@ietf.org autoconf@ietf.org" Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 11:14:29 -0000 --=-h+tTQs7JsQoLU1ahpCwj Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Ryuji, all, I have some comments: - Why are we assuming a DHCP-based solution? or a more general question: why are we pushing for a centralized solution? I'm neutral on this at this point, but I think it'd be good to analyze the different pros and cons before taking such an important decision. - Related with the former, I strongly believe that analyzing the existing solution space is a step that would help a lot in designing a solution. We have been working in the past on solutions surveys and problem space analysis: http://tools.ietf.org/html/draft-bernardos-manet-autoconf-survey-05 http://tools.ietf.org/html/draft-bernardos-autoconf-solution-space-02 I think it is worth adding an item in the charter for an informational document that analyzes the solution space. What do people think? do you think it is worth adding an item in the charter for this? we have already some documents that could serve as starting point and their authors are willing to work on this to make it progress. Would do other people contribute to that effort (e.g., suggesting updates, reviewing it)? Thanks, Carlos On Mon, 2010-06-28 at 21:20 -0700, Ryuji Wakikawa wrote:=20 > Hi all, >=20 > Please find a proposal of a new AUTOCONF charter attached below. > We need to define our new charter carefully to avoid yet-another 5 years = discussion. > Jari and chairs agreed to narrow down the charter items and go straight t= o solution space.=20 >=20 > This charter is not the final version. Please review it and provide us yo= ur comments. =20 > The discussion before the coming IETF is very important to set our charte= r ready soon. >=20 > Please give us your feedback before July 9th.=20 >=20 > thanks, > ryuji >=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.h= tml >=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 p= refixes for use by attached nodes. >=20 > After completing the work on RFC 5889, the main purpose of the AUTOCONF W= G is to standardize how existing IPv6 address configuration tools can be us= ed for address configuration: >=20 > 1. A DHCPv6-based mechanism for configuring required interface addresses = for the routers in the ad hoc network. This mechanism is expected to produc= e addresses with properties outlined in RFC 5889. This mechanism uses the e= xisting DHCPv6 protocol unchanged, and assumes a central node that can allo= cate addresses on a first-come-first-served basis. Other nodes in the ad ho= c network will relay messages to the central node in order to help a new no= de get an address for itself. This mechanism is only suitable for deploymen= ts 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 a= s well. Future extensions such as central node election may make this mecha= nism suitable for also for stand-alone ad hoc networks. >=20 > 2. A DHCPv6-based mechanism for delegating a prefix(es) to each router fo= r use by applications running on the routers themselves, or for configurati= on 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 on operation of any specific MANET = routing protocol, although may exploit information maintained by such a rou= ting protocol, if available. >=20 > The working group will adapt and/or reuse existing protocols whenever rea= sonable and possible. No new duplicate address detection mechanisms are wil= l be specified as a part of the first item; it is expected that address uni= queness is guaranteed by the central node alone. >=20 > Goals and Milestones: >=20 > Dec 2010 First working group draft of the address configuration mechanism > Apr 2011 First working group draft of the prefix configuration mechanism > Sep 2011 Submission of the address configuration mechanism to the IESG fo= r publication as a Proposed Standard > Sep 2011 Submission of the prefix configuration mechanism to the IESG for= publication as a Proposed Standard > _______________________________________________ > 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 --=-h+tTQs7JsQoLU1ahpCwj 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) iEYEABECAAYFAkwp1c8ACgkQNdy6TdFwT2clZwCgkveKxPpUeLCUztqtalLaV3rI 7zsAoNjZQd0HRg4Kk1aHneyhlDpqORFS =P9Ru -----END PGP SIGNATURE----- --=-h+tTQs7JsQoLU1ahpCwj-- From cjbc@it.uc3m.es Tue Jun 29 04:15: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 B13E93A6994 for ; Tue, 29 Jun 2010 04:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.439 X-Spam-Level: X-Spam-Status: No, score=-5.439 tagged_above=-999 required=5 tests=[AWL=0.260, 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 NQa3WjuGci1d for ; Tue, 29 Jun 2010 04:15:02 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 8D5673A6AA9 for ; Tue, 29 Jun 2010 04:14:45 -0700 (PDT) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 94F2022D59; Tue, 29 Jun 2010 13:14:54 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Dearlove, Christopher (UK)" In-Reply-To: References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-4QFKfssD+kkhyYuCa4ER" Organization: Universidad Carlos III de Madrid Date: Tue, 29 Jun 2010 13:15:54 +0200 Message-ID: <1277810154.4261.10.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.1.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17474.006 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 11:15:05 -0000 --=-4QFKfssD+kkhyYuCa4ER Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable On Tue, 2010-06-29 at 10:04 +0100, Dearlove, Christopher (UK) wrote: > > Does this proposal mean the autoconf group will not work on a > distributed=20 > > address configuration scheme for mesh networks ? >=20 > Same question, except I'd stick with the terminology ad hoc network. > A centralised distribution mechanism is a very poor fit to much of > what's attractive about an ad hoc network, and a very poor fit (due > to having a single point of failure) to many application areas for > ad hoc networks. Agree. Carlos >=20 > This is not the direction I for one had hoped that the Autoconf WG > would go in. I note the reference to "future extensions", but first > I assume that this is not chartered work, and second that forces > decentralised work into a certain shape, rather than working from > the problem more generally. >=20 > I appreciate that the WG can only work on solutions that people are > prepared to work on, and unfortunately I can't offer the effort needed > to make a concrete alternative proposal. I think however I've put in > at least my share of work in the Manet WG. >=20 > Incidentally the charter refers to RFC 5889, which is not yet published. > I see that is in AUTH48, but noted as on hold for a technical issue. > AUTH48 seems rather late for a technical issue, unless meaning a > publication technical issue rather than an engineering technical issue. >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > 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 --=-4QFKfssD+kkhyYuCa4ER 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) iEYEABECAAYFAkwp1eoACgkQNdy6TdFwT2csCwCgzKJ9Dg1Fbf86G7NocRU+CpVb 5ZMAoOAvUK9xce9vLNNrPiQ6GoYHvjQq =MU5m -----END PGP SIGNATURE----- --=-4QFKfssD+kkhyYuCa4ER-- From alexandru.petrescu@gmail.com Tue Jun 29 05:34: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 688273A6AE1 for ; Tue, 29 Jun 2010 05:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.318 X-Spam-Level: X-Spam-Status: No, score=-0.318 tagged_above=-999 required=5 tests=[AWL=-0.483, 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 w5GDf-b4E0eL for ; Tue, 29 Jun 2010 05:34:46 -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 830A33A6893 for ; Tue, 29 Jun 2010 05:34:43 -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 o5TCYf13004519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 29 Jun 2010 14:34:42 +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 o5TCYfuF030090 for ; Tue, 29 Jun 2010 14:34: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 o5TCYfLK026140 for ; Tue, 29 Jun 2010 14:34:41 +0200 Message-ID: <4C29E861.4080706@gmail.com> Date: Tue, 29 Jun 2010 14:34:41 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: autoconf@ietf.org References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 12:34:47 -0000 Le 29/06/2010 08:03, Henning Rogge a écrit : > On Tue June 29 2010 06:20:28 Ryuji Wakikawa wrote: >> 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. 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. > > I don't think elections are a good way to add redundancy for an address > configuration system. The dependency of a single node in the whole network to > configure the addresses will be a bottleneck for larger mesh networks. But elections is what gets rid of central node bottlenecks... if that single node fails then elect another. >> 2. 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. > > I don't see a difference between 1 and 2, for IPv6 case 1 is just case 2 with > a prefix length of 128 (or 64 if we use the IPv6 autoconf postfix). To my quick reading 2) does prefixes too whereas 1) does addresses only. Alex > > -------------- > Does this proposal mean the autoconf group will not work on a distributed > address configuration scheme for mesh networks ? > > Henning Rogge > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Tue Jun 29 05:39: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 8906D3A6893 for ; Tue, 29 Jun 2010 05:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.513 X-Spam-Level: X-Spam-Status: No, score=-1.513 tagged_above=-999 required=5 tests=[AWL=0.736, 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 jPuspBm4c8nu for ; Tue, 29 Jun 2010 05:39:27 -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 2FF603A6452 for ; Tue, 29 Jun 2010 05:39:27 -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 o5TCdakb027108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 29 Jun 2010 14:39:36 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o5TCdaWE031515 for ; Tue, 29 Jun 2010 14:39:36 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o5TCdabr029430 for ; Tue, 29 Jun 2010 14:39:36 +0200 Message-ID: <4C29E988.6000908@gmail.com> Date: Tue, 29 Jun 2010 14:39:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: autoconf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 12:39:29 -0000 Le 29/06/2010 06:20, Ryuji Wakikawa a écrit : > Hi all, > > Please find a proposal of a new AUTOCONF charter attached below. We > need to define our new charter carefully to avoid yet-another 5 > years discussion. Jari and chairs agreed to narrow down the charter > items and go straight to solution space. > > This charter is not the final version. Please review it and provide > us your comments. The discussion before the coming IETF is very > important to set our charter ready soon. > > Please give us your feedback before July 9th. > > thanks, ryuji > > 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. 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. > > 2. 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. Charter proposal looks like a good basis for further discussion, I agree. I suggest to add point "3) RA-based mechanism for exchanging existing prefixes and updating routing tables such that paths are set up ok." I can post an updated draft for Maastricht about a solution for this point 3. For point 1) and 2) I suggest to couple the design of address assignment to the specification of how the route state is updated when an address or prefix has been assigned. Alex > > Both mechanisms should be independent on 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 as a part of the first item; it is > expected that address uniqueness is guaranteed by the central node > alone. > > Goals and Milestones: > > Dec 2010 First working group draft of the address configuration > mechanism Apr 2011 First working group draft of the prefix > configuration mechanism Sep 2011 Submission of the address > configuration mechanism to the IESG for publication as a Proposed > Standard Sep 2011 Submission of the prefix configuration mechanism > to the IESG for publication as a Proposed Standard > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > From henning.rogge@fkie.fraunhofer.de Tue Jun 29 05:44: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 F25D33A6BC7 for ; Tue, 29 Jun 2010 05:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.453 X-Spam-Level: X-Spam-Status: No, score=0.453 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUBeXdwsZfbk for ; Tue, 29 Jun 2010 05:44:09 -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 A90E63A6BC6 for ; Tue, 29 Jun 2010 05:44:09 -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 1OTaAl-0001mw-G4; Tue, 29 Jun 2010 14:44:19 +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 1OTaAl-0005PL-7e; Tue, 29 Jun 2010 14:44:19 +0200 From: Henning Rogge To: autoconf@ietf.org Date: Tue, 29 Jun 2010 14:44:15 +0200 User-Agent: KMail/1.13.3 (Linux/2.6.32-22-generic; KDE/4.4.4; i686; ; ) References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> <4C29E861.4080706@gmail.com> In-Reply-To: <4C29E861.4080706@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2703990.rfFdGsWzqe"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201006291444.15951.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.96.1/11279/Tue Jun 29 14:08:44 2010) by mailguard.fgan.de X-Scan-Signature: ad1983844cdfc65af3eaa1381589e1d9 Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 12:44:14 -0000 --nextPart2703990.rfFdGsWzqe Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue June 29 2010 14:34:41 Alexandru Petrescu wrote: > > I don't think elections are a good way to add redundancy for an address > > configuration system. The dependency of a single node in the whole > > network to configure the addresses will be a bottleneck for larger mesh > > networks. >=20 > But elections is what gets rid of central node bottlenecks... if that > single node fails then elect another. Elections are a real complex thing in MANETs, better have redundancy and "n= o=20 bottlenecks" by allowing multiple redundant address providers. =20 > > I don't see a difference between 1 and 2, for IPv6 case 1 is just case 2 > > with a prefix length of 128 (or 64 if we use the IPv6 autoconf postfix). >=20 > To my quick reading 2) does prefixes too whereas 1) does addresses only. Which make it a waste of time to develop sollution 1, because it's only a=20 special case of sollution 2. 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 --nextPart2703990.rfFdGsWzqe 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) iEYEABECAAYFAkwp6p8ACgkQRIfGfFXsz+D9DgCfWDKlg42tUtLP64zp/0pPW3BW AKcAn2Ia3bG3tBpU+MOZUKU967opwLkB =BYmj -----END PGP SIGNATURE----- --nextPart2703990.rfFdGsWzqe-- From Chris.Dearlove@baesystems.com Tue Jun 29 07:07: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 339C43A6C0F for ; Tue, 29 Jun 2010 07:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_40=-0.185, 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 wqhPe9dygzwf for ; Tue, 29 Jun 2010 07:07:56 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id D961A3A6BCE for ; Tue, 29 Jun 2010 07:07:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,505,1272841200"; d="scan'208";a="73501629" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 29 Jun 2010 15:08:06 +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 o5TE85DJ032258; Tue, 29 Jun 2010 15:08:05 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 15:08:05 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit x-mimeole: Produced By Microsoft Exchange V6.5 Date: Tue, 29 Jun 2010 15:08:05 +0100 Message-ID: In-Reply-To: <201006291444.15951.henning.rogge@fkie.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] Call for comments to a new AUTOCONF charter proposal. thread-index: AcsXiNCAPGidV0yWRaOMf3ix4z7kRgACugrw References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C29E861.4080706@gmail.com> <201006291444.15951.henning.rogge@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , X-OriginalArrivalTime: 29 Jun 2010 14:08:05.0589 (UTC) FILETIME=[7E8BF050:01CB1794] Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 14:07:57 -0000 Henning > Elections are a real complex thing in MANETs, better have redundancy and "no > bottlenecks" by allowing multiple redundant address providers. The extreme case of which is that all nodes are address providers. Note that I'm not however saying that is the way to go, just that that's an option. There is also the IPv4 vs. IPv6 issue. While the IETF would like everything new to be IPv6, back in the real world IPv4 is currently still more important. -- 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 jari.arkko@piuha.net Tue Jun 29 13:52: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 96B293A6873 for ; Tue, 29 Jun 2010 13:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.839 X-Spam-Level: X-Spam-Status: No, score=-1.839 tagged_above=-999 required=5 tests=[AWL=0.760, 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 uQv87pZIom0L for ; Tue, 29 Jun 2010 13:52:04 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id AA7593A67E7 for ; Tue, 29 Jun 2010 13:52:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 434592CED4; Tue, 29 Jun 2010 23:52:13 +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 e2fG7gChsWcq; Tue, 29 Jun 2010 23:52:12 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 6E64D2CC62; Tue, 29 Jun 2010 23:52:12 +0300 (EEST) Message-ID: <4C2A5CFB.9070806@piuha.net> Date: Tue, 29 Jun 2010 23:52:11 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <1277810132.4261.9.camel@acorde.it.uc3m.es> In-Reply-To: <1277810132.4261.9.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: "autoconf@ietf.org autoconf@ietf.org" Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 20:52:05 -0000 Carlos, > I strongly believe that analyzing the > existing solution space is a step that would help a lot in designing a > solution. We have been working in the past on solutions surveys and > problem space analysis: > I think a solution analysis document would be a useful output from the working group, particularly if we already have a good start an existing paper or draft. Thanks for the suggestion! I think we should add it to the charter. (I'm a little reluctant to tie the completion of such a document to the start of solution work, however. Particularly if we can identify a simple first step solution such as DHCP that requires no new protocols.) Jari From jari.arkko@piuha.net Tue Jun 29 14:54: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 0D4823A6930 for ; Tue, 29 Jun 2010 14:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[AWL=-0.578, 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 w8q7UxfIZW58 for ; Tue, 29 Jun 2010 14:54:56 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 35A3C3A69F9 for ; Tue, 29 Jun 2010 14:54:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 37C5F2CC62; Wed, 30 Jun 2010 00:55:05 +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 kAe1Q3vlf93s; Wed, 30 Jun 2010 00:55:04 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 8673B2CED4; Wed, 30 Jun 2010 00:55:04 +0300 (EEST) Message-ID: <4C2A6BB7.1000900@piuha.net> Date: Wed, 30 Jun 2010 00:55:03 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "autoconf@ietf.org" Subject: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 21:54:57 -0000 Christopher, > Incidentally the charter refers to RFC 5889, which is not yet published. > I see that is in AUTH48, but noted as on hold for a technical issue. > AUTH48 seems rather late for a technical issue, unless meaning a > publication technical issue rather than an engineering technical issue. > Yes it is late. We approved the document but after approval there was a comment on the IETF last call thread from Erik Nordmark. We are trying to resolve it but unfortunately it took a long time for me to do so. But we are now trying to do it. The standing proposal is below, comments appreciated. Jari ----- We talked about this during Anaheim but never got to the end of it. Sorry -- I should have posted a suggestion back then but other business has kept me busy. I have now looked at the discussion again. The essence of Erik's complaint was twofold. First, the document claimed that routing protocols require a unique IP address (and not just a router ID), which is not true. Second, that the document unnecessarily dismisses link local identifiers as addresses. About the first issue: Erik is right that not all routing protocols require unique IP addresses at all. But at the same time, apparently some routing protocols in the MANET space do require it (e.g., OSLR in RFC 3626). In a way, the document is factually correct on this point as it states that some protocols do have these requirements. But it may also be misleading from another perspective, as we certainly do not want to claim that using unique IP addresses is a recommended design for a routing protocol or the only possible model. The second issue is partially related to the first one, as one of the reasons for using non-link-local addresses is to enable the use of unique addresses in routing protocols. In any case, the intent was never to claim that link local addresses cannot be used. The document merely makes one recommendation about a commonly used addressing model in adhoc networks. I would like to defend the working group's right to publish such an "example model" -- particularly after years of effort spent in trying to find the true universal model. As long as the working group is not making false claims, this is clearly appropriate. But I can see that the document could be clearer about its claims. Here's a possible rewrite of Section 5 to address these issues: OLD: Routing protocols running on a router may exhibit different requirements for uniqueness of interface addresses; some have no such requirements, others have requirements ranging from local uniqueness only, to uniqueness within, at least, the routing domain (as defined in [RFC1136]). Configuring an IP address that is unique within the routing domain satisfies the less stringent uniqueness requirements of local uniqueness, while also enabling protocols which have the most stringent requirements of uniqueness within the routing domain. This suggests the following principle: o an IP address assigned to an interface that connects to a link with undetermined connectivity properties should be unique, at least within the routing domain. NEW: Routing protocols running on a router may exhibit different requirements for uniqueness of interface addresses; some have no such requirements, others have requirements ranging from local uniqueness only, to uniqueness within, at least, the routing domain (as defined in [RFC1136]). Many modern routing protocols do not need to employ unique addresses at all, and theoretically, their only requirement is that some router identifier is unique. Nevertheless, configuring an IP address that is unique within the routing domain satisfies the less stringent uniqueness requirements of local uniqueness, while also enabling protocols which have the most stringent requirements of uniqueness within the routing domain. As a result, many current deployments have chosen to employ the following simplifying principle: o an IP address assigned to an interface that connects to a link with undetermined connectivity properties should be unique, at least within the routing domain. And in Section 6.1: OLD: o There is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, hence they cannot be used to reliably identify routers (it is often desirable to identify a router with an IP address). NEW: o There is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, hence they cannot be used to reliably identify routers, should this be necessary in the chosen routing protocol. OLD: Therefore, autoconfiguration solutions should be encouraged to primarily focus on configuring IP addresses that are not IPv6 link- local. NEW: Therefore, a common theme in many autoconfiguration solutions is to focus on configuring IP addresses that are not IPv6 link- local. From teco@inf-net.nl Tue Jun 29 14:55: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 B747E3A6C21 for ; Tue, 29 Jun 2010 14:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLQ8kea9LnId for ; Tue, 29 Jun 2010 14:55:53 -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 A13483A69ED for ; Tue, 29 Jun 2010 14:55:53 -0700 (PDT) Received: by wyb40 with SMTP id 40so83065wyb.31 for ; Tue, 29 Jun 2010 14:56:00 -0700 (PDT) Received: by 10.216.87.18 with SMTP id x18mr10149831wee.88.1277848560302; Tue, 29 Jun 2010 14:56:00 -0700 (PDT) Received: from [192.168.2.116] (dsl-087-195-131-102.solcon.nl [87.195.131.102]) by mx.google.com with ESMTPS id g17sm5930962wee.5.2010.06.29.14.55.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 29 Jun 2010 14:55:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Tue, 29 Jun 2010 23:55:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4AD57C4F-9C4F-47C8-BF36-47F400710C37@inf-net.nl> References: To: Ryuji Wakikawa X-Mailer: Apple Mail (2.1081) Cc: "autoconf@ietf.org autoconf@ietf.org" Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 21:55:54 -0000 Ryuji, all Thanks for the new draft charter. I agree with other postings, that selecting DHCPv6 with a central node = is not that obvious. I think a core attribute of an ad hoc network / MANET is cooperation = between equal nodes. Especially on item 1, I am worried on dependency, election mechanisms, = multi-hop (un)reachability and DHCP relay explosions.=20 On the other hand, I have a solution for this. I can rename BRDP to DSDP = (DHCP Server Discovery Protocol). There are other (minor) changes = needed. Using DHCPv6 for prefixes (and other parameters) makes sense to me. = There are some prerequisites, like addresses / reachability and a = pointer to a DHCPv6 server.=20 I suggest adding "and other parameters". On IPv4, I can think of getting an IPv4 address with DHCPv6 or "DHCP = over IPv6". Ditto for prefix and other parameters. A charter item could be the analysis how to support IPv4 on the IPv6 = solution. The result could be used for rechartering. On: > 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. Many more networks have more than one Internet gateway. Speaking for = myself, I don't see single homed MANETs in real world. Maybe it is my = reading, and the text was not intended to be restrictive. I support adding an overview document as charter item. =20 Regards, Teco From ryuji.wakikawa@gmail.com Tue Jun 29 15:16: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 195673A68AB for ; Tue, 29 Jun 2010 15:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 oIKT-y+BmGXv for ; Tue, 29 Jun 2010 15:16:21 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 8B5F03A68E6 for ; Tue, 29 Jun 2010 15:16:21 -0700 (PDT) Received: by pvd12 with SMTP id 12so98487pvd.31 for ; Tue, 29 Jun 2010 15:16:30 -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=ZODtJ/R99oHFTaksrLNml0cgwIPAJIWcIgtweq6Jy+g=; b=J/lW0vQ02pqL02wzeyRJ3XIoeBSub3NPWEvN7Pa0h4dp5O5GDxGpcZ6N4rsrBxipYO BSbow3v+wSBXtjGW9AKsGgwZkdeqjNxht5wylmhfsSLM7HPsMFTCsynBcn3lMfApWYJ1 G8J2Ko8csgOEBNljZFadUf2VhpZTkCzLw8sUE= 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=bxEJq7pMi6CQIRJm3T45p7jTQhD1fW1f8Wv8nWuB5+Ob3M2Ypo3ORUlwez/dOqVa0z h9KeafhSElWyCfzinPD8ksk2dTRXnJy+SwB4Zp361vCutOjTNoOHU56Lz+K82rA6srsU RoQgxtU48GgKfK0vSPw8thxUAyJ0/5t8N36fA= Received: by 10.114.164.37 with SMTP id m37mr8458012wae.39.1277849789837; Tue, 29 Jun 2010 15:16:29 -0700 (PDT) Received: from macbookpro-ryuji.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id d39sm65040253wam.16.2010.06.29.15.16.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 29 Jun 2010 15:16:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Ryuji Wakikawa In-Reply-To: <201006291444.15951.henning.rogge@fkie.fraunhofer.de> Date: Tue, 29 Jun 2010 15:16:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4C3B0DFE-C271-4E4E-838F-B6B23319F518@gmail.com> References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> <4C29E861.4080706@gmail.com> <201006291444.15951.henning.rogge@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 22:16:24 -0000 Hi Henning and all, On 2010/06/29, at 5:44, Henning Rogge wrote: > On Tue June 29 2010 14:34:41 Alexandru Petrescu wrote: >>> I don't think elections are a good way to add redundancy for an = address >>> configuration system. The dependency of a single node in the whole >>> network to configure the addresses will be a bottleneck for larger = mesh >>> networks. >>=20 >> But elections is what gets rid of central node bottlenecks... if that >> single node fails then elect another. > Elections are a real complex thing in MANETs, better have redundancy = and "no=20 > bottlenecks" by allowing multiple redundant address providers. =46rom the proposed charter, election part is just "future extension" = and not the item we will work on right away. In this charter we try to recycle existing IP autoconfiguration = protocols for MANET environment.=20 This was clearly noted in the previous charter. see below. "This group's effort may include the development of new protocol=20 mechanisms, should the existing IP autoconfiguration mechanisms be found inadequate. However, the first task of the working group is to describe one practical addressing model for ad hoc networks." DHCP is a protocol supporting prefix delegation and address assignment = now. RA based approach (Alex's proposal) may be an option, too. However, 6LowPAN WG is working on this subject based on the AUTOCONF = address arch. Why not stick to the existing IP autoconfiguration mechanism as a = starting point so that we can directly go to the solution space discussion. =20 Do you want to spend a few years to define protocol requirements of a = solution(s)? I specially concern the endless activity cycle in AUTOCONF from the WG's = history. >=20 >>> I don't see a difference between 1 and 2, for IPv6 case 1 is just = case 2 >>> with a prefix length of 128 (or 64 if we use the IPv6 autoconf = postfix). >>=20 >> To my quick reading 2) does prefixes too whereas 1) does addresses = only. > Which make it a waste of time to develop sollution 1, because it's = only a=20 > special case of sollution 2. Why waste of time? These two items should be tightly related, but each = solution (1 and ) should work independently.=20 For instance, we may use a manet routing protocol to assign an address = and use DHCP for PD in the future. To support these future extension, we should separate these two items. regards, ryuji >=20 >=20 > Henning Rogge > --=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 jari.arkko@piuha.net Tue Jun 29 15:22: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 4508828C0E8 for ; Tue, 29 Jun 2010 15:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.179 X-Spam-Level: X-Spam-Status: No, score=0.179 tagged_above=-999 required=5 tests=[AWL=-1.280, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gm5ZC8XPNXLY for ; Tue, 29 Jun 2010 15:22:47 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 8CB6328C0DE for ; Tue, 29 Jun 2010 15:22:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BF96D2CC62; Wed, 30 Jun 2010 01:22:56 +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 pyy0VkcOHXMP; Wed, 30 Jun 2010 01:22:55 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 791D52CED3; Wed, 30 Jun 2010 01:22:55 +0300 (EEST) Message-ID: <4C2A723E.3020806@piuha.net> Date: Wed, 30 Jun 2010 01:22:54 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 22:22:48 -0000 Christopher,

Does this proposal mean the autoconf group will not work on a
    
distributed 
  
address configuration scheme for mesh networks ?
    

Same question, except I'd stick with the terminology ad hoc network.
A centralised distribution mechanism is a very poor fit to much of
what's attractive about an ad hoc network, and a very poor fit (due
to having a single point of failure) to many application areas for
ad hoc networks.

This is not the direction I for one had hoped that the Autoconf WG
would go in. I note the reference to "future extensions", but first
I assume that this is not chartered work, and second that forces
decentralised work into a certain shape, rather than working from
the problem more generally.

I appreciate that the WG can only work on solutions that people are
prepared to work on, and unfortunately I can't offer the effort needed
to make a concrete alternative proposal. I think however I've put in
at least my share of work in the Manet WG.

Just so that you know who to blame :-) I was the one who asked Thomas and Ryuji to consider a simple solution with no new protocols.

But back to your feedback on the charter. I would like to respond in two ways. First, I am by no means wedded to the particular solution details. Do you have a suggested edit?

But, second, I will defend the idea that the working group needs to learn to walk before running. We've been through a five year exercise just to define the addressing model. When we attempted to define the architecture as a general model we realized that it was hard, and explaining the model to non ad hoc networking experts was even harder. But when we described a concrete addressing model that some deployments are using we did finally get an RFC. Or almost have, at least. I would like to continue on the same path. I'm told that there are deployed autoconfiguration mechanisms and that some level of support is doable even with existing protocols.

I would like to avoid repeating the experience we had earlier on trying to describe the autoconf problem. One way of avoiding it is to describe either a deployed autoconfiguration mechanism or describe how to employ standard protocols and components to provide autoconfiguration for an ad hoc network. Once this work is complete, we can describe the limitations of this mechanism as the remaining autoconfiguration problem, and work on that. But I do not look forward to more years of discussion of complex routing protocol/neighbor discovery extensions and a constant stream of questions from the outsiders about why ND or DHCP cannot do the job.

I do get that a solution with a central node (and perhaps any solution with DHCP) does not solve all needs. Would you be happier if the charter had four work items:

1. Design space survey (Informational)
2. The simple solution (such as DHCP) (PS)
3. Limitations of the simple solution (Informational)
4. Recharter for work on the more general solution

Jari

From zach@sensinode.com Tue Jun 29 23:41: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 9B3CD3A6A8B for ; Tue, 29 Jun 2010 23:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.514 X-Spam-Level: X-Spam-Status: No, score=-1.514 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_40=-0.185, 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 ZqS3XE9a0k5Z for ; Tue, 29 Jun 2010 23:41:32 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id E7C093A6835 for ; Tue, 29 Jun 2010 23:41:31 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o5U6fFEH008826 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jun 2010 09:41:15 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4C2A723E.3020806@piuha.net> Date: Wed, 30 Jun 2010 09:41:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> <4C2A723E.3020806@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 06:41:33 -0000 On Jun 30, 2010, at 1:22 AM, Jari Arkko wrote: > I do get that a solution with a central node (and perhaps any solution = with DHCP) does not solve all needs. Would you be happier if the charter = had four work items: >=20 > 1. Design space survey (Informational) > 2. The simple solution (such as DHCP) (PS) > 3. Limitations of the simple solution (Informational) > 4. Recharter for work on the more general solution +1. I support this approach. As Ryuji mentioned, we are almost finished = with work in 6LoWPAN on optimizing ND so that it works in such a = low-power and lossy network. There the approach is to enable = autoconfiguration with either DHCP or using a multihop DAD technique. = Autoconf might be able to extend or reference that work in item 2. above = and consider both DHCP and ND as parts of a simple solution. For now I = think it is enough to say in the charter that DHCP and ND mechanisms = will be applied (with minimal extensions) for the simple solution. Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From alexandru.petrescu@gmail.com Wed Jun 30 00:41: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 1C97D3A6980 for ; Wed, 30 Jun 2010 00:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.531 X-Spam-Level: X-Spam-Status: No, score=-1.531 tagged_above=-999 required=5 tests=[AWL=0.718, 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 AiTVmNFkLnwh for ; Wed, 30 Jun 2010 00:41:21 -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 9FA5C3A693C for ; Wed, 30 Jun 2010 00:41:21 -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 o5U7fUZ2004088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jun 2010 09:41:30 +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 o5U7fUSL005419; Wed, 30 Jun 2010 09:41:30 +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 o5U7fT3A004015; Wed, 30 Jun 2010 09:41:29 +0200 Message-ID: <4C2AF529.7020701@gmail.com> Date: Wed, 30 Jun 2010 09:41:29 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: autoconf@ietf.org References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> <4C29E861.4080706@gmail.com> <201006291444.15951.henning.rogge@fkie.fraunhofer.de> <4C3B0DFE-C271-4E4E-838F-B6B23319F518@gmail.com> In-Reply-To: <4C3B0DFE-C271-4E4E-838F-B6B23319F518@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 07:41:23 -0000 Innserting some comments although I'm not addressed. Le 30/06/2010 00:16, Ryuji Wakikawa a écrit : > Hi Henning and all, > > On 2010/06/29, at 5:44, Henning Rogge wrote: > >> On Tue June 29 2010 14:34:41 Alexandru Petrescu wrote: >>>> I don't think elections are a good way to add redundancy for an >>>> address configuration system. The dependency of a single node >>>> in the whole network to configure the addresses will be a >>>> bottleneck for larger mesh networks. >>> >>> But elections is what gets rid of central node bottlenecks... if >>> that single node fails then elect another. >> Elections are a real complex thing in MANETs, better have >> redundancy and "no bottlenecks" by allowing multiple redundant >> address providers. > >> From the proposed charter, election part is just "future extension" >> and not the item we will work on right away. > > In this charter we try to recycle existing IP autoconfiguration > protocols for MANET environment. > > This was clearly noted in the previous charter. see below. "This > group's effort may include the development of new protocol > mechanisms, should the existing IP autoconfiguration mechanisms be > found inadequate. However, the first task of the working group is to > describe one practical addressing model for ad hoc networks." > > DHCP is a protocol supporting prefix delegation and address > assignment now. RA based approach (Alex's proposal) may be an option, > too. However, 6LowPAN WG is working on this subject based on the > AUTOCONF address arch. Well, an RA-based prefix exchange and route update would not be dedicated to 802.15.4 only (6LoWPAN), and not to PAN either. I run it on wifi between Mobile Routers, supposedly between vehicles, and not on a PAN. > Why not stick to the existing IP autoconfiguration mechanism as a > starting point so that we can directly go to the solution space > discussion. Do you want to spend a few years to define protocol > requirements of a solution(s)? I specially concern the endless > activity cycle in AUTOCONF from the WG's history. Hmmm... I tend to agree to stick with existing IP address autoconfiguration mechanisms in AUTOCONF. >>>> I don't see a difference between 1 and 2, for IPv6 case 1 is >>>> just case 2 with a prefix length of 128 (or 64 if we use the >>>> IPv6 autoconf postfix). >>> >>> To my quick reading 2) does prefixes too whereas 1) does >>> addresses only. >> Which make it a waste of time to develop sollution 1, because it's >> only a special case of sollution 2. > > Why waste of time? These two items should be tightly related, but > each solution (1 and ) should work independently. For instance, we > may use a manet routing protocol to assign an address and use DHCP > for PD in the future. (I set aside what you are saying, explicitly the part suggesting that maybe the MANET routing protocol may assign an address... if so then, by symmetry, the address autoconfiguration mechanism could also exchange routing information and update the routing information databases - necessary for DHCP sometimes). > To support these future extension, we should separate these two > items. I agree I think we should follow the existing separation of prefixes vs addresses when it comes to address autoconfiguration mechanisms DHCPv6 and DHCPv6 PD. I need a new term like "address and prefix autoconfiguration mechanism", something like SLPAC (prefix autoconf instead of SLAAC), something like DRCP (Dynamic Router Configuration Protocol instead of DHCP). Alex > > regards, ryuji > > >> > >> >> 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 alexandru.petrescu@gmail.com Wed Jun 30 00:45: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 BA9A03A6C00 for ; Wed, 30 Jun 2010 00:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.618 X-Spam-Level: X-Spam-Status: No, score=-0.618 tagged_above=-999 required=5 tests=[AWL=-0.228, 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 JfOHoDQWbO-k for ; Wed, 30 Jun 2010 00:45:51 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id AF5663A6A83 for ; Wed, 30 Jun 2010 00:45:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o5U7jxv7011528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jun 2010 09:45:59 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o5U7jx0s007123; Wed, 30 Jun 2010 09:45:59 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o5U7jwFx006142; Wed, 30 Jun 2010 09:45:59 +0200 Message-ID: <4C2AF636.1060007@gmail.com> Date: Wed, 30 Jun 2010 09:45:58 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: autoconf@ietf.org References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> <4C2A723E.3020806@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 07:45:51 -0000 Le 30/06/2010 08:41, Zach Shelby a écrit : > > On Jun 30, 2010, at 1:22 AM, Jari Arkko wrote: > >> I do get that a solution with a central node (and perhaps any >> solution with DHCP) does not solve all needs. Would you be happier >> if the charter had four work items: >> >> 1. Design space survey (Informational) 2. The simple solution (such >> as DHCP) (PS) 3. Limitations of the simple solution >> (Informational) 4. Recharter for work on the more general solution > > > +1. I support this approach. As Ryuji mentioned, we are almost > finished with work in 6LoWPAN on optimizing ND so that it works in > such a low-power and lossy network. Well I need RA-based prefix exchanges and route updates not only on low-power and lossy networks. I don't consider 6LoWPAN neither RoLL appropriate for RA-based prefix exchanges. (not to paint them in a corner but their applicability domain is not WiFi neither Mobile Router). Alex There the approach is to enable > autoconfiguration with either DHCP or using a multihop DAD technique. > Autoconf might be able to extend or reference that work in item 2. > above and consider both DHCP and ND as parts of a simple solution. > For now I think it is enough to say in the charter that DHCP and ND > mechanisms will be applied (with minimal extensions) for the simple > solution. > > Zach > From ulrich@herberg.name Wed Jun 30 00:49:30 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1ADF3A6AC1 for ; Wed, 30 Jun 2010 00:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.305 X-Spam-Level: X-Spam-Status: No, score=-0.305 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_20=-0.74, 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 Am4foQodkKHa for ; Wed, 30 Jun 2010 00:49:30 -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 B868F3A6A1E for ; Wed, 30 Jun 2010 00:49:29 -0700 (PDT) Received: by bwz7 with SMTP id 7so259862bwz.31 for ; Wed, 30 Jun 2010 00:49:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.68.8 with SMTP id t8mr1700447bki.72.1277884176728; Wed, 30 Jun 2010 00:49:36 -0700 (PDT) Received: by 10.204.68.13 with HTTP; Wed, 30 Jun 2010 00:49:36 -0700 (PDT) In-Reply-To: References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> <4C2A723E.3020806@piuha.net> Date: Wed, 30 Jun 2010 09:49:36 +0200 Message-ID: From: Ulrich Herberg To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 07:49:30 -0000 Hi, On Wed, Jun 30, 2010 at 8:41 AM, Zach Shelby wrote: > > On Jun 30, 2010, at 1:22 AM, Jari Arkko wrote: > >> I do get that a solution with a central node (and perhaps any solution w= ith DHCP) does not solve all needs. Would you be happier if the charter had= four work items: >> >> 1. Design space survey (Informational) >> 2. The simple solution (such as DHCP) (PS) >> 3. Limitations of the simple solution (Informational) >> 4. Recharter for work on the more general solution > > > +1. I support this approach. As Ryuji mentioned, we are almost finished w= ith work in 6LoWPAN on optimizing ND so that it works in such a low-power a= nd lossy network. There the approach is to enable autoconfiguration with ei= ther DHCP or using a multihop DAD technique. Autoconf might be able to exte= nd or reference that work in item 2. above and consider both DHCP and ND as= parts of a simple solution. For now I think it is enough to say in the cha= rter that DHCP and ND mechanisms will be applied (with minimal extensions) = for the simple solution. I also agree with Jari's proposition. While I personally think that we eventually have to work on a more general solution, it may be a good start rechartering for a simple solution now. Considering how much time has passed for the address architecture document, we should aim to progress in small, doable steps rather than aiming for a "all-in-one" solution right now. As we already have a few ideas that could be integrated (e.g. Teco's and Zach's documents), the time frame seems to be doable for me. I will still continue do work on my distributed approach in the meantime, though, so that it progresses and could be considered once we will recharter again. Ulrich From zach@sensinode.com Wed Jun 30 01:09: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 DB1273A63EC for ; Wed, 30 Jun 2010 01:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.694 X-Spam-Level: X-Spam-Status: No, score=-2.694 tagged_above=-999 required=5 tests=[AWL=0.906, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fhp5M3WufRLd for ; Wed, 30 Jun 2010 01:09:10 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 64E5D3A686E for ; Wed, 30 Jun 2010 01:09:09 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o5U89GBg021681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jun 2010 11:09:16 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4C2AF636.1060007@gmail.com> Date: Wed, 30 Jun 2010 11:09:18 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> <4C2A723E.3020806@piuha.net> <4C2AF636.1060007@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 08:09:12 -0000 On Jun 30, 2010, at 10:45 AM, Alexandru Petrescu wrote: >> +1. I support this approach. As Ryuji mentioned, we are almost >> finished with work in 6LoWPAN on optimizing ND so that it works in >> such a low-power and lossy network. >=20 > Well I need RA-based prefix exchanges and route updates not only on = low-power and lossy networks. I don't consider 6LoWPAN neither RoLL = appropriate for RA-based prefix exchanges. (not to paint them in a = corner but their applicability domain is not WiFi neither Mobile = Router). Exactly, which is why that work is just an example of optimizing ND for = such an environment. Obviously in some MANETs you also have prefix = delegation to worry about, which we don't have in a LoWPAN.=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From Chris.Dearlove@baesystems.com Wed Jun 30 02:25: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 4F6F93A69CF for ; Wed, 30 Jun 2010 02:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.335 X-Spam-Level: X-Spam-Status: No, score=-4.335 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_50=0.001, HTML_MESSAGE=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 U-Yw+5iKbY6z for ; Wed, 30 Jun 2010 02:25:41 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 341B73A6978 for ; Wed, 30 Jun 2010 02:25:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,511,1272841200"; d="scan'208,217";a="73657212" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 30 Jun 2010 10:25:50 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o5U9Pn6K003885; Wed, 30 Jun 2010 10:25:50 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 10:25:49 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1836.3A15B79F" x-mimeole: Produced By Microsoft Exchange V6.5 Date: Wed, 30 Jun 2010 10:25:48 +0100 Message-ID: In-Reply-To: <4C2A723E.3020806@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] Call for comments to a new AUTOCONF charter proposal. thread-index: AcsX2aHhuWHRNnPXRVGeAZxFbxWbxwAWzXJQ References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> <4C2A723E.3020806@piuha.net> From: "Dearlove, Christopher (UK)" To: "Jari Arkko" X-OriginalArrivalTime: 30 Jun 2010 09:25:49.0799 (UTC) FILETIME=[3A713770:01CB1836] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 09:25:43 -0000 ------_=_NextPart_001_01CB1836.3A15B79F Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Just a brief comment for the moment. My current thoughts in ad hoc nedworks relate to security. And I think the interactions of security and address configuration will turn out to be critical. There are numerous solutions to address configuration that turn out to be pointless when combined with security configuration issues. I'm interested in more than just "assume all nodes have a shared secret X unknown to anyone else". -- 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 ________________________________ From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: 29 June 2010 23:23 To: Dearlove, Christopher (UK) Cc: Henning Rogge; autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. Christopher, Does this proposal mean the autoconf group will not work on a distributed address configuration scheme for mesh networks ? Same question, except I'd stick with the terminology ad hoc network. A centralised distribution mechanism is a very poor fit to much of what's attractive about an ad hoc network, and a very poor fit (due to having a single point of failure) to many application areas for ad hoc networks. This is not the direction I for one had hoped that the Autoconf WG would go in. I note the reference to "future extensions", but first I assume that this is not chartered work, and second that forces decentralised work into a certain shape, rather than working from the problem more generally. I appreciate that the WG can only work on solutions that people are prepared to work on, and unfortunately I can't offer the effort needed to make a concrete alternative proposal. I think however I've put in at least my share of work in the Manet WG. Just so that you know who to blame :-) I was the one who asked Thomas and Ryuji to consider a simple solution with no new protocols. But back to your feedback on the charter. I would like to respond in two ways. First, I am by no means wedded to the particular solution details. Do you have a suggested edit? But, second, I will defend the idea that the working group needs to learn to walk before running. We've been through a five year exercise just to define the addressing model. When we attempted to define the architecture as a general model we realized that it was hard, and explaining the model to non ad hoc networking experts was even harder. But when we described a concrete addressing model that some deployments are using we did finally get an RFC. Or almost have, at least. I would like to continue on the same path. I'm told that there are deployed autoconfiguration mechanisms and that some level of support is doable even with existing protocols. I would like to avoid repeating the experience we had earlier on trying to describe the autoconf problem. One way of avoiding it is to describe either a deployed autoconfiguration mechanism or describe how to employ standard protocols and components to provide autoconfiguration for an ad hoc network. Once this work is complete, we can describe the limitations of this mechanism as the remaining autoconfiguration problem, and work on that. But I do not look forward to more years of discussion of complex routing protocol/neighbor discovery extensions and a constant stream of questions from the outsiders about why ND or DHCP cannot do the job. I do get that a solution with a central node (and perhaps any solution with DHCP) does not solve all needs. Would you be happier if the charter had four work items: 1. Design space survey (Informational) 2. The simple solution (such as DHCP) (PS) 3. Limitations of the simple solution (Informational) 4. Recharter for work on the more general solution Jari ******************************************************************** 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. ******************************************************************** ------_=_NextPart_001_01CB1836.3A15B79F Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
Just a brief comment for the moment. My current thoughts in ad hoc
nedworks relate to security. And I think the interactions of security
and address configuration will turn out to be critical. There are
numerous solutions to address configuration that turn out to be
pointless when combined with security configuration issues. I'm
interested in more than just "assume all nodes have a shared secret
X unknown to anyone else".
 
--
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
 

From: Jari Arkko [mailto:jari.arkko@piuha.net]
Sent: 29 June 2010 23:23
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; autoconf@ietf.org
Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal.

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.
 
Christopher,

Does this proposal mean the autoconf group will not work on a
    
distributed 
  
address configuration scheme for mesh networks ?
    

Same question, except I'd stick with the terminology ad hoc network.
A centralised distribution mechanism is a very poor fit to much of
what's attractive about an ad hoc network, and a very poor fit (due
to having a single point of failure) to many application areas for
ad hoc networks.

This is not the direction I for one had hoped that the Autoconf WG
would go in. I note the reference to "future extensions", but first
I assume that this is not chartered work, and second that forces
decentralised work into a certain shape, rather than working from
the problem more generally.

I appreciate that the WG can only work on solutions that people are
prepared to work on, and unfortunately I can't offer the effort needed
to make a concrete alternative proposal. I think however I've put in
at least my share of work in the Manet WG.

Just so that you know who to blame :-) I was the one who asked Thomas and Ryuji to consider a simple solution with no new protocols.

But back to your feedback on the charter. I would like to respond in two ways. First, I am by no means wedded to the particular solution details. Do you have a suggested edit?

But, second, I will defend the idea that the working group needs to learn to walk before running. We've been through a five year exercise just to define the addressing model. When we attempted to define the architecture as a general model we realized that it was hard, and explaining the model to non ad hoc networking experts was even harder. But when we described a concrete addressing model that some deployments are using we did finally get an RFC. Or almost have, at least. I would like to continue on the same path. I'm told that there are deployed autoconfiguration mechanisms and that some level of support is doable even with existing protocols.

I would like to avoid repeating the experience we had earlier on trying to describe the autoconf problem. One way of avoiding it is to describe either a deployed autoconfiguration mechanism or describe how to employ standard protocols and components to provide autoconfiguration for an ad hoc network. Once this work is complete, we can describe the limitations of this mechanism as the remaining autoconfiguration problem, and work on that. But I do not look forward to more years of discussion of complex routing protocol/neighbor discovery extensions and a constant stream of questions from the outsiders about why ND or DHCP cannot do the job.

I do get that a solution with a central node (and perhaps any solution with DHCP) does not solve all needs. Would you be happier if the charter had four work items:

1. Design space survey (Informational)
2. The simple solution (such as DHCP) (PS)
3. Limitations of the simple solution (Informational)
4. Recharter for work on the more general solution

Jari


********************************************************************
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.
********************************************************************

------_=_NextPart_001_01CB1836.3A15B79F-- From jari.arkko@piuha.net Wed Jun 30 03:07: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 A2FBD3A67D0 for ; Wed, 30 Jun 2010 03:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.353 X-Spam-Level: X-Spam-Status: No, score=-0.353 tagged_above=-999 required=5 tests=[AWL=-0.701, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IkMic-91HO8 for ; Wed, 30 Jun 2010 03:07:21 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 04E863A695A for ; Wed, 30 Jun 2010 03:07:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6CB232CED4; Wed, 30 Jun 2010 13:07:31 +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 InW8sEqSrBm9; Wed, 30 Jun 2010 13:07:31 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 00DF72CC62; Wed, 30 Jun 2010 13:07:30 +0300 (EEST) Message-ID: <4C2B1762.1070600@piuha.net> Date: Wed, 30 Jun 2010 13:07:30 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> <4C2A723E.3020806@piuha.net> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 10:07:22 -0000 Christopher,

Just a brief comment for the moment. My current thoughts in ad hoc
nedworks relate to security. And I think the interactions of security
and address configuration will turn out to be critical. There are
numerous solutions to address configuration that turn out to be
pointless when combined with security configuration issues. I'm
interested in more than just "assume all nodes have a shared secret
X unknown to anyone else".


Absolutely. To begin with, its kind of pointless to talk about "ad hoc" (as in "unplanned") and then suddenly assume there was lots of preconfiguration.

I am hopeful though that there are clever ways to address the biggest security issues without causing too much pain. For instance, FCFS type of address and prefix allocation in the large IPv6 address space seems amenable for some proof-of-ownership solution.

Jari

From Chris.Dearlove@baesystems.com Wed Jun 30 04:00: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 B16323A68A9 for ; Wed, 30 Jun 2010 04:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[AWL=-0.299, 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 TBwoFmNXdui2 for ; Wed, 30 Jun 2010 04:00:30 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 9A8FB3A687E for ; Wed, 30 Jun 2010 04:00:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,511,1272841200"; d="scan'208";a="73694914" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 30 Jun 2010 12:00:41 +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 o5UB0eOQ024528; Wed, 30 Jun 2010 12:00:40 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 12:00:40 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit x-mimeole: Produced By Microsoft Exchange V6.5 Date: Wed, 30 Jun 2010 12:00:40 +0100 Message-ID: In-Reply-To: <4C2B1762.1070600@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] Call for comments to a new AUTOCONF charter proposal. thread-index: AcsYPBJW9D3tSQ1BTxGmDyYOS8H+/gABFoDg References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net> <4C2B1762.1070600@piuha.net> From: "Dearlove, Christopher (UK)" To: "Jari Arkko" X-OriginalArrivalTime: 30 Jun 2010 11:00:40.0907 (UTC) FILETIME=[7A9B61B0:01CB1843] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 11:00:31 -0000 Jari > I am hopeful though that there are clever ways to address > the biggest security issues without causing too much pain. I'm interested of course, but always sceptical. Pain-free security is elusive. > For instance, FCFS type of address and prefix allocation > in the large IPv6 address space seems amenable for some > proof-of-ownership solution. Any references? Right now I don't follow how that would work. But willing to be educated. The problem in a wireless network in particular is that a bad guy can send any pattern of bits he feels like, including any addresses he feels like using. The address(es) may be good, but he's not. That means the good guy needs to include something in a message that the bad guy can't reproduce (apart from replays, and they can be solved). It would appear that to do so the good guy must be preconfigured with something. If that something is specific to that device, couldn't the something include an address, or at least something to help the address problem? If the something is common to all devices, that's less security than I'd like (compromise one device, compromise them all). But the key point is I think that security really needs to be up front, part of the requirements/problem statement, and hence in the charter. This really is a case where security cannot be an afterthought. This is actually quite separate from the issue of whether centralised DHCP is what the WG should study. It's been noted that at least this way the WG might accomplish something, which is an issue. The question is whether it accomplishes anything really useful, given that even multiple DHCP servers are just for the future. I guess that needs people to stand up and say that if they had this, this would be what they need, and that they'd be quite happy with having to wait quite a while (a couple of years?) before any work in the WG was spent on anything decentralised. If enough people say that, that justifies the work (and provides some people who might be prevailed on to help). However I'm not standing up. -- 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 jari.arkko@piuha.net Wed Jun 30 04:18: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 2DDF33A69AA for ; Wed, 30 Jun 2010 04:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=0.801, 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 wBjceDNsMX2o for ; Wed, 30 Jun 2010 04:18:25 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 0A0ED3A68B9 for ; Wed, 30 Jun 2010 04:18:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 90D1F2CED4; Wed, 30 Jun 2010 14:18:30 +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 XRTws9acCBZ2; Wed, 30 Jun 2010 14:18:29 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id E0C1E2CC62; Wed, 30 Jun 2010 14:18:29 +0300 (EEST) Message-ID: <4C2B2805.5060307@piuha.net> Date: Wed, 30 Jun 2010 14:18:29 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net> <4C2B1762.1070600@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 11:18:26 -0000 Christopher, > Any references? Right now I don't follow how that would work. > But willing to be educated. > I'm just waving my hands and I have no references. But RFC 3971 does something similar for SLAAC. Its not the only approach, over the years people have looked at different ways in allocating mobile IPv6 home addresses as well. > But the key point is I think that security really needs to be > up front, part of the requirements/problem statement, and hence > in the charter. This really is a case where security cannot be > an afterthought. > OK. That makes sense. Jari From cjbc@it.uc3m.es Wed Jun 30 04:26: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 15B293A67D9 for ; Wed, 30 Jun 2010 04:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.482 X-Spam-Level: X-Spam-Status: No, score=-5.482 tagged_above=-999 required=5 tests=[AWL=0.217, 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 4QZmo0Rc50rp for ; Wed, 30 Jun 2010 04:26:34 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id B02E23A67DA for ; Wed, 30 Jun 2010 04:26:34 -0700 (PDT) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 3A4D26C9154; Wed, 30 Jun 2010 13:26:44 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Jari Arkko In-Reply-To: <4C2A5CFB.9070806@piuha.net> References: <1277810132.4261.9.camel@acorde.it.uc3m.es> <4C2A5CFB.9070806@piuha.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-x07tQnCl+jjtqoGWp6/i" Organization: Universidad Carlos III de Madrid Date: Wed, 30 Jun 2010 13:27:44 +0200 Message-ID: <1277897264.4261.121.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.1.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17476.006 Cc: "autoconf@ietf.org autoconf@ietf.org" Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 30 Jun 2010 11:26:36 -0000 --=-x07tQnCl+jjtqoGWp6/i Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Jari, On Tue, 2010-06-29 at 23:52 +0300, Jari Arkko wrote: > Carlos, >=20 > > I strongly believe that analyzing the > > existing solution space is a step that would help a lot in designing a > > solution. We have been working in the past on solutions surveys and > > problem space analysis: > > =20 >=20 > I think a solution analysis document would be a useful output from the= =20 > working group, particularly if we already have a good start an existing= =20 > paper or draft. Thanks for the suggestion! I think we should add it to= =20 > the charter. Thanks. >=20 > (I'm a little reluctant to tie the completion of such a document to the= =20 > start of solution work, however. Particularly if we can identify a=20 > simple first step solution such as DHCP that requires no new protocols.) Agree on that. Carlos >=20 > Jari >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-x07tQnCl+jjtqoGWp6/i 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) iEYEABECAAYFAkwrKjAACgkQNdy6TdFwT2fmvgCfbTEOykSVZY7/zf8qMC5Ke8Vd /FYAoIsdRgheLAlvV6V074ZZpwjE3W8e =uHWu -----END PGP SIGNATURE----- --=-x07tQnCl+jjtqoGWp6/i-- From cjbc@it.uc3m.es Wed Jun 30 04:29: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 93C4C3A68A7 for ; Wed, 30 Jun 2010 04:29:32 -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=0.186, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNJahUDa7C0s for ; Wed, 30 Jun 2010 04:29:31 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 788473A6878 for ; Wed, 30 Jun 2010 04:29:31 -0700 (PDT) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 3C2157FD7A7; Wed, 30 Jun 2010 13:29:41 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Jari Arkko In-Reply-To: <4C2A723E.3020806@piuha.net> References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> <4C2A723E.3020806@piuha.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-dt1D6V6iZo17lVRto051" Organization: Universidad Carlos III de Madrid Date: Wed, 30 Jun 2010 13:30:41 +0200 Message-ID: <1277897441.4261.122.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.1.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17476.006 Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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, 30 Jun 2010 11:29:32 -0000 --=-dt1D6V6iZo17lVRto051 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable On Wed, 2010-06-30 at 01:22 +0300, Jari Arkko wrote: (text skipped) > I do get that a solution with a central node (and perhaps any solution > with DHCP) does not solve all needs. Would you be happier if the > charter had four work items: >=20 > 1. Design space survey (Informational) > 2. The simple solution (such as DHCP) (PS) > 3. Limitations of the simple solution (Informational) > 4. Recharter for work on the more general solution +1. I support this approach. Thanks, Carlos >=20 > Jari >=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 --=-dt1D6V6iZo17lVRto051 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) iEYEABECAAYFAkwrKuEACgkQNdy6TdFwT2euTwCfX9Ik5F32Lb4VbsXpYlYXLcao oVEAnj/4ebttYJgriHa1izrtlAAcL6VV =U4hp -----END PGP SIGNATURE----- --=-dt1D6V6iZo17lVRto051-- From Chris.Dearlove@baesystems.com Wed Jun 30 04:40: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 3EF833A68B9 for ; Wed, 30 Jun 2010 04:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.824 X-Spam-Level: X-Spam-Status: No, score=-4.824 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xB0csegdnxgh for ; Wed, 30 Jun 2010 04:40:40 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id F1E043A67D9 for ; Wed, 30 Jun 2010 04:40:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,511,1272841200"; d="scan'208,223";a="73708833" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 30 Jun 2010 12:40:50 +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 o5UBenWH024893; Wed, 30 Jun 2010 12:40:50 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 12:40:49 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit x-mimeole: Produced By Microsoft Exchange V6.5 Date: Wed, 30 Jun 2010 12:40:49 +0100 Message-ID: In-Reply-To: <4C2B2805.5060307@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] Call for comments to a new AUTOCONF charter proposal. thread-index: AcsYRgbuEx3S39WHRcKdFCHpIboOxAAAm/Cg References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net><4C2B1762.1070600@piuha.net> <4C2B2805.5060307@piuha.net> From: "Dearlove, Christopher (UK)" To: "Jari Arkko" X-OriginalArrivalTime: 30 Jun 2010 11:40:49.0969 (UTC) FILETIME=[16851210:01CB1849] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 11:40:41 -0000 >From RFC 3971 To protect Router Discovery, SEND requires that routers be authorized to act as routers. This authorization is provisioned in both routers and hosts. Routers are given certificates from a trust anchor, and the hosts are configured with the trust anchor(s) to authorize routers. That's both significant pre-configuration, and problematic in an ad hoc network. (The rest of section 6 has a whole lot more complexity.) -- Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behalf Of Jari Arkko Sent: 30 June 2010 12:18 To: Dearlove, Christopher (UK) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. Christopher, > Any references? Right now I don't follow how that would work. > But willing to be educated. > I'm just waving my hands and I have no references. But RFC 3971 does something similar for SLAAC. Its not the only approach, over the years people have looked at different ways in allocating mobile IPv6 home addresses as well. > But the key point is I think that security really needs to be > up front, part of the requirements/problem statement, and hence > in the charter. This really is a case where security cannot be > an afterthought. > OK. That makes sense. Jari _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From dream.hjlim@gmail.com Wed Jun 30 04:44: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 3A49A3A6905 for ; Wed, 30 Jun 2010 04:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.139 X-Spam-Level: X-Spam-Status: No, score=-0.139 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 C81M4oH73J52 for ; Wed, 30 Jun 2010 04:44:23 -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 B0A6F3A68A7 for ; Wed, 30 Jun 2010 04:44:19 -0700 (PDT) Received: by vws10 with SMTP id 10so907187vws.31 for ; Wed, 30 Jun 2010 04:44:26 -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; bh=nhgW3g2c2zqoNCWgpQnyWnrPpwhbsc43qPPb+IEzacE=; b=la619m+rBeh2GeC0EUUiLs19h694dM5yFdNvNcGv8cr2RrJvh3MdeABvutYP7REs2f ftYcySI6CLvV+QQr/5wVfkwOxP6JBmhvvoJd7jEwOb6g+hG8Qt8Zs+UgDBZIg7lELZxK MbItHHZ5WDWWuD6fcguWhjwigun2qdlpSHkqE= 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; b=jS8liS2dzQZ2weBdDy1sIVqr9vANSfA1En45MQGHDaqfyKxaU1D517NTiW/Q1x4+Zn VrSkGx5JJEIywnfUGZSm0HJOodtINZR0Yvz5qEOQ7SHbWOKsa0yoyRnwsDBLLeQ/RmE9 BsfswUyCGKc5Ai2ZNh2Qc0+nXUO8hi8ky9su4= MIME-Version: 1.0 Received: by 10.220.124.211 with SMTP id v19mr2630621vcr.153.1277898265487; Wed, 30 Jun 2010 04:44:25 -0700 (PDT) Received: by 10.220.183.6 with HTTP; Wed, 30 Jun 2010 04:44:25 -0700 (PDT) In-Reply-To: <1277897441.4261.122.camel@acorde.it.uc3m.es> References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> <4C2A723E.3020806@piuha.net> <1277897441.4261.122.camel@acorde.it.uc3m.es> Date: Wed, 30 Jun 2010 20:44:25 +0900 Message-ID: From: HyungJin Lim To: ryuji.wakikawa@gmail.com Content-Type: multipart/alternative; boundary=001636ed782a2cade0048a3de04b Cc: Autoconf@ietf.org Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 11:44:24 -0000 --001636ed782a2cade0048a3de04b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, I would like to make some input to AUTOCONF WG by a related paper. The paper is as follows; *"Route Optimization in Nested NEMO: Classification, Evaluation and Analysi= s from NEMO Fringe Stub Perspective"*,* **IEEE Transactions on Mobile Computing, *, VOL. 8, NO. 11, Nov. 2009 Although this paper considers address configuration issues in NEMO viewpoint, the issues and result will be became nice input in AOTOCONF WG I think. We also need analysis about address configuration solutions like works inNEMO WG. Thanks, Hyung-Jin, Lim 2010/6/30 Carlos Jes=FAs Bernardos Cano > On Wed, 2010-06-30 at 01:22 +0300, Jari Arkko wrote: > > (text skipped) > > > I do get that a solution with a central node (and perhaps any solution > > with DHCP) does not solve all needs. Would you be happier if the > > charter had four work items: > > > > 1. Design space survey (Informational) > > 2. The simple solution (such as DHCP) (PS) > > 3. Limitations of the simple solution (Informational) > > 4. Recharter for work on the more general solution > > +1. I support this approach. > > Thanks, > > Carlos > > > > > Jari > > > > _______________________________________________ > > 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 > > --001636ed782a2cade0048a3de04b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
=A0
I would like to make some input to AUTOCONF WG by a related paper.
The paper is as follows;
"Route Optimization in Nested NEMO: Classification, Evalu= ation and Analysis from NEMO Fringe Stub Perspective", IEEE Transactions on Mobile Computin= g, , VOL. 8, NO. 11, Nov. 2009
=A0
Although this paper considers address configuration issues in=A0NEMO v= iewpoint, the issues and result will be=A0became nice input in AOTOCONF WG = I think.
=A0
We also need analysis about address configuration solutions like works= inNEMO WG.
=A0
Thanks,
Hyung-Jin, Lim

2010/6/30 Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>
On Wed, 2010-06-30 at 01:22 +030= 0, Jari Arkko wrote:

(text skipped)

> I do get that a solution with a central node (an= d perhaps any solution
> with DHCP) does not solve all needs. Would y= ou be happier if the
> charter had four work items:
>
> 1= . Design space survey (Informational)
> 2. The simple solution (such as DHCP) (PS)
> 3. Limitations of t= he simple solution (Informational)
> 4. Recharter for work on the mor= e general solution

+1. I support this approach.

Thanks,

= Carlos

>
> Jari
>
> ____________________________________________= ___
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/a= utoconf

--
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


--001636ed782a2cade0048a3de04b-- From hrogge@googlemail.com Wed Jun 30 06:14:18 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 165343A6AC9 for ; Wed, 30 Jun 2010 06:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.743, 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 0kRJ84cQqV6A for ; Wed, 30 Jun 2010 06:14:16 -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 4CE323A6830 for ; Wed, 30 Jun 2010 06:14:16 -0700 (PDT) Received: by wyb40 with SMTP id 40so826638wyb.31 for ; Wed, 30 Jun 2010 06:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=D1pOnygu1oq7v6DZB2fboc2KH+SQgFzs/oq9+d5OZrQ=; b=DBrPOQHN+K5FoWVKDTN+6WWMTU8glXHASXaQu2bgY7qAXnqTXrzRP5SD4X4E6KqbBu yZHiJyCqweQm4bF1i4K1pnDyAMV/fDV01y3H2nCDmw8eoxyAcbZJFnGJVDw784pOXVOm B1K2POVftgGiTuJXaSK6Rm/mzDndY0NfzBqHY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=GccLR6IG9681FQ+0dv88/m7vfDf/pOMy2FoKsZMqrWRYyuKdYdextNeqXG3bQGwtbP 2Ig6yOs/z+svZsvuH6nUmp8YTsfZbZDGULv+MYyfjXTYf226TTPF/dFspBuJMnh8TTtP mWcK2jz2Y9EtwC1IxLAAO/KsCJgwPS3643UzY= Received: by 10.216.172.204 with SMTP id t54mr6971258wel.44.1277903295235; Wed, 30 Jun 2010 06:08:15 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id w19sm8692568weq.44.2010.06.30.06.08.13 (version=SSLv3 cipher=RC4-MD5); Wed, 30 Jun 2010 06:08:13 -0700 (PDT) From: Henning Rogge To: autoconf@ietf.org Date: Wed, 30 Jun 2010 15:08:04 +0200 User-Agent: KMail/1.13.3 (Linux/2.6.34-gentoo-r1; KDE/4.4.4; x86_64; ; ) References: <4C2B2805.5060307@piuha.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2373826.atE9SGHUAA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201006301508.11533.hrogge@googlemail.com> Cc: "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 13:14:18 -0000 --nextPart2373826.atE9SGHUAA Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Am Mittwoch 30 Juni 2010, 13:40:49 schrieb Dearlove, Christopher (UK): > From RFC 3971 >=20 > To protect Router Discovery, SEND requires that routers be authorized > to act as routers. This authorization is provisioned in both routers > and hosts. Routers are given certificates from a trust anchor, and > the hosts are configured with the trust anchor(s) to authorize > routers. >=20 > That's both significant pre-configuration, and problematic in an ad hoc > network. (The rest of section 6 has a whole lot more complexity.) Address configuration security will need at least some kind of certificate= =20 system. Hmm, maybe a selfsigned certificate would work (nodes generate an identity = for=20 themselves, then get their address bound to this identity)... I agree we should not forget security aspects, they are very difficult to a= dd=20 on this protocol layer (similar to security for routing protocols). Henning Rogge =2D-=20 1) You can't win. 2) You can't break even. 3) You can't leave the game. =E2=80=94 The Laws of Thermodynamics, summarized --nextPart2373826.atE9SGHUAA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEABECAAYFAkwrQbsACgkQcenvcwAcHWd2twCaA90f4gdXhyvlWIr2nSklLhzp ZtgAmwQ395XOoq3M7HKvdqiGRc5jD2gT =6FI0 -----END PGP SIGNATURE----- --nextPart2373826.atE9SGHUAA-- From emmanuel.baccelli@gmail.com Wed Jun 30 06:42: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 28BC328C103 for ; Wed, 30 Jun 2010 06:42:58 -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 1qOu3WeGJECA for ; Wed, 30 Jun 2010 06:42:56 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 6096A28C0CF for ; Wed, 30 Jun 2010 06:42:55 -0700 (PDT) Received: by gxk5 with SMTP id 5so416513gxk.31 for ; Wed, 30 Jun 2010 06:43:02 -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=DgGWeH/fJ0XTxjH1YzAo6oRUm9ZCiTIL+/q78jwFMvo=; b=mCYqv3/hXWh6FnB+06svbfJUDo06d4NGtUkhr/G25wGQvnRXCD0hz5+v9Dy2JV9DQ9 JMUtHP3QL5DWRXziwAp/ZoZZcsS8UMMzIVsqNI4KYRoMnpoYIFf6+FVO1uQU9Fcw5WlM /tXLvspbixiXGHeb23uolUywGEj3kAZmUd2u8= 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=BPqMLoPhY6kTCR1LL3AfrOA+pU9IUZl/BMUnbzpljBzW8Vuix05xM0F5VbK2rA5HKx ekaXbG0eru0K2q2P6g+zMgthm/6uEgfuE2VNGbJiBwDyDvtX2NOMSSk4WZhHrrG5G2Do 0GAtislf7+NL+x9okHK3UUyxHf0xoiqlX60CQ= Received: by 10.213.10.195 with SMTP id q3mr427610ebq.59.1277905380227; Wed, 30 Jun 2010 06:43:00 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.216.173.198 with HTTP; Wed, 30 Jun 2010 06:42:40 -0700 (PDT) In-Reply-To: References: From: Emmanuel Baccelli Date: Wed, 30 Jun 2010 15:42:40 +0200 X-Google-Sender-Auth: 74gkGK2TbTaZOYh2CXdoS2g0hwY Message-ID: To: "autoconf@ietf.org autoconf@ietf.org" Content-Type: multipart/alternative; boundary=0015174c11e03ebd2f048a3f8817 Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 13:42:58 -0000 --0015174c11e03ebd2f048a3f8817 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I also support a "walk-before-run" approach. To focus on the specific case where a DHCP server is reachable somewhere in the MANET is somewhat restrictive, but to me, it makes sense to solve this particular "simple" case before tackling "hairy" cases. I want however to point out that an informational RFC documenting the observed weird characteristics of ad hoc wireless communications would be a useful companion document for the solution to be designed for AUTOCONF (as well as for other mechanisms currently being designed in other working groups, including 6lowpan, ROLL). In that respect, the draft we have worked on with Charlie is a candidate to consider: http://ietfreport.isoc.org/all-ids/draft-baccelli-multi-hop-wireless-communication-04.txt Regards, Emmanuel On Tue, Jun 29, 2010 at 6:20 AM, Ryuji Wakikawa wrote: > Hi all, > > Please find a proposal of a new AUTOCONF charter attached below. > We need to define our new charter carefully to avoid yet-another 5 years > discussion. > Jari and chairs agreed to narrow down the charter items and go straight to > solution space. > > This charter is not the final version. Please review it and provide us your > comments. > The discussion before the coming IETF is very important to set our charter > ready soon. > > Please give us your feedback before July 9th. > > thanks, > ryuji > > 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. 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. > > 2. 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 on 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 as a part of the first item; it is expected that address > uniqueness is guaranteed by the central node alone. > > Goals and Milestones: > > Dec 2010 First working group draft of the address configuration mechanism > Apr 2011 First working group draft of the prefix configuration mechanism > Sep 2011 Submission of the address configuration mechanism to the IESG for > publication as a Proposed Standard > Sep 2011 Submission of the prefix configuration mechanism to the IESG for > publication as a Proposed Standard > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > --0015174c11e03ebd2f048a3f8817 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,


I also support a "walk-befor= e-run" approach. To focus on the specific case where a DHCP server is = reachable somewhere in the MANET is somewhat restrictive, but to me, it mak= es sense to solve this particular "simple" case before tackling &= quot;hairy" cases.

I want however to point out that an informational RFC d= ocumenting the observed weird characteristics of ad hoc wireless communicat= ions would be a useful companion document for the solution to be designed f= or AUTOCONF (as well as for other mechanisms currently being designed in ot= her working groups, including 6lowpan, ROLL). In that respect, the draft we= have worked on with Charlie is a candidate to consider:


Regards,

Emmanuel





On Tue, Jun 29, 2010 at 6:20 AM, Ryuji Wakikawa = <ryuji.wakikawa@gmail.com> wrote:
Hi all,

Please find a proposal of a new AUTOCONF charter attached below.
We need to define our new charter carefully to avoid yet-another 5 years di= scussion.
Jari and chairs agreed to narrow down the charter items and go straight to = solution space.

This charter is not the final version. Please review it and provide us your= comments.
The discussion before the coming IETF is very important to set our charter = ready soon.

Please give us your feedback before July 9th.

thanks,
ryuji

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

Current Status: Active

Chairs:
Ryuji Wakikawa <ryuji.wakika= wa@gmail.com>
Thomas Clausen <T.Clausen@comp= uter.org>

Internet Area Directors:
Ralph Droms <rdroms.ietf@gmail.= com>
Jari Arkko <jari.arkko@piuha.net= >

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

Mailing Lists:
General Discussion: autoconf@ietf.org<= /a>
To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf
Archive: http://www.ietf.org/mail-archive/web/autoco= nf/current/maillist.html

Description of Working Group:

RFC 5889 presents one possible IPv6 addressing model for ad hoc nodes. In t= his model the ad hoc routers need to configure their network interface(s) w= ith addresses valid in the ad hoc network, and may configure additional pre= fixes 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. A DHCPv6-based mechanism for configuring required interface addresses fo= r the routers in the ad hoc network. This mechanism is expected to produce = addresses with properties outlined in RFC 5889. This mechanism uses the exi= sting DHCPv6 protocol unchanged, and assumes a central node that can alloca= te 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 d= eployments employ Internet gateways that can act as such a central node as = well. Future extensions such as central node election may make this mechani= sm suitable for also for stand-alone ad hoc networks.

2. 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 th= e one above, but allocates prefixes instead of addresses.

Both mechanisms should be independent on operation of any specific MANET ro= uting protocol, although may exploit information maintained by such a routi= ng protocol, if available.

The working group will adapt and/or reuse existing protocols whenever reaso= nable and possible. No new duplicate address detection mechanisms are will = be specified as a part of the first item; it is expected that address uniqu= eness is guaranteed by the central node alone.

Goals and Milestones:

Dec 2010 First working group draft of the address configuration mechanism Apr 2011 First working group draft of the prefix configuration mechanism Sep 2011 Submission of the address configuration mechanism to the IESG for = publication as a Proposed Standard
Sep 2011 Submission of the prefix configuration mechanism to the IESG for p= ublication as a Proposed Standard
_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf

--0015174c11e03ebd2f048a3f8817-- From jari.arkko@piuha.net Wed Jun 30 06:50: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 C8CE028B23E for ; Wed, 30 Jun 2010 06:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=0.769, 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 K+lPWwXY+nad for ; Wed, 30 Jun 2010 06:50:00 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id AB24F3A6A42 for ; Wed, 30 Jun 2010 06:50:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id F38D92CED7; Wed, 30 Jun 2010 16:50:10 +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 JncsBzYo+f-7; Wed, 30 Jun 2010 16:50:10 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 6C4412CC62; Wed, 30 Jun 2010 16:50:10 +0300 (EEST) Message-ID: <4C2B4B92.1010607@piuha.net> Date: Wed, 30 Jun 2010 16:50:10 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net><4C2B1762.1070600@piuha.net> <4C2B2805.5060307@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org Subject: [Autoconf] Security (Was: Re: Call for comments to a new AUTOCONF charter proposal.) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 13:50:06 -0000 Christopher, > >From RFC 3971 > > To protect Router Discovery, SEND requires that routers be authorized > to act as routers. This authorization is provisioned in both routers > and hosts. Routers are given certificates from a trust anchor, and > the hosts are configured with the trust anchor(s) to authorize > routers. > > That's both significant pre-configuration, and problematic in an ad hoc > network. (The rest of section 6 has a whole lot more complexity.) > I did not mean to imply that SEND would directly be a good fit for your problem. In fact, I was not thinking of SEND's router authorization part at all. I was thinking of SEND host's ability to create addresses securely and defend them from other hosts, all without any pre-configuration, or reliance on routers. Jari From Chris.Dearlove@baesystems.com Wed Jun 30 07:13: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 EE4043A6A1F for ; Wed, 30 Jun 2010 07:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.594 X-Spam-Level: X-Spam-Status: No, score=-5.594 tagged_above=-999 required=5 tests=[AWL=1.005, 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 nmfEks6zIEwo for ; Wed, 30 Jun 2010 07:13:35 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id EBA4C3A6993 for ; Wed, 30 Jun 2010 07:13:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,513,1272841200"; d="scan'208";a="73761451" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 30 Jun 2010 15:13:45 +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 o5UEDiwF024051; Wed, 30 Jun 2010 15:13:45 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 15:13:45 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit x-mimeole: Produced By Microsoft Exchange V6.5 Date: Wed, 30 Jun 2010 15:13:45 +0100 Message-ID: In-Reply-To: <4C2B4B92.1010607@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] Security (Was: Re: Call for comments to a new AUTOCONF charter proposal.) thread-index: AcsYWze7uMa+rxUSSteGELqK67atPgAAoecQ References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net><4C2B1762.1070600@piuha.net><4C2B2805.5060307@piuha.net> <4C2B4B92.1010607@piuha.net> From: "Dearlove, Christopher (UK)" To: "Jari Arkko" X-OriginalArrivalTime: 30 Jun 2010 14:13:45.0083 (UTC) FILETIME=[73505CB0:01CB185E] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Security (Was: Re: Call for comments to a new AUTOCONF charter proposal.) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 14:13:37 -0000 Jari > I did not mean to imply that SEND would directly be a good fit for your > problem. In fact, I was not thinking of SEND's router authorization part > at all. I was thinking of SEND host's ability to create addresses > securely and defend them from other hosts, all without any > pre-configuration, or reliance on routers. But one thing that the almost interminable autoconf discussions have made clear is that ad hoc nodes are routers, and if a SEND-like mechanism requires much of its routers, it would require much of the routers in an ad hoc network, i.e. all the nodes. For security we are also, unfortunately, defending against Machiavelli, not just against Murphy. If you pick an address, and I'm a bad guy, observing you using the address is a reason for me to use that address, not a reason to avoid it. ******************************************************************** 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 sratliff@cisco.com Wed Jun 30 07:21: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 F03B53A68E0 for ; Wed, 30 Jun 2010 07:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 930NKyB0pZTH for ; Wed, 30 Jun 2010 07:21:22 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 72CCD28C10D for ; Wed, 30 Jun 2010 07:20:44 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG7vKkxAZnwM/2dsb2JhbACfW3GmNJokhSUEiCM X-IronPort-AV: E=Sophos;i="4.53,513,1272844800"; d="scan'208";a="127189298" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 30 Jun 2010 14:19:39 +0000 Received: from dhcp-64-102-54-238.cisco.com (dhcp-64-102-54-238.cisco.com [64.102.54.238]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5UEJdDi018962; Wed, 30 Jun 2010 14:19:39 GMT Message-Id: <62FBD022-C7BF-4934-B72B-A90065995805@cisco.com> From: Stan Ratliff To: Zach Shelby 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: Wed, 30 Jun 2010 10:19:39 -0400 References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> <4C2A723E.3020806@piuha.net> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 14:21:24 -0000 On Jun 30, 2010, at 2:41 AM, Zach Shelby wrote: > > On Jun 30, 2010, at 1:22 AM, Jari Arkko wrote: > >> I do get that a solution with a central node (and perhaps any >> solution with DHCP) does not solve all needs. Would you be happier >> if the charter had four work items: >> >> 1. Design space survey (Informational) >> 2. The simple solution (such as DHCP) (PS) >> 3. Limitations of the simple solution (Informational) >> 4. Recharter for work on the more general solution > > > +1. I support this approach. As Ryuji mentioned, we are almost > finished with work in 6LoWPAN on optimizing ND so that it works in > such a low-power and lossy network. There the approach is to enable > autoconfiguration with either DHCP or using a multihop DAD > technique. Autoconf might be able to extend or reference that work > in item 2. above and consider both DHCP and ND as parts of a simple > solution. For now I think it is enough to say in the charter that > DHCP and ND mechanisms will be applied (with minimal extensions) for > the simple solution. > +2. I can support this approach as well. Regards, Stan From jari.arkko@piuha.net Wed Jun 30 08:21: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 BCBFD3A6A15 for ; Wed, 30 Jun 2010 08:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.740, 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 CCC0JrUGkVY7 for ; Wed, 30 Jun 2010 08:21:02 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 2E8D13A684A for ; Wed, 30 Jun 2010 08:21:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7E0B72CED4; Wed, 30 Jun 2010 18:21:11 +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 PSc8Wtldv7Ej; Wed, 30 Jun 2010 18:21:09 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 991642CC62; Wed, 30 Jun 2010 18:21:09 +0300 (EEST) Message-ID: <4C2B60E4.5070203@piuha.net> Date: Wed, 30 Jun 2010 18:21:08 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net><4C2B1762.1070600@piuha.net><4C2B2805.5060307@piuha.net> <4C2B4B92.1010607@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Security (Was: Re: Call for comments to a new AUTOCONF charter proposal.) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 15:21:07 -0000 Christopher, > But one thing that the almost interminable autoconf discussions have > made clear is that ad hoc nodes are routers, and if a SEND-like > mechanism requires much of its routers, it would require much of the > routers in an ad hoc network, i.e. all the nodes. > Please do not take the SEND model literally here. I am trying to suggest that some ideas similar to those used in other parts of SEND might be useful for protecting address autoconfiguration, which is what this WG is about. Other parts of SEND do not IMHO appear suitable. But again, I'm just handwaving so I could be wrong. > For security we are also, unfortunately, defending against Machiavelli, > not just against Murphy. If you pick an address, and I'm a bad guy, > observing you using the address is a reason for me to use that address, > not a reason to avoid it. > Right. And that is precisely the type of an attack that the address configuration security mechanisms could protect against. Of course, in ad hoc networking the full scope of security problems is wider. Presumably there are Byzantine security issues, for instance. But technically those are part of the routing protocol. I'm not sure what MANET or ROLL has done in this space, for instance. Do you know? I do not believe these are for this working group, however. Anyway, I think we've debated long enough about this particular topic. If I believe there are clever ways to deal with the address autoconfiguration security problem I need to write it up and then we can have a more in-depth discussion. Lets do that later. Jari From Chris.Dearlove@baesystems.com Wed Jun 30 09:13: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 4277C3A699F for ; Wed, 30 Jun 2010 09:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.678 X-Spam-Level: X-Spam-Status: No, score=-5.678 tagged_above=-999 required=5 tests=[AWL=0.921, 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 hswEXLrTVBl9 for ; Wed, 30 Jun 2010 09:13:57 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id A64A23A6A1D for ; Wed, 30 Jun 2010 09:13:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,513,1272841200"; d="scan'208";a="73798340" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 30 Jun 2010 17:14:07 +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 o5UGE6kH022968; Wed, 30 Jun 2010 17:14:07 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 17:14:07 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit x-mimeole: Produced By Microsoft Exchange V6.5 Date: Wed, 30 Jun 2010 17:14:08 +0100 Message-ID: In-Reply-To: <4C2B60E4.5070203@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Autoconf] Security (Was: Re: Call for comments to a new AUTOCONF charter proposal.) thread-index: AcsYZ+uZYh3HuhGaSX2Fc2C0bz7KOwABn11Q References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net><4C2B1762.1070600@piuha.net><4C2B2805.5060307@piuha.net><4C2B4B92.1010607@piuha.net> <4C2B60E4.5070203@piuha.net> From: "Dearlove, Christopher (UK)" To: "Jari Arkko" X-OriginalArrivalTime: 30 Jun 2010 16:14:07.0083 (UTC) FILETIME=[43F61BB0:01CB186F] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Security (Was: Re: Call for comments to a new AUTOCONF charter proposal.) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 16:13:58 -0000 > Of course, in ad hoc networking the full scope of security problems is > wider. Presumably there are Byzantine security issues, for instance. But > technically those are part of the routing protocol. If having an address is a pre-requisite of the routing protocol, then leaving everything to the routing protocol is too late. > I'm not sure what > MANET or ROLL has done in this space, for instance. Do you know? I do > not believe these are for this working group, however. MANET has just agreed to accept work on specifying authentication TLVs for the packet/message format RFC 5444 (which itself outlines the concept). That's the main work, i.e. it is limited. > Anyway, I think we've debated long enough about this particular topic. If the conclusion is that the issues of address configuration and security configuration are intertwined (really both are also part of the wider issue of identity) and that therefore this needs to be considered by the WG and should be mentioned in the charter, then OK. ******************************************************************** 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 hrogge@googlemail.com Wed Jun 30 10:01: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 62DC63A6893 for ; Wed, 30 Jun 2010 10:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.557, 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 gDuBduBtu9tq for ; Wed, 30 Jun 2010 10:01:52 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id A26233A67A3 for ; Wed, 30 Jun 2010 10:01:51 -0700 (PDT) Received: by fxm1 with SMTP id 1so725578fxm.31 for ; Wed, 30 Jun 2010 10:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=KbqI0VZkpaKuQl+a6mf4zQK1Eay6HjLfpZ3LiEVm0gI=; b=oNG7xlZeH7Z51Rit/Bta40Rm1Qf1rAxb8fcYXGQ9znUpEM/0RBfvnq7bFtQcsuFEmr QwQ5dCMIUzn8/fOoNDIO+7Bfn/nk5esbSu6vDabqo6qlg7RSmwpquwo51bzjEPCpuCjg nK3xgnxjyzXkeEZLmfWzo3STglTsOg0nNQtNU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=Y7khHPy16YvKS3TXB9hoC6cmiAo7X1ayyvbG2n5PhIotXhuuG4lP7HF9TN24EGwFR9 IJUIcbp9yHWHa5DJ7HS/RKMvv41OTeLTSa4RpfbD3dT4a0p0c4lOl3mUjOreHxn99R70 6SLYYG6+AZmZBP7Im3qo7X12cQYMIQqkuJD3s= Received: by 10.204.46.95 with SMTP id i31mr6417114bkf.17.1277917320679; Wed, 30 Jun 2010 10:02:00 -0700 (PDT) Received: from core2.localnet ([87.79.93.195]) by mx.google.com with ESMTPS id l70sm9396952weq.0.2010.06.30.10.01.58 (version=SSLv3 cipher=RC4-MD5); Wed, 30 Jun 2010 10:01:59 -0700 (PDT) From: Henning Rogge To: autoconf@ietf.org Date: Wed, 30 Jun 2010 19:01:50 +0200 User-Agent: KMail/1.13.3 (Linux/2.6.34-gentoo-r1; KDE/4.4.4; x86_64; ; ) References: <4C2B60E4.5070203@piuha.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1725208.iHE7Og4INh"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201006301901.55567.hrogge@googlemail.com> Cc: "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Security (Was: Re: Call for comments to a new AUTOCONF charter proposal.) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 17:01:53 -0000 --nextPart1725208.iHE7Og4INh Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Am Mittwoch 30 Juni 2010, 18:14:08 schrieb Dearlove, Christopher (UK): > If the conclusion is that the issues of address configuration and > security configuration are intertwined (really both are also part > of the wider issue of identity) and that therefore this needs to be > considered by the WG and should be mentioned in the charter, then OK. I agree to this. The identity of a router is a very important part of a security concept of = a=20 MANET/mesh. If the network is compromised during the address configuration,= it=20 might be difficult or impossible to secure it later. Henning Rogge =2D-=20 1) You can't win. 2) You can't break even. 3) You can't leave the game. =E2=80=94 The Laws of Thermodynamics, summarized --nextPart1725208.iHE7Og4INh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEABECAAYFAkwreIMACgkQcenvcwAcHWc7ugCffgf0dhWRr0AC2IshPqqM44yi 3GsAnA2ii4e0goLr0jMpSRVCiSWfm9sL =+xQh -----END PGP SIGNATURE----- --nextPart1725208.iHE7Og4INh-- From dream.hjlim@gmail.com Wed Jun 30 10:19: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 944873A6A47 for ; Wed, 30 Jun 2010 10:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=1.229, 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 2ol1s3pljq+R for ; Wed, 30 Jun 2010 10:19:52 -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 70E983A67AF for ; Wed, 30 Jun 2010 10:19:52 -0700 (PDT) Received: by vws10 with SMTP id 10so1260968vws.31 for ; Wed, 30 Jun 2010 10:20:00 -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:cc:content-type; bh=k2JnTKM0g0tTp16H0P2QT1tmC2mBcHL9IEsJzSDJ8/o=; b=X1q0/ceeYhQ6BN2dZk1g0kbyuvltX+KiLpZbXtmV+UtjmPnxWzazT4tep9IkBUXQ80 C96eRxbttDV1Lr4UlyidK3nUN85DisF7Qd0JXqGrE531q9Ilou+WjgtvdBD0ks6ecGxj O7rd1YC8uj15vhvu7p6UFH0Vg9H2+cvLbaQxw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=jXZB7p1VymlwhH654NT+EAp8OcXyxRO41ZG/ps2SnrzTqQVUomOiwNH8DMBRvz2oYW Ce+67ObKieglFp4qhdOOaA3QxGoYY+V+RdPff6YiS5Qfpi850Sy1miILWU0hl6ikQiHx a3xu9zSVACHtjDcKfYJJNtSjz/GAw8pID2ipQ= MIME-Version: 1.0 Received: by 10.220.168.213 with SMTP id v21mr3336708vcy.134.1277918400710; Wed, 30 Jun 2010 10:20:00 -0700 (PDT) Received: by 10.220.183.6 with HTTP; Wed, 30 Jun 2010 10:20:00 -0700 (PDT) Date: Thu, 1 Jul 2010 02:20:00 +0900 Message-ID: From: HyungJin Lim To: jari.arkko@piuha.net Content-Type: multipart/alternative; boundary=0016e65ae5a0538a6d048a429061 Cc: autoconf@ietf.org Subject: [Autoconf] Security (Was: Re: Call for comments to a new AUTOCONF charter proposal.) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 17:19:53 -0000 --0016e65ae5a0538a6d048a429061 Content-Type: text/plain; charset=ISO-8859-1 Hi all, In relation to security aspects, AUTOCONF WG's need to perceive fundamental problem I think. First, we should consider performance as well as security problem. MANET can form Internet connectivity as well as stand alone network. These situation has different requirement in view point of topology. This is not cryptography problem. We know AAA(authentication, authorization, accounting) protocol and standard. Standardized AAA basically is developed for host device. So. frist, we should identify requirements that should resolve issues in AUTOCONF WG. Address configuration issue and Security is different problem and issues I think. Thanks. Hyung-Jin, Lim --0016e65ae5a0538a6d048a429061 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
=A0
In relation to security aspects, AUTOCONF WG's need to perceive fu= ndamental problem I think.
First, we should consider performance=A0as well as=A0security problem.=
=A0
MANET can form Internet connectivity as well as stand alone network.
These=A0situation has different requirement in view point of topology.=
=A0
This is not cryptography problem.
We know AAA(authentication, authorization, accounting) protocol and st= andard. Standardized AAA basically is=A0developed for host device.
=A0
So. frist, we should identify requirements that should resolve issues = in=A0AUTOCONF WG.
=A0
Address configuration=A0issue and Security is different problem and=A0= issues I think.
=A0
=A0
Thanks.
=A0
Hyung-Jin, Lim
=A0
--0016e65ae5a0538a6d048a429061-- From charles.perkins@earthlink.net Wed Jun 30 10: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 1F89E3A6A6E for ; Wed, 30 Jun 2010 10:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.14 X-Spam-Level: X-Spam-Status: No, score=0.14 tagged_above=-999 required=5 tests=[AWL=0.139, 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 owQ6czIFLK8j for ; Wed, 30 Jun 2010 10:34:16 -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 414C73A6843 for ; Wed, 30 Jun 2010 10:34:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=h+yF7vf/XUA7ZowQybFzikSe3ODX14fFYlvKDjO00+LvEdvPvj8omJzHqyvNA2A5; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.153]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OU1B3-0003jU-Te; Wed, 30 Jun 2010 13:34:27 -0400 Message-ID: <4C2B801B.1070004@earthlink.net> Date: Wed, 30 Jun 2010 10: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.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Jari Arkko , autoconf@ietf.org References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de> <4C2A723E.3020806@piuha.net> In-Reply-To: <4C2A723E.3020806@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52631afed52bb3bc3a169f94bf90974906350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 17:34:21 -0000 Hello folks, I find the proposed charter extremely disappointing. Comments below. > Just so that you know who to blame :-) I was the one who asked Thomas > and Ryuji to consider a simple solution with no new protocols. If there's anything I've learned while working on ad hoc networks, it was that existing protocols just plain don't do the job. > But back to your feedback on the charter. I would like to respond in two > ways. First, I am by no means wedded to the particular solution details. > Do you have a suggested edit? I think we should consider solutions that have a chance to work in general ad hoc networks, and in my view DHCP is quite unlikely to do so in any scalable way, for reasons that we've discussed on the list seemingly dozens of times. > But, second, I will defend the idea that the working group needs to > learn to walk before running. This analogy, if accepted as accurate, pretty much ends the discussion. But I do not think it is accurate. We've had solutions on the table for years now. These solutions are known to work. There are multiple good ideas, based on sound understanding of the problem, then built and checked. > We've been through a five year exercise > just to define the addressing model. When we attempted to define the > architecture as a general model we realized that it was hard, and > explaining the model to non ad hoc networking experts was even harder. The way I see it, we spent five years trying to stop treating everything like an Ethernet. I wouldn't have wasted so much time on it, except that I thought the result would be that we could then specify an address autoconfiguration protocol that didn't pretend everything was an Ethernet. Maybe I was wrong, too wildly optimistic, in that regard. > But when we described a concrete addressing model that some deployments > are using we did finally get an RFC. Or almost have, at least. I would > like to continue on the same path. I'm told that there are deployed > autoconfiguration mechanisms and that some level of support is doable > even with existing protocols. The addressing model as recently completed does support a decentralized approach. > I would like to avoid repeating the experience we had earlier on trying > to describe the autoconf problem. Didn't we finish doing that by now? The next step would be to specify an autoconfiguration protocol that could work in ad hoc networks. We have several candidates, and we could compare them for applicability, performance, etc. > .... But I do not look forward to more years of discussion of > complex routing protocol/neighbor discovery extensions and a constant > stream of questions from the outsiders about why ND or DHCP cannot do > the job. Ahh... I guess you mean that the outsiders are now controlling the destiny of [autoconf] because they can soak up so much time asking about why we aren't interested in programming virtual Ethernets. > I do get that a solution with a central node (and perhaps any solution > with DHCP) does not solve all needs. Would you be happier if the charter > had four work items: > > 1. Design space survey (Informational) > 2. The simple solution (such as DHCP) (PS) > 3. Limitations of the simple solution (Informational) > 4. Recharter for work on the more general solution I'd be happy if it were possible for [autoconf] to be allowed to consider the excellent body of work that was seen already years ago -- the same body of work that motivated me and others to create and spend a lot of time over the last years and years. If I had known at the outside that the answers were "DHCP" and "avoid constant questions from outsiders", I would have had a lot more time at my disposal for other things. Regards, Charlie P. From charles.perkins@earthlink.net Wed Jun 30 10:38: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 97DB13A6A18 for ; Wed, 30 Jun 2010 10:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.188 X-Spam-Level: X-Spam-Status: No, score=-1.188 tagged_above=-999 required=5 tests=[AWL=1.411, 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 rVVWE15QrH9U for ; Wed, 30 Jun 2010 10:38:28 -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 72D4D3A6A71 for ; Wed, 30 Jun 2010 10:38:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=VrA9qDpuc2EsiVA7admVl7QpXDkQlMxoLofe9DYKWp2FETy+iN3EaQRNqJDoApqc; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.153]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OU1F9-0007A6-00; Wed, 30 Jun 2010 13:38:39 -0400 Message-ID: <4C2B811B.8040804@earthlink.net> Date: Wed, 30 Jun 2010 10:38:35 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Jari Arkko , autoconf@ietf.org References: <201006290803.34192.henning.rogge@fkie.fraunhofer.de><4C2A723E.3020806@piuha.net> <4C2B801B.1070004@earthlink.net> In-Reply-To: <4C2B801B.1070004@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f522eeace3cd0b54c9f2ec68440375bba70350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 17:38:29 -0000 Hello folks, Typo in my previous message (sigh)... On 6/30/2010 10:34 AM, Charles E. Perkins wrote: > If I had known at the outside that the answers were "outside" --> "outset". Regards, Charlie P. From hrogge@googlemail.com Wed Jun 30 12:16: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 8DAAE3A687B for ; Wed, 30 Jun 2010 12:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.446, 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 fUao11zdUyHN for ; Wed, 30 Jun 2010 12:16:29 -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 96C5F3A68FD for ; Wed, 30 Jun 2010 12:16:28 -0700 (PDT) Received: by wyb40 with SMTP id 40so1169220wyb.31 for ; Wed, 30 Jun 2010 12:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=sn5Sa7i9Kt7r2e2qxtN7l/fm89ehStIEUNwxAgRRv+I=; b=kq0u3WuXxc/daHagQukDVGR/0czZvkbPQGNQC1Ddl0H/z3A25KoHBVa6HmQ489DAzm L1IZfes/VUZylwpiARlBJbHWS008dw1twykh199sg5AsIZ8eJnV7KAjpAvbIV4krqXVm +NlUH+kTPnV5rr27XYZTmh1sDEIM7NjTgNNRY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=M4GbrISzywXfaLTBIMnMKvHMC6RP9dTUdEjK2ag/4hOeFZQpZFHDKjEq2dZsnFkEiK R72Z35y7yO6CXH0KtRdaGocYd6LWccHvALZqzSerZAcCwcG8gajv4zaFj7nlO7+IBaxJ I1BuP0eIjpoJLwhoc5MR252lD0Am9TjOPnDYs= Received: by 10.216.160.132 with SMTP id u4mr7128012wek.19.1277925396325; Wed, 30 Jun 2010 12:16:36 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 39sm7950373wet.43.2010.06.30.12.16.35 (version=SSLv3 cipher=RC4-MD5); Wed, 30 Jun 2010 12:16:35 -0700 (PDT) From: Henning Rogge To: Juliusz Chroboczek Date: Wed, 30 Jun 2010 21:16:29 +0200 User-Agent: KMail/1.13.3 (Linux/2.6.34-gentoo-r1; KDE/4.4.4; x86_64; ; ) References: <7ir5jojq6z.fsf@lanthane.pps.jussieu.fr> In-Reply-To: <7ir5jojq6z.fsf@lanthane.pps.jussieu.fr> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2276836.oNuOKaiAhj"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201006302116.34149.hrogge@googlemail.com> Cc: autoconf@ietf.org, Thomas Clausen Subject: Re: [Autoconf] The Ad-Hoc Configuration Protocol (AHCP) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 30 Jun 2010 19:16:30 -0000 --nextPart2276836.oNuOKaiAhj Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Am Mittwoch 30 Juni 2010, 21:06:12 schrieb Juliusz Chroboczek: > Dear Group, >=20 > I'd like to remind you of the existence of The Ad-Hoc Configuration > Protocol, a protocol roughly based on DHCPv6 but desigigned for Mesh > Networks. >=20 > You will find a description of the protocol and a sample implementation > of AHCP on >=20 > http://www.pps.jussieu.fr/~jch/software/ahcp/ >=20 > This page links in particular to a draft document describing the > protocol, >=20 > http://www.pps.jussieu.fr/~jch/software/ahcp/draft-chroboczek-ahcp-00.t= xt > =20 > http://www.pps.jussieu.fr/~jch/software/ahcp/draft-chroboczek-ahcp-00.html I asked Julius to post a few information about his AHCP. Maybe it would be= =20 better to start with something which is working on a MANET instead of a=20 complete new design based on DHCPv6. We used AHCP in our testbed at the CCC Decemberin Berlin last year, which i= s a=20 really nasty enviroment for MANETs (we needed 4-5 hops for the 25 meters=20 between the conference room and our uplink in the hacking center). Henning Rogge =2D-=20 1) You can't win. 2) You can't break even. 3) You can't leave the game. =E2=80=94 The Laws of Thermodynamics, summarized --nextPart2276836.oNuOKaiAhj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEABECAAYFAkwrmBIACgkQcenvcwAcHWf4MwCdHYM3pn9uleAoj+N3jGJTDAyO AR4An031/VWp/+HxOmO/a+2KOzif3gcC =YrZk -----END PGP SIGNATURE----- --nextPart2276836.oNuOKaiAhj--