From charles.perkins@earthlink.net Fri Dec 3 16:08: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 09A7C3A69E2 for ; Fri, 3 Dec 2010 16:08:26 -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 cozv5Stmx5cw for ; Fri, 3 Dec 2010 16:08:25 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 0B8113A69DF for ; Fri, 3 Dec 2010 16:08:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ZBuMj7I57nZ2evQt5tmp0iaXPotdTz/Urzbq7LvdBhtcZVt5UlMmL+QThBnzWa+a; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [138.111.58.2] (helo=[172.17.96.25]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1POfh8-0002dw-T3; Fri, 03 Dec 2010 19:09:42 -0500 Message-ID: <4CF986C5.8070208@earthlink.net> Date: Fri, 03 Dec 2010 16:09:41 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Teco Boot References: <20101129212013.184B53A6BDB@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5298bd03ebd448ff0c7a1534681dbcbb74350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: autoconf@ietf.org Subject: Re: [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: Sat, 04 Dec 2010 00:08:26 -0000 Hello Teco, Comments below: > Packet forwarding between hosts is always lead > via one ore more MANET routers, unless link-local addresses are used > and direct reachability between the hosts exists. I did not understand this sentence. > However, usage of > link-local addresses is not recommended, as non-link-local addresses > provide better support for session continuity in mobile environments. I was surprised to read that the purpose for using non-link-local addresses was for session continuity. I think it is more along the lines of "identity preservation and uniqueness". > Charles E. Parkins Thanks for the acknowledgement. My last name has an 'e' in it :-). > Mobility > solutions are already available and can be used in the MANET > scenario. This is true, but usually is considered in the context of having a home agent in the Internet instead of in the ad-hoc network. Is this what you are proposing? Regards, Charlie P. On 11/29/2010 1:30 PM, Teco Boot wrote: > 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. > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From teco@inf-net.nl Mon Dec 6 13:49:08 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7C83A68BE for ; Mon, 6 Dec 2010 13:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 4cK4ASegwFJh for ; Mon, 6 Dec 2010 13:49:06 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 9136D3A68C5 for ; Mon, 6 Dec 2010 13:49:06 -0800 (PST) Received: by wwa36 with SMTP id 36so13141663wwa.13 for ; Mon, 06 Dec 2010 13:50:30 -0800 (PST) Received: by 10.216.235.211 with SMTP id u61mr5323101weq.91.1291672230063; Mon, 06 Dec 2010 13:50:30 -0800 (PST) Received: from [192.168.2.166] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id p4sm2601656wej.4.2010.12.06.13.50.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 06 Dec 2010 13:50:28 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4CF986C5.8070208@earthlink.net> Date: Mon, 6 Dec 2010 22:50:25 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <20101129212013.184B53A6BDB@core3.amsl.com> <4CF986C5.8070208@earthlink.net> To: Charles E. Perkins X-Mailer: Apple Mail (2.1081) Cc: autoconf@ietf.org Subject: Re: [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, 06 Dec 2010 21:49:08 -0000 Hello Charlie, Thanks for reviewing. I posted a -01. I hope it clears up a bit. http://www.ietf.org/id/draft-boot-autoconf-support4hosts-01.txt Op 4 dec 2010, om 01:09 heeft Charles E. Perkins het volgende geschreven: > >> Packet forwarding between hosts is always lead >> via one ore more MANET routers, unless link-local addresses are used >> and direct reachability between the hosts exists. > > I did not understand this sentence. Now, diagrams and text is added. It shows when LLs work, and when it fails. Maybe MPTCP can support LLs and find out automatically if a host-host path exists and has larger throughput as a path via router(s). >> However, usage of >> link-local addresses is not recommended, as non-link-local addresses >> provide better support for session continuity in mobile environments. > > I was surprised to read that the purpose for using non-link-local > addresses was for session continuity. I think it is more along the > lines of "identity preservation and uniqueness". I guess mobility solutions are not designed for link-locals. But this is not clear in this sentence, so I reworded. >> Charles E. Parkins > > Thanks for the acknowledgement. My last name has > an 'e' in it :-). Who said it was you? :-) >> Mobility >> solutions are already available and can be used in the MANET >> scenario. > > This is true, but usually is considered in the context > of having a home agent in the Internet instead of in > the ad-hoc network. Is this what you are proposing? There are mobility solutions that don't need a home agent. E.g. I suggested running a MANET routing protocol. I am aware of MANETs where main requirement is connectivity with nodes on the Internet. Here, MIP6 could work quite well. Another model is using the router that provided the 1st configured prefix as MIP6 HA. When Host1 gets address from RtrA and assigns address HostA, it could use this address as home address. When later on, an address HostB with prefix from RtrB is assigned, it could bind this HostB address as care-of address to HA RtrA. Route optimization can be performed with for example MPTCP. Legacy hosts would not perform such functions, but I think it is doable. Regards, Teco From wwwrun@core3.amsl.com Tue Dec 21 09:50:17 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 212DD3A6B45; Tue, 21 Dec 2010 09:50:16 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20101221175017.212DD3A6B45@core3.amsl.com> Date: Tue, 21 Dec 2010 09:50:17 -0800 (PST) Cc: autoconf@ietf.org, T.Clausen@computer.org Subject: [Autoconf] WG Action: RECHARTER: 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, 21 Dec 2010 17:50:17 -0000 The Ad-Hoc Network Autoconfiguration (autoconf) working group in the Internet Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Ad-Hoc Network Autoconfiguration (autoconf) --------------------------------------------------- Current Status: Active Working Group 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. 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 will be specified. 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 Fred.L.Templin@boeing.com Tue Dec 21 12:44: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 245033A68BE for ; Tue, 21 Dec 2010 12:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.385 X-Spam-Level: X-Spam-Status: No, score=-5.385 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkwDOUtWtwIv for ; Tue, 21 Dec 2010 12:44:40 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 1DD313A688B for ; Tue, 21 Dec 2010 12:44:39 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id oBLKkYAp021842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 21 Dec 2010 14:46:34 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id oBLKkYlE005905 for ; Tue, 21 Dec 2010 14:46:34 -0600 (CST) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id oBLKkXOg005873 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Tue, 21 Dec 2010 14:46:33 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Tue, 21 Dec 2010 12:46:33 -0800 From: "Templin, Fred L" To: "autoconf@ietf.org" Date: Tue, 21 Dec 2010 12:46:32 -0800 Thread-Topic: DHCP-related solution proposal... Thread-Index: AcuhN859CI/W/L6QSD+btcsvN/azdAAF9ibg Message-ID: References: <20101221175017.212DD3A6B45@core3.amsl.com> In-Reply-To: <20101221175017.212DD3A6B45@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Autoconf] DHCP-related solution 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, 21 Dec 2010 20:44:41 -0000 ...is here: http://tools.ietf.org/html/draft-templin-intarea-vet Thanks - Fred fred.l.templin@boeing.com=