From autoconf-bounces@ietf.org Wed Feb 01 04:51:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4EeX-0003SU-3F; Wed, 01 Feb 2006 04:51:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4EeV-0003N8-5N for autoconf@megatron.ietf.org; Wed, 01 Feb 2006 04:51:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27521 for ; Wed, 1 Feb 2006 04:50:09 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4EpW-0006fQ-HE for autoconf@ietf.org; Wed, 01 Feb 2006 05:03:17 -0500 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IU0008C661U65@mailout2.samsung.com> for autoconf@ietf.org; Wed, 01 Feb 2006 18:51:30 +0900 (KST) Received: from Shubhranshu ([75.2.91.95]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IU000E4M61UUV@mmp1.samsung.com> for autoconf@ietf.org; Wed, 01 Feb 2006 18:51:30 +0900 (KST) Date: Wed, 01 Feb 2006 18:51:30 +0900 From: Shubhranshu To: autoconf@ietf.org Message-id: <04a901c62715$13c98c10$5f5b024b@Shubhranshu> Organization: Samsung Electronics MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7BIT Cc: manetautoconf@ml.free.fr Subject: [Autoconf] New "Autoconf" mailing list X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi, All the members of manetautoconf@ml.free.fr have been subscribed to "autoconf@ietf.org" mailing list. Please use "autoconf@ietf.org" for future Autoconf related discussions. To unsubscribe/subscribe use https://www1.ietf.org/mailman/listinfo/autoconf Also, the existing archive has been moved to http://www1.ietf.org/mail-archive/web/autoconf/current/index.html - Shubhranshu _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Feb 01 17:04:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Q5L-0002G7-PV; Wed, 01 Feb 2006 17:04:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Q5J-0002AV-4N for autoconf@megatron.ietf.org; Wed, 01 Feb 2006 17:04:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17041 for ; Wed, 1 Feb 2006 17:02:39 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4QGV-0002EM-JK for autoconf@ietf.org; Wed, 01 Feb 2006 17:15:55 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA16859; Wed, 1 Feb 2006 14:03:57 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k11M3vW28675; Wed, 1 Feb 2006 14:03:57 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Feb 2006 14:03:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Feb 2006 14:03:54 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1818A18@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: Comments on draft-wakikawa-manet-globalv6-04.txt Thread-Index: AcYnFR33skIEcNCmQ3y50mpXd07VpwAZAx2g From: "Templin, Fred L" To: X-OriginalArrivalTime: 01 Feb 2006 22:03:54.0966 (UTC) FILETIME=[64A56760:01C6277B] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org I don't know if this is the correct forum, but below are some comments on this draft: Fred fred.l.templin@boeing.com =20 1) In introduction, add DYMO to list of IETF routing protocols. 2) Second to last paragraph of P.4, change: "whether they are reactive and proactive." to: "... reactive or proactive." 3) Final paragraph of P.4, this text seems to assume that internet-gateways maintain a roster of the addresses of nodes that reside within the MANET, e.g., so that packets destined to MANET nodes don't leak out into the Internet and so that ICMP redirects can be issued. This assumption needs to be made explicit somehow - both in this section and elsewhere throughout the document. 4) Top of P.6, the sentence: "The node therefore needs to obtain a global prefix owned and distributed by an internet-gateway." Is the intention here that a prefix must be owned by one and only one internet-gateway? Or, could the same prefix potentially be advertised by multiple gateways? 5) Bottom of P.6, change "two messages such as" to "two messages:". 6) Section 4.3, add a third message type "internet gateway confirmation". The purpose of this message is to provide a 3-way handshake between manet nodes and internet gateways under the following procedure: 1. manet node sends "internet gateway solicitation" to multicast address 2. Internet gateway(s) sends "internet gateway advertisement" to unicast address of manet node 3. manet node sends "internet gateway confirmation" to unicast address of internet gateway(s) The "internet gateway confirm" message is needed to allow the internet gateway to construct a roster of the MANET nodes it serves. The roster is needed in order for the gateway to determine when redirects should be sent for intra-MANET communications. 7) P.11, second sentence beginning with: "Since the manet node is assumed to already have done Duplicate Address Detection (DAD), as defined in [11], for the link-local address", this does not seem to be a valid assumption since there is no way for the node to inquire throughout the entire MANET as to whether its link-local address is unique within the MANET. Suggest dropping the entire discussion on DAD and simply say "DAD is not in scope". 8) Section 5.5, change: "But it just stop sending..." to: "But it SHOULD stop sending...". Also, the rest of this first paragraph of section 5.5 seems poorly-worded and imprecise. Suggest either a re-write or just remove the text. 9) Section 6.1, second paragraph. Change: "When an internet-gateway..." to: "When a manet node...". 10) Section 7.3, the verification: "- If the hop limit field of the message is less than or equal to zero...", how is the "less than" check to be one (i.e., the hop-limit field is just an 8-bit unsigned integer). Suggest changing: "less than or equal to zero" to simply "equal to zero". 11) Section 7.3, final sentence (and section 7.4) the "global manet node list" spoken of here can only be unidirectional. If an "internet gateway confirm" message type is added (as per comment 6), the global manet node list can be made bi-directional. 12) Section 7.5, this entire section seems to assume that internet- gateways are assigned prefixes in 1x1 correspondence. As asked earlier, can more than one internet-gateway advertise the *same* prefix, i.e., can a prefix be co-owned by more than one gateway? If yes, then this section would require rewrites. If no, then why not? _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Feb 01 22:40:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4VKI-0004GF-E4; Wed, 01 Feb 2006 22:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4VKD-00049x-JM for autoconf@megatron.ietf.org; Wed, 01 Feb 2006 22:40:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20444 for ; Wed, 1 Feb 2006 22:38:16 -0500 (EST) Received: from yui.nc.u-tokyo.ac.jp ([130.69.251.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4VVL-0007sJ-Vc for autoconf@ietf.org; Wed, 01 Feb 2006 22:51:35 -0500 Received: from wifi-139-154.sfc.wide.ad.jp.sfc.wide.ad.jp (wifi-139-154.sfc.wide.ad.jp [203.178.139.154]) (authenticated bits=0) by yui.nc.u-tokyo.ac.jp (8.12.10/8.12.3/Debian-6.4) with ESMTP id k123dNUl015284; Thu, 2 Feb 2006 12:39:27 +0900 Date: Thu, 02 Feb 2006 12:39:20 +0900 Message-ID: From: Ryuji Wakikawa To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1818A18@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A1818A18@XCH-NW-7V2.nw.nos.boeing.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/22.0.50 (powerpc-apple-darwin8.1.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: autoconf@ietf.org Subject: [Autoconf] Re: Comments on draft-wakikawa-manet-globalv6-04.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Fred Thanks for detailed comments. Please find my reply in-line. At Wed, 1 Feb 2006 14:03:54 -0800, Templin, Fred L wrote: > > I don't know if this is the correct forum, but below are > some comments on this draft: > > Fred > fred.l.templin@boeing.com > > > 1) In introduction, add DYMO to list of IETF routing protocols. > > 2) Second to last paragraph of P.4, change: "whether they are > reactive and proactive." to: "... reactive or proactive." > > 3) Final paragraph of P.4, this text seems to assume that > internet-gateways maintain a roster of the addresses of > nodes that reside within the MANET, e.g., so that packets > destined to MANET nodes don't leak out into the Internet > and so that ICMP redirects can be issued. This assumption > needs to be made explicit somehow - both in this section > and elsewhere throughout the document. Right. However, there are several scenarios. 1. MN has only a topology correct address from IGW. 2. MN has a topology correct address and an own address such as HoA. Only in the case 2, we need such assumption. IGW can filter the packets easily with prefix comparison for the case-1. We may drop this assumption. When the destination node is in the same MANET, but the packet need to go through HA, this roster based filtering breaks this scenario. This feature is just an optimization to directly route the packet meant for a MN located in the same MANET. BTW, roster is good word:-) I didn't come up with this word. thanks. > 4) Top of P.6, the sentence: "The node therefore needs to obtain > a global prefix owned and distributed by an internet-gateway." > Is the intention here that a prefix must be owned by one > and only one internet-gateway? Or, could the same prefix > potentially be advertised by multiple gateways? We don't think such limitation. Multiple IGW can advertise the same prefix. > 5) Bottom of P.6, change "two messages such as" to "two messages:". > > 6) Section 4.3, add a third message type "internet gateway > confirmation". The purpose of this message is to provide > a 3-way handshake between manet nodes and internet gateways > under the following procedure: > > 1. manet node sends "internet gateway solicitation" to > multicast address > 2. Internet gateway(s) sends "internet gateway advertisement" > to unicast address of manet node > 3. manet node sends "internet gateway confirmation" to > unicast address of internet gateway(s) > > The "internet gateway confirm" message is needed to allow the > internet gateway to construct a roster of the MANET nodes it > serves. The roster is needed in order for the gateway to > determine when redirects should be sent for intra-MANET > communications. agree with the third message for the roster management. > 7) P.11, second sentence beginning with: "Since the manet node is > assumed to already have done Duplicate Address Detection (DAD), > as defined in [11], for the link-local address", this does not > seem to be a valid assumption since there is no way for the node > to inquire throughout the entire MANET as to whether its link-local > address is unique within the MANET. Suggest dropping the entire > discussion on DAD and simply say "DAD is not in scope". agree for the link-local address DAD. However, the IGW may help DAD operation because it has a roster of the MANET nodes. IGW easily detects the duplication. > 8) Section 5.5, change: "But it just stop sending..." to: "But it > SHOULD stop sending...". Also, the rest of this first paragraph > of section 5.5 seems poorly-worded and imprecise. Suggest either > a re-write or just remove the text. > 9) Section 6.1, second paragraph. Change: "When an internet-gateway..." > to: "When a manet node...". > 10) Section 7.3, the verification: "- If the hop limit field of the > message is less than or equal to zero...", how is the "less than" > check to be one (i.e., the hop-limit field is just an 8-bit > unsigned integer). Suggest changing: "less than or equal to zero" > to simply "equal to zero". OK. I'll fix these in the next revision. > 11) Section 7.3, final sentence (and section 7.4) the "global manet > node list" spoken of here can only be unidirectional. If an > "internet gateway confirm" message type is added (as per > comment 6), the global manet node list can be made bi-directional. right. I want to ask you whether we should keep the roster management in the spec. Roster brings several optimization such as filtering packets and helping DAD, but, on the other hand, it cause certain burden to MN and IGW. In addition, if we consider multiple IGW serving a same prefix, we need some the roster sync between gateways. > 12) Section 7.5, this entire section seems to assume that internet- > gateways are assigned prefixes in 1x1 correspondence. As asked > earlier, can more than one internet-gateway advertise the *same* > prefix, i.e., can a prefix be co-owned by more than one gateway? > If yes, then this section would require rewrites. If no, then > why not? Right. We don't need the assumption. To support multiple IGWs, we need to drop the roster management or put the roster sync between IGWs. thanks, ryuji _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 02 06:14:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4cQM-0001Ax-3V; Thu, 02 Feb 2006 06:14:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4cQE-00019N-BN for autoconf@megatron.ietf.org; Thu, 02 Feb 2006 06:14:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22554 for ; Thu, 2 Feb 2006 06:12:51 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4cbM-0006q0-GY for autoconf@ietf.org; Thu, 02 Feb 2006 06:26:14 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 734A38990D; Thu, 2 Feb 2006 13:14:07 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 352838990B; Thu, 2 Feb 2006 13:14:07 +0200 (EET) Message-ID: <43E1E998.8070500@piuha.net> Date: Thu, 02 Feb 2006 13:14:32 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt References: <39C363776A4E8C4A94691D2BD9D1C9A1818A18@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1818A18@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Templin, Fred L wrote: >12) Section 7.5, this entire section seems to assume that internet- > gateways are assigned prefixes in 1x1 correspondence. As asked > earlier, can more than one internet-gateway advertise the *same* > prefix, i.e., can a prefix be co-owned by more than one gateway? > If yes, then this section would require rewrites. If no, then > why not? > > Good question. If we look at this from an IP perspective, having the same prefix on two gateways is possible, but it requires those gateways to share a common link where, e.g., neighbor discovery can occur. But the main question is whether the MANET-specific parts can use multiple gateways or not. I guess the answer to that depends at least on whether the gateways can stay in sync. For instance, if the MANET hosts behind a gateway look exactly like other hosts connected to the gateways, then the usual RFC 2461-2463 mechanisms appear to be sufficient for hosts to talk to each other even if they are on another gateway, verify address uniqueness, etc. --Jari _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 02 07:03:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4dBq-0007cA-Uw; Thu, 02 Feb 2006 07:03:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4dBp-0007aq-Gu for autoconf@megatron.ietf.org; Thu, 02 Feb 2006 07:03:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25918 for ; Thu, 2 Feb 2006 07:02:07 -0500 (EST) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4dN0-0008R0-2K for autoconf@ietf.org; Thu, 02 Feb 2006 07:15:29 -0500 Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IU200A3M6TQH3@mailout1.samsung.com> for autoconf@ietf.org; Thu, 02 Feb 2006 21:03:26 +0900 (KST) Received: from daniellaptop ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IU200FLA6TQ5N@mmp1.samsung.com> for autoconf@ietf.org; Thu, 02 Feb 2006 21:03:26 +0900 (KST) Date: Thu, 02 Feb 2006 21:03:49 +0900 From: Soohong Daniel Park Subject: Re: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt To: autoconf@ietf.org Message-id: <01fc01c627f0$b9f62b30$6dc6dba8@daniellaptop> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <39C363776A4E8C4A94691D2BD9D1C9A1818A18@XCH-NW-7V2.nw.nos.boeing.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7BIT X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org In addition, current draft is still missing of how DNS Server can be configured on the manet node from the global connectivity point of view. Perhaps, Ryuji remembers what I am indicating because I did raise this concern before. Obtaining DNS Server address is an essential part of manet global connectivity, so one option SHOULD be attached to the RA option along with Prefix option. You can refer to the related work below; http://www.watersprings.org/pub/id/draft-daniel-manet-dns-discovery-globalv6-00.txt http://www.watersprings.org/pub/id/draft-jeong-dnsop-ipv6-dns-discovery-08.txt Thanks, Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. ----- Original Message ----- From: "Templin, Fred L" To: Sent: Thursday, February 02, 2006 7:03 AM Subject: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt I don't know if this is the correct forum, but below are some comments on this draft: Fred fred.l.templin@boeing.com 1) In introduction, add DYMO to list of IETF routing protocols. 2) Second to last paragraph of P.4, change: "whether they are reactive and proactive." to: "... reactive or proactive." 3) Final paragraph of P.4, this text seems to assume that internet-gateways maintain a roster of the addresses of nodes that reside within the MANET, e.g., so that packets destined to MANET nodes don't leak out into the Internet and so that ICMP redirects can be issued. This assumption needs to be made explicit somehow - both in this section and elsewhere throughout the document. 4) Top of P.6, the sentence: "The node therefore needs to obtain a global prefix owned and distributed by an internet-gateway." Is the intention here that a prefix must be owned by one and only one internet-gateway? Or, could the same prefix potentially be advertised by multiple gateways? 5) Bottom of P.6, change "two messages such as" to "two messages:". 6) Section 4.3, add a third message type "internet gateway confirmation". The purpose of this message is to provide a 3-way handshake between manet nodes and internet gateways under the following procedure: 1. manet node sends "internet gateway solicitation" to multicast address 2. Internet gateway(s) sends "internet gateway advertisement" to unicast address of manet node 3. manet node sends "internet gateway confirmation" to unicast address of internet gateway(s) The "internet gateway confirm" message is needed to allow the internet gateway to construct a roster of the MANET nodes it serves. The roster is needed in order for the gateway to determine when redirects should be sent for intra-MANET communications. 7) P.11, second sentence beginning with: "Since the manet node is assumed to already have done Duplicate Address Detection (DAD), as defined in [11], for the link-local address", this does not seem to be a valid assumption since there is no way for the node to inquire throughout the entire MANET as to whether its link-local address is unique within the MANET. Suggest dropping the entire discussion on DAD and simply say "DAD is not in scope". 8) Section 5.5, change: "But it just stop sending..." to: "But it SHOULD stop sending...". Also, the rest of this first paragraph of section 5.5 seems poorly-worded and imprecise. Suggest either a re-write or just remove the text. 9) Section 6.1, second paragraph. Change: "When an internet-gateway..." to: "When a manet node...". 10) Section 7.3, the verification: "- If the hop limit field of the message is less than or equal to zero...", how is the "less than" check to be one (i.e., the hop-limit field is just an 8-bit unsigned integer). Suggest changing: "less than or equal to zero" to simply "equal to zero". 11) Section 7.3, final sentence (and section 7.4) the "global manet node list" spoken of here can only be unidirectional. If an "internet gateway confirm" message type is added (as per comment 6), the global manet node list can be made bi-directional. 12) Section 7.5, this entire section seems to assume that internet- gateways are assigned prefixes in 1x1 correspondence. As asked earlier, can more than one internet-gateway advertise the *same* prefix, i.e., can a prefix be co-owned by more than one gateway? If yes, then this section would require rewrites. If no, then why not? _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 02 09:11:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4fB0-0001Jh-6L; Thu, 02 Feb 2006 09:11:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4f6h-0007lJ-Mv for autoconf@megatron.ietf.org; Thu, 02 Feb 2006 09:06:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05254 for ; Thu, 2 Feb 2006 09:04:47 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4fCx-0004Na-Pp for autoconf@ietf.org; Thu, 02 Feb 2006 09:13:15 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8D8058990F for ; Thu, 2 Feb 2006 16:01:10 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 565078990D for ; Thu, 2 Feb 2006 16:01:10 +0200 (EET) Message-ID: <43E210BF.5010707@piuha.net> Date: Thu, 02 Feb 2006 16:01:35 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: autoconf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Subject: [Autoconf] Re: [MANET-AUTOCONF] Re: review of draft-singh-autoconf-adp-02 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Simone Ruffino wrote: >Anyway, my personal understanding was that AUTOCONF must necessarily >take address uniqueness into account, for two reasons: >Primarily, to address specific problems of MANETs: for example, if two >nodes have the same address, routing in the *whole* MANET could possibly >be compromised. > > Right. Yes, I think I understand this, now. Will this happen always, or is this danger specific to some MANET routing mechanisms? >As a matter of fact, rfc2462 says also that DAD can be >disabled in cases when its overhead outweighs its benefits. > > Right. I wouldn't use compliance with RFC 2462 as the main reason for performing duplicate detection. >My conclusion was that a uniqueness check must be defined for MANETs, >but that can possibly be disabled. For this reason, I would like to have >a solution which check uniqueness using an "optimistic" approach >(something similar to optimistic DAD). > > Optional optimistic DAD is one approach. But that still leaves some questions to decide. For instance, are the manet-internal addresses and globally reachable addresses the same or different? If they are different, will they be allocated by the same or different mechanisms. For instance, you could use something PACMAN-like for the internal addresses, and then have the globally reachable addresses allocated centrally from the gateway (because obviously you need to be able to reach the gateway or else these addresses aren't useful). --Jari _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 02 09:11:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4fBi-0001RL-KQ; Thu, 02 Feb 2006 09:11:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4fBf-0001N6-GW for autoconf@megatron.ietf.org; Thu, 02 Feb 2006 09:11:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05946 for ; Thu, 2 Feb 2006 09:09:50 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4fMe-0004zO-8w for autoconf@ietf.org; Thu, 02 Feb 2006 09:23:14 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 44A328990F; Thu, 2 Feb 2006 16:11:16 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0498D8990D; Thu, 2 Feb 2006 16:11:15 +0200 (EET) Message-ID: <43E2131D.2030402@piuha.net> Date: Thu, 02 Feb 2006 16:11:41 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soohong Daniel Park Subject: Re: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt References: <39C363776A4E8C4A94691D2BD9D1C9A1818A18@XCH-NW-7V2.nw.nos.boeing.com> <01fc01c627f0$b9f62b30$6dc6dba8@daniellaptop> In-Reply-To: <01fc01c627f0$b9f62b30$6dc6dba8@daniellaptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Yes, DNS server is needed too, assuming we have global connectivity. But we may also need other information, such as NTP servers, local SIP servers etc. I wonder if there is a way to somehow use DHCP in this context so that we wouldn't need to invent all those options again. --Jari Soohong Daniel Park wrote: >In addition, current draft is still missing of how DNS Server can be >configured on the manet node from the global connectivity point of >view. Perhaps, Ryuji remembers what I am indicating because I did >raise this concern before. Obtaining DNS Server address is an >essential part of manet global connectivity, so one option SHOULD >be attached to the RA option along with Prefix option. You can refer >to the related work below; >http://www.watersprings.org/pub/id/draft-daniel-manet-dns-discovery-globalv6-00.txt >http://www.watersprings.org/pub/id/draft-jeong-dnsop-ipv6-dns-discovery-08.txt > >Thanks, > >Daniel (Soohong Daniel Park) >Mobile Convergence Laboratory, SAMSUNG Electronics. >----- Original Message ----- >From: "Templin, Fred L" >To: >Sent: Thursday, February 02, 2006 7:03 AM >Subject: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt > > >I don't know if this is the correct forum, but below are >some comments on this draft: > >Fred >fred.l.templin@boeing.com > > >1) In introduction, add DYMO to list of IETF routing protocols. > >2) Second to last paragraph of P.4, change: "whether they are > reactive and proactive." to: "... reactive or proactive." > >3) Final paragraph of P.4, this text seems to assume that > internet-gateways maintain a roster of the addresses of > nodes that reside within the MANET, e.g., so that packets > destined to MANET nodes don't leak out into the Internet > and so that ICMP redirects can be issued. This assumption > needs to be made explicit somehow - both in this section > and elsewhere throughout the document. > >4) Top of P.6, the sentence: "The node therefore needs to obtain > a global prefix owned and distributed by an internet-gateway." > Is the intention here that a prefix must be owned by one > and only one internet-gateway? Or, could the same prefix > potentially be advertised by multiple gateways? > >5) Bottom of P.6, change "two messages such as" to "two messages:". > >6) Section 4.3, add a third message type "internet gateway > confirmation". The purpose of this message is to provide > a 3-way handshake between manet nodes and internet gateways > under the following procedure: > > 1. manet node sends "internet gateway solicitation" to > multicast address > 2. Internet gateway(s) sends "internet gateway advertisement" > to unicast address of manet node > 3. manet node sends "internet gateway confirmation" to > unicast address of internet gateway(s) > > The "internet gateway confirm" message is needed to allow the > internet gateway to construct a roster of the MANET nodes it > serves. The roster is needed in order for the gateway to > determine when redirects should be sent for intra-MANET > communications. > >7) P.11, second sentence beginning with: "Since the manet node is > assumed to already have done Duplicate Address Detection (DAD), > as defined in [11], for the link-local address", this does not > seem to be a valid assumption since there is no way for the node > to inquire throughout the entire MANET as to whether its link-local > address is unique within the MANET. Suggest dropping the entire > discussion on DAD and simply say "DAD is not in scope". > >8) Section 5.5, change: "But it just stop sending..." to: "But it > SHOULD stop sending...". Also, the rest of this first paragraph > of section 5.5 seems poorly-worded and imprecise. Suggest either > a re-write or just remove the text. > >9) Section 6.1, second paragraph. Change: "When an internet-gateway..." > to: "When a manet node...". > >10) Section 7.3, the verification: "- If the hop limit field of the > message is less than or equal to zero...", how is the "less than" > check to be one (i.e., the hop-limit field is just an 8-bit > unsigned integer). Suggest changing: "less than or equal to zero" > to simply "equal to zero". > >11) Section 7.3, final sentence (and section 7.4) the "global manet > node list" spoken of here can only be unidirectional. If an > "internet gateway confirm" message type is added (as per > comment 6), the global manet node list can be made bi-directional. > >12) Section 7.5, this entire section seems to assume that internet- > gateways are assigned prefixes in 1x1 correspondence. As asked > earlier, can more than one internet-gateway advertise the *same* > prefix, i.e., can a prefix be co-owned by more than one gateway? > If yes, then this section would require rewrites. If no, then > why not? > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www1.ietf.org/mailman/listinfo/autoconf > > > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www1.ietf.org/mailman/listinfo/autoconf > > > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 02 10:10:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4g6R-0001ZU-CE; Thu, 02 Feb 2006 10:10:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4g6P-0001YQ-Jh for autoconf@megatron.ietf.org; Thu, 02 Feb 2006 10:10:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10911 for ; Thu, 2 Feb 2006 10:08:50 -0500 (EST) Received: from balu1.urz.unibas.ch ([131.152.1.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4gHm-0007CI-9G for autoconf@ietf.org; Thu, 02 Feb 2006 10:22:14 -0500 Received: from [10.147.66.117] (int-34-30.mobile.unibas.ch [131.152.34.30]) by balu1.urz.unibas.ch (8.13.5/8.13.5) with ESMTP id k12F9x7L001690; Thu, 2 Feb 2006 16:10:02 +0100 Message-ID: <43E220C8.4040009@unibas.ch> Date: Thu, 02 Feb 2006 16:10:00 +0100 From: Christophe Jelger Organization: University of Basel User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko References: <43E210BF.5010707@piuha.net> In-Reply-To: <43E210BF.5010707@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-Vilter-Version: 1.1.8 X-SMTP-Vilter-Virus-Backend: savse X-SMTP-Vilter-Status: clean X-SMTP-Vilter-savse-Virus-Status: clean X-SMTP-Vilter-Unwanted-Backend: attachment X-SMTP-Vilter-attachment-Unwanted-Status: clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org Subject: [Autoconf] The case for address uniqueness X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi all, Well we have already had quite a lot of discussions related to address uniqueness and I strongly support Jari's point to make DAD optional (especially if RFC2462 allows to do so). Actually I am in favor of getting rid of DAD, only maintaining a minimal scheme to detect and resolve address collisions when they occur. Going back to discussions with Bob Hinden (on this list in Feb. 2005 !) about the possible use of unique local IPv6 addresses (now RFC 4193) as MANET-local addresses, Bob agreed (email dated 02/24/2005) that each node could generate its own Global ID + subnet ID (56 bits), to be added to the EUI-64 (with 48 bits supposed to be unique from the MAC address). Moreover to make it even better, one could replace the ff:fe pattern of the EUI-64 with a random 16 bits pattern. This leads to a total of 120 bits, with 80 random bits and a sequence of 48 bits which has a very high probability of being unique. Additionaly the 80 bits pattern could include machine-specific data that would strongly increase the uniqueness of the generated address. For example, one could include the local date (in unix style, seconds elapsed since Jan. 1st 1970) when the address is generated: this is only 32 bits, but is a very strong anti-collision feature. Indeed 2 machines having the same MAC address, having generated the same random 48 bits (80-32), would have an address collision if they created their addresses at the very same (local) date !... do we really need a strong DAD mechanism to handle such highly improbable event ? Now if global connectivity is required, I personaly think that using EUI-64 with the ff:fe pattern replaced with random bits is enough to guaranty address uniqueness. Just my 2 cents ... ;-) Regards, Christophe Jari Arkko wrote: > Simone Ruffino wrote: > >> Anyway, my personal understanding was that AUTOCONF must necessarily >> take address uniqueness into account, for two reasons: Primarily, to >> address specific problems of MANETs: for example, if two >> nodes have the same address, routing in the *whole* MANET could possibly >> be compromised. >> >> > Right. Yes, I think I understand this, now. Will this > happen always, or is this danger specific to some > MANET routing mechanisms? > >> As a matter of fact, rfc2462 says also that DAD can be >> disabled in cases when its overhead outweighs its benefits. >> > Right. I wouldn't use compliance with RFC 2462 as the > main reason for performing duplicate detection. > >> My conclusion was that a uniqueness check must be defined for MANETs, >> but that can possibly be disabled. For this reason, I would like to have >> a solution which check uniqueness using an "optimistic" approach >> (something similar to optimistic DAD). >> > Optional optimistic DAD is one approach. But that > still leaves some questions to decide. For instance, are > the manet-internal addresses and globally reachable > addresses the same or different? If they are different, > will they be allocated by the same or different mechanisms. > For instance, you could use something PACMAN-like > for the internal addresses, and then have the globally > reachable addresses allocated centrally from the gateway > (because obviously you need to be able to reach the > gateway or else these addresses aren't useful). > > --Jari > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 02 11:11:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4h34-00037Y-BP; Thu, 02 Feb 2006 11:11:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4h32-00035q-5D for autoconf@megatron.ietf.org; Thu, 02 Feb 2006 11:11:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16336 for ; Thu, 2 Feb 2006 11:09:26 -0500 (EST) Received: from cluster-d.mailcontrol.com ([217.69.20.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4hEQ-0001Fp-5y for autoconf@ietf.org; Thu, 02 Feb 2006 11:22:51 -0500 Received: from rly35d.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly35d.srv.mailcontrol.com (MailControl) with ESMTP id k12GAQbg007082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Feb 2006 16:10:32 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly35d.srv.mailcontrol.com (MailControl) id k12GA0qM006133 for autoconf@ietf.org; Thu, 2 Feb 2006 16:10:00 GMT Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly35d-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id k12G9xIL006061; Thu, 02 Feb 2006 16:10:00 +0000 (GMT) Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 1cd2_3e0884b6_93ff_11da_9c51_0030482aac25; Thu, 02 Feb 2006 16:19:02 +0100 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.2) with ESMTP id 2006020217095028-685829 ; Thu, 2 Feb 2006 17:09:50 +0100 Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Thu, 2 Feb 2006 17:12:36 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Autoconf] The case for address uniqueness Thread-Topic: [Autoconf] The case for address uniqueness Thread-Index: AcYoDj099B76j26uSf26cmG30dayhwAAbqAg To: Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4F865A2B@lan-ex-01.panasonic.de> Date: Thu, 2 Feb 2006 17:09:43 +0100 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-06-00-01 (www.mailcontrol.com) on 10.68.1.145 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Christoph, all, I agree that the probability of collision is very low in case of EUI-64-based IPv6 addresses (especially with the measures you mentioned in your mail), but I want to raise awareness of the following related issues:=20 - Duplicate addresses have significant impacts on the routing of data packets and may lead to permanent packet loss - Globally unique addressing is only possible with IPv6, not with IPv4 - Those IDs are not 100\% globally unique, e.g., a IEEE MAC address configured at a specific network interface may be changed by the user, known instances of devices with duplicate MAC addresses exist on the market (e.g., non-registered or erroneous manufacturing), and some devices may not have globally unique hardware IDs at all (e.g., sensors) - Globally unique IDs may have negative implications on privacy (see RFC3041) - Globally unique IDs must be long to be able to uniquely identify all existing devices and hence significantly increase signaling traffic. This has negative implications on the scalability of, e.g., the routing protocol. Locally unique IDs can be much more efficient, since such addresses may very short (depending on the size of the network) or can easily be compressed to short addresses. Our simulations have shown that 80-90% of routing protocol overhead can be saved with locally unique IDs (see PACMAN paper referenced in my last mail). Especially for larger networks, I'm in favour of locally unique IDs, which implies that some kind of DAD scheme is needed. If globally unique IDs are used in the entire network (how does a node know that?), I'm fine with an optional DAD, but still prefer at least a SHOULD or MUST if the DAD is efficient in terms of ressource consumption. Regards, Kilian > -----Original Message----- > From: autoconf-bounces@ietf.org=20 > [mailto:autoconf-bounces@ietf.org] On Behalf Of Christophe Jelger > Sent: Donnerstag, 2. Februar 2006 16:10 > To: Jari Arkko > Cc: autoconf@ietf.org > Subject: [Autoconf] The case for address uniqueness >=20 > Hi all, >=20 > Well we have already had quite a lot of discussions related=20 > to address=20 > uniqueness and I strongly support Jari's point to make DAD optional=20 > (especially if RFC2462 allows to do so). Actually I am in favor of=20 > getting rid of DAD, only maintaining a minimal scheme to detect and=20 > resolve address collisions when they occur. >=20 > Going back to discussions with Bob Hinden (on this list in=20 > Feb. 2005 !)=20 > about the possible use of unique local IPv6 addresses (now=20 > RFC 4193) as=20 > MANET-local addresses, Bob agreed (email dated 02/24/2005) that each=20 > node could generate its own Global ID + subnet ID (56 bits),=20 > to be added=20 > to the EUI-64 (with 48 bits supposed to be unique from the=20 > MAC address).=20 > Moreover to make it even better, one could replace the ff:fe=20 > pattern of=20 > the EUI-64 with a random 16 bits pattern. >=20 > This leads to a total of 120 bits, with 80 random bits and a=20 > sequence of=20 > 48 bits which has a very high probability of being unique.=20 > Additionaly=20 > the 80 bits pattern could include machine-specific data that would=20 > strongly increase the uniqueness of the generated address.=20 > For example,=20 > one could include the local date (in unix style, seconds=20 > elapsed since=20 > Jan. 1st 1970) when the address is generated: this is only 32=20 > bits, but=20 > is a very strong anti-collision feature. Indeed 2 machines having the=20 > same MAC address, having generated the same random 48 bits (80-32),=20 > would have an address collision if they created their=20 > addresses at the=20 > very same (local) date !... do we really need a strong DAD=20 > mechanism to=20 > handle such highly improbable event ? >=20 > Now if global connectivity is required, I personaly think that using=20 > EUI-64 with the ff:fe pattern replaced with random bits is enough to=20 > guaranty address uniqueness. >=20 > Just my 2 cents ... ;-) >=20 > Regards, > Christophe >=20 > Jari Arkko wrote: > > Simone Ruffino wrote: > >=20 > >> Anyway, my personal understanding was that AUTOCONF must=20 > necessarily > >> take address uniqueness into account, for two reasons:=20 > Primarily, to=20 > >> address specific problems of MANETs: for example, if two > >> nodes have the same address, routing in the *whole* MANET=20 > could possibly > >> be compromised. > >> =20 > >> > > Right. Yes, I think I understand this, now. Will this > > happen always, or is this danger specific to some > > MANET routing mechanisms? > >=20 > >> As a matter of fact, rfc2462 says also that DAD can be > >> disabled in cases when its overhead outweighs its benefits. =20 > >> > > Right. I wouldn't use compliance with RFC 2462 as the > > main reason for performing duplicate detection. > >=20 > >> My conclusion was that a uniqueness check must be defined=20 > for MANETs, > >> but that can possibly be disabled. For this reason, I=20 > would like to have > >> a solution which check uniqueness using an "optimistic" approach > >> (something similar to optimistic DAD). =20 > >> > > Optional optimistic DAD is one approach. But that > > still leaves some questions to decide. For instance, are > > the manet-internal addresses and globally reachable > > addresses the same or different? If they are different, > > will they be allocated by the same or different mechanisms. > > For instance, you could use something PACMAN-like > > for the internal addresses, and then have the globally > > reachable addresses allocated centrally from the gateway > > (because obviously you need to be able to reach the > > gateway or else these addresses aren't useful). > >=20 > > --Jari > >=20 > >=20 > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www1.ietf.org/mailman/listinfo/autoconf > >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf >=20 >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 02 12:17:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4i2p-0004gr-VV; Thu, 02 Feb 2006 12:14:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4i2n-0004g6-HB for autoconf@megatron.ietf.org; Thu, 02 Feb 2006 12:14:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21491 for ; Thu, 2 Feb 2006 12:13:15 -0500 (EST) Received: from balu1.urz.unibas.ch ([131.152.1.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4iEC-0003aX-P0 for autoconf@ietf.org; Thu, 02 Feb 2006 12:26:41 -0500 Received: from [10.147.66.117] (int-34-193.mobile.unibas.ch [131.152.34.193]) by balu1.urz.unibas.ch (8.13.5/8.13.5) with ESMTP id k12HEWG1010795; Thu, 2 Feb 2006 18:14:32 +0100 Message-ID: <43E23DF9.8000804@unibas.ch> Date: Thu, 02 Feb 2006 18:14:33 +0100 From: Christophe Jelger Organization: University of Basel User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kilian Weniger Subject: Re: [Autoconf] The case for address uniqueness References: <4D2F935F08D41A4C8866693F4F0D7C4F865A2B@lan-ex-01.panasonic.de> In-Reply-To: <4D2F935F08D41A4C8866693F4F0D7C4F865A2B@lan-ex-01.panasonic.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-Vilter-Version: 1.1.8 X-SMTP-Vilter-Virus-Backend: savse X-SMTP-Vilter-Status: clean X-SMTP-Vilter-savse-Virus-Status: clean X-SMTP-Vilter-Unwanted-Backend: attachment X-SMTP-Vilter-attachment-Unwanted-Status: clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Kilian, Thanks for your answer. Actually I understand your points, and such things have already been discussed on the list and *all these comments make sense*. Now I think it's time to get rid of our researchers' hats, and put on the engineers' hats: what's the easiest solution, and how can we quickly standardize a solution that works ? Everybody knows the IETF standardization is a very slow process, but it would be nice to converge to some solutions before it's too late for mass people to widely use MANET technologies. See my comments inline below. Best regards, Christophe Kilian Weniger wrote: > Hi Christoph, all, > > I agree that the probability of collision is very low in case of > EUI-64-based IPv6 addresses (especially with the measures you mentioned > in your mail), but I want to raise awareness of the following related > issues: Good start... in a very sarcastic way I realize that most people on the list agrees on this but still there is quite a strong human resistance against the simplicity of randomly-generated addresses. Just to be clear, I do not advocate the blind use of randomly-generated addresses, but rather want to stress the fact that DAD should be as lightweight as possible because the probability of collisions is extremely low. > > - Duplicate addresses have significant impacts on the routing of data > packets and may lead to permanent packet loss I agree, but whatever solution one designs there can always be cases of address collisions (network merges, manually configured addresses). Thus I think the focus should be on address collision detection+repair. > - Globally unique addressing is only possible with IPv6, not with IPv4 I am not sure what you mean by globally here: MANET globally or Internet globally ? Just to make sure we are on the same wavelength, unique local IPv6 addresses are "site-local" and are not globally routeable. Now considering IPv4, if say I use private 10.0.0.0 class A addresses inside the MANET, I still have 2^24 different addresses (16 millions) so that's quite a low probability of collisions. Also note that the AUTOCONF charter is focused on IPv4 so I have to admit I don't really consider IPv4 . > - Those IDs are not 100\% globally unique, e.g., a IEEE MAC address > configured at a specific network interface may be changed by the user, > known instances of devices with duplicate MAC addresses exist on the > market (e.g., non-registered or erroneous manufacturing), and some > devices may not have globally unique hardware IDs at all (e.g., sensors) Yes but as I said in my email, I still have another 72 bits (not 80 as wrongly written in my previous email) to make the difference ! > - Globally unique IDs may have negative implications on privacy (see > RFC3041) Great, so you're in favor of generating random EUI-64 ? ;-) So am I, and we now have 120 random bits to play with (note that unique local ipv6 addresses are not global: they are not globally routeable so an address only needs to be unique inside the MANET). > - Globally unique IDs must be long to be able to uniquely identify all > existing devices and hence significantly increase signaling traffic. hmm .. not sure what you mean here but the main goal of using randomly generated addresses is to avoid signalling (i.e. to avoid DAD). Do you mean overhead of the routing protocol ? If yes, just note that whatever solution is designed for IPv6 the overhead is the same (howthe IPv6 address is derived makes no difference: it's always 128 bits !). > This has negative implications on the scalability of, e.g., the routing > protocol. Locally unique IDs can be much more efficient, since such > addresses may very short (depending on the size of the network) or can > easily be compressed to short addresses. Our simulations have shown that > 80-90% of routing protocol overhead can be saved with locally unique IDs > (see PACMAN paper referenced in my last mail). I read it a while ago but will have a look asap. > > Especially for larger networks, I'm in favour of locally unique IDs, > which implies that some kind of DAD scheme is needed. If globally unique > IDs are used in the entire network (how does a node know that?), I'm > fine with an optional DAD, but still prefer at least a SHOULD or MUST if > the DAD is efficient in terms of ressource consumption. Still not sure what you mean by "globally" ... with respect to what ? MANET or Internet ? > > Regards, > > Kilian > > >>-----Original Message----- >>From: autoconf-bounces@ietf.org >>[mailto:autoconf-bounces@ietf.org] On Behalf Of Christophe Jelger >>Sent: Donnerstag, 2. Februar 2006 16:10 >>To: Jari Arkko >>Cc: autoconf@ietf.org >>Subject: [Autoconf] The case for address uniqueness >> >>Hi all, >> >>Well we have already had quite a lot of discussions related >>to address >>uniqueness and I strongly support Jari's point to make DAD optional >>(especially if RFC2462 allows to do so). Actually I am in favor of >>getting rid of DAD, only maintaining a minimal scheme to detect and >>resolve address collisions when they occur. >> >>Going back to discussions with Bob Hinden (on this list in >>Feb. 2005 !) >>about the possible use of unique local IPv6 addresses (now >>RFC 4193) as >>MANET-local addresses, Bob agreed (email dated 02/24/2005) that each >>node could generate its own Global ID + subnet ID (56 bits), >>to be added >>to the EUI-64 (with 48 bits supposed to be unique from the >>MAC address). >>Moreover to make it even better, one could replace the ff:fe >>pattern of >>the EUI-64 with a random 16 bits pattern. >> >>This leads to a total of 120 bits, with 80 random bits and a >>sequence of >>48 bits which has a very high probability of being unique. >>Additionaly >>the 80 bits pattern could include machine-specific data that would >>strongly increase the uniqueness of the generated address. >>For example, >>one could include the local date (in unix style, seconds >>elapsed since >>Jan. 1st 1970) when the address is generated: this is only 32 >>bits, but >>is a very strong anti-collision feature. Indeed 2 machines having the >>same MAC address, having generated the same random 48 bits (80-32), >>would have an address collision if they created their >>addresses at the >>very same (local) date !... do we really need a strong DAD >>mechanism to >>handle such highly improbable event ? >> >>Now if global connectivity is required, I personaly think that using >>EUI-64 with the ff:fe pattern replaced with random bits is enough to >>guaranty address uniqueness. >> >>Just my 2 cents ... ;-) >> >>Regards, >>Christophe >> >>Jari Arkko wrote: >> >>>Simone Ruffino wrote: >>> >>> >>>>Anyway, my personal understanding was that AUTOCONF must >> >>necessarily >> >>>>take address uniqueness into account, for two reasons: >> >>Primarily, to >> >>>>address specific problems of MANETs: for example, if two >>>>nodes have the same address, routing in the *whole* MANET >> >>could possibly >> >>>>be compromised. >>>> >>>> >>> >>>Right. Yes, I think I understand this, now. Will this >>>happen always, or is this danger specific to some >>>MANET routing mechanisms? >>> >>> >>>>As a matter of fact, rfc2462 says also that DAD can be >>>>disabled in cases when its overhead outweighs its benefits. >>>> >>> >>>Right. I wouldn't use compliance with RFC 2462 as the >>>main reason for performing duplicate detection. >>> >>> >>>>My conclusion was that a uniqueness check must be defined >> >>for MANETs, >> >>>>but that can possibly be disabled. For this reason, I >> >>would like to have >> >>>>a solution which check uniqueness using an "optimistic" approach >>>>(something similar to optimistic DAD). >>>> >>> >>>Optional optimistic DAD is one approach. But that >>>still leaves some questions to decide. For instance, are >>>the manet-internal addresses and globally reachable >>>addresses the same or different? If they are different, >>>will they be allocated by the same or different mechanisms. >>>For instance, you could use something PACMAN-like >>>for the internal addresses, and then have the globally >>>reachable addresses allocated centrally from the gateway >>>(because obviously you need to be able to reach the >>>gateway or else these addresses aren't useful). >>> >>>--Jari >>> >>> >>>_______________________________________________ >>>Autoconf mailing list >>>Autoconf@ietf.org >>>https://www1.ietf.org/mailman/listinfo/autoconf >>> >> >>_______________________________________________ >>Autoconf mailing list >>Autoconf@ietf.org >>https://www1.ietf.org/mailman/listinfo/autoconf >> >> > > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 02 12:43:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4iUG-0004EI-L1; Thu, 02 Feb 2006 12:43:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4iUF-00047E-Qs for autoconf@megatron.ietf.org; Thu, 02 Feb 2006 12:43:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23415 for ; Thu, 2 Feb 2006 12:41:32 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4ifZ-0004Sj-Ga for autoconf@ietf.org; Thu, 02 Feb 2006 12:54:58 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k12H5oe19956; Thu, 2 Feb 2006 09:05:50 -0800 X-mProtect: <200602021705> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14198.americas.nokia.com (172.18.141.98, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdKdNThq; Thu, 02 Feb 2006 09:05:48 PST Message-ID: <43E24493.2090409@iprg.nokia.com> Date: Thu, 02 Feb 2006 09:42:43 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center, Mtn. View User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt References: <39C363776A4E8C4A94691D2BD9D1C9A1818A18@XCH-NW-7V2.nw.nos.boeing.com> <01fc01c627f0$b9f62b30$6dc6dba8@daniellaptop> <43E2131D.2030402@piuha.net> In-Reply-To: <43E2131D.2030402@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello folks, I've not read all of the emails, but this one caught my eye. Jari Arkko wrote: > Yes, DNS server is needed too, assuming we have > global connectivity. But we may also need other > information, such as NTP servers, local SIP servers > etc. I wonder if there is a way to somehow use DHCP > in this context so that we wouldn't need to invent > all those options again. Wouldn't it make sense to run the gateway as a sort of DHCP relay? But I would think that would be a separate draft. The functions are separable. Plus, such a scheme has to avoid conflicting with the useful possibility that DNS and SIP are present in the manet. Presumably, the local services would be preferred over the infrastructure services in many or most cases. Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 02 12:59:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ijs-00014D-W0; Thu, 02 Feb 2006 12:59:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ijs-00013W-9B for autoconf@megatron.ietf.org; Thu, 02 Feb 2006 12:59:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24648 for ; Thu, 2 Feb 2006 12:57:47 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4ivE-00051P-Ps for autoconf@ietf.org; Thu, 02 Feb 2006 13:11:11 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 02 Feb 2006 09:59:10 -0800 X-IronPort-AV: i="4.01,248,1136188800"; d="scan'208"; a="399924863:sNHT33288972" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k12Hx9jt006685; Thu, 2 Feb 2006 09:59:09 -0800 (PST) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Feb 2006 12:59:08 -0500 Received: from 161.44.65.204 ([161.44.65.204]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Feb 2006 17:59:08 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 02 Feb 2006 12:59:10 -0500 Subject: Re: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt From: Ralph Droms To: Jari Arkko , Soohong Daniel Park Message-ID: Thread-Topic: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt Thread-Index: AcYoIl4jnHuWMpQVEdqhogARJOT6eg== In-Reply-To: <43E2131D.2030402@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Feb 2006 17:59:08.0738 (UTC) FILETIME=[5D629A20:01C62822] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Jari - you could either run a DHCP server providing configuration information (as in RFC 3736) on the network element issuing the RAs or a DHCP relay forwarding to a server on another host. Either way, use of DHCP would leverage re-use of all the existing configuration options... - Ralph On 2/2/06 9:11 AM, "Jari Arkko" wrote: > Yes, DNS server is needed too, assuming we have > global connectivity. But we may also need other > information, such as NTP servers, local SIP servers > etc. I wonder if there is a way to somehow use DHCP > in this context so that we wouldn't need to invent > all those options again. > > --Jari > > Soohong Daniel Park wrote: > >> In addition, current draft is still missing of how DNS Server can be >> configured on the manet node from the global connectivity point of >> view. Perhaps, Ryuji remembers what I am indicating because I did >> raise this concern before. Obtaining DNS Server address is an >> essential part of manet global connectivity, so one option SHOULD >> be attached to the RA option along with Prefix option. You can refer >> to the related work below; >> http://www.watersprings.org/pub/id/draft-daniel-manet-dns-discovery-globalv6- >> 00.txt >> http://www.watersprings.org/pub/id/draft-jeong-dnsop-ipv6-dns-discovery-08.tx>> t >> >> Thanks, >> >> Daniel (Soohong Daniel Park) >> Mobile Convergence Laboratory, SAMSUNG Electronics. >> ----- Original Message ----- >> From: "Templin, Fred L" >> To: >> Sent: Thursday, February 02, 2006 7:03 AM >> Subject: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt >> >> >> I don't know if this is the correct forum, but below are >> some comments on this draft: >> >> Fred >> fred.l.templin@boeing.com >> >> >> 1) In introduction, add DYMO to list of IETF routing protocols. >> >> 2) Second to last paragraph of P.4, change: "whether they are >> reactive and proactive." to: "... reactive or proactive." >> >> 3) Final paragraph of P.4, this text seems to assume that >> internet-gateways maintain a roster of the addresses of >> nodes that reside within the MANET, e.g., so that packets >> destined to MANET nodes don't leak out into the Internet >> and so that ICMP redirects can be issued. This assumption >> needs to be made explicit somehow - both in this section >> and elsewhere throughout the document. >> >> 4) Top of P.6, the sentence: "The node therefore needs to obtain >> a global prefix owned and distributed by an internet-gateway." >> Is the intention here that a prefix must be owned by one >> and only one internet-gateway? Or, could the same prefix >> potentially be advertised by multiple gateways? >> >> 5) Bottom of P.6, change "two messages such as" to "two messages:". >> >> 6) Section 4.3, add a third message type "internet gateway >> confirmation". The purpose of this message is to provide >> a 3-way handshake between manet nodes and internet gateways >> under the following procedure: >> >> 1. manet node sends "internet gateway solicitation" to >> multicast address >> 2. Internet gateway(s) sends "internet gateway advertisement" >> to unicast address of manet node >> 3. manet node sends "internet gateway confirmation" to >> unicast address of internet gateway(s) >> >> The "internet gateway confirm" message is needed to allow the >> internet gateway to construct a roster of the MANET nodes it >> serves. The roster is needed in order for the gateway to >> determine when redirects should be sent for intra-MANET >> communications. >> >> 7) P.11, second sentence beginning with: "Since the manet node is >> assumed to already have done Duplicate Address Detection (DAD), >> as defined in [11], for the link-local address", this does not >> seem to be a valid assumption since there is no way for the node >> to inquire throughout the entire MANET as to whether its link-local >> address is unique within the MANET. Suggest dropping the entire >> discussion on DAD and simply say "DAD is not in scope". >> >> 8) Section 5.5, change: "But it just stop sending..." to: "But it >> SHOULD stop sending...". Also, the rest of this first paragraph >> of section 5.5 seems poorly-worded and imprecise. Suggest either >> a re-write or just remove the text. >> >> 9) Section 6.1, second paragraph. Change: "When an internet-gateway..." >> to: "When a manet node...". >> >> 10) Section 7.3, the verification: "- If the hop limit field of the >> message is less than or equal to zero...", how is the "less than" >> check to be one (i.e., the hop-limit field is just an 8-bit >> unsigned integer). Suggest changing: "less than or equal to zero" >> to simply "equal to zero". >> >> 11) Section 7.3, final sentence (and section 7.4) the "global manet >> node list" spoken of here can only be unidirectional. If an >> "internet gateway confirm" message type is added (as per >> comment 6), the global manet node list can be made bi-directional. >> >> 12) Section 7.5, this entire section seems to assume that internet- >> gateways are assigned prefixes in 1x1 correspondence. As asked >> earlier, can more than one internet-gateway advertise the *same* >> prefix, i.e., can a prefix be co-owned by more than one gateway? >> If yes, then this section would require rewrites. If no, then >> why not? >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www1.ietf.org/mailman/listinfo/autoconf >> >> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www1.ietf.org/mailman/listinfo/autoconf >> >> >> >> > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 02 13:17:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4j1M-00006F-LB; Thu, 02 Feb 2006 13:17:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4j1L-00004y-CS for autoconf@megatron.ietf.org; Thu, 02 Feb 2006 13:17:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25972 for ; Thu, 2 Feb 2006 13:15:50 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4jCk-0005ek-Fh for autoconf@ietf.org; Thu, 02 Feb 2006 13:29:15 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k12He7S10351; Thu, 2 Feb 2006 09:40:07 -0800 X-mProtect: <200602021740> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14198.americas.nokia.com (172.18.141.98, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdmfdQQk; Thu, 02 Feb 2006 09:40:05 PST Message-ID: <43E24C9C.7020506@iprg.nokia.com> Date: Thu, 02 Feb 2006 10:17:00 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center, Mtn. View User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christophe Jelger Subject: Re: [Autoconf] The case for address uniqueness References: <4D2F935F08D41A4C8866693F4F0D7C4F865A2B@lan-ex-01.panasonic.de> <43E23DF9.8000804@unibas.ch> In-Reply-To: <43E23DF9.8000804@unibas.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Christophe, I would like to support the view that we should avoid requirements for a strong DAD mechanism. Christophe Jelger wrote: > > I agree, but whatever solution one designs there can always be cases > of address collisions (network merges, manually configured addresses). > Thus I think the focus should be on address collision detection+repair. > I have two thought experiments that lead me to believe that duplicate address detection is properly the responsibility for the nodes that own the duplicated address. (1): What if a node moves so fast between two parts of the network that it "seems" to be in two places? One could easily imagine that such movement would fit within the time periods defined by local "hello" messages, depending on the range of radio transmission. (2) What if one node leaves the network, and later rejoins? This is certainly a network partition. If each such event causes the network to initiate global signaling for DAD, then a meltdown is almost guaranteed eventually. How can we distinguish between a reboot and a temporary node departure? Is there any real difference as far as the network is concerned? If the node itself detects duplication by any of several heuristics, then it can (a) borrow a new temporary address and (b) take corrective action. Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 02 14:06:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4jmu-0001b9-Nw; Thu, 02 Feb 2006 14:06:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4jmt-0001Zx-BP for autoconf@megatron.ietf.org; Thu, 02 Feb 2006 14:06:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00145 for ; Thu, 2 Feb 2006 14:04:45 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4jy1-0007S2-LT for autoconf@ietf.org; Thu, 02 Feb 2006 14:18:11 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA22373; Thu, 2 Feb 2006 11:05:59 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k12J5wN15321; Thu, 2 Feb 2006 13:05:58 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 11:05:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Autoconf] The case for address uniqueness Date: Thu, 2 Feb 2006 11:05:51 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1818A1E@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: [Autoconf] The case for address uniqueness Thread-Index: AcYoJ+xHXZva6GolR6qBAb0Htc53WQAAXaHQ From: "Templin, Fred L" To: "Charles E. Perkins" X-OriginalArrivalTime: 02 Feb 2006 19:05:52.0148 (UTC) FILETIME=[AF9A7D40:01C6282B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Charlie and others, These discussions have been going on for so many years now that it seems they may never converge on a "one-size-fits-all" solution for MANET autoconfiguration. Is there a chance we could steer things toward a best current practices direction? If so, what would they look like, e.g.: - use IPv6 link-local for neighbor discovery - use IPv6 Unique Local Addresses (ULAs) for intra-MANET comm's - use DHCPv6 to get a globally unique address for Internet comm's Is there a chance we will see some convergence soon or will the status remain quo for the forseeable future? Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]=20 > Sent: Thursday, February 02, 2006 10:17 AM > To: Christophe Jelger > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] The case for address uniqueness >=20 >=20 > Hello Christophe, >=20 > I would like to support the view that we should > avoid requirements for a strong DAD mechanism. >=20 > Christophe Jelger wrote: >=20 > > > > I agree, but whatever solution one designs there can always=20 > be cases=20 > > of address collisions (network merges, manually configured=20 > addresses).=20 > > Thus I think the focus should be on address collision=20 > detection+repair. > > >=20 > I have two thought experiments that lead me to believe that duplicate > address detection is properly the responsibility for the=20 > nodes that own > the duplicated address. >=20 > (1): What if a node moves so fast between two parts of the network > that it "seems" to be in two places? One could=20 > easily imagine that > such movement would fit within the time periods=20 > defined by local > "hello" messages, depending on the range of radio transmission. >=20 > (2) What if one node leaves the network, and later rejoins? This is > certainly a network partition. If each such event=20 > causes the network > to initiate global signaling for DAD, then a meltdown is almost > guaranteed eventually. How can we distinguish between a reboot > and a temporary node departure? Is there any real difference as > far as the network is concerned? >=20 > If the node itself detects duplication by any of several heuristics, > then it can (a) borrow a new temporary address and (b) take > corrective action. >=20 > Regards, > Charlie P. >=20 >=20 >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 02 15:33:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4l9H-0006pJ-Ip; Thu, 02 Feb 2006 15:33:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4l9C-0006nu-3L for autoconf@megatron.ietf.org; Thu, 02 Feb 2006 15:33:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06842 for ; Thu, 2 Feb 2006 15:31:56 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4lKS-000259-Gt for autoconf@ietf.org; Thu, 02 Feb 2006 15:45:23 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k12JtkA02832; Thu, 2 Feb 2006 11:55:46 -0800 X-mProtect: <200602021955> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14198.americas.nokia.com (172.18.141.98, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdaP2Noa; Thu, 02 Feb 2006 11:55:43 PST Message-ID: <43E26C67.2000802@iprg.nokia.com> Date: Thu, 02 Feb 2006 12:32:39 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center, Mtn. View User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ext Templin, Fred L" Subject: Re: [Autoconf] The case for address uniqueness References: <39C363776A4E8C4A94691D2BD9D1C9A1818A1E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1818A1E@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Fred, ext Templin, Fred L wrote: >These discussions have been going on for so many years now that >it seems they may never converge on a "one-size-fits-all" solution >for MANET autoconfiguration. > This may not be a good indicator, though, since autoconfiguration has never been on the charter for MANET as far as I remember. > Is there a chance we could steer >things toward a best current practices direction? If so, what >would they look like, e.g.: > > - use IPv6 link-local for neighbor discovery > > I would prefer not to make this constraint. By doing so, the neighbor discovery process is then required to suffer multiple rounds of signaling just to get neighbors to know the node's useful IP address. > - use IPv6 Unique Local Addresses (ULAs) for intra-MANET comm's > > This sounds great for nodes that don't already have global addresses. > - use DHCPv6 to get a globally unique address for Internet comm's > > I would prefer a stateless approach whenever it's available. >Is there a chance we will see some convergence soon or will the >status remain quo for the forseeable future? > > I guess both are very possible. It's up to us! The fact that the working group has been approved is a good sign, though. Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 02 17:34:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4n2A-0004Pl-MT; Thu, 02 Feb 2006 17:34:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4n28-0004OB-Um for autoconf@megatron.ietf.org; Thu, 02 Feb 2006 17:34:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22804 for ; Thu, 2 Feb 2006 17:32:52 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4nDW-0000Sf-E6 for autoconf@ietf.org; Thu, 02 Feb 2006 17:46:21 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA23347; Thu, 2 Feb 2006 14:34:04 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k12MY4W24547; Thu, 2 Feb 2006 14:34:04 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 14:34:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Autoconf] The case for address uniqueness Date: Thu, 2 Feb 2006 14:34:01 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1818A22@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: [Autoconf] The case for address uniqueness Thread-Index: AcYoOM7huDRqRJ8pSyaqQnnS08E4jgADeWDg From: "Templin, Fred L" To: "Charles E. Perkins" X-OriginalArrivalTime: 02 Feb 2006 22:34:01.0863 (UTC) FILETIME=[C40DC170:01C62848] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Charlie, OK to most of what you said, but is there really such a thing as "stateless" address autoconfiguration without also requiring a robust DAD mechanism? DAD is hard in MANETs due to the reasons you gave in an earlier message (partitions and merges) and it won't be made easier when nodes start using interface ID generation mechanisms like CGA instead of assigning an interface's MAC address. Can we rely on optimistic DAD and/or DAD avoidance? Thanks - Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]=20 > Sent: Thursday, February 02, 2006 12:33 PM > To: Templin, Fred L > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] The case for address uniqueness >=20 >=20 > Hello Fred, >=20 >=20 > ext Templin, Fred L wrote: >=20 > >These discussions have been going on for so many years now that > >it seems they may never converge on a "one-size-fits-all" solution > >for MANET autoconfiguration. > > > This may not be a good indicator, though, since autoconfiguration has > never been on the charter for MANET as far as I remember. >=20 > > Is there a chance we could steer > >things toward a best current practices direction? If so, what > >would they look like, e.g.: > > > > - use IPv6 link-local for neighbor discovery > > =20 > > > I would prefer not to make this constraint. By doing so, the neighbor > discovery process is then required to suffer multiple rounds=20 > of signaling > just to get neighbors to know the node's useful IP address. >=20 > > - use IPv6 Unique Local Addresses (ULAs) for intra-MANET comm's > > =20 > > > This sounds great for nodes that don't already have global addresses. >=20 > > - use DHCPv6 to get a globally unique address for Internet comm's > > =20 > > > I would prefer a stateless approach whenever it's available. >=20 > >Is there a chance we will see some convergence soon or will the > >status remain quo for the forseeable future? > > =20 > > > I guess both are very possible. It's up to us! The fact that the > working group has been approved is a good sign, though. >=20 > Regards, > Charlie P. >=20 >=20 >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 02 19:13:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4oa4-0002YR-4M; Thu, 02 Feb 2006 19:13:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4oZn-0002X0-NM for autoconf@megatron.ietf.org; Thu, 02 Feb 2006 19:13:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29794 for ; Thu, 2 Feb 2006 19:11:28 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4okv-0003ua-Ii for autoconf@ietf.org; Thu, 02 Feb 2006 19:24:56 -0500 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IU300BTV4LBAX@mailout2.samsung.com> for autoconf@ietf.org; Fri, 03 Feb 2006 09:12:47 +0900 (KST) Received: from daniellaptop ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IU3000HL4LAX1@mmp1.samsung.com> for autoconf@ietf.org; Fri, 03 Feb 2006 09:12:47 +0900 (KST) Date: Fri, 03 Feb 2006 09:13:10 +0900 From: Soohong Daniel Park Subject: Re: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt To: Ralph Droms , Jari Arkko Message-id: <012101c62856$9e062860$6dc6dba8@daniellaptop> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: 7BIT Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org I was saying that DNS option should be included into the manet RA message while modifying it to be adopted to the at least *mobile* adhoc environment. NTP, SIP and others can be also considered simuntaneously, but I believe DNS is most preferable information from the autoconf point of view. Others can be deliveried using DHCP whenever necessary. Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. ----- Original Message ----- From: "Ralph Droms" To: "Jari Arkko" ; "Soohong Daniel Park" Cc: Sent: Friday, February 03, 2006 2:59 AM Subject: Re: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt > Jari - you could either run a DHCP server providing configuration > information (as in RFC 3736) on the network element issuing the RAs or a > DHCP relay forwarding to a server on another host. Either way, use of DHCP > would leverage re-use of all the existing configuration options... > > - Ralph > > > On 2/2/06 9:11 AM, "Jari Arkko" wrote: > > > Yes, DNS server is needed too, assuming we have > > global connectivity. But we may also need other > > information, such as NTP servers, local SIP servers > > etc. I wonder if there is a way to somehow use DHCP > > in this context so that we wouldn't need to invent > > all those options again. > > > > --Jari > > > > Soohong Daniel Park wrote: > > > >> In addition, current draft is still missing of how DNS Server can be > >> configured on the manet node from the global connectivity point of > >> view. Perhaps, Ryuji remembers what I am indicating because I did > >> raise this concern before. Obtaining DNS Server address is an > >> essential part of manet global connectivity, so one option SHOULD > >> be attached to the RA option along with Prefix option. You can refer > >> to the related work below; > >> http://www.watersprings.org/pub/id/draft-daniel-manet-dns-discovery-globalv6- > >> 00.txt > >> > http://www.watersprings.org/pub/id/draft-jeong-dnsop-ipv6-dns-discovery-08.tx>> > t > >> > >> Thanks, > >> > >> Daniel (Soohong Daniel Park) > >> Mobile Convergence Laboratory, SAMSUNG Electronics. > >> ----- Original Message ----- > >> From: "Templin, Fred L" > >> To: > >> Sent: Thursday, February 02, 2006 7:03 AM > >> Subject: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt > >> > >> > >> I don't know if this is the correct forum, but below are > >> some comments on this draft: > >> > >> Fred > >> fred.l.templin@boeing.com > >> > >> > >> 1) In introduction, add DYMO to list of IETF routing protocols. > >> > >> 2) Second to last paragraph of P.4, change: "whether they are > >> reactive and proactive." to: "... reactive or proactive." > >> > >> 3) Final paragraph of P.4, this text seems to assume that > >> internet-gateways maintain a roster of the addresses of > >> nodes that reside within the MANET, e.g., so that packets > >> destined to MANET nodes don't leak out into the Internet > >> and so that ICMP redirects can be issued. This assumption > >> needs to be made explicit somehow - both in this section > >> and elsewhere throughout the document. > >> > >> 4) Top of P.6, the sentence: "The node therefore needs to obtain > >> a global prefix owned and distributed by an internet-gateway." > >> Is the intention here that a prefix must be owned by one > >> and only one internet-gateway? Or, could the same prefix > >> potentially be advertised by multiple gateways? > >> > >> 5) Bottom of P.6, change "two messages such as" to "two messages:". > >> > >> 6) Section 4.3, add a third message type "internet gateway > >> confirmation". The purpose of this message is to provide > >> a 3-way handshake between manet nodes and internet gateways > >> under the following procedure: > >> > >> 1. manet node sends "internet gateway solicitation" to > >> multicast address > >> 2. Internet gateway(s) sends "internet gateway advertisement" > >> to unicast address of manet node > >> 3. manet node sends "internet gateway confirmation" to > >> unicast address of internet gateway(s) > >> > >> The "internet gateway confirm" message is needed to allow the > >> internet gateway to construct a roster of the MANET nodes it > >> serves. The roster is needed in order for the gateway to > >> determine when redirects should be sent for intra-MANET > >> communications. > >> > >> 7) P.11, second sentence beginning with: "Since the manet node is > >> assumed to already have done Duplicate Address Detection (DAD), > >> as defined in [11], for the link-local address", this does not > >> seem to be a valid assumption since there is no way for the node > >> to inquire throughout the entire MANET as to whether its link-local > >> address is unique within the MANET. Suggest dropping the entire > >> discussion on DAD and simply say "DAD is not in scope". > >> > >> 8) Section 5.5, change: "But it just stop sending..." to: "But it > >> SHOULD stop sending...". Also, the rest of this first paragraph > >> of section 5.5 seems poorly-worded and imprecise. Suggest either > >> a re-write or just remove the text. > >> > >> 9) Section 6.1, second paragraph. Change: "When an internet-gateway..." > >> to: "When a manet node...". > >> > >> 10) Section 7.3, the verification: "- If the hop limit field of the > >> message is less than or equal to zero...", how is the "less than" > >> check to be one (i.e., the hop-limit field is just an 8-bit > >> unsigned integer). Suggest changing: "less than or equal to zero" > >> to simply "equal to zero". > >> > >> 11) Section 7.3, final sentence (and section 7.4) the "global manet > >> node list" spoken of here can only be unidirectional. If an > >> "internet gateway confirm" message type is added (as per > >> comment 6), the global manet node list can be made bi-directional. > >> > >> 12) Section 7.5, this entire section seems to assume that internet- > >> gateways are assigned prefixes in 1x1 correspondence. As asked > >> earlier, can more than one internet-gateway advertise the *same* > >> prefix, i.e., can a prefix be co-owned by more than one gateway? > >> If yes, then this section would require rewrites. If no, then > >> why not? > >> > >> _______________________________________________ > >> Autoconf mailing list > >> Autoconf@ietf.org > >> https://www1.ietf.org/mailman/listinfo/autoconf > >> > >> > >> > >> _______________________________________________ > >> Autoconf mailing list > >> Autoconf@ietf.org > >> https://www1.ietf.org/mailman/listinfo/autoconf > >> > >> > >> > >> > > > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www1.ietf.org/mailman/listinfo/autoconf > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Feb 03 04:16:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4x3G-0003Hy-Di; Fri, 03 Feb 2006 04:16:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4x3C-00039F-1M for autoconf@megatron.ietf.org; Fri, 03 Feb 2006 04:16:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08138 for ; Fri, 3 Feb 2006 04:14:39 -0500 (EST) Received: from cluster-d.mailcontrol.com ([217.69.20.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4xEi-0005QY-1b for autoconf@ietf.org; Fri, 03 Feb 2006 04:28:13 -0500 Received: from rly37d.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly37d.srv.mailcontrol.com (MailControl) with ESMTP id k139Fw3e025610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 Feb 2006 09:16:00 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly37d.srv.mailcontrol.com (MailControl) id k139F5iB023023 for autoconf@ietf.org; Fri, 3 Feb 2006 09:15:05 GMT Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly37d-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id k139Ep9Z022409; Fri, 03 Feb 2006 09:15:04 +0000 (GMT) Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 6aba_6c56ed1e_948e_11da_9bb2_0030482aac25; Fri, 03 Feb 2006 09:23:57 +0100 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.2) with ESMTP id 2006020310144396-712339 ; Fri, 3 Feb 2006 10:14:43 +0100 Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Fri, 3 Feb 2006 10:17:29 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Autoconf] The case for address uniqueness Thread-Topic: [Autoconf] The case for address uniqueness Thread-Index: AcYoHDDGevdzKH/yRWmlieb3GXgymAAeIdiQ To: "Christophe Jelger" Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4F865A78@lan-ex-01.panasonic.de> Date: Fri, 3 Feb 2006 10:14:38 +0100 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-06-00-02 (www.mailcontrol.com) on 10.68.1.147 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Christoph, thanks for your comments. See my comments inline > -----Original Message----- > From: Christophe Jelger [mailto:Christophe.Jelger@unibas.ch]=20 > Sent: Donnerstag, 2. Februar 2006 18:15 > To: Kilian Weniger > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] The case for address uniqueness >=20 > Hi Kilian, >=20 > Thanks for your answer. Actually I understand your points, and such=20 > things have already been discussed on the list and *all these=20 > comments=20 > make sense*. Now I think it's time to get rid of our=20 > researchers' hats,=20 > and put on the engineers' hats: what's the easiest solution,=20 > and how can=20 > we quickly standardize a solution that works ? Everybody=20 > knows the IETF=20 > standardization is a very slow process, but it would be nice=20 > to converge=20 > to some solutions before it's too late for mass people to widely use=20 > MANET technologies. Yes, I agree that a solution should be standardized quickly. I guess a widely accepted approach is to develop a basic solution first and optimizations (like the one I mentioned in my last bullet point) later... >=20 > See my comments inline below. >=20 > Best regards, > Christophe >=20 > Kilian Weniger wrote: > > Hi Christoph, all, > >=20 > > I agree that the probability of collision is very low in case of > > EUI-64-based IPv6 addresses (especially with the measures=20 > you mentioned > > in your mail), but I want to raise awareness of the=20 > following related > > issues:=20 >=20 > Good start... in a very sarcastic way I realize that most=20 > people on the=20 > list agrees on this but still there is quite a strong human=20 > resistance=20 > against the simplicity of randomly-generated addresses. Just to be=20 > clear, I do not advocate the blind use of randomly-generated=20 > addresses,=20 > but rather want to stress the fact that DAD should be as=20 > lightweight as=20 > possible because the probability of collisions is extremely low. we agree on that point. >=20 > >=20 > > - Duplicate addresses have significant impacts on the=20 > routing of data > > packets and may lead to permanent packet loss >=20 > I agree, but whatever solution one designs there can always=20 > be cases of=20 > address collisions (network merges, manually configured=20 > addresses). Thus=20 > I think the focus should be on address collision detection+repair. Yes, I agree.=20 >=20 > > - Globally unique addressing is only possible with IPv6,=20 > not with IPv4 >=20 > I am not sure what you mean by globally here: MANET globally=20 > or Internet=20 > globally ? Just to make sure we are on the same wavelength, unique=20 > local IPv6 addresses are "site-local" and are not globally routeable.=20 > Now considering IPv4, if say I use private 10.0.0.0 class A addresses=20 > inside the MANET, I still have 2^24 different addresses (16=20 > millions) so=20 > that's quite a low probability of collisions. Also note that the=20 > AUTOCONF charter is focused on IPv4 so I have to admit I don't really=20 > consider IPv4 . I guess you intended to say the charter focus on IPv6 ;) Maybe the term "globally unique addressing" is mistakable. What I meant with this term is the use of MANET-local IP addresses based on a globally unique ID such as EUI-64. I was not talking about globally routable addresses. >=20 > > - Those IDs are not 100\% globally unique, e.g., a IEEE MAC address > > configured at a specific network interface may be changed=20 > by the user, > > known instances of devices with duplicate MAC addresses exist on the > > market (e.g., non-registered or erroneous manufacturing), and some > > devices may not have globally unique hardware IDs at all=20 > (e.g., sensors) >=20 > Yes but as I said in my email, I still have another 72 bits=20 > (not 80 as=20 > wrongly written in my previous email) to make the difference ! I see. This signficantly reduces the probability of conflict, which might make DAD dispensable. Of course, users can still manually change the network interface IP address... >=20 > > - Globally unique IDs may have negative implications on privacy (see > > RFC3041) >=20 > Great, so you're in favor of generating random EUI-64 ? ;-)=20 > So am I, and=20 > we now have 120 random bits to play with (note that unique local ipv6=20 > addresses are not global: they are not globally routeable so=20 > an address=20 > only needs to be unique inside the MANET). Yes, I'm in favour of IPv6 addresses with random interface identifier as well (BTW, I guess an EUI-64 cannot be random, right?). With globally unique IDs I meant EUI-64-based (non-random) addresses. >=20 > > - Globally unique IDs must be long to be able to uniquely=20 > identify all > > existing devices and hence significantly increase signaling traffic. >=20 > hmm .. not sure what you mean here but the main goal of using=20 > randomly=20 > generated addresses is to avoid signalling (i.e. to avoid=20 > DAD). Do you=20 > mean overhead of the routing protocol ? If yes, just note=20 > that whatever=20 > solution is designed for IPv6 the overhead is the same (howthe IPv6=20 > address is derived makes no difference: it's always 128 bits !). What I meant is an optimization (used by PACMAN): The idea is that signaling overhead can be significantly reduced if only a subset of the bits are used.=20 If, e.g., only 24 bits of the interface identifier are random and the rest is set to zero, the IPv6 address can be compressed to a shorter ID, which then is transmitted in routing protocol messages (instead of the IPv6 address). Of course the probability of conflict increases, hence you probably need some kind of DAD. But the savings in terms of routing protocol overhead can be significant. >=20 > > This has negative implications on the scalability of, e.g.,=20 > the routing > > protocol. Locally unique IDs can be much more efficient, since such > > addresses may very short (depending on the size of the=20 > network) or can > > easily be compressed to short addresses. Our simulations=20 > have shown that > > 80-90% of routing protocol overhead can be saved with=20 > locally unique IDs > > (see PACMAN paper referenced in my last mail). >=20 > I read it a while ago but will have a look asap. >=20 > >=20 > > Especially for larger networks, I'm in favour of locally unique IDs, > > which implies that some kind of DAD scheme is needed. If=20 > globally unique > > IDs are used in the entire network (how does a node know that?), I'm > > fine with an optional DAD, but still prefer at least a=20 > SHOULD or MUST if > > the DAD is efficient in terms of ressource consumption. >=20 > Still not sure what you mean by "globally" ... with respect to what ?=20 > MANET or Internet ? With globally unique ID I meant EUI-64-based addresses. With locally unique ID I meant MANET-local addresses with a random interface-identifier. Maybe Sorry, maybe this terminology is a bit confusing... Overall, I think your proposal of 72 random bits + EUI-64 (I prefer a random interface identifier instead of EUI-64, mainly for privacy reasons) may solve the network merging problem (without DAD) for many scenarios from an engineering point of view, at least if we don't want to consider that users may manually assign an IP address. It may be good for a basic solution. But I think we should at some point of time consider optimizations, e.g., like the one I mentioned (use subset of bits to enable compression of IPv6 addresses in routing protocol messages) in order to increase scalability and support larger networks. Such an optimization requires an efficient ongoing DAD. Regards, Kilian >=20 > >=20 > > Regards, > >=20 > > Kilian > >=20 > >=20 > >>-----Original Message----- > >>From: autoconf-bounces@ietf.org=20 > >>[mailto:autoconf-bounces@ietf.org] On Behalf Of Christophe Jelger > >>Sent: Donnerstag, 2. Februar 2006 16:10 > >>To: Jari Arkko > >>Cc: autoconf@ietf.org > >>Subject: [Autoconf] The case for address uniqueness > >> > >>Hi all, > >> > >>Well we have already had quite a lot of discussions related=20 > >>to address=20 > >>uniqueness and I strongly support Jari's point to make DAD optional=20 > >>(especially if RFC2462 allows to do so). Actually I am in favor of=20 > >>getting rid of DAD, only maintaining a minimal scheme to detect and=20 > >>resolve address collisions when they occur. > >> > >>Going back to discussions with Bob Hinden (on this list in=20 > >>Feb. 2005 !)=20 > >>about the possible use of unique local IPv6 addresses (now=20 > >>RFC 4193) as=20 > >>MANET-local addresses, Bob agreed (email dated 02/24/2005)=20 > that each=20 > >>node could generate its own Global ID + subnet ID (56 bits),=20 > >>to be added=20 > >>to the EUI-64 (with 48 bits supposed to be unique from the=20 > >>MAC address).=20 > >>Moreover to make it even better, one could replace the ff:fe=20 > >>pattern of=20 > >>the EUI-64 with a random 16 bits pattern. > >> > >>This leads to a total of 120 bits, with 80 random bits and a=20 > >>sequence of=20 > >>48 bits which has a very high probability of being unique.=20 > >>Additionaly=20 > >>the 80 bits pattern could include machine-specific data that would=20 > >>strongly increase the uniqueness of the generated address.=20 > >>For example,=20 > >>one could include the local date (in unix style, seconds=20 > >>elapsed since=20 > >>Jan. 1st 1970) when the address is generated: this is only 32=20 > >>bits, but=20 > >>is a very strong anti-collision feature. Indeed 2 machines=20 > having the=20 > >>same MAC address, having generated the same random 48 bits (80-32),=20 > >>would have an address collision if they created their=20 > >>addresses at the=20 > >>very same (local) date !... do we really need a strong DAD=20 > >>mechanism to=20 > >>handle such highly improbable event ? > >> > >>Now if global connectivity is required, I personaly think=20 > that using=20 > >>EUI-64 with the ff:fe pattern replaced with random bits is=20 > enough to=20 > >>guaranty address uniqueness. > >> > >>Just my 2 cents ... ;-) > >> > >>Regards, > >>Christophe > >> > >>Jari Arkko wrote: > >> > >>>Simone Ruffino wrote: > >>> > >>> > >>>>Anyway, my personal understanding was that AUTOCONF must=20 > >> > >>necessarily > >> > >>>>take address uniqueness into account, for two reasons:=20 > >> > >>Primarily, to=20 > >> > >>>>address specific problems of MANETs: for example, if two > >>>>nodes have the same address, routing in the *whole* MANET=20 > >> > >>could possibly > >> > >>>>be compromised. > >>>>=20 > >>>> > >>> > >>>Right. Yes, I think I understand this, now. Will this > >>>happen always, or is this danger specific to some > >>>MANET routing mechanisms? > >>> > >>> > >>>>As a matter of fact, rfc2462 says also that DAD can be > >>>>disabled in cases when its overhead outweighs its benefits. =20 > >>>> > >>> > >>>Right. I wouldn't use compliance with RFC 2462 as the > >>>main reason for performing duplicate detection. > >>> > >>> > >>>>My conclusion was that a uniqueness check must be defined=20 > >> > >>for MANETs, > >> > >>>>but that can possibly be disabled. For this reason, I=20 > >> > >>would like to have > >> > >>>>a solution which check uniqueness using an "optimistic" approach > >>>>(something similar to optimistic DAD). =20 > >>>> > >>> > >>>Optional optimistic DAD is one approach. But that > >>>still leaves some questions to decide. For instance, are > >>>the manet-internal addresses and globally reachable > >>>addresses the same or different? If they are different, > >>>will they be allocated by the same or different mechanisms. > >>>For instance, you could use something PACMAN-like > >>>for the internal addresses, and then have the globally > >>>reachable addresses allocated centrally from the gateway > >>>(because obviously you need to be able to reach the > >>>gateway or else these addresses aren't useful). > >>> > >>>--Jari > >>> > >>> > >>>_______________________________________________ > >>>Autoconf mailing list > >>>Autoconf@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/autoconf > >>> > >> > >>_______________________________________________ > >>Autoconf mailing list > >>Autoconf@ietf.org > >>https://www1.ietf.org/mailman/listinfo/autoconf > >> > >> > >=20 > >=20 > >=20 >=20 >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Feb 03 05:29:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4yBu-0002Z9-Qd; Fri, 03 Feb 2006 05:29:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4yBp-0002Xz-6l for autoconf@megatron.ietf.org; Fri, 03 Feb 2006 05:29:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13269 for ; Fri, 3 Feb 2006 05:27:28 -0500 (EST) Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4yNB-0007ci-Lr for autoconf@ietf.org; Fri, 03 Feb 2006 05:41:04 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 5FAE31FB01D; Fri, 3 Feb 2006 11:28:37 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11556-01-26; Fri, 3 Feb 2006 11:28:34 +0100 (CET) Received: from [192.168.1.34] (dibulibu.um.es [155.54.1.250]) by mail.um.es (Postfix) with ESMTP id 7C45C1FAAAE; Fri, 3 Feb 2006 11:28:26 +0100 (CET) Message-ID: <43E33057.1080607@dif.um.es> Date: Fri, 03 Feb 2006 11:28:39 +0100 From: "Pedro M. Ruiz" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: [Autoconf] The case for address uniqueness References: <39C363776A4E8C4A94691D2BD9D1C9A1818A22@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1818A22@XCH-NW-7V2.nw.nos.boeing.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1465564046==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1465564046== Content-Type: multipart/alternative; boundary="------------090106020804030509000309" This is a multi-part message in MIME format. --------------090106020804030509000309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I think there is a very good reason to go for stateless address autoconfiguration which is that fact that the MANET must keep on working even if connectivity to Internet is completely lost for some period of time. My second point is that if we agree that duplication is expected to be unlikely to happen, we can live with the assumption that there is no duplication. In case of duplication, we can let those nodes with duplicate addresses to solve the issue if its eventually happens. Given that it won't happen too often, peformance shouldn't be compromised by such DAD resolution scheme. Regards, --Pedro Templin, Fred L wrote: >Charlie, > >OK to most of what you said, but is there really such a thing >as "stateless" address autoconfiguration without also requiring >a robust DAD mechanism? DAD is hard in MANETs due to the reasons >you gave in an earlier message (partitions and merges) and it >won't be made easier when nodes start using interface ID generation >mechanisms like CGA instead of assigning an interface's MAC address. >Can we rely on optimistic DAD and/or DAD avoidance? > >Thanks - Fred >fred.l.templin@boeing.com > > > > >>-----Original Message----- >>From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] >>Sent: Thursday, February 02, 2006 12:33 PM >>To: Templin, Fred L >>Cc: autoconf@ietf.org >>Subject: Re: [Autoconf] The case for address uniqueness >> >> >>Hello Fred, >> >> >>ext Templin, Fred L wrote: >> >> >> >>>These discussions have been going on for so many years now that >>>it seems they may never converge on a "one-size-fits-all" solution >>>for MANET autoconfiguration. >>> >>> >>> >>This may not be a good indicator, though, since autoconfiguration has >>never been on the charter for MANET as far as I remember. >> >> >> >>>Is there a chance we could steer >>>things toward a best current practices direction? If so, what >>>would they look like, e.g.: >>> >>> - use IPv6 link-local for neighbor discovery >>> >>> >>> >>> >>I would prefer not to make this constraint. By doing so, the neighbor >>discovery process is then required to suffer multiple rounds >>of signaling >>just to get neighbors to know the node's useful IP address. >> >> >> >>> - use IPv6 Unique Local Addresses (ULAs) for intra-MANET comm's >>> >>> >>> >>> >>This sounds great for nodes that don't already have global addresses. >> >> >> >>> - use DHCPv6 to get a globally unique address for Internet comm's >>> >>> >>> >>> >>I would prefer a stateless approach whenever it's available. >> >> >> >>>Is there a chance we will see some convergence soon or will the >>>status remain quo for the forseeable future? >>> >>> >>> >>> >>I guess both are very possible. It's up to us! The fact that the >>working group has been approved is a good sign, though. >> >>Regards, >>Charlie P. >> >> >> >> >> > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www1.ietf.org/mailman/listinfo/autoconf > > > --------------090106020804030509000309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think there is a very good reason to go for stateless address autoconfiguration which is that fact that the MANET must keep on working even if connectivity to Internet is completely lost for some period of time.

My second point is that if we agree that duplication is expected to be unlikely to happen, we can live with the assumption that there is no duplication. In case of duplication, we can let those nodes with duplicate addresses to solve the issue if its eventually happens. Given that it won't happen too often, peformance shouldn't be compromised by such DAD resolution scheme.

Regards,

--Pedro

Templin, Fred L wrote: 
Charlie,

OK to most of what you said, but is there really such a thing
as "stateless" address autoconfiguration without also requiring
a robust DAD mechanism? DAD is hard in MANETs due to the reasons
you gave in an earlier message (partitions and merges) and it
won't be made easier when nodes start using interface ID generation
mechanisms like CGA instead of assigning an interface's MAC address.
Can we rely on optimistic DAD and/or DAD avoidance?

Thanks - Fred
fred.l.templin@boeing.com
   

  
-----Original Message-----
From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] 
Sent: Thursday, February 02, 2006 12:33 PM
To: Templin, Fred L
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] The case for address uniqueness


