From autoconf-bounces@ietf.org Mon Oct 02 07:40:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUM9L-0002ZZ-Ta; Mon, 02 Oct 2006 07:39:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUM9L-0002ZR-Fz for autoconf@ietf.org; Mon, 02 Oct 2006 07:39:55 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUM9I-0005ca-W6 for autoconf@ietf.org; Mon, 02 Oct 2006 07:39:55 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 91FBC8984E; Mon, 2 Oct 2006 14:39:49 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3D15489808; Mon, 2 Oct 2006 14:39:49 +0300 (EEST) Message-ID: <4520FA6E.5030102@piuha.net> Date: Mon, 02 Oct 2006 14:39:26 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: autoconf@ietf.org, ian.chakeres@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Subject: [Autoconf] review of draft-chakeres-manet-arch-00.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: , Errors-To: autoconf-bounces@ietf.org Ian et al, I have read this document. Overall, its well written and its easy to agree with everything that it says. I liked the terminology that the document used. Unfortunately, it also doesn't go very far in terms of defining an architecture. In fact, there's very little in the document that goes beyond terminology and design challenges/requirements. In particular, I expected to find a description of what subnet model will be used, whether one can attach regular non-MANET interfaces to MRs, what security model will be applied, etc. For most of these questions the answer is probably very short and simple, but it is important that you have an answer. (Please remember that we are attempting to create standards in this space, and, as a part of that effort, it is natural that we have to choose a particular way of doing things as opposed to allowing or enumerating all possible ways that it could be done.) > MANET Router (MR) > a router that engages in a MANET routing protocol. In certain > scenarios a MR may forward packets only for itself (and its > attached nodes). > This may need clarification. I think you mean that a MR may forward packets only to itself or to nodes attached to it in a non-MANET manner (e.g., a device that offers a WLAN interface to regular hosts). But I wonder how typical it is for an MR to not forward in the MANET, and whether it is something that you want to highlight the definition. > 5. Architectural Issues There's very little architecture here, and the current text should probably should be placed in the previous section "Challenges". See also my high-level comments. > 7. Security Considerations > > TBD Like for the architecture, we need to make decisions so that work can progress. For instance, if you disallow prior arrangements to authorize nodes to act in a MANET, this probably has an effect to the kind of solutions that we can consider. > 6.4. Example Deployments If this section were completed it would be interesting, but I'm not sure it would be useful for the task at hand, i.e., defining the architecture of the MANETs. Focus on the architecture, not secondary issues. --Jari _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Oct 02 09:51:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOCq-0001cl-Pf; Mon, 02 Oct 2006 09:51:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOCq-0001Xs-4k for autoconf@ietf.org; Mon, 02 Oct 2006 09:51:40 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOCo-0005Dq-QO for autoconf@ietf.org; Mon, 02 Oct 2006 09:51:40 -0400 Received: by ug-out-1314.google.com with SMTP id 72so443675ugd for ; Mon, 02 Oct 2006 06:51:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tx1Z9HviHyd89i/UCvpWEmC3EoF9af0puDLVkLvllMMXCrCBW5QHwOpw59JgcFd+z4PX5oSz15nYEwQiKhBWnh8WjO2Sck+g9VlGQAgZB08dmz8BcuckTzHDvufgRR7abjcV+IsRBm474R7BUxqb2U7GaypCtEg6cihKlFh/fkY= Received: by 10.67.101.10 with SMTP id d10mr5290572ugm; Mon, 02 Oct 2006 06:51:35 -0700 (PDT) Received: by 10.66.224.14 with HTTP; Mon, 2 Oct 2006 06:51:35 -0700 (PDT) Message-ID: <374005f30610020651s7a997c22n2afec7c1cf375b25@mail.gmail.com> Date: Mon, 2 Oct 2006 06:51:35 -0700 From: "Ian Chakeres" To: "Jari Arkko" In-Reply-To: <4520FA6E.5030102@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4520FA6E.5030102@piuha.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: autoconf@ietf.org Subject: [Autoconf] Re: review of draft-chakeres-manet-arch-00.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: , Errors-To: autoconf-bounces@ietf.org Thank you very much for your comments Jari. We have been working hard to create a new revision based on people's feedback, and I have already made several of the changes you've suggested. I hope to submit the new rev in the next few days, so it can be discussed in San Diego. Thanks. Ian Chakeres On 10/2/06, Jari Arkko wrote: > Ian et al, > > I have read this document. Overall, its well > written and its easy to agree with everything > that it says. I liked the terminology that the > document used. > > Unfortunately, it also doesn't go very far in terms > of defining an architecture. In fact, there's very > little in the document that goes beyond terminology > and design challenges/requirements. In particular, > I expected to find a description of what subnet > model will be used, whether one can attach > regular non-MANET interfaces to MRs, what > security model will be applied, etc. > > For most of these questions the answer is > probably very short and simple, but it is > important that you have an answer. (Please > remember that we are attempting to create > standards in this space, and, as a part of that > effort, it is natural that we have to choose > a particular way of doing things as opposed to > allowing or enumerating all possible ways > that it could be done.) > > MANET Router (MR) > > a router that engages in a MANET routing protocol. In certain > > scenarios a MR may forward packets only for itself (and its > > attached nodes). > > > This may need clarification. I think you mean that a MR may forward > packets only to itself or to nodes attached to it in a non-MANET manner > (e.g., a device that offers a WLAN interface to regular hosts). But I > wonder how typical it is for an MR to not forward in the MANET, > and whether it is something that you want to highlight the > definition. > > 5. Architectural Issues > There's very little architecture here, and the > current text should probably should be placed > in the previous section "Challenges". > > See also my high-level comments. > > 7. Security Considerations > > > > TBD > Like for the architecture, we need to make decisions so > that work can progress. For instance, if you disallow > prior arrangements to authorize nodes to act in a MANET, > this probably has an effect to the kind of solutions that > we can consider. > > 6.4. Example Deployments > If this section were completed it would be interesting, but > I'm not sure it would be useful for the task at hand, i.e., > defining the architecture of the MANETs. Focus on the > architecture, not secondary issues. > > --Jari > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Oct 02 10:07:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOST-0002CN-LV; Mon, 02 Oct 2006 10:07:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOSS-0002Aw-7b for autoconf@ietf.org; Mon, 02 Oct 2006 10:07:48 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOSO-0006av-Tw for autoconf@ietf.org; Mon, 02 Oct 2006 10:07:48 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7C0FD8984E; Mon, 2 Oct 2006 17:07:41 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 365AE89808; Mon, 2 Oct 2006 17:07:41 +0300 (EEST) Message-ID: <45211D16.2010202@piuha.net> Date: Mon, 02 Oct 2006 17:07:18 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: Ian Chakeres References: <4520FA6E.5030102@piuha.net> <374005f30610020651s7a997c22n2afec7c1cf375b25@mail.gmail.com> In-Reply-To: <374005f30610020651s7a997c22n2afec7c1cf375b25@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: autoconf@ietf.org Subject: [Autoconf] Re: review of draft-chakeres-manet-arch-00.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: , Errors-To: autoconf-bounces@ietf.org Ian Chakeres wrote: > Thank you very much for your comments Jari. > > We have been working hard to create a new revision based on people's > feedback, and I have already made several of the changes you've > suggested. Good! > I hope to submit the new rev in the next few days, so it > can be discussed in San Diego. Any pointers on what you intend to say? There's no penalty for discussing things before the IETF meeting. --Jari _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Oct 02 14:00:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUS5H-0000NE-II; Mon, 02 Oct 2006 14:00:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUS5B-0008Lh-AX for autoconf@ietf.org; Mon, 02 Oct 2006 14:00:01 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GURzS-0000qZ-KM for autoconf@ietf.org; Mon, 02 Oct 2006 13:54:07 -0400 Received: by ug-out-1314.google.com with SMTP id 72so473423ugd for ; Mon, 02 Oct 2006 10:54:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nP9J2kFY1uScXMRHPekoANquL9dGJzMXfX6rIVRtWQPRUNt/0fK3iF21u3R2d/5ivZvsl7cWVQcqE6p1/odtjSB99tKvpabBTwmKQHaPYF8pKa8sFH6c76JUVV763IK60Q4E/L+wdZFEBviX/hx0h2oBrNTI4YUG5TlsxQS/mZ8= Received: by 10.67.101.8 with SMTP id d8mr5437859ugm; Mon, 02 Oct 2006 10:54:05 -0700 (PDT) Received: by 10.66.224.14 with HTTP; Mon, 2 Oct 2006 10:54:05 -0700 (PDT) Message-ID: <374005f30610021054s34ede90foa000d2096bb213b7@mail.gmail.com> Date: Mon, 2 Oct 2006 10:54:05 -0700 From: "Ian Chakeres" To: "Jari Arkko" In-Reply-To: <45211D16.2010202@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4520FA6E.5030102@piuha.net> <374005f30610020651s7a997c22n2afec7c1cf375b25@mail.gmail.com> <45211D16.2010202@piuha.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: autoconf@ietf.org Subject: [Autoconf] Re: review of draft-chakeres-manet-arch-00.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: , Errors-To: autoconf-bounces@ietf.org The number of changes in the ID is large, so I will withhold enumeration for a few more days while I work toward completion. In response to the subnet model of MANET, can you please elaborate on what you mean by subnet model? This is an often confused term and I'd like to understand your definition and question clearly. Ian Chakeres On 10/2/06, Jari Arkko wrote: > Ian Chakeres wrote: > > Thank you very much for your comments Jari. > > > > We have been working hard to create a new revision based on people's > > feedback, and I have already made several of the changes you've > > suggested. > Good! > > I hope to submit the new rev in the next few days, so it > > can be discussed in San Diego. > Any pointers on what you intend to say? There's no penalty > for discussing things before the IETF meeting. > > --Jari > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Oct 03 11:31:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmF7-00034g-1A; Tue, 03 Oct 2006 11:31:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmF6-00034U-9W for autoconf@ietf.org; Tue, 03 Oct 2006 11:31:36 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUmF2-0008B5-NL for autoconf@ietf.org; Tue, 03 Oct 2006 11:31:36 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8C80F1DEB6 for ; Tue, 3 Oct 2006 17:31:31 +0200 (CEST) Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 6CA951CEE3 for ; Tue, 3 Oct 2006 17:31:31 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: autoconf@ietf.org Organization: Universidad Carlos III de Madrid Date: Tue, 03 Oct 2006 17:31:31 +0200 Message-Id: <1159889491.25390.26.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: [Autoconf] CfP WWIC 2007 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1304719349==" Errors-To: autoconf-bounces@ietf.org --===============1304719349== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-G+SrRHjSKF2EqeExWlX8" --=-G+SrRHjSKF2EqeExWlX8 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Our apologies for duplicate postings. ------------------------------------------------------------------------- CALL FOR PAPERS WWIC 2007 5th International Conference on Wired / Wireless Internet Communications May 23-25 2007, Coimbra, Portugal http://wwic2007.dei.uc.pt =20 Next generation mobile networks will be based on Internet core networks and wireless access networks. The need for efficient merging of the wired and wireless infrastructure as well as the new multimedia services and applications of next generation networks call for novel network architectures, protocols and traffic-related mechanisms. WWIC addresses research topics such as the design and evaluation of protocols, the dynamics of the integration, the performance tradeoffs, the need for new performance metrics, and cross-layer interactions. The goal of the conference is to present high-quality results in the field, and to provide a framework for research collaboration through focused discussions that will designate future research efforts and directions. In this context, the program committee will accept only a limited number of papers that meet the criteria of originality, presentation quality and topic relevance. Important dates: Submission deadline: December 8, 2006 =20 Notification of acceptance: February 19, 2007 =20 Camera ready papers: February 28, 2007 Conference topics: The conference objectives will be pursued through highly technical sessions organized thematically and invited keynote talks offered by recognized experts. Topics of interest to WWIC 2007 include (but are not limited to) the following: AAA in mobile environments, Ambient networks, Ad-hoc mobile networks, Blended network configurations, Beyond 3G networks technologies, Cross layer interactions, Economical issues of wireless networks, End-to-end Quality of Service support, Handover techniques, Heterogeneous wireless access networks, Hybrid wired / wireless environments, Integration of wired and wireless networks, Mobile service level agreements / specification, Mobility management, Network design and network planning, Network mobility, Network coding in mobile networks, Network security in mobile environments, Performance evaluation of wireless systems, Pricing, charging and accounting in wireless networks, QoS routing in mobile networks, QoS signalling in mobile environments, Resource management and admission control, Service creation and management for wireless, Simulation for next generation mobile networks, Traffic characterisation and modeling, Traffic engineering, Transport protocols and congestion control, Wireless mesh networks, Wireless multi-hop networks, Wireless multimedia systems, Wireless network monitoring Wireless sensor networks Proceedings: The authors are encouraged to submit full papers describing original, previously unpublished, complete research, not currently under review by another conference or journal, addressing state-of-the-art research and development in all areas of computer networking and data communications. All papers will be reviewed and accepted papers will appear in the conference proceedings, published by Springer-Verlag in the LNCS series (approval pending). Papers must be submitted electronically. The maximum size of papers should be 5000 words including tables and figures. Please adhere to the formatting standard for a 12-page manuscript of Springer-Verlag LNCS. The cover page must contain an abstract of about 150 words, 3-5 keywords, name and affiliation of author(s) as well as the corresponding author's e-mail and postal address. There will be a Best Paper Award for the best submitted paper. --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 --=-G+SrRHjSKF2EqeExWlX8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFIoJT7QxZUr+JuXQRAqKLAKDI4KMpiF7h6vm5niTXJ/Ozb0vJGQCfRYTV xxjkjJfHTfNw46MOixJLZ10= =9VCd -----END PGP SIGNATURE----- --=-G+SrRHjSKF2EqeExWlX8-- --===============1304719349== 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 --===============1304719349==-- From autoconf-bounces@ietf.org Wed Oct 04 02:10:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUzx5-0001DZ-Rk; Wed, 04 Oct 2006 02:09:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUuc8-0004jE-PK for autoconf@ietf.org; Tue, 03 Oct 2006 20:27:56 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUuc4-00046N-ES for autoconf@ietf.org; Tue, 03 Oct 2006 20:27:56 -0400 Received: from ms152.net.ie.niigata-u.ac.jp ([133.35.156.152] helo=[192.168.100.94]) by outbound.mailhop.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.51) id 1GUuc3-000FSl-Um; Tue, 03 Oct 2006 20:27:52 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 133.35.156.152 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: voop In-Reply-To: <4520FA6E.5030102@piuha.net> References: <4520FA6E.5030102@piuha.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9C466697-EB5F-4E64-9C3F-CE7EA918711A@polytechnique.fr> Content-Transfer-Encoding: 7bit From: Thomas Clausen Subject: Re: [Autoconf] review of draft-chakeres-manet-arch-00.txt Date: Wed, 4 Oct 2006 01:16:55 +0200 To: Jari Arkko X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 X-Mailman-Approved-At: Wed, 04 Oct 2006 02:09:53 -0400 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: , Errors-To: autoconf-bounces@ietf.org Jari, Thanks for your thoughtful comments. I'll give a few comments below. On Oct 2, 2006, at 1:39 PM, Jari Arkko wrote: > Ian et al, > > I have read this document. Overall, its well > written and its easy to agree with everything > that it says. I liked the terminology that the > document used. > > Unfortunately, it also doesn't go very far in terms > of defining an architecture. In fact, there's very > little in the document that goes beyond terminology > and design challenges/requirements. In particular, > I expected to find a description of what subnet > model will be used, This, I think, is a topic that we need to discuss - I sense from our off-line discussions that we share an understanding of this, but we clearly do not do a good enough job at putting it into words in the I-D. > whether one can attach > regular non-MANET interfaces to MRs, Short answer: Yes. Longer answer: a MR in this respect is no different from any other R, which may have interfaces over which a routing protocol runs, and interfaces over which they do not. Or interfaces over which routing protocol X runs and interfaces over which routing protocol Y runs - and so on and so forth. > what > security model will be applied, etc. > > For most of these questions the answer is > probably very short and simple, but it is > important that you have an answer. (Please > remember that we are attempting to create > standards in this space, and, as a part of that > effort, it is natural that we have to choose > a particular way of doing things as opposed to > allowing or enumerating all possible ways > that it could be done.) Good point, and I agree. It's, therefore, very important also that we solicit and, if you wish, try to enumerate the options, such that we pick the right one. I hope that more people will give feedback on this I-D, that we may go forward with and informed choice. >> MANET Router (MR) >> a router that engages in a MANET routing protocol. In certain >> scenarios a MR may forward packets only for itself (and its >> attached nodes). >> > This may need clarification. I think you mean that a MR may forward > packets only to itself or to nodes attached to it in a non-MANET > manner > (e.g., a device that offers a WLAN interface to regular hosts). But I > wonder how typical it is for an MR to not forward in the MANET, > and whether it is something that you want to highlight the > definition. Actually, it is a permitted and, in some scenarios, useful mechanism. We have explicitly in, e.g., OLSR and OLSRv2 (and, I think DYMO too, but Ian can confirm) allowed for this. Think of such non-forwarding MRs as "routers which know they'll for a bit be roaming about a lot and therefore not be suitable network-forming-devices", yet still may have an external interface (WLAN) to which it would like to forward. --thomas >> 5. Architectural Issues > There's very little architecture here, and the > current text should probably should be placed > in the previous section "Challenges". > > See also my high-level comments. >> 7. Security Considerations >> >> TBD > Like for the architecture, we need to make decisions so > that work can progress. For instance, if you disallow > prior arrangements to authorize nodes to act in a MANET, > this probably has an effect to the kind of solutions that > we can consider. >> 6.4. Example Deployments > If this section were completed it would be interesting, but > I'm not sure it would be useful for the task at hand, i.e., > defining the architecture of the MANETs. Focus on the > architecture, not secondary issues. > > --Jari > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf > -- Thomas Clausen Thomas.Clausen@polytechnique.fr http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ http://www.lix.polytechnique.fr/hipercom/ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Oct 04 12:02:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9CA-0007sv-QA; Wed, 04 Oct 2006 12:02:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9C9-0007rg-0p for autoconf@ietf.org; Wed, 04 Oct 2006 12:02:05 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV90d-0001tf-5j for autoconf@ietf.org; Wed, 04 Oct 2006 11:50:13 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k94Fo7V6031093 for ; Wed, 4 Oct 2006 11:50:07 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k94Fo7nq142930 for ; Wed, 4 Oct 2006 11:50:07 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k94Fo7rd008953 for ; Wed, 4 Oct 2006 11:50:07 -0400 Received: from cichlid.raleigh.ibm.com (wecm-9-67-103-55.wecm.ibm.com [9.67.103.55]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k94Fo6Yf008910; Wed, 4 Oct 2006 11:50:07 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.7/8.12.5) with ESMTP id k94Fncms010732; Wed, 4 Oct 2006 11:50:02 -0400 Message-Id: <200610041550.k94Fncms010732@cichlid.raleigh.ibm.com> To: Thomas Clausen Subject: Re: [Autoconf] review of draft-chakeres-manet-arch-00.txt In-reply-to: <9C466697-EB5F-4E64-9C3F-CE7EA918711A@polytechnique.fr> References: <4520FA6E.5030102@piuha.net> <9C466697-EB5F-4E64-9C3F-CE7EA918711A@polytechnique.fr> Comments: In-reply-to Thomas Clausen message dated "Wed, 04 Oct 2006 01:16:55 +0200." Date: Wed, 04 Oct 2006 11:49:38 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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: , Errors-To: autoconf-bounces@ietf.org > This, I think, is a topic that we need to discuss - I sense from our > off-line discussions that we share an understanding of this, but we > clearly do not do a good enough job at putting it into words in the > I-D. Let me be frank (and this comment is really directed at the WG and the document authors). I've read the document and agree with Jari's assessment. But he's being very diplomatic. My own comments based on my review of two of the key documents is: manet-arch has no meat. As you may recall during the original chartering discussions, I've been really keen on understanding the basic subnet model. This document doesn't say anything about it! I think we are talking about a single page of (succinct) text. But we seem to keep dancing around the key questions that need to be answered! This documment has a lot of generic text about manets. We need to focus on the issues specific to an IP environment and what the basic subnet model is. If the answer is "there are no subnets, its flat host routing within an ASN", you need to come out and just say so. (and this can't actually be the answer, because you probably have to have a "link" between a node and its neighboring router, even if only to handle the case of being able to reach your neighbor.) (And the defn of an ASN is not good, IMO, because ASN already has a clear meaning in BGP/OSPF, but means something different in manets.) Autoconf-statement seems to basically say "we need to assign unique addresses", which is obvious. But how hard that is or why this is complicated (IMO) has little meaning until some basic assumptions are nailed down on the subnet model, and how it differs from what we are familiar with in other LANs (e.g., ethernets) I.e., why doesn't stateless addrconf work? Or DHC? Just asserting they don't isn't an answer. You have to explain why. (And I suspect that in order to explain why, you have to make assumptions about the subnet/link model...) Now, what I would suggest is that these topics be discussed _here_ (on the mailing list) and _now_. I.e., not "in the next rev of the document. How about proposing some text (that could maybe go into the document), but post it here so we can get some discussion about whether the text is what is needed. Please do this on the mailing list, so we don't have deal with the (very long) cycle of publish a draft, get comments, revise draft, etc. Thomas _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Oct 04 12:27:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9aH-0000tp-GM; Wed, 04 Oct 2006 12:27:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9aF-0000p9-QA for autoconf@ietf.org; Wed, 04 Oct 2006 12:26:59 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV9MI-000655-3t for autoconf@ietf.org; Wed, 04 Oct 2006 12:12:35 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 04 Oct 2006 09:12:34 -0700 X-IronPort-AV: i="4.09,256,1157353200"; d="scan'208"; a="44826193:sNHT58607820" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k94GCXjU022374; Wed, 4 Oct 2006 12:12:33 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k94GCXdO020804; Wed, 4 Oct 2006 12:12:33 -0400 (EDT) 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.1830); Wed, 4 Oct 2006 12:12:33 -0400 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 ; Wed, 4 Oct 2006 16:12:32 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Wed, 04 Oct 2006 12:12:35 -0400 Subject: Re: [Autoconf] review of draft-chakeres-manet-arch-00.txt From: Ralph Droms To: Thomas Narten , Thomas Clausen Message-ID: Thread-Topic: [Autoconf] review of draft-chakeres-manet-arch-00.txt Thread-Index: Acbnz+c2Jfj4zFPDEduerwARJOT6eg== In-Reply-To: <200610041550.k94Fncms010732@cichlid.raleigh.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 16:12:33.0148 (UTC) FILETIME=[E61C03C0:01C6E7CF] DKIM-Signature: a=rsa-sha1; q=dns; l=3740; t=1159978354; x=1160842354; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:Ralph=20Droms=20 |Subject:Re=3A=20[Autoconf]=20review=20of=20draft-chakeres-manet-arch-00.txt=20 |To:Thomas=20Narten=20, =0A=20=20=20=20=20=20=20=20Thomas= 20Clausen=20; X=v=3Dcisco.com=3B=20h=3Dxn5mzXQs7iO932z0hJZ6zdJ9yH8=3D; b=KOe2HTevHznZweXbxD21zHtE90R7XaTTxpYrih0hTQCqA7aA+XG/U9h0+GBCbrWlNe5Lp94O 6fotvSqi03BuY0cTCLXBoH41b3Axs44J8MW2MzYY0NjLJV+2t7wSqPTw; Authentication-Results: rtp-dkim-1.cisco.com; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.5 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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: , Errors-To: autoconf-bounces@ietf.org Thomas - I agree that some additional detail in fundamental assumptions is needed. But, I think we need a better term than "subnet model". I think you mean "basic assumptions about L2 delivery that affect IP". For example, IPoEthernet assumes every transmission reaches every node, every node has a unique L2 address, there is an MTU, there is a broadcast mechanism, there is a multicast mechanism, etc. At the risk of over-generalization, those assumptions are reflected in the design of IP. An L2 technology that deviates from those assumptions will have an effect on how IP operates. I see two ways to deal with an L2 technology that has fundamental characteristics that differ from those assumed by IP: add function to L2 to meet those assumptions; modify IP to work with the L2 characteristics. Either way, we have to know the characteristics first. I started off by suggesting we need a better term than "subnet model". How about "L2 model"? - Ralph On 10/4/06 11:49 AM, "Thomas Narten" wrote: >> This, I think, is a topic that we need to discuss - I sense from our >> off-line discussions that we share an understanding of this, but we >> clearly do not do a good enough job at putting it into words in the >> I-D. > > Let me be frank (and this comment is really directed at the WG and the > document authors). I've read the document and agree with Jari's > assessment. But he's being very diplomatic. My own comments based on > my review of two of the key documents is: > > manet-arch has no meat. As you may recall during the original > chartering discussions, I've been really keen on understanding the > basic subnet model. This document doesn't say anything about it! I > think we are talking about a single page of (succinct) text. But we > seem to keep dancing around the key questions that need to be > answered! This documment has a lot of generic text about manets. We > need to focus on the issues specific to an IP environment and what the > basic subnet model is. If the answer is "there are no subnets, its > flat host routing within an ASN", you need to come out and just say > so. (and this can't actually be the answer, because you probably have > to have a "link" between a node and its neighboring router, even if > only to handle the case of being able to reach your neighbor.) > > (And the defn of an ASN is not good, IMO, because ASN already has a > clear meaning in BGP/OSPF, but means something different in manets.) > > Autoconf-statement seems to basically say "we need to assign unique > addresses", which is obvious. But how hard that is or why this is > complicated (IMO) has little meaning until some basic assumptions are > nailed down on the subnet model, and how it differs from what we are > familiar with in other LANs (e.g., ethernets) I.e., why doesn't > stateless addrconf work? Or DHC? Just asserting they don't isn't an > answer. You have to explain why. (And I suspect that in order to > explain why, you have to make assumptions about the subnet/link > model...) > > Now, what I would suggest is that these topics be discussed _here_ (on > the mailing list) and _now_. I.e., not "in the next rev of the > document. How about proposing some text (that could maybe go into the > document), but post it here so we can get some discussion about > whether the text is what is needed. Please do this on the mailing > list, so we don't have deal with the (very long) cycle of publish a > draft, get comments, revise draft, etc. > > Thomas > > _______________________________________________ > 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 Oct 04 12:31:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9es-0004LU-LC; Wed, 04 Oct 2006 12:31:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9er-0004LJ-Fy for autoconf@ietf.org; Wed, 04 Oct 2006 12:31:45 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV9ep-0001am-8A for autoconf@ietf.org; Wed, 04 Oct 2006 12:31:45 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k94GV3aw014672; Wed, 4 Oct 2006 19:31:30 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 19:31:06 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 11:31:00 -0500 Received: from [10.241.52.125] ([10.241.52.125]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 11:30:59 -0500 Message-ID: <4523E1C1.8080203@nokia.com> Date: Wed, 04 Oct 2006 09:30:57 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ext Thomas Narten Subject: Re: [Autoconf] review of draft-chakeres-manet-arch-00.txt References: <4520FA6E.5030102@piuha.net> <9C466697-EB5F-4E64-9C3F-CE7EA918711A@polytechnique.fr> <200610041550.k94Fncms010732@cichlid.raleigh.ibm.com> In-Reply-To: <200610041550.k94Fncms010732@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 16:30:59.0524 (UTC) FILETIME=[798F9840:01C6E7D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: autoconf@ietf.org, Thomas Clausen 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 Hello Thomas, ext Thomas Narten wrote: > As you may recall during the original > chartering discussions, I've been really keen on understanding the > basic subnet model. This document doesn't say anything about it! I think that is probably a good thing. We need to make an autoconfiguration protocol that works even in the absence of well-defined subnets. > We need to focus on the issues specific to an IP environment O.K. > and what the > basic subnet model is. You didn't explain why. The fact is, that many people have built workable systems using various autoconfiguration techniques, without going into paroxysms and paralysis trying to solve this non-essential problem. > If the answer is "there are no subnets, its > flat host routing within an ASN", you need to come out and just say > so. Well, I reckon that subnets can be "allowed" -- without being a stumbling block when the collection of nodes that are internetworking do not conform naturally to any subnet model. > (and this can't actually be the answer, because you probably have > to have a "link" between a node and its neighboring router, even if > only to handle the case of being able to reach your neighbor.) > You do not need to be on a common subnet to have IP connectivity. You need to have a common link. And I do not think it is reasonable to assume that every link has a subnet prefix (i.e., not every link is a subnet). Regards, Charlie P. -- Please address return e-mail to charles.perkins@nokia.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Oct 04 12:47:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9uB-0005oh-BD; Wed, 04 Oct 2006 12:47:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9uA-0005nN-MT for autoconf@ietf.org; Wed, 04 Oct 2006 12:47:34 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV9qg-0004Zr-Ez for autoconf@ietf.org; Wed, 04 Oct 2006 12:44:00 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 04 Oct 2006 12:43:59 -0400 X-IronPort-AV: i="4.09,256,1157342400"; d="scan'208"; a="105711946:sNHT74291430" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k94GhwVI003349; Wed, 4 Oct 2006 12:43:58 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k94GhvdM005957; Wed, 4 Oct 2006 12:43:57 -0400 (EDT) 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.1830); Wed, 4 Oct 2006 12:43:57 -0400 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 ; Wed, 4 Oct 2006 16:43:57 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Wed, 04 Oct 2006 12:44:00 -0400 Subject: Re: [Autoconf] review of draft-chakeres-manet-arch-00.txt From: Ralph Droms To: "Charles E. Perkins" , Thomas Narten Message-ID: Thread-Topic: [Autoconf] review of draft-chakeres-manet-arch-00.txt Thread-Index: Acbn1ErCiRcbpVPHEduerwARJOT6eg== In-Reply-To: <4523E1C1.8080203@nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 16:43:57.0574 (UTC) FILETIME=[49509A60:01C6E7D4] DKIM-Signature: a=rsa-sha1; q=dns; l=1985; t=1159980238; x=1160844238; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:Ralph=20Droms=20 |Subject:Re=3A=20[Autoconf]=20review=20of=20draft-chakeres-manet-arch-00.txt |To:=22Charles=20E.=20Perkins=22=20, =0A=20=20=20= 20=20=20=20=20Thomas=20Narten=20; X=v=3Dcisco.com=3B=20h=3Dxn5mzXQs7iO932z0hJZ6zdJ9yH8=3D; b=EdJJNaRucENyYsL8MuU0xhYdOH6XjvCWFto658iJZAyMl0Y6EQm/ZvR0SZ7W1K96K6DVyJfM ARZoSAe1zKFWRzSYfvCO8hEm3k1p+Xs2rLX95DWRcbpSYK8mTuPloPES; Authentication-Results: rtp-dkim-2.cisco.com; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.5 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: autoconf@ietf.org, Thomas Clausen 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 Charlie - perhaps we're running into the terminology problem I mentioned in my previous e-mail; "subnet model" might be misleading. Do you agree that there has to be some explicit description of the characteristics of the L2 connectivity to give a basis for discussion of manet autoconf mechanisms? What shall we call that description? - Ralph On 10/4/06 12:30 PM, "Charles E. Perkins" wrote: > > Hello Thomas, > > ext Thomas Narten wrote: >> As you may recall during the original >> chartering discussions, I've been really keen on understanding the >> basic subnet model. This document doesn't say anything about it! > I think that is probably a good thing. We need to make an autoconfiguration > protocol that works even in the absence of well-defined subnets. >> We need to focus on the issues specific to an IP environment > O.K. >> and what the >> basic subnet model is. > You didn't explain why. The fact is, that many people have built workable > systems using various autoconfiguration techniques, without going into > paroxysms and paralysis trying to solve this non-essential problem. >> If the answer is "there are no subnets, its >> flat host routing within an ASN", you need to come out and just say >> so. > Well, I reckon that subnets can be "allowed" -- without being a stumbling > block when the collection of nodes that are internetworking do not conform > naturally to any subnet model. >> (and this can't actually be the answer, because you probably have >> to have a "link" between a node and its neighboring router, even if >> only to handle the case of being able to reach your neighbor.) >> > You do not need to be on a common subnet to have IP connectivity. > You need to have a common link. And I do not think it is reasonable > to assume that every link has a subnet prefix (i.e., not every link is > a subnet). > > > Regards, > Charlie P. > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Oct 04 13:03:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVA9G-0002kL-VE; Wed, 04 Oct 2006 13:03:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVA9E-0002kG-Sv for autoconf@ietf.org; Wed, 04 Oct 2006 13:03:08 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVA9C-00005W-D6 for autoconf@ietf.org; Wed, 04 Oct 2006 13:03:08 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k94H2xkw001218; Wed, 4 Oct 2006 20:02:59 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 20:02:59 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 12:02:44 -0500 Received: from [10.241.52.125] ([10.241.52.125]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 12:02:43 -0500 Message-ID: <4523E931.8060802@nokia.com> Date: Wed, 04 Oct 2006 10:02:41 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ext Ralph Droms Subject: Re: [Autoconf] review of draft-chakeres-manet-arch-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 17:02:43.0282 (UTC) FILETIME=[E84A0320:01C6E7D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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: , Errors-To: autoconf-bounces@ietf.org Hello Ralph, I am not sure such an explicit description is needed. If a node transmits a packet over a link and another node receives the packet as sent, then what more is needed? For more general delivery mechanisms such as multicast and broadcast transmission of IP packets, some information about L2 connectivity is important to know. But I don't think that is what you are looking for, is it? Regarding the subnet model and its applicability, I have always thought that any node announcing reachability to a subnet has to be responsible for verifying that reachability. But for a large class of manets we do not need that. Regards, Charlie P. ext Ralph Droms wrote: > Charlie - perhaps we're running into the terminology problem I mentioned in > my previous e-mail; "subnet model" might be misleading. Do you agree that > there has to be some explicit description of the characteristics of the L2 > connectivity to give a basis for discussion of manet autoconf mechanisms? > What shall we call that description? > > - Ralph > > > On 10/4/06 12:30 PM, "Charles E. Perkins" wrote: > > >> Hello Thomas, >> >> ext Thomas Narten wrote: >> >>> As you may recall during the original >>> chartering discussions, I've been really keen on understanding the >>> basic subnet model. This document doesn't say anything about it! >>> >> I think that is probably a good thing. We need to make an autoconfiguration >> protocol that works even in the absence of well-defined subnets. >> >>> We need to focus on the issues specific to an IP environment >>> >> O.K. >> >>> and what the >>> basic subnet model is. >>> >> You didn't explain why. The fact is, that many people have built workable >> systems using various autoconfiguration techniques, without going into >> paroxysms and paralysis trying to solve this non-essential problem. >> >>> If the answer is "there are no subnets, its >>> flat host routing within an ASN", you need to come out and just say >>> so. >>> >> Well, I reckon that subnets can be "allowed" -- without being a stumbling >> block when the collection of nodes that are internetworking do not conform >> naturally to any subnet model. >> >>> (and this can't actually be the answer, because you probably have >>> to have a "link" between a node and its neighboring router, even if >>> only to handle the case of being able to reach your neighbor.) >>> >>> >> You do not need to be on a common subnet to have IP connectivity. >> You need to have a common link. And I do not think it is reasonable >> to assume that every link has a subnet prefix (i.e., not every link is >> a subnet). >> >> >> Regards, >> Charlie P. >> >> -- Please address return e-mail to charles.perkins@nokia.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Oct 04 13:28:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVAXQ-0001pB-TV; Wed, 04 Oct 2006 13:28:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVAXP-0001oR-4C for autoconf@ietf.org; Wed, 04 Oct 2006 13:28:07 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVAK0-00027n-SO for autoconf@ietf.org; Wed, 04 Oct 2006 13:14:19 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id k94HEAdW026979; Wed, 4 Oct 2006 13:14:10 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2006100413145621120 ; Wed, 04 Oct 2006 13:14:56 -0400 From: "Joe Macker" To: "'Charles E. Perkins'" , "'ext Thomas Narten'" Subject: RE: [Autoconf] review of draft-chakeres-manet-arch-00.txt Date: Wed, 4 Oct 2006 13:14:07 -0400 Message-ID: <017c01c6e7d8$7feb7f50$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.2962 In-Reply-To: <4523E1C1.8080203@nokia.com> Thread-Index: Acbn0qe9WrSErMWxSWm9zsO5c2amMAABJ2Mg X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: autoconf@ietf.org, 'Thomas Clausen' 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 >-----Original Message----- >From: Charles E. Perkins [mailto:charles.perkins@nokia.com] >Sent: Wednesday, October 04, 2006 12:31 PM >To: ext Thomas Narten >Cc: autoconf@ietf.org; Thomas Clausen >Subject: Re: [Autoconf] review of draft-chakeres-manet-arch-00.txt > > >Hello Thomas, > >ext Thomas Narten wrote: >> As you may recall during the original >> chartering discussions, I've been really keen on understanding the >> basic subnet model. This document doesn't say anything about it! >I think that is probably a good thing. We need to make an >autoconfiguration protocol that works even in the absence of >well-defined subnets. >> We need to focus on the issues specific to an IP environment >O.K. >> and what the >> basic subnet model is. >You didn't explain why. The fact is, that many people have >built workable systems using various autoconfiguration >techniques, without going into paroxysms and paralysis trying >to solve this non-essential problem. >> If the answer is "there are no subnets, its flat host routing within >> an ASN", you need to come out and just say so. >Well, I reckon that subnets can be "allowed" -- without being >a stumbling block when the collection of nodes that are >internetworking do not conform naturally to any subnet model. >> (and this can't actually be the answer, because you >probably have to >> have a "link" between a node and its neighboring router, >even if only >> to handle the case of being able to reach your neighbor.) >> >You do not need to be on a common subnet to have IP connectivity. >You need to have a common link. And I do not think it is >reasonable to assume that every link has a subnet prefix >(i.e., not every link is a subnet). True since we define MRs as routers. We certainly have implemented routers that use link local addresses and unnumbered interfaces to support attached prefixes. Flat host routing yuck why would we say that. One thing missing is interconnectivity scenarios which we had in a different draft. This can lead to multiple valid autconf solution spaces. > > >Regards, >Charlie P. > > >-- >Please address return e-mail to charles.perkins@nokia.com > > >_______________________________________________ >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 Oct 04 13:56:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVAzA-0003RS-IT; Wed, 04 Oct 2006 13:56:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVAz9-0003Qt-RT for autoconf@ietf.org; Wed, 04 Oct 2006 13:56:47 -0400 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVAz8-0000FB-J8 for autoconf@ietf.org; Wed, 04 Oct 2006 13:56:47 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k94HuhE1011202 for ; Wed, 4 Oct 2006 13:56:43 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k94Huf80126938 for ; Wed, 4 Oct 2006 13:56:43 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k94Huep3004813 for ; Wed, 4 Oct 2006 13:56:40 -0400 Received: from cichlid.raleigh.ibm.com (wecm-9-67-103-55.wecm.ibm.com [9.67.103.55]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k94HueoI004784; Wed, 4 Oct 2006 13:56:40 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.7/8.12.5) with ESMTP id k94HuTiF022005; Wed, 4 Oct 2006 13:56:45 -0400 Message-Id: <200610041756.k94HuTiF022005@cichlid.raleigh.ibm.com> To: Ralph Droms Subject: Re: [Autoconf] review of draft-chakeres-manet-arch-00.txt In-reply-to: References: Comments: In-reply-to Ralph Droms message dated "Wed, 04 Oct 2006 12:12:35 -0400." Date: Wed, 04 Oct 2006 13:56:29 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: autoconf@ietf.org, Thomas Clausen 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 Ralph. > Thomas - I agree that some additional detail in fundamental assumptions is > needed. But, I think we need a better term than "subnet model". I think > you mean "basic assumptions about L2 delivery that affect IP". For example, > IPoEthernet assumes every transmission reaches every node, every node has a > unique L2 address, there is an MTU, there is a broadcast mechanism, there is > a multicast mechanism, etc. Actually, after thinking a bit about this, I think I do mean "subnet model". This is all about defining the abstraction that IP sees. From IP's perspective, what does a manet network look like? But, let's dig deeper. Some questions: 1) What is the scope of an IP "link" or "subnet"? That is, if one has a manet (which consists of many routers and hosts), which hosts are considered (from IP's perspective) to be on the same "link", and thus can communicate directly with each other (without having to forward traffic through a router)? Note that here, I'm using the term "link", and one could assume link-local addressing is in use. 2) Are there "subnets" in a manet? That is, is there a prefix that covers multiple nodes? that is, where all the nodes on that subnet can reach each other (directly, without going through a router)? Or stated differently, are there subnets where all the nodes on that subnet can be assigned addresses out of the same prefix (and that can reach each other directly)? 3) What type of link does a "host" connect to? Is it essentially just a p2p link between itself and a router? Is a manet nothing more than a set of links, each of which is p2p? Consider Figure 1 in chakeres-manet-arch. It only shows routers. I'd like a corresponding figure that also shows hosts, and gives example IP address assignments, and shows where the IP subnets are. Thomas _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Oct 04 14:18:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBJp-0003A3-Oq; Wed, 04 Oct 2006 14:18:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBJo-00039T-DY for autoconf@ietf.org; Wed, 04 Oct 2006 14:18:08 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVBJm-0002kz-GF for autoconf@ietf.org; Wed, 04 Oct 2006 14:18:08 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k94IHYdi017589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 4 Oct 2006 11:17:35 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k94II5xa024973 for ; Wed, 4 Oct 2006 13:18:05 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k94IHvQC024635; Wed, 4 Oct 2006 13:18:05 -0500 (CDT) 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, 4 Oct 2006 11:18:03 -0700 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] review of draft-chakeres-manet-arch-00.txt Date: Wed, 4 Oct 2006 11:18:02 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774369@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <017c01c6e7d8$7feb7f50$165cfa84@SEXTANT> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] review of draft-chakeres-manet-arch-00.txt Thread-Index: Acbn0qe9WrSErMWxSWm9zsO5c2amMAABJ2MgAAFxerA= From: "Templin, Fred L" To: "Joe Macker" , "Charles E. Perkins" , "ext Thomas Narten" X-OriginalArrivalTime: 04 Oct 2006 18:18:04.0109 (UTC) FILETIME=[6EE977D0:01C6E7E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: autoconf@ietf.org, Thomas Clausen 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 Joe, > We certainly have implemented routers that use link > local addresses and unnumbered interfaces to support > attached prefixes. Yes; this approach was outlined in Dave Thaler's "Multi-subnet MANET" draft. Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Oct 04 14:27:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBSt-0003cA-Ml; Wed, 04 Oct 2006 14:27:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBSs-0003bP-Hg for autoconf@ietf.org; Wed, 04 Oct 2006 14:27:30 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVBSr-000453-97 for autoconf@ietf.org; Wed, 04 Oct 2006 14:27:30 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k94IQv4r024828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 4 Oct 2006 11:26:58 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k94IRR1v004310 for ; Wed, 4 Oct 2006 11:27:28 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k94IRFiO003878; Wed, 4 Oct 2006 11:27:27 -0700 (PDT) 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, 4 Oct 2006 11:27:27 -0700 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] review of draft-chakeres-manet-arch-00.txt Date: Wed, 4 Oct 2006 11:27:26 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177436A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774367@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] review of draft-chakeres-manet-arch-00.txt Thread-Index: Acbn1ErCiRcbpVPHEduerwARJOT6egABzJsAAAG+EcA= From: "Templin, Fred L" To: "Ralph Droms" , "Charles E. Perkins" , "Thomas Narten" X-OriginalArrivalTime: 04 Oct 2006 18:27:27.0280 (UTC) FILETIME=[BE968B00:01C6E7E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: autoconf@ietf.org, Thomas Clausen 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 (Did this not make it to the list?) Ralph, > Charlie - perhaps we're running into the terminology problem I mentioned in > my previous e-mail; "subnet model" might be misleading. Do you agree that > there has to be some explicit description of the characteristics of the L2 > connectivity to give a basis for discussion of manet autoconf mechanisms? > What shall we call that description? 'draft-templin-manet-autoconf-link' gives: "Observations on "Link" in MANET/Autoconf and Other Contexts". I don't know whether/not this would help these discussions. Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Oct 04 16:20:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVDET-0006IS-4h; Wed, 04 Oct 2006 16:20:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVDEQ-0006Gh-83 for autoconf@ietf.org; Wed, 04 Oct 2006 16:20:42 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVDEO-0006bg-Io for autoconf@ietf.org; Wed, 04 Oct 2006 16:20:41 -0400 Received: by ug-out-1314.google.com with SMTP id 72so107492ugd for ; Wed, 04 Oct 2006 13:20:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=D6R66k/h4AbUhin2zmgwtwX4hRVMHEvpbYA+5yOPQuejpB4HJX/OfTh/xXWDiXEQqqDmDIK1QUm9ILSzplpBPEvzylusilImpAYvVF0ya0hgBlF0aMdNk6WM7fjy7EvT4C9RYH7A+sYARuJg0G4sNj00dPVXOFkgdDw7GGlznrk= Received: by 10.66.240.12 with SMTP id n12mr1030026ugh; Wed, 04 Oct 2006 13:20:36 -0700 (PDT) Received: by 10.66.224.14 with HTTP; Wed, 4 Oct 2006 13:20:36 -0700 (PDT) Message-ID: <374005f30610041320l346c5e4ds6358234815a14090@mail.gmail.com> Date: Wed, 4 Oct 2006 13:20:36 -0700 From: "Ian Chakeres" To: "Thomas Narten" , autoconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Thomas Clausen Subject: [Autoconf] Re:subnet model 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 In response to the term "subnet model", I don't think that MANETs impose any new constraints. I will elaborate with my comments inline. BTW: I've submitted ARCH-01 to ID@ietf.org. Once it is on the server, I'll send notice to the list. On 10/4/06, Thomas Narten wrote: > Hi Ralph. > > > Thomas - I agree that some additional detail in fundamental assumptions is > > needed. But, I think we need a better term than "subnet model". I think > > you mean "basic assumptions about L2 delivery that affect IP". For example, > > IPoEthernet assumes every transmission reaches every node, every node has a > > unique L2 address, there is an MTU, there is a broadcast mechanism, there is > > a multicast mechanism, etc. > > Actually, after thinking a bit about this, I think I do mean "subnet > model". This is all about defining the abstraction that IP sees. From > IP's perspective, what does a manet network look like? > > But, let's dig deeper. Some questions: > > 1) What is the scope of an IP "link" or "subnet"? That is, if one has > a manet (which consists of many routers and hosts), which hosts are > considered (from IP's perspective) to be on the same "link", and > thus can communicate directly with each other (without having to > forward traffic through a router)? Note that here, I'm using the term "link", and one could > assume link-local addressing is in use. When a link local message is transmitted, then all nodes within one IP hop receive the message. I don't think MANET imposes any change to this definition. > 2) Are there "subnets" in a manet? That is, is there a prefix that > covers multiple nodes? that is, where all the nodes on that subnet > can reach each other (directly, without going through a router)? Or > stated differently, are there subnets where all the nodes on that > subnet can be assigned addresses out of the same prefix (and that > can reach each other directly)? I would say that in the most general case, a MANET router cannot make assumptions about the IP addresses of other MANET routers that are reachable using link local communication. That is not to say that a MANET router cannot be configured to make this assumption, if it is true. Again, I don't think that MANET imposes any change to existing definitions in this respect. I elaborate a little more below about hosts. > 3) What type of link does a "host" connect to? Is it essentially just > a p2p link between itself and a router? Is a manet nothing more > than a set of links, each of which is p2p? I think Joe addressed this question, but I will reiterate it here. A router supports attached prefixes. I think that hosts connect to the larger network by using a router. > Consider Figure 1 in chakeres-manet-arch. It only shows routers. I'd > like a corresponding figure that also shows hosts, and gives example > IP address assignments, and shows where the IP subnets are. If we look at a router, there might be several attached hosts. These hosts might possibly be in the same prefix to allow easy aggregation and advertisement in the routing protocol. Here is an example (pardon the ascii art) \|/ | wireless interface participating in MANET [RT1] | wired interface for attached hosts ---------------------------- | | [host1] [host2] Ian Chakeres _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Oct 04 17:45:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVEYT-0002zW-RS; Wed, 04 Oct 2006 17:45:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVEYS-0002zN-7G for autoconf@ietf.org; Wed, 04 Oct 2006 17:45:28 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVAlM-00078G-2y for autoconf@ietf.org; Wed, 04 Oct 2006 13:42:35 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k94HgTWe028563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 4 Oct 2006 12:42:29 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k94HgSCj004443 for ; Wed, 4 Oct 2006 10:42:28 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k94HgOSo004340; Wed, 4 Oct 2006 10:42:27 -0700 (PDT) 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, 4 Oct 2006 10:42:22 -0700 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] review of draft-chakeres-manet-arch-00.txt Date: Wed, 4 Oct 2006 10:42:21 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774367@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] review of draft-chakeres-manet-arch-00.txt Thread-Index: Acbn1ErCiRcbpVPHEduerwARJOT6egABzJsA From: "Templin, Fred L" To: "Ralph Droms" , "Charles E. Perkins" , "Thomas Narten" X-OriginalArrivalTime: 04 Oct 2006 17:42:22.0710 (UTC) FILETIME=[7289E960:01C6E7DC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: autoconf@ietf.org, Thomas Clausen 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 Ralph, > Charlie - perhaps we're running into the terminology problem I mentioned in > my previous e-mail; "subnet model" might be misleading. Do you agree that > there has to be some explicit description of the characteristics of the L2 > connectivity to give a basis for discussion of manet autoconf mechanisms? > What shall we call that description? 'draft-templin-manet-autoconf-link' gives: "Observations on "Link" in MANET/Autoconf and Other Contexts". I don't know whether/not this would help these discussions. Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Oct 04 21:29:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVI3L-00018X-Ll; Wed, 04 Oct 2006 21:29:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVI3K-00018S-Kb for autoconf@ietf.org; Wed, 04 Oct 2006 21:29:34 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVI3J-0004L0-77 for autoconf@ietf.org; Wed, 04 Oct 2006 21:29:34 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id k951TJLJ005053 for ; Wed, 4 Oct 2006 21:29:19 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k951TJE5329228 for ; Wed, 4 Oct 2006 19:29:19 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k951TIW9015381 for ; Wed, 4 Oct 2006 19:29:18 -0600 Received: from cichlid.raleigh.ibm.com (wecm-9-67-103-55.wecm.ibm.com [9.67.103.55]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k951TH2A015343; Wed, 4 Oct 2006 19:29:18 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.7/8.12.5) with ESMTP id k951TPGT000493; Wed, 4 Oct 2006 21:29:26 -0400 Message-Id: <200610050129.k951TPGT000493@cichlid.raleigh.ibm.com> To: "Ian Chakeres" Subject: Re: [Autoconf] Re:subnet model In-reply-to: <374005f30610041320l346c5e4ds6358234815a14090@mail.gmail.com> References: <374005f30610041320l346c5e4ds6358234815a14090@mail.gmail.com> Comments: In-reply-to "Ian Chakeres" message dated "Wed, 04 Oct 2006 13:20:36 -0700." Date: Wed, 04 Oct 2006 21:29:25 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: autoconf@ietf.org, Thomas Clausen 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 > > 1) What is the scope of an IP "link" or "subnet"? That is, if one has > > a manet (which consists of many routers and hosts), which hosts are > > considered (from IP's perspective) to be on the same "link", and > > thus can communicate directly with each other (without having to > > forward traffic through a router)? Note that here, I'm using the term "link", and one could > > assume link-local addressing is in use. > When a link local message is transmitted, then all nodes within one IP > hop receive the message. I don't think MANET imposes any change to > this definition. I don't understand what this means. This is more like an L2 statement that says "anyone within range gets the packet". What I'm asking is, what defines "one subnet hop"? Which nodes are attached the same link? Which are not? What is the distinction between those nodes? How does a node know which link it is attached to, since presumably there are presumably overlapping regions in some cases. In conventional links, the answer is obvious, because you don't have overlapping links. One is attached to one link, or another, but you don't have situations where the link is as ill-defined as "receives the signal". In comparison, with manets, one presumably has situations where those in the middle of a radio area can receive packets from all nodes, whereas those at the edges may not receive packets from those at the other edge. > > 2) Are there "subnets" in a manet? That is, is there a prefix that > > covers multiple nodes? that is, where all the nodes on that subnet > > can reach each other (directly, without going through a router)? Or > > stated differently, are there subnets where all the nodes on that > > subnet can be assigned addresses out of the same prefix (and that > > can reach each other directly)? > I would say that in the most general case, a MANET router cannot make > assumptions about the IP addresses of other MANET routers that are > reachable using link local communication. That is not to say that a > MANET router cannot be configured to make this assumption, if it is > true. Again, I don't think that MANET imposes any change to existing > definitions in this respect. I elaborate a little more below about > hosts. Again, I don't understand this answer. Is there a notion with manets that three hosts, say A, B & C are on the same subnet, but node D & E are on different subnets? This is a very basic concept with IP (i.e., A, B & C would be on one ethernet, D & E would be on another). Nodes A, B & C would have addresses on thes same subnet (and on the same subnet prefix), where D & E would have addresses corresponding to different subnet prefixes Is there a corresponding model with manets? > > 3) What type of link does a "host" connect to? Is it essentially just > > a p2p link between itself and a router? Is a manet nothing more > > than a set of links, each of which is p2p? > I think Joe addressed this question, but I will reiterate it here. A > router supports attached prefixes. I think that hosts connect to the > larger network by using a router. Again, I don't understand this response (or it doesn't answere what I'm trying to ask). Is a link a point-to-point link (from IP's perspective)? one that can have exactly to devices attached to it? Or is it something else? Again, I think it might really help to give some actual examples with (possible) IP addresses and (possible) subnet prefixes/masks. > > Consider Figure 1 in chakeres-manet-arch. It only shows routers. I'd > > like a corresponding figure that also shows hosts, and gives example > > IP address assignments, and shows where the IP subnets are. > If we look at a router, there might be several attached hosts. These > hosts might possibly be in the same prefix to allow easy aggregation > and advertisement in the routing protocol. Might? Or might not? Again, this sort of vague answer just doesn't help explain anything to me. > Here is an example (pardon the ascii art) > \|/ > | wireless interface participating in MANET > [RT1] > | wired interface for attached hosts > ---------------------------- > | | > [host1] [host2] How about this example: [RT1] - H1 - H2 - H3 - H4 (All hosts connected to RT1). What IP addresses are assigned to H1-H4? What subnet prefix (if any) is assigned to the "link" (which is what I imagine the set of RT1 and H1-H4 would be). Can H1 talk to H3 directly without going through RT1 (at the IP layer)? Thomas _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Oct 04 22:18:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVIoF-0005ob-W0; Wed, 04 Oct 2006 22:18:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVIoE-0005kt-ME for autoconf@ietf.org; Wed, 04 Oct 2006 22:18:02 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVIoD-0007NB-4M for autoconf@ietf.org; Wed, 04 Oct 2006 22:18:02 -0400 Received: by ug-out-1314.google.com with SMTP id 72so131404ugd for ; Wed, 04 Oct 2006 19:18:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=G0aKOe/qQT6gfFNNYe1WjA8hd/IJUoGRQPKU+ndyvrBS3NVNWVLzjpSG/7T6mGmFWEnj64YbzxWfJxhPc8KhNet01ddwWfQs5G5z1FP9Opo17Lg+WVDuRcMXncVyaCzEXCjq0ruy9OB/W2AK7amhdDVt9h0k+6xotNu7l64rqk8= Received: by 10.67.100.17 with SMTP id c17mr1323595ugm; Wed, 04 Oct 2006 19:18:00 -0700 (PDT) Received: by 10.66.224.14 with HTTP; Wed, 4 Oct 2006 19:17:59 -0700 (PDT) Message-ID: <374005f30610041917u1781a6e4tf41d66ee82c49e3b@mail.gmail.com> Date: Wed, 4 Oct 2006 19:17:59 -0700 From: "Ian Chakeres" To: "Thomas Narten" Subject: Re: [Autoconf] Re:subnet model In-Reply-To: <200610050129.k951TPGT000493@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30610041320l346c5e4ds6358234815a14090@mail.gmail.com> <200610050129.k951TPGT000493@cichlid.raleigh.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: autoconf@ietf.org, Thomas Clausen 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 A link is defined as: A communications facility at a layer below IP, over which nodes exchange IP packets directly without decrementing IP TTL (Hop Limit). Other comments inline. On 10/4/06, Thomas Narten wrote: > > > 1) What is the scope of an IP "link" or "subnet"? That is, if one has > > > a manet (which consists of many routers and hosts), which hosts are > > > considered (from IP's perspective) to be on the same "link", and > > > thus can communicate directly with each other (without having to > > > forward traffic through a router)? Note that here, I'm using the term "link", and one could > > > assume link-local addressing is in use. > > > When a link local message is transmitted, then all nodes within one IP > > hop receive the message. I don't think MANET imposes any change to > > this definition. > > I don't understand what this means. This is more like an L2 statement > that says "anyone within range gets the packet". > > What I'm asking is, what defines "one subnet hop"? Which nodes are > attached the same link? Which are not? What is the distinction between > those nodes? How does a node know which link it is attached to, since > presumably there are presumably overlapping regions in some cases. Can you please define subnet hop? In MANET, the MANET routers may not know beforehand which other MANET routers are nearby. They will need to learn about nearby MANET routers using link local messaging. > In conventional links, the answer is obvious, because you don't have > overlapping links. One is attached to one link, or another, but you > don't have situations where the link is as ill-defined as "receives > the signal". In comparison, with manets, one presumably has situations > where those in the middle of a radio area can receive packets from all > nodes, whereas those at the edges may not receive packets from those > at the other edge. What is a conventional link? Is it a link that does not exhibit asymmetric reachability? > > > 2) Are there "subnets" in a manet? That is, is there a prefix that > > > covers multiple nodes? that is, where all the nodes on that subnet > > > can reach each other (directly, without going through a router)? Or > > > stated differently, are there subnets where all the nodes on that > > > subnet can be assigned addresses out of the same prefix (and that > > > can reach each other directly)? > > > I would say that in the most general case, a MANET router cannot make > > assumptions about the IP addresses of other MANET routers that are > > reachable using link local communication. That is not to say that a > > MANET router cannot be configured to make this assumption, if it is > > true. Again, I don't think that MANET imposes any change to existing > > definitions in this respect. I elaborate a little more below about > > hosts. > > Again, I don't understand this answer. Is there a notion with manets > that three hosts, say A, B & C are on the same subnet, but node D & E > are on different subnets? This is a very basic concept with IP (i.e., > A, B & C would be on one ethernet, D & E would be on another). Nodes > A, B & C would have addresses on thes same subnet (and on the same > subnet prefix), where D & E would have addresses corresponding to > different subnet prefixes > > Is there a corresponding model with manets? If two nodes will reliably be able to communicate using one IP hop, then they can (and probably should) be configured in the same subnet/prefix. MANET routing protocols support the aggregation of IP addresses using the subnet/prefix concept. I would also like to state that A/B/C & D/E could be on the same Ethernet segment and still configured to be in two different subnets. If the nodes were so configured, their link local communications would reach A/B/C/D/E and they could learn about each other. > > > 3) What type of link does a "host" connect to? Is it essentially just > > > a p2p link between itself and a router? Is a manet nothing more > > > than a set of links, each of which is p2p? > > > I think Joe addressed this question, but I will reiterate it here. A > > router supports attached prefixes. I think that hosts connect to the > > larger network by using a router. > > Again, I don't understand this response (or it doesn't answere what > I'm trying to ask). > > Is a link a point-to-point link (from IP's perspective)? one that can > have exactly to devices attached to it? Or is it something else? In MANET we do not need to add attach any additional criteria to the term link. It is simply a communication facility below IP. We have in general assumed that the MANET WG protocols will often be run over semi-broadcast interfaces, exhibiting both non-transitive and non-reflexive behaviors. We have tailored our routing protocols for this environment. I would say the protocols work equally well in broadcast networks that exhibit both transitive and reflexive behaviors. > Again, I think it might really help to give some actual examples with > (possible) IP addresses and (possible) subnet prefixes/masks. > > > > Consider Figure 1 in chakeres-manet-arch. It only shows routers. I'd > > > like a corresponding figure that also shows hosts, and gives example > > > IP address assignments, and shows where the IP subnets are. > > > If we look at a router, there might be several attached hosts. These > > hosts might possibly be in the same prefix to allow easy aggregation > > and advertisement in the routing protocol. > > Might? Or might not? Again, this sort of vague answer just doesn't > help explain anything to me. > > > Here is an example (pardon the ascii art) > > > \|/ > > | wireless interface participating in MANET > > [RT1] > > | wired interface for attached hosts > > ---------------------------- > > | | > > [host1] [host2] > > How about this example: > > [RT1] - H1 > - H2 > - H3 > - H4 > > (All hosts connected to RT1). > > What IP addresses are assigned to H1-H4? What subnet prefix (if any) > is assigned to the "link" (which is what I imagine the set of RT1 and > H1-H4 would be). Can H1 talk to H3 directly without going through RT1 > (at the IP layer)? Let us assume that RT1 and H[1-4] are attached to the same Ethernet segment. The IP addresses of all the nodes could be configured in the same subnet prefix. Alternatively, each node's interface could be configured in its own subnet prefix. Independent of a node's configured prefix, the node's routing table would determine whether they spoke directly to another node or through the router. In a MANET, MANET routers' semi-broadcast interfaces will likely have IP addresses. In respect to any one MANET router's interface, they will likely assume that only themselves are directly reachable. Unless other nodes are connected and the router is configured with this knowledge. The MANET routers will need to use link local messaging (one IP hop) to learn about other nearby MANET routers. I hope I have addressed your questions. Ian Chakeres _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Oct 04 22:36:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVJ5r-0007pw-Ju; Wed, 04 Oct 2006 22:36:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVJ5q-0007oR-3v for autoconf@ietf.org; Wed, 04 Oct 2006 22:36:14 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVJ5p-0006Za-M4 for autoconf@ietf.org; Wed, 04 Oct 2006 22:36:14 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k952aLHa024865 for ; Wed, 4 Oct 2006 22:36:21 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k952aCm5281076 for ; Wed, 4 Oct 2006 22:36:12 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k952aCxf012364 for ; Wed, 4 Oct 2006 22:36:12 -0400 Received: from cichlid.raleigh.ibm.com (wecm-9-67-103-55.wecm.ibm.com [9.67.103.55]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k952aBbh012340; Wed, 4 Oct 2006 22:36:11 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.7/8.12.5) with ESMTP id k952aGUA021093; Wed, 4 Oct 2006 22:36:20 -0400 Message-Id: <200610050236.k952aGUA021093@cichlid.raleigh.ibm.com> To: "Ian Chakeres" Subject: Re: [Autoconf] Re:subnet model In-reply-to: <374005f30610041917u1781a6e4tf41d66ee82c49e3b@mail.gmail.com> References: <374005f30610041320l346c5e4ds6358234815a14090@mail.gmail.com> <200610050129.k951TPGT000493@cichlid.raleigh.ibm.com> <374005f30610041917u1781a6e4tf41d66ee82c49e3b@mail.gmail.com> Comments: In-reply-to "Ian Chakeres" message dated "Wed, 04 Oct 2006 19:17:59 -0700." Date: Wed, 04 Oct 2006 22:36:16 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: autoconf@ietf.org, Thomas Clausen 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 > A link is defined as: > A communications facility at a layer below IP, over which nodes > exchange IP packets directly without decrementing IP TTL (Hop > Limit). This is a somewhat funny definition, IMO. If such nodes can exchange packets "directly" at L2, by defintion the IP TTL would not be decremented. The IP TTL gets decremented only if a packet is forwarded/processed at the IP layer. Is this then just the standard definition of a link as is commonly used in both IPv4 and IPv6? E.g., from 2460: link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6. Examples are Ethernets (simple or bridged); PPP links; X.25, Frame Relay, or ATM networks; and internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. Note, in the above context, it is assumed that "at the link layer" means an IP packet will be delivered unmodified, i.e., without decrementing the IP TTL. > Other comments inline. > On 10/4/06, Thomas Narten wrote: > > > > 1) What is the scope of an IP "link" or "subnet"? That is, if one has > > > > a manet (which consists of many routers and hosts), which hosts are > > > > considered (from IP's perspective) to be on the same "link", and > > > > thus can communicate directly with each other (without having to > > > > forward traffic through a router)? Note that here, I'm using the term "link", and one could > > > > assume link-local addressing is in use. > > > > > When a link local message is transmitted, then all nodes within one IP > > > hop receive the message. I don't think MANET imposes any change to > > > this definition. > > > > I don't understand what this means. This is more like an L2 statement > > that says "anyone within range gets the packet". > > > > What I'm asking is, what defines "one subnet hop"? Which nodes are > > attached the same link? Which are not? What is the distinction between > > those nodes? How does a node know which link it is attached to, since > > presumably there are presumably overlapping regions in some cases. > Can you please define subnet hop? The set of nodes that are all connected to the same link, and can each send directly to each other. By analogy, this is a typical L2 link over which an IP "subnet" is configured (e.g., an ethernet). > In MANET, the MANET routers may not know beforehand which other MANET > routers are nearby. They will need to learn about nearby MANET routers > using link local messaging. You keep dragging in "other manet routers". I'd like to understand what a single "link" or "subnet" is, without dragging in other routers that (presumbly) are (at least in many cases) on other links. Or, the set of nodes and manet routers that can all send packets directly to each other. > > In conventional links, the answer is obvious, because you don't have > > overlapping links. One is attached to one link, or another, but you > > don't have situations where the link is as ill-defined as "receives > > the signal". In comparison, with manets, one presumably has situations > > where those in the middle of a radio area can receive packets from all > > nodes, whereas those at the edges may not receive packets from those > > at the other edge. > What is a conventional link? Is it a link that does not exhibit > asymmetric reachability? Yes. All links on which IP runs today are always reachable in both directions. When that isn't the case, IP doesn't run normally. > > > > 2) Are there "subnets" in a manet? That is, is there a prefix that > > > > covers multiple nodes? that is, where all the nodes on that subnet > > > > can reach each other (directly, without going through a router)? Or > > > > stated differently, are there subnets where all the nodes on that > > > > subnet can be assigned addresses out of the same prefix (and that > > > > can reach each other directly)? > > > > > I would say that in the most general case, a MANET router cannot make > > > assumptions about the IP addresses of other MANET routers that are > > > reachable using link local communication. That is not to say that a > > > MANET router cannot be configured to make this assumption, if it is > > > true. Again, I don't think that MANET imposes any change to existing > > > definitions in this respect. I elaborate a little more below about > > > hosts. > > > > Again, I don't understand this answer. Is there a notion with manets > > that three hosts, say A, B & C are on the same subnet, but node D & E > > are on different subnets? This is a very basic concept with IP (i.e., > > A, B & C would be on one ethernet, D & E would be on another). Nodes > > A, B & C would have addresses on thes same subnet (and on the same > > subnet prefix), where D & E would have addresses corresponding to > > different subnet prefixes > > > > Is there a corresponding model with manets? > If two nodes will reliably be able to communicate using one IP hop, > then they can (and probably should) be configured in the same > subnet/prefix. OK. so manets do have the notion of subnets, as is commonly assumed in IP. > MANET routing protocols support the aggregation of IP addresses using > the subnet/prefix concept. I don't want to hear about manet routing protocols. We should be able to talk about the subnet model/architecture without getting into specific manet routing protocols. > I would also like to state that A/B/C & D/E could be on the same > Ethernet segment and still configured to be in two different > subnets. If the nodes were so configured, their link local > communications would reach A/B/C/D/E and they could learn about each > other. yes, but let's keep it simple for now because in practice, if they were on different L2 links as I originally described, they would be configured as above. in other words, don't make the picture more complicated when we seem to be having such a disconnect on even the most basic concepts! > > > > 3) What type of link does a "host" connect to? Is it essentially just > > > > a p2p link between itself and a router? Is a manet nothing more > > > > than a set of links, each of which is p2p? > > > > > I think Joe addressed this question, but I will reiterate it here. A > > > router supports attached prefixes. I think that hosts connect to the > > > larger network by using a router. > > > > Again, I don't understand this response (or it doesn't answere what > > I'm trying to ask). > > > > Is a link a point-to-point link (from IP's perspective)? one that can > > have exactly to devices attached to it? Or is it something else? > In MANET we do not need to add attach any additional criteria to the > term link. It is simply a communication facility below IP. > We have in general assumed that the MANET WG protocols will often be > run over semi-broadcast interfaces, exhibiting both non-transitive and > non-reflexive behaviors. We have tailored our routing protocols for > this environment. I would say the protocols work equally well in > broadcast networks that exhibit both transitive and reflexive > behaviors. Again, don't talk about routing protocols. If you have asymetric "interfaces", what is the subnet model? going back to the A/B/C/RT1 example, if A can't reach B directly, can they be on the same IP subnet? And how do packets get from A to B? Via RT1? and is this visible to IP (e.g., by decrementing a TTL)? > > Again, I think it might really help to give some actual examples with > > (possible) IP addresses and (possible) subnet prefixes/masks. > > > > > > Consider Figure 1 in chakeres-manet-arch. It only shows routers. I'd > > > > like a corresponding figure that also shows hosts, and gives example > > > > IP address assignments, and shows where the IP subnets are. > > > > > If we look at a router, there might be several attached hosts. These > > > hosts might possibly be in the same prefix to allow easy aggregation > > > and advertisement in the routing protocol. > > > > Might? Or might not? Again, this sort of vague answer just doesn't > > help explain anything to me. > > > > > Here is an example (pardon the ascii art) > > > > > \|/ > > > | wireless interface participating in MANET > > > [RT1] > > > | wired interface for attached hosts > > > ---------------------------- > > > | | > > > [host1] [host2] > > > > How about this example: > > > > [RT1] - H1 > > - H2 > > - H3 > > - H4 > > > > (All hosts connected to RT1). > > > > What IP addresses are assigned to H1-H4? What subnet prefix (if any) > > is assigned to the "link" (which is what I imagine the set of RT1 and > > H1-H4 would be). Can H1 talk to H3 directly without going through RT1 > > (at the IP layer)? > Let us assume that RT1 and H[1-4] are attached to the same Ethernet > segment. Argh!!!! I think we all know about ethernets (and conventional links). Assume the above is a manet. How would the addresses and subnet prefixes be configured? Exactly the same way? Thomas _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Oct 04 23:10:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVJdN-0007pL-TH; Wed, 04 Oct 2006 23:10:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVJdM-0007nj-DZ for autoconf@ietf.org; Wed, 04 Oct 2006 23:10:52 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVJdL-0006yP-PT for autoconf@ietf.org; Wed, 04 Oct 2006 23:10:52 -0400 Received: by ug-out-1314.google.com with SMTP id 72so134014ugd for ; Wed, 04 Oct 2006 20:10:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Kd/pPrdj6uGjZPvfa3vPYfF9qnv69b7BKTsTImjOUn2+Li6eTVM7ePVf6FlXVp2RuUfNI+A0NFLSSMfH0S+HNMwRf10EP0k7ThXb9GDwzxtQTiDOtvXh6GEabSGWor1WTTXdt2IvK5uaUZCwtbVGFNVS04NN73nlo/J8zmKMEDs= Received: by 10.66.220.17 with SMTP id s17mr1353678ugg; Wed, 04 Oct 2006 20:10:50 -0700 (PDT) Received: by 10.66.224.14 with HTTP; Wed, 4 Oct 2006 20:10:49 -0700 (PDT) Message-ID: <374005f30610042010u5397995cm75eca51b0da03eb3@mail.gmail.com> Date: Wed, 4 Oct 2006 20:10:49 -0700 From: "Ian Chakeres" To: "Thomas Narten" Subject: Re: [Autoconf] Re:subnet model In-Reply-To: <200610050236.k952aGUA021093@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30610041320l346c5e4ds6358234815a14090@mail.gmail.com> <200610050129.k951TPGT000493@cichlid.raleigh.ibm.com> <374005f30610041917u1781a6e4tf41d66ee82c49e3b@mail.gmail.com> <200610050236.k952aGUA021093@cichlid.raleigh.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: autoconf@ietf.org, Thomas Clausen 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 Comments inline. On 10/4/06, Thomas Narten wrote: > > A link is defined as: > > A communications facility at a layer below IP, over which nodes > > exchange IP packets directly without decrementing IP TTL (Hop > > Limit). > > This is a somewhat funny definition, IMO. If such nodes can exchange > packets "directly" at L2, by defintion the IP TTL would not be > decremented. The IP TTL gets decremented only if a packet is > forwarded/processed at the IP layer. > > Is this then just the standard definition of a link as is commonly > used in both IPv4 and IPv6? E.g., from 2460: > > link - a communication facility or medium over which nodes can > communicate at the link layer, i.e., the layer > immediately below IPv6. Examples are Ethernets (simple > or bridged); PPP links; X.25, Frame Relay, or ATM > networks; and internet (or higher) layer "tunnels", > such as tunnels over IPv4 or IPv6 itself. > > Note, in the above context, it is assumed that "at the link layer" > means an IP packet will be delivered unmodified, i.e., without > decrementing the IP TTL. Sounds good. Yes, the standard terminology applies. > > Other comments inline. > > > On 10/4/06, Thomas Narten wrote: > > > > > 1) What is the scope of an IP "link" or "subnet"? That is, if one has > > > > > a manet (which consists of many routers and hosts), which hosts are > > > > > considered (from IP's perspective) to be on the same "link", and > > > > > thus can communicate directly with each other (without having to > > > > > forward traffic through a router)? Note that here, I'm using the term "link", and one could > > > > > assume link-local addressing is in use. > > > > > > > When a link local message is transmitted, then all nodes within one IP > > > > hop receive the message. I don't think MANET imposes any change to > > > > this definition. > > > > > > I don't understand what this means. This is more like an L2 statement > > > that says "anyone within range gets the packet". > > > > > > What I'm asking is, what defines "one subnet hop"? Which nodes are > > > attached the same link? Which are not? What is the distinction between > > > those nodes? How does a node know which link it is attached to, since > > > presumably there are presumably overlapping regions in some cases. > > > Can you please define subnet hop? > > The set of nodes that are all connected to the same link, and can each > send directly to each other. By analogy, this is a typical L2 link > over which an IP "subnet" is configured (e.g., an ethernet). I would say that a subnet is a configured option/concept and not inherent to a link. Perhaps this is where the misunderstanding lies. A subnet and a "communication" link are not the same. This is the reason I discussed the case where A/B/C/D/E are on the same link yet the nodes might be configured in different subnets. > > In MANET, the MANET routers may not know beforehand which other MANET > > routers are nearby. They will need to learn about nearby MANET routers > > using link local messaging. > > You keep dragging in "other manet routers". I'd like to understand > what a single "link" or "subnet" is, without dragging in other routers > that (presumbly) are (at least in many cases) on other links. > > Or, the set of nodes and manet routers that can all send packets > directly to each other. > > > > In conventional links, the answer is obvious, because you don't have > > > overlapping links. One is attached to one link, or another, but you > > > don't have situations where the link is as ill-defined as "receives > > > the signal". In comparison, with manets, one presumably has situations > > > where those in the middle of a radio area can receive packets from all > > > nodes, whereas those at the edges may not receive packets from those > > > at the other edge. > > > What is a conventional link? Is it a link that does not exhibit > > asymmetric reachability? > > Yes. All links on which IP runs today are always reachable in both > directions. When that isn't the case, IP doesn't run normally. Note: This discussion is a bit off topic. I would say that IP runs normally even on unidirectional links (e.g. satellite). In many cases, reachablity through via multiple hops (routing) is sufficient. I admit that certain IP protocols do not work well over this type of communication link. > > > > > 2) Are there "subnets" in a manet? That is, is there a prefix that > > > > > covers multiple nodes? that is, where all the nodes on that subnet > > > > > can reach each other (directly, without going through a router)? Or > > > > > stated differently, are there subnets where all the nodes on that > > > > > subnet can be assigned addresses out of the same prefix (and that > > > > > can reach each other directly)? > > > > > > > I would say that in the most general case, a MANET router cannot make > > > > assumptions about the IP addresses of other MANET routers that are > > > > reachable using link local communication. That is not to say that a > > > > MANET router cannot be configured to make this assumption, if it is > > > > true. Again, I don't think that MANET imposes any change to existing > > > > definitions in this respect. I elaborate a little more below about > > > > hosts. > > > > > > Again, I don't understand this answer. Is there a notion with manets > > > that three hosts, say A, B & C are on the same subnet, but node D & E > > > are on different subnets? This is a very basic concept with IP (i.e., > > > A, B & C would be on one ethernet, D & E would be on another). Nodes > > > A, B & C would have addresses on thes same subnet (and on the same > > > subnet prefix), where D & E would have addresses corresponding to > > > different subnet prefixes > > > > > > Is there a corresponding model with manets? > > > If two nodes will reliably be able to communicate using one IP hop, > > then they can (and probably should) be configured in the same > > subnet/prefix. > > OK. so manets do have the notion of subnets, as is commonly assumed in > IP. > > > MANET routing protocols support the aggregation of IP addresses using > > the subnet/prefix concept. > > I don't want to hear about manet routing protocols. We should be able > to talk about the subnet model/architecture without getting into > specific manet routing protocols. > > > I would also like to state that A/B/C & D/E could be on the same > > Ethernet segment and still configured to be in two different > > subnets. If the nodes were so configured, their link local > > communications would reach A/B/C/D/E and they could learn about each > > other. > > yes, but let's keep it simple for now because in practice, if they > were on different L2 links as I originally described, they would be > configured as above. > > in other words, don't make the picture more complicated when we seem > to be having such a disconnect on even the most basic concepts! > > > > > > 3) What type of link does a "host" connect to? Is it essentially just > > > > > a p2p link between itself and a router? Is a manet nothing more > > > > > than a set of links, each of which is p2p? > > > > > > > I think Joe addressed this question, but I will reiterate it here. A > > > > router supports attached prefixes. I think that hosts connect to the > > > > larger network by using a router. > > > > > > Again, I don't understand this response (or it doesn't answere what > > > I'm trying to ask). > > > > > > Is a link a point-to-point link (from IP's perspective)? one that can > > > have exactly to devices attached to it? Or is it something else? > > > In MANET we do not need to add attach any additional criteria to the > > term link. It is simply a communication facility below IP. > > > We have in general assumed that the MANET WG protocols will often be > > run over semi-broadcast interfaces, exhibiting both non-transitive and > > non-reflexive behaviors. We have tailored our routing protocols for > > this environment. I would say the protocols work equally well in > > broadcast networks that exhibit both transitive and reflexive > > behaviors. > > Again, don't talk about routing protocols. If you have asymetric > "interfaces", what is the subnet model? going back to the A/B/C/RT1 > example, if A can't reach B directly, can they be on the same IP > subnet? And how do packets get from A to B? Via RT1? and is this > visible to IP (e.g., by decrementing a TTL)? I think that if two nodes cannot communicate directly, they should not be configured to believe they can. That is to say, they should not be configured to believe they are in same subnet. > > > Again, I think it might really help to give some actual examples with > > > (possible) IP addresses and (possible) subnet prefixes/masks. > > > > > > > > Consider Figure 1 in chakeres-manet-arch. It only shows routers. I'd > > > > > like a corresponding figure that also shows hosts, and gives example > > > > > IP address assignments, and shows where the IP subnets are. > > > > > > > If we look at a router, there might be several attached hosts. These > > > > hosts might possibly be in the same prefix to allow easy aggregation > > > > and advertisement in the routing protocol. > > > > > > Might? Or might not? Again, this sort of vague answer just doesn't > > > help explain anything to me. > > > > > > > Here is an example (pardon the ascii art) > > > > > > > \|/ > > > > | wireless interface participating in MANET > > > > [RT1] > > > > | wired interface for attached hosts > > > > ---------------------------- > > > > | | > > > > [host1] [host2] > > > > > > How about this example: > > > > > > [RT1] - H1 > > > - H2 > > > - H3 > > > - H4 > > > > > > (All hosts connected to RT1). > > > > > > What IP addresses are assigned to H1-H4? What subnet prefix (if any) > > > is assigned to the "link" (which is what I imagine the set of RT1 and > > > H1-H4 would be). Can H1 talk to H3 directly without going through RT1 > > > (at the IP layer)? > > > Let us assume that RT1 and H[1-4] are attached to the same Ethernet > > segment. > > Argh!!!! I think we all know about ethernets (and conventional links). > > Assume the above is a manet. How would the addresses and subnet > prefixes be configured? Exactly the same way? The above is not representative of a MANET. That said, the IP address allocation and configuration of hosts behind a MANET router is no different from existing router/host interactions. Ian Chakeres _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Oct 05 06:05:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVQ6N-0004I7-CC; Thu, 05 Oct 2006 06:05:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVQ6K-0004G5-TW for autoconf@ietf.org; Thu, 05 Oct 2006 06:05:12 -0400 Received: from balu1.urz.unibas.ch ([131.152.1.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVQ13-0005Ta-By for autoconf@ietf.org; Thu, 05 Oct 2006 05:59:46 -0400 Received: from [131.152.55.200] (baobab.cs.unibas.ch [131.152.55.200]) by balu1.urz.unibas.ch (8.13.7/8.13.7) with ESMTP id k959xfr5001287 for ; Thu, 5 Oct 2006 11:59:42 +0200 Message-ID: <4524D7C5.9080409@unibas.ch> Date: Thu, 05 Oct 2006 12:00:37 +0200 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: autoconf@ietf.org References: <374005f30610041320l346c5e4ds6358234815a14090@mail.gmail.com> <200610050129.k951TPGT000493@cichlid.raleigh.ibm.com> <374005f30610041917u1781a6e4tf41d66ee82c49e3b@mail.gmail.com> <200610050236.k952aGUA021093@cichlid.raleigh.ibm.com> In-Reply-To: <200610050236.k952aGUA021093@cichlid.raleigh.ibm.com> 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: 00e94c813bef7832af255170dca19e36 Subject: [Autoconf] Subnet model 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 all, [sorry for the long email] I think the current discussion is interesting but it embraces too many things that have little to do with IP subneting. I agree with Thomas N. that things like link properties, routing protocol details, and connectivity dynamics are out of scope wrt defining what is or what is not a MANET subnet. Subnetting relates to addressing and routing aggregation: whatever techniques are used to allocate addresses and prefixes and setup (aggregated) routing entries is an implementation issue (yet not always an easy one). For example for say IPv6, if one wants a MANET model without subnet then all routers and hosts are configured with a /128 and routing is flat. How addresses are assigned (to both routers and hosts), how routing is established (reactive or proactive), and how links "operate" does not change the model: it's flat, and all routing entries are /128. Now if the model is that each MANET router "is" a subnet that comprises itself and hosts attached to it, we can specify e.g. that a MR gets a /64, and routing between MRs is based on /64 routing entries. Hosts attached to a MR get an address from the MR's /64. Now again how this is achieved does not change the model. For example, "routing" between hosts that share a /64 (all attached to the same MR) can be direct (hosts are neighbors) or via the MR. Now if one wants to aggregate more, one can specify the target goal (e.g. all MRs share a given prefix, say a /48), define how routing is performed between MRs (maybe still with /64s), and then write protocols that can do this in one way or another: again what matters is the model, not how you implement it. I think the whole discussion is biased because there is no common agreement about the objectives of MANET autoconfiguration. In the Internet, addresses are administratively assigned to RIRs, LIRs, etc and a subnet is something that has administrative boundaries. A human user assigns prefixes, and autoconfiguration only takes place for hosts (via DHCP or SAA). One can see a subnet as the entity that "owns" a given address space, as my university owns a /48 and the CS department owns a few /64s. This is actually merely done for IP routing to scale, and to avoid 2 sites from using the same addresses. It's all about how the Internet is topologically organized. Now how does this relate to MANETs? First a MANET is made of routers, so we do router autoconfiguration and possibly host autoconfiguration (for hosts attached to MRs). Second and more importantly, MANET routers do not necessarily belong to an administrative authority and this is a big difference compared to the Internet. Also a MANET is not always connected to the Internet, so we don't always have to follow existing rules. To me this is the kind of discussions that should appear in the MANET-arch document. One could then extract scenarios that will be considered by the WG. I see 4 of them: - flat: all nodes have /128, routing entries are /128. An MR has to take care of routing for hosts attached to it, and hosts have a default route pointing to the MR they are attached to - semi-flat: all routers own a /64, they delegate /128 to hosts attached to them, routing entries in routers are /64, hosts have a default route pointing to the MR they are attached to - coherent: all MRs share a given prefix. For example for an Internet-connected MANET this could an Internet routeable /48, and for an isolated MANET this could a reserved prefix by IANA for MANETs (e.g. MANET-local prefix). - clustered: some (topologically close) MRs share a given prefix, and routing entries to this cluster may be aggregated. Example is a MANET with multiple gateways to the Internet or a very large isolated MANET that need routing aggregation for scalability reasons. I think that MANET-arch-00 would have been a very good document for the MANET WG when it started, but I currently don't see how it fits into the AUTOCONF framework. best regards, Christophe _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Oct 05 09:56:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVThp-0006wf-PU; Thu, 05 Oct 2006 09:56:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVThn-0006uh-PL for autoconf@ietf.org; Thu, 05 Oct 2006 09:56:07 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVThm-0004ko-71 for autoconf@ietf.org; Thu, 05 Oct 2006 09:56:07 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k95Du5T8008569 for ; Thu, 5 Oct 2006 09:56:05 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k95Du4uv257646 for ; Thu, 5 Oct 2006 09:56:05 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k95Du4bU017923 for ; Thu, 5 Oct 2006 09:56:04 -0400 Received: from cichlid.raleigh.ibm.com (wecm-9-67-103-55.wecm.ibm.com [9.67.103.55]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k95Du3Fl017665; Thu, 5 Oct 2006 09:56:04 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.7/8.12.5) with ESMTP id k95Du5ij004113; Thu, 5 Oct 2006 09:56:11 -0400 Message-Id: <200610051356.k95Du5ij004113@cichlid.raleigh.ibm.com> To: Christophe Jelger Subject: Re: [Autoconf] Subnet model In-reply-to: <4524D7C5.9080409@unibas.ch> References: <374005f30610041320l346c5e4ds6358234815a14090@mail.gmail.com> <200610050129.k951TPGT000493@cichlid.raleigh.ibm.com> <374005f30610041917u1781a6e4tf41d66ee82c49e3b@mail.gmail.com> <200610050236.k952aGUA021093@cichlid.raleigh.ibm.com> <4524D7C5.9080409@unibas.ch> Comments: In-reply-to Christophe Jelger message dated "Thu, 05 Oct 2006 12:00:37 +0200." Date: Thu, 05 Oct 2006 09:56:05 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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: , Errors-To: autoconf-bounces@ietf.org Thank you Christophe. I agree with pretty much everything you say. Christophe Jelger writes: > I think the whole discussion is biased because there is no common > agreement about the objectives of MANET autoconfiguration. Well, that is what I'm trying to understand. And if people can't explain it, or write it down in a document (even if this is only 2 pages), then we (this WG and the IETF) do not have agreement, and the obvious implication is that none of the work being worked on in this space is going to go anywhere. Thus, attempts to brush these questions off as unimportant or trivial (rather than actually answering them) while preferring to work on solutions is (IMO) a doomed strategy. I assume the real goal is to get documents out that can be approved by the broader community and IESG! > Now how does this relate to MANETs? First a MANET is made of > routers, And indeed, one question I have is "are all nodes routers?" Who decides whether one wants to be just a host or a router? And how does that change things? (I assume there will be dumb hosts that don't want to be routers -- is that a shared assumption?) > so we do router autoconfiguration and possibly host > autoconfiguration (for hosts attached to MRs). Second and more > importantly, MANET routers do not necessarily belong to an > administrative authority and this is a big difference compared to > the Internet. Yes, but I wonder if this too is a distraction. Whether a manet is connected to the Public internet or not, doesn't seem (to me) to have any impact on its subnet model. The only impact would be what addresses the nodes have (publically routable vs. private/site local). Indeed, another question that comes to my mind is, how does the autoconf problem in manets compare/relate to the zrouter (zero config router) BOFs that were held at one point, where the goal was to autoconfigure the subnets within an autonomous area. How is the work here similar, and how does it differ? > Also a MANET is not always connected to the Internet, so we don't > always have to follow existing rules. But there presumably still needs to be some basic assumptions about what a subnet is, how the addresses on a subnet relate to each other, etc., regadless of whether the manet is connected to the internet. > To me this is the kind of discussions that should appear in the > MANET-arch document. One could then extract scenarios that will be > considered by the WG. I see 4 of them: > - flat: all nodes have /128, routing entries are /128. An MR has to take > care of routing for hosts attached to it, and hosts have a default route > pointing to the MR they are attached to > - semi-flat: all routers own a /64, they delegate /128 to hosts attached > to them, routing entries in routers are /64, hosts have a default route > pointing to the MR they are attached to > - coherent: all MRs share a given prefix. For example for an > Internet-connected MANET this could an Internet routeable /48, and for > an isolated MANET this could a reserved prefix by IANA for MANETs (e.g. > MANET-local prefix). > - clustered: some (topologically close) MRs share a given prefix, and > routing entries to this cluster may be aggregated. Example is a MANET > with multiple gateways to the Internet or a very large isolated MANET > that need routing aggregation for scalability reasons. Yep, the above are the kinds of questions I have. Just what is being proposed? (and answering "any and all of them" is not the answer I'm looking for!) Thomas _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Oct 05 10:28:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUDG-0004E8-8F; Thu, 05 Oct 2006 10:28:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUDE-0004E1-Ud for autoconf@ietf.org; Thu, 05 Oct 2006 10:28:36 -0400 Received: from balu1.urz.unibas.ch ([131.152.1.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVUDA-000503-Ex for autoconf@ietf.org; Thu, 05 Oct 2006 10:28:36 -0400 Received: from [131.152.55.200] (baobab.cs.unibas.ch [131.152.55.200]) by balu1.urz.unibas.ch (8.13.7/8.13.7) with ESMTP id k95ESV64022822 for ; Thu, 5 Oct 2006 16:28:31 +0200 Message-ID: <452516C7.80106@unibas.ch> Date: Thu, 05 Oct 2006 16:29:27 +0200 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: autoconf@ietf.org References: <442A7F16.1070801@ac.upc.edu> <4431281B.3090504@unibas.ch> In-Reply-To: <4431281B.3090504@unibas.ch> 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: cf4fa59384e76e63313391b70cd0dd25 Subject: [Autoconf] Manet local addresses: updated draft 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 Dear all, I just updated my Internet Draft on MANET Local IPv6 Addresses (MLAs) as it was about to expire. It is available here (and normally soon on ietf web site): http://cn.cs.unibas.ch/people/cj/draft-jelger-autoconf-mla-01.txt I included some comments I got from Fred Templin and Joe Macker, and I also extended it to include the case where non-router hosts are attached to MANET routers and one wants these hosts to autoconfigure a MLA. Comments are of course welcome. best regards, Christophe _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Oct 05 12:52:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVWST-00035j-EG; Thu, 05 Oct 2006 12:52:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVWQu-0002TW-So for autoconf@ietf.org; Thu, 05 Oct 2006 12:50:52 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVWHe-0005Ch-H8 for autoconf@ietf.org; Thu, 05 Oct 2006 12:41:19 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id k95Gf8jw027022; Thu, 5 Oct 2006 12:41:13 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2006100512420026805 ; Thu, 05 Oct 2006 12:42:00 -0400 From: "Joe Macker" To: "'Thomas Narten'" , "'Christophe Jelger'" Subject: RE: [Autoconf] Subnet model Date: Thu, 5 Oct 2006 12:41:11 -0400 Message-ID: <01f001c6e89d$1081a840$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.2962 In-Reply-To: <200610051356.k95Du5ij004113@cichlid.raleigh.ibm.com> Thread-Index: AcbohjsDyVEamtkwQtapv7aU/6jV8gACmZgQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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: , Errors-To: autoconf-bounces@ietf.org Thomas/All: Just some thoughts here. Hopefully they add to the discussion. Regarding the router/host question that keeps coming up. I think we really are talking about configuring routers and associated prefixes (for networks behind the routers) if we do our job right. It would be good to review any related zrouter issues but I believe there are more than zero configuration issues as well. Also, we sometimes in MANET routing designs have modes were a node is not actively forwarding (for policy or energy reasons) but is running a MANET routing code. I view these nodes as routers or MRs since they can become active L3 forwarders dynamically. Attached hosts and prefixes behind the router are just that IMO as with the normal IP model (e.g., vehicular LANS,etc). I do believe multiple deployment models have been envisioned to manage addressing and interconnection for MANET routing in particular ways. In particular, I have a working MANET testbed running two very different addressing approach. Just as for host configuration this may lead to alternate solutions that are valid and solve different scenarios (e.g., zrouter type vs more stateful DHCP with relay agents,etc). We need to discuss scenarios to understand this better. Does the group want to define both of those types ? .. perhaps not but the discussion should happen. The fixed Internet has both types and they are both valid. Even hybrid stateful/stateless autoconf can make sense as we see with IPv6. These are just examples but the rationale would be driven by deployment scenarios as you suggest. I think we can discuss that. > Yes. All links on which IP runs today are always reachable in both > directions. When that isn't the case, IP doesn't run normally. Also on this point, even without MANET, IP is running on wireless links everyday all over the world (e.g., 802.11) that are ONLY Temporally not Always bidirectional. I certainly have better antennas at my access point in my house than in my portable devices and there are lost link packets in both directions for various environmental reasons and its not as simple as an out-of-range issue. Rather than always, I would say we need some statistically significant reachability in both directions for many protocols in the IP stack to run normally and this varies dependent upon the protocol design assumptions and transport layer. Certainly with mobile routers we are attempting to improve this situation by defining neighbor bidirectionality testing and status maintenance for IP prior to declaring a valid useable link. We could or course borrow L2 bidirectional neighbor status if that information is available. -Joe >-----Original Message----- >From: Thomas Narten [mailto:narten@us.ibm.com] >Sent: Thursday, October 05, 2006 9:56 AM >To: Christophe Jelger >Cc: autoconf@ietf.org >Subject: Re: [Autoconf] Subnet model > >Thank you Christophe. I agree with pretty much everything you say. > >Christophe Jelger writes: > >> I think the whole discussion is biased because there is no common >> agreement about the objectives of MANET autoconfiguration. > >Well, that is what I'm trying to understand. And if people >can't explain it, or write it down in a document (even if this >is only 2 pages), then we (this WG and the IETF) do not have >agreement, and the obvious implication is that none of the >work being worked on in this space is going to go anywhere. >Thus, attempts to brush these questions off as unimportant or >trivial (rather than actually answering them) while preferring >to work on solutions is (IMO) a doomed strategy. I assume the >real goal is to get documents out that can be approved by the >broader community and IESG! > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Oct 05 15:20:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVYlL-0007Mo-93; Thu, 05 Oct 2006 15:20:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVYlJ-0007Mi-Sm for autoconf@ietf.org; Thu, 05 Oct 2006 15:20:05 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVYlI-0005a5-Di for autoconf@ietf.org; Thu, 05 Oct 2006 15:20:05 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k95JK0QY020372; Thu, 5 Oct 2006 22:20:03 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 22:19:34 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 14:19:29 -0500 Received: from [172.18.141.113] ([172.18.141.113]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 14:19:29 -0500 Message-ID: <45255AA2.9010304@nokia.com> Date: Thu, 05 Oct 2006 12:18:58 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ext Thomas Narten Subject: Re: [Autoconf] Re:subnet model References: <374005f30610041320l346c5e4ds6358234815a14090@mail.gmail.com> <200610050129.k951TPGT000493@cichlid.raleigh.ibm.com> <374005f30610041917u1781a6e4tf41d66ee82c49e3b@mail.gmail.com> <200610050236.k952aGUA021093@cichlid.raleigh.ibm.com> In-Reply-To: <200610050236.k952aGUA021093@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 19:19:29.0160 (UTC) FILETIME=[2DC96080:01C6E8B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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: , Errors-To: autoconf-bounces@ietf.org Hello Thomas, It is important to allow a manet that consists of a lot of point-to-point links without enforcing subnet definitions on those links. The endpoints of these communication links are called neighbors, and neighbors do not have to share a common subnet prefix for their IP addresses. This behavior is pretty much the same as with Mobile IP. Suppose that a mobile node encounters a foreign agent and sets up communication using the care-of address offered by the foreign agent (i.e., not using a co-located care-of address). The node can register by way of that foreign agent, and communicate with the foreign agent, even though the mobile node and the foreign agent do not have a common subnet prefix. The addresses of the mobile node and the foreign agent are not on the same subnet, but the two nodes clearly have an established communication link. That communication link is important for the IP communication between the two nodes -- just as the communication link between any two manet nodes is important for them to communicate. A few comments inline. ext Thomas Narten wrote: > >> If two nodes will reliably be able to communicate using one IP hop, >> then they can (and probably should) be configured in the same >> subnet/prefix. >> I do not agree with this. > > OK. so manets do have the notion of subnets, as is commonly assumed in > IP. > > I also do not agree that manets necessarily have a notion of subnets. > > I don't want to hear about manet routing protocols. We should be able > to talk about the subnet model/architecture without getting into > specific manet routing protocols. > That is true, but on the other hand we should be able to talk about manet routing protocols and address autoconfiguration in situations where there are not any subnets (except perhaps for the trivial subnet consisting of just one node). > > >> In MANET we do not need to add attach any additional criteria to the >> term link. It is simply a communication facility below IP. >> Check! Regards, Charlie P. -- Please address return e-mail to charles.perkins@nokia.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Oct 06 14:21:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVuJn-0000Qm-OF; Fri, 06 Oct 2006 14:21:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVuJm-0000QW-Jk for autoconf@ietf.org; Fri, 06 Oct 2006 14:21:06 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVuJl-00063y-8c for autoconf@ietf.org; Fri, 06 Oct 2006 14:21:06 -0400 Received: by ug-out-1314.google.com with SMTP id 72so341740ugd for ; Fri, 06 Oct 2006 11:21:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nH51tr2dpP+CqcDTAjp5ZEYaWm/JSZfUZ1tFjJpZpBd2VsxYeAERWPW3TR5gJHnNjLccUjJsAS082vIxzCwU2EKUAqiTaJOW+F+1yT9ivdsdgRAkgYox4ui9xtF8nEyrJXLaySQCoogS5rYnlF+G52aWTwA83/Ua+offRkWOClY= Received: by 10.66.240.12 with SMTP id n12mr3555210ugh; Fri, 06 Oct 2006 11:21:03 -0700 (PDT) Received: by 10.66.255.17 with HTTP; Fri, 6 Oct 2006 11:21:03 -0700 (PDT) Message-ID: <374005f30610061121s1ce9e956o3fa7698acebcd729@mail.gmail.com> Date: Fri, 6 Oct 2006 11:21:03 -0700 From: "Ian Chakeres" To: autoconf@ietf.org, manet In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Subject: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-arch-01.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: , Errors-To: autoconf-bounces@ietf.org I'd like to announce the arch-01 document. Please review it, send me comments, and bring discussion to the mailing list. Thanks. Ian Chakeres ---------- Forwarded message ---------- From: Internet-Drafts@ietf.org Date: Oct 5, 2006 12:50 PM Subject: I-D ACTION:draft-chakeres-manet-arch-01.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobile Ad hoc Network Architecture Author(s) : I. Chakeres, et al. Filename : draft-chakeres-manet-arch-01.txt Pages : 17 Date : 2006-10-5 This document discusses Mobile Ad hoc NETworks (MANETs). It introduces basic MANET terms, characteristics, and challenges. This document also defines several MANET entities and architectural concepts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chakeres-manet-arch-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-chakeres-manet-arch-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-chakeres-manet-arch-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Oct 06 20:53:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW0RO-0008R5-8d; Fri, 06 Oct 2006 20:53:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW0RM-0008OV-9I for autoconf@ietf.org; Fri, 06 Oct 2006 20:53:20 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GW0RI-0002s7-TD for autoconf@ietf.org; Fri, 06 Oct 2006 20:53:20 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k970r4C8013156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 6 Oct 2006 19:53:10 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k970r4PH022875 for ; Fri, 6 Oct 2006 17:53:04 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k970r3Ie022859 for ; Fri, 6 Oct 2006 17:53:04 -0700 (PDT) Received: from XCH-NW-5V2.nw.nos.boeing.com ([130.247.55.45]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 17:53:04 -0700 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: FW: [Autoconf] Subnet model Date: Fri, 6 Oct 2006 17:53:02 -0700 Message-ID: <8BA40F9A33179E4E877E37D7D5E9D82D01EC9E1A@XCH-NW-5V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Subnet model Thread-Index: AcbohiCVO2/nijtVQ4ekCsNpBtLwpwBIbf7Q From: "Yi, Seung" To: X-OriginalArrivalTime: 07 Oct 2006 00:53:04.0186 (UTC) FILETIME=[F215B9A0:01C6E9AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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, all, It seems I'm a bit late to the discussion. Let me put my two cents in, though. Comments inline.=20 > > Now how does this relate to MANETs? First a MANET is made of routers, >=20 > And indeed, one question I have is "are all nodes routers?"=20 > Who decides whether one wants to be just a host or a router?=20 > And how does that change things? (I assume there will be dumb=20 > hosts that don't want to be routers -- is that a shared assumption?) > I don't seem to see the big difference that this can make. If one allows dumb hosts, they won't care if they are in a MANET or not. They're dumb. So, the only thing that matters is that an MR that stands in front of such dumb hosts need to take care of them. NAT comes to mind. Also, getting a prefix and assigning addresses from the prefix to the attached dumb hosts will work just as fine.=20 =20 > Indeed, another question that comes to my mind is, how does=20 > the autoconf problem in manets compare/relate to the zrouter=20 > (zero config > router) BOFs that were held at one point, where the goal was=20 > to autoconfigure the subnets within an autonomous area. How=20 > is the work here similar, and how does it differ? > I'm not familiar with this work. Could you point me to some information about this zrouter BOF? =20 > > Also a MANET is not always connected to the Internet, so we don't=20 > > always have to follow existing rules. >=20 > But there presumably still needs to be some basic assumptions=20 > about what a subnet is, how the addresses on a subnet relate=20 > to each other, etc., regadless of whether the manet is=20 > connected to the internet. > The was I understand things are like this. A "link" is a communication facility under L3. I don't think there should be an assumption of bi-directional reachability on a link. It may or may not provide such support. Joe gave a good example of wireless "links" that may not provide it. A "subnet" is an artificial concept that is used to group a set of nodes that are presumably "on" a same link. Note that this group is not necessarily all nodes on the link as pointed out by Ian. By assigning/configuring addresses that belongs to the same subnet, this group of nodes know that all the other nodes in the same subnet (that can be identified with their IP addresses and netmask) can be reached by just relying on the link, without getting any L3/IP routing involved. If we limit the discussion to providing multihop connectivity at the layer 3 (i.e., the multi-hop nature is exposed to L3 compared to L2 MANET solutions that present an ethernet-like view of MANET to L3), an MR cannot really be sure about what other MRs will be one hop away (i.e., that can be reached by L2) because of their mobility and the nature of wireless medium. So, if a MANET is configured to be a single subnet, that causes the multi-link subnet problems as pointed out by Dave Thaler. =20 > > To me this is the kind of discussions that should appear in the=20 > > MANET-arch document. One could then extract scenarios that will be=20 > > considered by the WG. I see 4 of them: >=20 > > - flat: all nodes have /128, routing entries are /128. An MR has to=20 > > take care of routing for hosts attached to it, and hosts have a=20 > > default route pointing to the MR they are attached to > > - semi-flat: all routers own a /64, they delegate /128 to hosts=20 > > attached to them, routing entries in routers are /64, hosts have a=20 > > default route pointing to the MR they are attached to > > - coherent: all MRs share a given prefix. For example for an=20 > > Internet-connected MANET this could an Internet routeable /48, and for=20 > > an isolated MANET this could a reserved prefix by IANA for MANETs (e.g. > > MANET-local prefix). > > - clustered: some (topologically close) MRs share a given prefix, and=20 > > routing entries to this cluster may be aggregated. Example is a MANET=20 > > with multiple gateways to the Internet or a very large isolated MANET=20 > > that need routing aggregation for scalability reasons. >=20 > Yep, the above are the kinds of questions I have. Just what=20 > is being proposed? (and answering "any and all of them" is=20 > not the answer I'm looking for!) > I did not think of the "clustered" one but I like this classification. I don't see why we need to choose one over the others. They can all co-exist. When there are no attached hosts, "flat" will work just fine. An autoconf scheme needs to assign a /128 address per MR. When there are attached hosts and MRs do not want to NAT them, they can get a prefix and sub-allocate the addresses to the attached hosts - "semi-flat". The autoconf scheme will need to provide prefix on top of addresses. When a MANET is connected to the Internet, a topologically correct prefix can be assigned for the whole MANET - "coherent". MANET gateways will be the aggregation points for the prefix but none of the MRs will be configured to be in the same subnet with any other MRs. This can be done with appropriate netmask settings. This prefix can be divided and given out to MRs in the MANET as in "semi-flat" model. And we can avoid having a multi-link subnet in this way, which I think is a good thing. Thanks, - Seung _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Oct 09 05:52:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWroA-00019y-P6; Mon, 09 Oct 2006 05:52:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWro8-000152-T7 for autoconf@ietf.org; Mon, 09 Oct 2006 05:52:24 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWro7-00015s-91 for autoconf@ietf.org; Mon, 09 Oct 2006 05:52:24 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 Oct 2006 02:51:55 -0700 X-IronPort-AV: i="4.09,281,1157353200"; d="scan'208"; a="45327107:sNHT56426172" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k999pZID026998; Mon, 9 Oct 2006 05:51:35 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k999pWYL014931; Mon, 9 Oct 2006 05:51:35 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 05:51:32 -0400 Received: from 10.86.240.113 ([10.86.240.113]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Mon, 9 Oct 2006 09:51:32 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Sun, 08 Oct 2006 19:59:16 -0400 Subject: Re: [Autoconf] Subnet model From: Ralph Droms To: "Yi, Seung" , Message-ID: Thread-Topic: [Autoconf] Subnet model Thread-Index: AcbohiCVO2/nijtVQ4ekCsNpBtLwpwBIbf7QAGN6jQg= In-Reply-To: <8BA40F9A33179E4E877E37D7D5E9D82D01EC9E1A@XCH-NW-5V2.nw.nos.boeing.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Oct 2006 09:51:32.0950 (UTC) FILETIME=[806F5F60:01C6EB88] DKIM-Signature: a=rsa-sha1; q=dns; l=2291; t=1160387495; x=1161251495; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:Ralph=20Droms=20 |Subject:Re=3A=20[Autoconf]=20Subnet=20model=20 |To:=22Yi,=20Seung=22=20,=20; X=v=3Dcisco.com=3B=20h=3DPr8ym5gT+TwFbPlN2gn4itNi1Po=3D; b=a3pik4GyQT6ve55EOhrKioBt+DZScLXs+LjeUNlru41MXwMkOxY+ExrenLImBc2VE7BFgJod 2ARRjW0cCa2gUJ3oO1NWpNzc+kPzYuesP372nN7/GVBGerr08PeguEe9; Authentication-Results: rtp-dkim-1.cisco.com; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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: , Errors-To: autoconf-bounces@ietf.org Excerpted, with comments in line... - Ralph On 10/6/06 8:53 PM, "Yi, Seung" wrote: >> >> But there presumably still needs to be some basic assumptions >> about what a subnet is, how the addresses on a subnet relate >> to each other, etc., regadless of whether the manet is >> connected to the internet. >> > > The was I understand things are like this. A "link" is a communication > facility under L3. I don't think there should be an assumption of > bi-directional reachability on a link. It may or may not provide such > support. Joe gave a good example of wireless "links" that may not > provide it. OK ... But are there fundamental assumptions in IP about bi-directional reachability? E.g., will ARP, ND, IPv6 address autoconfiguration all work if bi-directional reachability fails? > A "subnet" is an artificial concept that is used to group a > set of nodes that are presumably "on" a same link. Is a "subnet" the set of nodes with addresses assigned from a single prefix? Is there an assumption that all nodes in a subnet have bi-directional reachability? Is that reachability achieved without routing and without TTL decrement? > Note that this group > is not necessarily all nodes on the link as pointed out by Ian. By > assigning/configuring addresses that belongs to the same subnet, this > group of nodes know that all the other nodes in the same subnet (that > can be identified with their IP addresses and netmask) can be reached by > just relying on the link, without getting any L3/IP routing involved. If > we limit the discussion to providing multihop connectivity at the layer > 3 (i.e., the multi-hop nature is exposed to L3 compared to L2 MANET > solutions that present an ethernet-like view of MANET to L3), Is this the point at which we need to add fixes to IP? Is there a fundamental assumption in IP that an L2 layer is always "single hop" for IP? > an MR > cannot really be sure about what other MRs will be one hop away (i.e., > that can be reached by L2) because of their mobility and the nature of > wireless medium. So, if a MANET is configured to be a single subnet, > that causes the multi-link subnet problems as pointed out by Dave > Thaler. > > - Seung - Ralph _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Oct 09 09:30:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWvD5-0000Tl-4x; Mon, 09 Oct 2006 09:30:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWvD3-0000Tg-Vn for autoconf@ietf.org; Mon, 09 Oct 2006 09:30:21 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWvD2-0000YK-WA for autoconf@ietf.org; Mon, 09 Oct 2006 09:30:21 -0400 Received: from ep_mmp2 (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 <0J6V007XTEUFJB@mailout2.samsung.com> for autoconf@ietf.org; Mon, 09 Oct 2006 22:30:15 +0900 (KST) Received: from Shubhranshu ([107.108.4.124]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0J6V00HQ6EUDL5@mmp2.samsung.com> for autoconf@ietf.org; Mon, 09 Oct 2006 22:30:14 +0900 (KST) Date: Mon, 09 Oct 2006 19:02:09 +0530 From: Shubhranshu Subject: Re: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-arch-01.txt To: Ian Chakeres , autoconf@ietf.org Message-id: <00ee01c6eba7$5321d5f0$7c046c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 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: , Content-Type: multipart/mixed; boundary="===============0434718552==" Errors-To: autoconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0434718552== Content-type: multipart/alternative; boundary="Boundary_(ID_LtJGCVE+ekoVgC+2awbpNQ)" This is a multi-part message in MIME format. --Boundary_(ID_LtJGCVE+ekoVgC+2awbpNQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Ian et al/All, I went through this revised ID and found it well written. However, this version also does not say anything about MANET subnet. Looking from the Autoconf perspective, two important things that I would like to see in this document are: - Specific text about MANET subnet - Since there could be different subnet models, this document should nail down all the options and come forward with single model that could be acceptable to the majority. It would be good to hear different thoughts & opinions on the second point. Other thoughts related to this ID are: - I wonder how much of section 7.2. "Cross Layering" belong to this document. I find this section quite general and true for any wireless network. - "Challenges" section sounds more like requirements than architecture and I would suggest further revision. - IMO, first para, section 4 does not belong to this document esp I think words such as "ideally suited" should be avoided. Regards, Shubhranshu ----- Original Message ----- From: "Ian Chakeres" To: ; "manet" Sent: Friday, October 06, 2006 11:51 PM Subject: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-arch-01.txt > I'd like to announce the arch-01 document. > > Please review it, send me comments, and bring discussion to the mailing list. > > Thanks. > Ian Chakeres > > ---------- Forwarded message ---------- > From: Internet-Drafts@ietf.org > Date: Oct 5, 2006 12:50 PM > Subject: I-D ACTION:draft-chakeres-manet-arch-01.txt > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Mobile Ad hoc Network Architecture > Author(s) : I. Chakeres, et al. > Filename : draft-chakeres-manet-arch-01.txt > Pages : 17 > Date : 2006-10-5 > > This document discusses Mobile Ad hoc NETworks (MANETs). It > introduces basic MANET terms, characteristics, and challenges. This > document also defines several MANET entities and architectural > concepts. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chakeres-manet-arch-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-chakeres-manet-arch-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-chakeres-manet-arch-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf > > --Boundary_(ID_LtJGCVE+ekoVgC+2awbpNQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
 Ian et al/All,
 
I went through this revised ID and found it well written. However, this version also does not say anything about MANET subnet. Looking from the Autoconf perspective, two important things that I would like to see in this document are:
 
- Specific text about MANET subnet
- Since there could be different subnet models, this document should nail down all the options and come forward with single model that could be acceptable to the majority.
It would be good to hear different thoughts & opinions on the second point.  
 
Other thoughts related to this ID are:
 
- I wonder how much of section 7.2. "Cross Layering" belong to this document. I find this section quite general and true for any wireless network.
 
- "Challenges" section sounds more like requirements than architecture and I would suggest further revision.
 
- IMO, first para, section 4 does not belong to this document esp I think words such as "ideally suited" should be avoided.
 
Regards,
Shubhranshu
 
----- Original Message -----
From: "Ian Chakeres" <ian.chakeres@gmail.com>
Sent: Friday, October 06, 2006 11:51 PM
Subject: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-arch-01.txt

> I'd like to announce the arch-01 document.
>
> Please review it, send me comments, and bring discussion to the mailing list.
>
> Thanks.
> Ian Chakeres
>
> ---------- Forwarded message ----------
> From: Internet-Drafts@ietf.org <Internet-Drafts@ietf.org>
> Date: Oct 5, 2006 12:50 PM
> Subject: I-D ACTION:draft-chakeres-manet-arch-01.txt
> To: i-d-announce@ietf.org
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>        Title           : Mobile Ad hoc Network Architecture
>        Author(s)       : I. Chakeres, et al.
>        Filename        : draft-chakeres-manet-arch-01.txt
>        Pages           : 17
>        Date            : 2006-10-5
>
> This document discusses Mobile Ad hoc NETworks (MANETs).  It
>   introduces basic MANET terms, characteristics, and challenges.  This
>   document also defines several MANET entities and architectural
>   concepts.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-chakeres-manet-arch-01.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request@ietf.org with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-chakeres-manet-arch-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>        mailserv@ietf.org.
> In the body type:
>        "FILE /internet-drafts/draft-chakeres-manet-arch-01.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
>        MIME-encoded form by using the "mpack" utility.  To use this
>        feature, insert the command "ENCODING mime" before the "FILE"
>        command.  To decode the response(s), you will need "munpack" or
>        a MIME-compliant mail reader.  Different MIME-compliant mail readers
>        exhibit different behavior, especially when dealing with
>        "multipart" MIME messages (i.e. documents which have been split
>        up into multiple messages), so check your local documentation on
>        how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www1.ietf.org/mailman/listinfo/autoconf
>
>

 --Boundary_(ID_LtJGCVE+ekoVgC+2awbpNQ)-- --===============0434718552== 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 --===============0434718552==-- From autoconf-bounces@ietf.org Mon Oct 09 10:57:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwZf-0003cr-3m; Mon, 09 Oct 2006 10:57:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwZe-0003cB-7p for autoconf@ietf.org; Mon, 09 Oct 2006 10:57:46 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWwZa-0007zY-Ph for autoconf@ietf.org; Mon, 09 Oct 2006 10:57:46 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k99Ev5VM020814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 9 Oct 2006 07:57:11 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k99EvZJw014178 for ; Mon, 9 Oct 2006 09:57:36 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k99EvUaM014013; Mon, 9 Oct 2006 09:57:34 -0500 (CDT) Received: from XCH-NW-5V2.nw.nos.boeing.com ([130.247.55.45]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 07:57:31 -0700 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: FW: [Autoconf] Subnet model Date: Mon, 9 Oct 2006 07:57:29 -0700 Message-ID: <8BA40F9A33179E4E877E37D7D5E9D82D01EC9E6F@XCH-NW-5V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Subnet model Thread-Index: AcbohiCVO2/nijtVQ4ekCsNpBtLwpwBIbf7QAGN6jQgAHuAJsA== From: "Yi, Seung" To: X-OriginalArrivalTime: 09 Oct 2006 14:57:31.0012 (UTC) FILETIME=[3EB15440:01C6EBB3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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: , Errors-To: autoconf-bounces@ietf.org Ralph, Comments inline.=20 > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com]=20 > Sent: Sunday, October 08, 2006 4:59 PM > To: Yi, Seung; autoconf@ietf.org > Subject: Re: [Autoconf] Subnet model=20 > > > The was I understand things are like this. A "link" is a=20 > communication=20 > > facility under L3. I don't think there should be an assumption of=20 > > bi-directional reachability on a link. It may or may not=20 > provide such=20 > > support. Joe gave a good example of wireless "links" that may not=20 > > provide it. >=20 > OK ... But are there fundamental assumptions in IP about=20 > bi-directional reachability? E.g., will ARP, ND, IPv6=20 > address autoconfiguration all work if bi-directional=20 > reachability fails? > I'm not saying there should be such an assumption. Rather, I'm making an observation that such an assumption seems to exist in many protocol=20 designer's mind. ARP and IPv6 ND are the perfect examples. Obviously, neither can work without the bi-directional reachability. Further, if that=20 assumption was "implicit", different operatinal environment of the MANET brings it out to the front so that we actually have to deal with the case=20 when that assumption does not hold anymore and some protocols break=20 as the result. Of course, what is the best way to approach this challenge will have to be discussed. =20 >=20 > > A "subnet" is an artificial concept that is used to group a set of=20 > > nodes that are presumably "on" a same link. >=20 > Is a "subnet" the set of nodes with addresses assigned from a=20 > single prefix? > Is there an assumption that all nodes in a subnet have=20 > bi-directional reachability? Is that reachability achieved=20 > without routing and without TTL decrement? >=20 That is what I understand as a subnet: a set of nodes that shares=20 a network prefix. Again, from the way IP routing decision works=20 (i.e., a node sends/forwards packets to an interface that sits on the=20 subnet prefix if the packet is destined to a node in the same subnet),=20 it seems to me that the bi-directional L2 reachability is assumed=20 within a subnet. Or, am I missing something? > > Note that this group > > is not necessarily all nodes on the link as pointed out by Ian. By=20 > > assigning/configuring addresses that belongs to the same=20 > subnet, this=20 > > group of nodes know that all the other nodes in the same=20 > subnet (that=20 > > can be identified with their IP addresses and netmask) can=20 > be reached=20 > > by just relying on the link, without getting any L3/IP routing=20 > > involved. If we limit the discussion to providing multihop=20 > > connectivity at the layer > > 3 (i.e., the multi-hop nature is exposed to L3 compared to L2 MANET=20 > > solutions that present an ethernet-like view of MANET to L3), >=20 > Is this the point at which we need to add fixes to IP? Is=20 > there a fundamental assumption in IP that an L2 layer is=20 > always "single hop" for IP? > Again, some of fundamental components such as ARP and IPv6 ND will break when L2 is not a single hop for IP. Do we "fix" IP so that IP can handle=20 such situations or do we make all L2 look like an ethernet to IP? I'm not=20 making any strong claim for either at this point. I think both can be viable solutions depending on the application domain and deployment scenarios. Also, I think we can preserve much of existing semantics by "fixing" some=20 of the protocols (compared to the IP) that obviously rely on the "single hop"=20 view such as ARP and IPv6 ND.=20 - Seung _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Oct 09 16:32:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX1nw-0003k8-Ke; Mon, 09 Oct 2006 16:32:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX1nv-0003jn-A3 for autoconf@ietf.org; Mon, 09 Oct 2006 16:32:51 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX1nq-0007pq-Ob for autoconf@ietf.org; Mon, 09 Oct 2006 16:32:51 -0400 Received: by ug-out-1314.google.com with SMTP id 72so607347ugd for ; Mon, 09 Oct 2006 13:32:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=rUJeUI9ipkdvgKgxNXdI3WuDUlbStzfEXFLqm1tHv8O/45Cg4qLQdq5MXav9tPHxF2dS5piiHlZdjrxWXdYMFzrMXk28NWAgi2aq4jrQdnTxb/SDNgC+jZ4ILOfjPqF9ISptHs/ARf/PixO/ZVkd1d091iN0eLHSWZCxXkd8ifI= Received: by 10.66.224.3 with SMTP id w3mr7377696ugg; Mon, 09 Oct 2006 13:32:43 -0700 (PDT) Received: by 10.66.255.17 with HTTP; Mon, 9 Oct 2006 13:32:43 -0700 (PDT) Message-ID: <374005f30610091332s20a798d6v88f99a89dcddd595@mail.gmail.com> Date: Mon, 9 Oct 2006 13:32:43 -0700 From: "Ian Chakeres" To: Shubhranshu , autoconf@ietf.org, "Thomas Narten" , "Thomas Heide Clausen (home)" , "Joe P Macker (home)" Subject: Re: [Autoconf] "No" Subnet Model and Autoconf Goal MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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: , Errors-To: autoconf-bounces@ietf.org After doings some reading up on various RFCs, I've been trying to come up with an answer to the question "what is the subnet model for MANET", or perhaps more accurately "what is the subnet model for MANET Autoconf". As Joe pointed out, I think that running MANET routers unnumbered is a valid approach. Essentially this can be thought of as the "no subnet model". Some more information on running unnumbered can be found in RFC 1812, and a few other references I've listed below my name. Given this subnet model, I think that the first goal of the Autoconf group would be to determine a MANET router's router-id. Do you think this is the right "subnet model" for the Autoconf WG? Do you think the initial goal of the Autoconf group should be to determine a MANET router's router-id? Ian Chakeres Here are a few references I found relevent: RFC 950 RFC 3819 draft-iab-multilink-subnet-issues www.apricot2006.net/slides/conf/thursday/Kireeti_Kompella_unnum.ppt draft-madanapalli-16ng-subnet-model-analysis draft-ietf-v6ops-802.16-deployment-scenarios On 10/9/06, Shubhranshu wrote: > > > Ian et al/All, > > I went through this revised ID and found it well written. However, this > version also does not say anything about MANET subnet. Looking from the > Autoconf perspective, two important things that I would like to see in this > document are: > > - Specific text about MANET subnet > - Since there could be different subnet models, this document should nail > down all the options and come forward with single model that could be > acceptable to the majority. > It would be good to hear different thoughts & opinions on the second point. > > > Other thoughts related to this ID are: > > - I wonder how much of section 7.2. "Cross Layering" belong to this > document. I find this section quite general and true for any wireless > network. > > - "Challenges" section sounds more like requirements than architecture and I > would suggest further revision. > > - IMO, first para, section 4 does not belong to this document esp I think > words such as "ideally suited" should be avoided. > > Regards, > Shubhranshu > > > ----- Original Message ----- > From: "Ian Chakeres" > To: ; "manet" > Sent: Friday, October 06, 2006 11:51 PM > Subject: [Autoconf] Fwd: I-D > ACTION:draft-chakeres-manet-arch-01.txt > > > I'd like to announce the arch-01 document. > > > > Please review it, send me comments, and bring discussion to the mailing > list. > > > > Thanks. > > Ian Chakeres > > > > ---------- Forwarded message ---------- > > From: Internet-Drafts@ietf.org > > Date: Oct 5, 2006 12:50 PM > > Subject: I-D ACTION:draft-chakeres-manet-arch-01.txt > > To: i-d-announce@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Mobile Ad hoc Network Architecture > > Author(s) : I. Chakeres, et al. > > Filename : draft-chakeres-manet-arch-01.txt > > Pages : 17 > > Date : 2006-10-5 > > > > This document discusses Mobile Ad hoc NETworks (MANETs). It > > introduces basic MANET terms, characteristics, and challenges. This > > document also defines several MANET entities and architectural > > concepts. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-chakeres-manet-arch-01.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > > the message. > > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then > > "get draft-chakeres-manet-arch-01.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-chakeres-manet-arch-01.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > _______________________________________________ > > 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 Mon Oct 09 16:50:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX25S-0005qN-O6; Mon, 09 Oct 2006 16:50:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX25R-0005qD-Kx for autoconf@ietf.org; Mon, 09 Oct 2006 16:50:57 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX25O-0003OV-AY for autoconf@ietf.org; Mon, 09 Oct 2006 16:50:57 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k99KokGL000738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 9 Oct 2006 13:50:47 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k99KokpG018461 for ; Mon, 9 Oct 2006 15:50:46 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k99Koab2018071; Mon, 9 Oct 2006 15:50:45 -0500 (CDT) 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); Mon, 9 Oct 2006 13:50:44 -0700 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] "No" Subnet Model and Autoconf Goal Date: Mon, 9 Oct 2006 13:50:43 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774387@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <374005f30610091332s20a798d6v88f99a89dcddd595@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] "No" Subnet Model and Autoconf Goal Thread-Index: Acbr4phm5FrvKajbTMi3AJyGbuWDMAAASJ5g From: "Templin, Fred L" To: "Ian Chakeres" , "Shubhranshu" , , "Thomas Narten" , "Thomas Heide Clausen \(home\)" , "Joe P Macker \(home\)" X-OriginalArrivalTime: 09 Oct 2006 20:50:44.0519 (UTC) FILETIME=[9701DB70:01C6EBE4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Errors-To: autoconf-bounces@ietf.org > As Joe pointed out, I think that running MANET routers unnumbered is a > valid approach. Essentially this can be thought of as the "no subnet > model". Right, and as I pointed out that model derives from: http://tools.ietf.org/wg/autoconf/draft-thaler-autoconf-multisubnet-mane ts-00.txt But, in this "multisubnet manet" model the MANET routers still have a link-local address on their MANET interface that needs to be maintained as unique within the MANET; right? So, maybe it would be better called something like the "link-local-only" model? Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Oct 09 21:24:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX6MB-0001nY-PR; Mon, 09 Oct 2006 21:24:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX6MA-0001nT-VJ for autoconf@ietf.org; Mon, 09 Oct 2006 21:24:30 -0400 Received: from client207-106.dsl.intrex.net ([209.42.207.106] helo=cichlid.raleigh.ibm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX6M9-0006yu-JE for autoconf@ietf.org; Mon, 09 Oct 2006 21:24:30 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.7/8.11.6) with ESMTP id k9A1OVX7003979; Mon, 9 Oct 2006 21:24:31 -0400 Message-Id: <200610100124.k9A1OVX7003979@cichlid.raleigh.ibm.com> To: "Ian Chakeres" Subject: Re: [Autoconf] "No" Subnet Model and Autoconf Goal In-reply-to: <374005f30610091332s20a798d6v88f99a89dcddd595@mail.gmail.com> References: <374005f30610091332s20a798d6v88f99a89dcddd595@mail.gmail.com> Comments: In-reply-to "Ian Chakeres" message dated "Mon, 09 Oct 2006 13:32:43 -0700." Date: Mon, 09 Oct 2006 21:24:31 -0400 From: Thomas Narten X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: autoconf@ietf.org, "Thomas Heide Clausen \(home\)" 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 "Ian Chakeres" writes: > After doings some reading up on various RFCs, I've been trying to come > up with an answer to the question "what is the subnet model for > MANET", or perhaps more accurately "what is the subnet model for MANET > Autoconf". > As Joe pointed out, I think that running MANET routers unnumbered is a > valid approach. Essentially this can be thought of as the "no subnet > model". Some more information on running unnumbered can be found in > RFC 1812, and a few other references I've listed below my name. Maybe it's just me, but I just don't get this (and it is driving me crazy!) Can you point to any other network that runs IP that has a "no subnet model"? What does this mean? I'm trying to understand how this would work actually work. I.e., how packets go from one node to another. For example, if I am a host H1, how do I send packets to H3? Can H1 send packets to H3 directly (if they are in radio range of each other)? Or can they never do so? Do they always forward traffic to their attached router, and then the routers (via the magic of flat routing) route the packet to the host's directly attached route for final delivery? And above you say "running MANET routers unnumbered is a valid approach". I'm sure there are a number of "valid approaches". Which one is the WG focussed on? Or are there a number of different valid approaches, each of which will need to be supported? Presumably this WG needs to pick one approach and standardize it. Right? > Given this subnet model, I think that the first goal of the Autoconf > group would be to determine a MANET router's router-id. What is the significance of a router ID? What does it have to do with a _host_ determining what address it should use? Or what constitues an IP subnet? > Do you think this is the right "subnet model" for the Autoconf WG? > Do you think the initial goal of the Autoconf group should be to > determine a MANET router's router-id? What documents describe the purpose of the router ID and what it is used for? (I assume this is a well-understood concept in MANETs...) Thomas _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Oct 10 05:40:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXE69-00007O-Hs; Tue, 10 Oct 2006 05:40:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXE68-00007J-G4 for autoconf@ietf.org; Tue, 10 Oct 2006 05:40:28 -0400 Received: from balu1.urz.unibas.ch ([131.152.1.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXE67-0007ho-13 for autoconf@ietf.org; Tue, 10 Oct 2006 05:40:28 -0400 Received: from [131.152.55.200] (baobab.cs.unibas.ch [131.152.55.200]) by balu1.urz.unibas.ch (8.13.7/8.13.7) with ESMTP id k9A9eJ6o027859 for ; Tue, 10 Oct 2006 11:40:19 +0200 Message-ID: <452B6AC1.9020409@unibas.ch> Date: Tue, 10 Oct 2006 11:41:21 +0200 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: autoconf@ietf.org Subject: Re: [Autoconf] "No" Subnet Model and Autoconf Goal References: <374005f30610091332s20a798d6v88f99a89dcddd595@mail.gmail.com> In-Reply-To: <374005f30610091332s20a798d6v88f99a89dcddd595@mail.gmail.com> 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: 21c69d3cfc2dd19218717dbe1d974352 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 Ian, Joe, Well I have to admit I'm not so familiar with this unnumbered approach and I think it would be useful (hopefully for everybody) if you could further explain why you think this is a good approach. I had a look at different documents, and I'm not sure how you want to apply this unnumbered approach to MANETs and what it really solves. It seems it's useful so that one does not need to assign a unique address to each interface of the router: is this what you foresee? Or do you want to use this for its off-link properties? best regards, Christophe Ian Chakeres wrote: > After doings some reading up on various RFCs, I've been trying to come > up with an answer to the question "what is the subnet model for > MANET", or perhaps more accurately "what is the subnet model for MANET > Autoconf". > > As Joe pointed out, I think that running MANET routers unnumbered is a > valid approach. Essentially this can be thought of as the "no subnet > model". Some more information on running unnumbered can be found in > RFC 1812, and a few other references I've listed below my name. > > Given this subnet model, I think that the first goal of the Autoconf > group would be to determine a MANET router's router-id. > > Do you think this is the right "subnet model" for the Autoconf WG? > > Do you think the initial goal of the Autoconf group should be to > determine a MANET router's router-id? > > Ian Chakeres > > Here are a few references I found relevent: > RFC 950 > RFC 3819 > draft-iab-multilink-subnet-issues > www.apricot2006.net/slides/conf/thursday/Kireeti_Kompella_unnum.ppt > draft-madanapalli-16ng-subnet-model-analysis > draft-ietf-v6ops-802.16-deployment-scenarios > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Oct 10 10:45:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXIrJ-00015I-QV; Tue, 10 Oct 2006 10:45:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXIrI-00014q-5r for autoconf@ietf.org; Tue, 10 Oct 2006 10:45:28 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXIrF-00038k-MW for autoconf@ietf.org; Tue, 10 Oct 2006 10:45:28 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9AEjNYA029021; Tue, 10 Oct 2006 17:45:23 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 17:45:23 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 09:45:15 -0500 Received: from [172.21.43.234] ([172.21.43.234]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 09:45:14 -0500 Message-ID: <452BB1F7.2000307@nokia.com> Date: Tue, 10 Oct 2006 07:45:11 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ext Thomas Narten Subject: Re: [Autoconf] "No" Subnet Model and Autoconf Goal References: <374005f30610091332s20a798d6v88f99a89dcddd595@mail.gmail.com> <200610100124.k9A1OVX7003979@cichlid.raleigh.ibm.com> In-Reply-To: <200610100124.k9A1OVX7003979@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Oct 2006 14:45:14.0862 (UTC) FILETIME=[B25380E0:01C6EC7A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: autoconf@ietf.org, "Thomas Heide Clausen \(home\)" 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 Hello Thomas, ext Thomas Narten wrote: > > Can you point to any other network that runs IP that has a "no subnet > model"? What does this mean? I'm trying to understand how this would > work actually work. I.e., how packets go from one node to another. > What is wrong with modeling the link as a point-to-point connection? What about my Mobile IP example? > For example, if I am a host H1, how do I send packets to H3? Can H1 > send packets to H3 directly (if they are in radio range of each > other)? Yes, if they have a point-to-point link. -- Please address return e-mail to charles.perkins@nokia.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Oct 10 10:50:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXIvx-0004Fx-NF; Tue, 10 Oct 2006 10:50:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXIvw-0004Fr-Cm for autoconf@ietf.org; Tue, 10 Oct 2006 10:50:16 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXIvt-00049H-S7 for autoconf@ietf.org; Tue, 10 Oct 2006 10:50:16 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9AEo6GD032126; Tue, 10 Oct 2006 17:50:12 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 17:50:10 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 09:50:07 -0500 Received: from [172.21.43.234] ([172.21.43.234]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 09:50:07 -0500 Message-ID: <452BB31C.2080302@nokia.com> Date: Tue, 10 Oct 2006 07:50:04 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ext Ian Chakeres Subject: Re: [Autoconf] "No" Subnet Model and Autoconf Goal References: <374005f30610091332s20a798d6v88f99a89dcddd595@mail.gmail.com> In-Reply-To: <374005f30610091332s20a798d6v88f99a89dcddd595@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Oct 2006 14:50:07.0662 (UTC) FILETIME=[60D93CE0:01C6EC7B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: , Errors-To: autoconf-bounces@ietf.org Hello Ian, ext Ian Chakeres wrote: > As Joe pointed out, I think that running MANET routers unnumbered is a > valid approach. O.K., but... > Essentially this can be thought of as the "no subnet > model". Sounds like a no-address model. > > > Given this subnet model, I think that the first goal of the Autoconf > group would be to determine a MANET router's router-id. Why not use the node's IP address as its router-id? But why even bother? It is quite clear we can use the unsubnetted IP address as the endpoint of a point-to-point link. > > Do you think this is the right "subnet model" for the Autoconf WG? I don't think it is necessary, and I think it is easier to just not bother making any requirement for having a subnet model. What good is it to make the requirement? Of course it should be _allowed_ to have subnets... > > Do you think the initial goal of the Autoconf group should be to > determine a MANET router's router-id? No, I definitely do not think so. I think it would be a big waste of time and a mistake. Regards, Charlie P. -- Please address return e-mail to charles.perkins@nokia.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Oct 10 12:03:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXK4I-0005XN-0B; Tue, 10 Oct 2006 12:02:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXK4H-0005XH-Ju for autoconf@ietf.org; Tue, 10 Oct 2006 12:02:57 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXK4F-0005cd-AK for autoconf@ietf.org; Tue, 10 Oct 2006 12:02:57 -0400 Received: by ug-out-1314.google.com with SMTP id 72so713076ugd for ; Tue, 10 Oct 2006 09:02:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=o8YP0apzHXTXL3P/ctcYWzQFnrDcTyoXafzdyH/QOF3yptx8krAdsLXU7dWjrVtSjPUBOg0WeFxNIvvJqRFWtStk8ov+Z1ewOa4ROpQeNdbjqxZr8yCZ37fuF52s5VpfuhiLuaxoDgrAXsmJeYYB27dVGJ34FK+zpJ9IPlRtWs8= Received: by 10.67.91.6 with SMTP id t6mr8418141ugl; Tue, 10 Oct 2006 09:02:54 -0700 (PDT) Received: by 10.66.255.17 with HTTP; Tue, 10 Oct 2006 09:02:53 -0700 (PDT) Message-ID: <374005f30610100902w7de5cbe2o484d5f9294db10ec@mail.gmail.com> Date: Tue, 10 Oct 2006 09:02:53 -0700 From: "Ian Chakeres" To: autoconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Autoconf] Autoconf Discussion - Scenario #1 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 I went back and looked at Dave's presentation about autoconf-multisubnet-manet (www3.ietf.org/proceedings/06mar/slides/autoconf-0/autoconf-0.ppt). It provides some good food for thought, and fits with the MANET routing protocols. Do people agree with the ideas below? paraphrased from above presentation AUTOCONF protocol determines/allocates prefixes not addresses to MANET routers MANET routers assign a prefix to a loopback interface or to a non-MANET interface for clients MANET routers pick a router-id, and often configure an address within this prefix MANET routing protocol exchanges prefix routes client nodes attached to MANET routers, pick their address(es) in the router's prefix normally Ian Chakeres _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Oct 10 12:24:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXKOz-0003oi-3p; Tue, 10 Oct 2006 12:24:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXKOy-0003oc-FP for autoconf@ietf.org; Tue, 10 Oct 2006 12:24:20 -0400 Received: from balu1.urz.unibas.ch ([131.152.1.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXKOx-0001op-2R for autoconf@ietf.org; Tue, 10 Oct 2006 12:24:20 -0400 Received: from [131.152.55.200] (baobab.cs.unibas.ch [131.152.55.200]) by balu1.urz.unibas.ch (8.13.7/8.13.7) with ESMTP id k9AGOH9E014728 for ; Tue, 10 Oct 2006 18:24:18 +0200 Message-ID: <452BC96F.8090606@unibas.ch> Date: Tue, 10 Oct 2006 18:25:19 +0200 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: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf Discussion - Scenario #1 References: <374005f30610100902w7de5cbe2o484d5f9294db10ec@mail.gmail.com> In-Reply-To: <374005f30610100902w7de5cbe2o484d5f9294db10ec@mail.gmail.com> 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: 21c69d3cfc2dd19218717dbe1d974352 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 Hello Ian, Overall this sounds very reasonable. See detailed comments inline. Ian Chakeres wrote: > I went back and looked at Dave's presentation about > autoconf-multisubnet-manet > (www3.ietf.org/proceedings/06mar/slides/autoconf-0/autoconf-0.ppt). It > provides some good food for thought, and fits with the MANET routing > protocols. > > Do people agree with the ideas below? paraphrased from above presentation > > AUTOCONF protocol determines/allocates prefixes not addresses to MANET > routers fine, except that IPv6 routers are not supposed to perform stateless address autoconfiguration: so yes AUTOCONF determines prefixes, but depending on the scheme one might need to also assign an address for the router (which is a side problem). > MANET routers assign a prefix to a loopback interface or to a > non-MANET interface for clients as expressed in a previous email today, I'm not sure what this brings us so I'm not for or against it yet: I'm waiting to be convinced this is a good idea. ;-) I don't see any problems with assigning addresses to interfaces as long as routing protocols advertise prefixes (by the way the link to ppt slides you sent yesterday says the unnumbered trick is useless with IPv6 and I agree so far). > MANET routers pick a router-id, and often configure an address within > this prefix what's the difference between a prefix and a router-id? Is there any? I think it's just fine if we use the term prefix and forget about this router-id stuff. > MANET routing protocol exchanges prefix routes > > client nodes attached to MANET routers, pick their address(es) in the > router's prefix normally fine. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Oct 10 12:35:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXKa0-0000oz-4q; Tue, 10 Oct 2006 12:35:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXKZy-0000ob-O3 for autoconf@ietf.org; Tue, 10 Oct 2006 12:35:42 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXKZu-0004Jd-Da for autoconf@ietf.org; Tue, 10 Oct 2006 12:35:42 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k9AGYxI2011726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 10 Oct 2006 09:35:04 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k9AGZV9Z016110 for ; Tue, 10 Oct 2006 09:35:32 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k9AGZOUQ015712; Tue, 10 Oct 2006 09:35:24 -0700 (PDT) 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); Tue, 10 Oct 2006 09:35:23 -0700 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] Autoconf Discussion - Scenario #1 Date: Tue, 10 Oct 2006 09:35:22 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177438D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <452BC96F.8090606@unibas.ch> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Autoconf Discussion - Scenario #1 Thread-Index: AcbsiK/uHpf18l1bRAOc2vfedK3WSAAALlWA From: "Templin, Fred L" To: "Christophe Jelger" , X-OriginalArrivalTime: 10 Oct 2006 16:35:23.0877 (UTC) FILETIME=[159B2950:01C6EC8A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Errors-To: autoconf-bounces@ietf.org > fine, except that IPv6 routers are not supposed to perform stateless=20 > address autoconfiguration: so yes AUTOCONF determines prefixes, but=20 > depending on the scheme one might need to also assign an address for the=20 > router (which is a side problem). Two points here: 1) the router would not be doing SLAAC to get an address on its access interface; it would be using some prefix delegation mechanism to get a prefix via its access interface that it could use on a loopback interface *or* for subnetting on its downstream attached interfaces. 2) the router still needs a unique link-local address on its access interface - unless the access interface is a p2p interface in which case it doesn't even need that. Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Oct 10 12:47:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXKlo-0007ow-6e; Tue, 10 Oct 2006 12:47:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXKln-0007ol-6P for autoconf@ietf.org; Tue, 10 Oct 2006 12:47:55 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXKlk-00063v-T2 for autoconf@ietf.org; Tue, 10 Oct 2006 12:47:55 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id k9AGlY7X010103; Tue, 10 Oct 2006 12:47:37 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2006101012482615795 ; Tue, 10 Oct 2006 12:48:26 -0400 From: "Joe Macker" To: "'Charles E. Perkins'" , "'ext Ian Chakeres'" Subject: RE: [Autoconf] "No" Subnet Model and Autoconf Goal Date: Tue, 10 Oct 2006 12:47:34 -0400 Message-ID: <03d301c6ec8b$c9147c10$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.2962 In-Reply-To: <452BB31C.2080302@nokia.com> Thread-Index: Acbse27C4cdRi9FZQk+xzQcR3nr7awAC5KFw X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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: , Errors-To: autoconf-bounces@ietf.org I agree with both approaches. A MANET L3 interface is not a fixed Ethernet model. Subnet prefixes in the general sense are supported within the routing domain for attached networks or border aggregation. To retierate some previous posts, in the late 90s some early MANET deployments incorrectly configured local MANET interfaces with prefixes that included hosts multiple hops away. This only worked because router redirects can be turned off and longest prefix matching in the routing tables kept things working .. at least for proactive routing. I think that was bad practice and is not how things have been done or should be done. Hopefully at least that much is clear. Viewing it as an unsubnetted local interface model with multiple point-to-point neighbors works. Running unnumbered or link local for some architecturess also works. Various running code has supported these appraoches. Do we need to force one model or can we support both? Or as a slightly different question does autoconf only want to address one approach? I am fan of enigneering both but discussing the differences clearly. -joe >-----Original Message----- >From: Charles E. Perkins [mailto:charles.perkins@nokia.com] >Sent: Tuesday, October 10, 2006 10:50 AM >To: ext Ian Chakeres >Cc: autoconf@ietf.org >Subject: Re: [Autoconf] "No" Subnet Model and Autoconf Goal > > >Hello Ian, > >ext Ian Chakeres wrote: >> As Joe pointed out, I think that running MANET routers >unnumbered is a >> valid approach. >O.K., but... >> Essentially this can be thought of as the "no subnet model". >Sounds like a no-address model. >> >> >> Given this subnet model, I think that the first goal of the Autoconf >> group would be to determine a MANET router's router-id. >Why not use the node's IP address as its router-id? > >But why even bother? It is quite clear we can use the >unsubnetted IP address as the endpoint of a point-to-point link. >> >> Do you think this is the right "subnet model" for the Autoconf WG? >I don't think it is necessary, and I think it is easier to >just not bother making any requirement for having a subnet model. >What good is it to make the requirement? > >Of course it should be _allowed_ to have subnets... >> >> Do you think the initial goal of the Autoconf group should be to >> determine a MANET router's router-id? >No, I definitely do not think so. I think it would be a big >waste of time and a mistake. > >Regards, >Charlie P. > > >-- >Please address return e-mail to charles.perkins@nokia.com > > >_______________________________________________ >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 Tue Oct 10 13:10:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXL7c-0002H9-Km; Tue, 10 Oct 2006 13:10:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXL7b-0002GC-09 for autoconf@ietf.org; Tue, 10 Oct 2006 13:10:27 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXL3Q-0000rz-6f for autoconf@ietf.org; Tue, 10 Oct 2006 13:06:09 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k9AH5YWh006274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 10 Oct 2006 10:05:34 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k9AH6650001943 for ; Tue, 10 Oct 2006 10:06:07 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k9AH5xrp001600; Tue, 10 Oct 2006 10:06:04 -0700 (PDT) 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); Tue, 10 Oct 2006 10:05:59 -0700 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] "No" Subnet Model and Autoconf Goal Date: Tue, 10 Oct 2006 10:05:57 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177438F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10177438E@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] "No" Subnet Model and Autoconf Goal Thread-Index: Acbse27C4cdRi9FZQk+xzQcR3nr7awAC5KFwAAFNREAAAHGg0A== From: "Templin, Fred L" To: "Joe Macker" , "Charles E. Perkins" , "ext Ian Chakeres" X-OriginalArrivalTime: 10 Oct 2006 17:05:59.0018 (UTC) FILETIME=[5B6F74A0:01C6EC8E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: , Errors-To: autoconf-bounces@ietf.org Question to ADs and/or WG chairs - is this list being moderated or something? Fred=20 -----Original Message----- From: Templin, Fred L=20 Sent: Tuesday, October 10, 2006 9:56 AM To: 'Joe Macker'; 'Charles E. Perkins'; 'ext Ian Chakeres' Cc: autoconf@ietf.org Subject: RE: [Autoconf] "No" Subnet Model and Autoconf Goal > Viewing it as an unsubnetted local interface model with multiple > point-to-point neighbors works. I think this depends on the type of access technology. If broadcasts/multicasts sent over the access interface are received by multiple neighbors, then it isn't multiple point-to-point links - it is shared media link. A shared media link can be made to look like multiple point-to-point links if you use some sort of L2 partitioning like VLANs. But then, it wouldn't be mobility-agile. I don't want to keep plugging for my document, but maybe take a look at 'draft-templin-manet-autoconf-link'. Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Oct 10 13:12:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXL9w-0003Ia-J9; Tue, 10 Oct 2006 13:12:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXL83-0002VY-9J for autoconf@ietf.org; Tue, 10 Oct 2006 13:10:55 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXKu3-0007yu-J2 for autoconf@ietf.org; Tue, 10 Oct 2006 12:56:28 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k9AGtr7c028758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 10 Oct 2006 09:55:54 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k9AGuQi9025118 for ; Tue, 10 Oct 2006 11:56:26 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k9AGuIXO024783; Tue, 10 Oct 2006 11:56:26 -0500 (CDT) 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); Tue, 10 Oct 2006 09:56:25 -0700 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] "No" Subnet Model and Autoconf Goal Date: Tue, 10 Oct 2006 09:56:24 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177438E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <03d301c6ec8b$c9147c10$165cfa84@SEXTANT> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] "No" Subnet Model and Autoconf Goal Thread-Index: Acbse27C4cdRi9FZQk+xzQcR3nr7awAC5KFwAAFNREA= From: "Templin, Fred L" To: "Joe Macker" , "Charles E. Perkins" , "ext Ian Chakeres" X-OriginalArrivalTime: 10 Oct 2006 16:56:25.0441 (UTC) FILETIME=[058E8D10:01C6EC8D] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: , Errors-To: autoconf-bounces@ietf.org > Viewing it as an unsubnetted local interface model with multiple > point-to-point neighbors works. I think this depends on the type of access technology. If broadcasts/multicasts sent over the access interface are received by multiple neighbors, then it isn't multiple point-to-point links - it is shared media link. A shared media link can be made to look like multiple point-to-point links if you use some sort of L2 partitioning like VLANs. But then, it wouldn't be mobility-agile. I don't want to keep plugging for my document, but maybe take a look at 'draft-templin-manet-autoconf-link'. Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Oct 10 15:19:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXN8d-0006Kk-4d; Tue, 10 Oct 2006 15:19:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXN8b-0006J3-W0 for autoconf@ietf.org; Tue, 10 Oct 2006 15:19:37 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXN1a-00026t-Ie for autoconf@ietf.org; Tue, 10 Oct 2006 15:12:23 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id k9AJC75D019822; Tue, 10 Oct 2006 15:12:07 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2006101015125716713 ; Tue, 10 Oct 2006 15:12:57 -0400 From: "Joe Macker" To: "'Templin, Fred L'" , "'Charles E. Perkins'" , "'ext Ian Chakeres'" Subject: RE: [Autoconf] "No" Subnet Model and Autoconf Goal Date: Tue, 10 Oct 2006 15:12:04 -0400 Message-ID: <03ed01c6ec9f$f8fad0a0$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.2962 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10177438E@XCH-NW-7V2.nw.nos.boeing.com> Thread-Index: Acbse27C4cdRi9FZQk+xzQcR3nr7awAC5KFwAAFNREAAA9GigA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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: , Errors-To: autoconf-bounces@ietf.org Fred: Yes, I think we agree, its multiple access specific and most akin to P2MP with dynamic neighbor discovery (sorry I said that in a separate message) ...so in this interface type we can take advantage of link local multicast (often optional with present IP P2MP) to reach multiple link local neighbors. The main point was a shared prefix assignment on the link local interface for reaching neighbor routers like a typical Ethernet doesn't make much sense in a MANET. The routers can be in the same aggregate prefix for routing area aggreagation purposes or can support attached prefixes as normal. Actually, since many router implementations support working across multiple interface types we could have different types supported as well. You are right in that this is multiple access specific and we have all perhaps gotten used to discussing the typical shared access type that we deal with. -Joe >-----Original Message----- >From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] >Sent: Tuesday, October 10, 2006 12:56 PM >To: Joe Macker; Charles E. Perkins; ext Ian Chakeres >Cc: autoconf@ietf.org >Subject: RE: [Autoconf] "No" Subnet Model and Autoconf Goal > >> Viewing it as an unsubnetted local interface model with multiple >> point-to-point neighbors works. > >I think this depends on the type of access technology. If >broadcasts/multicasts sent over the access interface are >received by multiple neighbors, then it isn't multiple >point-to-point links - it is shared media link. A shared media >link can be made to look like multiple point-to-point links if >you use some sort of L2 partitioning like VLANs. >But then, it wouldn't be mobility-agile. > >I don't want to keep plugging for my document, but maybe take >a look at 'draft-templin-manet-autoconf-link'. > >Fred >fred.l.templin@boeing.com > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Oct 10 15:35:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXNO8-0004TW-8X; Tue, 10 Oct 2006 15:35:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXNO7-0004TR-5Q for autoconf@ietf.org; Tue, 10 Oct 2006 15:35:39 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXNO5-0005m5-Rx for autoconf@ietf.org; Tue, 10 Oct 2006 15:35:39 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id k9AJZYLI021113; Tue, 10 Oct 2006 15:35:35 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2006101015362416813 ; Tue, 10 Oct 2006 15:36:24 -0400 From: "Joe Macker" To: "'Christophe Jelger'" , Subject: RE: [Autoconf] "No" Subnet Model and Autoconf Goal Date: Tue, 10 Oct 2006 15:35:32 -0400 Message-ID: <03f401c6eca3$3fcece20$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.2962 In-Reply-To: <452B6AC1.9020409@unibas.ch> Thread-Index: AcbsUHyuCieAnMqbQ42KZhlVpOFciAAT4q3A X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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: , Errors-To: autoconf-bounces@ietf.org I do not want to get hung up on this too much (because I believe multiple architectural models are valid)... Also this is not my idea and I am not proposing it as new. It is a special case of router only mode of operation. In MANET-OSPF this was being applied along with the use of link local addressing approaches for IPv6 router-router links. In this case the mobile routers are just sending around and advertising attached prefix information. Its what routers do and often times we have valid deployments in which we know what routers and attached prefixes are being deployed. This is similar to the Thaler ID concepts. One would still want methods for assigning distributed prefixes somehow and have some BGR discovery there are some EUID uniqueness requirements(IPv6 stateless case). so there are still autoconf issues. There was a thread at the first autoconf WG in Dallas (there are some notes in the proceedings I believe). I think we should talk about the numbered case as well with the PTMP/dynamic neighbor/multicast type interface assumption. >-----Original Message----- >From: Christophe Jelger [mailto:Christophe.Jelger@unibas.ch] >Sent: Tuesday, October 10, 2006 5:41 AM >To: autoconf@ietf.org >Subject: Re: [Autoconf] "No" Subnet Model and Autoconf Goal > >Ian, Joe, > >Well I have to admit I'm not so familiar with this unnumbered >approach and I think it would be useful (hopefully for >everybody) if you could further explain why you think this is >a good approach. > >I had a look at different documents, and I'm not sure how you >want to apply this unnumbered approach to MANETs and what it >really solves. It seems it's useful so that one does not need >to assign a unique address to each interface of the router: is >this what you foresee? Or do you want to use this for its >off-link properties? > >best regards, >Christophe > >Ian Chakeres wrote: >> After doings some reading up on various RFCs, I've been >trying to come >> up with an answer to the question "what is the subnet model for >> MANET", or perhaps more accurately "what is the subnet model >for MANET >> Autoconf". >> >> As Joe pointed out, I think that running MANET routers >unnumbered is a >> valid approach. Essentially this can be thought of as the >"no subnet >> model". Some more information on running unnumbered can be found in >> RFC 1812, and a few other references I've listed below my name. >> >> Given this subnet model, I think that the first goal of the Autoconf >> group would be to determine a MANET router's router-id. >> >> Do you think this is the right "subnet model" for the Autoconf WG? >> >> Do you think the initial goal of the Autoconf group should be to >> determine a MANET router's router-id? >> >> Ian Chakeres >> >> Here are a few references I found relevent: >> RFC 950 >> RFC 3819 >> draft-iab-multilink-subnet-issues >> www.apricot2006.net/slides/conf/thursday/Kireeti_Kompella_unnum.ppt >> draft-madanapalli-16ng-subnet-model-analysis >> draft-ietf-v6ops-802.16-deployment-scenarios >> > >_______________________________________________ >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 Oct 11 07:32:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXcJf-0000FW-UL; Wed, 11 Oct 2006 07:32:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXcJe-0000Er-G2 for autoconf@ietf.org; Wed, 11 Oct 2006 07:32:02 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXcJd-0004PZ-1K for autoconf@ietf.org; Wed, 11 Oct 2006 07:32:02 -0400 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 <0J6Y00K4DYP0DQ@mailout2.samsung.com> for autoconf@ietf.org; Wed, 11 Oct 2006 20:31:48 +0900 (KST) Received: from Shubhranshu ([107.108.4.124]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0J6Y00FWKYOZ8G@mmp1.samsung.com> for autoconf@ietf.org; Wed, 11 Oct 2006 20:31:48 +0900 (KST) Date: Wed, 11 Oct 2006 17:04:01 +0530 From: Shubhranshu Subject: Re: [Autoconf] "No" Subnet Model and Autoconf Goal To: "Templin, Fred L" Message-id: <015c01c6ed29$26e769e0$7c046c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; reply-type=original; charset=iso-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <39C363776A4E8C4A94691D2BD9D1C9A10177438F@XCH-NW-7V2.nw.nos.boeing.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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: , Errors-To: autoconf-bounces@ietf.org Fred, ----- Original Message ----- From: "Templin, Fred L" To: "Joe Macker" ; "Charles E. Perkins" ; "ext Ian Chakeres" Cc: Sent: Tuesday, October 10, 2006 10:35 PM Subject: RE: [Autoconf] "No" Subnet Model and Autoconf Goal >Question to ADs and/or WG chairs - is this list being moderated or something? Yes, it is moderated. - Shubhranshu Fred -----Original Message----- From: Templin, Fred L Sent: Tuesday, October 10, 2006 9:56 AM To: 'Joe Macker'; 'Charles E. Perkins'; 'ext Ian Chakeres' Cc: autoconf@ietf.org Subject: RE: [Autoconf] "No" Subnet Model and Autoconf Goal > Viewing it as an unsubnetted local interface model with multiple > point-to-point neighbors works. I think this depends on the type of access technology. If broadcasts/multicasts sent over the access interface are received by multiple neighbors, then it isn't multiple point-to-point links - it is shared media link. A shared media link can be made to look like multiple point-to-point links if you use some sort of L2 partitioning like VLANs. But then, it wouldn't be mobility-agile. I don't want to keep plugging for my document, but maybe take a look at 'draft-templin-manet-autoconf-link'. Fred fred.l.templin@boeing.com _______________________________________________ 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 Tue Oct 17 00:50:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZgtl-00023V-FK; Tue, 17 Oct 2006 00:49:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZgtk-00023N-P4 for autoconf@ietf.org; Tue, 17 Oct 2006 00:49:52 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZgtj-0007GW-Ga for autoconf@ietf.org; Tue, 17 Oct 2006 00:49:52 -0400 Received: by nf-out-0910.google.com with SMTP id n15so161594nfc for ; Mon, 16 Oct 2006 21:49:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=R4mzGW64pjkw/NAfkBKUld0NxE/CvL39Trd0ciY9J/2wLt7cpJu8c3KBQ2I3INEZS7DbpLmKKF9T9DLTOJELTdNQXh8K9qYJpYVC73guS4TDbA7C8UagbyH3HhBH4iSCBgRVn0X0M+xcPJIZhOgY2LVnVSCnqzpnx0Y2jKQI0/U= Received: by 10.48.48.1 with SMTP id v1mr820674nfv; Mon, 16 Oct 2006 21:49:50 -0700 (PDT) Received: by 10.49.66.20 with HTTP; Mon, 16 Oct 2006 21:49:50 -0700 (PDT) Message-ID: Date: Tue, 17 Oct 2006 10:19:50 +0530 From: "Rohit Arul Raj" To: autoconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Autoconf] Checking dependency style 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 all, I was trying to build a package (m4 1.4.7) using two different cross compilers. one was GCC 4.1.1and other was non GNU compiler 3.4. My autoconf version is 2.6.0, automake is 1.9.6 one of the output of the configure was checking dependecy style. it gave gcc3 as result while building with GCC crosscompiler. while building with the non GNU compiler it gave 'none'. 1.Why do we check or under what condition do we have to check dependecy style? 2. Will it affect the performance of the compiler? 3. What are other dependency checks available other than gcc3? Thanking you in advance. Regards, Rohit _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Oct 17 07:08:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZmoQ-0006Of-Hh; Tue, 17 Oct 2006 07:08:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZmoP-0006Hr-BK for autoconf@ietf.org; Tue, 17 Oct 2006 07:08:45 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZmoO-0001b3-2Y for autoconf@ietf.org; Tue, 17 Oct 2006 07:08:45 -0400 Received: from did75-10-82-236-230-133.fbx.proxad.net ([82.236.230.133] helo=[192.168.147.201]) by outbound.mailhop.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.51) id 1GZmoN-000BRj-FJ; Tue, 17 Oct 2006 07:08:43 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 82.236.230.133 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: voop In-Reply-To: <015c01c6ed29$26e769e0$7c046c6b@sisodomain.com> References: <39C363776A4E8C4A94691D2BD9D1C9A10177438F@XCH-NW-7V2.nw.nos.boeing.com> <015c01c6ed29$26e769e0$7c046c6b@sisodomain.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Thomas Clausen Subject: Re: [Autoconf] "No" Subnet Model and Autoconf Goal Date: Tue, 17 Oct 2006 13:09:03 +0200 To: Shubhranshu X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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: , Errors-To: autoconf-bounces@ietf.org No, the list is not moderated. One must be subscribed to the list in order to post, but the postings are not moderated. --thomas On Oct 11, 2006, at 1:34 PM, Shubhranshu wrote: > Fred, > > ----- Original Message ----- From: "Templin, Fred L" > > To: "Joe Macker" ; "Charles E. Perkins" > ; "ext Ian Chakeres" > > Cc: > Sent: Tuesday, October 10, 2006 10:35 PM > Subject: RE: [Autoconf] "No" Subnet Model and Autoconf Goal > > >> Question to ADs and/or WG chairs - is this list being > moderated or something? > > Yes, it is moderated. > > - Shubhranshu > > Fred > > -----Original Message----- > From: Templin, Fred L > Sent: Tuesday, October 10, 2006 9:56 AM > To: 'Joe Macker'; 'Charles E. Perkins'; 'ext Ian Chakeres' > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] "No" Subnet Model and Autoconf Goal > >> Viewing it as an unsubnetted local interface model with multiple >> point-to-point neighbors works. > > I think this depends on the type of access technology. If > broadcasts/multicasts sent over the access interface are > received by multiple neighbors, then it isn't multiple > point-to-point links - it is shared media link. A shared > media link can be made to look like multiple point-to-point > links if you use some sort of L2 partitioning like VLANs. > But then, it wouldn't be mobility-agile. > > I don't want to keep plugging for my document, but maybe > take a look at 'draft-templin-manet-autoconf-link'. > > Fred > fred.l.templin@boeing.com > > _______________________________________________ > 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 > -- Thomas Clausen Thomas.Clausen@polytechnique.fr http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ http://www.lix.polytechnique.fr/hipercom/ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Oct 18 02:48:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga5E1-0005fz-BN; Wed, 18 Oct 2006 02:48:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga5E0-0005fu-Cz for autoconf@ietf.org; Wed, 18 Oct 2006 02:48:24 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga5Dx-0002pf-Vu for autoconf@ietf.org; Wed, 18 Oct 2006 02:48:24 -0400 Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J7B00FESK7BTV@mailout3.samsung.com> for autoconf@ietf.org; Wed, 18 Oct 2006 15:47:35 +0900 (KST) Received: from Shubhranshu ([107.108.4.124]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0J7B00FJIK79V1@mmp1.samsung.com> for autoconf@ietf.org; Wed, 18 Oct 2006 15:47:35 +0900 (KST) Date: Wed, 18 Oct 2006 12:20:19 +0530 From: Shubhranshu To: autoconf@ietf.org Message-id: <00bb01c6f281$adc8aa70$7c046c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Autoconf] IETF 67 Autoconf meeting agenda solicitation 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="===============1343124733==" Errors-To: autoconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1343124733== Content-type: multipart/alternative; boundary="Boundary_(ID_eZ1CNSd/Gm9PgoXgUY41VA)" This is a multi-part message in MIME format. --Boundary_(ID_eZ1CNSd/Gm9PgoXgUY41VA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT If you have any agenda item(s) for the upcoming Autoconf WG meeting then please send them to the chairs or list. Here is the scheduled session information: AUTOCONF Session 1 (2 hours) Monday, Afternoon Session III 1740-1950 Room Name: Nautilus 1 - Shubhranshu --Boundary_(ID_eZ1CNSd/Gm9PgoXgUY41VA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
 
If you have any agenda item(s) for the upcoming Autoconf WG meeting
then please send them to the chairs or list.
 
Here is the scheduled session information:
 
AUTOCONF Session 1 (2 hours)
Monday, Afternoon Session III 1740-1950
Room Name: Nautilus 1
 
- Shubhranshu
--Boundary_(ID_eZ1CNSd/Gm9PgoXgUY41VA)-- --===============1343124733== 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 --===============1343124733==-- From autoconf-bounces@ietf.org Tue Oct 24 20:36:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcWke-0007AQ-7w; Tue, 24 Oct 2006 20:36:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcWkc-0007A6-Fy for autoconf@ietf.org; Tue, 24 Oct 2006 20:36:10 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcWkX-0007QZ-2C for autoconf@ietf.org; Tue, 24 Oct 2006 20:36:10 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k9P0a12T000796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 24 Oct 2006 17:36:02 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k9P0a1hr029668 for ; Tue, 24 Oct 2006 19:36:01 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k9P0a1LH029648 for ; Tue, 24 Oct 2006 19:36:01 -0500 (CDT) Received: from XCH-NW-5V2.nw.nos.boeing.com ([130.247.55.45]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 17:36:01 -0700 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: Tue, 24 Oct 2006 17:35:25 -0700 Message-ID: <8BA40F9A33179E4E877E37D7D5E9D82D01FF661A@XCH-NW-5V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MANET subnet model Thread-Index: Acb3zXYw/4UymQs9SO6aR8eDuvHY8A== From: "Yi, Seung" To: X-OriginalArrivalTime: 25 Oct 2006 00:36:01.0088 (UTC) FILETIME=[8BB4DC00:01C6F7CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Subject: [Autoconf] MANET subnet model 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 all, Some of us at Boeing have been discussing about the MANET subnet model issue brought up in the list and came up with some idea we'd like to share. Following is a short description of our view. Please direct your comments and questions to the list so that we can continue the discussion. Thanks, - Seung ------------------------------------------------------------------------ ------------------------------------------------------------------------ -------------------------------------- IPv6 Subnet Model for MANETs In this text, we outline candidate models for assigning IPv6 addresses in a MANET. We organize our discussion by separately discussing the assignment of i) link-local addresses to a MANET interface, ii) non-link-local addresses to a MANET interface, and iii) non-link-local addresses to a MANET router's non-MANET interfaces. Definitions and terminology are borrowed from the MANET architecture I-D (draft-chakeres-manet-arch-01.txt).=20 Any two routers that can communicate via the underlying layer-2 technology without decrementing the Hop Count are said to be on the same link; under this definition, the links and on-link neighbors may be time-varying on a MANET. 1. Link-local addresses on MANET interfaces We assume that each MANET Router (MR) configures a link-local unicast address on its MANET interface. In standard IPv6 operation, a link-local address is generated without relying on external support per RFC2462 with interface identifiers configured from EUI-64 identifiers (RFC4291), Cryptographically Generated Addresses (CGAs- RFC3972), etc. A key challenge with link-local addresses is providing duplicate address detection (DAD). To satisfy the uniqueness on the link, the link-local address for a MR's MANET interface must be unique among all MANET interfaces on the link. However, assuming mobility the neighbor relationship of an MR may change over time. Since RFC 2462 (DAD) is performed only when the link-local address is configured, there is a chance that two nodes that were originally not on-link with respect to one another might configure the same link-local address. If this occurs and the two nodes then move into each other's transmission range, this situation would violate the on-link address uniqueness condition. This calls for extending the DAD functionality in three potential directions: a. Operational guarantees - Guarantee address uniqueness using out-of-band mechanisms. This may include providing a large-enough address space for a small number of nodes so that random address selection can be virtually collision-free, managed configuration of interface identifiers, etc. b. Pre-service DAD using Neighbor Discovery Proxies (RFC 4389) - Use ND proxies to propagate DAD messages across links with colliding addresses in the MANET. This technique is known to have conflicts with Secure Neighbor Discovery (SEND), but can be mitigated by "partial proxying" that covers only the DAD function. =20 =20 c. In-service DAD - Constantly monitor addresses of other nodes to detect any potential address conflict. When detected, the conflict must be resolved (mechanism to be specified). 2. Non-link-local addresses and prefixes MRs can configure non-link-local addresses and prefixes such as Unique Local Addresses (ULA), MANET Local Addresses (MLA) or globally routable IP addresses. Two concepts of operations include prefix assignment and prefix delegation. How to assign or acquire addresses/prefixes is out of scope of this discussion. 2.1 Assignment from prefix to a MANET interface With prefix assignment, multiple MRs each configures one or more addresses (and the addresses' associated prefix lengths) to their MANET interface. This case is distinct from prefix delegation in that in prefix assignment, the router does not own the whole prefix. One possible configuration is that each MR can assign addresses from the same prefix to a MANET interface so that interfaces on multiple MRs belong to the same subnet. This method is feasible only when all MANET nodes that configure addresses from the same prefix are operationally assured to be reachable in one IP hop on the same link. If all nodes within this prefix are not reachable in one IP hop on the same link, then a multi-link subnet exists [draft-iab-multilink-subnet-issues-00.txt]. Another possible configuration is for each MR to assign prefixes to a MANET interface so that no two MRs belong to a same subnet. MANET routing protocol behavior need not change since it will still inject appropriate routes to provide connectivity. The simplest case would be configuring MANET interfaces with an address with a /128 prefix length. However, an application might make an incorrect assumption; e.g., a host application might assume that the MANET interface is configured with a /64 instead of a /128. If a host makes this assumption, it could fail to connect with another node in the same subnet due to an incorrect on-link assumption. But, the IPv6 scenario should be no different than for IPv4 since IPv4 applications must honor CIDR prefix assignments on interfaces in order to avoid incorrect on-link assumptions. 2.2 Delegation from prefix to a non-MANET interface With prefix delegation, an MR acquires/chooses one or more prefixes for assignment to non-MANET interfaces and other downstream hosts on those links. For applications on the router itself that require a non-link-local address, a technique of delegating a small prefix to the router's loopback interface and having the router's applications bind to an address in that prefix has proven to be operationally useful. To an attached node, this set-up appears as a normal link where link-local scope addressing and on-link determination works as usual. Again, MANET routing protocol behavior does not change and the MR injects appropriate routes over its MANET interface to provide connectivity. 2.3 Combined model Prefix assignment and prefix delegation are not disjoint. An MR can both assign addresses from shared prefixes to its MANET interface and receive prefix delegations for assignment to non-MANET interfaces, but it should keep the prefixes for each operation disjoint. An MR should not use a same prefix for both assignment and delegation on different interfaces. 3. Prefix Aggregation Section 2 presents certain implications about prefix aggregation in MANETs. MANET border routers may be able to present the MANET as a whole to external entities by enforcing a common network prefix for the all the nodes inside the MANET. For instance, all of the addresses in the prefixes delegated to each MR may be aggregated. However, there is an operational risk to doing so if the MANET becomes partitioned. =20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Oct 26 02:39:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcyt9-0002iD-6z; Thu, 26 Oct 2006 02:38:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcyt7-0002ho-QF for autoconf@ietf.org; Thu, 26 Oct 2006 02:38:49 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcyt6-0000JF-AH for autoconf@ietf.org; Thu, 26 Oct 2006 02:38:49 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9Q6ZorW013502; Thu, 26 Oct 2006 09:38:40 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 09:38:38 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 01:38:35 -0500 Received: from [10.241.53.102] ([10.241.53.102]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 01:38:34 -0500 Message-ID: <454057E7.4020803@nokia.com> Date: Wed, 25 Oct 2006 23:38:31 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "ext Yi, Seung" Subject: Re: [Autoconf] MANET subnet model References: <8BA40F9A33179E4E877E37D7D5E9D82D01FF661A@XCH-NW-5V2.nw.nos.boeing.com> In-Reply-To: <8BA40F9A33179E4E877E37D7D5E9D82D01FF661A@XCH-NW-5V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2006 06:38:34.0638 (UTC) FILETIME=[5C3EEAE0:01C6F8C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: , Errors-To: autoconf-bounces@ietf.org Hello, I have a few comments on your text. ext Yi, Seung wrote: > Any two routers that can communicate via the underlying layer-2 > technology without decrementing the Hop Count are said to be on the same > link; under this definition, the links and on-link neighbors may be > time-varying on a MANET. > I think it would be better to make sure that any time a packet goes from one node to another distinct node the hop count is decremented. A router decrements the hop count before forwarding to a node on the same link. > 1. Link-local addresses on MANET interfaces > We assume that each MANET Router (MR) configures a link-local unicast > address on its MANET interface. I don't think this is necessary. It should be allowed, but not mandated. > 2. Non-link-local addresses and prefixes > MRs can configure non-link-local addresses and prefixes such as Unique > Local Addresses (ULA), MANET Local Addresses (MLA) or globally routable > IP addresses. Two concepts of operations include prefix assignment and > prefix delegation. How to assign or acquire addresses/prefixes is out > of scope of this discussion. > What exactly does it mean to say that acquiring addresses is out of scope? Regards, Charlie P. -- Please address return e-mail to charles.perkins@nokia.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sun Oct 29 17:15:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeIwO-0001XY-As; Sun, 29 Oct 2006 17:15:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeIwL-0001XT-Ov for autoconf@ietf.org; Sun, 29 Oct 2006 17:15:37 -0500 Received: from monet.knu.ac.kr ([155.230.29.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeIwK-00044s-5s for autoconf@ietf.org; Sun, 29 Oct 2006 17:15:37 -0500 Received: from choco ([155.230.29.237]) by monet.knu.ac.kr (8.13.1/8.13.1) with ESMTP id k9U6E0g4003552 for ; Mon, 30 Oct 2006 15:14:01 +0900 From: "Hong-Jong Jeong" To: Subject: FW: [Autoconf] duplicated MAC and IP addresses in one-hop neighbor Date: Mon, 30 Oct 2006 07:15:36 +0900 Message-ID: <000501c6fba7$c25a0ef0$ed1de69b@choco> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acb7pZOp3Cs0IMJCRYqsIwyZTYpAEAAAhn7A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.2 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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="===============1322716790==" Errors-To: autoconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1322716790== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C6FBF3.3241B6F0" This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C6FBF3.3241B6F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, I'm finding solutions of this problem. The problem is as follows. There are two or more nodes which are in transmission range each other. Their wireless interfaces have same MAC address and IP address. Then, how can they detect this situation and duplicate addresses? Hong-Jong Jeong ------=_NextPart_000_0006_01C6FBF3.3241B6F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi = all,

I’m finding solutions of this = problem.

The problem is as = follows.

There are two or more nodes = which are in transmission range each other.

Their wireless interfaces = have same MAC address and IP address.

Then, how can they detect = this situation and duplicate addresses?

 

Hong-Jong = Jeong

 

------=_NextPart_000_0006_01C6FBF3.3241B6F0-- --===============1322716790== 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 --===============1322716790==-- From autoconf-bounces@ietf.org Mon Oct 30 07:36:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeWNc-0004Ob-O7; Mon, 30 Oct 2006 07:36:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeWNb-0004OV-QH for autoconf@ietf.org; Mon, 30 Oct 2006 07:36:39 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeWNa-0006fe-TG for autoconf@ietf.org; Mon, 30 Oct 2006 07:36:39 -0500 Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J7Y00IIX8CWFD@mailout3.samsung.com> for autoconf@ietf.org; Mon, 30 Oct 2006 21:36:32 +0900 (KST) Received: from Shubhranshu ([107.108.4.124]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0J7Y00HPP8CUQR@mmp2.samsung.com> for autoconf@ietf.org; Mon, 30 Oct 2006 21:36:32 +0900 (KST) Date: Mon, 30 Oct 2006 18:09:26 +0530 From: Shubhranshu Subject: Re: [Autoconf] MANET subnet model To: "Yi, Seung" Message-id: <012e01c6fc20$70430030$1b0510ac@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c 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="===============1598736503==" Errors-To: autoconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1598736503== Content-type: multipart/alternative; boundary="Boundary_(ID_OPEExFkAjkf9mPL/n2KbrA)" This is a multi-part message in MIME format. --Boundary_(ID_OPEExFkAjkf9mPL/n2KbrA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hello Seung, Please find a few inline comments. > To: > Subject: MANET subnet model > From: "Yi, Seung" > IPv6 Subnet Model for MANETs > > A key challenge with link-local addresses is providing duplicate address > detection (DAD). To satisfy the uniqueness on the link, the link-local > address for a MR's MANET interface must be unique among all MANET > interfaces on the link. However, assuming mobility the neighbor > relationship of an MR may change over time. Since RFC 2462 (DAD) is > performed only when the link-local address is configured, there is a > chance that two nodes that were originally not on-link with respect to > one another might configure the same link-local address. If this occurs > and the two nodes then move into each other's transmission range, this > situation would violate the on-link address uniqueness condition. Considering these complicacies and overhead involved in maintaining uniqueness of the link local address, do you suggest that manet node be allowed to have flexibility to configure only MANET local address (and optionally global addresses) ? > 2. Non-link-local addresses and prefixes > MRs can configure non-link-local addresses and prefixes such as Unique > Local Addresses (ULA), MANET Local Addresses (MLA) or globally routable > IP addresses. sounds like you are assuming ULA and MLA as different addresses. IMO ULA can be used as Manet local address. > One possible configuration is that each MR can assign addresses from the > same prefix to a MANET interface so that interfaces on multiple MRs > belong to the same subnet. This method is feasible only when all MANET > nodes that configure addresses from the same prefix are operationally > assured to be reachable in one IP hop on the same link. that would be hard to assure considering the dynamicity of manet topology and hence this method will mostly result in all those issues discussed in draft-iab-multilink-subnet-issues. > > Another possible configuration is for each MR to assign prefixes to a > MANET interface so that no two MRs belong to a same subnet. MANET > routing protocol behavior need not change since it will still inject > appropriate routes to provide connectivity. this sounds fine and better way of doing things compared to the previous one provided we can assign appropriate prefixes. This approach would avoid most of the issues due to the assumptions related with TTL value. -- Shubhranshu The simplest case would be > configuring MANET interfaces with an address with a /128 prefix length. > However, an application might make an incorrect assumption; e.g., a host > application might assume that the MANET interface is configured with a > /64 instead of a /128. If a host makes this assumption, it could fail to > connect with another node in the same subnet due to an incorrect on-link > assumption. But, the IPv6 scenario should be no different than for IPv4 > since IPv4 applications must honor CIDR prefix assignments on interfaces > in order to avoid incorrect on-link assumptions. > > 2.2 Delegation from prefix to a non-MANET interface > With prefix delegation, an MR acquires/chooses one or more prefixes for > assignment to non-MANET interfaces and other downstream hosts on those > links. For applications on the router itself that require a > non-link-local address, a technique of delegating a small prefix to the > router's loopback interface and having the router's applications bind to > an address in that prefix has proven to be operationally useful. To an > attached node, this set-up appears as a normal link where link-local > scope addressing and on-link determination works as usual. Again, MANET > routing protocol behavior does not change and the MR injects appropriate > routes over its MANET interface to provide connectivity. > > 2.3 Combined model > Prefix assignment and prefix delegation are not disjoint. An MR can > both assign addresses from shared prefixes to its MANET interface and > receive prefix delegations for assignment to non-MANET interfaces, but > it should keep the prefixes for each operation disjoint. An MR should > not use a same prefix for both assignment and delegation on different > interfaces. > > 3. Prefix Aggregation > Section 2 presents certain implications about prefix aggregation in > MANETs. MANET border routers may be able to present the MANET as a > whole to external entities by enforcing a common network prefix for the > all the nodes inside the MANET. For instance, all of the addresses in > the prefixes delegated to each MR may be aggregated. However, there is > an operational risk to doing so if the MANET becomes partitioned. > --Boundary_(ID_OPEExFkAjkf9mPL/n2KbrA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hello Seung,
 
Please find a few inline comments.
 
> To: <autoconf at ietf.org>
> Subject: MANET subnet model
> From: "Yi, Seung" <Seung.Yi at boeing.com>
> IPv6 Subnet Model for MANETs
<snip>
>
> A key challenge with link-local addresses is providing duplicate address
> detection (DAD).  To satisfy the uniqueness on the link, the link-local
> address for a MR's MANET interface must be unique among all MANET
> interfaces on the link.  However, assuming mobility the neighbor
> relationship of an MR may change over time.  Since RFC 2462 (DAD) is
> performed only when the link-local address is configured, there is a
> chance that two nodes that were originally not on-link with respect to
> one another might configure the same link-local address.  If this occurs
> and the two nodes then move into each other's transmission range, this
> situation would violate the on-link address uniqueness condition.
 
Considering these complicacies and overhead involved in maintaining uniqueness
of the link local address, do you suggest that manet node be allowed to have
flexibility to configure only MANET local address (and optionally global addresses) ?
 

> 2.  Non-link-local addresses and prefixes
> MRs can configure non-link-local addresses and prefixes such as Unique
> Local Addresses (ULA), MANET Local Addresses (MLA) or globally routable
> IP addresses.
 
sounds like you are assuming ULA and MLA as different addresses. IMO
ULA can be used as Manet local address.
 

> One possible configuration is that each MR can assign addresses from the
> same prefix to a MANET interface so that interfaces on multiple MRs
> belong to the same subnet. This method is feasible only when all MANET
> nodes that configure addresses from the same prefix are operationally
> assured to be reachable in one IP hop on the same link.
 
that would be hard to assure considering the dynamicity of manet topology and
hence this method will mostly result in all those issues discussed in
draft-iab-multilink-subnet-issues.
 
>
> Another possible configuration is for each MR to assign prefixes to a
> MANET interface so that no two MRs belong to a same subnet.  MANET
> routing protocol behavior need not change since it will still inject
> appropriate routes to provide connectivity. 
 
this sounds fine and better way of doing things compared to the previous one
provided we can assign appropriate prefixes. This approach would avoid most of
the issues due to the assumptions related with TTL value. 
 
-- Shubhranshu
 
The simplest case would be
> configuring MANET interfaces with an address with a /128 prefix length.
> However, an application might make an incorrect assumption; e.g., a host
> application might assume that the MANET interface is configured with a
> /64 instead of a /128. If a host makes this assumption, it could fail to
> connect with another node in the same subnet due to an incorrect on-link
> assumption. But, the IPv6 scenario should be no different than for IPv4
> since IPv4 applications must honor CIDR prefix assignments on interfaces
> in order to avoid incorrect on-link assumptions.
>
> 2.2   Delegation from prefix to a non-MANET interface
> With prefix delegation, an MR acquires/chooses one or more prefixes for
> assignment to non-MANET interfaces and other downstream hosts on those
> links.  For applications on the router itself that require a
> non-link-local address, a technique of delegating a small prefix to the
> router's loopback interface and having the router's applications bind to
> an address in that prefix has proven to be operationally useful.  To an
> attached node, this set-up appears as a normal link where link-local
> scope addressing and on-link determination works as usual. Again, MANET
> routing protocol behavior does not change and the MR injects appropriate
> routes over its MANET interface to provide connectivity.
>
> 2.3 Combined model
> Prefix assignment and prefix delegation are not disjoint.  An MR can
> both assign addresses from shared prefixes to its MANET interface and
> receive prefix delegations for assignment to non-MANET interfaces, but
> it should keep the prefixes for each operation disjoint.  An MR should
> not use a same prefix for both assignment and delegation on different
> interfaces.
>
> 3.  Prefix Aggregation
> Section 2 presents certain implications about prefix aggregation in
> MANETs.  MANET border routers may be able to present the MANET as a
> whole to external entities by enforcing a common network prefix for the
> all the nodes inside the MANET. For instance, all of the addresses in
> the prefixes delegated to each MR may be aggregated.  However, there is
> an operational risk to doing so if the MANET becomes partitioned.
>
--Boundary_(ID_OPEExFkAjkf9mPL/n2KbrA)-- --===============1598736503== 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 --===============1598736503==-- From autoconf-bounces@ietf.org Mon Oct 30 08:22:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeX6B-0000ZJ-M7; Mon, 30 Oct 2006 08:22:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeX6A-0000Z3-HX for autoconf@ietf.org; Mon, 30 Oct 2006 08:22:42 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeX68-00053m-8l for autoconf@ietf.org; Mon, 30 Oct 2006 08:22:42 -0500 Received: from ep_mmp2 (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 <0J7Y007B1AHOGR@mailout2.samsung.com> for autoconf@ietf.org; Mon, 30 Oct 2006 22:22:36 +0900 (KST) Received: from Shubhranshu ([107.108.4.124]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0J7Y00I6PAHNLX@mmp2.samsung.com> for autoconf@ietf.org; Mon, 30 Oct 2006 22:22:36 +0900 (KST) Date: Mon, 30 Oct 2006 18:55:27 +0530 From: Shubhranshu Subject: Re: [Autoconf] IETF 67 Autoconf meeting agenda solicitation To: autoconf@ietf.org Message-id: <016901c6fc26$de120ec0$1b0510ac@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-Priority: 3 X-MSMail-priority: Normal References: <00bb01c6f281$adc8aa70$7c046c6b@sisodomain.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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="===============1510020404==" Errors-To: autoconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1510020404== Content-type: multipart/alternative; boundary="Boundary_(ID_b0fipVPEy8+3AmadOAFPlw)" This is a multi-part message in MIME format. --Boundary_(ID_b0fipVPEy8+3AmadOAFPlw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT One of the Autoconf WG milestone is in Mar 2007: Mar 2007 Submit initial I-D of 'IPv6 address autoconfiguration mechanism' for WG review So, if you have any presentation on your solution space ID then please send them too. It would still be possible to accommodate a couple of short presentations in the WG meeting agenda. -- Shubhranshu ----- Original Message ----- From: Shubhranshu To: autoconf@ietf.org Sent: Wednesday, October 18, 2006 12:20 PM Subject: [Autoconf] IETF 67 Autoconf meeting agenda solicitation If you have any agenda item(s) for the upcoming Autoconf WG meeting then please send them to the chairs or list. Here is the scheduled session information: AUTOCONF Session 1 (2 hours) Monday, Afternoon Session III 1740-1950 Room Name: Nautilus 1 - Shubhranshu ------------------------------------------------------------------------------ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf --Boundary_(ID_b0fipVPEy8+3AmadOAFPlw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
One of the Autoconf WG milestone is in Mar 2007:
 
Mar 2007    Submit initial I-D of 'IPv6 address autoconfiguration mechanism' for WG review 
 
So, if you have any presentation on your solution space ID then please send them too.
It would still be possible to accommodate a couple of short presentations in the WG meeting agenda.
 
-- Shubhranshu
 
 
 ----- Original Message -----
Sent: Wednesday, October 18, 2006 12:20 PM
Subject: [Autoconf] IETF 67 Autoconf meeting agenda solicitation

 
If you have any agenda item(s) for the upcoming Autoconf WG meeting
then please send them to the chairs or list.
 
Here is the scheduled session information:
 
AUTOCONF Session 1 (2 hours)
Monday, Afternoon Session III 1740-1950
Room Name: Nautilus 1
 
- Shubhranshu

_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www1.ietf.org/mailman/listinfo/autoconf
--Boundary_(ID_b0fipVPEy8+3AmadOAFPlw)-- --===============1510020404== 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 --===============1510020404==-- From autoconf-bounces@ietf.org Mon Oct 30 13:44:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gec7l-0007Ig-NW; Mon, 30 Oct 2006 13:44:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gec7c-0007Gk-K8 for autoconf@ietf.org; Mon, 30 Oct 2006 13:44:32 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gec74-0001i6-2C for autoconf@ietf.org; Mon, 30 Oct 2006 13:44:01 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k9UIhu0S006662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 30 Oct 2006 10:43:57 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k9UIhu9q017860 for ; Mon, 30 Oct 2006 12:43:56 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k9UIhLIw016307; Mon, 30 Oct 2006 12:43:23 -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); Mon, 30 Oct 2006 10:43:22 -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] MANET subnet model Date: Mon, 30 Oct 2006 10:43:20 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177440E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <012e01c6fc20$70430030$1b0510ac@sisodomain.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] MANET subnet model Thread-Index: Acb8ICZR3NAHN3FhRGmupmVt9KtzXAALuijw From: "Templin, Fred L" To: "Shubhranshu" , "Yi, Seung" X-OriginalArrivalTime: 30 Oct 2006 18:43:22.0115 (UTC) FILETIME=[46744D30:01C6FC53] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Errors-To: autoconf-bounces@ietf.org Hi Shubhranshu, >> One possible configuration is that each MR can assign addresses from the >> same prefix to a MANET interface so that interfaces on multiple MRs >> belong to the same subnet. This method is feasible only when all MANET >> nodes that configure addresses from the same prefix are operationally >> assured to be reachable in one IP hop on the same link. >=20 > that would be hard to assure considering the dynamicity of manet topology and=20 > hence this method will mostly result in all those issues discussed in=20 > draft-iab-multilink-subnet-issues. This may depend on the particular access link technology and/or deployment scenario. True, the most widely-anticipated scenario seems to be for mobile wireless techonolgies with dynamically- changing topologies; this also seems to be well-articulated (in RFC2501, Section 3.) But, could a MANET also entail, e.g., nodes permanently attached to a common Ethernet cable or even wireless nodes that are somehow operationally assured to remain as one-hop neighbors even as they move about? If so, couldn't it be possible to configure a shared on-link prefix on MANET interfaces in such scenarios without it becoming a multilink subnet? Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Oct 30 14:10:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GecWt-0006zi-1h; Mon, 30 Oct 2006 14:10:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GecWs-0006zd-7q for autoconf@ietf.org; Mon, 30 Oct 2006 14:10:38 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GecWn-0005aJ-1O for autoconf@ietf.org; Mon, 30 Oct 2006 14:10:38 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id k9UJAWjE000777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 30 Oct 2006 13:10:32 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k9UJA1UY004614 for ; Mon, 30 Oct 2006 11:10:31 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k9UJ1niP007486; Mon, 30 Oct 2006 11:01:49 -0800 (PST) Received: from XCH-NW-5V2.nw.nos.boeing.com ([130.247.55.45]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 11:01:49 -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] MANET subnet model Date: Mon, 30 Oct 2006 11:01:45 -0800 Message-ID: <8BA40F9A33179E4E877E37D7D5E9D82D02132C29@XCH-NW-5V2.nw.nos.boeing.com> In-Reply-To: <454057E7.4020803@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] MANET subnet model Thread-Index: Acb4yWTPRHORWvNKQqyJ3AghSxnbpwDjBUMg From: "Yi, Seung" To: "Charles E. Perkins" X-OriginalArrivalTime: 30 Oct 2006 19:01:49.0221 (UTC) FILETIME=[DA574550:01C6FC55] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Errors-To: autoconf-bounces@ietf.org Charlie, I believe Fred answered question 1. For question 2, I tried to convey that a subnet model is not tied to any particular address management mechanism. We may use one or some of existing mechanisms such as DHCP or we can invent a completely new mechanism/protocol for MANET. Regards, - Seung -----Original Message----- From: Charles E. Perkins [mailto:charles.perkins@nokia.com]=20 Sent: Wednesday, October 25, 2006 11:39 PM To: Yi, Seung Cc: autoconf@ietf.org Subject: Re: [Autoconf] MANET subnet model > 2. Non-link-local addresses and prefixes MRs can configure=20 > non-link-local addresses and prefixes such as Unique Local Addresses=20 > (ULA), MANET Local Addresses (MLA) or globally routable IP addresses. > Two concepts of operations include prefix assignment and > prefix delegation. How to assign or acquire addresses/prefixes is out > of scope of this discussion. > =20 What exactly does it mean to say that acquiring addresses is out of scope? Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Oct 30 15:22:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gedda-0003D2-Qi; Mon, 30 Oct 2006 15:21:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeddZ-0003CG-Mt for autoconf@ietf.org; Mon, 30 Oct 2006 15:21:37 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeddV-0003u4-6N for autoconf@ietf.org; Mon, 30 Oct 2006 15:21:37 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9UKLN3p013659; Mon, 30 Oct 2006 22:21:27 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 22:21:26 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 14:20:49 -0600 Received: from [10.241.174.88] ([10.241.174.88]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 14:20:48 -0600 Message-ID: <45465E9D.5040000@nokia.com> Date: Mon, 30 Oct 2006 12:20:45 -0800 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "ext Templin, Fred L" Subject: Re: [Autoconf] MANET subnet model References: <39C363776A4E8C4A94691D2BD9D1C9A10177440E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10177440E@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2006 20:20:48.0569 (UTC) FILETIME=[E3366290:01C6FC60] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061030222127-311B2BB0-4C1AE558/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: autoconf@ietf.org, "Yi, Seung" 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 Hello Fred, ext Templin, Fred L wrote: > But, could a MANET also entail, e.g., nodes permanently attached > to a common Ethernet cable or even wireless nodes that are somehow > operationally assured to remain as one-hop neighbors even as they > move about? If so, couldn't it be possible to configure a shared > on-link prefix on MANET interfaces in such scenarios without it > becoming a multilink subnet? > I would certainly agree that it should be possible. The role of the subnet leader in AODV was to perform exactly this function of sharing a subnet prefix with every node on the subnet, without it being a multilink subnet. We worked this out in quite some detail, to the point of being careful about which ICMP messages needed to be sent. This is also supported in DYMO (section 5.7) and, presumably, OLSR but I did not verify the latter. In fact, I think the internal structure of the subnet is nobody's business, as long as the external interface (of a router that offers connectivity to every live node in the subnet) is maintained. Regards, Charlie P. -- Please address return e-mail to charles.perkins@nokia.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Oct 30 17:59:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geg5q-0004Nl-Tb; Mon, 30 Oct 2006 17:58:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geg5p-0004NR-MT for autoconf@ietf.org; Mon, 30 Oct 2006 17:58:57 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geg5X-0008Ta-8k for autoconf@ietf.org; Mon, 30 Oct 2006 17:58:57 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id k9UMwavl011942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 30 Oct 2006 14:58:36 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k9UMwark009181 for ; Mon, 30 Oct 2006 14:58:36 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k9UMwSEh008923; Mon, 30 Oct 2006 14:58:35 -0800 (PST) Received: from XCH-NW-5V2.nw.nos.boeing.com ([130.247.55.45]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 14:58:31 -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] MANET subnet model Date: Mon, 30 Oct 2006 14:58:29 -0800 Message-ID: <8BA40F9A33179E4E877E37D7D5E9D82D02132CAF@XCH-NW-5V2.nw.nos.boeing.com> In-Reply-To: <012e01c6fc20$70430030$1b0510ac@sisodomain.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] MANET subnet model Thread-Index: Acb8IA5JiFDDLwBzRL2vZ+pBHj2IygAVWmTw X-Priority: 5 Priority: Non-Urgent Importance: low From: "Yi, Seung" To: "Shubhranshu" X-OriginalArrivalTime: 30 Oct 2006 22:58:31.0366 (UTC) FILETIME=[EB7A9E60:01C6FC76] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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: , Errors-To: autoconf-bounces@ietf.org Hi, Shubhranshu, Comments inline.=20 ________________________________ >> >>=20 >> A key challenge with link-local addresses is providing duplicate address >> detection (DAD). To satisfy the uniqueness on the link, the link-local >> address for a MR's MANET interface must be unique among all MANET >> interfaces on the link. However, assuming mobility the neighbor >> relationship of an MR may change over time. Since RFC 2462 (DAD) is >> performed only when the link-local address is configured, there is a >> chance that two nodes that were originally not on-link with respect to >> one another might configure the same link-local address. If this occurs >> and the two nodes then move into each other's transmission range, this >> situation would violate the on-link address uniqueness condition.=20 >=20 >Considering these complicacies and overhead involved in maintaining uniqueness >of the link local address, do you suggest that manet node be allowed to have=20 >Flexibility to configure only MANET local address (and optionally global addresses) ? =20 Fred pointed out that a MANET router seems to be required to configured link-local address too per RFC2461(bis). However I don't see any architectural reason why one cannot go with MANET-local addresses only. >> 2. Non-link-local addresses and prefixes >> MRs can configure non-link-local addresses and prefixes such as Unique >> Local Addresses (ULA), MANET Local Addresses (MLA) or globally routable >> IP addresses.=20 >=20 >sounds like you are assuming ULA and MLA as different addresses. IMO=20 >ULA can be used as Manet local address.=20 =20 Agreed. I was referring to ULA as in RFC4193 and MLA as in draft-jelger-autoconf-mla-01.txt. They are indeed quite similar. As long as it serves as a unique identifier within MANET, it should do. >> One possible configuration is that each MR can assign addresses from the >> same prefix to a MANET interface so that interfaces on multiple MRs >> belong to the same subnet. This method is feasible only when all MANET >> nodes that configure addresses from the same prefix are operationally >> assured to be reachable in one IP hop on the same link. >=20 >That would be hard to assure considering the dynamicity of manet topology and=20 >hence this method will mostly result in all those issues discussed in=20 >draft-iab-multilink-subnet-issues. =20 Fred's reply seems reasonable to me. >>=20 >> Another possible configuration is for each MR to assign prefixes to a >> MANET interface so that no two MRs belong to a same subnet. MANET >> routing protocol behavior need not change since it will still inject >> appropriate routes to provide connectivity. =20 >=20 >This sounds fine and better way of doing things compared to the previous one=20 >provided we can assign appropriate prefixes. This approach would avoid most of=20 >the issues due to the assumptions related with TTL value. =20 =20 I agree. Again, I'm leaning toward a design that eliminates the headaches of multilink subnet. However, I'm not yet fully convinced that the first choice (resulting in multilink subnet) is completely without merit. Any opinions? Thanks, - Seung _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Oct 31 08:45:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Getv9-0001Xq-Dj; Tue, 31 Oct 2006 08:44:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Getv6-0001Wp-9Q for autoconf@ietf.org; Tue, 31 Oct 2006 08:44:48 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Getv0-0007ov-Q0 for autoconf@ietf.org; Tue, 31 Oct 2006 08:44:48 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 91A4D89806; Tue, 31 Oct 2006 15:44:41 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6033389801; Tue, 31 Oct 2006 15:44:39 +0200 (EET) Message-ID: <45475349.1050304@piuha.net> Date: Tue, 31 Oct 2006 15:44:41 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: "Yi, Seung" Subject: Re: [Autoconf] MANET subnet model References: <8BA40F9A33179E4E877E37D7D5E9D82D02132CAF@XCH-NW-5V2.nw.nos.boeing.com> In-Reply-To: <8BA40F9A33179E4E877E37D7D5E9D82D02132CAF@XCH-NW-5V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: autoconf-bounces@ietf.org >>> Another possible configuration is for each MR to assign prefixes to a >>> MANET interface so that no two MRs belong to a same subnet. MANET >>> routing protocol behavior need not change since it will still inject >>> appropriate routes to provide connectivity. >>> >> This sounds fine and better way of doing things compared to the >> > previous one > >> provided we can assign appropriate prefixes. This approach would avoid >> > most of > >> the issues due to the assumptions related with TTL value. >> > > I agree. Again, I'm leaning toward a design that eliminates the > headaches of multilink subnet. However, I'm not yet fully convinced that > the first choice (resulting in multilink subnet) is completely without > merit. Any opinions? > If it is the case that you have a well understood approach that avoids the multilink subnet issues you should go for that. You have a complicated enough problem in your hands even without having to support multiple ways to do things. If you have a solution that works and has no major drawbacks, standardize that. --Jari _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Oct 31 11:39:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gewdl-0006mX-5I; Tue, 31 Oct 2006 11:39:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gewdh-0006iq-TV for autoconf@ietf.org; Tue, 31 Oct 2006 11:39:01 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GewdW-0002U1-7S for autoconf@ietf.org; Tue, 31 Oct 2006 11:39:01 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k9VGciR4026595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 31 Oct 2006 08:38:49 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k9VGchYK003991 for ; Tue, 31 Oct 2006 10:38:43 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k9VGcUd5003353; Tue, 31 Oct 2006 10:38:37 -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); Tue, 31 Oct 2006 08:38:37 -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] MANET subnet model Date: Tue, 31 Oct 2006 08:38:36 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774417@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <45475349.1050304@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] MANET subnet model Thread-Index: Acb88vAdFAfs5i6qSvaUpwAh6WpynQAELSyg From: "Templin, Fred L" To: "Jari Arkko" , "Yi, Seung" X-OriginalArrivalTime: 31 Oct 2006 16:38:37.0451 (UTC) FILETIME=[03A8F5B0:01C6FD0B] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: , Errors-To: autoconf-bounces@ietf.org Jari, > If it is the case that you have a well understood approach > that avoids the multilink subnet issues you should go for > that. You have a complicated enough problem in your > hands even without having to support multiple ways to > do things. If you have a solution that works and has no > major drawbacks, standardize that. Can you clarify what you mean by this? I believe Seung's post is essentially listing the following options for prefix assignment to MANET interfaces: 1) shared prefix for both address configuration and on-link determination (i.e., prefix length shorter than 128) - requires that all MANET interfaces that assign the prefix and configure addresses from the prefix be attached to the same link always and run DAD on the link 2) shared prefix for address configuration but not on-link determination (i.e., prefix length =3D 128) - requires MANET-wide proxy-DAD in case multiple MANET interfaces configure duplicate addresses, but does not require attachment to same link 3) unique prefix for each MANET interface - DAD avoidance through operational assurance against duplication 4) link-local-only - requires MANET-wide proxy-DAD in case multiple MANET interfaces that configure the same link-local address might move onto the same link at some point in time. There would seem to be potential use-cases for all of these options, so why do you say "pick one" when it seems like all may have their appropriate use-cases? Note 1: option 4) also needs to be considered along with options 1) thru 3) since all MANET interfaces must configure a link-local address. Note 2: DAD can be avoided through operational assurance against duplication in all cases, but that would tend to negate SEND. Thanks - Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Oct 31 12:09:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gex7a-0001ex-Q2; Tue, 31 Oct 2006 12:09:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gex7W-0001eQ-RV for autoconf@ietf.org; Tue, 31 Oct 2006 12:09:51 -0500 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gex7Q-0000LU-T4 for autoconf@ietf.org; Tue, 31 Oct 2006 12:09:50 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id k9VH9beE004476; Tue, 31 Oct 2006 12:09:37 -0500 (EST) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2006103112102803997 ; Tue, 31 Oct 2006 12:10:28 -0500 From: "Joe Macker" To: "'Templin, Fred L'" , "'Jari Arkko'" , "'Yi, Seung'" Subject: RE: [Autoconf] MANET subnet model Date: Tue, 31 Oct 2006 12:09:33 -0500 Message-ID: <007401c6fd0f$5646dfe0$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.2962 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774417@XCH-NW-7V2.nw.nos.boeing.com> Thread-Index: Acb88vAdFAfs5i6qSvaUpwAh6WpynQAELSygAAIuJgA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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: , Errors-To: autoconf-bounces@ietf.org Fred: It's a good idea to enumerate prefix assignment cases to help scope the work. Do we really need to REQUIRE multi-hop DAD for all deployments? Having mechanisms TO SUPPORT IT defined is ok, but requiring it is not IMHO. So can we talk about prefix assignment cases without DAD off-link issues for now. Just a thought. -joe >-----Original Message----- >From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] >Sent: Tuesday, October 31, 2006 11:39 AM >To: Jari Arkko; Yi, Seung >Cc: autoconf@ietf.org >Subject: RE: [Autoconf] MANET subnet model > >Jari, > >> If it is the case that you have a well understood approach >that avoids >> the multilink subnet issues you should go for that. You have a >> complicated enough problem in your hands even without having to >> support multiple ways to do things. If you have a solution >that works >> and has no major drawbacks, standardize that. > >Can you clarify what you mean by this? I believe Seung's post >is essentially listing the following options for prefix >assignment to MANET interfaces: > > 1) shared prefix for both address configuration and on-link > determination (i.e., prefix length shorter than 128) - > requires that all MANET interfaces that assign the prefix > and configure addresses from the prefix be attached to > the same link always and run DAD on the link > 2) shared prefix for address configuration but not on-link > determination (i.e., prefix length = 128) - requires > MANET-wide proxy-DAD in case multiple MANET interfaces > configure duplicate addresses, but does not require > attachment to same link > 3) unique prefix for each MANET interface - DAD avoidance > through operational assurance against duplication > 4) link-local-only - requires MANET-wide proxy-DAD in case > multiple MANET interfaces that configure the same link-local > address might move onto the same link at some point in time. > >There would seem to be potential use-cases for all of these >options, so why do you say "pick one" when it seems like all >may have their appropriate use-cases? > >Note 1: option 4) also needs to be considered along with > options 1) thru 3) since all MANET interfaces must > configure a link-local address. >Note 2: DAD can be avoided through operational assurance > against duplication in all cases, but that would > tend to negate SEND. > >Thanks - Fred >fred.l.templin@boeing.com > >_______________________________________________ >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 Tue Oct 31 13:17:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeyAQ-0000a8-SH; Tue, 31 Oct 2006 13:16:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeyAP-0000SD-4O for autoconf@ietf.org; Tue, 31 Oct 2006 13:16:53 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeyAI-0006Se-PK for autoconf@ietf.org; Tue, 31 Oct 2006 13:16:53 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k9VIGjeQ029289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 31 Oct 2006 10:16:46 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k9VIGjXu016977 for ; Tue, 31 Oct 2006 10:16:45 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k9VIGfHa016806; Tue, 31 Oct 2006 10:16:44 -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); Tue, 31 Oct 2006 10:16:42 -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] MANET subnet model Date: Tue, 31 Oct 2006 10:16:42 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177441A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <007401c6fd0f$5646dfe0$165cfa84@SEXTANT> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] MANET subnet model Thread-Index: Acb88vAdFAfs5i6qSvaUpwAh6WpynQAELSygAAIuJgAAAjj8sA== From: "Templin, Fred L" To: "Joe Macker" , "Jari Arkko" , "Yi, Seung" X-OriginalArrivalTime: 31 Oct 2006 18:16:42.0722 (UTC) FILETIME=[B78E0C20:01C6FD18] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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: , Errors-To: autoconf-bounces@ietf.org Joe and Jari, > It's a good idea to enumerate prefix assignment cases to help scope the > work. OK. > Do we really need to REQUIRE multi-hop DAD for all deployments? Only for deployments that want to use self-generated addresses like SEND/CGA that have non-negligible probability of collision. Because if two MRs configure the same non-link-local address on their MANET interface communications might fail. (Same is true if two MRs configure the same link-local address and move onto the same link at some point in time.) > Having mechanisms TO SUPPORT IT defined is ok, but requiring it > is not IMHO. DAD avoidance through operational assurance against address duplication (e.g., interface identifier assignment by a central authority) is certainly an option, but self-generated addresses like SEND/CGA can collide so you would need proxy-DAD for that.=20 > So can we talk about prefix assignment cases without DAD off-link > issues for now. Just a thought. James Kempf indicated that Jari Arkko and Dave Thaler have had previous discussions about proxy-DAD and implied that there may be barriers to its adoption: =20 http://www1.ietf.org/mail-archive/web/netlmm/current/msg00850.html http://www1.ietf.org/mail-archive/web/netlmm/current/msg00860.html Jari, I'd appreciate if you could shed some light on those prior discussions on the list. Thanks - Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf