From ryuji.wakikawa@gmail.com Tue Nov 9 23:25:38 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56E103A6A75 for ; Tue, 9 Nov 2010 23:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zm5BgT8q0BIl for ; Tue, 9 Nov 2010 23:25:36 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 9850D3A6A36 for ; Tue, 9 Nov 2010 23:24:45 -0800 (PST) Received: by ywp6 with SMTP id 6so174467ywp.31 for ; Tue, 09 Nov 2010 23:25:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=GTfqByy3TZpeA1yJLMbl56w18GbWI9uuxs7Q2q5MB0s=; b=lNsynk4jRpEQheyfiMY9Prl1Yx2piIT+c0T3TUGixAB8Cbyvf3OxJCGna9iBRiDS8t ETFji4W5t8DCCOOZD1wXz+vMR6m2B+jhJ78Jh8/t2KQaRMlg94JNmq57XLqE6AO/rVWF lp+qcVP2MGoe6oOcRrc1ld6zYtxo42q+gx4cU= 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=o7JB+PgLM0fOpiRZKUjeaVl9nnirR0QwPLYMosarOMI21msrDkRdEPXzPj7p4CmdcU w59jb2OT3cKA063DCsSDppJy9kzwfi2XEz5JyDhD1Vbd5aVdq+wclRDlxCaLo/PMCScA G8g4plu1VFPO8/aVjE2sR5ZhsNlFI0zUgJvwU= Received: by 10.100.48.20 with SMTP id v20mr4539338anv.152.1289373911559; Tue, 09 Nov 2010 23:25:11 -0800 (PST) Received: from dhcp-81f0.meeting.ietf.org (dhcp-81f0.meeting.ietf.org [130.129.129.240]) by mx.google.com with ESMTPS id w3sm481947anw.25.2010.11.09.23.25.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Nov 2010 23:25:10 -0800 (PST) From: Ryuji Wakikawa Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Nov 2010 15:25:05 +0800 Message-Id: <86A2091E-A92B-4485-A7F8-7A9829A39073@gmail.com> To: "Autoconf autoconf@ietf.org" Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 07:25:38 -0000 Hi all, Here is the last charter sent to IESG.=20 regards, ryuji Ad-Hoc Network Autoconfiguration (autoconf) ------------------------------------------- Current Status: Active Chairs: Ryuji Wakikawa X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A92D3A6A18 for ; Wed, 10 Nov 2010 02:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMqTolkF3FG9 for ; Wed, 10 Nov 2010 02:07:17 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 01AF13A6A81 for ; Wed, 10 Nov 2010 02:07:16 -0800 (PST) Received: by yxe1 with SMTP id 1so191079yxe.31 for ; Wed, 10 Nov 2010 02:07:43 -0800 (PST) Received: by 10.100.124.5 with SMTP id w5mr4765067anc.84.1289383662533; Wed, 10 Nov 2010 02:07:42 -0800 (PST) Received: from dhcp-61f2.meeting.ietf.org (dhcp-61f2.meeting.ietf.org [130.129.97.242]) by mx.google.com with ESMTPS id w3sm664814anw.25.2010.11.10.02.07.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Nov 2010 02:07:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <86A2091E-A92B-4485-A7F8-7A9829A39073@gmail.com> Date: Wed, 10 Nov 2010 11:07:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9BA62AD8-1F6D-4B6E-A905-77B031115557@inf-net.nl> References: <86A2091E-A92B-4485-A7F8-7A9829A39073@gmail.com> To: Ryuji Wakikawa X-Mailer: Apple Mail (2.1081) Cc: "Autoconf autoconf@ietf.org" Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 10:07:18 -0000 Hi Ryuji, I am happy to repeat my comments. None is picked up, is it? Regards, Teco Op 24 aug 2010, om 22:16 heeft Teco Boot het volgende geschreven: > I am happy with the dual approach. >=20 > Some remarks on the draft text: >=20 > It says that "other nodes will relay messages to the central node". > On the list is was discussed the relay function could be co-located on = the node itself. > Is such a method rejected? >=20 > Typo: No new duplicate address detection mechanisms are will be = specified > "are" or "will be". This is duplicate already :-) >=20 > I have problems with: >>> it is expected that address uniqueness is >>> guaranteed by the central node alone. > 1) DHCPv6 doesn't work this way. Addresses are managed by the = requesting node unique token, the DUID. > 2) I have seen many DHCP implementations that use (link-local) probing = for duplicate detection. This is for some guarantee for non-duplicates = after a reboot and NV-storage. Quite often, CPE devices don't have = volatile storage. > 3) RFC 3315 specifies usage of DAD by the clients (18.1.8), e.g. for = conflict resolving as result of point 2 above.=20 > So the expectation is built on quicksand. > Still, I think it is the right approach. Maybe just remove this = sentence? > =20 >=20 Op 10 nov 2010, om 08:25 heeft Ryuji Wakikawa het volgende geschreven: > Hi all, >=20 > Here is the last charter sent to IESG.=20 >=20 > regards, > ryuji >=20 >=20 >=20 > Ad-Hoc Network Autoconfiguration (autoconf) > ------------------------------------------- >=20 > Current Status: Active >=20 > Chairs: > Ryuji Wakikawa Thomas Clausen =20 > Internet Area Directors: > Ralph Droms Jari Arkko =20 > Internet Area Advisor: > Jari Arkko =20 > Mailing Lists: > General Discussion: autoconf@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf > Archive: = http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html >=20 > Description of Working Group: >=20 > RFC 5889 presents one possible IPv6 addressing model for ad hoc > nodes. In this model the ad hoc routers need to configure their > network interface(s) with addresses valid in the ad hoc network, and > may configure additional prefixes for use by attached nodes. >=20 > After completing the work on RFC 5889, the main purpose of the > AUTOCONF WG is to standardize how existing IPv6 address configuration > tools can be used for address configuration. >=20 > 1. DHCPv6 operation over MANET, including: >=20 > - A DHCPv6-based mechanism for configuring required interface > addresses for the routers in the ad hoc network. This mechanism > is expected to produce addresses with properties outlined in RFC > 5889. This mechanism uses the existing DHCPv6 protocol unchanged, > and assumes a central node that can allocate addresses on a > first-come-first-served basis. Other nodes in the ad hoc network > will relay messages to the central node in order to help a new > node get an address for itself. This mechanism is only suitable > for deployments were a central node can be set up. It should be > noted that many existing deployments employ Internet gateways > that can act as such a central node as well. Future extensions > such as central node election may make this mechanism suitable > for also for stand-alone ad hoc networks. >=20 > - A DHCPv6-based mechanism for delegating a prefix(es) to each > router for use by applications running on the routers themselves, > or for configuration of attached hosts/networks. This mechanism > works in a similar manner to the one above, but allocates > prefixes instead of addresses. >=20 > Both mechanisms should be independent from operation of any specific > MANET routing protocol, although may exploit information maintained by > such a routing protocol, if available. >=20 > The working group will adapt and/or reuse existing protocols whenever > reasonable and possible. No new duplicate address detection mechanisms > are will be specified; it is expected that address uniqueness is > guaranteed by the central node alone. >=20 > 2. Analysis of Problem Space for distributed address configuration and > service discovery. >=20 > The working group plans to establish design teams for rapidly = advancing > towards initial submissions for these two work items. >=20 > Goals and Milestones: >=20 > - Jan 2011 First working group draft of the "DHCPv6 operation over = MANET" > - Jan 2011 First working group draft of the "Analysis of Problem = Space" > -Sep 2011 Submission of the "DHCPv6 operation over MANET" to the IESG = for publication as BCP > -Sep 2011 Submission of the "Analysis of Problem Space" the IESG for = publication as Informational RFC > -Sep 2011 Rechartering or Closing WG >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From teco@inf-net.nl Mon Nov 29 13:29: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 E61923A6C35 for ; Mon, 29 Nov 2010 13:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+inF9v-T-Uw for ; Mon, 29 Nov 2010 13:29:14 -0800 (PST) Received: from mail-wy0-f194.google.com (mail-wy0-f194.google.com [74.125.82.194]) by core3.amsl.com (Postfix) with ESMTP id 5721A3A6A6E for ; Mon, 29 Nov 2010 13:29:14 -0800 (PST) Received: by wyb32 with SMTP id 32so2094822wyb.1 for ; Mon, 29 Nov 2010 13:30:23 -0800 (PST) Received: by 10.227.142.197 with SMTP id r5mr6670254wbu.197.1291066222792; Mon, 29 Nov 2010 13:30:22 -0800 (PST) Received: from [192.168.2.196] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id 11sm3812979wbi.0.2010.11.29.13.30.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 29 Nov 2010 13:30:22 -0800 (PST) From: Teco Boot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 29 Nov 2010 22:30:19 +0100 References: <20101129212013.184B53A6BDB@core3.amsl.com> To: "Autoconf autoconf@ietf.org" Message-Id: Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [Autoconf] draft-boot-autoconf-support4hosts X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 21:29:17 -0000 Feel free to comment on a draft I just submitted. http://www.ietf.org/id/draft-boot-autoconf-support4hosts-00.txt Teco. > Abstract: > This document describes how hosts using IPv6 Stateless Address > Autoconfiguration can be used in a MANET, without a need for any > change, neither in functioning of Neighbor Discovery nor in MANET > protocols. In addition, legacy hosts nor other parts of the network > are faced any deviation on the IPv6 Addressing architecture. From wwwrun@core3.amsl.com Tue Nov 30 09:42:57 2010 Return-Path: X-Original-To: autoconf@ietf.org Delivered-To: autoconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 9343928C0D9; Tue, 30 Nov 2010 09:42:57 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20101130174257.9343928C0D9@core3.amsl.com> Date: Tue, 30 Nov 2010 09:42:57 -0800 (PST) Cc: autoconf@ietf.org, T.Clausen@computer.org Subject: [Autoconf] WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 17:42:57 -0000 A modified charter has been submitted for the Ad-Hoc Network Autoconfiguration (autoconf) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, December 7, 2010. Ad-Hoc Network Autoconfiguration (autoconf) ------------------------------------------- Last modified: 2010-11-30 Current Status: Active Chairs: Ryuji Wakikawa Thomas Clausen Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: autoconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf Archive: http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html Description of Working Group: RFC 5889 presents one possible IPv6 addressing model for ad hoc nodes. In this model the ad hoc routers need to configure their network interface(s) with addresses valid in the ad hoc network, and may configure additional prefixes for use by attached nodes. After completing the work on RFC 5889, the main purpose of the AUTOCONF WG is to standardize how existing IPv6 address configuration tools can be used for address configuration. 1. DHCPv6 operation over MANET, including: - A DHCPv6-based mechanism for configuring required interface addresses for the routers in the ad hoc network. This mechanism is expected to produce addresses with properties outlined in RFC 5889. This mechanism uses the existing DHCPv6 protocol unchanged, and assumes a central node that can allocate addresses on a first-come-first-served basis. Other nodes in the ad hoc network will relay messages to the central node in order to help a new node get an address for itself. This mechanism is only suitable for deployments were a central node can be set up. It should be noted that many existing deployments employ Internet gateways that can act as such a central node as well. Future extensions such as central node election may make this mechanism suitable for also for stand-alone ad hoc networks. - A DHCPv6-based mechanism for delegating a prefix(es) to each router for use by applications running on the routers themselves, or for configuration of attached hosts/networks. This mechanism works in a similar manner to the one above, but allocates prefixes instead of addresses. Both mechanisms should be independent from operation of any specific MANET routing protocol, although may exploit information maintained by such a routing protocol, if available. The working group will adapt and/or reuse existing protocols whenever reasonable and possible. No new duplicate address detection mechanisms are will be specified; it is expected that address uniqueness is guaranteed by the central node alone. 2. Analysis of Problem Space for distributed address configuration and service discovery. This analysis is necessary in order to understand what type of distributed solution(s) can be standardized. There is already quite a lot of material about possible solutions in the literature. The working group plans to establish design teams for rapidly advancing towards initial submissions for these two work items. The group shall also work with the 6LOWPAN and ROLL working group to ensure that the results from AUTOCONF working group are useful for the larger community and do not overlap with work already in progress in these other working groups. Goals and Milestones: - Jan 2011 First working group draft of the "DHCPv6 operation over MANET" - Jan 2011 First working group draft of the "Analysis of Problem Space" - Sep 2011 Submission of the "DHCPv6 operation over MANET" to the IESG for publication as BCP - Sep 2011 Submission of the "Analysis of Problem Space" the IESG for publication as Informational RFC - Oct 2011 First working group draft of the "Distributed Solution" - Jun 2012 Submission of the "Distributed Solution" to the IESG for publication as an Proposed Standard RFC - Jun 2012 Rechartering or Closing WG From ryuji.wakikawa@gmail.com Tue Nov 30 13:51:46 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F6A3A6C31 for ; Tue, 30 Nov 2010 13:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AplifW2A97rB for ; Tue, 30 Nov 2010 13:51:45 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 9A62C3A6BB4 for ; Tue, 30 Nov 2010 13:51:45 -0800 (PST) Received: by ywh2 with SMTP id 2so3316318ywh.31 for ; Tue, 30 Nov 2010 13:52:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:references:to:message-id :mime-version:x-mailer; bh=jvc39jkLIULY2xtKNqtEIbRkqcRa0hPqDS5TAXfOgLM=; b=BfXA9/CM3YVqJLvE/j2Tufyd6Eg23J905jgjbF+8sMksQumNqvIhIyYuLIYsVF8Tcs 2Wus8Glx5AjvcIFWwXfqawa+KDJDryz8gmbGz0ACVzqwPyhQ2jxuLMGDdzBjz7zIvJJP KAyXq4zCDf0CgjYRLakItZxU/89Hs+JuQIiRs= 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=TNEcHg9mR9kPW3yOor6DLjGSfmwY3L/IkC+5ILy3g+wkwXaAD/uyK/BuYCTj8y5s0S ptrnfGWuzsofqZ5TxErMps7Zy47x5GSuHdp5Hm9B3LJuJkxK/FFbslzxFGNG+ypL12yP iXVJQvAwGx4+2H1sJ4xoUCH7QFqkXtf1rncss= Received: by 10.150.196.11 with SMTP id t11mr13616350ybf.194.1291153976987; Tue, 30 Nov 2010 13:52:56 -0800 (PST) Received: from macbookpro-ryuji.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id x39sm7450926ana.6.2010.11.30.13.52.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 30 Nov 2010 13:52:55 -0800 (PST) From: Ryuji Wakikawa Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Nov 2010 13:52:53 -0800 References: <20101130174257.9343928C0D9@core3.amsl.com> To: "Autoconf autoconf@ietf.org" Message-Id: <7E066FA7-AA84-4042-9DE0-D274602EB794@gmail.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Autoconf] Fwd: WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 21:51:47 -0000 Hi All, Just FYI. Our new charter is in review.=20 As soon as the charter is approved, we need to jump start our activity. Charlie, Teco, we have two documents about legacy host support. Thanks = Teco for the new ID. http://www.ietf.org/id/draft-boot-autoconf-support4hosts-00.txt http://www.ietf.org/id/draft-perkins-autoconf-leghost-00.txt The list of IDs submitted to AUTOCONF WG can be found here.=20 = https://datatracker.ietf.org/doc/search/?name=3Dautoconf&rfcs=3Don&activeD= rafts=3Don The charter said the design team formation, but we expect individual = submissions before that. Specially I would solicit the DHCP operation document. If you have idea or problem statement for our charter items, please = write and submit a draft. thanks! ryuji Begin forwarded message: > From: IESG Secretary > Date: 2010/11/30 09:42:57GMT-08:00 > To: IETF Announcement list > Cc: ryuji.wakikawa@gmail.com, T.Clausen@computer.org, = autoconf@ietf.org > Subject: WG Review: Recharter of Ad-Hoc Network Autoconfiguration = (autoconf)=20 > Reply-To: iesg@ietf.org >=20 > A modified charter has been submitted for the Ad-Hoc Network > Autoconfiguration (autoconf) working group in the Internet Area of the > IETF. The IESG has not made any determination as yet. The modified > charter is provided below for informational purposes only. Please = send > your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, > December 7, 2010. >=20 > Ad-Hoc Network Autoconfiguration (autoconf) > ------------------------------------------- > Last modified: 2010-11-30 > Current Status: Active >=20 > Chairs: > Ryuji Wakikawa > Thomas Clausen >=20 > Internet Area Directors: > Ralph Droms > Jari Arkko >=20 > Internet Area Advisor: > Jari Arkko >=20 > Mailing Lists: > General Discussion: autoconf@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf > Archive: > http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html >=20 > Description of Working Group: >=20 > RFC 5889 presents one possible IPv6 addressing model for ad hoc > nodes. In this model the ad hoc routers need to configure their > network interface(s) with addresses valid in the ad hoc network, and > may configure additional prefixes for use by attached nodes. >=20 > After completing the work on RFC 5889, the main purpose of the > AUTOCONF WG is to standardize how existing IPv6 address configuration > tools can be used for address configuration. >=20 > 1. DHCPv6 operation over MANET, including: >=20 > - A DHCPv6-based mechanism for configuring required interface > addresses for the routers in the ad hoc network. This mechanism > is expected to produce addresses with properties outlined in RFC > 5889. This mechanism uses the existing DHCPv6 protocol unchanged, > and assumes a central node that can allocate addresses on a > first-come-first-served basis. Other nodes in the ad hoc network > will relay messages to the central node in order to help a new > node get an address for itself. This mechanism is only suitable > for deployments were a central node can be set up. It should be > noted that many existing deployments employ Internet gateways > that can act as such a central node as well. Future extensions > such as central node election may make this mechanism suitable > for also for stand-alone ad hoc networks. >=20 > - A DHCPv6-based mechanism for delegating a prefix(es) to each > router for use by applications running on the routers themselves, > or for configuration of attached hosts/networks. This mechanism > works in a similar manner to the one above, but allocates > prefixes instead of addresses. >=20 > Both mechanisms should be independent from operation of any specific > MANET routing protocol, although may exploit information maintained by > such a routing protocol, if available. >=20 > The working group will adapt and/or reuse existing protocols whenever > reasonable and possible. No new duplicate address detection mechanisms > are will be specified; it is expected that address uniqueness is > guaranteed by the central node alone. >=20 > 2. Analysis of Problem Space for distributed address configuration and > service discovery. This analysis is necessary in order to understand > what type of distributed solution(s) can be standardized. There is > already quite a lot of material about possible solutions in the > literature. >=20 > The working group plans to establish design teams for rapidly = advancing > towards initial submissions for these two work items. The group shall > also work with the 6LOWPAN and ROLL working group to ensure that > the results from AUTOCONF working group are useful for the larger > community and do not overlap with work already in progress in these > other working groups. >=20 > Goals and Milestones: >=20 > - Jan 2011 First working group draft of the "DHCPv6 operation over=20 > MANET" > - Jan 2011 First working group draft of the "Analysis of Problem = Space" > - Sep 2011 Submission of the "DHCPv6 operation over MANET" to the IESG=20= > for publication as BCP > - Sep 2011 Submission of the "Analysis of Problem Space" the IESG for=20= > publication as Informational RFC > - Oct 2011 First working group draft of the "Distributed Solution" > - Jun 2012 Submission of the "Distributed Solution" to the IESG for=20 > publication as an Proposed Standard RFC > - Jun 2012 Rechartering or Closing WG