Hello Fred,


ext Templin, Fred L wrote:

    
These discussions have been going on for so many years now that
it seems they may never converge on a "one-size-fits-all" solution
for MANET autoconfiguration.

      
This may not be a good indicator, though, since autoconfiguration has
never been on the charter for MANET as far as I remember.

    
Is there a chance we could steer
things toward a best current practices direction? If so, what
would they look like, e.g.:

 - use IPv6 link-local for neighbor discovery
 

      
I would prefer not to make this constraint.  By doing so, the neighbor
discovery process is then required to suffer multiple rounds 
of signaling
just to get neighbors to know the node's useful IP address.

    
 - use IPv6 Unique Local Addresses (ULAs) for intra-MANET comm's
 

      
This sounds great for nodes that don't already have global addresses.

    
 - use DHCPv6 to get a globally unique address for Internet comm's
 

      
I would prefer a stateless approach whenever it's available.

    
Is there a chance we will see some convergence soon or will the
status remain quo for the forseeable future?
 

      
I guess both are very possible.  It's up to us!  The fact that the
working group has been approved is a good sign, though.

Regards,
Charlie P.



    

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

--------------090106020804030509000309-- --===============1465564046== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf --===============1465564046==-- From autoconf-bounces@ietf.org Fri Feb 03 05:44:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4yQX-0000LA-RU; Fri, 03 Feb 2006 05:44:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4yQW-0000KJ-Ii for autoconf@megatron.ietf.org; Fri, 03 Feb 2006 05:44:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15286 for ; Fri, 3 Feb 2006 05:42:40 -0500 (EST) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4ybv-0008AL-EN for autoconf@ietf.org; Fri, 03 Feb 2006 05:56:16 -0500 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IU300G6NXTGPT@dns1.cselt.it> for autoconf@ietf.org; Fri, 03 Feb 2006 11:44:04 +0100 (MET) Received: from EXC01A.cselt.it ([163.162.4.198]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Fri, 03 Feb 2006 11:44:04 +0100 Date: Fri, 03 Feb 2006 11:44:03 +0100 From: Simone Ruffino Subject: RE: [Autoconf] Re: [MANET-AUTOCONF] Re: review ofdraft-singh-autoconf-adp-02 To: autoconf@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Autoconf] Re: [MANET-AUTOCONF] Re: review ofdraft-singh-autoconf-adp-02 Thread-Index: AcYoA9ZRzUAmwkSRSXqOuo+G+O15awAmUPpA Content-class: urn:content-classes:message X-OriginalArrivalTime: 03 Feb 2006 10:44:04.0096 (UTC) FILETIME=[C0381800:01C628AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Please, see my comments below. Regards, Simone > -----Original Message----- > From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On = Behalf > Of Jari Arkko > Sent: gioved=EC 2 febbraio 2006 15.02 > To: autoconf@ietf.org > Subject: [Autoconf] Re: [MANET-AUTOCONF] Re: review = ofdraft-singh-autoconf- > adp-02 >=20 > Simone Ruffino wrote: >=20 > >Anyway, my personal understanding was that AUTOCONF must necessarily > >take address uniqueness into account, for two reasons: > >Primarily, to address specific problems of MANETs: for example, if = two > >nodes have the same address, routing in the *whole* MANET could = possibly > >be compromised. > > > > > Right. Yes, I think I understand this, now. Will this > happen always, or is this danger specific to some > MANET routing mechanisms? =20 [Simone] I believe it can happen with every routing protocol, although = in different ways. I tend to think that you might experience more = problems with proactive protocols (e.g. olsr), because wrong topology = information is distributed to all nodes.=20 However, the real impact of duplicated addresses on routing protocols = can be examined only with simulations (or experiments). It would be = interesting (and beneficial to our work) to know whether someone on this = list has some results on this! >=20 > >As a matter of fact, rfc2462 says also that DAD can be > >disabled in cases when its overhead outweighs its benefits. > > > > > Right. I wouldn't use compliance with RFC 2462 as the > main reason for performing duplicate detection. >=20 > >My conclusion was that a uniqueness check must be defined for MANETs, > >but that can possibly be disabled. For this reason, I would like to = have > >a solution which check uniqueness using an "optimistic" approach > >(something similar to optimistic DAD). > > > > > Optional optimistic DAD is one approach. But that > still leaves some questions to decide. For instance, are > the manet-internal addresses and globally reachable > addresses the same or different?=20 [Simone] I think what you call "MANET-internal" are, in my view, = MANET-local addresses (they can be ULA). In this sense, they are = different from global addresses (obviously). But, a node can use global = addresses also for comms within the MANET, if it has one. > If they are different, > will they be allocated by the same or different mechanisms. [Simone] I prefer consider them as separated mechanisms, because the = first one must work in an isolated (or temporary disconnected) MANET, = without relying on gateways or servers located in the Internet.=20 > For instance, you could use something PACMAN-like > for the internal addresses, and then have the globally > reachable addresses allocated centrally from the gateway > (because obviously you need to be able to reach the > gateway or else these addresses aren't useful). >=20 > --Jari >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =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=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 CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. 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=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 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Feb 03 06:12:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4yrq-0001vf-DM; Fri, 03 Feb 2006 06:12:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4yrp-0001us-3g for autoconf@megatron.ietf.org; Fri, 03 Feb 2006 06:12:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17379 for ; Fri, 3 Feb 2006 06:10:52 -0500 (EST) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4z3D-0000W4-L1 for autoconf@ietf.org; Fri, 03 Feb 2006 06:24:28 -0500 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IU300B0SZ4KHB@dns2.cselt.it> for autoconf@ietf.org; Fri, 03 Feb 2006 12:12:20 +0100 (MET) Received: from EXC01A.cselt.it ([163.162.4.198]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Fri, 03 Feb 2006 12:11:51 +0100 Date: Fri, 03 Feb 2006 12:12:20 +0100 From: Simone Ruffino Subject: RE: [Autoconf] The case for address uniqueness To: autoconf@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Autoconf] The case for address uniqueness Thread-Index: AcYoJ+xHXZva6GolR6qBAb0Htc53WQAAXaHQACJMQdA= Content-class: urn:content-classes:message X-OriginalArrivalTime: 03 Feb 2006 11:11:51.0812 (UTC) FILETIME=[A2415C40:01C628B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Maybe address scoping could be addressed in the "MANET architecture" = draft, which can be a starting point to reach an agreement on this.=20 What do you think? Regards, Simone > -----Original Message----- > From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On = Behalf > Of Templin, Fred L > Sent: gioved=EC 2 febbraio 2006 20.06 > To: Charles E. Perkins > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] The case for address uniqueness >=20 > Charlie and others, >=20 > These discussions have been going on for so many years now that > it seems they may never converge on a "one-size-fits-all" solution > for MANET autoconfiguration. Is there a chance we could steer > things toward a best current practices direction? If so, what > would they look like, e.g.: >=20 > - use IPv6 link-local for neighbor discovery > - use IPv6 Unique Local Addresses (ULAs) for intra-MANET comm's > - use DHCPv6 to get a globally unique address for Internet comm's >=20 > Is there a chance we will see some convergence soon or will the > status remain quo for the forseeable future? >=20 > Fred > fred.l.templin@boeing.com >=20 >=20 > > -----Original Message----- > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > Sent: Thursday, February 02, 2006 10:17 AM > > To: Christophe Jelger > > Cc: autoconf@ietf.org > > Subject: Re: [Autoconf] The case for address uniqueness > > > > > > Hello Christophe, > > > > I would like to support the view that we should > > avoid requirements for a strong DAD mechanism. > > > > Christophe Jelger wrote: > > > > > > > > I agree, but whatever solution one designs there can always > > be cases > > > of address collisions (network merges, manually configured > > addresses). > > > Thus I think the focus should be on address collision > > detection+repair. > > > > > > > I have two thought experiments that lead me to believe that = duplicate > > address detection is properly the responsibility for the > > nodes that own > > the duplicated address. > > > > (1): What if a node moves so fast between two parts of the network > > that it "seems" to be in two places? One could > > easily imagine that > > such movement would fit within the time periods > > defined by local > > "hello" messages, depending on the range of radio = transmission. > > > > (2) What if one node leaves the network, and later rejoins? This is > > certainly a network partition. If each such event > > causes the network > > to initiate global signaling for DAD, then a meltdown is = almost > > guaranteed eventually. How can we distinguish between a = reboot > > and a temporary node departure? Is there any real difference = as > > far as the network is concerned? > > > > If the node itself detects duplication by any of several heuristics, > > then it can (a) borrow a new temporary address and (b) take > > corrective action. > > > > Regards, > > Charlie P. > > > > > > > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www1.ietf.org/mailman/listinfo/autoconf > > >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =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=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 CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. 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=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 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Feb 03 08:49:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F51Jk-0004iR-3k; Fri, 03 Feb 2006 08:49:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F51Jh-0004cO-Kh for autoconf@megatron.ietf.org; Fri, 03 Feb 2006 08:49:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28872 for ; Fri, 3 Feb 2006 08:48:00 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F51VH-0002Rw-9A for autoconf@ietf.org; Fri, 03 Feb 2006 09:01:36 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1DA6989911; Fri, 3 Feb 2006 15:49:19 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D9B858990D; Fri, 3 Feb 2006 15:49:18 +0200 (EET) Message-ID: <43E35F77.6060209@piuha.net> Date: Fri, 03 Feb 2006 15:49:43 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Charles E. Perkins" Subject: Re: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt References: <39C363776A4E8C4A94691D2BD9D1C9A1818A18@XCH-NW-7V2.nw.nos.boeing.com> <01fc01c627f0$b9f62b30$6dc6dba8@daniellaptop> <43E2131D.2030402@piuha.net> <43E24493.2090409@iprg.nokia.com> In-Reply-To: <43E24493.2090409@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Charles E. Perkins wrote: > Wouldn't it make sense to run the gateway as a > sort of DHCP relay? Sounds reasonable to me. > But I would think that would be a separate draft. > The functions are separable. I like separation. Perhaps what we are after here is making a model for the Manet - Internet connection that enables such separation. That is, just make the smallest possible function that can provide communication capability from the manet nodes to the gateway, and then use that capability to build things like the DHCP relay. > Plus, such a scheme > has to avoid conflicting with the useful possibility that > DNS and SIP are present in the manet. Ack. --Jari _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Feb 03 11:06:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F53SN-0002kB-EC; Fri, 03 Feb 2006 11:06:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F53SJ-0002iX-Vn for autoconf@megatron.ietf.org; Fri, 03 Feb 2006 11:06:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14355 for ; Fri, 3 Feb 2006 11:04:53 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F53dm-0000L2-Pp for autoconf@ietf.org; Fri, 03 Feb 2006 11:18:32 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k13FTAi04899; Fri, 3 Feb 2006 07:29:10 -0800 X-mProtect: <200602031529> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp161147.americas.nokia.com (10.241.161.147, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdxutd4o; Fri, 03 Feb 2006 07:29:08 PST Message-ID: <43E37F6B.6090606@iprg.nokia.com> Date: Fri, 03 Feb 2006 08:06:03 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center, Mtn. View User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: [Autoconf] The case for address uniqueness References: <39C363776A4E8C4A94691D2BD9D1C9A1818A22@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1818A22@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Fred, Templin, Fred L wrote: >OK to most of what you said > Thanks! > but is there really such a thing >as "stateless" address autoconfiguration without also requiring >a robust DAD mechanism? > Briefly, yes -- but ... > DAD is hard in MANETs due to the reasons >you gave in an earlier message (partitions and merges) and it >won't be made easier when nodes start using interface ID generation >mechanisms like CGA instead of assigning an interface's MAC address. >Can we rely on optimistic DAD and/or DAD avoidance? > > ...as you hint, the tradeoff is likely to be in reliability. In other words, _if_ one could design a stateful mechanism that was appropriate for disconnected ad hoc networks, then that mechanism could probably be made more robust. The impediments seem to include (probably there are others): - substantially increased signaling - creation of signaling hotspots - single point of failure - algorithmically difficult - stateful ==> configuration requirements ==> not exactly ad hoc My guess is that stateless will continue to be "better" for a while until some new approaches are discovered and developed. I'll bet that will not happen this year. My other guess is that it won't look like DHCP. Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Feb 03 12:02:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F54Ke-0004ru-1T; Fri, 03 Feb 2006 12:02:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F54Kc-0004rd-Es for autoconf@megatron.ietf.org; Fri, 03 Feb 2006 12:02:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20231 for ; Fri, 3 Feb 2006 12:01:07 -0500 (EST) Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F54WD-0002qH-Ri for autoconf@ietf.org; Fri, 03 Feb 2006 12:14:47 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.10+Sun/8.12.8) with SMTP id k13H2GoS011190; Fri, 3 Feb 2006 12:02:24 -0500 (EST) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.11.41) with SMTP id M2006020312022328612 ; Fri, 03 Feb 2006 12:02:23 -0500 From: "Joe Macker" To: "'Pedro M. Ruiz'" , "'Templin, Fred L'" Subject: RE: [Autoconf] The case for address uniqueness Date: Fri, 3 Feb 2006 12:02:21 -0500 Message-ID: <01be01c628e3$98ebdf40$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYorSKBepONwDz4QlOW4v9hqwzatwANJb2g In-Reply-To: <43E33057.1080607@dif.um.es> X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Fred: I think those are some good points. Some related experience with DAD in mobile systems is that its more problematic when DAD is considered completely essential in all cases and must be completed prior to allowing interface configuration. This can add signficant delay and reliability problems. I believe you captured some salient points for consideration and that some things should remain deplyment specific. I also feel a more general DAD solutions is welcome and fine for edge system architectures that need it and can live with the tradeoffs. We should also remember IPv6 lends itself well to hybrid stateless and stateful configuration concepts. >-----Original Message----- >From: autoconf-bounces@ietf.org >[mailto:autoconf-bounces@ietf.org] On Behalf Of Pedro M. Ruiz >Sent: Friday, February 03, 2006 5:29 AM >To: Templin, Fred L >Cc: autoconf@ietf.org >Subject: Re: [Autoconf] The case for address uniqueness > >I think there is a very good reason to go for stateless >address autoconfiguration which is that fact that the MANET >must keep on working even if connectivity to Internet is >completely lost for some period of time. > >My second point is that if we agree that duplication is >expected to be unlikely to happen, we can live with the >assumption that there is no duplication. In case of >duplication, we can let those nodes with duplicate addresses >to solve the issue if its eventually happens. Given that it >won't happen too often, peformance shouldn't be compromised by >such DAD resolution scheme. > >Regards, > >--Pedro > >Templin, Fred L wrote: > > Charlie, > > OK to most of what you said, but is there really such a thing > as "stateless" address autoconfiguration without also requiring > a robust DAD mechanism? DAD is hard in MANETs due to the reasons > you gave in an earlier message (partitions and merges) and it > won't be made easier when nodes start using interface >ID generation > mechanisms like CGA instead of assigning an interface's >MAC address. > Can we rely on optimistic DAD and/or DAD avoidance? > > Thanks - Fred > fred.l.templin@boeing.com > > > > > -----Original Message----- > From: Charles E. Perkins >[mailto:charliep@iprg.nokia.com] > Sent: Thursday, February 02, 2006 12:33 PM > To: Templin, Fred L > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] The case for address uniqueness > > > Hello Fred, > > > ext Templin, Fred L wrote: > > > > These discussions have been going on >for so many years now that > it seems they may never converge on a >"one-size-fits-all" solution > for MANET autoconfiguration. > > > > This may not be a good indicator, though, since >autoconfiguration has > never been on the charter for MANET as far as I >remember. > > > > Is there a chance we could steer > things toward a best current practices >direction? If so, what > would they look like, e.g.: > > - use IPv6 link-local for neighbor discovery > > > > > I would prefer not to make this constraint. By >doing so, the neighbor > discovery process is then required to suffer >multiple rounds > of signaling > just to get neighbors to know the node's useful >IP address. > > > > - use IPv6 Unique Local Addresses >(ULAs) for intra-MANET comm's > > > > > This sounds great for nodes that don't already >have global addresses. > > > > - use DHCPv6 to get a globally unique >address for Internet comm's > > > > > I would prefer a stateless approach whenever >it's available. > > > > Is there a chance we will see some >convergence soon or will the > status remain quo for the forseeable future? > > > > > I guess both are very possible. It's up to us! > The fact that the > working group has been approved is a good sign, though. > > Regards, > Charlie P. > > > > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf > > > > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Feb 03 12:19:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F54Uv-0006F6-0w; Fri, 03 Feb 2006 12:13:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F54UT-00069p-GM for autoconf@megatron.ietf.org; Fri, 03 Feb 2006 12:12:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20909 for ; Fri, 3 Feb 2006 12:11:18 -0500 (EST) Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F54g5-00039U-TS for autoconf@ietf.org; Fri, 03 Feb 2006 12:24:58 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.10+Sun/8.12.8) with SMTP id k13HCkoO011640; Fri, 3 Feb 2006 12:12:48 -0500 (EST) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.11.41) with SMTP id M2006020312124728679 ; Fri, 03 Feb 2006 12:12:47 -0500 From: "Joe Macker" To: "'Jari Arkko'" , "'Charles E. Perkins'" Subject: RE: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt Date: Fri, 3 Feb 2006 12:12:45 -0500 Message-ID: <01bf01c628e5$0cc42200$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYoyUSImyzbf6o9QqOeg/2p2iFdqwAGvOOA In-Reply-To: <43E35F77.6060209@piuha.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Can someone help me with recent background on this thread? We have been running DHCP relay type functionality for years in manet. I gave a few high level briefing in older manet minutes. In many scenario (connected ones) this approach works fine. There are remaining engineering questions of how relay agents can and should operate in a MANET. What documents presently discuss related work for stateful or hybrid stateless/stateful. Say using the DHCP only to configure stateful things other than address. Also there are some engineering discussions that could take place when considering unicast vs. multicast support of the signaling. -joe >-----Original Message----- >From: autoconf-bounces@ietf.org >[mailto:autoconf-bounces@ietf.org] On Behalf Of Jari Arkko >Sent: Friday, February 03, 2006 8:50 AM >To: Charles E. Perkins >Cc: autoconf@ietf.org >Subject: Re: [Autoconf] Comments on >draft-wakikawa-manet-globalv6-04.txt > >Charles E. Perkins wrote: > >> Wouldn't it make sense to run the gateway as a sort of DHCP relay? > >Sounds reasonable to me. > >> But I would think that would be a separate draft. >> The functions are separable. > >I like separation. Perhaps what we are after here is making a >model for the Manet - Internet connection that enables such >separation. That is, just make the smallest possible function >that can provide communication capability from the manet nodes >to the gateway, and then use that capability to build things >like the DHCP relay. > >> Plus, such a scheme >> has to avoid conflicting with the useful possibility that >DNS and SIP >> are present in the manet. > >Ack. > >--Jari > > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www1.ietf.org/mailman/listinfo/autoconf > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Feb 03 12:19:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F54aO-0007AP-K5; Fri, 03 Feb 2006 12:19:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F54aL-00078j-4v for autoconf@megatron.ietf.org; Fri, 03 Feb 2006 12:19:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21313 for ; Fri, 3 Feb 2006 12:17:22 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F54lw-0003QR-5V for autoconf@ietf.org; Fri, 03 Feb 2006 12:31:01 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k13GfYu15514; Fri, 3 Feb 2006 08:41:34 -0800 X-mProtect: <200602031641> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp161147.americas.nokia.com (10.241.161.147, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpd6hJT3d; Fri, 03 Feb 2006 08:41:33 PST Message-ID: <43E39065.5040206@iprg.nokia.com> Date: Fri, 03 Feb 2006 09:18:29 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center, Mtn. View User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Macker Subject: Re: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt References: <01bf01c628e5$0cc42200$165cfa84@SEXTANT> In-Reply-To: <01bf01c628e5$0cc42200$165cfa84@SEXTANT> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Joe, Joe Macker wrote: >Can someone help me with recent background on this thread? >We have been running DHCP relay type functionality for years in manet. >I gave a few high level briefing in older manet minutes. > > For those of us with short memories, could you provide URLs into the pages the IETF proceedings? >In many scenario (connected ones) this approach works fine. > Of this, I have no doubt. Using a gateway as a DHCP relay, or configuring a well connected manet node as a DHCP server, seems pretty workable. But, what about scenarios where there isn't any preconfigured DHCP server or gateway? Do you have solutions for that? If the solutions were in your previous presentations, oops sorry I missed that. Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Feb 03 12:31:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F54mP-0000nS-Dc; Fri, 03 Feb 2006 12:31:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F54mN-0000iC-H7 for autoconf@megatron.ietf.org; Fri, 03 Feb 2006 12:31:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22436 for ; Fri, 3 Feb 2006 12:29:48 -0500 (EST) Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F54xz-00043k-9J for autoconf@ietf.org; Fri, 03 Feb 2006 12:43:28 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.10+Sun/8.12.8) with SMTP id k13HVHoL012556; Fri, 3 Feb 2006 12:31:17 -0500 (EST) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.11.41) with SMTP id M2006020312311728810 ; Fri, 03 Feb 2006 12:31:17 -0500 From: "Joe Macker" To: "'Charles E. Perkins'" Subject: RE: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt Date: Fri, 3 Feb 2006 12:31:14 -0500 Message-ID: <01c101c628e7$a1e7fe90$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYo5eYeYloAwjTJR2GozapOLn/gRwAAHzJg In-Reply-To: <43E39065.5040206@iprg.nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org It was discussed publicly twice. There was a short presentation at the Vienna IETF. If it isnt in the proceedings I can forward it. It is also discussed breif;y as a testing example in the following mobile emulator paper. We used the emulator to test multiple hop MANET configuration with DHCP relay agent functionality. This work strived to be independent from a particular unicast routing protocol. Once its only applicable for a connected scenario. In doing this work we realized future things that we would like to improve. So I am interested in having more discussion with other parties that may be working in this area. Macker J.P., J. Weston, W. Chao. " A Low Cost IP-based Mobile Network Emulator", IEEE Milcom 2003 Proceedings, Oct 2003. >-----Original Message----- >From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] >Sent: Friday, February 03, 2006 12:18 PM >To: Joe Macker >Cc: autoconf@ietf.org >Subject: Re: [Autoconf] Comments on >draft-wakikawa-manet-globalv6-04.txt > >Hello Joe, > >Joe Macker wrote: > >>Can someone help me with recent background on this thread? >>We have been running DHCP relay type functionality for years in manet. >>I gave a few high level briefing in older manet minutes. >> >> >For those of us with short memories, could you provide URLs >into the pages the IETF proceedings? > >>In many scenario (connected ones) this approach works fine. >> >Of this, I have no doubt. Using a gateway as a DHCP relay, or >configuring a well connected manet node as a DHCP server, >seems pretty workable. > >But, what about scenarios where there isn't any preconfigured >DHCP server or gateway? Do you have solutions for that? If >the solutions were in your previous presentations, oops sorry >I missed that. > >Regards, >Charlie P. > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Feb 03 12:45:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5507-0007E6-Lp; Fri, 03 Feb 2006 12:45:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5505-0007DZ-Ku for autoconf@megatron.ietf.org; Fri, 03 Feb 2006 12:45:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23566 for ; Fri, 3 Feb 2006 12:43:50 -0500 (EST) Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F55Ba-0004gC-Ee for autoconf@ietf.org; Fri, 03 Feb 2006 12:57:30 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.10+Sun/8.12.8) with SMTP id k13HjKoL013345; Fri, 3 Feb 2006 12:45:20 -0500 (EST) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.11.41) with SMTP id M2006020312451928981 ; Fri, 03 Feb 2006 12:45:19 -0500 From: "Joe Macker" To: "'Charles E. Perkins'" Subject: RE: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt Date: Fri, 3 Feb 2006 12:45:17 -0500 Message-ID: <01c201c628e9$982ced50$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYo5eYeYloAwjTJR2GozapOLn/gRwAAc9Ng In-Reply-To: <43E39065.5040206@iprg.nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org >-----Original Message----- >From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] >Sent: Friday, February 03, 2006 12:18 PM >To: Joe Macker >Cc: autoconf@ietf.org >Subject: Re: [Autoconf] Comments on >draft-wakikawa-manet-globalv6-04.txt > >Hello Joe, > >Joe Macker wrote: > >>Can someone help me with recent background on this thread? >>We have been running DHCP relay type functionality for years in manet. >>I gave a few high level briefing in older manet minutes. >> >> >For those of us with short memories, could you provide URLs >into the pages the IETF proceedings? > >>In many scenario (connected ones) this approach works fine. >> >Of this, I have no doubt. Using a gateway as a DHCP relay, or >configuring a well connected manet node as a DHCP server, >seems pretty workable. > >But, what about scenarios where there isn't any preconfigured >DHCP server or gateway? Do you have solutions for that? If >the solutions were in your previous presentations, oops sorry >I missed that. > >Regards, >Charlie P. > > Charlie/All: Sent a separate note on previous work reference. Some of this was IPv4 work and some limited IPv6 work was done as well. The approach does do some limited gatway discovery (if that is what you mean by preconfigured?) but I believe the larger answer with distributed, fragmented, or self-election involves taking advantage of anycast or SMF/SMURF multicast work to enable more distributed/efficent adaptation and service discovery. of course, this goes beyond DHCP.. Hopefully that is one way to provide some separation in technique specification that is more general yet practical. For a single server type scenarios the unicast type relay agent approach may be more efficient. I think more examples and scenarios need to be looked at here. -Joe _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Feb 03 16:32:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F58Y5-0005Yn-Gf; Fri, 03 Feb 2006 16:32:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F58Y4-0005WW-1n for autoconf@megatron.ietf.org; Fri, 03 Feb 2006 16:32:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17211 for ; Fri, 3 Feb 2006 16:31:17 -0500 (EST) Received: from cecom6.monmouth.army.mil ([134.80.0.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F58jg-0007dl-Fx for autoconf@ietf.org; Fri, 03 Feb 2006 16:44:58 -0500 Received: from MONM226.nae.ds.army.mil (mailsw2.monmouth.army.mil [134.80.5.41]) by cecom6.monmouth.army.mil (8.13.5/8.13.5) with ESMTP id k13LV5N3015318 for ; Fri, 3 Feb 2006 16:31:05 -0500 (EST) Received: from SWGM6.nae.ds.army.mil (unverified) by MONM226.nae.ds.army.mil (Content Technologies SMTPRS 4.3.12) with ESMTP id ; Fri, 3 Feb 2006 16:32:43 -0500 Received: by swgm6.nae.ds.army.mil with Internet Mail Service (5.5.2656.59) id ; Fri, 3 Feb 2006 16:32:43 -0500 Message-ID: From: "Green, David B RDECOM CERDEC STCD SRI" To: "'Templin, Fred L'" , "Charles E. Perkins" Subject: RE: [Autoconf] The case for address uniqueness Date: Fri, 3 Feb 2006 16:32:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: autoconf@ietf.org, "Ralph Liguori \(liguorir@ftm.disa.mil\)" X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org If the lower 64bit address identifiers in MANET AS router neodes are made with a guaranteed Unique IDentification (UID) numbers do we need DAD for IPv6 Unique Local Addresses (ULAs) and global addresses? David Green CERDEC Site Manager SRI International Office: (732) 532-6715 Mobile: (732) 693-6500 [Note: To reliably reach me with important, time-sensitive information, call my cell phone instead of e-mailing me.] -----Original Message----- From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: Thursday, February 02, 2006 5:34 PM To: Charles E. Perkins Cc: autoconf@ietf.org Subject: RE: [Autoconf] The case for address uniqueness Charlie, OK to most of what you said, but is there really such a thing as "stateless" address autoconfiguration without also requiring a robust DAD mechanism? DAD is hard in MANETs due to the reasons you gave in an earlier message (partitions and merges) and it won't be made easier when nodes start using interface ID generation mechanisms like CGA instead of assigning an interface's MAC address. Can we rely on optimistic DAD and/or DAD avoidance? Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Thursday, February 02, 2006 12:33 PM > To: Templin, Fred L > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] The case for address uniqueness > > > Hello Fred, > > > ext Templin, Fred L wrote: > > >These discussions have been going on for so many years now that it > >seems they may never converge on a "one-size-fits-all" solution for > >MANET autoconfiguration. > > > This may not be a good indicator, though, since autoconfiguration has > never been on the charter for MANET as far as I remember. > > > Is there a chance we could steer > >things toward a best current practices direction? If so, what would > >they look like, e.g.: > > > > - use IPv6 link-local for neighbor discovery > > > > > I would prefer not to make this constraint. By doing so, the neighbor > discovery process is then required to suffer multiple rounds of > signaling just to get neighbors to know the node's useful IP address. > > > - use IPv6 Unique Local Addresses (ULAs) for intra-MANET comm's > > > > > This sounds great for nodes that don't already have global addresses. > > > - use DHCPv6 to get a globally unique address for Internet comm's > > > > > I would prefer a stateless approach whenever it's available. > > >Is there a chance we will see some convergence soon or will the > >status remain quo for the forseeable future? > > > > > I guess both are very possible. It's up to us! The fact that the > working group has been approved is a good sign, though. > > Regards, > Charlie P. > > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Feb 03 16:46:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F58kr-0004gK-D3; Fri, 03 Feb 2006 16:46:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F58kl-0004fF-DS for autoconf@megatron.ietf.org; Fri, 03 Feb 2006 16:46:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18190 for ; Fri, 3 Feb 2006 16:44:17 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F58wG-00088N-5G for autoconf@ietf.org; Fri, 03 Feb 2006 16:57:58 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA29510; Fri, 3 Feb 2006 15:45:40 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k13LjgW17822; Fri, 3 Feb 2006 13:45:42 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 13:45:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Autoconf] The case for address uniqueness Date: Fri, 3 Feb 2006 13:45:39 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1818A26@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: [Autoconf] The case for address uniqueness Thread-Index: AcYpCYtekw+utAzRRM6EDs2D1HDL+AAAA2rg From: "Templin, Fred L" To: "Green, David B RDECOM CERDEC STCD SRI" , "Charles E. Perkins" X-OriginalArrivalTime: 03 Feb 2006 21:45:39.0684 (UTC) FILETIME=[2CA22240:01C6290B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org, liguorir@ftm.disa.mil X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org David,=20 > -----Original Message----- > From: Green, David B RDECOM CERDEC STCD SRI=20 > If the lower 64bit address identifiers in MANET AS router=20 > neodes are made with a guaranteed Unique IDentification (UID)=20 > numbers do we need DAD for IPv6 Unique Local Addresses (ULAs)=20 > and global addresses? IMHO, the answer is no, you do not need DAD if you can guarantee unique IDs in the lower 64bits of an IPv6 address simply because there are enough bits available to ensure uniqueness to a high probability. But, if your scheme is based on having lots of bits then does that mean that you need to carry all of those bits in the headers and address fields of all IPv6 packets you send? Asked another way, does DAD avoidance through requiring lots of bits for uniqueness purposes defeat IP header and address field compression? Fred fred.l.templin@boeing.com =20 =20 > David Green=20 > CERDEC Site Manager > SRI International > Office: (732) 532-6715 > Mobile: (732) 693-6500 >=20 > [Note: To reliably reach me with important, time-sensitive=20 > information, call my cell phone instead of e-mailing me.] =20 > =20 >=20 > -----Original Message----- > From: autoconf-bounces@ietf.org=20 > [mailto:autoconf-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Thursday, February 02, 2006 5:34 PM > To: Charles E. Perkins > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] The case for address uniqueness >=20 > Charlie, >=20 > OK to most of what you said, but is there really such a thing=20 > as "stateless" address autoconfiguration without also=20 > requiring a robust DAD mechanism? DAD is hard in MANETs due=20 > to the reasons you gave in an earlier message (partitions and=20 > merges) and it won't be made easier when nodes start using=20 > interface ID generation mechanisms like CGA instead of=20 > assigning an interface's MAC address. > Can we rely on optimistic DAD and/or DAD avoidance? >=20 > Thanks - Fred > fred.l.templin@boeing.com > =20 >=20 > > -----Original Message----- > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > Sent: Thursday, February 02, 2006 12:33 PM > > To: Templin, Fred L > > Cc: autoconf@ietf.org > > Subject: Re: [Autoconf] The case for address uniqueness > >=20 > >=20 > > Hello Fred, > >=20 > >=20 > > ext Templin, Fred L wrote: > >=20 > > >These discussions have been going on for so many years now that it=20 > > >seems they may never converge on a "one-size-fits-all"=20 > solution for=20 > > >MANET autoconfiguration. > > > > > This may not be a good indicator, though, since=20 > autoconfiguration has=20 > > never been on the charter for MANET as far as I remember. > >=20 > > > Is there a chance we could steer > > >things toward a best current practices direction? If so,=20 > what would=20 > > >they look like, e.g.: > > > > > > - use IPv6 link-local for neighbor discovery > > > =20 > > > > > I would prefer not to make this constraint. By doing so,=20 > the neighbor=20 > > discovery process is then required to suffer multiple rounds of=20 > > signaling just to get neighbors to know the node's useful=20 > IP address. > >=20 > > > - use IPv6 Unique Local Addresses (ULAs) for intra-MANET comm's > > > =20 > > > > > This sounds great for nodes that don't already have global=20 > addresses. > >=20 > > > - use DHCPv6 to get a globally unique address for Internet comm's > > > =20 > > > > > I would prefer a stateless approach whenever it's available. > >=20 > > >Is there a chance we will see some convergence soon or will the=20 > > >status remain quo for the forseeable future? > > > =20 > > > > > I guess both are very possible. It's up to us! The fact that the=20 > > working group has been approved is a good sign, though. > >=20 > > Regards, > > Charlie P. > >=20 > >=20 > >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Feb 03 19:20:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5BAA-0008B2-8o; Fri, 03 Feb 2006 19:20:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5BA8-00086m-HZ for autoconf@megatron.ietf.org; Fri, 03 Feb 2006 19:20:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01056 for ; Fri, 3 Feb 2006 19:18:38 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5BLd-00064N-71 for autoconf@ietf.org; Fri, 03 Feb 2006 19:32:20 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id SAA14727; Fri, 3 Feb 2006 18:19:54 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k140JrN19276; Fri, 3 Feb 2006 18:19:53 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 16:19:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Autoconf] The case for address uniqueness Date: Fri, 3 Feb 2006 16:19:50 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1818A27@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: [Autoconf] The case for address uniqueness Thread-Index: AcYpCYtekw+utAzRRM6EDs2D1HDL+AAAA2rgAAWOS+A= From: "Templin, Fred L" To: "Templin, Fred L" , "Green, David B RDECOM CERDEC STCD SRI" , "Charles E. Perkins" X-OriginalArrivalTime: 04 Feb 2006 00:19:51.0531 (UTC) FILETIME=[B729F3B0:01C62920] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org, liguorir@ftm.disa.mil X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > Asked another way, does DAD avoidance through requiring > lots of bits for uniqueness purposes defeat IP header > and address field compression? I am responding to my own post because I do not want to create FUD. I do not know of any interaction between DAD avoidance and IP header and address field compression, but if anyone else does they are welcome to respond. Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sun Feb 05 18:53:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5thQ-0002XK-Dy; Sun, 05 Feb 2006 18:53:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5thO-0002Wv-QM for autoconf@megatron.ietf.org; Sun, 05 Feb 2006 18:53:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24784 for ; Sun, 5 Feb 2006 18:52:00 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5ttQ-0006Iw-GA for autoconf@ietf.org; Sun, 05 Feb 2006 19:06:10 -0500 Received: from [?P?IPv6:2001:200::8801:211:24ff:fe79:8e82] (unknown [IPv6:2001:200:0:8801:211:24ff:fe79:8e82]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 3C01A4DB7F; Mon, 6 Feb 2006 08:53:09 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <31BF3668-C341-4F44-9963-1E01555C86EF@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt Date: Mon, 6 Feb 2006 08:53:09 +0900 To: Ralph Droms , Jari Arkko , Soohong Daniel Park , autoconf@ietf.org X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: 7bit Cc: X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi all I basically agree on using existing approaches as many as possible for connected-manet. However, manet is multi-hop networks and some of signaling may be multi-hopped. If a node is capable of being both a manet node and IPv6 node, it must operate the protocol carefully. If a node attaches to a legacy IPv6 link and starts sending a DHCP server solicitation, a NS, and a RS over multihop, it will be messed up. We needs certain modifications to these protocols for manet and an DNA!? mechanism to detect whether the attached link is manet or not. regards, ryuji On 2006/02/03, at 2:59, Ralph Droms wrote: > Jari - you could either run a DHCP server providing configuration > information (as in RFC 3736) on the network element issuing the RAs > or a > DHCP relay forwarding to a server on another host. Either way, use > of DHCP > would leverage re-use of all the existing configuration options... > > - Ralph > > > On 2/2/06 9:11 AM, "Jari Arkko" wrote: > >> Yes, DNS server is needed too, assuming we have >> global connectivity. But we may also need other >> information, such as NTP servers, local SIP servers >> etc. I wonder if there is a way to somehow use DHCP >> in this context so that we wouldn't need to invent >> all those options again. >> >> --Jari >> >> Soohong Daniel Park wrote: >> >>> In addition, current draft is still missing of how DNS Server can be >>> configured on the manet node from the global connectivity point of >>> view. Perhaps, Ryuji remembers what I am indicating because I did >>> raise this concern before. Obtaining DNS Server address is an >>> essential part of manet global connectivity, so one option SHOULD >>> be attached to the RA option along with Prefix option. You can refer >>> to the related work below; >>> http://www.watersprings.org/pub/id/draft-daniel-manet-dns- >>> discovery-globalv6- >>> 00.txt >>> > http://www.watersprings.org/pub/id/draft-jeong-dnsop-ipv6-dns- > discovery-08.tx>> > t >>> >>> Thanks, >>> >>> Daniel (Soohong Daniel Park) >>> Mobile Convergence Laboratory, SAMSUNG Electronics. >>> ----- Original Message ----- >>> From: "Templin, Fred L" >>> To: >>> Sent: Thursday, February 02, 2006 7:03 AM >>> Subject: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt >>> >>> >>> I don't know if this is the correct forum, but below are >>> some comments on this draft: >>> >>> Fred >>> fred.l.templin@boeing.com >>> >>> >>> 1) In introduction, add DYMO to list of IETF routing protocols. >>> >>> 2) Second to last paragraph of P.4, change: "whether they are >>> reactive and proactive." to: "... reactive or proactive." >>> >>> 3) Final paragraph of P.4, this text seems to assume that >>> internet-gateways maintain a roster of the addresses of >>> nodes that reside within the MANET, e.g., so that packets >>> destined to MANET nodes don't leak out into the Internet >>> and so that ICMP redirects can be issued. This assumption >>> needs to be made explicit somehow - both in this section >>> and elsewhere throughout the document. >>> >>> 4) Top of P.6, the sentence: "The node therefore needs to obtain >>> a global prefix owned and distributed by an internet-gateway." >>> Is the intention here that a prefix must be owned by one >>> and only one internet-gateway? Or, could the same prefix >>> potentially be advertised by multiple gateways? >>> >>> 5) Bottom of P.6, change "two messages such as" to "two messages:". >>> >>> 6) Section 4.3, add a third message type "internet gateway >>> confirmation". The purpose of this message is to provide >>> a 3-way handshake between manet nodes and internet gateways >>> under the following procedure: >>> >>> 1. manet node sends "internet gateway solicitation" to >>> multicast address >>> 2. Internet gateway(s) sends "internet gateway advertisement" >>> to unicast address of manet node >>> 3. manet node sends "internet gateway confirmation" to >>> unicast address of internet gateway(s) >>> >>> The "internet gateway confirm" message is needed to allow the >>> internet gateway to construct a roster of the MANET nodes it >>> serves. The roster is needed in order for the gateway to >>> determine when redirects should be sent for intra-MANET >>> communications. >>> >>> 7) P.11, second sentence beginning with: "Since the manet node is >>> assumed to already have done Duplicate Address Detection (DAD), >>> as defined in [11], for the link-local address", this does not >>> seem to be a valid assumption since there is no way for the node >>> to inquire throughout the entire MANET as to whether its link- >>> local >>> address is unique within the MANET. Suggest dropping the entire >>> discussion on DAD and simply say "DAD is not in scope". >>> >>> 8) Section 5.5, change: "But it just stop sending..." to: "But it >>> SHOULD stop sending...". Also, the rest of this first paragraph >>> of section 5.5 seems poorly-worded and imprecise. Suggest either >>> a re-write or just remove the text. >>> >>> 9) Section 6.1, second paragraph. Change: "When an internet- >>> gateway..." >>> to: "When a manet node...". >>> >>> 10) Section 7.3, the verification: "- If the hop limit field of the >>> message is less than or equal to zero...", how is the "less than" >>> check to be one (i.e., the hop-limit field is just an 8-bit >>> unsigned integer). Suggest changing: "less than or equal to zero" >>> to simply "equal to zero". >>> >>> 11) Section 7.3, final sentence (and section 7.4) the "global manet >>> node list" spoken of here can only be unidirectional. If an >>> "internet gateway confirm" message type is added (as per >>> comment 6), the global manet node list can be made bi- >>> directional. >>> >>> 12) Section 7.5, this entire section seems to assume that internet- >>> gateways are assigned prefixes in 1x1 correspondence. As asked >>> earlier, can more than one internet-gateway advertise the *same* >>> prefix, i.e., can a prefix be co-owned by more than one gateway? >>> If yes, then this section would require rewrites. If no, then >>> why not? >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www1.ietf.org/mailman/listinfo/autoconf >>> >>> >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www1.ietf.org/mailman/listinfo/autoconf >>> >>> >>> >>> >> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www1.ietf.org/mailman/listinfo/autoconf > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Feb 08 06:40:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ngY-0005VH-Kf; Wed, 08 Feb 2006 06:40:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ngV-0005UB-0F for autoconf@megatron.ietf.org; Wed, 08 Feb 2006 06:40:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14083 for ; Wed, 8 Feb 2006 06:38:35 -0500 (EST) Received: from balu1.urz.unibas.ch ([131.152.1.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6nsp-0000kV-Qx for autoconf@ietf.org; Wed, 08 Feb 2006 06:53:17 -0500 Received: from [10.147.66.117] (int-33-68.mobile.unibas.ch [131.152.33.68]) by balu1.urz.unibas.ch (8.13.5/8.13.5) with ESMTP id k18Be5SE006790; Wed, 8 Feb 2006 12:40:06 +0100 Message-ID: <43E9D898.6060808@unibas.ch> Date: Wed, 08 Feb 2006 12:40:08 +0100 From: Christophe Jelger Organization: University of Basel User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [Autoconf] Comments on draft-wakikawa-manet-globalv6-04.txt References: <31BF3668-C341-4F44-9963-1E01555C86EF@sfc.wide.ad.jp> In-Reply-To: <31BF3668-C341-4F44-9963-1E01555C86EF@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-Vilter-Version: 1.1.8 X-SMTP-Vilter-Virus-Backend: savse X-SMTP-Vilter-Status: clean X-SMTP-Vilter-savse-Virus-Status: clean X-SMTP-Vilter-Unwanted-Backend: attachment X-SMTP-Vilter-attachment-Unwanted-Status: clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Ryuji, See some comments and self-publicity below. Regards, Christophe Ryuji Wakikawa wrote: > Hi all > > I basically agree on using existing approaches as many as possible for > connected-manet. > However, manet is multi-hop networks and some of signaling may be > multi-hopped. > If a node is capable of being both a manet node and IPv6 node, it must > operate the protocol carefully. > If a node attaches to a legacy IPv6 link and starts sending a DHCP > server solicitation, > a NS, and a RS over multihop, it will be messed up. Well such messages can be "captured" and handled in a clever way. For example the underlay nature of LUNARng (see http://core.it.uu.se/adhoc/) allows a node to perform a "MANET-specific handling" of such messages. For example, DHCP/RS requests are captured, autoconf is performed and faked DHCP/RA replies are generated back to the application (dhcp client) or IP layer (IPv6 SAA). Interested readers can have a look at our paper describing this "Model Based Protocol Fusion for MANET-Internet Integration" here: http://cn.cs.unibas.ch/pub/doc/2006-Wons.pdf > > We needs certain modifications to these protocols for manet and > an DNA!? mechanism to detect whether the attached link is manet or not. We have alrady had some debate about this (threads around 02/25/05) and I remember a clear issue was "how" and "who" should perform such a "detection". I agree there is quite some room here to enable some sort of a "MANET-aware" node behavior. > > regards, > ryuji > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Feb 08 16:23:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6wmi-0004Y3-Nk; Wed, 08 Feb 2006 16:23:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6wma-0004V4-ET for autoconf@megatron.ietf.org; Wed, 08 Feb 2006 16:23:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04520 for ; Wed, 8 Feb 2006 16:21:31 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6wz0-0006NB-Mk for autoconf@ietf.org; Wed, 08 Feb 2006 16:36:20 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA25469; Wed, 8 Feb 2006 13:21:39 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k18LLcN07428; Wed, 8 Feb 2006 15:21:38 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Feb 2006 13:21:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Autoconf] The case for address uniqueness Date: Wed, 8 Feb 2006 13:21:34 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1818A30@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: [Autoconf] The case for address uniqueness Thread-Index: AcYpCYtekw+utAzRRM6EDs2D1HDL+AAAA2rgAPokMhA= From: "Templin, Fred L" To: "Templin, Fred L" , "Green, David B RDECOM CERDEC STCD SRI" , "Charles E. Perkins" X-OriginalArrivalTime: 08 Feb 2006 21:21:34.0979 (UTC) FILETIME=[A3966530:01C62CF5] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org, liguorir@ftm.disa.mil X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org =20 > > -----Original Message----- > > From: Green, David B RDECOM CERDEC STCD SRI=20 > > If the lower 64bit address identifiers in MANET AS router=20 > > neodes are made with a guaranteed Unique IDentification (UID)=20 > > numbers do we need DAD for IPv6 Unique Local Addresses (ULAs)=20 > > and global addresses? >=20 > IMHO, the answer is no, you do not need DAD if you can > guarantee unique IDs in the lower 64bits of an IPv6 > address simply because there are enough bits available > to ensure uniqueness to a high probability. Exploring this just a bit further; suppose there existed an IPv6 Internet for which some centralized authority was responsible for assigning each node a guaranteed-unique ID and it actually worked out that way in practice. The Internet would also be such that the guaranteed-unique node IDs were always used in constructing IPv6 addresses, and mechanisms like privacy addressing were never used. Then, an IPv6 address on that Internet could be thought of as containing a locator component in the upper 64 bits and an identifier component in the lower 64 bits, i.e., a clear locator/identifier split. This would seemingly allow for DAD avoidance in all cases, but would essentially restrict the Internet to only having 2^64 unique addresses instead of 2^128. What are the other benefits and drawbacks you could imagine for such an Internet? Fred fred.l.templin@boeing.com =20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 09 08:45:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7C6q-0007vb-Q8; Thu, 09 Feb 2006 08:45:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7C6o-0007rT-5e for autoconf@megatron.ietf.org; Thu, 09 Feb 2006 08:45:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22214 for ; Thu, 9 Feb 2006 08:43:30 -0500 (EST) Received: from balu1.urz.unibas.ch ([131.152.1.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7CJV-0008K2-QY for autoconf@ietf.org; Thu, 09 Feb 2006 08:58:27 -0500 Received: from [10.147.66.117] (int-32-204.mobile.unibas.ch [131.152.32.204]) by balu1.urz.unibas.ch (8.13.5/8.13.5) with ESMTP id k19DiqTl020555; Thu, 9 Feb 2006 14:44:52 +0100 Message-ID: <43EB4752.5060702@unibas.ch> Date: Thu, 09 Feb 2006 14:44:50 +0100 From: Christophe Jelger Organization: University of Basel User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: [Autoconf] The case for address uniqueness References: <39C363776A4E8C4A94691D2BD9D1C9A1818A30@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1818A30@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-Vilter-Version: 1.2.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello, See some comments below. Templin, Fred L wrote: > (...) > > Exploring this just a bit further; suppose there existed an > IPv6 Internet for which some centralized authority was > responsible for assigning each node a guaranteed-unique > ID and it actually worked out that way in practice. The > Internet would also be such that the guaranteed-unique node > IDs were always used in constructing IPv6 addresses, and > mechanisms like privacy addressing were never used. > > Then, an IPv6 address on that Internet could be thought of > as containing a locator component in the upper 64 bits and > an identifier component in the lower 64 bits, i.e., a clear > locator/identifier split. This would seemingly allow for DAD > avoidance in all cases, but would essentially restrict the > Internet to only having 2^64 unique addresses instead of 2^128. Actually this is roughly what happens with IPv6 stateless address autoconfiguration. The network prefix (usually 64 bits) is the locator ("where you are", or rather "the network link your are attached to"), and the EUI-64 is one of your identifiers. That is it identifies one NIC of your PC, IPAQ, Palm or whatever device is yours (or actually yours via your company ;-). What you propose is essentialy to stick the 64-bit identifier to the device (or the user itself but that would probably raise so much privacy concern that it would be rejected). > > What are the other benefits and drawbacks you could imagine > for such an Internet? > Actually although I tend to find such a solution as being "elegant", I think it suffers from many problems. First there is the centralized authority (which could in fact be decentralized as IANA decentralizes IPv6 address allocation via RIRs) which would have to deal with the registration of millions of devices. Quite complex and open concerns such as "Are you really who you tell us you are". Second, that doesn't help much to locate somebody. I mean you would look for a given host and its associated HUI-64 (Host Unique Identifer) but could not easily derive the locator ... unless there is somewhere a huge database that keeps track of location (unless there is some home network associated to each HUI and a Mobile IP like home agent in each local network). Finally I am not sure whether it's a good idea to embedd this numerical identity into the IP address because even if there is a clear locator/identity split it's still after all an IPv6 address which is not supposed to have anything to do with identity. I think something like HIP (Host Identity Protocol) does the same thing but in a cleaner way. Regards, Christophe _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Feb 17 21:07:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAHVk-00028N-Me; Fri, 17 Feb 2006 21:07:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAHVj-00027l-Jy for autoconf@megatron.ietf.org; Fri, 17 Feb 2006 21:07:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11764 for ; Fri, 17 Feb 2006 21:05:59 -0500 (EST) Received: from mailgate.cc.niigata-u.ac.jp ([133.35.14.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAHjt-0000jB-HS for autoconf@ietf.org; Fri, 17 Feb 2006 21:22:49 -0500 Received: from mailgate.cc.niigata-u.ac.jp (unknown [127.0.0.1]) by localhost.cc.niigata-u.ac.jp (Postfix) with ESMTP id 31B5624C204 for ; Sat, 18 Feb 2006 11:07:20 +0900 (JST) Received: from chamame.ie.niigata-u.ac.jp (chamame.ie.niigata-u.ac.jp [133.35.169.34]) by mailgate.cc.niigata-u.ac.jp (Postfix) with SMTP id 2436C24C1F0 for ; Sat, 18 Feb 2006 11:07:20 +0900 (JST) Received: (qmail 27919 invoked from network); 18 Feb 2006 11:07:12 +0900 Received: from unknown (HELO MS191.ie.niigata-u.ac.jp) (133.35.156.191) by chamame.ie.niigata-u.ac.jp with SMTP; 18 Feb 2006 11:07:12 +0900 Message-Id: <5.0.2.5.2.20060218105627.063a2440@127.0.0.1> X-Sender: mh.ie.niigata-u.ac.jp:mase:apop@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Sat, 18 Feb 2006 11:06:58 +0900 To: autoconf@ietf.org From: mase Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Autoconf] autoconf-framework draft udpate X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi, all, We have updated the following draft. http://www.ietf.org/internet-drafts/draft-mase-autoconf-framework-01.txt The major change from ver.00 is as follows: -The 00 version has two state-transition diagrams for proactive and reactive routing protocols, respectively. The 01 version has a common state-transition diagram. Your comments are welcome. Thanks. Kenichi _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Feb 27 05:42:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDfpp-0008O9-Ia; Mon, 27 Feb 2006 05:42:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDfpo-0008Nm-4m; Mon, 27 Feb 2006 05:42:32 -0500 Received: from balu1.urz.unibas.ch ([131.152.1.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDfpm-0004tp-Mg; Mon, 27 Feb 2006 05:42:32 -0500 Received: from [10.147.66.117] (int-34-41.mobile.unibas.ch [131.152.34.41]) by balu1.urz.unibas.ch (8.13.5/8.13.5) with ESMTP id k1RAbP1Q023473; Mon, 27 Feb 2006 11:37:25 +0100 Message-ID: <4402D666.7030001@unibas.ch> Date: Mon, 27 Feb 2006 11:37:26 +0100 From: Christophe Jelger Organization: University of Basel User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa References: <704bb0850602270021o1f23772as@mail.gmail.com> <5FF59CC1-10A2-4C45-B7C7-F7089476AB45@sfc.wide.ad.jp> In-Reply-To: <5FF59CC1-10A2-4C45-B7C7-F7089476AB45@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-Vilter-Version: 1.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Youngmin Kim , autoconf@ietf.org, manet@ietf.org Subject: [Autoconf] Re: [manet] Default route (internet route) for global connectivity X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi Ryuji/all, See my comments inline below. regards, Christophe Ryuji Wakikawa wrote: > Hello Kim > > On 2006/02/27, at 17:21, Youngmin Kim wrote: > >> Hello. >> I have had a question while I was reading draft-wakikawa-manet- >> globalv6-04.txt. >> Manet node configures a routable IP address from the prefix of the >> gateway and inserts the gateway address as an internet route. Next hop >> for default route is the internet-gateway address. >> As I know, next hop is one hop distance neighbor. Internet-gateway may >> not be one hop neighbor from manet node. How can the internet-gateway >> be set to next hop? You use a tunnel? > > > The route configuration is different on each OS. > I want to leave this as implementation specific. > > What we wrote in the draft is that MN setup both a default route and a > host route to IGW. > 1. :: -> IGW > 2. IGW -> next hop > Then, a MN can recursively lookup the routing table. > > I think how to treat a route inside OS is beyond specification. Well we've already discussed this a while ago and I tend to disagree here for a few reasons: 1. OS don't do dual-lookups, and having a solution that requires dual-lookups (or recursive as you call it) introduces a lot of hassles: changing kernel-code, patching, re-compiling, which slows down use and deployment (e.g. MIPv6). 2. Whether you use a tunnel (or a routing header) or rely on "routing coherence" imposes different requirements. The first solution is the easiest because you explicitly say via which gateway you want your packets to go through. The second solution requires a logical organization (e.g. prefix continuity) and it's more complex to setup but you don't need to introduce any forwarding indirection (which usually means changing or "hooking into" the kernel in order to setup the tunnel). I think that leaving such details as "implementation specific" is risky because these details are exactly what makes MANETs different from traditional LANs. Especially the point 2. (above) is tricky because two implementations may end up using different schemes and may not interoperate. For having implemented various flavors of autoconf, I know it's not a simple issue that should be left aside. Other issues also arise: for example, once you have a default route how would your reactive protocol behave ? Always try to discover first and use the gateway if it fails ? These kind of issues are exactly what we need to clarify. Regards, Christophe > > regards > ryuji > >> Thank you. >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf