From nemo-admin@ietf.org Fri Aug 1 00:20:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25812 for ; Fri, 1 Aug 2003 00:20:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iRNc-0004Dy-Ra; Fri, 01 Aug 2003 00:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iRNB-0004Dg-2p for nemo@optimus.ietf.org; Fri, 01 Aug 2003 00:18:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25796 for ; Fri, 1 Aug 2003 00:18:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iRN8-0002Au-00 for nemo@ietf.org; Fri, 01 Aug 2003 00:18:30 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19iRN7-0002Am-00 for nemo@ietf.org; Fri, 01 Aug 2003 00:18:30 -0400 Received: from huez (unknown [203.178.138.11]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 4A95C5D019; Fri, 1 Aug 2003 13:17:59 +0900 (JST) Date: Fri, 1 Aug 2003 13:09:50 +0900 From: Thierry Ernst To: nemo@ietf.org Cc: tj@kniveton.com Subject: Re: [nemo] Missing minutes Message-Id: <20030801130950.6b6db0d3.ernst@sfc.wide.ad.jp> In-Reply-To: <20030730181821.1c7db2b2.ernst@sfc.wide.ad.jp> References: <20030730181821.1c7db2b2.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all, I didn't get any reply, if nobody send me some notes, we cannot complete the minutes. Thanks for the interest of the group. Thierry > Our minutes-taker went out of battery during the NEMO meeting. As a > result, part of his notes are corrupted. > > So, is there anyone out there who could provide his notes for the first > 4 parts below so that we can merge and publish ? > > 1) Agenda Bashing - Chairs > 2) NEMO status and milestones - Chairs > 3) NEMO Basic Support - Ryuji Wakikawa > 4) Multihoming > > This would be highly appreciated. The most important is questions and > answers. > > Thanks in advance, > Thierry. From exim@www1.ietf.org Fri Aug 1 00:20:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25827 for ; Fri, 1 Aug 2003 00:20:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iROX-0004IK-DM for nemo-archive@odin.ietf.org; Fri, 01 Aug 2003 00:19:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h714JvoH016502 for nemo-archive@odin.ietf.org; Fri, 1 Aug 2003 00:19:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iROX-0004I5-8i for nemo-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 00:19:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25804 for ; Fri, 1 Aug 2003 00:19:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iROU-0002BH-00 for nemo-web-archive@ietf.org; Fri, 01 Aug 2003 00:19:55 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iROU-0002BE-00 for nemo-web-archive@ietf.org; Fri, 01 Aug 2003 00:19:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iRNc-0004Dy-Ra; Fri, 01 Aug 2003 00:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iRNB-0004Dg-2p for nemo@optimus.ietf.org; Fri, 01 Aug 2003 00:18:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25796 for ; Fri, 1 Aug 2003 00:18:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iRN8-0002Au-00 for nemo@ietf.org; Fri, 01 Aug 2003 00:18:30 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19iRN7-0002Am-00 for nemo@ietf.org; Fri, 01 Aug 2003 00:18:30 -0400 Received: from huez (unknown [203.178.138.11]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 4A95C5D019; Fri, 1 Aug 2003 13:17:59 +0900 (JST) Date: Fri, 1 Aug 2003 13:09:50 +0900 From: Thierry Ernst To: nemo@ietf.org Cc: tj@kniveton.com Subject: Re: [nemo] Missing minutes Message-Id: <20030801130950.6b6db0d3.ernst@sfc.wide.ad.jp> In-Reply-To: <20030730181821.1c7db2b2.ernst@sfc.wide.ad.jp> References: <20030730181821.1c7db2b2.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, I didn't get any reply, if nobody send me some notes, we cannot complete the minutes. Thanks for the interest of the group. Thierry > Our minutes-taker went out of battery during the NEMO meeting. As a > result, part of his notes are corrupted. > > So, is there anyone out there who could provide his notes for the first > 4 parts below so that we can merge and publish ? > > 1) Agenda Bashing - Chairs > 2) NEMO status and milestones - Chairs > 3) NEMO Basic Support - Ryuji Wakikawa > 4) Multihoming > > This would be highly appreciated. The most important is questions and > answers. > > Thanks in advance, > Thierry. From nemo-admin@ietf.org Fri Aug 1 04:32:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02709 for ; Fri, 1 Aug 2003 04:32:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iVKU-0007OR-LJ; Fri, 01 Aug 2003 04:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iVJf-0007Ng-Qn for nemo@optimus.ietf.org; Fri, 01 Aug 2003 04:31:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02647 for ; Fri, 1 Aug 2003 04:31:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iVJb-0003Sa-00 for nemo@ietf.org; Fri, 01 Aug 2003 04:31:07 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19iVJa-0003SX-00 for nemo@ietf.org; Fri, 01 Aug 2003 04:31:06 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h718V4C9017963; Fri, 1 Aug 2003 01:31:06 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h718UpKl010080; Fri, 1 Aug 2003 03:30:51 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 1C2D32EC86; Fri, 1 Aug 2003 10:31:02 +0200 (CEST) Message-ID: <3F2A2545.1080901@motorola.com> Date: Fri, 01 Aug 2003 10:31:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: nemo@ietf.org, tj@kniveton.com Subject: Re: [nemo] Missing minutes References: <20030730181821.1c7db2b2.ernst@sfc.wide.ad.jp> <20030801130950.6b6db0d3.ernst@sfc.wide.ad.jp> In-Reply-To: <20030801130950.6b6db0d3.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > I didn't get any reply, if nobody send me some notes, we cannot > complete the minutes. I am very much and highly interested in seeing how the discussions turned. I am mainly interested to see the discussions around the IPR. I have read the IPR claims and the documents involved, I want to go further and see what's been discussed about IPR. I am very much and highly interested in seeing what has been discussed around the several modes of basic solution, including the explicit prefix len mode and extended home network. So please provide minutes, thank you in advance, Alex GBU From exim@www1.ietf.org Fri Aug 1 04:32:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02724 for ; Fri, 1 Aug 2003 04:32:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iVKk-0007Qk-1k for nemo-archive@odin.ietf.org; Fri, 01 Aug 2003 04:32:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h718WH11028561 for nemo-archive@odin.ietf.org; Fri, 1 Aug 2003 04:32:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iVKj-0007Qa-Kp for nemo-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 04:32:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02703 for ; Fri, 1 Aug 2003 04:32:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iVKg-0003Tn-00 for nemo-web-archive@ietf.org; Fri, 01 Aug 2003 04:32:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iVKg-0003Tk-00 for nemo-web-archive@ietf.org; Fri, 01 Aug 2003 04:32:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iVKU-0007OR-LJ; Fri, 01 Aug 2003 04:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iVJf-0007Ng-Qn for nemo@optimus.ietf.org; Fri, 01 Aug 2003 04:31:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02647 for ; Fri, 1 Aug 2003 04:31:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iVJb-0003Sa-00 for nemo@ietf.org; Fri, 01 Aug 2003 04:31:07 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19iVJa-0003SX-00 for nemo@ietf.org; Fri, 01 Aug 2003 04:31:06 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h718V4C9017963; Fri, 1 Aug 2003 01:31:06 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h718UpKl010080; Fri, 1 Aug 2003 03:30:51 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 1C2D32EC86; Fri, 1 Aug 2003 10:31:02 +0200 (CEST) Message-ID: <3F2A2545.1080901@motorola.com> Date: Fri, 01 Aug 2003 10:31:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: nemo@ietf.org, tj@kniveton.com Subject: Re: [nemo] Missing minutes References: <20030730181821.1c7db2b2.ernst@sfc.wide.ad.jp> <20030801130950.6b6db0d3.ernst@sfc.wide.ad.jp> In-Reply-To: <20030801130950.6b6db0d3.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > I didn't get any reply, if nobody send me some notes, we cannot > complete the minutes. I am very much and highly interested in seeing how the discussions turned. I am mainly interested to see the discussions around the IPR. I have read the IPR claims and the documents involved, I want to go further and see what's been discussed about IPR. I am very much and highly interested in seeing what has been discussed around the several modes of basic solution, including the explicit prefix len mode and extended home network. So please provide minutes, thank you in advance, Alex GBU From mailman-admin@ietf.org Fri Aug 1 09:01:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08646 for ; Fri, 1 Aug 2003 09:01:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iZWV-00008t-NS for nemo-archive@lists.ietf.org; Fri, 01 Aug 2003 09:00:43 -0400 Date: Fri, 01 Aug 2003 09:00:43 -0400 Message-ID: <20030801130043.29120.48627.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: nemo-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, nemo-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for nemo-archive@lists.ietf.org: List Password // URL ---- -------- nemo@ietf.org koepih https://www1.ietf.org/mailman/options/nemo/nemo-archive%40lists.ietf.org From exim@www1.ietf.org Fri Aug 1 10:13:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16564 for ; Fri, 1 Aug 2003 09:35:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ia3Z-0003ln-Ii for nemo-archive@odin.ietf.org; Fri, 01 Aug 2003 09:34:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71DYruX014485 for nemo-archive@odin.ietf.org; Fri, 1 Aug 2003 09:34:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ia3Z-0003lX-8P for nemo-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 09:34:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16018 for ; Fri, 1 Aug 2003 09:34:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ia0w-0000TP-00 for nemo-web-archive@ietf.org; Fri, 01 Aug 2003 09:32:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iZmr-0005qi-02 for nemo-web-archive@ietf.org; Fri, 01 Aug 2003 09:17:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iZaT-0006TR-IQ for nemo-web-archive@ietf.org; Fri, 01 Aug 2003 09:04:49 -0400 Date: Fri, 01 Aug 2003 09:04:49 -0400 Message-ID: <20030801130449.29120.1819.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: nemo-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, nemo-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for nemo-web-archive@ietf.org: List Password // URL ---- -------- nemo@ietf.org dawauv https://www1.ietf.org/mailman/options/nemo/nemo-web-archive%40ietf.org From nemo-admin@ietf.org Mon Aug 4 07:34:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22398 for ; Mon, 4 Aug 2003 07:34:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jdbE-00038G-UQ; Mon, 04 Aug 2003 07:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jdP0-0002qz-JB for nemo@optimus.ietf.org; Mon, 04 Aug 2003 07:21:22 -0400 Received: from netscape212.com ([62.166.232.230]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22167 for ; Mon, 4 Aug 2003 07:21:18 -0400 (EDT) Message-Id: <200308041121.HAA22167@ietf.org> From: TRAVIS NKALA To: nemo@ietf.org Reply-To: travisnkala@netscape.net Date: Mon, 04 Aug 2003 13:20:23 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="49a40bdc-7acb-4a55-b764-8c61a95f9c18" Subject: [nemo] INVESTMENT PROPOSAL Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format --49a40bdc-7acb-4a55-b764-8c61a95f9c18 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear Sir, Difficulties encountered in efforts to establish a business abroad = necessitate this search for someone to assist me in securing and investing = the sum of USD21,000.000 (twenty one million dollars)inherited from my = father's business reserve. I am the heir of a Zimbabwean family; my father was an agriculturist. He = became rich from his old-aged investment in agriculture and later was = victimized by President Robert Mugabe's land reform policy. He was = assassinated by unknown gunmen for defending his land ownership and siding = the minority white farmers. Before his death, my father foresaw the = insecurity of both our lives and property then decided to deposit the above = sum with a private finance and security firm in Europe. This money has become = the only inherited property of our family since our home was burnt,and the = farmlands and machines seized; yet the government and it's loyalists are bent = on making life difficult for us. To summarise this traumatic story, my mother and I have decided to offer 25% = of the above sum to anyone who assists us to secure this funds overseas or = 30% share for any joint investment in a reliable venture. if you would want to proceed under these terms,please reply for detailed = information. if you do not accept my offer,please in good fate treat with = utmost confidentiality . A quick reply with your name,telephone and fax = numbers for more confidential communication will be highly appreciated. Sincerely yours, TRAVIS NKALA --49a40bdc-7acb-4a55-b764-8c61a95f9c18-- From exim@www1.ietf.org Mon Aug 4 07:34:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22413 for ; Mon, 4 Aug 2003 07:34:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jdbM-00039A-Ay for nemo-archive@odin.ietf.org; Mon, 04 Aug 2003 07:34:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74BY8Ea012093 for nemo-archive@odin.ietf.org; Mon, 4 Aug 2003 07:34:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jdbK-00038y-P8 for nemo-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 07:34:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22394 for ; Mon, 4 Aug 2003 07:34:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jdbK-0000AZ-00 for nemo-web-archive@ietf.org; Mon, 04 Aug 2003 07:34:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jdbJ-0000AV-00 for nemo-web-archive@ietf.org; Mon, 04 Aug 2003 07:34:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jdbE-00038G-UQ; Mon, 04 Aug 2003 07:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jdP0-0002qz-JB for nemo@optimus.ietf.org; Mon, 04 Aug 2003 07:21:22 -0400 Received: from netscape212.com ([62.166.232.230]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22167 for ; Mon, 4 Aug 2003 07:21:18 -0400 (EDT) Message-Id: <200308041121.HAA22167@ietf.org> From: TRAVIS NKALA To: nemo@ietf.org Reply-To: travisnkala@netscape.net Date: Mon, 04 Aug 2003 13:20:23 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="49a40bdc-7acb-4a55-b764-8c61a95f9c18" Subject: [nemo] INVESTMENT PROPOSAL Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format --49a40bdc-7acb-4a55-b764-8c61a95f9c18 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear Sir, Difficulties encountered in efforts to establish a business abroad = necessitate this search for someone to assist me in securing and investing = the sum of USD21,000.000 (twenty one million dollars)inherited from my = father's business reserve. I am the heir of a Zimbabwean family; my father was an agriculturist. He = became rich from his old-aged investment in agriculture and later was = victimized by President Robert Mugabe's land reform policy. He was = assassinated by unknown gunmen for defending his land ownership and siding = the minority white farmers. Before his death, my father foresaw the = insecurity of both our lives and property then decided to deposit the above = sum with a private finance and security firm in Europe. This money has become = the only inherited property of our family since our home was burnt,and the = farmlands and machines seized; yet the government and it's loyalists are bent = on making life difficult for us. To summarise this traumatic story, my mother and I have decided to offer 25% = of the above sum to anyone who assists us to secure this funds overseas or = 30% share for any joint investment in a reliable venture. if you would want to proceed under these terms,please reply for detailed = information. if you do not accept my offer,please in good fate treat with = utmost confidentiality . A quick reply with your name,telephone and fax = numbers for more confidential communication will be highly appreciated. Sincerely yours, TRAVIS NKALA --49a40bdc-7acb-4a55-b764-8c61a95f9c18-- From nemo-admin@ietf.org Mon Aug 4 09:24:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24806 for ; Mon, 4 Aug 2003 09:24:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfJg-0006DU-Rw; Mon, 04 Aug 2003 09:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfJa-0006DC-G6 for nemo@optimus.ietf.org; Mon, 04 Aug 2003 09:23:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24773 for ; Mon, 4 Aug 2003 09:23:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jfJY-00010m-00 for nemo@ietf.org; Mon, 04 Aug 2003 09:23:52 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19jfJY-00010j-00 for nemo@ietf.org; Mon, 04 Aug 2003 09:23:52 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h74DNmLe018913; Mon, 4 Aug 2003 06:23:48 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h74DNlfG019598; Mon, 4 Aug 2003 08:23:47 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 80BAE2EC86; Mon, 4 Aug 2003 15:23:46 +0200 (CEST) Message-ID: <3F2E5E61.8050602@motorola.com> Date: Mon, 04 Aug 2003 15:23:45 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] Issue 10 References: <3F2964EA.D01F466E@iprg.nokia.com> In-Reply-To: <3F2964EA.D01F466E@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > hi Pascal and all, > > I want to see if we can close issue 10. I was not heavily involved in the discussions around this issue. I find the below text about issue 10 reasonable, good to keep igp separated from implicit mode. But I have another related question. I was wondering whether there might be a necessity to clearly state in the draft which modes must be implemented by whom for this to be a relevant spec. An example would be: all MR's MUST implement at least "explicit prefixlen" and all HA's must implement all three modes. This is just an example, I'm looking to know whether it is good or not to be specific about what's mandatory to be implemented. Alex GBU > > Binding Ack status 143 is supposed to be used when the HA cant figure > out which MNP belongs to the MR in the implicit mode. it is every > essential to have this error status because we dont want the MR > assuming that the HA has set up forwarding for the MNP when it > actually didnt. it doesnt matter which mechanism (Prefix Table being > one) is used by the HA in the implicit mode. > > status code 143 is not supposed to be used when an IGP is being run > over the MR-HA tunnel. when an IGP is being used, the HA just waits > for the routing protocol updates from the MR and does not attempt to > create any routes if the BU did not contain any prefix information. > > there are basically three different mechanisms by which the MR > propagates routes to the HA. > > 1. explicit mode. the Binding Update contains the prefix information > in the mobility options (Mobile Network Prefix option or Mobile > Network Prefix Length option) > > 2. implicit mode. the HA figures out the MNP through mechanisms not > defined in the draft. a pre-configured Prefix Table is one such > mechanism that you can use. a static route configuration (manually > added) is another one. > > 3. IGP over the MR-HA tunnel. > > I dont want to mix up (3) with (2). I would like to keep the IGP part > separate from the rest of the specification. I am not too sure we > have taken care of all the issues related to running an IGP over the > tunnel. > > does this make sense? > > Vijay > From exim@www1.ietf.org Mon Aug 4 09:24:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24821 for ; Mon, 4 Aug 2003 09:24:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfJk-0006EL-R1 for nemo-archive@odin.ietf.org; Mon, 04 Aug 2003 09:24:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74DO4oK023949 for nemo-archive@odin.ietf.org; Mon, 4 Aug 2003 09:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfJk-0006EC-LA for nemo-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 09:24:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24778 for ; Mon, 4 Aug 2003 09:23:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jfJj-00010t-00 for nemo-web-archive@ietf.org; Mon, 04 Aug 2003 09:24:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jfJi-00010q-00 for nemo-web-archive@ietf.org; Mon, 04 Aug 2003 09:24:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfJg-0006DU-Rw; Mon, 04 Aug 2003 09:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfJa-0006DC-G6 for nemo@optimus.ietf.org; Mon, 04 Aug 2003 09:23:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24773 for ; Mon, 4 Aug 2003 09:23:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jfJY-00010m-00 for nemo@ietf.org; Mon, 04 Aug 2003 09:23:52 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19jfJY-00010j-00 for nemo@ietf.org; Mon, 04 Aug 2003 09:23:52 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h74DNmLe018913; Mon, 4 Aug 2003 06:23:48 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h74DNlfG019598; Mon, 4 Aug 2003 08:23:47 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 80BAE2EC86; Mon, 4 Aug 2003 15:23:46 +0200 (CEST) Message-ID: <3F2E5E61.8050602@motorola.com> Date: Mon, 04 Aug 2003 15:23:45 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] Issue 10 References: <3F2964EA.D01F466E@iprg.nokia.com> In-Reply-To: <3F2964EA.D01F466E@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > hi Pascal and all, > > I want to see if we can close issue 10. I was not heavily involved in the discussions around this issue. I find the below text about issue 10 reasonable, good to keep igp separated from implicit mode. But I have another related question. I was wondering whether there might be a necessity to clearly state in the draft which modes must be implemented by whom for this to be a relevant spec. An example would be: all MR's MUST implement at least "explicit prefixlen" and all HA's must implement all three modes. This is just an example, I'm looking to know whether it is good or not to be specific about what's mandatory to be implemented. Alex GBU > > Binding Ack status 143 is supposed to be used when the HA cant figure > out which MNP belongs to the MR in the implicit mode. it is every > essential to have this error status because we dont want the MR > assuming that the HA has set up forwarding for the MNP when it > actually didnt. it doesnt matter which mechanism (Prefix Table being > one) is used by the HA in the implicit mode. > > status code 143 is not supposed to be used when an IGP is being run > over the MR-HA tunnel. when an IGP is being used, the HA just waits > for the routing protocol updates from the MR and does not attempt to > create any routes if the BU did not contain any prefix information. > > there are basically three different mechanisms by which the MR > propagates routes to the HA. > > 1. explicit mode. the Binding Update contains the prefix information > in the mobility options (Mobile Network Prefix option or Mobile > Network Prefix Length option) > > 2. implicit mode. the HA figures out the MNP through mechanisms not > defined in the draft. a pre-configured Prefix Table is one such > mechanism that you can use. a static route configuration (manually > added) is another one. > > 3. IGP over the MR-HA tunnel. > > I dont want to mix up (3) with (2). I would like to keep the IGP part > separate from the rest of the specification. I am not too sure we > have taken care of all the issues related to running an IGP over the > tunnel. > > does this make sense? > > Vijay > From nemo-admin@ietf.org Mon Aug 4 09:28:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24917 for ; Mon, 4 Aug 2003 09:28:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfNY-0006Kx-Tw; Mon, 04 Aug 2003 09:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfMj-0006JG-DS for nemo@optimus.ietf.org; Mon, 04 Aug 2003 09:27:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24858 for ; Mon, 4 Aug 2003 09:27:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jfMh-00011V-00 for nemo@ietf.org; Mon, 04 Aug 2003 09:27:07 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19jfMg-00011S-00 for nemo@ietf.org; Mon, 04 Aug 2003 09:27:06 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h74DQxOr023111; Mon, 4 Aug 2003 06:26:59 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h74DQuaQ006421; Mon, 4 Aug 2003 08:26:56 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id E9D9F2EC86; Mon, 4 Aug 2003 15:26:55 +0200 (CEST) Message-ID: <3F2E5F1F.4060302@motorola.com> Date: Mon, 04 Aug 2003 15:26:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Cc: Vijay Devarapalli , pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] Issue 10 References: <3F2964EA.D01F466E@iprg.nokia.com> <3F2E5E61.8050602@motorola.com> In-Reply-To: <3F2E5E61.8050602@motorola.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > But I have another related question. I was wondering whether there > might be a necessity to clearly state in the draft which modes must > be implemented by whom for this to be a relevant spec. An example > would be: all MR's MUST implement at least "explicit prefixlen" and > all HA's must implement all three modes. This is just an example, > I'm looking to know whether it is good or not to be specific about > what's mandatory to be implemented. ...the reason being that one might not want to have a situation where MR only implements say explicit prefixlen mode and HA only implements say explicit network mode. Alex GBU From exim@www1.ietf.org Mon Aug 4 09:28:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24932 for ; Mon, 4 Aug 2003 09:28:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfNa-0006Lv-5N for nemo-archive@odin.ietf.org; Mon, 04 Aug 2003 09:28:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74DS2ex024413 for nemo-archive@odin.ietf.org; Mon, 4 Aug 2003 09:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfNZ-0006Lg-W9 for nemo-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 09:28:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24910 for ; Mon, 4 Aug 2003 09:27:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jfNY-00012R-00 for nemo-web-archive@ietf.org; Mon, 04 Aug 2003 09:28:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jfNX-00012L-00 for nemo-web-archive@ietf.org; Mon, 04 Aug 2003 09:27:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfNY-0006Kx-Tw; Mon, 04 Aug 2003 09:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfMj-0006JG-DS for nemo@optimus.ietf.org; Mon, 04 Aug 2003 09:27:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24858 for ; Mon, 4 Aug 2003 09:27:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jfMh-00011V-00 for nemo@ietf.org; Mon, 04 Aug 2003 09:27:07 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19jfMg-00011S-00 for nemo@ietf.org; Mon, 04 Aug 2003 09:27:06 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h74DQxOr023111; Mon, 4 Aug 2003 06:26:59 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h74DQuaQ006421; Mon, 4 Aug 2003 08:26:56 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id E9D9F2EC86; Mon, 4 Aug 2003 15:26:55 +0200 (CEST) Message-ID: <3F2E5F1F.4060302@motorola.com> Date: Mon, 04 Aug 2003 15:26:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Cc: Vijay Devarapalli , pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] Issue 10 References: <3F2964EA.D01F466E@iprg.nokia.com> <3F2E5E61.8050602@motorola.com> In-Reply-To: <3F2E5E61.8050602@motorola.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > But I have another related question. I was wondering whether there > might be a necessity to clearly state in the draft which modes must > be implemented by whom for this to be a relevant spec. An example > would be: all MR's MUST implement at least "explicit prefixlen" and > all HA's must implement all three modes. This is just an example, > I'm looking to know whether it is good or not to be specific about > what's mandatory to be implemented. ...the reason being that one might not want to have a situation where MR only implements say explicit prefixlen mode and HA only implements say explicit network mode. Alex GBU From nemo-admin@ietf.org Mon Aug 4 09:38:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25308 for ; Mon, 4 Aug 2003 09:38:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfXF-0006tv-EB; Mon, 04 Aug 2003 09:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfWw-0006rW-I2 for nemo@optimus.ietf.org; Mon, 04 Aug 2003 09:37:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25274 for ; Mon, 4 Aug 2003 09:37:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jfWu-00019U-00 for nemo@ietf.org; Mon, 04 Aug 2003 09:37:40 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19jfWt-00018x-00 for nemo@ietf.org; Mon, 04 Aug 2003 09:37:39 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 04 Aug 2003 15:36:44 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h74DYsOP029205; Mon, 4 Aug 2003 15:34:54 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 4 Aug 2003 15:37:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Issue 10 Date: Mon, 4 Aug 2003 14:37:05 +0100 Message-ID: Thread-Topic: [nemo] Issue 10 Thread-Index: AcNai7GqKaxvkPhNTwqWkQ1WB8kkbAAAVM5w From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 04 Aug 2003 13:37:06.0188 (UTC) FILETIME=[7EDE1CC0:01C35A8D] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > But I have another related question. I was wondering whether there > might be a necessity to clearly state in the draft which modes must be > implemented by whom for this to be a relevant spec. An example would > be: all MR's MUST implement at least "explicit prefixlen" and all HA's > must implement all three modes. This is just an example, I'm looking to > know whether it is good or not to be specific about what's mandatory to > be implemented. Good point, Alex. My view is that the HA SHOULD support all modes and that the MR MAY support anyone of them. Note that full static routes on the HA does not require anything from the MR in terms of routing protocols. One may provide low cost implementations with just support of connected routes and default over MRHA... Pascal From exim@www1.ietf.org Mon Aug 4 09:38:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25326 for ; Mon, 4 Aug 2003 09:38:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfXR-0006ux-Tq for nemo-archive@odin.ietf.org; Mon, 04 Aug 2003 09:38:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74DcD2m026585 for nemo-archive@odin.ietf.org; Mon, 4 Aug 2003 09:38:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfXR-0006ui-OI for nemo-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 09:38:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25292 for ; Mon, 4 Aug 2003 09:38:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jfXQ-00019p-00 for nemo-web-archive@ietf.org; Mon, 04 Aug 2003 09:38:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jfXP-00019m-00 for nemo-web-archive@ietf.org; Mon, 04 Aug 2003 09:38:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfXF-0006tv-EB; Mon, 04 Aug 2003 09:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jfWw-0006rW-I2 for nemo@optimus.ietf.org; Mon, 04 Aug 2003 09:37:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25274 for ; Mon, 4 Aug 2003 09:37:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jfWu-00019U-00 for nemo@ietf.org; Mon, 04 Aug 2003 09:37:40 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19jfWt-00018x-00 for nemo@ietf.org; Mon, 04 Aug 2003 09:37:39 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 04 Aug 2003 15:36:44 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h74DYsOP029205; Mon, 4 Aug 2003 15:34:54 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 4 Aug 2003 15:37:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Issue 10 Date: Mon, 4 Aug 2003 14:37:05 +0100 Message-ID: Thread-Topic: [nemo] Issue 10 Thread-Index: AcNai7GqKaxvkPhNTwqWkQ1WB8kkbAAAVM5w From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 04 Aug 2003 13:37:06.0188 (UTC) FILETIME=[7EDE1CC0:01C35A8D] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > But I have another related question. I was wondering whether there > might be a necessity to clearly state in the draft which modes must be > implemented by whom for this to be a relevant spec. An example would > be: all MR's MUST implement at least "explicit prefixlen" and all HA's > must implement all three modes. This is just an example, I'm looking to > know whether it is good or not to be specific about what's mandatory to > be implemented. Good point, Alex. My view is that the HA SHOULD support all modes and that the MR MAY support anyone of them. Note that full static routes on the HA does not require anything from the MR in terms of routing protocols. One may provide low cost implementations with just support of connected routes and default over MRHA... Pascal From nemo-admin@ietf.org Mon Aug 4 13:37:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05092 for ; Mon, 4 Aug 2003 13:37:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjGX-0006e4-K3; Mon, 04 Aug 2003 13:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjGL-0006dT-Eb for nemo@optimus.ietf.org; Mon, 04 Aug 2003 13:36:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05043 for ; Mon, 4 Aug 2003 13:36:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jjG7-0004BA-00 for nemo@ietf.org; Mon, 04 Aug 2003 13:36:35 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19jjG6-0004Al-00 for nemo@ietf.org; Mon, 04 Aug 2003 13:36:34 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA27756; Mon, 4 Aug 2003 10:36:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h74Ha2I05189; Mon, 4 Aug 2003 10:36:02 -0700 X-mProtect: <200308041736> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqfoAtD; Mon, 04 Aug 2003 10:36:01 PDT Message-ID: <3F2E9982.96A8C21E@iprg.nokia.com> Date: Mon, 04 Aug 2003 10:36:02 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: pthubert@cisco.com, nemo@ietf.org References: <3F2964EA.D01F466E@iprg.nokia.com> <3F2E5E61.8050602@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Implementation requirements for the different modes (was Re: [nemo] Issue 10) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > But I have another related question. I was wondering whether there > might be a necessity to clearly state in the draft which modes must be > implemented by whom for this to be a relevant spec. An example would > be: all MR's MUST implement at least "explicit prefixlen" and all HA's > must implement all three modes. This is just an example, I'm looking to > know whether it is good or not to be specific about what's mandatory to > be implemented. good point. IMO, the Home Agent MUST implement all modes in section 5.2. support for running an IGP over the MR-HA tunnel is still optional. the MR may implement any method it wants. I made this issue 11. proposed text 6. Home Agent Operation In order for a Mobile Router to operate correctly, the Home Agent MUST satisfy all the requirements listed in section 8.4 of [1]. The Home Agent MUST implement all the modes described in Section 5.2. as for the MR we already have some text in section 5.2 The Mobile Router uses one of the following modes to instruct the Home Agent to determine the prefixes owned by the Mobile Router. Vijay From exim@www1.ietf.org Mon Aug 4 13:37:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05107 for ; Mon, 4 Aug 2003 13:37:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjGc-0006ga-I7 for nemo-archive@odin.ietf.org; Mon, 04 Aug 2003 13:37:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74Hb6oo025690 for nemo-archive@odin.ietf.org; Mon, 4 Aug 2003 13:37:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjGc-0006gF-EG for nemo-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 13:37:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05083 for ; Mon, 4 Aug 2003 13:37:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jjGa-0004Bg-00 for nemo-web-archive@ietf.org; Mon, 04 Aug 2003 13:37:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jjGZ-0004Bd-00 for nemo-web-archive@ietf.org; Mon, 04 Aug 2003 13:37:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjGX-0006e4-K3; Mon, 04 Aug 2003 13:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjGL-0006dT-Eb for nemo@optimus.ietf.org; Mon, 04 Aug 2003 13:36:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05043 for ; Mon, 4 Aug 2003 13:36:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jjG7-0004BA-00 for nemo@ietf.org; Mon, 04 Aug 2003 13:36:35 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19jjG6-0004Al-00 for nemo@ietf.org; Mon, 04 Aug 2003 13:36:34 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA27756; Mon, 4 Aug 2003 10:36:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h74Ha2I05189; Mon, 4 Aug 2003 10:36:02 -0700 X-mProtect: <200308041736> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqfoAtD; Mon, 04 Aug 2003 10:36:01 PDT Message-ID: <3F2E9982.96A8C21E@iprg.nokia.com> Date: Mon, 04 Aug 2003 10:36:02 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: pthubert@cisco.com, nemo@ietf.org References: <3F2964EA.D01F466E@iprg.nokia.com> <3F2E5E61.8050602@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Implementation requirements for the different modes (was Re: [nemo] Issue 10) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > But I have another related question. I was wondering whether there > might be a necessity to clearly state in the draft which modes must be > implemented by whom for this to be a relevant spec. An example would > be: all MR's MUST implement at least "explicit prefixlen" and all HA's > must implement all three modes. This is just an example, I'm looking to > know whether it is good or not to be specific about what's mandatory to > be implemented. good point. IMO, the Home Agent MUST implement all modes in section 5.2. support for running an IGP over the MR-HA tunnel is still optional. the MR may implement any method it wants. I made this issue 11. proposed text 6. Home Agent Operation In order for a Mobile Router to operate correctly, the Home Agent MUST satisfy all the requirements listed in section 8.4 of [1]. The Home Agent MUST implement all the modes described in Section 5.2. as for the MR we already have some text in section 5.2 The Mobile Router uses one of the following modes to instruct the Home Agent to determine the prefixes owned by the Mobile Router. Vijay From nemo-admin@ietf.org Mon Aug 4 20:35:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16533 for ; Mon, 4 Aug 2003 20:35:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jpn3-000266-QS; Mon, 04 Aug 2003 20:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jpma-00025m-DZ for nemo@optimus.ietf.org; Mon, 04 Aug 2003 20:34:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16493 for ; Mon, 4 Aug 2003 20:34:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jpmX-0006W1-00 for nemo@ietf.org; Mon, 04 Aug 2003 20:34:29 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19jpmW-0006Vu-00 for nemo@ietf.org; Mon, 04 Aug 2003 20:34:29 -0400 Received: from huez (h131.p019.iij4u.or.jp [210.130.19.131]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 4A64F5D13C; Tue, 5 Aug 2003 09:32:34 +0900 (JST) Date: Tue, 5 Aug 2003 09:24:15 +0900 From: Thierry Ernst To: Vijay Devarapalli Cc: alexandru.petrescu@motorola.com, pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] Implementation requirements for the different modes (was Re: [nemo] Issue 10) Message-Id: <20030805092415.3c20c234.ernst@sfc.wide.ad.jp> In-Reply-To: <3F2E9982.96A8C21E@iprg.nokia.com> References: <3F2964EA.D01F466E@iprg.nokia.com> <3F2E5E61.8050602@motorola.com> <3F2E9982.96A8C21E@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, This sounds reasonable to me to have only HA implementing all modes. As for the HA, isn't it one of the modes that MUST at least be supported ? What happens if 2 MRs in the same mobile network don't implement the same mode ? Thierry. > > But I have another related question. I was wondering whether there > > might be a necessity to clearly state in the draft which modes must be > > implemented by whom for this to be a relevant spec. An example would > > be: all MR's MUST implement at least "explicit prefixlen" and all HA's > > must implement all three modes. This is just an example, I'm looking to > > know whether it is good or not to be specific about what's mandatory to > > be implemented. > > good point. IMO, the Home Agent MUST implement all > modes in section 5.2. support for running an IGP over > the MR-HA tunnel is still optional. the MR may > implement any method it wants. > > I made this issue 11. > > proposed text > > 6. Home Agent Operation > > In order for a Mobile Router to operate correctly, the Home Agent > MUST satisfy all the requirements listed in section 8.4 of [1]. The > Home Agent MUST implement all the modes described in Section 5.2. > > as for the MR we already have some text in section 5.2 > > The Mobile Router uses > one of the following modes to instruct the Home Agent to determine > the prefixes owned by the Mobile Router. > From exim@www1.ietf.org Mon Aug 4 20:35:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16548 for ; Mon, 4 Aug 2003 20:35:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jpn8-00026y-Js for nemo-archive@odin.ietf.org; Mon, 04 Aug 2003 20:35:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h750Z6pr008114 for nemo-archive@odin.ietf.org; Mon, 4 Aug 2003 20:35:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jpn8-00026n-F7 for nemo-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 20:35:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16515 for ; Mon, 4 Aug 2003 20:35:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jpn6-0006WI-00 for nemo-web-archive@ietf.org; Mon, 04 Aug 2003 20:35:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jpn5-0006WF-00 for nemo-web-archive@ietf.org; Mon, 04 Aug 2003 20:35:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jpn3-000266-QS; Mon, 04 Aug 2003 20:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jpma-00025m-DZ for nemo@optimus.ietf.org; Mon, 04 Aug 2003 20:34:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16493 for ; Mon, 4 Aug 2003 20:34:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jpmX-0006W1-00 for nemo@ietf.org; Mon, 04 Aug 2003 20:34:29 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19jpmW-0006Vu-00 for nemo@ietf.org; Mon, 04 Aug 2003 20:34:29 -0400 Received: from huez (h131.p019.iij4u.or.jp [210.130.19.131]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 4A64F5D13C; Tue, 5 Aug 2003 09:32:34 +0900 (JST) Date: Tue, 5 Aug 2003 09:24:15 +0900 From: Thierry Ernst To: Vijay Devarapalli Cc: alexandru.petrescu@motorola.com, pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] Implementation requirements for the different modes (was Re: [nemo] Issue 10) Message-Id: <20030805092415.3c20c234.ernst@sfc.wide.ad.jp> In-Reply-To: <3F2E9982.96A8C21E@iprg.nokia.com> References: <3F2964EA.D01F466E@iprg.nokia.com> <3F2E5E61.8050602@motorola.com> <3F2E9982.96A8C21E@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, This sounds reasonable to me to have only HA implementing all modes. As for the HA, isn't it one of the modes that MUST at least be supported ? What happens if 2 MRs in the same mobile network don't implement the same mode ? Thierry. > > But I have another related question. I was wondering whether there > > might be a necessity to clearly state in the draft which modes must be > > implemented by whom for this to be a relevant spec. An example would > > be: all MR's MUST implement at least "explicit prefixlen" and all HA's > > must implement all three modes. This is just an example, I'm looking to > > know whether it is good or not to be specific about what's mandatory to > > be implemented. > > good point. IMO, the Home Agent MUST implement all > modes in section 5.2. support for running an IGP over > the MR-HA tunnel is still optional. the MR may > implement any method it wants. > > I made this issue 11. > > proposed text > > 6. Home Agent Operation > > In order for a Mobile Router to operate correctly, the Home Agent > MUST satisfy all the requirements listed in section 8.4 of [1]. The > Home Agent MUST implement all the modes described in Section 5.2. > > as for the MR we already have some text in section 5.2 > > The Mobile Router uses > one of the following modes to instruct the Home Agent to determine > the prefixes owned by the Mobile Router. > From nemo-admin@ietf.org Mon Aug 4 20:45:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16675 for ; Mon, 4 Aug 2003 20:45:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jpwi-0002Ww-PS; Mon, 04 Aug 2003 20:45:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jpwG-0002Wc-4K for nemo@optimus.ietf.org; Mon, 04 Aug 2003 20:44:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16646 for ; Mon, 4 Aug 2003 20:44:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jpwD-0006YN-00 for nemo@ietf.org; Mon, 04 Aug 2003 20:44:29 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19jpwC-0006Y2-00 for nemo@ietf.org; Mon, 04 Aug 2003 20:44:29 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA22058; Mon, 4 Aug 2003 17:43:58 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h750hvp05563; Mon, 4 Aug 2003 17:43:57 -0700 X-mProtect: <200308050043> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCc2bdj; Mon, 04 Aug 2003 17:43:56 PDT Message-ID: <3F2EFDCD.AADC6D7A@iprg.nokia.com> Date: Mon, 04 Aug 2003 17:43:57 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Thierry Ernst CC: alexandru.petrescu@motorola.com, pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] Implementation requirements for the different modes (wasRe: [nemo] Issue 10) References: <3F2964EA.D01F466E@iprg.nokia.com> <3F2E5E61.8050602@motorola.com> <3F2E9982.96A8C21E@iprg.nokia.com> <20030805092415.3c20c234.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > This sounds reasonable to me to have only HA implementing all modes. As > for the HA, you mean the MR? > isn't it one of the modes that MUST at least be supported ? I thought thats obvious from the current text > The Mobile Router uses > one of the following modes to instruct the Home Agent to determine > the prefixes owned by the Mobile Router. this means that the Mobile Router MUST implement one of the modes. > What happens if 2 MRs in the same mobile network don't implement the > same mode ? shouldnt be a problem as long as the HA implements both. do you see a problem? Vijay > > Thierry. > > > > But I have another related question. I was wondering whether there > > > might be a necessity to clearly state in the draft which modes must be > > > implemented by whom for this to be a relevant spec. An example would > > > be: all MR's MUST implement at least "explicit prefixlen" and all HA's > > > must implement all three modes. This is just an example, I'm looking to > > > know whether it is good or not to be specific about what's mandatory to > > > be implemented. > > > > good point. IMO, the Home Agent MUST implement all > > modes in section 5.2. support for running an IGP over > > the MR-HA tunnel is still optional. the MR may > > implement any method it wants. > > > > I made this issue 11. > > > > proposed text > > > > 6. Home Agent Operation > > > > In order for a Mobile Router to operate correctly, the Home Agent > > MUST satisfy all the requirements listed in section 8.4 of [1]. The > > Home Agent MUST implement all the modes described in Section 5.2. > > > > as for the MR we already have some text in section 5.2 > > > > The Mobile Router uses > > one of the following modes to instruct the Home Agent to determine > > the prefixes owned by the Mobile Router. > > From exim@www1.ietf.org Mon Aug 4 20:45:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16690 for ; Mon, 4 Aug 2003 20:45:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jpwm-0002Xs-6R for nemo-archive@odin.ietf.org; Mon, 04 Aug 2003 20:45:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h750j4hE009778 for nemo-archive@odin.ietf.org; Mon, 4 Aug 2003 20:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jpwm-0002Xd-1E for nemo-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 20:45:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16672 for ; Mon, 4 Aug 2003 20:44:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jpwj-0006Yf-00 for nemo-web-archive@ietf.org; Mon, 04 Aug 2003 20:45:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jpwj-0006Yc-00 for nemo-web-archive@ietf.org; Mon, 04 Aug 2003 20:45:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jpwi-0002Ww-PS; Mon, 04 Aug 2003 20:45:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jpwG-0002Wc-4K for nemo@optimus.ietf.org; Mon, 04 Aug 2003 20:44:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16646 for ; Mon, 4 Aug 2003 20:44:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jpwD-0006YN-00 for nemo@ietf.org; Mon, 04 Aug 2003 20:44:29 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19jpwC-0006Y2-00 for nemo@ietf.org; Mon, 04 Aug 2003 20:44:29 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA22058; Mon, 4 Aug 2003 17:43:58 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h750hvp05563; Mon, 4 Aug 2003 17:43:57 -0700 X-mProtect: <200308050043> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCc2bdj; Mon, 04 Aug 2003 17:43:56 PDT Message-ID: <3F2EFDCD.AADC6D7A@iprg.nokia.com> Date: Mon, 04 Aug 2003 17:43:57 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Thierry Ernst CC: alexandru.petrescu@motorola.com, pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] Implementation requirements for the different modes (wasRe: [nemo] Issue 10) References: <3F2964EA.D01F466E@iprg.nokia.com> <3F2E5E61.8050602@motorola.com> <3F2E9982.96A8C21E@iprg.nokia.com> <20030805092415.3c20c234.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > This sounds reasonable to me to have only HA implementing all modes. As > for the HA, you mean the MR? > isn't it one of the modes that MUST at least be supported ? I thought thats obvious from the current text > The Mobile Router uses > one of the following modes to instruct the Home Agent to determine > the prefixes owned by the Mobile Router. this means that the Mobile Router MUST implement one of the modes. > What happens if 2 MRs in the same mobile network don't implement the > same mode ? shouldnt be a problem as long as the HA implements both. do you see a problem? Vijay > > Thierry. > > > > But I have another related question. I was wondering whether there > > > might be a necessity to clearly state in the draft which modes must be > > > implemented by whom for this to be a relevant spec. An example would > > > be: all MR's MUST implement at least "explicit prefixlen" and all HA's > > > must implement all three modes. This is just an example, I'm looking to > > > know whether it is good or not to be specific about what's mandatory to > > > be implemented. > > > > good point. IMO, the Home Agent MUST implement all > > modes in section 5.2. support for running an IGP over > > the MR-HA tunnel is still optional. the MR may > > implement any method it wants. > > > > I made this issue 11. > > > > proposed text > > > > 6. Home Agent Operation > > > > In order for a Mobile Router to operate correctly, the Home Agent > > MUST satisfy all the requirements listed in section 8.4 of [1]. The > > Home Agent MUST implement all the modes described in Section 5.2. > > > > as for the MR we already have some text in section 5.2 > > > > The Mobile Router uses > > one of the following modes to instruct the Home Agent to determine > > the prefixes owned by the Mobile Router. > > From nemo-admin@ietf.org Mon Aug 4 21:02:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16927 for ; Mon, 4 Aug 2003 21:02:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jqDB-0002rA-UQ; Mon, 04 Aug 2003 21:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jqD3-0002qx-Nh for nemo@optimus.ietf.org; Mon, 04 Aug 2003 21:01:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16913 for ; Mon, 4 Aug 2003 21:01:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jqD1-0006df-00 for nemo@ietf.org; Mon, 04 Aug 2003 21:01:51 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19jqD0-0006dS-00 for nemo@ietf.org; Mon, 04 Aug 2003 21:01:50 -0400 Received: from huez (h131.p019.iij4u.or.jp [210.130.19.131]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id B654C5D19E; Tue, 5 Aug 2003 10:00:58 +0900 (JST) Date: Tue, 5 Aug 2003 09:52:32 +0900 From: Thierry Ernst To: Vijay Devarapalli Cc: alexandru.petrescu@motorola.com, pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] Implementation requirements for the different modes (wasRe: [nemo] Issue 10) Message-Id: <20030805095232.5979ef62.ernst@sfc.wide.ad.jp> In-Reply-To: <3F2EFDCD.AADC6D7A@iprg.nokia.com> References: <3F2964EA.D01F466E@iprg.nokia.com> <3F2E5E61.8050602@motorola.com> <3F2E9982.96A8C21E@iprg.nokia.com> <20030805092415.3c20c234.ernst@sfc.wide.ad.jp> <3F2EFDCD.AADC6D7A@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > > This sounds reasonable to me to have only HA implementing all modes. As > > for the HA, > > you mean the MR? Sorry, misstyping. Yes, MR. > > isn't it one of the modes that MUST at least be supported ? > > I thought thats obvious from the current text > > > The Mobile Router uses > > one of the following modes to instruct the Home Agent to determine > > the prefixes owned by the Mobile Router. > > this means that the Mobile Router MUST implement one of the > modes. > > > What happens if 2 MRs in the same mobile network don't implement the > > same mode ? > > shouldnt be a problem as long as the HA implements both. do > you see a problem? I don't see any specific problem but it may be one once we do some testing (?): what happens if a multihomed mobile network has 2 MRs, and 1 MR uses implicit, the other uses explicit ? Will it work ? It this reasonable to allow this ? Thierry From exim@www1.ietf.org Mon Aug 4 21:02:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16942 for ; Mon, 4 Aug 2003 21:02:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jqDD-0002s7-W3 for nemo-archive@odin.ietf.org; Mon, 04 Aug 2003 21:02:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75123qA011033 for nemo-archive@odin.ietf.org; Mon, 4 Aug 2003 21:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jqDD-0002rs-OM for nemo-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 21:02:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16917 for ; Mon, 4 Aug 2003 21:01:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jqDB-0006dp-00 for nemo-web-archive@ietf.org; Mon, 04 Aug 2003 21:02:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jqDA-0006dm-00 for nemo-web-archive@ietf.org; Mon, 04 Aug 2003 21:02:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jqDB-0002rA-UQ; Mon, 04 Aug 2003 21:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jqD3-0002qx-Nh for nemo@optimus.ietf.org; Mon, 04 Aug 2003 21:01:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16913 for ; Mon, 4 Aug 2003 21:01:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jqD1-0006df-00 for nemo@ietf.org; Mon, 04 Aug 2003 21:01:51 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19jqD0-0006dS-00 for nemo@ietf.org; Mon, 04 Aug 2003 21:01:50 -0400 Received: from huez (h131.p019.iij4u.or.jp [210.130.19.131]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id B654C5D19E; Tue, 5 Aug 2003 10:00:58 +0900 (JST) Date: Tue, 5 Aug 2003 09:52:32 +0900 From: Thierry Ernst To: Vijay Devarapalli Cc: alexandru.petrescu@motorola.com, pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] Implementation requirements for the different modes (wasRe: [nemo] Issue 10) Message-Id: <20030805095232.5979ef62.ernst@sfc.wide.ad.jp> In-Reply-To: <3F2EFDCD.AADC6D7A@iprg.nokia.com> References: <3F2964EA.D01F466E@iprg.nokia.com> <3F2E5E61.8050602@motorola.com> <3F2E9982.96A8C21E@iprg.nokia.com> <20030805092415.3c20c234.ernst@sfc.wide.ad.jp> <3F2EFDCD.AADC6D7A@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > > This sounds reasonable to me to have only HA implementing all modes. As > > for the HA, > > you mean the MR? Sorry, misstyping. Yes, MR. > > isn't it one of the modes that MUST at least be supported ? > > I thought thats obvious from the current text > > > The Mobile Router uses > > one of the following modes to instruct the Home Agent to determine > > the prefixes owned by the Mobile Router. > > this means that the Mobile Router MUST implement one of the > modes. > > > What happens if 2 MRs in the same mobile network don't implement the > > same mode ? > > shouldnt be a problem as long as the HA implements both. do > you see a problem? I don't see any specific problem but it may be one once we do some testing (?): what happens if a multihomed mobile network has 2 MRs, and 1 MR uses implicit, the other uses explicit ? Will it work ? It this reasonable to allow this ? Thierry From nemo-admin@ietf.org Mon Aug 4 21:24:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17247 for ; Mon, 4 Aug 2003 21:24:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jqYT-0003Ph-Da; Mon, 04 Aug 2003 21:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jqYG-0003ON-VR for nemo@optimus.ietf.org; Mon, 04 Aug 2003 21:23:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17237 for ; Mon, 4 Aug 2003 21:23:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jqYE-0006jc-00 for nemo@ietf.org; Mon, 04 Aug 2003 21:23:46 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19jqYD-0006jZ-00 for nemo@ietf.org; Mon, 04 Aug 2003 21:23:45 -0400 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (h131.p019.iij4u.or.jp [210.130.19.131]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h751N4ee026556; Tue, 5 Aug 2003 10:23:04 +0900 Date: Mon, 04 Aug 2003 20:49:48 +0900 Message-ID: From: Ryuji Wakikawa To: ernst@sfc.wide.ad.jp Sent-via: ernst@sfc.wide.ad.jp Cc: vijayd@IPRG.nokia.com, alexandru.petrescu@motorola.com, pthubert@cisco.com, nemo@ietf.org Sent-via: vijayd@IPRG.nokia.com, alexandru.petrescu@motorola.com, pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] Implementation requirements for the different modes (wasRe: [nemo] Issue 10) In-Reply-To: <20030805095232.5979ef62.ernst@sfc.wide.ad.jp> References: <3F2964EA.D01F466E@iprg.nokia.com> <3F2E5E61.8050602@motorola.com> <3F2E9982.96A8C21E@iprg.nokia.com> <20030805092415.3c20c234.ernst@sfc.wide.ad.jp> <3F2EFDCD.AADC6D7A@iprg.nokia.com> <20030805095232.5979ef62.ernst@sfc.wide.ad.jp> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi, At Tue, 5 Aug 2003 09:52:32 +0900, Thierry Ernst wrote: > > > Hi, > > > > This sounds reasonable to me to have only HA implementing all modes. As > > > for the HA, > > > > you mean the MR? > > Sorry, misstyping. Yes, MR. > > > > isn't it one of the modes that MUST at least be supported ? > > > > I thought thats obvious from the current text > > > > > The Mobile Router uses > > > one of the following modes to instruct the Home Agent to determine > > > the prefixes owned by the Mobile Router. > > > > this means that the Mobile Router MUST implement one of the > > modes. > > > > > What happens if 2 MRs in the same mobile network don't implement the > > > same mode ? > > > > shouldnt be a problem as long as the HA implements both. do > > you see a problem? > > I don't see any specific problem but it may be one once we do some > testing (?): what happens if a multihomed mobile network has 2 MRs, and > 1 MR uses implicit, the other uses explicit ? Will it work ? It this > reasonable to allow this ? I don't see any problem, neither:-) I personally think this evaluation should be done in the multihoming draft, but not in the basic. regards, ryuji From exim@www1.ietf.org Mon Aug 4 21:24:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17262 for ; Mon, 4 Aug 2003 21:24:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jqYY-0003Rg-1p for nemo-archive@odin.ietf.org; Mon, 04 Aug 2003 21:24:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h751O64W013244 for nemo-archive@odin.ietf.org; Mon, 4 Aug 2003 21:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jqYX-0003RX-UM for nemo-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 21:24:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17241 for ; Mon, 4 Aug 2003 21:24:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jqYV-0006jj-00 for nemo-web-archive@ietf.org; Mon, 04 Aug 2003 21:24:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jqYU-0006jg-00 for nemo-web-archive@ietf.org; Mon, 04 Aug 2003 21:24:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jqYT-0003Ph-Da; Mon, 04 Aug 2003 21:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jqYG-0003ON-VR for nemo@optimus.ietf.org; Mon, 04 Aug 2003 21:23:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17237 for ; Mon, 4 Aug 2003 21:23:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jqYE-0006jc-00 for nemo@ietf.org; Mon, 04 Aug 2003 21:23:46 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19jqYD-0006jZ-00 for nemo@ietf.org; Mon, 04 Aug 2003 21:23:45 -0400 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (h131.p019.iij4u.or.jp [210.130.19.131]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h751N4ee026556; Tue, 5 Aug 2003 10:23:04 +0900 Date: Mon, 04 Aug 2003 20:49:48 +0900 Message-ID: From: Ryuji Wakikawa To: ernst@sfc.wide.ad.jp Sent-via: ernst@sfc.wide.ad.jp Cc: vijayd@IPRG.nokia.com, alexandru.petrescu@motorola.com, pthubert@cisco.com, nemo@ietf.org Sent-via: vijayd@IPRG.nokia.com, alexandru.petrescu@motorola.com, pthubert@cisco.com, nemo@ietf.org Subject: Re: [nemo] Implementation requirements for the different modes (wasRe: [nemo] Issue 10) In-Reply-To: <20030805095232.5979ef62.ernst@sfc.wide.ad.jp> References: <3F2964EA.D01F466E@iprg.nokia.com> <3F2E5E61.8050602@motorola.com> <3F2E9982.96A8C21E@iprg.nokia.com> <20030805092415.3c20c234.ernst@sfc.wide.ad.jp> <3F2EFDCD.AADC6D7A@iprg.nokia.com> <20030805095232.5979ef62.ernst@sfc.wide.ad.jp> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi, At Tue, 5 Aug 2003 09:52:32 +0900, Thierry Ernst wrote: > > > Hi, > > > > This sounds reasonable to me to have only HA implementing all modes. As > > > for the HA, > > > > you mean the MR? > > Sorry, misstyping. Yes, MR. > > > > isn't it one of the modes that MUST at least be supported ? > > > > I thought thats obvious from the current text > > > > > The Mobile Router uses > > > one of the following modes to instruct the Home Agent to determine > > > the prefixes owned by the Mobile Router. > > > > this means that the Mobile Router MUST implement one of the > > modes. > > > > > What happens if 2 MRs in the same mobile network don't implement the > > > same mode ? > > > > shouldnt be a problem as long as the HA implements both. do > > you see a problem? > > I don't see any specific problem but it may be one once we do some > testing (?): what happens if a multihomed mobile network has 2 MRs, and > 1 MR uses implicit, the other uses explicit ? Will it work ? It this > reasonable to allow this ? I don't see any problem, neither:-) I personally think this evaluation should be done in the multihoming draft, but not in the basic. regards, ryuji From nemo-admin@ietf.org Tue Aug 5 03:05:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03834 for ; Tue, 5 Aug 2003 03:05:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jvsU-0004hI-1G; Tue, 05 Aug 2003 03:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jvsR-0004h3-Hy for nemo@optimus.ietf.org; Tue, 05 Aug 2003 03:04:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03813 for ; Tue, 5 Aug 2003 03:04:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jvsN-0000DF-00 for nemo@ietf.org; Tue, 05 Aug 2003 03:04:55 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19jvsN-0000Cz-00 for nemo@ietf.org; Tue, 05 Aug 2003 03:04:55 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Aug 2003 09:04:03 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h7572CCM022495; Tue, 5 Aug 2003 09:02:13 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Aug 2003 09:04:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Aug 2003 08:04:24 +0100 Message-ID: Thread-Topic: Issue 10 Thread-Index: AcNXlLU6mvAHcBzjR3ydLr38YLJh5gDiTJMg From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , X-OriginalArrivalTime: 05 Aug 2003 07:04:24.0746 (UTC) FILETIME=[CD9120A0:01C35B1F] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Issue 10 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Vijay :) Yes it globally makes a lot of sense. A few comments in line: > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: jeudi 31 juillet 2003 20:50 > To: Pascal Thubert (pthubert); nemo@ietf.org > Subject: Issue 10 >=20 > hi Pascal and all, >=20 > I want to see if we can close issue 10. >=20 > Binding Ack status 143 is supposed to be used when the > HA cant figure out which MNP belongs to the MR in the > implicit mode. it is every essential to have this error > status because we dont want the MR assuming that the HA > has set up forwarding for the MNP when it actually didnt. > it doesnt matter which mechanism (Prefix Table being one) > is used by the HA in the implicit mode. >=20 Agreed, with restrictions below below > status code 143 is not supposed to be used when an IGP > is being run over the MR-HA tunnel. when an IGP is being > used, the HA just waits for the routing protocol updates > from the MR and does not attempt to create any routes if > the BU did not contain any prefix information. >=20 Yes, that's the key. I would agree with the 143 if it was sure between HA and MR that they are talking about implicit, the real one, as opposed to static or IGP. That would be the only reason at this time to have an implicit bit in the BU/BA, so that the HA can answer 143 if it is expected to have MNP information in a Nemo specific config that we usually refer to as prefix table, and can not find it. So I'd say it's either (NO 143) or (143 AND implicit bit). What do you think? > there are basically three different mechanisms by which > the MR propagates routes to the HA. >=20 (you do not seem to like them, but they are definitely in the picture) 0. static routes. The routes to the MNP is preinstalled and resident in the HA(s), independently of the binding update or IGP activity between the HA and the MR. > 1. explicit mode. the Binding Update contains the prefix > information in the mobility options (Mobile Network > Prefix option or Mobile Network Prefix Length option) >=20 > 2. implicit mode. the HA figures out the MNP through > mechanisms not defined in the draft. a pre-configured > Prefix Table is one such mechanism that you can use. > a static route configuration (manually added) is > another one. >=20 > 3. IGP over the MR-HA tunnel. >=20 > I dont want to mix up (3) with (2). I would like to keep > the IGP part separate from the rest of the specification. > I am not too sure we have taken care of all the issues > related to running an IGP over the tunnel. >=20 > does this make sense? >=20 Sure does. How about my comments ;) ? Pascal From exim@www1.ietf.org Tue Aug 5 03:05:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03849 for ; Tue, 5 Aug 2003 03:05:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jvsZ-0004iA-7E for nemo-archive@odin.ietf.org; Tue, 05 Aug 2003 03:05:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75757qp018110 for nemo-archive@odin.ietf.org; Tue, 5 Aug 2003 03:05:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jvsY-0004i1-Kp for nemo-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 03:05:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03817 for ; Tue, 5 Aug 2003 03:05:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jvsU-0000DM-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 03:05:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jvsU-0000DJ-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 03:05:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jvsU-0004hI-1G; Tue, 05 Aug 2003 03:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jvsR-0004h3-Hy for nemo@optimus.ietf.org; Tue, 05 Aug 2003 03:04:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03813 for ; Tue, 5 Aug 2003 03:04:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jvsN-0000DF-00 for nemo@ietf.org; Tue, 05 Aug 2003 03:04:55 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19jvsN-0000Cz-00 for nemo@ietf.org; Tue, 05 Aug 2003 03:04:55 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Aug 2003 09:04:03 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h7572CCM022495; Tue, 5 Aug 2003 09:02:13 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Aug 2003 09:04:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Aug 2003 08:04:24 +0100 Message-ID: Thread-Topic: Issue 10 Thread-Index: AcNXlLU6mvAHcBzjR3ydLr38YLJh5gDiTJMg From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , X-OriginalArrivalTime: 05 Aug 2003 07:04:24.0746 (UTC) FILETIME=[CD9120A0:01C35B1F] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Issue 10 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Vijay :) Yes it globally makes a lot of sense. A few comments in line: > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: jeudi 31 juillet 2003 20:50 > To: Pascal Thubert (pthubert); nemo@ietf.org > Subject: Issue 10 >=20 > hi Pascal and all, >=20 > I want to see if we can close issue 10. >=20 > Binding Ack status 143 is supposed to be used when the > HA cant figure out which MNP belongs to the MR in the > implicit mode. it is every essential to have this error > status because we dont want the MR assuming that the HA > has set up forwarding for the MNP when it actually didnt. > it doesnt matter which mechanism (Prefix Table being one) > is used by the HA in the implicit mode. >=20 Agreed, with restrictions below below > status code 143 is not supposed to be used when an IGP > is being run over the MR-HA tunnel. when an IGP is being > used, the HA just waits for the routing protocol updates > from the MR and does not attempt to create any routes if > the BU did not contain any prefix information. >=20 Yes, that's the key. I would agree with the 143 if it was sure between HA and MR that they are talking about implicit, the real one, as opposed to static or IGP. That would be the only reason at this time to have an implicit bit in the BU/BA, so that the HA can answer 143 if it is expected to have MNP information in a Nemo specific config that we usually refer to as prefix table, and can not find it. So I'd say it's either (NO 143) or (143 AND implicit bit). What do you think? > there are basically three different mechanisms by which > the MR propagates routes to the HA. >=20 (you do not seem to like them, but they are definitely in the picture) 0. static routes. The routes to the MNP is preinstalled and resident in the HA(s), independently of the binding update or IGP activity between the HA and the MR. > 1. explicit mode. the Binding Update contains the prefix > information in the mobility options (Mobile Network > Prefix option or Mobile Network Prefix Length option) >=20 > 2. implicit mode. the HA figures out the MNP through > mechanisms not defined in the draft. a pre-configured > Prefix Table is one such mechanism that you can use. > a static route configuration (manually added) is > another one. >=20 > 3. IGP over the MR-HA tunnel. >=20 > I dont want to mix up (3) with (2). I would like to keep > the IGP part separate from the rest of the specification. > I am not too sure we have taken care of all the issues > related to running an IGP over the tunnel. >=20 > does this make sense? >=20 Sure does. How about my comments ;) ? Pascal From nemo-admin@ietf.org Tue Aug 5 03:09:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03892 for ; Tue, 5 Aug 2003 03:09:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jvwK-000575-Ge; Tue, 05 Aug 2003 03:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jvw3-00056g-9R for nemo@optimus.ietf.org; Tue, 05 Aug 2003 03:08:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03883 for ; Tue, 5 Aug 2003 03:08:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jvvz-0000EN-00 for nemo@ietf.org; Tue, 05 Aug 2003 03:08:39 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19jvvy-0000EK-00 for nemo@ietf.org; Tue, 05 Aug 2003 03:08:38 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Aug 2003 09:07:47 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h7575usY023002; Tue, 5 Aug 2003 09:05:56 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Aug 2003 09:08:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Implementation requirements for the different modes (was Re: [nemo] Issue 10) Date: Tue, 5 Aug 2003 08:08:07 +0100 Message-ID: Thread-Topic: Implementation requirements for the different modes (was Re: [nemo] Issue 10) Thread-Index: AcNarwM+iYLYLou1S06n66JvyeD+GgAcPTiA From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Alexandru Petrescu" Cc: X-OriginalArrivalTime: 05 Aug 2003 07:08:08.0545 (UTC) FILETIME=[52F62510:01C35B20] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Excellent :)=20 I understand from the discussion with Thierry that you could say=20 "The Mobile Router MUST support at least one of" to make it more = specific but this is minor... Pascal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: lundi 4 ao=FBt 2003 19:36 > To: Alexandru Petrescu > Cc: Pascal Thubert (pthubert); nemo@ietf.org > Subject: Implementation requirements for the different modes (was Re: = [nemo] Issue 10) >=20 > Alexandru Petrescu wrote: >=20 > > > > But I have another related question. I was wondering whether there > > might be a necessity to clearly state in the draft which modes must = be > > implemented by whom for this to be a relevant spec. An example = would > > be: all MR's MUST implement at least "explicit prefixlen" and all = HA's > > must implement all three modes. This is just an example, I'm = looking to > > know whether it is good or not to be specific about what's mandatory = to > > be implemented. >=20 > good point. IMO, the Home Agent MUST implement all > modes in section 5.2. support for running an IGP over > the MR-HA tunnel is still optional. the MR may > implement any method it wants. >=20 > I made this issue 11. >=20 > proposed text >=20 > 6. Home Agent Operation >=20 > In order for a Mobile Router to operate correctly, the Home Agent > MUST satisfy all the requirements listed in section 8.4 of [1]. = The > Home Agent MUST implement all the modes described in Section 5.2. >=20 > as for the MR we already have some text in section 5.2 >=20 > The Mobile Router uses > one of the following modes to instruct the Home Agent to determine > the prefixes owned by the Mobile Router. >=20 > Vijay From exim@www1.ietf.org Tue Aug 5 03:09:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03907 for ; Tue, 5 Aug 2003 03:09:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jvwM-00059n-Cc for nemo-archive@odin.ietf.org; Tue, 05 Aug 2003 03:09:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75792Qt019709 for nemo-archive@odin.ietf.org; Tue, 5 Aug 2003 03:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jvwL-00057o-MV for nemo-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 03:09:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03887 for ; Tue, 5 Aug 2003 03:08:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jvwH-0000EU-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 03:08:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jvwH-0000ER-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 03:08:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jvwK-000575-Ge; Tue, 05 Aug 2003 03:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jvw3-00056g-9R for nemo@optimus.ietf.org; Tue, 05 Aug 2003 03:08:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03883 for ; Tue, 5 Aug 2003 03:08:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jvvz-0000EN-00 for nemo@ietf.org; Tue, 05 Aug 2003 03:08:39 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19jvvy-0000EK-00 for nemo@ietf.org; Tue, 05 Aug 2003 03:08:38 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Aug 2003 09:07:47 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h7575usY023002; Tue, 5 Aug 2003 09:05:56 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Aug 2003 09:08:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Implementation requirements for the different modes (was Re: [nemo] Issue 10) Date: Tue, 5 Aug 2003 08:08:07 +0100 Message-ID: Thread-Topic: Implementation requirements for the different modes (was Re: [nemo] Issue 10) Thread-Index: AcNarwM+iYLYLou1S06n66JvyeD+GgAcPTiA From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Alexandru Petrescu" Cc: X-OriginalArrivalTime: 05 Aug 2003 07:08:08.0545 (UTC) FILETIME=[52F62510:01C35B20] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Excellent :)=20 I understand from the discussion with Thierry that you could say=20 "The Mobile Router MUST support at least one of" to make it more = specific but this is minor... Pascal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: lundi 4 ao=FBt 2003 19:36 > To: Alexandru Petrescu > Cc: Pascal Thubert (pthubert); nemo@ietf.org > Subject: Implementation requirements for the different modes (was Re: = [nemo] Issue 10) >=20 > Alexandru Petrescu wrote: >=20 > > > > But I have another related question. I was wondering whether there > > might be a necessity to clearly state in the draft which modes must = be > > implemented by whom for this to be a relevant spec. An example = would > > be: all MR's MUST implement at least "explicit prefixlen" and all = HA's > > must implement all three modes. This is just an example, I'm = looking to > > know whether it is good or not to be specific about what's mandatory = to > > be implemented. >=20 > good point. IMO, the Home Agent MUST implement all > modes in section 5.2. support for running an IGP over > the MR-HA tunnel is still optional. the MR may > implement any method it wants. >=20 > I made this issue 11. >=20 > proposed text >=20 > 6. Home Agent Operation >=20 > In order for a Mobile Router to operate correctly, the Home Agent > MUST satisfy all the requirements listed in section 8.4 of [1]. = The > Home Agent MUST implement all the modes described in Section 5.2. >=20 > as for the MR we already have some text in section 5.2 >=20 > The Mobile Router uses > one of the following modes to instruct the Home Agent to determine > the prefixes owned by the Mobile Router. >=20 > Vijay From nemo-admin@ietf.org Tue Aug 5 03:26:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04211 for ; Tue, 5 Aug 2003 03:26:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jwCm-0005V3-Rr; Tue, 05 Aug 2003 03:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jwBs-0005U8-B4 for nemo@optimus.ietf.org; Tue, 05 Aug 2003 03:25:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04190 for ; Tue, 5 Aug 2003 03:25:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jw2r-0000FM-00 for nemo@ietf.org; Tue, 05 Aug 2003 03:15:45 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19jw2q-0000FF-00 for nemo@ietf.org; Tue, 05 Aug 2003 03:15:44 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Aug 2003 09:14:52 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h757Cxhb023991; Tue, 5 Aug 2003 09:13:01 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Aug 2003 09:15:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Implementation requirements for the different modes (wasRe: [nemo] Issue 10) Date: Tue, 5 Aug 2003 08:15:12 +0100 Message-ID: Thread-Topic: [nemo] Implementation requirements for the different modes (wasRe: [nemo] Issue 10) Thread-Index: AcNa8Ka3D5OOz1teTBuRMBYUcTtDGQAL72+g From: "Pascal Thubert (pthubert)" To: "Ryuji Wakikawa" , Cc: , , X-OriginalArrivalTime: 05 Aug 2003 07:15:13.0391 (UTC) FILETIME=[50307FF0:01C35B21] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable The Mobile Router can be a tiny embedded logic. It may be an IP = forwarder with no routing logic but Nemo itself. Please allow it to be = simple. IMHO, the modus operandi with static routes can be enough for = some situations with mass produced such devices. So unless you prove me = that we have an interoperability problem by allowing MRs that support = only static and implicit, please detail. Otherwise, I suggest we either: - keep saying that the MR MUST support at least one mode or - make static + implicit the minimum set.=20 Pascal > -----Original Message----- > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] > Sent: lundi 4 ao=FBt 2003 13:50 > To: ernst@sfc.wide.ad.jp > Cc: vijayd@IPRG.nokia.com; alexandru.petrescu@motorola.com; Pascal = Thubert (pthubert); > nemo@ietf.org > Subject: Re: [nemo] Implementation requirements for the different = modes (wasRe: [nemo] Issue > 10) >=20 >=20 > Hi, >=20 > At Tue, 5 Aug 2003 09:52:32 +0900, > Thierry Ernst wrote: > > > > > > Hi, > > > > > > This sounds reasonable to me to have only HA implementing all = modes. As > > > > for the HA, > > > > > > you mean the MR? > > > > Sorry, misstyping. Yes, MR. > > > > > > isn't it one of the modes that MUST at least be supported ? > > > > > > I thought thats obvious from the current text > > > > > > > The Mobile Router uses > > > > one of the following modes to instruct the Home Agent to = determine > > > > the prefixes owned by the Mobile Router. > > > > > > this means that the Mobile Router MUST implement one of the > > > modes. > > > > > > > What happens if 2 MRs in the same mobile network don't implement = the > > > > same mode ? > > > > > > shouldnt be a problem as long as the HA implements both. do > > > you see a problem? > > > > I don't see any specific problem but it may be one once we do some > > testing (?): what happens if a multihomed mobile network has 2 MRs, = and > > 1 MR uses implicit, the other uses explicit ? Will it work ? It this > > reasonable to allow this ? >=20 > I don't see any problem, neither:-) >=20 > I personally think this evaluation should be done in the multihoming > draft, but not in the basic. >=20 > regards, > ryuji From exim@www1.ietf.org Tue Aug 5 03:27:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04236 for ; Tue, 5 Aug 2003 03:27:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jwDi-0005ZV-AJ for nemo-archive@odin.ietf.org; Tue, 05 Aug 2003 03:26:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h757QwSF021417 for nemo-archive@odin.ietf.org; Tue, 5 Aug 2003 03:26:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jwDh-0005ZM-BZ for nemo-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 03:26:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04228 for ; Tue, 5 Aug 2003 03:26:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jwDf-0000IJ-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 03:26:55 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jwDe-0000IA-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 03:26:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jwCm-0005V3-Rr; Tue, 05 Aug 2003 03:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jwBs-0005U8-B4 for nemo@optimus.ietf.org; Tue, 05 Aug 2003 03:25:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04190 for ; Tue, 5 Aug 2003 03:25:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jw2r-0000FM-00 for nemo@ietf.org; Tue, 05 Aug 2003 03:15:45 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19jw2q-0000FF-00 for nemo@ietf.org; Tue, 05 Aug 2003 03:15:44 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Aug 2003 09:14:52 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h757Cxhb023991; Tue, 5 Aug 2003 09:13:01 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Aug 2003 09:15:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Implementation requirements for the different modes (wasRe: [nemo] Issue 10) Date: Tue, 5 Aug 2003 08:15:12 +0100 Message-ID: Thread-Topic: [nemo] Implementation requirements for the different modes (wasRe: [nemo] Issue 10) Thread-Index: AcNa8Ka3D5OOz1teTBuRMBYUcTtDGQAL72+g From: "Pascal Thubert (pthubert)" To: "Ryuji Wakikawa" , Cc: , , X-OriginalArrivalTime: 05 Aug 2003 07:15:13.0391 (UTC) FILETIME=[50307FF0:01C35B21] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The Mobile Router can be a tiny embedded logic. It may be an IP = forwarder with no routing logic but Nemo itself. Please allow it to be = simple. IMHO, the modus operandi with static routes can be enough for = some situations with mass produced such devices. So unless you prove me = that we have an interoperability problem by allowing MRs that support = only static and implicit, please detail. Otherwise, I suggest we either: - keep saying that the MR MUST support at least one mode or - make static + implicit the minimum set.=20 Pascal > -----Original Message----- > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] > Sent: lundi 4 ao=FBt 2003 13:50 > To: ernst@sfc.wide.ad.jp > Cc: vijayd@IPRG.nokia.com; alexandru.petrescu@motorola.com; Pascal = Thubert (pthubert); > nemo@ietf.org > Subject: Re: [nemo] Implementation requirements for the different = modes (wasRe: [nemo] Issue > 10) >=20 >=20 > Hi, >=20 > At Tue, 5 Aug 2003 09:52:32 +0900, > Thierry Ernst wrote: > > > > > > Hi, > > > > > > This sounds reasonable to me to have only HA implementing all = modes. As > > > > for the HA, > > > > > > you mean the MR? > > > > Sorry, misstyping. Yes, MR. > > > > > > isn't it one of the modes that MUST at least be supported ? > > > > > > I thought thats obvious from the current text > > > > > > > The Mobile Router uses > > > > one of the following modes to instruct the Home Agent to = determine > > > > the prefixes owned by the Mobile Router. > > > > > > this means that the Mobile Router MUST implement one of the > > > modes. > > > > > > > What happens if 2 MRs in the same mobile network don't implement = the > > > > same mode ? > > > > > > shouldnt be a problem as long as the HA implements both. do > > > you see a problem? > > > > I don't see any specific problem but it may be one once we do some > > testing (?): what happens if a multihomed mobile network has 2 MRs, = and > > 1 MR uses implicit, the other uses explicit ? Will it work ? It this > > reasonable to allow this ? >=20 > I don't see any problem, neither:-) >=20 > I personally think this evaluation should be done in the multihoming > draft, but not in the basic. >=20 > regards, > ryuji From nemo-admin@ietf.org Tue Aug 5 05:03:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05584 for ; Tue, 5 Aug 2003 05:03:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jxif-00087Q-Em; Tue, 05 Aug 2003 05:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jxic-00087F-Cu for nemo@optimus.ietf.org; Tue, 05 Aug 2003 05:02:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05574 for ; Tue, 5 Aug 2003 05:02:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jxiZ-0000eJ-00 for nemo@ietf.org; Tue, 05 Aug 2003 05:02:55 -0400 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx with smtp (Exim 4.12) id 19jxiY-0000eF-00 for nemo@ietf.org; Tue, 05 Aug 2003 05:02:54 -0400 Received: From mustafa ([129.94.172.200] == mustafa.cse.unsw.EDU.AU) (for ) By note With Smtp ; Tue, 5 Aug 2003 19:02:47 +1000 From: "Muhammad Ali Malik" To: Date: Tue, 5 Aug 2003 19:02:54 +1000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C35B84.2D3BCB90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: [nemo] message travelling over bi-directional tunnel. Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C35B84.2D3BCB90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Do the message traveling from home agent of MR to MR-CoA will always took the same path as message from MR-CoA to MR-Home agent. In other words, do the message traveling on bi-directional tunnel in each direction will always take the same path. Regards, Muhammad Ali Malik ------=_NextPart_000_0009_01C35B84.2D3BCB90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

Do the message traveling from home agent of MR to MR-CoA will = always took the same path as message from MR-CoA to MR-Home = agent.

In other words, do the message traveling on bi-directional tunnel = in each direction will always take the same = path.

 

Regards,

 

Muhammad Ali Malik

------=_NextPart_000_0009_01C35B84.2D3BCB90-- From exim@www1.ietf.org Tue Aug 5 05:03:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05599 for ; Tue, 5 Aug 2003 05:03:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jxij-00088M-69 for nemo-archive@odin.ietf.org; Tue, 05 Aug 2003 05:03:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75935EO031260 for nemo-archive@odin.ietf.org; Tue, 5 Aug 2003 05:03:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jxii-000887-Vk for nemo-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 05:03:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05578 for ; Tue, 5 Aug 2003 05:03:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jxif-0000eP-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 05:03:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jxif-0000eM-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 05:03:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jxif-00087Q-Em; Tue, 05 Aug 2003 05:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jxic-00087F-Cu for nemo@optimus.ietf.org; Tue, 05 Aug 2003 05:02:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05574 for ; Tue, 5 Aug 2003 05:02:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jxiZ-0000eJ-00 for nemo@ietf.org; Tue, 05 Aug 2003 05:02:55 -0400 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx with smtp (Exim 4.12) id 19jxiY-0000eF-00 for nemo@ietf.org; Tue, 05 Aug 2003 05:02:54 -0400 Received: From mustafa ([129.94.172.200] == mustafa.cse.unsw.EDU.AU) (for ) By note With Smtp ; Tue, 5 Aug 2003 19:02:47 +1000 From: "Muhammad Ali Malik" To: Date: Tue, 5 Aug 2003 19:02:54 +1000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C35B84.2D3BCB90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: [nemo] message travelling over bi-directional tunnel. Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C35B84.2D3BCB90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Do the message traveling from home agent of MR to MR-CoA will always took the same path as message from MR-CoA to MR-Home agent. In other words, do the message traveling on bi-directional tunnel in each direction will always take the same path. Regards, Muhammad Ali Malik ------=_NextPart_000_0009_01C35B84.2D3BCB90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

Do the message traveling from home agent of MR to MR-CoA will = always took the same path as message from MR-CoA to MR-Home = agent.

In other words, do the message traveling on bi-directional tunnel = in each direction will always take the same = path.

 

Regards,

 

Muhammad Ali Malik

------=_NextPart_000_0009_01C35B84.2D3BCB90-- From nemo-admin@ietf.org Tue Aug 5 05:56:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06317 for ; Tue, 5 Aug 2003 05:56:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jyXx-0001LJ-So; Tue, 05 Aug 2003 05:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jyXL-0001KA-7j for nemo@optimus.ietf.org; Tue, 05 Aug 2003 05:55:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06287 for ; Tue, 5 Aug 2003 05:55:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jyXH-0000sv-00 for nemo@ietf.org; Tue, 05 Aug 2003 05:55:19 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19jyXG-0000sg-00 for nemo@ietf.org; Tue, 05 Aug 2003 05:55:19 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Aug 2003 11:54:26 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h759qJ9A028276; Tue, 5 Aug 2003 11:52:36 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Aug 2003 11:54:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35B37.91387F96" Subject: RE: [nemo] message travelling over bi-directional tunnel. Date: Tue, 5 Aug 2003 10:54:31 +0100 Message-ID: Thread-Topic: [nemo] message travelling over bi-directional tunnel. Thread-Index: AcNbMla0BFEZ2L4QQP6sZDZHOnVKhAABFEZg From: "Pascal Thubert (pthubert)" To: "Muhammad Ali Malik" , X-OriginalArrivalTime: 05 Aug 2003 09:54:32.0116 (UTC) FILETIME=[91A22F40:01C35B37] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C35B37.91387F96 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The tunnel is still an IP packet. So the answer is no, not necessarily. =20 Pascal =20 -----Original Message----- From: Muhammad Ali Malik [mailto:mamalik@cse.unsw.edu.au]=20 Sent: mardi 5 ao=FBt 2003 11:03 To: nemo@ietf.org Subject: [nemo] message travelling over bi-directional tunnel. =20 Hi =20 Do the message traveling from home agent of MR to MR-CoA will always = took the same path as message from MR-CoA to MR-Home agent. In other words, do the message traveling on bi-directional tunnel in = each direction will always take the same path. =20 Regards, =20 Muhammad Ali Malik ------_=_NextPart_001_01C35B37.91387F96 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The tunnel is still an IP packet. = So the answer is no, not necessarily.

 

Pascal

 

-----Original Message-----
From: Muhammad Ali Malik [mailto:mamalik@cse.unsw.edu.au]
Sent: mardi 5 ao=FBt 2003 = 11:03
To: nemo@ietf.org
Subject: [nemo] message = travelling over bi-directional tunnel.

 

Hi

 

Do the message traveling = from home agent of MR to MR-CoA will always took the same path as message from = MR-CoA to MR-Home agent.

In other words, do the = message traveling on bi-directional tunnel in each direction will always take = the same path.

 

Regards,

 

Muhammad Ali = Malik

------_=_NextPart_001_01C35B37.91387F96-- From exim@www1.ietf.org Tue Aug 5 05:56:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06332 for ; Tue, 5 Aug 2003 05:56:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jyY0-0001MD-92 for nemo-archive@odin.ietf.org; Tue, 05 Aug 2003 05:56:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h759u45e005213 for nemo-archive@odin.ietf.org; Tue, 5 Aug 2003 05:56:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jyY0-0001M0-0l for nemo-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 05:56:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06314 for ; Tue, 5 Aug 2003 05:55:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jyXw-0000tP-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 05:56:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jyXv-0000tM-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 05:55:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jyXx-0001LJ-So; Tue, 05 Aug 2003 05:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jyXL-0001KA-7j for nemo@optimus.ietf.org; Tue, 05 Aug 2003 05:55:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06287 for ; Tue, 5 Aug 2003 05:55:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jyXH-0000sv-00 for nemo@ietf.org; Tue, 05 Aug 2003 05:55:19 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19jyXG-0000sg-00 for nemo@ietf.org; Tue, 05 Aug 2003 05:55:19 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Aug 2003 11:54:26 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h759qJ9A028276; Tue, 5 Aug 2003 11:52:36 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Aug 2003 11:54:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35B37.91387F96" Subject: RE: [nemo] message travelling over bi-directional tunnel. Date: Tue, 5 Aug 2003 10:54:31 +0100 Message-ID: Thread-Topic: [nemo] message travelling over bi-directional tunnel. Thread-Index: AcNbMla0BFEZ2L4QQP6sZDZHOnVKhAABFEZg From: "Pascal Thubert (pthubert)" To: "Muhammad Ali Malik" , X-OriginalArrivalTime: 05 Aug 2003 09:54:32.0116 (UTC) FILETIME=[91A22F40:01C35B37] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C35B37.91387F96 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The tunnel is still an IP packet. So the answer is no, not necessarily. =20 Pascal =20 -----Original Message----- From: Muhammad Ali Malik [mailto:mamalik@cse.unsw.edu.au]=20 Sent: mardi 5 ao=FBt 2003 11:03 To: nemo@ietf.org Subject: [nemo] message travelling over bi-directional tunnel. =20 Hi =20 Do the message traveling from home agent of MR to MR-CoA will always = took the same path as message from MR-CoA to MR-Home agent. In other words, do the message traveling on bi-directional tunnel in = each direction will always take the same path. =20 Regards, =20 Muhammad Ali Malik ------_=_NextPart_001_01C35B37.91387F96 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The tunnel is still an IP packet. = So the answer is no, not necessarily.

 

Pascal

 

-----Original Message-----
From: Muhammad Ali Malik [mailto:mamalik@cse.unsw.edu.au]
Sent: mardi 5 ao=FBt 2003 = 11:03
To: nemo@ietf.org
Subject: [nemo] message = travelling over bi-directional tunnel.

 

Hi

 

Do the message traveling = from home agent of MR to MR-CoA will always took the same path as message from = MR-CoA to MR-Home agent.

In other words, do the = message traveling on bi-directional tunnel in each direction will always take = the same path.

 

Regards,

 

Muhammad Ali = Malik

------_=_NextPart_001_01C35B37.91387F96-- From nemo-admin@ietf.org Tue Aug 5 06:28:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06682 for ; Tue, 5 Aug 2003 06:28:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jz2v-00026t-0B; Tue, 05 Aug 2003 06:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jz1y-00025m-G5 for nemo@optimus.ietf.org; Tue, 05 Aug 2003 06:27:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06658 for ; Tue, 5 Aug 2003 06:26:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jz1u-00011G-00 for nemo@ietf.org; Tue, 05 Aug 2003 06:26:58 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19jz1s-00011D-00 for nemo@ietf.org; Tue, 05 Aug 2003 06:26:57 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h75AQ6s2013733; Tue, 5 Aug 2003 03:26:07 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h75APrKl019606; Tue, 5 Aug 2003 05:25:54 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 2A84E2EC86; Tue, 5 Aug 2003 12:26:04 +0200 (CEST) Message-ID: <3F2F863C.4090804@motorola.com> Date: Tue, 05 Aug 2003 12:26:04 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: Ryuji Wakikawa , ernst@sfc.wide.ad.jp, vijayd@IPRG.nokia.com, nemo@ietf.org Subject: Re: [nemo] Implementation requirements for the different modes (wasRe: [nemo] Issue 10) References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > The Mobile Router can be a tiny embedded logic. It may be an IP > forwarder with no routing logic but Nemo itself. Please allow it to > be simple. IMHO, the modus operandi with static routes can be enough > for some situations with mass produced such devices. So unless you > prove me that we have an interoperability problem by allowing MRs > that support only static and implicit, please detail. > > Otherwise, I suggest we either: > > - keep saying that the MR MUST support at least one mode > or > - make static + implicit the minimum set. I favour the latter since it seems to require the minimum effort in terms of additional implementation on top of Mobile IPv6 IMHO. Alex From exim@www1.ietf.org Tue Aug 5 06:28:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06697 for ; Tue, 5 Aug 2003 06:28:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jz30-00027p-UA for nemo-archive@odin.ietf.org; Tue, 05 Aug 2003 06:28:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75AS6uE008164 for nemo-archive@odin.ietf.org; Tue, 5 Aug 2003 06:28:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jz30-00027b-O8 for nemo-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 06:28:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06663 for ; Tue, 5 Aug 2003 06:28:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jz2w-00011k-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 06:28:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jz2w-00011h-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 06:28:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jz2v-00026t-0B; Tue, 05 Aug 2003 06:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jz1y-00025m-G5 for nemo@optimus.ietf.org; Tue, 05 Aug 2003 06:27:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06658 for ; Tue, 5 Aug 2003 06:26:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jz1u-00011G-00 for nemo@ietf.org; Tue, 05 Aug 2003 06:26:58 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19jz1s-00011D-00 for nemo@ietf.org; Tue, 05 Aug 2003 06:26:57 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h75AQ6s2013733; Tue, 5 Aug 2003 03:26:07 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h75APrKl019606; Tue, 5 Aug 2003 05:25:54 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 2A84E2EC86; Tue, 5 Aug 2003 12:26:04 +0200 (CEST) Message-ID: <3F2F863C.4090804@motorola.com> Date: Tue, 05 Aug 2003 12:26:04 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: Ryuji Wakikawa , ernst@sfc.wide.ad.jp, vijayd@IPRG.nokia.com, nemo@ietf.org Subject: Re: [nemo] Implementation requirements for the different modes (wasRe: [nemo] Issue 10) References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > The Mobile Router can be a tiny embedded logic. It may be an IP > forwarder with no routing logic but Nemo itself. Please allow it to > be simple. IMHO, the modus operandi with static routes can be enough > for some situations with mass produced such devices. So unless you > prove me that we have an interoperability problem by allowing MRs > that support only static and implicit, please detail. > > Otherwise, I suggest we either: > > - keep saying that the MR MUST support at least one mode > or > - make static + implicit the minimum set. I favour the latter since it seems to require the minimum effort in terms of additional implementation on top of Mobile IPv6 IMHO. Alex From nemo-admin@ietf.org Tue Aug 5 07:53:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07778 for ; Tue, 5 Aug 2003 07:53:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k0NA-0003zC-RJ; Tue, 05 Aug 2003 07:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k0MU-0003yu-8H for nemo@optimus.ietf.org; Tue, 05 Aug 2003 07:52:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07757 for ; Tue, 5 Aug 2003 07:52:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k0MT-0001No-00 for nemo@ietf.org; Tue, 05 Aug 2003 07:52:17 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 19k0MS-0001Ng-00 for nemo@ietf.org; Tue, 05 Aug 2003 07:52:16 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 1D30168953 for ; Tue, 5 Aug 2003 07:51:46 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h75BpjrE022605; Tue, 5 Aug 2003 07:51:45 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (gr7700006462.grc.nasa.gov [139.88.111.44]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h75Bphdp021748; Tue, 5 Aug 2003 07:51:43 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030805074929.02130010@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 05 Aug 2003 07:51:43 -0400 To: "Muhammad Ali Malik" From: William D Ivancic Subject: Re: [nemo] message travelling over bi-directional tunnel. Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_84993003==.ALT" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --=====================_84993003==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I don't think we should be required or assumed that the bi-directional tunnel in each direction always takes the same path. This would preclude utilizing architectures and technologies such as unidirectional link routing. Will At 07:02 PM 8/5/2003 +1000, Muhammad Ali Malik wrote: >Hi > > > >Do the message traveling from home agent of MR to MR-CoA will always took >the same path as message from MR-CoA to MR-Home agent. > >In other words, do the message traveling on bi-directional tunnel in each >direction will always take the same path. > > > >Regards, > > > >Muhammad Ali Malik --=====================_84993003==.ALT Content-Type: text/html; charset="us-ascii" I don't think we should be required or assumed that the bi-directional tunnel in each direction always takes the same path.  This would preclude utilizing architectures and technologies such as unidirectional link routing.

Will

At 07:02 PM 8/5/2003 +1000, Muhammad Ali Malik wrote:

Hi

 

Do the message traveling from home agent of MR to MR-CoA will always took the same path as message from MR-CoA to MR-Home agent.

In other words, do the message traveling on bi-directional tunnel in each direction will always take the same path.

 

Regards,

 

Muhammad Ali Malik
--=====================_84993003==.ALT-- From exim@www1.ietf.org Tue Aug 5 07:53:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07793 for ; Tue, 5 Aug 2003 07:53:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k0NG-000405-He for nemo-archive@odin.ietf.org; Tue, 05 Aug 2003 07:53:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75Br6TS015375 for nemo-archive@odin.ietf.org; Tue, 5 Aug 2003 07:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k0NG-0003zu-47 for nemo-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 07:53:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07766 for ; Tue, 5 Aug 2003 07:53:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k0NF-0001O0-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 07:53:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k0NE-0001Nw-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 07:53:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k0NA-0003zC-RJ; Tue, 05 Aug 2003 07:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k0MU-0003yu-8H for nemo@optimus.ietf.org; Tue, 05 Aug 2003 07:52:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07757 for ; Tue, 5 Aug 2003 07:52:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k0MT-0001No-00 for nemo@ietf.org; Tue, 05 Aug 2003 07:52:17 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 19k0MS-0001Ng-00 for nemo@ietf.org; Tue, 05 Aug 2003 07:52:16 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 1D30168953 for ; Tue, 5 Aug 2003 07:51:46 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h75BpjrE022605; Tue, 5 Aug 2003 07:51:45 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (gr7700006462.grc.nasa.gov [139.88.111.44]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h75Bphdp021748; Tue, 5 Aug 2003 07:51:43 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030805074929.02130010@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 05 Aug 2003 07:51:43 -0400 To: "Muhammad Ali Malik" From: William D Ivancic Subject: Re: [nemo] message travelling over bi-directional tunnel. Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_84993003==.ALT" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --=====================_84993003==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I don't think we should be required or assumed that the bi-directional tunnel in each direction always takes the same path. This would preclude utilizing architectures and technologies such as unidirectional link routing. Will At 07:02 PM 8/5/2003 +1000, Muhammad Ali Malik wrote: >Hi > > > >Do the message traveling from home agent of MR to MR-CoA will always took >the same path as message from MR-CoA to MR-Home agent. > >In other words, do the message traveling on bi-directional tunnel in each >direction will always take the same path. > > > >Regards, > > > >Muhammad Ali Malik --=====================_84993003==.ALT Content-Type: text/html; charset="us-ascii" I don't think we should be required or assumed that the bi-directional tunnel in each direction always takes the same path.  This would preclude utilizing architectures and technologies such as unidirectional link routing.

Will

At 07:02 PM 8/5/2003 +1000, Muhammad Ali Malik wrote:

Hi

 

Do the message traveling from home agent of MR to MR-CoA will always took the same path as message from MR-CoA to MR-Home agent.

In other words, do the message traveling on bi-directional tunnel in each direction will always take the same path.

 

Regards,

 

Muhammad Ali Malik
--=====================_84993003==.ALT-- From nemo-admin@ietf.org Tue Aug 5 08:00:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08120 for ; Tue, 5 Aug 2003 08:00:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k0Tx-0004Bv-Lg; Tue, 05 Aug 2003 08:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k0TO-00049y-Ml for nemo@optimus.ietf.org; Tue, 05 Aug 2003 07:59:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08089 for ; Tue, 5 Aug 2003 07:59:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k0TN-0001QD-00 for nemo@ietf.org; Tue, 05 Aug 2003 07:59:25 -0400 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx with smtp (Exim 4.12) id 19k0TN-0001Q1-00 for nemo@ietf.org; Tue, 05 Aug 2003 07:59:25 -0400 Received: From mozart With LocalMail ; Tue, 5 Aug 2003 21:58:41 +1000 From: Muhammad Ali Malik To: nemo@ietf.org Date: Tue, 5 Aug 2003 21:58:41 +1000 (EST) X-X-Sender: mamalik@mozart.orchestra.cse.unsw.EDU.AU Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [nemo] RSVP tunnel over bi-directional tunnel of NEMO Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Can somebody address an issues if RSVP tunneling protocol is used over NEMO bi-directional tunnel. Regards, Ali From exim@www1.ietf.org Tue Aug 5 08:00:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08135 for ; Tue, 5 Aug 2003 08:00:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k0Tz-0004Cs-1l for nemo-archive@odin.ietf.org; Tue, 05 Aug 2003 08:00:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75C03OS016164 for nemo-archive@odin.ietf.org; Tue, 5 Aug 2003 08:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k0Ty-0004Cd-Tr for nemo-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 08:00:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08098 for ; Tue, 5 Aug 2003 07:59:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k0Ty-0001QR-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 08:00:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k0Tx-0001QO-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 08:00:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k0Tx-0004Bv-Lg; Tue, 05 Aug 2003 08:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k0TO-00049y-Ml for nemo@optimus.ietf.org; Tue, 05 Aug 2003 07:59:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08089 for ; Tue, 5 Aug 2003 07:59:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k0TN-0001QD-00 for nemo@ietf.org; Tue, 05 Aug 2003 07:59:25 -0400 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx with smtp (Exim 4.12) id 19k0TN-0001Q1-00 for nemo@ietf.org; Tue, 05 Aug 2003 07:59:25 -0400 Received: From mozart With LocalMail ; Tue, 5 Aug 2003 21:58:41 +1000 From: Muhammad Ali Malik To: nemo@ietf.org Date: Tue, 5 Aug 2003 21:58:41 +1000 (EST) X-X-Sender: mamalik@mozart.orchestra.cse.unsw.EDU.AU Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [nemo] RSVP tunnel over bi-directional tunnel of NEMO Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Can somebody address an issues if RSVP tunneling protocol is used over NEMO bi-directional tunnel. Regards, Ali From nemo-admin@ietf.org Tue Aug 5 10:16:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12990 for ; Tue, 5 Aug 2003 10:16:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2bb-0000ga-Ca; Tue, 05 Aug 2003 10:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2bW-0000fR-If for nemo@optimus.ietf.org; Tue, 05 Aug 2003 10:15:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12839; Tue, 5 Aug 2003 10:15:37 -0400 (EDT) Message-Id: <200308051415.KAA12839@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com, ipsec@lists.tislabs.com, nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 05 Aug 2003 10:15:36 -0400 Subject: [nemo] I-D ACTION:draft-ivancic-layer3-encryptors-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Use And Implementation of Layer-3 Encryption Devices Author(s) : W. Ivancic, D. Stewart Filename : draft-ivancic-layer3-encryptors-00.txt Pages : 6 Date : 2003-8-5 This document describes some issues related to performing encryption at layer-3. In particular, routing protocol problems may result if the time-to-live (TTL) field in IPv4 or the Hop Limit field in IPv6 is decremented once before encapsulation [1][2]. Also, special provisions may be necessary within the encryptor devices if broadcast messages are to transition the encryptor pairs. Maximum Transmission Unit (MTU) issues are also presented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ivancic-layer3-encryptors-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ivancic-layer3-encryptors-00.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-ivancic-layer3-encryptors-00.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-5100517.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ivancic-layer3-encryptors-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ivancic-layer3-encryptors-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-5100517.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Tue Aug 5 10:16:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13035 for ; Tue, 5 Aug 2003 10:16:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2bg-0000jt-Rd for nemo-archive@odin.ietf.org; Tue, 05 Aug 2003 10:16:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75EG8Ju002835 for nemo-archive@odin.ietf.org; Tue, 5 Aug 2003 10:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2bg-0000je-Nb for nemo-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 10:16:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12909 for ; Tue, 5 Aug 2003 10:16:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k2be-0002IU-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 10:16:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k2bd-0002IR-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 10:16:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2bb-0000ga-Ca; Tue, 05 Aug 2003 10:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2bW-0000fR-If for nemo@optimus.ietf.org; Tue, 05 Aug 2003 10:15:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12839; Tue, 5 Aug 2003 10:15:37 -0400 (EDT) Message-Id: <200308051415.KAA12839@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com, ipsec@lists.tislabs.com, nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 05 Aug 2003 10:15:36 -0400 Subject: [nemo] I-D ACTION:draft-ivancic-layer3-encryptors-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Use And Implementation of Layer-3 Encryption Devices Author(s) : W. Ivancic, D. Stewart Filename : draft-ivancic-layer3-encryptors-00.txt Pages : 6 Date : 2003-8-5 This document describes some issues related to performing encryption at layer-3. In particular, routing protocol problems may result if the time-to-live (TTL) field in IPv4 or the Hop Limit field in IPv6 is decremented once before encapsulation [1][2]. Also, special provisions may be necessary within the encryptor devices if broadcast messages are to transition the encryptor pairs. Maximum Transmission Unit (MTU) issues are also presented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ivancic-layer3-encryptors-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ivancic-layer3-encryptors-00.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-ivancic-layer3-encryptors-00.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-5100517.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ivancic-layer3-encryptors-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ivancic-layer3-encryptors-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-5100517.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-admin@ietf.org Tue Aug 5 13:23:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19610 for ; Tue, 5 Aug 2003 13:23:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5WW-0008Mv-O8; Tue, 05 Aug 2003 13:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5Vq-0008Lv-TC for nemo@optimus.ietf.org; Tue, 05 Aug 2003 13:22:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19597 for ; Tue, 5 Aug 2003 13:22:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k5Vo-00041C-00 for nemo@ietf.org; Tue, 05 Aug 2003 13:22:17 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19k5Vn-000417-00 for nemo@ietf.org; Tue, 05 Aug 2003 13:22:16 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA10691; Tue, 5 Aug 2003 10:21:44 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h75HLia22536; Tue, 5 Aug 2003 10:21:44 -0700 X-mProtect: <200308051721> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqYEeSj; Tue, 05 Aug 2003 10:21:42 PDT Message-ID: <3F2FE7A6.F5AD7BFE@iprg.nokia.com> Date: Tue, 05 Aug 2003 10:21:42 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: "Pascal Thubert (pthubert)" , Ryuji Wakikawa , ernst@sfc.wide.ad.jp, nemo@ietf.org Subject: Re: [nemo] Implementation requirements for the different modes (wasRe:[nemo] Issue 10) References: <3F2F863C.4090804@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > Pascal Thubert (pthubert) wrote: > > The Mobile Router can be a tiny embedded logic. It may be an IP > > forwarder with no routing logic but Nemo itself. Please allow it to > > be simple. IMHO, the modus operandi with static routes can be enough > > for some situations with mass produced such devices. So unless you > > prove me that we have an interoperability problem by allowing MRs > > that support only static and implicit, please detail. > > > > Otherwise, I suggest we either: > > > > - keep saying that the MR MUST support at least one mode > > or > > - make static + implicit the minimum set. > > I favour the latter since it seems to require the minimum effort in > terms of additional implementation on top of Mobile IPv6 IMHO. I prefer saying the MR MUST support at least one mode (which the text already says). IMHO, the explicit network mode will be most widely used. this gives you the maximum flexibility of setting forwarding for specific prefixes when there are multiple MNPs in the mobile network. anyway it is too early to tell. Vijay From exim@www1.ietf.org Tue Aug 5 13:23:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19625 for ; Tue, 5 Aug 2003 13:23:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5Wb-0008No-6z for nemo-archive@odin.ietf.org; Tue, 05 Aug 2003 13:23:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75HN5cA032222 for nemo-archive@odin.ietf.org; Tue, 5 Aug 2003 13:23:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5Wb-0008Nd-1X for nemo-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 13:23:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19603 for ; Tue, 5 Aug 2003 13:22:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k5WZ-00041K-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 13:23:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k5WY-00041H-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 13:23:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5WW-0008Mv-O8; Tue, 05 Aug 2003 13:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5Vq-0008Lv-TC for nemo@optimus.ietf.org; Tue, 05 Aug 2003 13:22:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19597 for ; Tue, 5 Aug 2003 13:22:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k5Vo-00041C-00 for nemo@ietf.org; Tue, 05 Aug 2003 13:22:17 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19k5Vn-000417-00 for nemo@ietf.org; Tue, 05 Aug 2003 13:22:16 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA10691; Tue, 5 Aug 2003 10:21:44 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h75HLia22536; Tue, 5 Aug 2003 10:21:44 -0700 X-mProtect: <200308051721> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqYEeSj; Tue, 05 Aug 2003 10:21:42 PDT Message-ID: <3F2FE7A6.F5AD7BFE@iprg.nokia.com> Date: Tue, 05 Aug 2003 10:21:42 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: "Pascal Thubert (pthubert)" , Ryuji Wakikawa , ernst@sfc.wide.ad.jp, nemo@ietf.org Subject: Re: [nemo] Implementation requirements for the different modes (wasRe:[nemo] Issue 10) References: <3F2F863C.4090804@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > Pascal Thubert (pthubert) wrote: > > The Mobile Router can be a tiny embedded logic. It may be an IP > > forwarder with no routing logic but Nemo itself. Please allow it to > > be simple. IMHO, the modus operandi with static routes can be enough > > for some situations with mass produced such devices. So unless you > > prove me that we have an interoperability problem by allowing MRs > > that support only static and implicit, please detail. > > > > Otherwise, I suggest we either: > > > > - keep saying that the MR MUST support at least one mode > > or > > - make static + implicit the minimum set. > > I favour the latter since it seems to require the minimum effort in > terms of additional implementation on top of Mobile IPv6 IMHO. I prefer saying the MR MUST support at least one mode (which the text already says). IMHO, the explicit network mode will be most widely used. this gives you the maximum flexibility of setting forwarding for specific prefixes when there are multiple MNPs in the mobile network. anyway it is too early to tell. Vijay From nemo-admin@ietf.org Tue Aug 5 13:53:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20480 for ; Tue, 5 Aug 2003 13:53:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5zZ-0000sl-2n; Tue, 05 Aug 2003 13:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5yd-0000sD-LA for nemo@optimus.ietf.org; Tue, 05 Aug 2003 13:52:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20454 for ; Tue, 5 Aug 2003 13:51:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k5yb-0004Gu-00 for nemo@ietf.org; Tue, 05 Aug 2003 13:52:01 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19k5yZ-0004Gl-00 for nemo@ietf.org; Tue, 05 Aug 2003 13:52:00 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA12110; Tue, 5 Aug 2003 10:51:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h75HpTS26472; Tue, 5 Aug 2003 10:51:29 -0700 X-mProtect: <200308051751> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZ0kAIs; Tue, 05 Aug 2003 10:51:27 PDT Message-ID: <3F2FEE9F.497B71F2@iprg.nokia.com> Date: Tue, 05 Aug 2003 10:51:27 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: nemo@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Issue 10 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Pascal Thubert (pthubert)" wrote: > > > status code 143 is not supposed to be used when an IGP > > is being run over the MR-HA tunnel. when an IGP is being > > used, the HA just waits for the routing protocol updates > > from the MR and does not attempt to create any routes if > > the BU did not contain any prefix information. > > > > Yes, that's the key. I would agree with the 143 if it was sure between > HA and MR that they are talking about implicit, the real one, as opposed > to static or IGP. That would be the only reason at this time to have an > implicit bit in the BU/BA, so that the HA can answer 143 if it is > expected to have MNP information in a Nemo specific config that we > usually refer to as prefix table, and can not find it. > > So I'd say it's either (NO 143) or (143 AND implicit bit). What do you > think? you are hung up on the prefix table. :) forget it for the moment. implicit mode was supposed to cover every mechanism under which the HA is in control of adding/activating/maintaining routes to the mobile network. if this is not clear in the spec, lets correct the text. the MR has control only in the two explicit modes and when an IGP is being run over the MR-HA tunnel. FWIW, I dislike any mode where the MR is not in control. but that doesnt matter. implicit mode includes static routes. it includes prefix table. it includes any proprietary mechanism that you implement on the HA. it is internal to the HA and there is no interoperability problem. but if the HA for some reason is not able to setup forwarding to the mobile network in the implicit mode, then we need a Binding Ack status to indicate this. we can change 143 to mean "forwarding setup failed". if we cant agree on this, I would suggest removing implicit mode with static routes from the spec and writing up a short separate spec on how to do it. we already have too many mechanisms/modes in the spec. I am not sure the IESG is going to like these many different mechanisms of doing the same thing. Vijay From exim@www1.ietf.org Tue Aug 5 13:53:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20495 for ; Tue, 5 Aug 2003 13:53:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5zc-0000to-Mo for nemo-archive@odin.ietf.org; Tue, 05 Aug 2003 13:53:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75Hr4Rb003450 for nemo-archive@odin.ietf.org; Tue, 5 Aug 2003 13:53:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5zc-0000tZ-Ix for nemo-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 13:53:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20469 for ; Tue, 5 Aug 2003 13:53:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k5za-0004HR-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 13:53:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k5zZ-0004HO-00 for nemo-web-archive@ietf.org; Tue, 05 Aug 2003 13:53:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5zZ-0000sl-2n; Tue, 05 Aug 2003 13:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k5yd-0000sD-LA for nemo@optimus.ietf.org; Tue, 05 Aug 2003 13:52:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20454 for ; Tue, 5 Aug 2003 13:51:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k5yb-0004Gu-00 for nemo@ietf.org; Tue, 05 Aug 2003 13:52:01 -0400 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by ietf-mx with esmtp (Exim 4.12) id 19k5yZ-0004Gl-00 for nemo@ietf.org; Tue, 05 Aug 2003 13:52:00 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA12110; Tue, 5 Aug 2003 10:51:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h75HpTS26472; Tue, 5 Aug 2003 10:51:29 -0700 X-mProtect: <200308051751> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZ0kAIs; Tue, 05 Aug 2003 10:51:27 PDT Message-ID: <3F2FEE9F.497B71F2@iprg.nokia.com> Date: Tue, 05 Aug 2003 10:51:27 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: nemo@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Issue 10 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Pascal Thubert (pthubert)" wrote: > > > status code 143 is not supposed to be used when an IGP > > is being run over the MR-HA tunnel. when an IGP is being > > used, the HA just waits for the routing protocol updates > > from the MR and does not attempt to create any routes if > > the BU did not contain any prefix information. > > > > Yes, that's the key. I would agree with the 143 if it was sure between > HA and MR that they are talking about implicit, the real one, as opposed > to static or IGP. That would be the only reason at this time to have an > implicit bit in the BU/BA, so that the HA can answer 143 if it is > expected to have MNP information in a Nemo specific config that we > usually refer to as prefix table, and can not find it. > > So I'd say it's either (NO 143) or (143 AND implicit bit). What do you > think? you are hung up on the prefix table. :) forget it for the moment. implicit mode was supposed to cover every mechanism under which the HA is in control of adding/activating/maintaining routes to the mobile network. if this is not clear in the spec, lets correct the text. the MR has control only in the two explicit modes and when an IGP is being run over the MR-HA tunnel. FWIW, I dislike any mode where the MR is not in control. but that doesnt matter. implicit mode includes static routes. it includes prefix table. it includes any proprietary mechanism that you implement on the HA. it is internal to the HA and there is no interoperability problem. but if the HA for some reason is not able to setup forwarding to the mobile network in the implicit mode, then we need a Binding Ack status to indicate this. we can change 143 to mean "forwarding setup failed". if we cant agree on this, I would suggest removing implicit mode with static routes from the spec and writing up a short separate spec on how to do it. we already have too many mechanisms/modes in the spec. I am not sure the IESG is going to like these many different mechanisms of doing the same thing. Vijay From nemo-admin@ietf.org Wed Aug 6 02:46:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07461 for ; Wed, 6 Aug 2003 02:46:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kI3d-0001Me-Ok; Wed, 06 Aug 2003 02:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kI3V-0001MH-Nf for nemo@optimus.ietf.org; Wed, 06 Aug 2003 02:45:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07454 for ; Wed, 6 Aug 2003 02:45:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kI3R-0000uA-00 for nemo@ietf.org; Wed, 06 Aug 2003 02:45:50 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19kI3R-0000tz-00 for nemo@ietf.org; Wed, 06 Aug 2003 02:45:49 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 06 Aug 2003 08:44:55 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h766h68O007362; Wed, 6 Aug 2003 08:43:06 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Aug 2003 08:45:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Aug 2003 07:45:17 +0100 Message-ID: Thread-Topic: Issue 10 Thread-Index: AcNbelSeRXxnV2hFR2+c8S0rHvr6gAAa9TMw From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 06 Aug 2003 06:45:18.0269 (UTC) FILETIME=[4CA05ED0:01C35BE6] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Issue 10 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mardi 5 ao=FBt 2003 19:51 > To: Pascal Thubert (pthubert) > Cc: nemo@ietf.org > Subject: Re: Issue 10 >=20 > "Pascal Thubert (pthubert)" wrote: > > > > > status code 143 is not supposed to be used when an IGP > > > is being run over the MR-HA tunnel. when an IGP is being > > > used, the HA just waits for the routing protocol updates > > > from the MR and does not attempt to create any routes if > > > the BU did not contain any prefix information. > > > > > > > Yes, that's the key. I would agree with the 143 if it was sure = between > > HA and MR that they are talking about implicit, the real one, as = opposed > > to static or IGP. That would be the only reason at this time to have = an > > implicit bit in the BU/BA, so that the HA can answer 143 if it is > > expected to have MNP information in a Nemo specific config that we > > usually refer to as prefix table, and can not find it. > > > > So I'd say it's either (NO 143) or (143 AND implicit bit). What do = you > > think? >=20 > you are hung up on the prefix table. :) forget it for the > moment. implicit mode was supposed to cover every mechanism > under which the HA is in control of adding/activating/maintaining > routes to the mobile network. if this is not clear in the > spec, lets correct the text. the MR has control only in the > two explicit modes and when an IGP is being run over the > MR-HA tunnel. >=20 > FWIW, I dislike any mode where the MR is not in control. > but that doesnt matter. >=20 > implicit mode includes static routes. it includes prefix > table. it includes any proprietary mechanism that you > implement on the HA. it is internal to the HA and there > is no interoperability problem. >=20 > but if the HA for some reason is not able to setup > forwarding to the mobile network in the implicit mode, > then we need a Binding Ack status to indicate this. >=20 > we can change 143 to mean "forwarding setup failed". >=20 > if we cant agree on this, I would suggest removing implicit > mode with static routes from the spec and writing up a short > separate spec on how to do it. we already have too many > mechanisms/modes in the spec. I am not sure the IESG is > going to like these many different mechanisms of doing the > same thing. >=20 Agreed :) > Vijay From exim@www1.ietf.org Wed Aug 6 02:46:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07476 for ; Wed, 6 Aug 2003 02:46:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kI3l-0001Ng-HK for nemo-archive@odin.ietf.org; Wed, 06 Aug 2003 02:46:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h766k9eK005305 for nemo-archive@odin.ietf.org; Wed, 6 Aug 2003 02:46:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kI3k-0001NU-8B for nemo-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 02:46:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07458 for ; Wed, 6 Aug 2003 02:46:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kI3g-0000uG-00 for nemo-web-archive@ietf.org; Wed, 06 Aug 2003 02:46:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kI3g-0000uD-00 for nemo-web-archive@ietf.org; Wed, 06 Aug 2003 02:46:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kI3d-0001Me-Ok; Wed, 06 Aug 2003 02:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kI3V-0001MH-Nf for nemo@optimus.ietf.org; Wed, 06 Aug 2003 02:45:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07454 for ; Wed, 6 Aug 2003 02:45:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kI3R-0000uA-00 for nemo@ietf.org; Wed, 06 Aug 2003 02:45:50 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19kI3R-0000tz-00 for nemo@ietf.org; Wed, 06 Aug 2003 02:45:49 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 06 Aug 2003 08:44:55 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h766h68O007362; Wed, 6 Aug 2003 08:43:06 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Aug 2003 08:45:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Aug 2003 07:45:17 +0100 Message-ID: Thread-Topic: Issue 10 Thread-Index: AcNbelSeRXxnV2hFR2+c8S0rHvr6gAAa9TMw From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 06 Aug 2003 06:45:18.0269 (UTC) FILETIME=[4CA05ED0:01C35BE6] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Issue 10 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mardi 5 ao=FBt 2003 19:51 > To: Pascal Thubert (pthubert) > Cc: nemo@ietf.org > Subject: Re: Issue 10 >=20 > "Pascal Thubert (pthubert)" wrote: > > > > > status code 143 is not supposed to be used when an IGP > > > is being run over the MR-HA tunnel. when an IGP is being > > > used, the HA just waits for the routing protocol updates > > > from the MR and does not attempt to create any routes if > > > the BU did not contain any prefix information. > > > > > > > Yes, that's the key. I would agree with the 143 if it was sure = between > > HA and MR that they are talking about implicit, the real one, as = opposed > > to static or IGP. That would be the only reason at this time to have = an > > implicit bit in the BU/BA, so that the HA can answer 143 if it is > > expected to have MNP information in a Nemo specific config that we > > usually refer to as prefix table, and can not find it. > > > > So I'd say it's either (NO 143) or (143 AND implicit bit). What do = you > > think? >=20 > you are hung up on the prefix table. :) forget it for the > moment. implicit mode was supposed to cover every mechanism > under which the HA is in control of adding/activating/maintaining > routes to the mobile network. if this is not clear in the > spec, lets correct the text. the MR has control only in the > two explicit modes and when an IGP is being run over the > MR-HA tunnel. >=20 > FWIW, I dislike any mode where the MR is not in control. > but that doesnt matter. >=20 > implicit mode includes static routes. it includes prefix > table. it includes any proprietary mechanism that you > implement on the HA. it is internal to the HA and there > is no interoperability problem. >=20 > but if the HA for some reason is not able to setup > forwarding to the mobile network in the implicit mode, > then we need a Binding Ack status to indicate this. >=20 > we can change 143 to mean "forwarding setup failed". >=20 > if we cant agree on this, I would suggest removing implicit > mode with static routes from the spec and writing up a short > separate spec on how to do it. we already have too many > mechanisms/modes in the spec. I am not sure the IESG is > going to like these many different mechanisms of doing the > same thing. >=20 Agreed :) > Vijay From nemo-admin@ietf.org Wed Aug 6 02:48:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07509 for ; Wed, 6 Aug 2003 02:48:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kI5Z-0001U3-QZ; Wed, 06 Aug 2003 02:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kI5R-0001Tq-6K for nemo@optimus.ietf.org; Wed, 06 Aug 2003 02:47:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07499 for ; Wed, 6 Aug 2003 02:47:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kI5N-0000uY-00 for nemo@ietf.org; Wed, 06 Aug 2003 02:47:49 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19kI5M-0000uU-00 for nemo@ietf.org; Wed, 06 Aug 2003 02:47:48 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 06 Aug 2003 08:46:55 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h766j6lb007641; Wed, 6 Aug 2003 08:45:06 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Aug 2003 08:47:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Implementation requirements for the different modes (wasRe:[nemo] Issue 10) Date: Wed, 6 Aug 2003 07:47:17 +0100 Message-ID: Thread-Topic: [nemo] Implementation requirements for the different modes (wasRe:[nemo] Issue 10) Thread-Index: AcNbditmKmbXNXr8TgCYCs0o+hvWUgAcCLJA From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Alexandru Petrescu" Cc: "Ryuji Wakikawa" , , X-OriginalArrivalTime: 06 Aug 2003 06:47:18.0394 (UTC) FILETIME=[9439FDA0:01C35BE6] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mardi 5 ao=FBt 2003 19:22 > To: Alexandru Petrescu > Cc: Pascal Thubert (pthubert); Ryuji Wakikawa; ernst@sfc.wide.ad.jp; = nemo@ietf.org > Subject: Re: [nemo] Implementation requirements for the different = modes (wasRe:[nemo] Issue > 10) >=20 > Alexandru Petrescu wrote: > > > > Pascal Thubert (pthubert) wrote: > > > The Mobile Router can be a tiny embedded logic. It may be an IP > > > forwarder with no routing logic but Nemo itself. Please allow it = to > > > be simple. IMHO, the modus operandi with static routes can be = enough > > > for some situations with mass produced such devices. So unless you > > > prove me that we have an interoperability problem by allowing MRs > > > that support only static and implicit, please detail. > > > > > > Otherwise, I suggest we either: > > > > > > - keep saying that the MR MUST support at least one mode > > > or > > > - make static + implicit the minimum set. > > > > I favour the latter since it seems to require the minimum effort in > > terms of additional implementation on top of Mobile IPv6 IMHO. >=20 > I prefer saying the MR MUST support at least one mode > (which the text already says). IMHO, the explicit > network mode will be most widely used. this gives you > the maximum flexibility of setting forwarding for > specific prefixes when there are multiple MNPs in the > mobile network. anyway it is too early to tell. Indeed :) I'm with Vijay on this. Because it's the most open wording and it still = does not create interop problem that I can foresee at the moment.=20 >=20 > Vijay From exim@www1.ietf.org Wed Aug 6 02:48:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07524 for ; Wed, 6 Aug 2003 02:48:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kI5b-0001Uv-C4 for nemo-archive@odin.ietf.org; Wed, 06 Aug 2003 02:48:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h766m3s4005755 for nemo-archive@odin.ietf.org; Wed, 6 Aug 2003 02:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kI5a-0001Uk-VN for nemo-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 02:48:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07506 for ; Wed, 6 Aug 2003 02:47:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kI5X-0000uj-00 for nemo-web-archive@ietf.org; Wed, 06 Aug 2003 02:47:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kI5W-0000ug-00 for nemo-web-archive@ietf.org; Wed, 06 Aug 2003 02:47:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kI5Z-0001U3-QZ; Wed, 06 Aug 2003 02:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kI5R-0001Tq-6K for nemo@optimus.ietf.org; Wed, 06 Aug 2003 02:47:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07499 for ; Wed, 6 Aug 2003 02:47:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kI5N-0000uY-00 for nemo@ietf.org; Wed, 06 Aug 2003 02:47:49 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19kI5M-0000uU-00 for nemo@ietf.org; Wed, 06 Aug 2003 02:47:48 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 06 Aug 2003 08:46:55 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h766j6lb007641; Wed, 6 Aug 2003 08:45:06 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Aug 2003 08:47:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Implementation requirements for the different modes (wasRe:[nemo] Issue 10) Date: Wed, 6 Aug 2003 07:47:17 +0100 Message-ID: Thread-Topic: [nemo] Implementation requirements for the different modes (wasRe:[nemo] Issue 10) Thread-Index: AcNbditmKmbXNXr8TgCYCs0o+hvWUgAcCLJA From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Alexandru Petrescu" Cc: "Ryuji Wakikawa" , , X-OriginalArrivalTime: 06 Aug 2003 06:47:18.0394 (UTC) FILETIME=[9439FDA0:01C35BE6] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mardi 5 ao=FBt 2003 19:22 > To: Alexandru Petrescu > Cc: Pascal Thubert (pthubert); Ryuji Wakikawa; ernst@sfc.wide.ad.jp; = nemo@ietf.org > Subject: Re: [nemo] Implementation requirements for the different = modes (wasRe:[nemo] Issue > 10) >=20 > Alexandru Petrescu wrote: > > > > Pascal Thubert (pthubert) wrote: > > > The Mobile Router can be a tiny embedded logic. It may be an IP > > > forwarder with no routing logic but Nemo itself. Please allow it = to > > > be simple. IMHO, the modus operandi with static routes can be = enough > > > for some situations with mass produced such devices. So unless you > > > prove me that we have an interoperability problem by allowing MRs > > > that support only static and implicit, please detail. > > > > > > Otherwise, I suggest we either: > > > > > > - keep saying that the MR MUST support at least one mode > > > or > > > - make static + implicit the minimum set. > > > > I favour the latter since it seems to require the minimum effort in > > terms of additional implementation on top of Mobile IPv6 IMHO. >=20 > I prefer saying the MR MUST support at least one mode > (which the text already says). IMHO, the explicit > network mode will be most widely used. this gives you > the maximum flexibility of setting forwarding for > specific prefixes when there are multiple MNPs in the > mobile network. anyway it is too early to tell. Indeed :) I'm with Vijay on this. Because it's the most open wording and it still = does not create interop problem that I can foresee at the moment.=20 >=20 > Vijay From nemo-admin@ietf.org Wed Aug 6 03:16:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08055 for ; Wed, 6 Aug 2003 03:16:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kIWf-0002iW-JY; Wed, 06 Aug 2003 03:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kIWF-0002hj-Lk for nemo@optimus.ietf.org; Wed, 06 Aug 2003 03:15:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08007 for ; Wed, 6 Aug 2003 03:15:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kIWD-00013X-00 for nemo@ietf.org; Wed, 06 Aug 2003 03:15:33 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19kIWC-00013O-00 for nemo@ietf.org; Wed, 06 Aug 2003 03:15:32 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 06 Aug 2003 09:14:39 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h767CnrL011953 for ; Wed, 6 Aug 2003 09:12:50 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Aug 2003 09:15:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35BEA.73B044B4" Date: Wed, 6 Aug 2003 08:15:01 +0100 Message-ID: Thread-Topic: Network priority for Binding Thread-Index: AcNb6loP/ld3rwyLQPWjWpa8JNWnAQ== From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 06 Aug 2003 07:15:02.0249 (UTC) FILETIME=[73F61D90:01C35BEA] Subject: [nemo] Network priority for Binding Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C35BEA.73B044B4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: Seems to me that the Binding should be sent with a network priority. Because they are keep alive.=20 The reason is that if they get mixed with a lot of traffic on a slow line, the BU may time out otherwise. It's a very classical problem.=20 I could not find in RFC 2328 or 2740 a statement about that for the Hello protocol in OSPF so maybe it's alright to say nothing in the spec and let it fall into the sense. But as opposed to Hellos, though, the BU may travel a long way, maybe across other MRs. So maybe it's worth agreeing on how it is done and what MRs need to support in terms of precedence or DSCP management. Also it seems that It's a mostly a MIP6 thing anyway... But Nemo makes it worse because of the nested configuration: - If a BU from a MR is tunneled by the upstream MR, should the encapsulated packet bear the same DSCP? - If the DSCP is copied on the encapsulation, then this opens to a downstream MR attacking with high traffic of high priority messages Some RO solutions inside the nested Nemo allow circumventing the first problem. The second one, I guess, is mostly a configuration issue if the MR is able to perform some ingress filtering/ priority queuing. What do you think? Pascal ------_=_NextPart_001_01C35BEA.73B044B4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Network priority for Binding

Hi:

Seems = to me that the Binding should be sent with a network = priority. Because they are keep alive.

The = reason is that if they get mixed with a lot of traffic on a slow line, the = BU may time out otherwise. It’s a very classical = problem.

I = could not find in RFC 2328 or = 2740 a statement about that for = the Hello = protocol in OSPF so maybe = it’s alright to say nothing in the spec and let it fall into the sense.

But as opposed to Hellos, = though, the BU may travel a long way, = maybe = across other MRs. So maybe = it’s worth = agreeing on how it is done and what MRs need to support in terms of precedence or DSCP = management.

Also = it seems that It’s a mostly a MIP6 thing anyway…

But Nemo makes it = worse because of the nested = configuration:

-       = If a BU from a MR is tunneled by the upstream MR, should the = encapsulated packet bear the same DSCP?
-       If = the DSCP is copied on the = encapsulation, then this opens to a downstream MR attacking with high traffic of high priority = messages

Some = RO solutions inside the nested Nemo allow circumventing the first problem. The second one, I guess, is mostly a configuration issue = if the MR is = able to perform some ingress filtering/ priority queuing.

What = do you think?

Pascal

------_=_NextPart_001_01C35BEA.73B044B4-- From exim@www1.ietf.org Wed Aug 6 03:16:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08070 for ; Wed, 6 Aug 2003 03:16:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kIWi-0002jk-Ua for nemo-archive@odin.ietf.org; Wed, 06 Aug 2003 03:16:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h767G4xM010516 for nemo-archive@odin.ietf.org; Wed, 6 Aug 2003 03:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kIWh-0002jS-B5 for nemo-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 03:16:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08016 for ; Wed, 6 Aug 2003 03:16:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kIWf-00013h-00 for nemo-web-archive@ietf.org; Wed, 06 Aug 2003 03:16:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kIWe-00013e-00 for nemo-web-archive@ietf.org; Wed, 06 Aug 2003 03:16:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kIWf-0002iW-JY; Wed, 06 Aug 2003 03:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kIWF-0002hj-Lk for nemo@optimus.ietf.org; Wed, 06 Aug 2003 03:15:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08007 for ; Wed, 6 Aug 2003 03:15:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kIWD-00013X-00 for nemo@ietf.org; Wed, 06 Aug 2003 03:15:33 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19kIWC-00013O-00 for nemo@ietf.org; Wed, 06 Aug 2003 03:15:32 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 06 Aug 2003 09:14:39 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h767CnrL011953 for ; Wed, 6 Aug 2003 09:12:50 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Aug 2003 09:15:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35BEA.73B044B4" Date: Wed, 6 Aug 2003 08:15:01 +0100 Message-ID: Thread-Topic: Network priority for Binding Thread-Index: AcNb6loP/ld3rwyLQPWjWpa8JNWnAQ== From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 06 Aug 2003 07:15:02.0249 (UTC) FILETIME=[73F61D90:01C35BEA] Subject: [nemo] Network priority for Binding Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C35BEA.73B044B4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: Seems to me that the Binding should be sent with a network priority. Because they are keep alive.=20 The reason is that if they get mixed with a lot of traffic on a slow line, the BU may time out otherwise. It's a very classical problem.=20 I could not find in RFC 2328 or 2740 a statement about that for the Hello protocol in OSPF so maybe it's alright to say nothing in the spec and let it fall into the sense. But as opposed to Hellos, though, the BU may travel a long way, maybe across other MRs. So maybe it's worth agreeing on how it is done and what MRs need to support in terms of precedence or DSCP management. Also it seems that It's a mostly a MIP6 thing anyway... But Nemo makes it worse because of the nested configuration: - If a BU from a MR is tunneled by the upstream MR, should the encapsulated packet bear the same DSCP? - If the DSCP is copied on the encapsulation, then this opens to a downstream MR attacking with high traffic of high priority messages Some RO solutions inside the nested Nemo allow circumventing the first problem. The second one, I guess, is mostly a configuration issue if the MR is able to perform some ingress filtering/ priority queuing. What do you think? Pascal ------_=_NextPart_001_01C35BEA.73B044B4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Network priority for Binding

Hi:

Seems = to me that the Binding should be sent with a network = priority. Because they are keep alive.

The = reason is that if they get mixed with a lot of traffic on a slow line, the = BU may time out otherwise. It’s a very classical = problem.

I = could not find in RFC 2328 or = 2740 a statement about that for = the Hello = protocol in OSPF so maybe = it’s alright to say nothing in the spec and let it fall into the sense.

But as opposed to Hellos, = though, the BU may travel a long way, = maybe = across other MRs. So maybe = it’s worth = agreeing on how it is done and what MRs need to support in terms of precedence or DSCP = management.

Also = it seems that It’s a mostly a MIP6 thing anyway…

But Nemo makes it = worse because of the nested = configuration:

-       = If a BU from a MR is tunneled by the upstream MR, should the = encapsulated packet bear the same DSCP?
-       If = the DSCP is copied on the = encapsulation, then this opens to a downstream MR attacking with high traffic of high priority = messages

Some = RO solutions inside the nested Nemo allow circumventing the first problem. The second one, I guess, is mostly a configuration issue = if the MR is = able to perform some ingress filtering/ priority queuing.

What = do you think?

Pascal

------_=_NextPart_001_01C35BEA.73B044B4-- From nemo-admin@ietf.org Wed Aug 6 05:20:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10076 for ; Wed, 6 Aug 2003 05:20:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kKSf-0006HC-Fu; Wed, 06 Aug 2003 05:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kHsF-0000p9-HK for nemo@optimus.ietf.org; Wed, 06 Aug 2003 02:34:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07204 for ; Wed, 6 Aug 2003 02:34:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kHsA-0000qQ-00 for nemo@ietf.org; Wed, 06 Aug 2003 02:34:10 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 19kHsA-0000qN-00 for nemo@ietf.org; Wed, 06 Aug 2003 02:34:10 -0400 Received: from isi.edu ([206.117.105.46]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h766XkX25466; Tue, 5 Aug 2003 23:33:46 -0700 (PDT) Message-ID: <3F30A148.5040400@isi.edu> Date: Tue, 05 Aug 2003 23:33:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: mobile-ip@sunroof.eng.sun.com, ipsec@lists.tislabs.com, nemo@ietf.org References: <200308051415.KAA12839@ietf.org> In-Reply-To: <200308051415.KAA12839@ietf.org> X-Enigmail-Version: 0.74.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: I-D ACTION:draft-ivancic-layer3-encryptors-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Use And Implementation of Layer-3 Encryption Devices > Author(s) : W. Ivancic, D. Stewart > Filename : draft-ivancic-layer3-encryptors-00.txt > Pages : 6 > Date : 2003-8-5 > > This document describes some issues related to performing > encryption at layer-3. In particular, routing protocol problems > may result if the time-to-live (TTL) field in IPv4 or the Hop Limit > field in IPv6 is decremented once before encapsulation [1][2]. > Also, special provisions may be necessary within the encryptor > devices if broadcast messages are to transition the encryptor > pairs. Maximum Transmission Unit (MTU) issues are also presented. This draft refers to RFC1853 for IP-in-IP encapsulation which was Informational. The more useful reference would be to RFC2003, which is Standards Track. RFC2003 appears to cover most of the issues in this document, where IPsec-specific issues are further covered already in RFC2401 and its pending update. Joe From exim@www1.ietf.org Wed Aug 6 05:20:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10091 for ; Wed, 6 Aug 2003 05:20:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kKSk-0006II-OL for nemo-archive@odin.ietf.org; Wed, 06 Aug 2003 05:20:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h769K6x8024188 for nemo-archive@odin.ietf.org; Wed, 6 Aug 2003 05:20:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kKSk-0006I3-Ht for nemo-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 05:20:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10072 for ; Wed, 6 Aug 2003 05:20:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kKSh-0001VG-00 for nemo-web-archive@ietf.org; Wed, 06 Aug 2003 05:20:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kKSg-0001VD-00 for nemo-web-archive@ietf.org; Wed, 06 Aug 2003 05:20:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kKSf-0006HC-Fu; Wed, 06 Aug 2003 05:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kHsF-0000p9-HK for nemo@optimus.ietf.org; Wed, 06 Aug 2003 02:34:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07204 for ; Wed, 6 Aug 2003 02:34:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kHsA-0000qQ-00 for nemo@ietf.org; Wed, 06 Aug 2003 02:34:10 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 19kHsA-0000qN-00 for nemo@ietf.org; Wed, 06 Aug 2003 02:34:10 -0400 Received: from isi.edu ([206.117.105.46]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h766XkX25466; Tue, 5 Aug 2003 23:33:46 -0700 (PDT) Message-ID: <3F30A148.5040400@isi.edu> Date: Tue, 05 Aug 2003 23:33:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: mobile-ip@sunroof.eng.sun.com, ipsec@lists.tislabs.com, nemo@ietf.org References: <200308051415.KAA12839@ietf.org> In-Reply-To: <200308051415.KAA12839@ietf.org> X-Enigmail-Version: 0.74.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: I-D ACTION:draft-ivancic-layer3-encryptors-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Use And Implementation of Layer-3 Encryption Devices > Author(s) : W. Ivancic, D. Stewart > Filename : draft-ivancic-layer3-encryptors-00.txt > Pages : 6 > Date : 2003-8-5 > > This document describes some issues related to performing > encryption at layer-3. In particular, routing protocol problems > may result if the time-to-live (TTL) field in IPv4 or the Hop Limit > field in IPv6 is decremented once before encapsulation [1][2]. > Also, special provisions may be necessary within the encryptor > devices if broadcast messages are to transition the encryptor > pairs. Maximum Transmission Unit (MTU) issues are also presented. This draft refers to RFC1853 for IP-in-IP encapsulation which was Informational. The more useful reference would be to RFC2003, which is Standards Track. RFC2003 appears to cover most of the issues in this document, where IPsec-specific issues are further covered already in RFC2401 and its pending update. Joe From nemo-admin@ietf.org Wed Aug 6 14:02:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27255 for ; Wed, 6 Aug 2003 14:02:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSbp-0001OF-MA; Wed, 06 Aug 2003 14:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSbc-0001Nu-JM for nemo@optimus.ietf.org; Wed, 06 Aug 2003 14:01:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27240 for ; Wed, 6 Aug 2003 14:01:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSba-0005H3-00 for nemo@ietf.org; Wed, 06 Aug 2003 14:01:46 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19kSbZ-0005Gk-00 for nemo@ietf.org; Wed, 06 Aug 2003 14:01:45 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h76I1Eu20634; Wed, 6 Aug 2003 11:01:14 -0700 X-mProtect: <200308061801> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdv9OwBa; Wed, 06 Aug 2003 11:01:13 PDT Message-ID: <3F314269.90BD06E4@iprg.nokia.com> Date: Wed, 06 Aug 2003 11:01:13 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@ietf.org CC: pthubert@cisco.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Text changes to close issue 10 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi all, I made some significant changes to the text. this is for closing issue 10. I realised that the Prefix Table and implict mode has been a source for lot of confusion. many people dont seem to like what was intended to be a simple solution. anyway here is what I propose we should do. 1. use Prefix Table only for verification in explicit mode. it is used only if the HA needs to be prevent misbehaving MRs from claiming prefixes that belong to other MRs. if a particular deployment is such that the HA does not expect MRs to misbehave then the Prefix Table is not required. 2. make it clear in Implicit mode that any mechanism can be used. it is totally internal to the Home Agent. remove all refereces to using Prefix Table in implicit mode. 3. change Binding Ack status 143 to 'Forwarding Setup failed'. it is used to indicate that the HA was unable to setup forwarding for the Mobile Network when it received a Binding Update from the MR in implicit mode. and here the proposed text changes to reflect this. let me know what you think about these changes. replace > Prefix Table > > It is a list of a mobile network prefixes indexed > by the extended Home Address of a Mobile Router. The > prefix table is managed by the Home Agent. When a Home > Agent receives a Binding Update without any options, > it searches a correspondent Mobile Network Prefix in > the prefix table, keying with the Home Address of the > requesting Mobile Router. This is an optional data > structure. with Prefix Table It is a list of a mobile network prefixes indexed by the extended Home Address of a Mobile Router. The prefix table is managed by the Home Agent. This is an optional data structure. replace > 143 Mobile Network Prefix information unavailable. with 143 Forwarding Setup failed replace > The Home Agent can use any mechanism (not defined > in this document) to determine the Mobile Network Prefix(es) > owned by the Mobile Router. One of the possible mechanisms is > where the Home Agent maintains a pre-configured Prefix Table > listing all the Mobile Network prefixes owned by a particular > Mobile Router. This table is keyed on the Home Address of the > Mobile Router. with The Home Agent can use any mechanism (not defined in this document) to determine the Mobile Network Prefix(es) owned by the Mobile Router and setup forwarding for the Mobile Network. One example would be manual configuration at the Home Agent mapping the Mobile Router's home address to the information required for setting up forwarding for the Mobile Network. replace > In some scenarios, the Home Agent might need to maintain a Prefix > Table of Mobile Routers and the IPv6 prefixes owned by Mobile > Routers. The Home Agent MUST maintain this table if the Mobile > Routers operate under the implicit mode where they do not include any > prefix information in the Binding Updates. > > Each entry in the Prefix Table conceptually contains the following > fields: > > - The Home Address of the Mobile Router. This field is used as the > key for searching the pre-configured prefix table. > > - The Mobile Network Prefix of the Mobile Router associated with > the Home Address. > > In some deployment scenarios, it is necessary for Home Agent to > prevent a misbehaving Mobile Router from claiming mobile network > prefixes belonging to another Mobile Router. The Home Agent can > prevent such attacks if it maintains the Prefix Table and verifies > the Prefix Information provided by the Mobile Router against the > if the Binding Update contained explicit prefix information in the > form of either the Mobile Network Prefix Option or the Mobile Network > Prefix Length Option. with In some deployment scenarios it may be necessary for the Home Agent to prevent a misbehaving Mobile Router from claiming mobile network prefixes belonging to another Mobile Router. The Home Agent can prevent such attacks if it maintains the Prefix Table and verifies the Prefix Information provided by the Mobile Router against the entries in the Prefix Table. However, this verification is done only if the Binding Update contained explicit prefix information in the form of either the Mobile Network Prefix Option or the Mobile Network Prefix Length Option. Each entry in the Prefix Table conceptually contains the following fields: - The Home Address of the Mobile Router. This field is used as the key for searching the pre-configured prefix table. - The Mobile Network Prefix of the Mobile Router associated with the Home Address. replace > - If there are no options in the Binding Update, the Home Agent > figures out which prefixes are assigned to the Mobile Router > from the Pre-configured Prefix Table. If the Home Agent can not > find the correspondent Mobile Network Prefix, it MUST reject the > Binding Update and send a Binding Acknowledgement with the Status > field set to 143 (Prefix Information unavailable). to - If there are no options in the Binding Update, the Home Agent uses manual pre-configured information to determine the prefixes assigned to the Mobile Router and for setting up forwarding for the Mobile Network. If there is no information that the Home Agent can use, it MUST reject the Binding Update and send a Binding Acknowledgement with status set to 143 (Forwarding Setup failed). replace > The Home Agent sets the status code in the Binding Acknowledgement > to '143' (Mobile Network Prefix information unavailable) in order > to indicate the Mobile Router that the received Home Address in the > Binding Update does not match any prefix entry in the pre-configured > prefix table. This is used in the Implicit case where the Mobile > Router does not include any prefix information in the Binding Update. with The Home Agent sets the status code to 143 (Forwarding Setup failed) if it is unable to determine the information needed to setup forwarding for the Mobile Network. This is used in the Implicit mode where the Mobile Router does not include any prefix information in the Binding Update. Vijay From exim@www1.ietf.org Wed Aug 6 14:02:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27270 for ; Wed, 6 Aug 2003 14:02:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSbu-0001P5-SM for nemo-archive@odin.ietf.org; Wed, 06 Aug 2003 14:02:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76I26oL005395 for nemo-archive@odin.ietf.org; Wed, 6 Aug 2003 14:02:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSbu-0001Ow-Lj for nemo-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 14:02:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27250 for ; Wed, 6 Aug 2003 14:02:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSbs-0005HB-00 for nemo-web-archive@ietf.org; Wed, 06 Aug 2003 14:02:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kSbr-0005H7-00 for nemo-web-archive@ietf.org; Wed, 06 Aug 2003 14:02:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSbp-0001OF-MA; Wed, 06 Aug 2003 14:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSbc-0001Nu-JM for nemo@optimus.ietf.org; Wed, 06 Aug 2003 14:01:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27240 for ; Wed, 6 Aug 2003 14:01:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSba-0005H3-00 for nemo@ietf.org; Wed, 06 Aug 2003 14:01:46 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19kSbZ-0005Gk-00 for nemo@ietf.org; Wed, 06 Aug 2003 14:01:45 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h76I1Eu20634; Wed, 6 Aug 2003 11:01:14 -0700 X-mProtect: <200308061801> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdv9OwBa; Wed, 06 Aug 2003 11:01:13 PDT Message-ID: <3F314269.90BD06E4@iprg.nokia.com> Date: Wed, 06 Aug 2003 11:01:13 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@ietf.org CC: pthubert@cisco.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Text changes to close issue 10 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi all, I made some significant changes to the text. this is for closing issue 10. I realised that the Prefix Table and implict mode has been a source for lot of confusion. many people dont seem to like what was intended to be a simple solution. anyway here is what I propose we should do. 1. use Prefix Table only for verification in explicit mode. it is used only if the HA needs to be prevent misbehaving MRs from claiming prefixes that belong to other MRs. if a particular deployment is such that the HA does not expect MRs to misbehave then the Prefix Table is not required. 2. make it clear in Implicit mode that any mechanism can be used. it is totally internal to the Home Agent. remove all refereces to using Prefix Table in implicit mode. 3. change Binding Ack status 143 to 'Forwarding Setup failed'. it is used to indicate that the HA was unable to setup forwarding for the Mobile Network when it received a Binding Update from the MR in implicit mode. and here the proposed text changes to reflect this. let me know what you think about these changes. replace > Prefix Table > > It is a list of a mobile network prefixes indexed > by the extended Home Address of a Mobile Router. The > prefix table is managed by the Home Agent. When a Home > Agent receives a Binding Update without any options, > it searches a correspondent Mobile Network Prefix in > the prefix table, keying with the Home Address of the > requesting Mobile Router. This is an optional data > structure. with Prefix Table It is a list of a mobile network prefixes indexed by the extended Home Address of a Mobile Router. The prefix table is managed by the Home Agent. This is an optional data structure. replace > 143 Mobile Network Prefix information unavailable. with 143 Forwarding Setup failed replace > The Home Agent can use any mechanism (not defined > in this document) to determine the Mobile Network Prefix(es) > owned by the Mobile Router. One of the possible mechanisms is > where the Home Agent maintains a pre-configured Prefix Table > listing all the Mobile Network prefixes owned by a particular > Mobile Router. This table is keyed on the Home Address of the > Mobile Router. with The Home Agent can use any mechanism (not defined in this document) to determine the Mobile Network Prefix(es) owned by the Mobile Router and setup forwarding for the Mobile Network. One example would be manual configuration at the Home Agent mapping the Mobile Router's home address to the information required for setting up forwarding for the Mobile Network. replace > In some scenarios, the Home Agent might need to maintain a Prefix > Table of Mobile Routers and the IPv6 prefixes owned by Mobile > Routers. The Home Agent MUST maintain this table if the Mobile > Routers operate under the implicit mode where they do not include any > prefix information in the Binding Updates. > > Each entry in the Prefix Table conceptually contains the following > fields: > > - The Home Address of the Mobile Router. This field is used as the > key for searching the pre-configured prefix table. > > - The Mobile Network Prefix of the Mobile Router associated with > the Home Address. > > In some deployment scenarios, it is necessary for Home Agent to > prevent a misbehaving Mobile Router from claiming mobile network > prefixes belonging to another Mobile Router. The Home Agent can > prevent such attacks if it maintains the Prefix Table and verifies > the Prefix Information provided by the Mobile Router against the > if the Binding Update contained explicit prefix information in the > form of either the Mobile Network Prefix Option or the Mobile Network > Prefix Length Option. with In some deployment scenarios it may be necessary for the Home Agent to prevent a misbehaving Mobile Router from claiming mobile network prefixes belonging to another Mobile Router. The Home Agent can prevent such attacks if it maintains the Prefix Table and verifies the Prefix Information provided by the Mobile Router against the entries in the Prefix Table. However, this verification is done only if the Binding Update contained explicit prefix information in the form of either the Mobile Network Prefix Option or the Mobile Network Prefix Length Option. Each entry in the Prefix Table conceptually contains the following fields: - The Home Address of the Mobile Router. This field is used as the key for searching the pre-configured prefix table. - The Mobile Network Prefix of the Mobile Router associated with the Home Address. replace > - If there are no options in the Binding Update, the Home Agent > figures out which prefixes are assigned to the Mobile Router > from the Pre-configured Prefix Table. If the Home Agent can not > find the correspondent Mobile Network Prefix, it MUST reject the > Binding Update and send a Binding Acknowledgement with the Status > field set to 143 (Prefix Information unavailable). to - If there are no options in the Binding Update, the Home Agent uses manual pre-configured information to determine the prefixes assigned to the Mobile Router and for setting up forwarding for the Mobile Network. If there is no information that the Home Agent can use, it MUST reject the Binding Update and send a Binding Acknowledgement with status set to 143 (Forwarding Setup failed). replace > The Home Agent sets the status code in the Binding Acknowledgement > to '143' (Mobile Network Prefix information unavailable) in order > to indicate the Mobile Router that the received Home Address in the > Binding Update does not match any prefix entry in the pre-configured > prefix table. This is used in the Implicit case where the Mobile > Router does not include any prefix information in the Binding Update. with The Home Agent sets the status code to 143 (Forwarding Setup failed) if it is unable to determine the information needed to setup forwarding for the Mobile Network. This is used in the Implicit mode where the Mobile Router does not include any prefix information in the Binding Update. Vijay From nemo-admin@ietf.org Wed Aug 6 18:01:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06769 for ; Wed, 6 Aug 2003 18:01:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kWL6-0004Pv-6z; Wed, 06 Aug 2003 18:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kWKM-0004LA-De for nemo@optimus.ietf.org; Wed, 06 Aug 2003 18:00:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06741 for ; Wed, 6 Aug 2003 18:00:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kWKJ-0007cr-00 for nemo@ietf.org; Wed, 06 Aug 2003 18:00:11 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19kWKI-0007cX-00 for nemo@ietf.org; Wed, 06 Aug 2003 18:00:10 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h76Lxdk03222; Wed, 6 Aug 2003 14:59:39 -0700 X-mProtect: <200308062159> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpddXEmGn; Wed, 06 Aug 2003 14:59:37 PDT Message-ID: <3F317A49.656327B8@iprg.nokia.com> Date: Wed, 06 Aug 2003 14:59:37 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@ietf.org, pthubert@cisco.com References: <3F314269.90BD06E4@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Text changes to close issue 10 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > 3. change Binding Ack status 143 to 'Forwarding Setup failed'. it > is used to indicate that the HA was unable to setup forwarding > for the Mobile Network when it received a Binding Update from the > MR in implicit mode. and if somebody can come up with something better than 'Forwarding Setup failed', it would be nice. :) Vijay From exim@www1.ietf.org Wed Aug 6 18:01:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06784 for ; Wed, 6 Aug 2003 18:01:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kWLE-0004RI-TD for nemo-archive@odin.ietf.org; Wed, 06 Aug 2003 18:01:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76M1833017058 for nemo-archive@odin.ietf.org; Wed, 6 Aug 2003 18:01:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kWLE-0004R3-Mj for nemo-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 18:01:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06764 for ; Wed, 6 Aug 2003 18:01:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kWLC-0007d9-00 for nemo-web-archive@ietf.org; Wed, 06 Aug 2003 18:01:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kWLB-0007d6-00 for nemo-web-archive@ietf.org; Wed, 06 Aug 2003 18:01:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kWL6-0004Pv-6z; Wed, 06 Aug 2003 18:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kWKM-0004LA-De for nemo@optimus.ietf.org; Wed, 06 Aug 2003 18:00:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06741 for ; Wed, 6 Aug 2003 18:00:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kWKJ-0007cr-00 for nemo@ietf.org; Wed, 06 Aug 2003 18:00:11 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19kWKI-0007cX-00 for nemo@ietf.org; Wed, 06 Aug 2003 18:00:10 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h76Lxdk03222; Wed, 6 Aug 2003 14:59:39 -0700 X-mProtect: <200308062159> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpddXEmGn; Wed, 06 Aug 2003 14:59:37 PDT Message-ID: <3F317A49.656327B8@iprg.nokia.com> Date: Wed, 06 Aug 2003 14:59:37 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@ietf.org, pthubert@cisco.com References: <3F314269.90BD06E4@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Text changes to close issue 10 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > 3. change Binding Ack status 143 to 'Forwarding Setup failed'. it > is used to indicate that the HA was unable to setup forwarding > for the Mobile Network when it received a Binding Update from the > MR in implicit mode. and if somebody can come up with something better than 'Forwarding Setup failed', it would be nice. :) Vijay From nemo-admin@ietf.org Wed Aug 6 21:12:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12465 for ; Wed, 6 Aug 2003 21:12:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kZJx-000315-6G; Wed, 06 Aug 2003 21:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kZJN-0002xz-Qf for nemo@optimus.ietf.org; Wed, 06 Aug 2003 21:11:25 -0400 Received: from popeye.snu.ac.kr (popeye.snu.ac.kr [147.46.240.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12349 for ; Wed, 6 Aug 2003 21:11:18 -0400 (EDT) Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h7718IQn025774; Thu, 7 Aug 2003 10:08:18 +0900 From: "Jongkeun Na" To: "'Vijay Devarapalli'" , Cc: Subject: RE: [nemo] Text changes to close issue 10 Date: Thu, 7 Aug 2003 10:13:11 +0900 Message-ID: <000001c35c81$1221d6d0$dbf02e93@JONGKN02> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <3F314269.90BD06E4@iprg.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit It seems to be nice to restrict the use of Prefix Table. I agree with your proposal. Those of changes make issue 10 as well as issue 6 clear to me. /JongKeun > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Vijay > Devarapalli > Sent: Thursday, August 07, 2003 3:01 AM > To: nemo@ietf.org > Cc: pthubert@cisco.com > Subject: [nemo] Text changes to close issue 10 > > hi all, > > I made some significant changes to the text. this is for closing > issue 10. I realised that the Prefix Table and implict mode has > been a source for lot of confusion. many people dont seem to > like what was intended to be a simple solution. anyway here is > what I propose we should do. > > 1. use Prefix Table only for verification in explicit mode. it > is used only if the HA needs to be prevent misbehaving MRs from > claiming prefixes that belong to other MRs. if a particular > deployment is such that the HA does not expect MRs to misbehave > then the Prefix Table is not required. > > 2. make it clear in Implicit mode that any mechanism can be used. > it is totally internal to the Home Agent. remove all refereces to > using Prefix Table in implicit mode. > > 3. change Binding Ack status 143 to 'Forwarding Setup failed'. it > is used to indicate that the HA was unable to setup forwarding > for the Mobile Network when it received a Binding Update from the > MR in implicit mode. > > and here the proposed text changes to reflect this. let me > know what you think about these changes. > > > replace > > Prefix Table > > > > It is a list of a mobile network prefixes indexed > > by the extended Home Address of a Mobile Router. The > > prefix table is managed by the Home Agent. When a Home > > Agent receives a Binding Update without any options, > > it searches a correspondent Mobile Network Prefix in > > the prefix table, keying with the Home Address of the > > requesting Mobile Router. This is an optional data > > structure. > > with > Prefix Table > > It is a list of a mobile network prefixes indexed > by the extended Home Address of a Mobile Router. The > prefix table is managed by the Home Agent. This is an > optional data structure. > > replace > > 143 Mobile Network Prefix information unavailable. > > with > 143 Forwarding Setup failed > > > replace > > The Home Agent can use any mechanism (not defined > > in this document) to determine the Mobile Network Prefix(es) > > owned by the Mobile Router. One of the possible mechanisms is > > where the Home Agent maintains a pre-configured Prefix Table > > listing all the Mobile Network prefixes owned by a particular > > Mobile Router. This table is keyed on the Home Address of the > > Mobile Router. > > with > > The Home Agent can use any mechanism (not defined > in this document) to determine the Mobile Network Prefix(es) > owned by the Mobile Router and setup forwarding for the Mobile > Network. One example would be manual configuration at the > Home Agent mapping the Mobile Router's home address to the > information required for setting up forwarding for the Mobile > Network. > > replace > > In some scenarios, the Home Agent might need to maintain a Prefix > > Table of Mobile Routers and the IPv6 prefixes owned by Mobile > > Routers. The Home Agent MUST maintain this table if the Mobile > > Routers operate under the implicit mode where they do not include any > > prefix information in the Binding Updates. > > > > Each entry in the Prefix Table conceptually contains the following > > fields: > > > > - The Home Address of the Mobile Router. This field is used as the > > key for searching the pre-configured prefix table. > > > > - The Mobile Network Prefix of the Mobile Router associated with > > the Home Address. > > > > In some deployment scenarios, it is necessary for Home Agent to > > prevent a misbehaving Mobile Router from claiming mobile network > > prefixes belonging to another Mobile Router. The Home Agent can > > prevent such attacks if it maintains the Prefix Table and verifies > > the Prefix Information provided by the Mobile Router against the > > if the Binding Update contained explicit prefix information in the > > form of either the Mobile Network Prefix Option or the Mobile Network > > Prefix Length Option. > > with > > In some deployment scenarios it may be necessary for the Home Agent > to prevent a misbehaving Mobile Router from claiming mobile network > prefixes belonging to another Mobile Router. The Home Agent can > prevent such attacks if it maintains the Prefix Table and verifies > the Prefix Information provided by the Mobile Router against the > entries in the Prefix Table. However, this verification is done only > if the Binding Update contained explicit prefix information in the > form of either the Mobile Network Prefix Option or the Mobile Network > Prefix Length Option. > > Each entry in the Prefix Table conceptually contains the following > fields: > > - The Home Address of the Mobile Router. This field is used as the > key for searching the pre-configured prefix table. > > - The Mobile Network Prefix of the Mobile Router associated with > the Home Address. > > replace > > - If there are no options in the Binding Update, the Home Agent > > figures out which prefixes are assigned to the Mobile Router > > from the Pre-configured Prefix Table. If the Home Agent can not > > find the correspondent Mobile Network Prefix, it MUST reject the > > Binding Update and send a Binding Acknowledgement with the Status > > field set to 143 (Prefix Information unavailable). > > to > - If there are no options in the Binding Update, the Home Agent > uses manual pre-configured information to determine the > prefixes assigned to the Mobile Router and for setting up > forwarding for the Mobile Network. If there is no information > that the Home Agent can use, it MUST reject the Binding Update > and send a Binding Acknowledgement with status set to 143 > (Forwarding Setup failed). > > replace > > The Home Agent sets the status code in the Binding Acknowledgement > > to '143' (Mobile Network Prefix information unavailable) in order > > to indicate the Mobile Router that the received Home Address in the > > Binding Update does not match any prefix entry in the pre-configured > > prefix table. This is used in the Implicit case where the Mobile > > Router does not include any prefix information in the Binding Update. > > > with > > The Home Agent sets the status code to 143 (Forwarding Setup > failed) if it is unable to determine the information needed to setup > forwarding for the Mobile Network. This is used in the Implicit mode > where the Mobile Router does not include any prefix information in > the Binding Update. > > > Vijay From exim@www1.ietf.org Wed Aug 6 21:12:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12480 for ; Wed, 6 Aug 2003 21:12:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kZK1-000323-To for nemo-archive@odin.ietf.org; Wed, 06 Aug 2003 21:12:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h771C5wG011651 for nemo-archive@odin.ietf.org; Wed, 6 Aug 2003 21:12:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kZK1-00031q-Pj for nemo-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 21:12:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12446 for ; Wed, 6 Aug 2003 21:12:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kZJz-00018l-00 for nemo-web-archive@ietf.org; Wed, 06 Aug 2003 21:12:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kZJy-00018i-00 for nemo-web-archive@ietf.org; Wed, 06 Aug 2003 21:12:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kZJx-000315-6G; Wed, 06 Aug 2003 21:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kZJN-0002xz-Qf for nemo@optimus.ietf.org; Wed, 06 Aug 2003 21:11:25 -0400 Received: from popeye.snu.ac.kr (popeye.snu.ac.kr [147.46.240.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12349 for ; Wed, 6 Aug 2003 21:11:18 -0400 (EDT) Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h7718IQn025774; Thu, 7 Aug 2003 10:08:18 +0900 From: "Jongkeun Na" To: "'Vijay Devarapalli'" , Cc: Subject: RE: [nemo] Text changes to close issue 10 Date: Thu, 7 Aug 2003 10:13:11 +0900 Message-ID: <000001c35c81$1221d6d0$dbf02e93@JONGKN02> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <3F314269.90BD06E4@iprg.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It seems to be nice to restrict the use of Prefix Table. I agree with your proposal. Those of changes make issue 10 as well as issue 6 clear to me. /JongKeun > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Vijay > Devarapalli > Sent: Thursday, August 07, 2003 3:01 AM > To: nemo@ietf.org > Cc: pthubert@cisco.com > Subject: [nemo] Text changes to close issue 10 > > hi all, > > I made some significant changes to the text. this is for closing > issue 10. I realised that the Prefix Table and implict mode has > been a source for lot of confusion. many people dont seem to > like what was intended to be a simple solution. anyway here is > what I propose we should do. > > 1. use Prefix Table only for verification in explicit mode. it > is used only if the HA needs to be prevent misbehaving MRs from > claiming prefixes that belong to other MRs. if a particular > deployment is such that the HA does not expect MRs to misbehave > then the Prefix Table is not required. > > 2. make it clear in Implicit mode that any mechanism can be used. > it is totally internal to the Home Agent. remove all refereces to > using Prefix Table in implicit mode. > > 3. change Binding Ack status 143 to 'Forwarding Setup failed'. it > is used to indicate that the HA was unable to setup forwarding > for the Mobile Network when it received a Binding Update from the > MR in implicit mode. > > and here the proposed text changes to reflect this. let me > know what you think about these changes. > > > replace > > Prefix Table > > > > It is a list of a mobile network prefixes indexed > > by the extended Home Address of a Mobile Router. The > > prefix table is managed by the Home Agent. When a Home > > Agent receives a Binding Update without any options, > > it searches a correspondent Mobile Network Prefix in > > the prefix table, keying with the Home Address of the > > requesting Mobile Router. This is an optional data > > structure. > > with > Prefix Table > > It is a list of a mobile network prefixes indexed > by the extended Home Address of a Mobile Router. The > prefix table is managed by the Home Agent. This is an > optional data structure. > > replace > > 143 Mobile Network Prefix information unavailable. > > with > 143 Forwarding Setup failed > > > replace > > The Home Agent can use any mechanism (not defined > > in this document) to determine the Mobile Network Prefix(es) > > owned by the Mobile Router. One of the possible mechanisms is > > where the Home Agent maintains a pre-configured Prefix Table > > listing all the Mobile Network prefixes owned by a particular > > Mobile Router. This table is keyed on the Home Address of the > > Mobile Router. > > with > > The Home Agent can use any mechanism (not defined > in this document) to determine the Mobile Network Prefix(es) > owned by the Mobile Router and setup forwarding for the Mobile > Network. One example would be manual configuration at the > Home Agent mapping the Mobile Router's home address to the > information required for setting up forwarding for the Mobile > Network. > > replace > > In some scenarios, the Home Agent might need to maintain a Prefix > > Table of Mobile Routers and the IPv6 prefixes owned by Mobile > > Routers. The Home Agent MUST maintain this table if the Mobile > > Routers operate under the implicit mode where they do not include any > > prefix information in the Binding Updates. > > > > Each entry in the Prefix Table conceptually contains the following > > fields: > > > > - The Home Address of the Mobile Router. This field is used as the > > key for searching the pre-configured prefix table. > > > > - The Mobile Network Prefix of the Mobile Router associated with > > the Home Address. > > > > In some deployment scenarios, it is necessary for Home Agent to > > prevent a misbehaving Mobile Router from claiming mobile network > > prefixes belonging to another Mobile Router. The Home Agent can > > prevent such attacks if it maintains the Prefix Table and verifies > > the Prefix Information provided by the Mobile Router against the > > if the Binding Update contained explicit prefix information in the > > form of either the Mobile Network Prefix Option or the Mobile Network > > Prefix Length Option. > > with > > In some deployment scenarios it may be necessary for the Home Agent > to prevent a misbehaving Mobile Router from claiming mobile network > prefixes belonging to another Mobile Router. The Home Agent can > prevent such attacks if it maintains the Prefix Table and verifies > the Prefix Information provided by the Mobile Router against the > entries in the Prefix Table. However, this verification is done only > if the Binding Update contained explicit prefix information in the > form of either the Mobile Network Prefix Option or the Mobile Network > Prefix Length Option. > > Each entry in the Prefix Table conceptually contains the following > fields: > > - The Home Address of the Mobile Router. This field is used as the > key for searching the pre-configured prefix table. > > - The Mobile Network Prefix of the Mobile Router associated with > the Home Address. > > replace > > - If there are no options in the Binding Update, the Home Agent > > figures out which prefixes are assigned to the Mobile Router > > from the Pre-configured Prefix Table. If the Home Agent can not > > find the correspondent Mobile Network Prefix, it MUST reject the > > Binding Update and send a Binding Acknowledgement with the Status > > field set to 143 (Prefix Information unavailable). > > to > - If there are no options in the Binding Update, the Home Agent > uses manual pre-configured information to determine the > prefixes assigned to the Mobile Router and for setting up > forwarding for the Mobile Network. If there is no information > that the Home Agent can use, it MUST reject the Binding Update > and send a Binding Acknowledgement with status set to 143 > (Forwarding Setup failed). > > replace > > The Home Agent sets the status code in the Binding Acknowledgement > > to '143' (Mobile Network Prefix information unavailable) in order > > to indicate the Mobile Router that the received Home Address in the > > Binding Update does not match any prefix entry in the pre-configured > > prefix table. This is used in the Implicit case where the Mobile > > Router does not include any prefix information in the Binding Update. > > > with > > The Home Agent sets the status code to 143 (Forwarding Setup > failed) if it is unable to determine the information needed to setup > forwarding for the Mobile Network. This is used in the Implicit mode > where the Mobile Router does not include any prefix information in > the Binding Update. > > > Vijay From nemo-admin@ietf.org Thu Aug 7 01:09:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18262 for ; Thu, 7 Aug 2003 01:09:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kd1I-00029Q-Vh; Thu, 07 Aug 2003 01:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kd0f-00028u-FT for nemo@optimus.ietf.org; Thu, 07 Aug 2003 01:08:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18242 for ; Thu, 7 Aug 2003 01:08:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kd0c-0002f1-00 for nemo@ietf.org; Thu, 07 Aug 2003 01:08:18 -0400 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx with smtp (Exim 4.12) id 19kd0c-0002ex-00 for nemo@ietf.org; Thu, 07 Aug 2003 01:08:18 -0400 Received: From mozart With LocalMail ; Thu, 7 Aug 2003 15:08:13 +1000 From: Muhammad Ali Malik To: nemo@ietf.org Date: Thu, 7 Aug 2003 15:08:12 +1000 (EST) X-X-Sender: mamalik@mozart.orchestra.cse.unsw.EDU.AU Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [nemo] crossover tunnel.... Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi When a visting mobile node (VMN) needs to communicate with local fixed node (LFN) of mobile network, can they communicate directly or the communication need to pass via home agent of VMN. Cheers Malik From exim@www1.ietf.org Thu Aug 7 01:09:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18277 for ; Thu, 7 Aug 2003 01:09:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kd1N-0002AN-TB for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 01:09:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77595HM008321 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 01:09:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kd1N-0002A8-OW for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 01:09:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18252 for ; Thu, 7 Aug 2003 01:09:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kd1K-0002fD-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 01:09:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kd1K-0002fA-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 01:09:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kd1I-00029Q-Vh; Thu, 07 Aug 2003 01:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kd0f-00028u-FT for nemo@optimus.ietf.org; Thu, 07 Aug 2003 01:08:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18242 for ; Thu, 7 Aug 2003 01:08:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kd0c-0002f1-00 for nemo@ietf.org; Thu, 07 Aug 2003 01:08:18 -0400 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx with smtp (Exim 4.12) id 19kd0c-0002ex-00 for nemo@ietf.org; Thu, 07 Aug 2003 01:08:18 -0400 Received: From mozart With LocalMail ; Thu, 7 Aug 2003 15:08:13 +1000 From: Muhammad Ali Malik To: nemo@ietf.org Date: Thu, 7 Aug 2003 15:08:12 +1000 (EST) X-X-Sender: mamalik@mozart.orchestra.cse.unsw.EDU.AU Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [nemo] crossover tunnel.... Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi When a visting mobile node (VMN) needs to communicate with local fixed node (LFN) of mobile network, can they communicate directly or the communication need to pass via home agent of VMN. Cheers Malik From nemo-admin@ietf.org Thu Aug 7 01:53:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19112 for ; Thu, 7 Aug 2003 01:53:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kdhs-0003aE-17; Thu, 07 Aug 2003 01:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kdhC-0003Zv-Um for nemo@optimus.ietf.org; Thu, 07 Aug 2003 01:52:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19048 for ; Thu, 7 Aug 2003 01:52:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kdh9-0002ua-00 for nemo@ietf.org; Thu, 07 Aug 2003 01:52:15 -0400 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx with smtp (Exim 4.12) id 19kdh9-0002uW-00 for nemo@ietf.org; Thu, 07 Aug 2003 01:52:15 -0400 Received: From mozart With LocalMail ; Thu, 7 Aug 2003 15:52:11 +1000 From: Muhammad Ali Malik To: nemo@ietf.org Date: Thu, 7 Aug 2003 15:52:11 +1000 (EST) X-X-Sender: mamalik@mozart.orchestra.cse.unsw.EDU.AU Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [nemo] visting mobile node CoA Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi When a visiting mobile node (VMN) together with Mobile network moves to new location. Does VMN obtains the new care-of-address or it attains its old care-of-address. Do we need to treat VMN as LFN once it obtains the CoA from MR. Regards, Muhammad Ali Malik From exim@www1.ietf.org Thu Aug 7 01:53:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19127 for ; Thu, 7 Aug 2003 01:53:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kdhu-0003bC-HX for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 01:53:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h775r22B013828 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 01:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kdhu-0003ax-D1 for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 01:53:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19086 for ; Thu, 7 Aug 2003 01:52:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kdhr-0002v7-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 01:52:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kdhq-0002v4-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 01:52:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kdhs-0003aE-17; Thu, 07 Aug 2003 01:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kdhC-0003Zv-Um for nemo@optimus.ietf.org; Thu, 07 Aug 2003 01:52:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19048 for ; Thu, 7 Aug 2003 01:52:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kdh9-0002ua-00 for nemo@ietf.org; Thu, 07 Aug 2003 01:52:15 -0400 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx with smtp (Exim 4.12) id 19kdh9-0002uW-00 for nemo@ietf.org; Thu, 07 Aug 2003 01:52:15 -0400 Received: From mozart With LocalMail ; Thu, 7 Aug 2003 15:52:11 +1000 From: Muhammad Ali Malik To: nemo@ietf.org Date: Thu, 7 Aug 2003 15:52:11 +1000 (EST) X-X-Sender: mamalik@mozart.orchestra.cse.unsw.EDU.AU Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [nemo] visting mobile node CoA Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi When a visiting mobile node (VMN) together with Mobile network moves to new location. Does VMN obtains the new care-of-address or it attains its old care-of-address. Do we need to treat VMN as LFN once it obtains the CoA from MR. Regards, Muhammad Ali Malik From nemo-admin@ietf.org Thu Aug 7 02:39:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02354 for ; Thu, 7 Aug 2003 02:39:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19keQP-0006u8-HA; Thu, 07 Aug 2003 02:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kePj-0006tL-D1 for nemo@optimus.ietf.org; Thu, 07 Aug 2003 02:38:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02309 for ; Thu, 7 Aug 2003 02:38:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kePf-0003M4-00 for nemo@ietf.org; Thu, 07 Aug 2003 02:38:15 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19kePf-0003Ln-00 for nemo@ietf.org; Thu, 07 Aug 2003 02:38:15 -0400 Received: from huez (Q118006.ppp.dion.ne.jp [61.204.118.6]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 64C835D090 for ; Thu, 7 Aug 2003 15:37:39 +0900 (JST) Date: Thu, 7 Aug 2003 15:37:15 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... Message-Id: <20030807153715.662ea066.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > When a visting mobile node (VMN) needs to communicate with local fixed > node (LFN) of mobile network, can they communicate directly or the > communication need to pass via home agent of VMN. Good question. And the answer is "(may be) no", in NEMO Basic Support. If VMN performs MIPv6 Route Optimization, direct communication may be possible once HoTi/CoTi is performed (so if for some reasons the MR is disconnected, it won't work). Such optimization should be taken of by extended support, once we come to work on it (if we do). Hope this helps. Thierry From exim@www1.ietf.org Thu Aug 7 02:39:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02369 for ; Thu, 7 Aug 2003 02:39:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19keQU-0006vH-3B for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 02:39:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h776d6qY026605 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 02:39:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19keQT-0006v2-KN for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 02:39:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02337 for ; Thu, 7 Aug 2003 02:38:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19keQP-0003Mk-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 02:39:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19keQP-0003Mh-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 02:39:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19keQP-0006u8-HA; Thu, 07 Aug 2003 02:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kePj-0006tL-D1 for nemo@optimus.ietf.org; Thu, 07 Aug 2003 02:38:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02309 for ; Thu, 7 Aug 2003 02:38:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kePf-0003M4-00 for nemo@ietf.org; Thu, 07 Aug 2003 02:38:15 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19kePf-0003Ln-00 for nemo@ietf.org; Thu, 07 Aug 2003 02:38:15 -0400 Received: from huez (Q118006.ppp.dion.ne.jp [61.204.118.6]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 64C835D090 for ; Thu, 7 Aug 2003 15:37:39 +0900 (JST) Date: Thu, 7 Aug 2003 15:37:15 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... Message-Id: <20030807153715.662ea066.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > When a visting mobile node (VMN) needs to communicate with local fixed > node (LFN) of mobile network, can they communicate directly or the > communication need to pass via home agent of VMN. Good question. And the answer is "(may be) no", in NEMO Basic Support. If VMN performs MIPv6 Route Optimization, direct communication may be possible once HoTi/CoTi is performed (so if for some reasons the MR is disconnected, it won't work). Such optimization should be taken of by extended support, once we come to work on it (if we do). Hope this helps. Thierry From nemo-admin@ietf.org Thu Aug 7 02:41:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02425 for ; Thu, 7 Aug 2003 02:41:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19keSL-00074K-Ek; Thu, 07 Aug 2003 02:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19keS4-00073f-Va for nemo@optimus.ietf.org; Thu, 07 Aug 2003 02:40:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02414 for ; Thu, 7 Aug 2003 02:40:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19keS1-0003Np-00 for nemo@ietf.org; Thu, 07 Aug 2003 02:40:41 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19keS0-0003Nf-00 for nemo@ietf.org; Thu, 07 Aug 2003 02:40:40 -0400 Received: from huez (Q118006.ppp.dion.ne.jp [61.204.118.6]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id A270F5D090 for ; Thu, 7 Aug 2003 15:40:09 +0900 (JST) Date: Thu, 7 Aug 2003 15:39:39 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] visting mobile node CoA Message-Id: <20030807153939.55041a86.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > When a visiting mobile node (VMN) together with Mobile network moves to > new location. Does VMN obtains the new care-of-address or it attains its > old care-of-address. Do we need to treat VMN as LFN once it obtains the > CoA from MR. I'm not sure what you really want to ask. VMN and LFNs do not obtain CoA from MR. LFN is a fixed node, so no CoA. VMN obtains a CoA from the link it attached to, with the home prefix of MR. So, if MR happens to obtain a new CoA, this is transparent to VMN. Thierry. From exim@www1.ietf.org Thu Aug 7 02:41:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02440 for ; Thu, 7 Aug 2003 02:41:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19keSN-000787-3F for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 02:41:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h776f2A5027306 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 02:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19keSM-00076L-Hk for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 02:41:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02418 for ; Thu, 7 Aug 2003 02:40:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19keSI-0003O0-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 02:40:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19keSI-0003Nx-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 02:40:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19keSL-00074K-Ek; Thu, 07 Aug 2003 02:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19keS4-00073f-Va for nemo@optimus.ietf.org; Thu, 07 Aug 2003 02:40:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02414 for ; Thu, 7 Aug 2003 02:40:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19keS1-0003Np-00 for nemo@ietf.org; Thu, 07 Aug 2003 02:40:41 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19keS0-0003Nf-00 for nemo@ietf.org; Thu, 07 Aug 2003 02:40:40 -0400 Received: from huez (Q118006.ppp.dion.ne.jp [61.204.118.6]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id A270F5D090 for ; Thu, 7 Aug 2003 15:40:09 +0900 (JST) Date: Thu, 7 Aug 2003 15:39:39 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] visting mobile node CoA Message-Id: <20030807153939.55041a86.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > When a visiting mobile node (VMN) together with Mobile network moves to > new location. Does VMN obtains the new care-of-address or it attains its > old care-of-address. Do we need to treat VMN as LFN once it obtains the > CoA from MR. I'm not sure what you really want to ask. VMN and LFNs do not obtain CoA from MR. LFN is a fixed node, so no CoA. VMN obtains a CoA from the link it attached to, with the home prefix of MR. So, if MR happens to obtain a new CoA, this is transparent to VMN. Thierry. From nemo-admin@ietf.org Thu Aug 7 04:47:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04715 for ; Thu, 7 Aug 2003 04:47:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kgQH-0003QS-6k; Thu, 07 Aug 2003 04:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kgPx-0003QG-31 for nemo@optimus.ietf.org; Thu, 07 Aug 2003 04:46:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04707 for ; Thu, 7 Aug 2003 04:46:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kgPu-00046q-00 for nemo@ietf.org; Thu, 07 Aug 2003 04:46:38 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19kgPt-00046n-00 for nemo@ietf.org; Thu, 07 Aug 2003 04:46:37 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h778kZBM016534; Thu, 7 Aug 2003 01:46:35 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h778kJKl012533; Thu, 7 Aug 2003 03:46:20 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 6AE2C2EC86; Thu, 7 Aug 2003 10:46:30 +0200 (CEST) Message-ID: <3F3211E5.1020807@motorola.com> Date: Thu, 07 Aug 2003 10:46:29 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Muhammad Ali Malik Cc: nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Muhammad Ali Malik wrote: > When a visting mobile node (VMN) needs to communicate with local > fixed node (LFN) of mobile network, can they communicate directly or > the communication need to pass via home agent of VMN. If VMN uses its permanent Home Address for this communication and neither VMN nor MR are at home, then communication passes via both HA of MR and HA of VMN. If VMN still uses its Home Address and MR is at home then communication passes only through HA of VMN. One might be tempted to think that if VMN does RO with LFN then that HA of VMN is eliminated too; however, LFN is said to not have Mobile IPv6 capabilities and thus can't support the CN side, so communication will necessarily go through HA of VMN. If VMN uses its CoA (not the permanent Home Address) then no communication with any HA is needed, it's all straight between VMN and LFN. Alex From exim@www1.ietf.org Thu Aug 7 04:47:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04730 for ; Thu, 7 Aug 2003 04:47:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kgQO-0003SS-7O for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 04:47:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h778l8Sd013292 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 04:47:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kgQN-0003SJ-Ks for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 04:47:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04712 for ; Thu, 7 Aug 2003 04:47:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kgQK-00046w-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 04:47:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kgQK-00046t-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 04:47:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kgQH-0003QS-6k; Thu, 07 Aug 2003 04:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kgPx-0003QG-31 for nemo@optimus.ietf.org; Thu, 07 Aug 2003 04:46:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04707 for ; Thu, 7 Aug 2003 04:46:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kgPu-00046q-00 for nemo@ietf.org; Thu, 07 Aug 2003 04:46:38 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19kgPt-00046n-00 for nemo@ietf.org; Thu, 07 Aug 2003 04:46:37 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h778kZBM016534; Thu, 7 Aug 2003 01:46:35 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h778kJKl012533; Thu, 7 Aug 2003 03:46:20 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 6AE2C2EC86; Thu, 7 Aug 2003 10:46:30 +0200 (CEST) Message-ID: <3F3211E5.1020807@motorola.com> Date: Thu, 07 Aug 2003 10:46:29 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Muhammad Ali Malik Cc: nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Muhammad Ali Malik wrote: > When a visting mobile node (VMN) needs to communicate with local > fixed node (LFN) of mobile network, can they communicate directly or > the communication need to pass via home agent of VMN. If VMN uses its permanent Home Address for this communication and neither VMN nor MR are at home, then communication passes via both HA of MR and HA of VMN. If VMN still uses its Home Address and MR is at home then communication passes only through HA of VMN. One might be tempted to think that if VMN does RO with LFN then that HA of VMN is eliminated too; however, LFN is said to not have Mobile IPv6 capabilities and thus can't support the CN side, so communication will necessarily go through HA of VMN. If VMN uses its CoA (not the permanent Home Address) then no communication with any HA is needed, it's all straight between VMN and LFN. Alex From nemo-admin@ietf.org Thu Aug 7 04:50:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04781 for ; Thu, 7 Aug 2003 04:50:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kgTB-0003bA-Dr; Thu, 07 Aug 2003 04:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kgSF-0003WV-9T for nemo@optimus.ietf.org; Thu, 07 Aug 2003 04:49:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04753 for ; Thu, 7 Aug 2003 04:48:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kgSC-00047H-00 for nemo@ietf.org; Thu, 07 Aug 2003 04:49:00 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19kgSB-00047E-00 for nemo@ietf.org; Thu, 07 Aug 2003 04:48:59 -0400 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h778muhx016601; Thu, 7 Aug 2003 01:48:56 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h778mqke012193; Thu, 7 Aug 2003 03:48:53 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 851702EC86; Thu, 7 Aug 2003 10:48:52 +0200 (CEST) Message-ID: <3F321274.7010800@motorola.com> Date: Thu, 07 Aug 2003 10:48:52 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Muhammad Ali Malik Cc: nemo@ietf.org Subject: Re: [nemo] visting mobile node CoA References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Muhammad Ali Malik wrote: > When a visiting mobile node (VMN) together with Mobile network moves > to new location. Does VMN obtains the new care-of-address or it > attains its old care-of-address. No VMN doesn't obtain a new CoA when MR obtains a new CoA; in this case VMN keeps its old CoA. > Do we need to treat VMN as LFN once it obtains the CoA from MR. Mostly yes, except that VMN can do RO while LFN no. Alex GBU From exim@www1.ietf.org Thu Aug 7 04:50:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04796 for ; Thu, 7 Aug 2003 04:50:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kgTC-0003dH-NH for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 04:50:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h778o2lF013957 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 04:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kgTC-0003d2-Hc for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 04:50:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04774 for ; Thu, 7 Aug 2003 04:49:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kgT9-00047X-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 04:49:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kgT9-00047U-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 04:49:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kgTB-0003bA-Dr; Thu, 07 Aug 2003 04:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kgSF-0003WV-9T for nemo@optimus.ietf.org; Thu, 07 Aug 2003 04:49:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04753 for ; Thu, 7 Aug 2003 04:48:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kgSC-00047H-00 for nemo@ietf.org; Thu, 07 Aug 2003 04:49:00 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19kgSB-00047E-00 for nemo@ietf.org; Thu, 07 Aug 2003 04:48:59 -0400 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h778muhx016601; Thu, 7 Aug 2003 01:48:56 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h778mqke012193; Thu, 7 Aug 2003 03:48:53 -0500 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 851702EC86; Thu, 7 Aug 2003 10:48:52 +0200 (CEST) Message-ID: <3F321274.7010800@motorola.com> Date: Thu, 07 Aug 2003 10:48:52 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Muhammad Ali Malik Cc: nemo@ietf.org Subject: Re: [nemo] visting mobile node CoA References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Muhammad Ali Malik wrote: > When a visiting mobile node (VMN) together with Mobile network moves > to new location. Does VMN obtains the new care-of-address or it > attains its old care-of-address. No VMN doesn't obtain a new CoA when MR obtains a new CoA; in this case VMN keeps its old CoA. > Do we need to treat VMN as LFN once it obtains the CoA from MR. Mostly yes, except that VMN can do RO while LFN no. Alex GBU From nemo-admin@ietf.org Thu Aug 7 06:13:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06371 for ; Thu, 7 Aug 2003 06:13:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khlV-00067T-7m; Thu, 07 Aug 2003 06:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khkq-000673-Bf for nemo@optimus.ietf.org; Thu, 07 Aug 2003 06:12:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06315 for ; Thu, 7 Aug 2003 06:12:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19khkm-0004a4-00 for nemo@ietf.org; Thu, 07 Aug 2003 06:12:16 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19khkl-0004ZA-00 for nemo@ietf.org; Thu, 07 Aug 2003 06:12:15 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Aug 2003 12:11:21 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h77A9W2k021333; Thu, 7 Aug 2003 12:09:33 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Aug 2003 12:11:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Aug 2003 11:11:45 +0100 Message-ID: Thread-Topic: Text changes to close issue 10 Thread-Index: AcNcRNmpJ+tynwMETp2iupGuZgzeDAAhxJmQ From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , X-OriginalArrivalTime: 07 Aug 2003 10:11:46.0114 (UTC) FILETIME=[4EC54220:01C35CCC] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Text changes to close issue 10 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I Vijay: I favor these changes too. Thanks for all the work. There's still the original question of differentiating implicit and IGP? Also, MUST is a bit severe for the 143, ain't it? Pascal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mercredi 6 ao=FBt 2003 20:01 > To: nemo@ietf.org > Cc: Pascal Thubert (pthubert) > Subject: Text changes to close issue 10 >=20 > hi all, >=20 > I made some significant changes to the text. this is for closing > issue 10. I realised that the Prefix Table and implict mode has > been a source for lot of confusion. many people dont seem to > like what was intended to be a simple solution. anyway here is > what I propose we should do. >=20 > 1. use Prefix Table only for verification in explicit mode. it > is used only if the HA needs to be prevent misbehaving MRs from > claiming prefixes that belong to other MRs. if a particular > deployment is such that the HA does not expect MRs to misbehave > then the Prefix Table is not required. >=20 > 2. make it clear in Implicit mode that any mechanism can be used. > it is totally internal to the Home Agent. remove all refereces to > using Prefix Table in implicit mode. >=20 > 3. change Binding Ack status 143 to 'Forwarding Setup failed'. it > is used to indicate that the HA was unable to setup forwarding > for the Mobile Network when it received a Binding Update from the > MR in implicit mode. >=20 > and here the proposed text changes to reflect this. let me > know what you think about these changes. >=20 >=20 > replace > > Prefix Table > > > > It is a list of a mobile network prefixes indexed > > by the extended Home Address of a Mobile Router. The > > prefix table is managed by the Home Agent. When a = Home > > Agent receives a Binding Update without any options, > > it searches a correspondent Mobile Network Prefix in > > the prefix table, keying with the Home Address of the > > requesting Mobile Router. This is an optional data > > structure. >=20 > with > Prefix Table >=20 > It is a list of a mobile network prefixes indexed > by the extended Home Address of a Mobile Router. The > prefix table is managed by the Home Agent. This is an > optional data structure. >=20 > replace > > 143 Mobile Network Prefix information unavailable. >=20 > with > 143 Forwarding Setup failed >=20 >=20 > replace > > The Home Agent can use any mechanism (not defined > > in this document) to determine the Mobile Network = Prefix(es) > > owned by the Mobile Router. One of the possible mechanisms = is > > where the Home Agent maintains a pre-configured Prefix = Table > > listing all the Mobile Network prefixes owned by a = particular > > Mobile Router. This table is keyed on the Home Address of = the > > Mobile Router. >=20 > with >=20 > The Home Agent can use any mechanism (not defined > in this document) to determine the Mobile Network Prefix(es) > owned by the Mobile Router and setup forwarding for the = Mobile > Network. One example would be manual configuration at the > Home Agent mapping the Mobile Router's home address to the > information required for setting up forwarding for the Mobile > Network. >=20 > replace > > In some scenarios, the Home Agent might need to maintain a Prefix > > Table of Mobile Routers and the IPv6 prefixes owned by Mobile > > Routers. The Home Agent MUST maintain this table if the Mobile > > Routers operate under the implicit mode where they do not include = any > > prefix information in the Binding Updates. > > > > Each entry in the Prefix Table conceptually contains the = following > > fields: > > > > - The Home Address of the Mobile Router. This field is used as = the > > key for searching the pre-configured prefix table. > > > > - The Mobile Network Prefix of the Mobile Router associated = with > > the Home Address. > > > > In some deployment scenarios, it is necessary for Home Agent to > > prevent a misbehaving Mobile Router from claiming mobile network > > prefixes belonging to another Mobile Router. The Home Agent can > > prevent such attacks if it maintains the Prefix Table and = verifies > > the Prefix Information provided by the Mobile Router against the > > if the Binding Update contained explicit prefix information in = the > > form of either the Mobile Network Prefix Option or the Mobile = Network > > Prefix Length Option. >=20 > with >=20 > In some deployment scenarios it may be necessary for the Home Agent > to prevent a misbehaving Mobile Router from claiming mobile network > prefixes belonging to another Mobile Router. The Home Agent can > prevent such attacks if it maintains the Prefix Table and verifies > the Prefix Information provided by the Mobile Router against the > entries in the Prefix Table. However, this verification is done = only > if the Binding Update contained explicit prefix information in the > form of either the Mobile Network Prefix Option or the Mobile = Network > Prefix Length Option. >=20 > Each entry in the Prefix Table conceptually contains the following > fields: >=20 > - The Home Address of the Mobile Router. This field is used as = the > key for searching the pre-configured prefix table. >=20 > - The Mobile Network Prefix of the Mobile Router associated with > the Home Address. >=20 > replace > > - If there are no options in the Binding Update, the Home Agent > > figures out which prefixes are assigned to the Mobile Router > > from the Pre-configured Prefix Table. If the Home Agent can = not > > find the correspondent Mobile Network Prefix, it MUST reject = the > > Binding Update and send a Binding Acknowledgement with the = Status > > field set to 143 (Prefix Information unavailable). >=20 > to > - If there are no options in the Binding Update, the Home Agent > uses manual pre-configured information to determine the > prefixes assigned to the Mobile Router and for setting up > forwarding for the Mobile Network. If there is no information > that the Home Agent can use, it MUST reject the Binding Update > and send a Binding Acknowledgement with status set to 143 > (Forwarding Setup failed). >=20 > replace > > The Home Agent sets the status code in the Binding = Acknowledgement > > to '143' (Mobile Network Prefix information unavailable) in order > > to indicate the Mobile Router that the received Home Address in = the > > Binding Update does not match any prefix entry in the = pre-configured > > prefix table. This is used in the Implicit case where the Mobile > > Router does not include any prefix information in the Binding = Update. >=20 >=20 > with >=20 > The Home Agent sets the status code to 143 (Forwarding Setup > failed) if it is unable to determine the information needed to = setup > forwarding for the Mobile Network. This is used in the Implicit = mode > where the Mobile Router does not include any prefix information in > the Binding Update. >=20 >=20 > Vijay From exim@www1.ietf.org Thu Aug 7 06:13:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06390 for ; Thu, 7 Aug 2003 06:13:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khlZ-00068n-Vu for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 06:13:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77AD5Ka023602 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 06:13:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khlZ-00068b-Pc for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 06:13:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06351 for ; Thu, 7 Aug 2003 06:12:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19khlW-0004b7-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 06:13:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19khlV-0004b4-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 06:13:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khlV-00067T-7m; Thu, 07 Aug 2003 06:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khkq-000673-Bf for nemo@optimus.ietf.org; Thu, 07 Aug 2003 06:12:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06315 for ; Thu, 7 Aug 2003 06:12:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19khkm-0004a4-00 for nemo@ietf.org; Thu, 07 Aug 2003 06:12:16 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19khkl-0004ZA-00 for nemo@ietf.org; Thu, 07 Aug 2003 06:12:15 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Aug 2003 12:11:21 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h77A9W2k021333; Thu, 7 Aug 2003 12:09:33 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Aug 2003 12:11:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Aug 2003 11:11:45 +0100 Message-ID: Thread-Topic: Text changes to close issue 10 Thread-Index: AcNcRNmpJ+tynwMETp2iupGuZgzeDAAhxJmQ From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , X-OriginalArrivalTime: 07 Aug 2003 10:11:46.0114 (UTC) FILETIME=[4EC54220:01C35CCC] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Text changes to close issue 10 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I Vijay: I favor these changes too. Thanks for all the work. There's still the original question of differentiating implicit and IGP? Also, MUST is a bit severe for the 143, ain't it? Pascal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mercredi 6 ao=FBt 2003 20:01 > To: nemo@ietf.org > Cc: Pascal Thubert (pthubert) > Subject: Text changes to close issue 10 >=20 > hi all, >=20 > I made some significant changes to the text. this is for closing > issue 10. I realised that the Prefix Table and implict mode has > been a source for lot of confusion. many people dont seem to > like what was intended to be a simple solution. anyway here is > what I propose we should do. >=20 > 1. use Prefix Table only for verification in explicit mode. it > is used only if the HA needs to be prevent misbehaving MRs from > claiming prefixes that belong to other MRs. if a particular > deployment is such that the HA does not expect MRs to misbehave > then the Prefix Table is not required. >=20 > 2. make it clear in Implicit mode that any mechanism can be used. > it is totally internal to the Home Agent. remove all refereces to > using Prefix Table in implicit mode. >=20 > 3. change Binding Ack status 143 to 'Forwarding Setup failed'. it > is used to indicate that the HA was unable to setup forwarding > for the Mobile Network when it received a Binding Update from the > MR in implicit mode. >=20 > and here the proposed text changes to reflect this. let me > know what you think about these changes. >=20 >=20 > replace > > Prefix Table > > > > It is a list of a mobile network prefixes indexed > > by the extended Home Address of a Mobile Router. The > > prefix table is managed by the Home Agent. When a = Home > > Agent receives a Binding Update without any options, > > it searches a correspondent Mobile Network Prefix in > > the prefix table, keying with the Home Address of the > > requesting Mobile Router. This is an optional data > > structure. >=20 > with > Prefix Table >=20 > It is a list of a mobile network prefixes indexed > by the extended Home Address of a Mobile Router. The > prefix table is managed by the Home Agent. This is an > optional data structure. >=20 > replace > > 143 Mobile Network Prefix information unavailable. >=20 > with > 143 Forwarding Setup failed >=20 >=20 > replace > > The Home Agent can use any mechanism (not defined > > in this document) to determine the Mobile Network = Prefix(es) > > owned by the Mobile Router. One of the possible mechanisms = is > > where the Home Agent maintains a pre-configured Prefix = Table > > listing all the Mobile Network prefixes owned by a = particular > > Mobile Router. This table is keyed on the Home Address of = the > > Mobile Router. >=20 > with >=20 > The Home Agent can use any mechanism (not defined > in this document) to determine the Mobile Network Prefix(es) > owned by the Mobile Router and setup forwarding for the = Mobile > Network. One example would be manual configuration at the > Home Agent mapping the Mobile Router's home address to the > information required for setting up forwarding for the Mobile > Network. >=20 > replace > > In some scenarios, the Home Agent might need to maintain a Prefix > > Table of Mobile Routers and the IPv6 prefixes owned by Mobile > > Routers. The Home Agent MUST maintain this table if the Mobile > > Routers operate under the implicit mode where they do not include = any > > prefix information in the Binding Updates. > > > > Each entry in the Prefix Table conceptually contains the = following > > fields: > > > > - The Home Address of the Mobile Router. This field is used as = the > > key for searching the pre-configured prefix table. > > > > - The Mobile Network Prefix of the Mobile Router associated = with > > the Home Address. > > > > In some deployment scenarios, it is necessary for Home Agent to > > prevent a misbehaving Mobile Router from claiming mobile network > > prefixes belonging to another Mobile Router. The Home Agent can > > prevent such attacks if it maintains the Prefix Table and = verifies > > the Prefix Information provided by the Mobile Router against the > > if the Binding Update contained explicit prefix information in = the > > form of either the Mobile Network Prefix Option or the Mobile = Network > > Prefix Length Option. >=20 > with >=20 > In some deployment scenarios it may be necessary for the Home Agent > to prevent a misbehaving Mobile Router from claiming mobile network > prefixes belonging to another Mobile Router. The Home Agent can > prevent such attacks if it maintains the Prefix Table and verifies > the Prefix Information provided by the Mobile Router against the > entries in the Prefix Table. However, this verification is done = only > if the Binding Update contained explicit prefix information in the > form of either the Mobile Network Prefix Option or the Mobile = Network > Prefix Length Option. >=20 > Each entry in the Prefix Table conceptually contains the following > fields: >=20 > - The Home Address of the Mobile Router. This field is used as = the > key for searching the pre-configured prefix table. >=20 > - The Mobile Network Prefix of the Mobile Router associated with > the Home Address. >=20 > replace > > - If there are no options in the Binding Update, the Home Agent > > figures out which prefixes are assigned to the Mobile Router > > from the Pre-configured Prefix Table. If the Home Agent can = not > > find the correspondent Mobile Network Prefix, it MUST reject = the > > Binding Update and send a Binding Acknowledgement with the = Status > > field set to 143 (Prefix Information unavailable). >=20 > to > - If there are no options in the Binding Update, the Home Agent > uses manual pre-configured information to determine the > prefixes assigned to the Mobile Router and for setting up > forwarding for the Mobile Network. If there is no information > that the Home Agent can use, it MUST reject the Binding Update > and send a Binding Acknowledgement with status set to 143 > (Forwarding Setup failed). >=20 > replace > > The Home Agent sets the status code in the Binding = Acknowledgement > > to '143' (Mobile Network Prefix information unavailable) in order > > to indicate the Mobile Router that the received Home Address in = the > > Binding Update does not match any prefix entry in the = pre-configured > > prefix table. This is used in the Implicit case where the Mobile > > Router does not include any prefix information in the Binding = Update. >=20 >=20 > with >=20 > The Home Agent sets the status code to 143 (Forwarding Setup > failed) if it is unable to determine the information needed to = setup > forwarding for the Mobile Network. This is used in the Implicit = mode > where the Mobile Router does not include any prefix information in > the Binding Update. >=20 >=20 > Vijay From nemo-admin@ietf.org Thu Aug 7 06:21:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06628 for ; Thu, 7 Aug 2003 06:21:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khtE-0006RM-LZ; Thu, 07 Aug 2003 06:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khsI-0006QM-58 for nemo@optimus.ietf.org; Thu, 07 Aug 2003 06:20:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06566 for ; Thu, 7 Aug 2003 06:19:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19khsE-0004gt-00 for nemo@ietf.org; Thu, 07 Aug 2003 06:19:58 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19khsD-0004gS-00 for nemo@ietf.org; Thu, 07 Aug 2003 06:19:57 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Aug 2003 12:19:03 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h77AGp2o022709; Thu, 7 Aug 2003 12:17:14 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Aug 2003 12:19:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] crossover tunnel.... Date: Thu, 7 Aug 2003 11:19:11 +0100 Message-ID: Thread-Topic: [nemo] crossover tunnel.... Thread-Index: AcNcrr1iYBRYAZxHTRKAF+DunodwkAAHZYOA From: "Pascal Thubert (pthubert)" To: "Thierry Ernst" , X-OriginalArrivalTime: 07 Aug 2003 10:19:11.0601 (UTC) FILETIME=[584D2E10:01C35CCD] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hum... Actually this is not a Nemo but a MIP question, since it's a MN talking = to a FN in a given network. What the MN should have done is set a connected route to the visited = prefix.=20 If the MN starts a connection with the FN, its source address selection = should have used the CareOf to talk to the FN, and the routing should = not have encapsulated the packet over the tunnel. So the MN can send = packets to the FN, and the FN can respond. But I'm not sure all implementations work that way. Mine does (since MR = extends MN). We should have mentioned SAS in MIP (as I said at the last = Nemo WG :) ... Pascal > -----Original Message----- > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > Sent: jeudi 7 ao=FBt 2003 08:37 > To: nemo@ietf.org > Subject: Re: [nemo] crossover tunnel.... >=20 >=20 > > When a visting mobile node (VMN) needs to communicate with local = fixed > > node (LFN) of mobile network, can they communicate directly or the > > communication need to pass via home agent of VMN. >=20 > Good question. And the answer is "(may be) no", in NEMO Basic > Support. If VMN performs MIPv6 Route Optimization, direct = communication > may be possible once HoTi/CoTi is performed (so if for some reasons = the > MR is disconnected, it won't work). Such optimization should be taken = of > by extended support, once we come to work on it (if we do). >=20 > Hope this helps. > Thierry From exim@www1.ietf.org Thu Aug 7 06:21:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06645 for ; Thu, 7 Aug 2003 06:21:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khtG-0006Tf-0o for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 06:21:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77AL1XC024893 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 06:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khtF-0006TQ-Sp for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 06:21:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06606 for ; Thu, 7 Aug 2003 06:20:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19khtC-0004hr-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 06:20:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19khtB-0004ho-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 06:20:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khtE-0006RM-LZ; Thu, 07 Aug 2003 06:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khsI-0006QM-58 for nemo@optimus.ietf.org; Thu, 07 Aug 2003 06:20:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06566 for ; Thu, 7 Aug 2003 06:19:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19khsE-0004gt-00 for nemo@ietf.org; Thu, 07 Aug 2003 06:19:58 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19khsD-0004gS-00 for nemo@ietf.org; Thu, 07 Aug 2003 06:19:57 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Aug 2003 12:19:03 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h77AGp2o022709; Thu, 7 Aug 2003 12:17:14 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Aug 2003 12:19:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] crossover tunnel.... Date: Thu, 7 Aug 2003 11:19:11 +0100 Message-ID: Thread-Topic: [nemo] crossover tunnel.... Thread-Index: AcNcrr1iYBRYAZxHTRKAF+DunodwkAAHZYOA From: "Pascal Thubert (pthubert)" To: "Thierry Ernst" , X-OriginalArrivalTime: 07 Aug 2003 10:19:11.0601 (UTC) FILETIME=[584D2E10:01C35CCD] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hum... Actually this is not a Nemo but a MIP question, since it's a MN talking = to a FN in a given network. What the MN should have done is set a connected route to the visited = prefix.=20 If the MN starts a connection with the FN, its source address selection = should have used the CareOf to talk to the FN, and the routing should = not have encapsulated the packet over the tunnel. So the MN can send = packets to the FN, and the FN can respond. But I'm not sure all implementations work that way. Mine does (since MR = extends MN). We should have mentioned SAS in MIP (as I said at the last = Nemo WG :) ... Pascal > -----Original Message----- > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > Sent: jeudi 7 ao=FBt 2003 08:37 > To: nemo@ietf.org > Subject: Re: [nemo] crossover tunnel.... >=20 >=20 > > When a visting mobile node (VMN) needs to communicate with local = fixed > > node (LFN) of mobile network, can they communicate directly or the > > communication need to pass via home agent of VMN. >=20 > Good question. And the answer is "(may be) no", in NEMO Basic > Support. If VMN performs MIPv6 Route Optimization, direct = communication > may be possible once HoTi/CoTi is performed (so if for some reasons = the > MR is disconnected, it won't work). Such optimization should be taken = of > by extended support, once we come to work on it (if we do). >=20 > Hope this helps. > Thierry From nemo-admin@ietf.org Thu Aug 7 06:24:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06862 for ; Thu, 7 Aug 2003 06:24:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khw9-0006dy-Lk; Thu, 07 Aug 2003 06:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khvc-0006de-OJ for nemo@optimus.ietf.org; Thu, 07 Aug 2003 06:23:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06829 for ; Thu, 7 Aug 2003 06:23:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19khvY-0004nM-00 for nemo@ietf.org; Thu, 07 Aug 2003 06:23:24 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19khvX-0004mE-00 for nemo@ietf.org; Thu, 07 Aug 2003 06:23:24 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Aug 2003 12:22:28 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h77AKbGk023438; Thu, 7 Aug 2003 12:20:41 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Aug 2003 12:22:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] visting mobile node CoA Date: Thu, 7 Aug 2003 11:22:49 +0100 Message-ID: Thread-Topic: [nemo] visting mobile node CoA Thread-Index: AcNcrusVWrxAytTUT6KY31A9slQPhQAHpwdg From: "Pascal Thubert (pthubert)" To: "Thierry Ernst" , X-OriginalArrivalTime: 07 Aug 2003 10:22:50.0259 (UTC) FILETIME=[DAA1BE30:01C35CCD] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thierry,=20 I can not parse your answer ???? Yes, the VMN gets a careof from the MR = (MNP) and with basic, it is totally unaware of the MR movements. Some RO = solutions change that more or less, though. Pascal > -----Original Message----- > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > Sent: jeudi 7 ao=FBt 2003 08:40 > To: nemo@ietf.org > Subject: Re: [nemo] visting mobile node CoA >=20 >=20 > > When a visiting mobile node (VMN) together with Mobile network moves = to > > new location. Does VMN obtains the new care-of-address or it attains = its > > old care-of-address. Do we need to treat VMN as LFN once it obtains = the > > CoA from MR. >=20 > I'm not sure what you really want to ask. VMN and LFNs do not obtain = CoA > from MR. LFN is a fixed node, so no CoA. VMN obtains a CoA from the = link > it attached to, with the home prefix of MR. So, if MR happens to = obtain > a new CoA, this is transparent to VMN. >=20 > Thierry. From exim@www1.ietf.org Thu Aug 7 06:24:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06877 for ; Thu, 7 Aug 2003 06:24:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khwB-0006g9-C5 for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 06:24:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77AO3Xw025667 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 06:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khwB-0006fu-6s for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 06:24:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06852 for ; Thu, 7 Aug 2003 06:23:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19khw7-0004o2-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 06:23:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19khw6-0004nz-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 06:23:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khw9-0006dy-Lk; Thu, 07 Aug 2003 06:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19khvc-0006de-OJ for nemo@optimus.ietf.org; Thu, 07 Aug 2003 06:23:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06829 for ; Thu, 7 Aug 2003 06:23:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19khvY-0004nM-00 for nemo@ietf.org; Thu, 07 Aug 2003 06:23:24 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19khvX-0004mE-00 for nemo@ietf.org; Thu, 07 Aug 2003 06:23:24 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Aug 2003 12:22:28 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h77AKbGk023438; Thu, 7 Aug 2003 12:20:41 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Aug 2003 12:22:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] visting mobile node CoA Date: Thu, 7 Aug 2003 11:22:49 +0100 Message-ID: Thread-Topic: [nemo] visting mobile node CoA Thread-Index: AcNcrusVWrxAytTUT6KY31A9slQPhQAHpwdg From: "Pascal Thubert (pthubert)" To: "Thierry Ernst" , X-OriginalArrivalTime: 07 Aug 2003 10:22:50.0259 (UTC) FILETIME=[DAA1BE30:01C35CCD] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thierry,=20 I can not parse your answer ???? Yes, the VMN gets a careof from the MR = (MNP) and with basic, it is totally unaware of the MR movements. Some RO = solutions change that more or less, though. Pascal > -----Original Message----- > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > Sent: jeudi 7 ao=FBt 2003 08:40 > To: nemo@ietf.org > Subject: Re: [nemo] visting mobile node CoA >=20 >=20 > > When a visiting mobile node (VMN) together with Mobile network moves = to > > new location. Does VMN obtains the new care-of-address or it attains = its > > old care-of-address. Do we need to treat VMN as LFN once it obtains = the > > CoA from MR. >=20 > I'm not sure what you really want to ask. VMN and LFNs do not obtain = CoA > from MR. LFN is a fixed node, so no CoA. VMN obtains a CoA from the = link > it attached to, with the home prefix of MR. So, if MR happens to = obtain > a new CoA, this is transparent to VMN. >=20 > Thierry. From nemo-admin@ietf.org Thu Aug 7 07:21:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08218 for ; Thu, 7 Aug 2003 07:21:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kipI-0008LS-VN; Thu, 07 Aug 2003 07:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kipF-0008L7-BE for nemo@optimus.ietf.org; Thu, 07 Aug 2003 07:20:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08208 for ; Thu, 7 Aug 2003 07:20:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kipE-00057N-00 for nemo@ietf.org; Thu, 07 Aug 2003 07:20:56 -0400 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx with smtp (Exim 4.12) id 19kipE-00057K-00 for nemo@ietf.org; Thu, 07 Aug 2003 07:20:56 -0400 Received: From mozart With LocalMail ; Thu, 7 Aug 2003 21:20:46 +1000 From: Muhammad Ali Malik To: Thierry Ernst Date: Thu, 7 Aug 2003 21:20:46 +1000 (EST) X-X-Sender: mamalik@mozart.orchestra.cse.unsw.EDU.AU cc: nemo@ietf.org Subject: Re: [nemo] visting mobile node CoA In-Reply-To: <20030807153939.55041a86.ernst@sfc.wide.ad.jp> Message-ID: References: <20030807153939.55041a86.ernst@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Thierry Thanxx for reponse. My question is that suppose VMN joins the Mobile Network at home location. Then VMN together with Mobile Network moves to new location. At this new location, can VMN communicate directly to CN or the communication between VMN and CN must take place via home agent of MR. Thanxx in advance. Malik On Thu, 7 Aug 2003, Thierry Ernst wrote: > > > When a visiting mobile node (VMN) together with Mobile network moves to > > new location. Does VMN obtains the new care-of-address or it attains its > > old care-of-address. Do we need to treat VMN as LFN once it obtains the > > CoA from MR. > > I'm not sure what you really want to ask. VMN and LFNs do not obtain CoA > from MR. LFN is a fixed node, so no CoA. VMN obtains a CoA from the link > it attached to, with the home prefix of MR. So, if MR happens to obtain > a new CoA, this is transparent to VMN. > > Thierry. > From exim@www1.ietf.org Thu Aug 7 07:21:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08233 for ; Thu, 7 Aug 2003 07:21:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kipN-0008MP-QF for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 07:21:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77BL568032136 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 07:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kipN-0008MF-L9 for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 07:21:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08215 for ; Thu, 7 Aug 2003 07:21:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kipN-00057Z-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 07:21:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kipM-00057W-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 07:21:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kipI-0008LS-VN; Thu, 07 Aug 2003 07:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kipF-0008L7-BE for nemo@optimus.ietf.org; Thu, 07 Aug 2003 07:20:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08208 for ; Thu, 7 Aug 2003 07:20:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kipE-00057N-00 for nemo@ietf.org; Thu, 07 Aug 2003 07:20:56 -0400 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx with smtp (Exim 4.12) id 19kipE-00057K-00 for nemo@ietf.org; Thu, 07 Aug 2003 07:20:56 -0400 Received: From mozart With LocalMail ; Thu, 7 Aug 2003 21:20:46 +1000 From: Muhammad Ali Malik To: Thierry Ernst Date: Thu, 7 Aug 2003 21:20:46 +1000 (EST) X-X-Sender: mamalik@mozart.orchestra.cse.unsw.EDU.AU cc: nemo@ietf.org Subject: Re: [nemo] visting mobile node CoA In-Reply-To: <20030807153939.55041a86.ernst@sfc.wide.ad.jp> Message-ID: References: <20030807153939.55041a86.ernst@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Thierry Thanxx for reponse. My question is that suppose VMN joins the Mobile Network at home location. Then VMN together with Mobile Network moves to new location. At this new location, can VMN communicate directly to CN or the communication between VMN and CN must take place via home agent of MR. Thanxx in advance. Malik On Thu, 7 Aug 2003, Thierry Ernst wrote: > > > When a visiting mobile node (VMN) together with Mobile network moves to > > new location. Does VMN obtains the new care-of-address or it attains its > > old care-of-address. Do we need to treat VMN as LFN once it obtains the > > CoA from MR. > > I'm not sure what you really want to ask. VMN and LFNs do not obtain CoA > from MR. LFN is a fixed node, so no CoA. VMN obtains a CoA from the link > it attached to, with the home prefix of MR. So, if MR happens to obtain > a new CoA, this is transparent to VMN. > > Thierry. > From nemo-admin@ietf.org Thu Aug 7 07:40:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08510 for ; Thu, 7 Aug 2003 07:40:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kj7g-0000fF-JA; Thu, 07 Aug 2003 07:40:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kj6m-0000Xd-AU for nemo@optimus.ietf.org; Thu, 07 Aug 2003 07:39:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08467 for ; Thu, 7 Aug 2003 07:38:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kj6l-0005BT-00 for nemo@ietf.org; Thu, 07 Aug 2003 07:39:03 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19kj6k-0005BD-00 for nemo@ietf.org; Thu, 07 Aug 2003 07:39:03 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Aug 2003 13:38:06 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h77BaIZJ007679; Thu, 7 Aug 2003 13:36:18 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Aug 2003 13:38:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] crossover tunnel.... Date: Thu, 7 Aug 2003 12:38:30 +0100 Message-ID: Thread-Topic: [nemo] crossover tunnel.... Thread-Index: AcNc01ByyP+P7l3HT+uA1FwqKzWo3wAAn4Kw From: "Pascal Thubert (pthubert)" To: "Jongkeun Na" Cc: X-OriginalArrivalTime: 07 Aug 2003 11:38:31.0085 (UTC) FILETIME=[6D2CCDD0:01C35CD8] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Source Address Selection in IPv6... Look at MIPv6 chapter 11.3.1, second = bullet: There's this thing that: The mobile node MAY choose to directly use one of its care-of addresses as the source of the packet, not requiring the use of a Home Address option in the packet. This is particularly useful for short-term communication that may easily be retried if it fails. The way I see it, for SAS, the MIP tunnel is yet another interface, with = the home address on it. So if the packet goes over that tunnel, the home = address is the natural source address selection. Now for an MN talking to an FN on the same network (FN's address has = same prefix as MN's CareOf), they both have a connected route to the = prefix; so for the MN, the next hop is not over the tunnel but over the = roaming interface, and the CareOf is the natural global address there, = thus it's selected as source. This is even more crucial for a Mobile Router since it also has = connected routes to the Mobile Network Prefix, and it's much better for = a MR to use its MNP based address to talk to a device on the mobile = network, isn't it? This all works fine even if the HA is not reachable; but if the MN = moves, the connections will be broken. Trade Off. Should we make an issue of this? Discuss a little bit SAS in the basic = Nemo draft? Personally I'd go for it. Pascal > -----Original Message----- > From: Jongkeun Na [mailto:jkna@popeye.snu.ac.kr] > Sent: jeudi 7 ao=FBt 2003 13:04 > To: Pascal Thubert (pthubert) > Subject: RE: [nemo] crossover tunnel.... >=20 > SAS in MIP .. what mean? >=20 > > -----Original Message----- > > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of > Pascal > > Thubert (pthubert) > > Sent: Thursday, August 07, 2003 7:19 PM > > To: Thierry Ernst; nemo@ietf.org > > Subject: RE: [nemo] crossover tunnel.... > > > > Hum... > > > > Actually this is not a Nemo but a MIP question, since it's a MN > talking to a FN in a > > given network. > > > > What the MN should have done is set a connected route to the visited > prefix. > > > > If the MN starts a connection with the FN, its source address > selection should have > > used the CareOf to talk to the FN, and the routing should not have > encapsulated > > the packet over the tunnel. So the MN can send packets to the FN, = and > the FN can > > respond. > > > > But I'm not sure all implementations work that way. Mine does (since > MR extends > > MN). We should have mentioned SAS in MIP (as I said at the last Nemo > WG :) ... > > > > Pascal > > > > > -----Original Message----- > > > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > > > Sent: jeudi 7 ao=FBt 2003 08:37 > > > To: nemo@ietf.org > > > Subject: Re: [nemo] crossover tunnel.... > > > > > > > > > > When a visting mobile node (VMN) needs to communicate with local > fixed > > > > node (LFN) of mobile network, can they communicate directly or = the > > > > communication need to pass via home agent of VMN. > > > > > > Good question. And the answer is "(may be) no", in NEMO Basic > > > Support. If VMN performs MIPv6 Route Optimization, direct > communication > > > may be possible once HoTi/CoTi is performed (so if for some = reasons > the > > > MR is disconnected, it won't work). Such optimization should be > taken of > > > by extended support, once we come to work on it (if we do). > > > > > > Hope this helps. > > > Thierry >=20 From exim@www1.ietf.org Thu Aug 7 07:40:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08525 for ; Thu, 7 Aug 2003 07:40:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kj7i-0000hL-TK for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 07:40:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77Be20a002680 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 07:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kj7i-0000h9-A9 for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 07:40:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08505 for ; Thu, 7 Aug 2003 07:39:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kj7h-0005Bz-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 07:40:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kj7h-0005Bw-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 07:40:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kj7g-0000fF-JA; Thu, 07 Aug 2003 07:40:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kj6m-0000Xd-AU for nemo@optimus.ietf.org; Thu, 07 Aug 2003 07:39:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08467 for ; Thu, 7 Aug 2003 07:38:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kj6l-0005BT-00 for nemo@ietf.org; Thu, 07 Aug 2003 07:39:03 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19kj6k-0005BD-00 for nemo@ietf.org; Thu, 07 Aug 2003 07:39:03 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Aug 2003 13:38:06 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h77BaIZJ007679; Thu, 7 Aug 2003 13:36:18 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Aug 2003 13:38:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] crossover tunnel.... Date: Thu, 7 Aug 2003 12:38:30 +0100 Message-ID: Thread-Topic: [nemo] crossover tunnel.... Thread-Index: AcNc01ByyP+P7l3HT+uA1FwqKzWo3wAAn4Kw From: "Pascal Thubert (pthubert)" To: "Jongkeun Na" Cc: X-OriginalArrivalTime: 07 Aug 2003 11:38:31.0085 (UTC) FILETIME=[6D2CCDD0:01C35CD8] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Source Address Selection in IPv6... Look at MIPv6 chapter 11.3.1, second = bullet: There's this thing that: The mobile node MAY choose to directly use one of its care-of addresses as the source of the packet, not requiring the use of a Home Address option in the packet. This is particularly useful for short-term communication that may easily be retried if it fails. The way I see it, for SAS, the MIP tunnel is yet another interface, with = the home address on it. So if the packet goes over that tunnel, the home = address is the natural source address selection. Now for an MN talking to an FN on the same network (FN's address has = same prefix as MN's CareOf), they both have a connected route to the = prefix; so for the MN, the next hop is not over the tunnel but over the = roaming interface, and the CareOf is the natural global address there, = thus it's selected as source. This is even more crucial for a Mobile Router since it also has = connected routes to the Mobile Network Prefix, and it's much better for = a MR to use its MNP based address to talk to a device on the mobile = network, isn't it? This all works fine even if the HA is not reachable; but if the MN = moves, the connections will be broken. Trade Off. Should we make an issue of this? Discuss a little bit SAS in the basic = Nemo draft? Personally I'd go for it. Pascal > -----Original Message----- > From: Jongkeun Na [mailto:jkna@popeye.snu.ac.kr] > Sent: jeudi 7 ao=FBt 2003 13:04 > To: Pascal Thubert (pthubert) > Subject: RE: [nemo] crossover tunnel.... >=20 > SAS in MIP .. what mean? >=20 > > -----Original Message----- > > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of > Pascal > > Thubert (pthubert) > > Sent: Thursday, August 07, 2003 7:19 PM > > To: Thierry Ernst; nemo@ietf.org > > Subject: RE: [nemo] crossover tunnel.... > > > > Hum... > > > > Actually this is not a Nemo but a MIP question, since it's a MN > talking to a FN in a > > given network. > > > > What the MN should have done is set a connected route to the visited > prefix. > > > > If the MN starts a connection with the FN, its source address > selection should have > > used the CareOf to talk to the FN, and the routing should not have > encapsulated > > the packet over the tunnel. So the MN can send packets to the FN, = and > the FN can > > respond. > > > > But I'm not sure all implementations work that way. Mine does (since > MR extends > > MN). We should have mentioned SAS in MIP (as I said at the last Nemo > WG :) ... > > > > Pascal > > > > > -----Original Message----- > > > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > > > Sent: jeudi 7 ao=FBt 2003 08:37 > > > To: nemo@ietf.org > > > Subject: Re: [nemo] crossover tunnel.... > > > > > > > > > > When a visting mobile node (VMN) needs to communicate with local > fixed > > > > node (LFN) of mobile network, can they communicate directly or = the > > > > communication need to pass via home agent of VMN. > > > > > > Good question. And the answer is "(may be) no", in NEMO Basic > > > Support. If VMN performs MIPv6 Route Optimization, direct > communication > > > may be possible once HoTi/CoTi is performed (so if for some = reasons > the > > > MR is disconnected, it won't work). Such optimization should be > taken of > > > by extended support, once we come to work on it (if we do). > > > > > > Hope this helps. > > > Thierry >=20 From nemo-admin@ietf.org Thu Aug 7 07:53:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08870 for ; Thu, 7 Aug 2003 07:53:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjKG-00018q-Qq; Thu, 07 Aug 2003 07:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjK5-00018Y-Mt for nemo@optimus.ietf.org; Thu, 07 Aug 2003 07:52:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08802; Thu, 7 Aug 2003 07:52:44 -0400 (EDT) Message-Id: <200308071152.HAA08802@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 07 Aug 2003 07:52:44 -0400 Subject: [nemo] I-D ACTION:draft-perera-nemo-extended-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extended Network Mobility Support Author(s) : E. Perera et al. Filename : draft-perera-nemo-extended-00.txt Pages : 15 Date : 2003-7-29 This draft proposes a solution for extended network mobility support, that is a mechanism to enable optimal routing between mobile network nodes and its correspondent nodes. The proposed scheme not only provides optimal routing for the mobility aware nodes but also maintains the benefits of mobility transparency. Our solution achieves route optimization by expecting the Mobile Router to take the role of an Access Router thereby reducing the number of external signaling messages a node behind the Mobile Router needs to perform. In order to further reduce the number of signaling messages beyond the scope of the mobile network we further propose the Mobile Router to play the role of an Home Agent for NEMO-enabled nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perera-nemo-extended-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-perera-nemo-extended-00.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-perera-nemo-extended-00.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-7081157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-perera-nemo-extended-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-perera-nemo-extended-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-7081157.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Thu Aug 7 07:53:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08886 for ; Thu, 7 Aug 2003 07:53:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjKJ-0001BB-5c for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 07:53:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77Br3Gw004528 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 07:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjKJ-0001AW-0B for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 07:53:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08862 for ; Thu, 7 Aug 2003 07:52:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kjKI-0005GO-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 07:53:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kjKH-0005GL-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 07:53:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjKG-00018q-Qq; Thu, 07 Aug 2003 07:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjK5-00018Y-Mt for nemo@optimus.ietf.org; Thu, 07 Aug 2003 07:52:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08802; Thu, 7 Aug 2003 07:52:44 -0400 (EDT) Message-Id: <200308071152.HAA08802@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 07 Aug 2003 07:52:44 -0400 Subject: [nemo] I-D ACTION:draft-perera-nemo-extended-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extended Network Mobility Support Author(s) : E. Perera et al. Filename : draft-perera-nemo-extended-00.txt Pages : 15 Date : 2003-7-29 This draft proposes a solution for extended network mobility support, that is a mechanism to enable optimal routing between mobile network nodes and its correspondent nodes. The proposed scheme not only provides optimal routing for the mobility aware nodes but also maintains the benefits of mobility transparency. Our solution achieves route optimization by expecting the Mobile Router to take the role of an Access Router thereby reducing the number of external signaling messages a node behind the Mobile Router needs to perform. In order to further reduce the number of signaling messages beyond the scope of the mobile network we further propose the Mobile Router to play the role of an Home Agent for NEMO-enabled nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perera-nemo-extended-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-perera-nemo-extended-00.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-perera-nemo-extended-00.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-7081157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-perera-nemo-extended-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-perera-nemo-extended-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-7081157.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-admin@ietf.org Thu Aug 7 08:17:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09704 for ; Thu, 7 Aug 2003 08:17:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjhV-0002Mc-4P; Thu, 07 Aug 2003 08:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjgi-0002MA-Sa for nemo@optimus.ietf.org; Thu, 07 Aug 2003 08:16:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09642 for ; Thu, 7 Aug 2003 08:16:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kjgh-0005U5-00 for nemo@ietf.org; Thu, 07 Aug 2003 08:16:11 -0400 Received: from mx03.forces.gc.ca ([131.137.245.203]) by ietf-mx with esmtp (Exim 4.12) id 19kjgh-0005U2-00 for nemo@ietf.org; Thu, 07 Aug 2003 08:16:11 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 96EB9206609 for ; Thu, 7 Aug 2003 08:14:40 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19kjKl-0004DN-7X for ietf-announce-list@asgard.ietf.org; Thu, 07 Aug 2003 07:53:31 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19kjK5-0004CA-8l for all-ietf@asgard.ietf.org; Thu, 07 Aug 2003 07:52:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08802; Thu, 7 Aug 2003 07:52:44 -0400 (EDT) Message-Id: <200308071152.HAA08802@ietf.org> To: IETF-Announce: ; Cc: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Thu, 07 Aug 2003 07:52:44 -0400 Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+260193_89149976412544_2691795815" Subject: [nemo] I-D ACTION:draft-perera-nemo-extended-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --MIMEStream=_0+260193_89149976412544_2691795815 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extended Network Mobility Support Author(s) : E. Perera et al. Filename : draft-perera-nemo-extended-00.txt Pages : 15 Date : 2003-7-29 This draft proposes a solution for extended network mobility support, that is a mechanism to enable optimal routing between mobile network nodes and its correspondent nodes. The proposed scheme not only provides optimal routing for the mobility aware nodes but also maintains the benefits of mobility transparency. Our solution achieves route optimization by expecting the Mobile Router to take the role of an Access Router thereby reducing the number of external signaling messages a node behind the Mobile Router needs to perform. In order to further reduce the number of signaling messages beyond the scope of the mobile network we further propose the Mobile Router to play the role of an Home Agent for NEMO-enabled nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perera-nemo-extended-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-perera-nemo-extended-00.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-perera-nemo-extended-00.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. --MIMEStream=_0+260193_89149976412544_2691795815 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+279460_7657361911498_76683006714" --MIMEStream=_1+279460_7657361911498_76683006714 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-7081157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-perera-nemo-extended-00.txt --MIMEStream=_1+279460_7657361911498_76683006714 Content-Type: Message/External-body; name="draft-perera-nemo-extended-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-7081157.I-D@ietf.org> --MIMEStream=_1+279460_7657361911498_76683006714-- --MIMEStream=_0+260193_89149976412544_2691795815-- From exim@www1.ietf.org Thu Aug 7 08:17:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09719 for ; Thu, 7 Aug 2003 08:17:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjhW-0002NZ-R5 for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 08:17:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77CH27M009139 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 08:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjhW-0002NK-N5 for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 08:17:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09698 for ; Thu, 7 Aug 2003 08:16:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kjhV-0005Uq-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 08:17:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kjhV-0005Un-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 08:17:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjhV-0002Mc-4P; Thu, 07 Aug 2003 08:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kjgi-0002MA-Sa for nemo@optimus.ietf.org; Thu, 07 Aug 2003 08:16:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09642 for ; Thu, 7 Aug 2003 08:16:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kjgh-0005U5-00 for nemo@ietf.org; Thu, 07 Aug 2003 08:16:11 -0400 Received: from mx03.forces.gc.ca ([131.137.245.203]) by ietf-mx with esmtp (Exim 4.12) id 19kjgh-0005U2-00 for nemo@ietf.org; Thu, 07 Aug 2003 08:16:11 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 96EB9206609 for ; Thu, 7 Aug 2003 08:14:40 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19kjKl-0004DN-7X for ietf-announce-list@asgard.ietf.org; Thu, 07 Aug 2003 07:53:31 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19kjK5-0004CA-8l for all-ietf@asgard.ietf.org; Thu, 07 Aug 2003 07:52:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08802; Thu, 7 Aug 2003 07:52:44 -0400 (EDT) Message-Id: <200308071152.HAA08802@ietf.org> To: IETF-Announce: ; Cc: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Thu, 07 Aug 2003 07:52:44 -0400 Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+260193_89149976412544_2691795815" Subject: [nemo] I-D ACTION:draft-perera-nemo-extended-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --MIMEStream=_0+260193_89149976412544_2691795815 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extended Network Mobility Support Author(s) : E. Perera et al. Filename : draft-perera-nemo-extended-00.txt Pages : 15 Date : 2003-7-29 This draft proposes a solution for extended network mobility support, that is a mechanism to enable optimal routing between mobile network nodes and its correspondent nodes. The proposed scheme not only provides optimal routing for the mobility aware nodes but also maintains the benefits of mobility transparency. Our solution achieves route optimization by expecting the Mobile Router to take the role of an Access Router thereby reducing the number of external signaling messages a node behind the Mobile Router needs to perform. In order to further reduce the number of signaling messages beyond the scope of the mobile network we further propose the Mobile Router to play the role of an Home Agent for NEMO-enabled nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perera-nemo-extended-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-perera-nemo-extended-00.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-perera-nemo-extended-00.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. --MIMEStream=_0+260193_89149976412544_2691795815 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+279460_7657361911498_76683006714" --MIMEStream=_1+279460_7657361911498_76683006714 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-7081157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-perera-nemo-extended-00.txt --MIMEStream=_1+279460_7657361911498_76683006714 Content-Type: Message/External-body; name="draft-perera-nemo-extended-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-7081157.I-D@ietf.org> --MIMEStream=_1+279460_7657361911498_76683006714-- --MIMEStream=_0+260193_89149976412544_2691795815-- From nemo-admin@ietf.org Thu Aug 7 11:45:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19534 for ; Thu, 7 Aug 2003 11:45:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kmwn-00034f-Ap; Thu, 07 Aug 2003 11:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kmPc-0001RQ-MZ for nemo@optimus.ietf.org; Thu, 07 Aug 2003 11:10:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18165 for ; Thu, 7 Aug 2003 11:10:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kmPa-0007QK-00 for nemo@ietf.org; Thu, 07 Aug 2003 11:10:42 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 19kmPZ-0007Q3-00 for nemo@ietf.org; Thu, 07 Aug 2003 11:10:41 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 99BEB68956 for ; Thu, 7 Aug 2003 11:10:03 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h77FA3rE010744 for ; Thu, 7 Aug 2003 11:10:03 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (gr7700006462.grc.nasa.gov [139.88.111.44]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h77F9xdp009852 for ; Thu, 7 Aug 2003 11:10:00 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030807110426.022c7c30@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 07 Aug 2003 11:09:59 -0400 To: nemo@ietf.org From: William D Ivancic Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [nemo] ID regarding interactions of IPSec encryption devices and mobile-ip (and other protocols) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , (Sorry if this is a duplicate transmission, My mail server indicated non-delivery and I did not see this appear on the list.) During my work with mobile-ipv4 mobile router code and deployment in operational networks, We have ran across a number of problems that had to be resolved. Also, during my last trip to IETF (San Francisco), there was much talk in mobile-ip, NEMO and IPSec on the need for these groups to understand each others issues and workings as securing mobile users and networks is ..... challenging (nasty). I wrote this draft in hopes of highlighting some of the issues and hopefully preventing others from banging their head against the walls trying to figure out why things don't work. Also, the NSA is currently working on a specification similar to IPSec and needs to understand some of these issues if they want to use such devices in mobile environments. Any suggestions on improving this document would be greatly appreciated. http://www.ietf.org/internet-drafts/draft-ivancic-layer3-encryptors-00.txt Abstract This document describes some issues related to performing encryption at layer-3. In particular, routing protocol problems may result if the time-to-live (TTL) field in IPv4 or the Hop Limit field in IPv6 is decremented once before encapsulation [1][2]. Also, special provisions may be necessary within the encryptor devices if broadcast messages are to transition the encryptor pairs. Maximum Transmission Unit (MTU) issues are also presented. Will Ivancic From exim@www1.ietf.org Thu Aug 7 11:45:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19549 for ; Thu, 7 Aug 2003 11:45:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kmww-00035e-87 for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 11:45:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77FjAAs011874 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 11:45:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kmww-00035R-35 for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 11:45:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19521 for ; Thu, 7 Aug 2003 11:45:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kmwv-00000Z-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 11:45:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kmwu-00000W-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 11:45:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kmwn-00034f-Ap; Thu, 07 Aug 2003 11:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kmPc-0001RQ-MZ for nemo@optimus.ietf.org; Thu, 07 Aug 2003 11:10:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18165 for ; Thu, 7 Aug 2003 11:10:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kmPa-0007QK-00 for nemo@ietf.org; Thu, 07 Aug 2003 11:10:42 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 19kmPZ-0007Q3-00 for nemo@ietf.org; Thu, 07 Aug 2003 11:10:41 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 99BEB68956 for ; Thu, 7 Aug 2003 11:10:03 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h77FA3rE010744 for ; Thu, 7 Aug 2003 11:10:03 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (gr7700006462.grc.nasa.gov [139.88.111.44]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h77F9xdp009852 for ; Thu, 7 Aug 2003 11:10:00 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030807110426.022c7c30@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 07 Aug 2003 11:09:59 -0400 To: nemo@ietf.org From: William D Ivancic Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [nemo] ID regarding interactions of IPSec encryption devices and mobile-ip (and other protocols) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , (Sorry if this is a duplicate transmission, My mail server indicated non-delivery and I did not see this appear on the list.) During my work with mobile-ipv4 mobile router code and deployment in operational networks, We have ran across a number of problems that had to be resolved. Also, during my last trip to IETF (San Francisco), there was much talk in mobile-ip, NEMO and IPSec on the need for these groups to understand each others issues and workings as securing mobile users and networks is ..... challenging (nasty). I wrote this draft in hopes of highlighting some of the issues and hopefully preventing others from banging their head against the walls trying to figure out why things don't work. Also, the NSA is currently working on a specification similar to IPSec and needs to understand some of these issues if they want to use such devices in mobile environments. Any suggestions on improving this document would be greatly appreciated. http://www.ietf.org/internet-drafts/draft-ivancic-layer3-encryptors-00.txt Abstract This document describes some issues related to performing encryption at layer-3. In particular, routing protocol problems may result if the time-to-live (TTL) field in IPv4 or the Hop Limit field in IPv6 is decremented once before encapsulation [1][2]. Also, special provisions may be necessary within the encryptor devices if broadcast messages are to transition the encryptor pairs. Maximum Transmission Unit (MTU) issues are also presented. Will Ivancic From nemo-admin@ietf.org Thu Aug 7 13:23:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22857 for ; Thu, 7 Aug 2003 13:23:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koTd-00006T-U9; Thu, 07 Aug 2003 13:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koTE-00005z-2n for nemo@optimus.ietf.org; Thu, 07 Aug 2003 13:22:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22822 for ; Thu, 7 Aug 2003 13:22:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19koT9-0000rO-00 for nemo@ietf.org; Thu, 07 Aug 2003 13:22:31 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19koT7-0000rD-00 for nemo@ietf.org; Thu, 07 Aug 2003 13:22:30 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h77HLma32633; Thu, 7 Aug 2003 10:21:48 -0700 X-mProtect: <200308071721> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTYM5iI; Thu, 07 Aug 2003 10:21:46 PDT Message-ID: <3F328AAA.2E6E6057@iprg.nokia.com> Date: Thu, 07 Aug 2003 10:21:46 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: nemo@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Text changes to close issue 10 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Pascal Thubert (pthubert)" wrote: > > I Vijay: > > I favor these changes too. Thanks for all the work. > > There's still the original question of differentiating implicit and IGP? ??? this was issue 6. please read your own comments. the concensus was it is a matter of config at the HA and the HA would be able to distinguish between implicit mode and running an IGP over the MR-HA tunnel. moreover, it would be a good idea to keep the IGP part separate from rest of the specification. I dont think we have considered all the issues. > > Also, MUST is a bit severe for the 143, ain't it? MUST is needed. we dont want the MR assuming everything is fine, when the HA actually couldnt setup forwarding for the Mobile Network. Vijay From exim@www1.ietf.org Thu Aug 7 13:23:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22875 for ; Thu, 7 Aug 2003 13:23:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koTh-000089-B2 for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 13:23:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77HN5oq000495 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 13:23:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koTh-00007u-61 for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 13:23:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22837 for ; Thu, 7 Aug 2003 13:22:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19koTf-0000rg-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 13:23:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19koTe-0000rd-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 13:23:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koTd-00006T-U9; Thu, 07 Aug 2003 13:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koTE-00005z-2n for nemo@optimus.ietf.org; Thu, 07 Aug 2003 13:22:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22822 for ; Thu, 7 Aug 2003 13:22:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19koT9-0000rO-00 for nemo@ietf.org; Thu, 07 Aug 2003 13:22:31 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19koT7-0000rD-00 for nemo@ietf.org; Thu, 07 Aug 2003 13:22:30 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h77HLma32633; Thu, 7 Aug 2003 10:21:48 -0700 X-mProtect: <200308071721> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTYM5iI; Thu, 07 Aug 2003 10:21:46 PDT Message-ID: <3F328AAA.2E6E6057@iprg.nokia.com> Date: Thu, 07 Aug 2003 10:21:46 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: nemo@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Text changes to close issue 10 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Pascal Thubert (pthubert)" wrote: > > I Vijay: > > I favor these changes too. Thanks for all the work. > > There's still the original question of differentiating implicit and IGP? ??? this was issue 6. please read your own comments. the concensus was it is a matter of config at the HA and the HA would be able to distinguish between implicit mode and running an IGP over the MR-HA tunnel. moreover, it would be a good idea to keep the IGP part separate from rest of the specification. I dont think we have considered all the issues. > > Also, MUST is a bit severe for the 143, ain't it? MUST is needed. we dont want the MR assuming everything is fine, when the HA actually couldnt setup forwarding for the Mobile Network. Vijay From nemo-admin@ietf.org Thu Aug 7 14:39:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26215 for ; Thu, 7 Aug 2003 14:39:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpfA-0006sI-Ha; Thu, 07 Aug 2003 14:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpeK-0006pI-DQ for nemo@optimus.ietf.org; Thu, 07 Aug 2003 14:38:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26141 for ; Thu, 7 Aug 2003 14:38:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kpeH-0001dV-00 for nemo@ietf.org; Thu, 07 Aug 2003 14:38:05 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19kpeG-0001cx-00 for nemo@ietf.org; Thu, 07 Aug 2003 14:38:04 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h77IbRY31664; Thu, 7 Aug 2003 11:37:27 -0700 X-mProtect: <200308071837> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxaIi1Z; Thu, 07 Aug 2003 11:37:25 PDT Message-ID: <3F329C66.3C933B7E@iprg.nokia.com> Date: Thu, 07 Aug 2003 11:37:26 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: Muhammad Ali Malik , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F3211E5.1020807@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > however, LFN > is said to not have Mobile IPv6 capabilities and thus can't support the > CN side, so communication will necessarily go through HA of VMN. MIPv6 requirements are split into CN, HA, and MN requirements. I understood LFN to mean that there is no MIPv6 MN capability. I dont it means there is no MIPv6 CN functionality. for the terminology document > Local Fixed Node (LFN) > > A fixed node (FN), either a host or a router, that belongs to the > mobile network and which doesn't move topologically with respect > to the MR. > > Local Mobile Node (LMN) > > A mobile node (MN), either a host or a router who can move > topologically with respect to the MR and whose home link belongs > to the mobile network. a LMN implements MIPv6 MN functionality. then it is obvious from the above that LFN does not just implement MIPv6 MN functionality. LFN is like any fixed IPv6 host. so it could still support MIPv6 CN functionality correct me if I am wrong. Vijay From exim@www1.ietf.org Thu Aug 7 14:39:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26245 for ; Thu, 7 Aug 2003 14:39:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpfF-0006xT-TI for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 14:39:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77Id5rC026741 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 14:39:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpfF-0006xE-Nn for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 14:39:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26196 for ; Thu, 7 Aug 2003 14:38:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kpfD-0001eh-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 14:39:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kpfC-0001ed-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 14:39:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpfA-0006sI-Ha; Thu, 07 Aug 2003 14:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpeK-0006pI-DQ for nemo@optimus.ietf.org; Thu, 07 Aug 2003 14:38:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26141 for ; Thu, 7 Aug 2003 14:38:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kpeH-0001dV-00 for nemo@ietf.org; Thu, 07 Aug 2003 14:38:05 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19kpeG-0001cx-00 for nemo@ietf.org; Thu, 07 Aug 2003 14:38:04 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h77IbRY31664; Thu, 7 Aug 2003 11:37:27 -0700 X-mProtect: <200308071837> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxaIi1Z; Thu, 07 Aug 2003 11:37:25 PDT Message-ID: <3F329C66.3C933B7E@iprg.nokia.com> Date: Thu, 07 Aug 2003 11:37:26 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: Muhammad Ali Malik , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F3211E5.1020807@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > however, LFN > is said to not have Mobile IPv6 capabilities and thus can't support the > CN side, so communication will necessarily go through HA of VMN. MIPv6 requirements are split into CN, HA, and MN requirements. I understood LFN to mean that there is no MIPv6 MN capability. I dont it means there is no MIPv6 CN functionality. for the terminology document > Local Fixed Node (LFN) > > A fixed node (FN), either a host or a router, that belongs to the > mobile network and which doesn't move topologically with respect > to the MR. > > Local Mobile Node (LMN) > > A mobile node (MN), either a host or a router who can move > topologically with respect to the MR and whose home link belongs > to the mobile network. a LMN implements MIPv6 MN functionality. then it is obvious from the above that LFN does not just implement MIPv6 MN functionality. LFN is like any fixed IPv6 host. so it could still support MIPv6 CN functionality correct me if I am wrong. Vijay From nemo-admin@ietf.org Thu Aug 7 14:42:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26419 for ; Thu, 7 Aug 2003 14:42:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpi6-0007GZ-PY; Thu, 07 Aug 2003 14:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpi4-0007Ff-1q for nemo@optimus.ietf.org; Thu, 07 Aug 2003 14:42:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26348 for ; Thu, 7 Aug 2003 14:41:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kpi1-0001gA-00 for nemo@ietf.org; Thu, 07 Aug 2003 14:41:57 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19kpi0-0001fp-00 for nemo@ietf.org; Thu, 07 Aug 2003 14:41:56 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h77IeWj05086; Thu, 7 Aug 2003 11:40:32 -0700 X-mProtect: <200308071840> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7q2FtW; Thu, 07 Aug 2003 11:40:30 PDT Message-ID: <3F329D1E.29545562@iprg.nokia.com> Date: Thu, 07 Aug 2003 11:40:30 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: Thierry Ernst , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > But I'm not sure all implementations work that way. Mine does (since MR extends MN). We should have mentioned SAS in MIP (as I said at the last Nemo WG :) ... check out http://www.ietf.org/internet-drafts/draft-chakrabarti-ipv6-addrselect-api-01.txt Vijay > > Pascal > > > -----Original Message----- > > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > > Sent: jeudi 7 ao{t 2003 08:37 > > To: nemo@ietf.org > > Subject: Re: [nemo] crossover tunnel.... > > > > > > > When a visting mobile node (VMN) needs to communicate with local fixed > > > node (LFN) of mobile network, can they communicate directly or the > > > communication need to pass via home agent of VMN. > > > > Good question. And the answer is "(may be) no", in NEMO Basic > > Support. If VMN performs MIPv6 Route Optimization, direct communication > > may be possible once HoTi/CoTi is performed (so if for some reasons the > > MR is disconnected, it won't work). Such optimization should be taken of > > by extended support, once we come to work on it (if we do). > > > > Hope this helps. > > Thierry From exim@www1.ietf.org Thu Aug 7 14:42:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26437 for ; Thu, 7 Aug 2003 14:42:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpi9-0007JC-CJ for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 14:42:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77Ig5Kd028088 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 14:42:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpi9-0007Ix-6P for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 14:42:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26371 for ; Thu, 7 Aug 2003 14:41:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kpi6-0001gj-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 14:42:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kpi5-0001gg-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 14:42:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpi6-0007GZ-PY; Thu, 07 Aug 2003 14:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpi4-0007Ff-1q for nemo@optimus.ietf.org; Thu, 07 Aug 2003 14:42:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26348 for ; Thu, 7 Aug 2003 14:41:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kpi1-0001gA-00 for nemo@ietf.org; Thu, 07 Aug 2003 14:41:57 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19kpi0-0001fp-00 for nemo@ietf.org; Thu, 07 Aug 2003 14:41:56 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h77IeWj05086; Thu, 7 Aug 2003 11:40:32 -0700 X-mProtect: <200308071840> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7q2FtW; Thu, 07 Aug 2003 11:40:30 PDT Message-ID: <3F329D1E.29545562@iprg.nokia.com> Date: Thu, 07 Aug 2003 11:40:30 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: Thierry Ernst , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > But I'm not sure all implementations work that way. Mine does (since MR extends MN). We should have mentioned SAS in MIP (as I said at the last Nemo WG :) ... check out http://www.ietf.org/internet-drafts/draft-chakrabarti-ipv6-addrselect-api-01.txt Vijay > > Pascal > > > -----Original Message----- > > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > > Sent: jeudi 7 ao{t 2003 08:37 > > To: nemo@ietf.org > > Subject: Re: [nemo] crossover tunnel.... > > > > > > > When a visting mobile node (VMN) needs to communicate with local fixed > > > node (LFN) of mobile network, can they communicate directly or the > > > communication need to pass via home agent of VMN. > > > > Good question. And the answer is "(may be) no", in NEMO Basic > > Support. If VMN performs MIPv6 Route Optimization, direct communication > > may be possible once HoTi/CoTi is performed (so if for some reasons the > > MR is disconnected, it won't work). Such optimization should be taken of > > by extended support, once we come to work on it (if we do). > > > > Hope this helps. > > Thierry From nemo-admin@ietf.org Thu Aug 7 14:53:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26791 for ; Thu, 7 Aug 2003 14:53:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpsj-0007t4-Cy; Thu, 07 Aug 2003 14:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpsK-0007rW-I6 for nemo@optimus.ietf.org; Thu, 07 Aug 2003 14:52:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26733 for ; Thu, 7 Aug 2003 14:52:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kpsH-0001l3-00 for nemo@ietf.org; Thu, 07 Aug 2003 14:52:33 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19kpsG-0001kg-00 for nemo@ietf.org; Thu, 07 Aug 2003 14:52:32 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h77Ipjp18563; Thu, 7 Aug 2003 11:51:45 -0700 X-mProtect: <200308071851> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdc0Wp2O; Thu, 07 Aug 2003 11:51:43 PDT Message-ID: <3F329FBF.EE0F3B1C@iprg.nokia.com> Date: Thu, 07 Aug 2003 11:51:43 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: Jongkeun Na , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Pascal Thubert (pthubert)" wrote: > Now for an MN talking to an FN on the same network (FN's address has same prefix as MN's CareOf), they both have a connected route to the prefix; so for the MN, the next hop is not over the tunnel but over the roaming interface, and the CareOf is the natural global address there, thus it's selected as source. > > This is even more crucial for a Mobile Router since it also has connected routes to the Mobile Network Prefix, and it's much better for a MR to use its MNP based address to talk to a device on the mobile network, isn't it? > > This all works fine even if the HA is not reachable; but if the MN moves, the connections will be broken. Trade Off. > > Should we make an issue of this? I think so. > Discuss a little bit SAS in the basic Nemo draft? Personally I'd go for it. I think we should write up a short separate specification on how a VMN is supposed to behave in a Mobile Network. here is an outline. 1. VMN attaches to Mobile Network and acquires a CoA from MNP. 2. if it wants to start a session with an LFN, and if the session is a short lived one, uses CoA as source address. 3. if the session is a long lived one, uses MIPv6 Route Optimization 4. performs Return Routability with LFN 5. if LFN does not support Route Optimization, it sends ICMP error message (from MIPv6 spec). 6. VMN reverse tunnels through its Home Agent 7. if MR is not connected to a network, both step 5 and 6 will fail. then VMN defaults to using CoA. if the VMN moves in the middle of the session, the session just breaks. hard luck. since the MR is disconnected, LFN cant be reached anyway. comments? Vijay From exim@www1.ietf.org Thu Aug 7 14:53:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26806 for ; Thu, 7 Aug 2003 14:53:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpsm-0007wz-Ne for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 14:53:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77Ir4G9030557 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 14:53:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpsm-0007wm-JW for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 14:53:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26756 for ; Thu, 7 Aug 2003 14:52:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kpsj-0001lg-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 14:53:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kpsj-0001ld-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 14:53:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpsj-0007t4-Cy; Thu, 07 Aug 2003 14:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kpsK-0007rW-I6 for nemo@optimus.ietf.org; Thu, 07 Aug 2003 14:52:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26733 for ; Thu, 7 Aug 2003 14:52:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kpsH-0001l3-00 for nemo@ietf.org; Thu, 07 Aug 2003 14:52:33 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19kpsG-0001kg-00 for nemo@ietf.org; Thu, 07 Aug 2003 14:52:32 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h77Ipjp18563; Thu, 7 Aug 2003 11:51:45 -0700 X-mProtect: <200308071851> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdc0Wp2O; Thu, 07 Aug 2003 11:51:43 PDT Message-ID: <3F329FBF.EE0F3B1C@iprg.nokia.com> Date: Thu, 07 Aug 2003 11:51:43 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: Jongkeun Na , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Pascal Thubert (pthubert)" wrote: > Now for an MN talking to an FN on the same network (FN's address has same prefix as MN's CareOf), they both have a connected route to the prefix; so for the MN, the next hop is not over the tunnel but over the roaming interface, and the CareOf is the natural global address there, thus it's selected as source. > > This is even more crucial for a Mobile Router since it also has connected routes to the Mobile Network Prefix, and it's much better for a MR to use its MNP based address to talk to a device on the mobile network, isn't it? > > This all works fine even if the HA is not reachable; but if the MN moves, the connections will be broken. Trade Off. > > Should we make an issue of this? I think so. > Discuss a little bit SAS in the basic Nemo draft? Personally I'd go for it. I think we should write up a short separate specification on how a VMN is supposed to behave in a Mobile Network. here is an outline. 1. VMN attaches to Mobile Network and acquires a CoA from MNP. 2. if it wants to start a session with an LFN, and if the session is a short lived one, uses CoA as source address. 3. if the session is a long lived one, uses MIPv6 Route Optimization 4. performs Return Routability with LFN 5. if LFN does not support Route Optimization, it sends ICMP error message (from MIPv6 spec). 6. VMN reverse tunnels through its Home Agent 7. if MR is not connected to a network, both step 5 and 6 will fail. then VMN defaults to using CoA. if the VMN moves in the middle of the session, the session just breaks. hard luck. since the MR is disconnected, LFN cant be reached anyway. comments? Vijay From nemo-admin@ietf.org Thu Aug 7 15:03:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27291 for ; Thu, 7 Aug 2003 15:03:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kq2O-0008Qf-Lq; Thu, 07 Aug 2003 15:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kq2K-0008QQ-J5 for nemo@optimus.ietf.org; Thu, 07 Aug 2003 15:02:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27271 for ; Thu, 7 Aug 2003 15:02:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kq2H-0001tZ-00 for nemo@ietf.org; Thu, 07 Aug 2003 15:02:53 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19kq2G-0001tW-00 for nemo@ietf.org; Thu, 07 Aug 2003 15:02:52 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h77J26v30187; Thu, 7 Aug 2003 12:02:06 -0700 X-mProtect: <200308071902> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7Pe2wL; Thu, 07 Aug 2003 12:02:04 PDT Message-ID: <3F32A22C.A1DCF36F@iprg.nokia.com> Date: Thu, 07 Aug 2003 12:02:04 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , Jongkeun Na , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F329FBF.EE0F3B1C@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I think we should write up a short separate specification on > how a VMN is supposed to behave in a Mobile Network. here is > an outline. > > 1. VMN attaches to Mobile Network and acquires a CoA from MNP. > 2. if it wants to start a session with an LFN, and if the session > is a short lived one, uses CoA as source address. > 3. if the session is a long lived one, uses MIPv6 Route Optimization > 4. performs Return Routability with LFN > 5. if LFN does not support Route Optimization, it sends ICMP error > message (from MIPv6 spec). > 6. VMN reverse tunnels through its Home Agent > 7. if MR is not connected to a network, both step 5 and 6 will fail. > then VMN defaults to using CoA. if the VMN moves in the middle > of the session, the session just breaks. hard luck. since the > MR is disconnected, LFN cant be reached anyway. its very easy for the VMN to figure out the MR is not currently attached to any network. the MR would be generating ICMP error messages when VMN tries to do 5 or 6. then VMN defaults to using CoA for the session with LFN. Vijay From exim@www1.ietf.org Thu Aug 7 15:03:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27306 for ; Thu, 7 Aug 2003 15:03:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kq2R-0008Rc-22 for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 15:03:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77J33TH032454 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 15:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kq2Q-0008RN-Rm for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 15:03:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27275 for ; Thu, 7 Aug 2003 15:02:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kq2N-0001tf-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 15:03:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kq2N-0001tc-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 15:02:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kq2O-0008Qf-Lq; Thu, 07 Aug 2003 15:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kq2K-0008QQ-J5 for nemo@optimus.ietf.org; Thu, 07 Aug 2003 15:02:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27271 for ; Thu, 7 Aug 2003 15:02:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kq2H-0001tZ-00 for nemo@ietf.org; Thu, 07 Aug 2003 15:02:53 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19kq2G-0001tW-00 for nemo@ietf.org; Thu, 07 Aug 2003 15:02:52 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h77J26v30187; Thu, 7 Aug 2003 12:02:06 -0700 X-mProtect: <200308071902> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7Pe2wL; Thu, 07 Aug 2003 12:02:04 PDT Message-ID: <3F32A22C.A1DCF36F@iprg.nokia.com> Date: Thu, 07 Aug 2003 12:02:04 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , Jongkeun Na , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F329FBF.EE0F3B1C@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I think we should write up a short separate specification on > how a VMN is supposed to behave in a Mobile Network. here is > an outline. > > 1. VMN attaches to Mobile Network and acquires a CoA from MNP. > 2. if it wants to start a session with an LFN, and if the session > is a short lived one, uses CoA as source address. > 3. if the session is a long lived one, uses MIPv6 Route Optimization > 4. performs Return Routability with LFN > 5. if LFN does not support Route Optimization, it sends ICMP error > message (from MIPv6 spec). > 6. VMN reverse tunnels through its Home Agent > 7. if MR is not connected to a network, both step 5 and 6 will fail. > then VMN defaults to using CoA. if the VMN moves in the middle > of the session, the session just breaks. hard luck. since the > MR is disconnected, LFN cant be reached anyway. its very easy for the VMN to figure out the MR is not currently attached to any network. the MR would be generating ICMP error messages when VMN tries to do 5 or 6. then VMN defaults to using CoA for the session with LFN. Vijay From nemo-admin@ietf.org Thu Aug 7 20:35:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10056 for ; Thu, 7 Aug 2003 20:35:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvDh-0004di-9n; Thu, 07 Aug 2003 20:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvD9-0004ay-Jq for nemo@optimus.ietf.org; Thu, 07 Aug 2003 20:34:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10017 for ; Thu, 7 Aug 2003 20:34:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kvD7-00042B-00 for nemo@ietf.org; Thu, 07 Aug 2003 20:34:25 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19kvD6-00041x-00 for nemo@ietf.org; Thu, 07 Aug 2003 20:34:24 -0400 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (pdd8a18.tkyoac00.ap.so-net.ne.jp [218.221.138.24]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h780Xfhs011502; Fri, 8 Aug 2003 09:33:41 +0900 Date: Fri, 08 Aug 2003 09:33:43 +0900 Message-ID: From: Ryuji Wakikawa To: vijayd@iprg.nokia.com Cc: pthubert@cisco.com, jkna@popeye.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... In-Reply-To: <3F329FBF.EE0F3B1C@iprg.nokia.com> References: <3F329FBF.EE0F3B1C@iprg.nokia.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Vijay At Thu, 07 Aug 2003 11:51:43 -0700, Vijay Devarapalli wrote: > > "Pascal Thubert (pthubert)" wrote: > > > Now for an MN talking to an FN on the same network (FN's address has same prefix as MN's CareOf), they both have a connected route to the prefix; so for the MN, the next hop is not over the tunnel but over the roaming interface, and the CareOf is the natural global address there, thus it's selected as source. > > > > This is even more crucial for a Mobile Router since it also has connected routes to the Mobile Network Prefix, and it's much better for a MR to use its MNP based address to talk to a device on the mobile network, isn't it? > > > > This all works fine even if the HA is not reachable; but if the MN moves, the connections will be broken. Trade Off. > > > > Should we make an issue of this? > > I think so. > > > Discuss a little bit SAS in the basic Nemo draft? Personally I'd go for it. > > I think we should write up a short separate specification on > how a VMN is supposed to behave in a Mobile Network. here is > an outline. > > 1. VMN attaches to Mobile Network and acquires a CoA from MNP. > 2. if it wants to start a session with an LFN, and if the session > is a short lived one, uses CoA as source address. > 3. if the session is a long lived one, uses MIPv6 Route Optimization > 4. performs Return Routability with LFN > 5. if LFN does not support Route Optimization, it sends ICMP error > message (from MIPv6 spec). > 6. VMN reverse tunnels through its Home Agent > 7. if MR is not connected to a network, both step 5 and 6 will fail. > then VMN defaults to using CoA. if the VMN moves in the middle > of the session, the session just breaks. hard luck. since the > MR is disconnected, LFN cant be reached anyway. > > comments? How does VMN can determine whether a destination is LFN or not. If LFN is subset of VMN, LFN can suddenly become VMN and vice versa. Actually if LMN is attached to the home (i.e. mobile network), it can be treated as LFN. Unless there is some trick to determine the type of destination node, there is no advantage to use LFN term in this texts. can't we use MNN term instead of LFN? Even if I replaced LFN to MNN, your texts works fine. regards, ryuji From exim@www1.ietf.org Thu Aug 7 20:35:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10071 for ; Thu, 7 Aug 2003 20:35:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvDn-0004fk-JP for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 20:35:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h780Z7s3017959 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 20:35:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvDn-0004fa-Ew for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 20:35:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10028 for ; Thu, 7 Aug 2003 20:35:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kvDl-00042N-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 20:35:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kvDk-00042K-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 20:35:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvDh-0004di-9n; Thu, 07 Aug 2003 20:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvD9-0004ay-Jq for nemo@optimus.ietf.org; Thu, 07 Aug 2003 20:34:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10017 for ; Thu, 7 Aug 2003 20:34:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kvD7-00042B-00 for nemo@ietf.org; Thu, 07 Aug 2003 20:34:25 -0400 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 19kvD6-00041x-00 for nemo@ietf.org; Thu, 07 Aug 2003 20:34:24 -0400 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (pdd8a18.tkyoac00.ap.so-net.ne.jp [218.221.138.24]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.9/8.12.0) with ESMTP id h780Xfhs011502; Fri, 8 Aug 2003 09:33:41 +0900 Date: Fri, 08 Aug 2003 09:33:43 +0900 Message-ID: From: Ryuji Wakikawa To: vijayd@iprg.nokia.com Cc: pthubert@cisco.com, jkna@popeye.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... In-Reply-To: <3F329FBF.EE0F3B1C@iprg.nokia.com> References: <3F329FBF.EE0F3B1C@iprg.nokia.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Vijay At Thu, 07 Aug 2003 11:51:43 -0700, Vijay Devarapalli wrote: > > "Pascal Thubert (pthubert)" wrote: > > > Now for an MN talking to an FN on the same network (FN's address has same prefix as MN's CareOf), they both have a connected route to the prefix; so for the MN, the next hop is not over the tunnel but over the roaming interface, and the CareOf is the natural global address there, thus it's selected as source. > > > > This is even more crucial for a Mobile Router since it also has connected routes to the Mobile Network Prefix, and it's much better for a MR to use its MNP based address to talk to a device on the mobile network, isn't it? > > > > This all works fine even if the HA is not reachable; but if the MN moves, the connections will be broken. Trade Off. > > > > Should we make an issue of this? > > I think so. > > > Discuss a little bit SAS in the basic Nemo draft? Personally I'd go for it. > > I think we should write up a short separate specification on > how a VMN is supposed to behave in a Mobile Network. here is > an outline. > > 1. VMN attaches to Mobile Network and acquires a CoA from MNP. > 2. if it wants to start a session with an LFN, and if the session > is a short lived one, uses CoA as source address. > 3. if the session is a long lived one, uses MIPv6 Route Optimization > 4. performs Return Routability with LFN > 5. if LFN does not support Route Optimization, it sends ICMP error > message (from MIPv6 spec). > 6. VMN reverse tunnels through its Home Agent > 7. if MR is not connected to a network, both step 5 and 6 will fail. > then VMN defaults to using CoA. if the VMN moves in the middle > of the session, the session just breaks. hard luck. since the > MR is disconnected, LFN cant be reached anyway. > > comments? How does VMN can determine whether a destination is LFN or not. If LFN is subset of VMN, LFN can suddenly become VMN and vice versa. Actually if LMN is attached to the home (i.e. mobile network), it can be treated as LFN. Unless there is some trick to determine the type of destination node, there is no advantage to use LFN term in this texts. can't we use MNN term instead of LFN? Even if I replaced LFN to MNN, your texts works fine. regards, ryuji From nemo-admin@ietf.org Thu Aug 7 20:44:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10231 for ; Thu, 7 Aug 2003 20:44:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvMO-00056w-N1; Thu, 07 Aug 2003 20:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvLg-00055M-6k for nemo@optimus.ietf.org; Thu, 07 Aug 2003 20:43:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10203 for ; Thu, 7 Aug 2003 20:43:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kvLd-00045L-00 for nemo@ietf.org; Thu, 07 Aug 2003 20:43:14 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19kvLd-00045C-00 for nemo@ietf.org; Thu, 07 Aug 2003 20:43:13 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h780gRT23312; Thu, 7 Aug 2003 17:42:27 -0700 X-mProtect: <200308080042> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVhQIOK; Thu, 07 Aug 2003 17:42:25 PDT Message-ID: <3F32F1F1.AF511FAE@iprg.nokia.com> Date: Thu, 07 Aug 2003 17:42:25 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Ryuji Wakikawa CC: pthubert@cisco.com, jkna@popeye.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F329FBF.EE0F3B1C@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: > > > > > I think we should write up a short separate specification on > > how a VMN is supposed to behave in a Mobile Network. here is > > an outline. > > > > 1. VMN attaches to Mobile Network and acquires a CoA from MNP. > > 2. if it wants to start a session with an LFN, and if the session > > is a short lived one, uses CoA as source address. > > 3. if the session is a long lived one, uses MIPv6 Route Optimization > > 4. performs Return Routability with LFN > > 5. if LFN does not support Route Optimization, it sends ICMP error > > message (from MIPv6 spec). > > 6. VMN reverse tunnels through its Home Agent > > 7. if MR is not connected to a network, both step 5 and 6 will fail. > > then VMN defaults to using CoA. if the VMN moves in the middle > > of the session, the session just breaks. hard luck. since the > > MR is disconnected, LFN cant be reached anyway. > > > > comments? > > How does VMN can determine whether a destination is LFN or not. > If LFN is subset of VMN, LFN can suddenly become VMN and vice versa. > Actually if LMN is attached to the home (i.e. mobile network), it can > be treated as LFN. > > Unless there is some trick to determine the type of destination node, > there is no advantage to use LFN term in this texts. > > can't we use MNN term instead of LFN? > Even if I replaced LFN to MNN, your texts works fine. you are right. just use MNN (Mobile Network Node). the VMN (Visiting Mobile Node) cannot figure out if a host in the mobile network is a fixed node or a mobile node. Vijay From exim@www1.ietf.org Thu Aug 7 20:44:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10249 for ; Thu, 7 Aug 2003 20:44:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvMQ-00057t-5q for nemo-archive@odin.ietf.org; Thu, 07 Aug 2003 20:44:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h780i2aG019699 for nemo-archive@odin.ietf.org; Thu, 7 Aug 2003 20:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvMP-00057e-WB for nemo-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 20:44:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10218 for ; Thu, 7 Aug 2003 20:43:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kvMN-00045U-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 20:43:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kvMN-00045R-00 for nemo-web-archive@ietf.org; Thu, 07 Aug 2003 20:43:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvMO-00056w-N1; Thu, 07 Aug 2003 20:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kvLg-00055M-6k for nemo@optimus.ietf.org; Thu, 07 Aug 2003 20:43:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10203 for ; Thu, 7 Aug 2003 20:43:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kvLd-00045L-00 for nemo@ietf.org; Thu, 07 Aug 2003 20:43:14 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19kvLd-00045C-00 for nemo@ietf.org; Thu, 07 Aug 2003 20:43:13 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h780gRT23312; Thu, 7 Aug 2003 17:42:27 -0700 X-mProtect: <200308080042> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVhQIOK; Thu, 07 Aug 2003 17:42:25 PDT Message-ID: <3F32F1F1.AF511FAE@iprg.nokia.com> Date: Thu, 07 Aug 2003 17:42:25 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Ryuji Wakikawa CC: pthubert@cisco.com, jkna@popeye.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F329FBF.EE0F3B1C@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: > > > > > I think we should write up a short separate specification on > > how a VMN is supposed to behave in a Mobile Network. here is > > an outline. > > > > 1. VMN attaches to Mobile Network and acquires a CoA from MNP. > > 2. if it wants to start a session with an LFN, and if the session > > is a short lived one, uses CoA as source address. > > 3. if the session is a long lived one, uses MIPv6 Route Optimization > > 4. performs Return Routability with LFN > > 5. if LFN does not support Route Optimization, it sends ICMP error > > message (from MIPv6 spec). > > 6. VMN reverse tunnels through its Home Agent > > 7. if MR is not connected to a network, both step 5 and 6 will fail. > > then VMN defaults to using CoA. if the VMN moves in the middle > > of the session, the session just breaks. hard luck. since the > > MR is disconnected, LFN cant be reached anyway. > > > > comments? > > How does VMN can determine whether a destination is LFN or not. > If LFN is subset of VMN, LFN can suddenly become VMN and vice versa. > Actually if LMN is attached to the home (i.e. mobile network), it can > be treated as LFN. > > Unless there is some trick to determine the type of destination node, > there is no advantage to use LFN term in this texts. > > can't we use MNN term instead of LFN? > Even if I replaced LFN to MNN, your texts works fine. you are right. just use MNN (Mobile Network Node). the VMN (Visiting Mobile Node) cannot figure out if a host in the mobile network is a fixed node or a mobile node. Vijay From nemo-admin@ietf.org Fri Aug 8 03:41:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02339 for ; Fri, 8 Aug 2003 03:41:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l1ry-0005vb-8x; Fri, 08 Aug 2003 03:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l1rd-0005v1-Ad for nemo@optimus.ietf.org; Fri, 08 Aug 2003 03:40:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02323 for ; Fri, 8 Aug 2003 03:40:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l1ra-0006Sz-00 for nemo@ietf.org; Fri, 08 Aug 2003 03:40:38 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19l1ra-0006Sl-00 for nemo@ietf.org; Fri, 08 Aug 2003 03:40:38 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Aug 2003 09:39:42 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h787bpmR025009; Fri, 8 Aug 2003 09:37:54 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Aug 2003 09:39:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] crossover tunnel.... Date: Fri, 8 Aug 2003 08:39:43 +0100 Message-ID: Thread-Topic: [nemo] crossover tunnel.... Thread-Index: AcNdRgc+S69+tS2wRvaE6tk08qRZqAAOf/Nw From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Ryuji Wakikawa" Cc: , X-OriginalArrivalTime: 08 Aug 2003 07:39:44.0450 (UTC) FILETIME=[3C3F8A20:01C35D80] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable So just say a node :) Pascal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: vendredi 8 ao=FBt 2003 02:42 > To: Ryuji Wakikawa > Cc: Pascal Thubert (pthubert); jkna@popeye.snu.ac.kr; nemo@ietf.org > Subject: Re: [nemo] crossover tunnel.... >=20 > Ryuji Wakikawa wrote: > > > > > > > > I think we should write up a short separate specification on > > > how a VMN is supposed to behave in a Mobile Network. here is > > > an outline. > > > > > > 1. VMN attaches to Mobile Network and acquires a CoA from MNP. > > > 2. if it wants to start a session with an LFN, and if the session > > > is a short lived one, uses CoA as source address. > > > 3. if the session is a long lived one, uses MIPv6 Route = Optimization > > > 4. performs Return Routability with LFN > > > 5. if LFN does not support Route Optimization, it sends ICMP error > > > message (from MIPv6 spec). > > > 6. VMN reverse tunnels through its Home Agent > > > 7. if MR is not connected to a network, both step 5 and 6 will = fail. > > > then VMN defaults to using CoA. if the VMN moves in the middle > > > of the session, the session just breaks. hard luck. since the > > > MR is disconnected, LFN cant be reached anyway. > > > > > > comments? > > > > How does VMN can determine whether a destination is LFN or not. > > If LFN is subset of VMN, LFN can suddenly become VMN and vice versa. > > Actually if LMN is attached to the home (i.e. mobile network), it = can > > be treated as LFN. > > > > Unless there is some trick to determine the type of destination = node, > > there is no advantage to use LFN term in this texts. > > > > can't we use MNN term instead of LFN? > > Even if I replaced LFN to MNN, your texts works fine. >=20 > you are right. just use MNN (Mobile Network Node). the > VMN (Visiting Mobile Node) cannot figure out if a host > in the mobile network is a fixed node or a mobile node. >=20 > Vijay From exim@www1.ietf.org Fri Aug 8 03:41:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02354 for ; Fri, 8 Aug 2003 03:41:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l1s4-0005wU-6u for nemo-archive@odin.ietf.org; Fri, 08 Aug 2003 03:41:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h787f8YR022843 for nemo-archive@odin.ietf.org; Fri, 8 Aug 2003 03:41:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l1s3-0005wM-Pb for nemo-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 03:41:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02331 for ; Fri, 8 Aug 2003 03:41:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l1s1-0006T5-00 for nemo-web-archive@ietf.org; Fri, 08 Aug 2003 03:41:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19l1s0-0006T2-00 for nemo-web-archive@ietf.org; Fri, 08 Aug 2003 03:41:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l1ry-0005vb-8x; Fri, 08 Aug 2003 03:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l1rd-0005v1-Ad for nemo@optimus.ietf.org; Fri, 08 Aug 2003 03:40:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02323 for ; Fri, 8 Aug 2003 03:40:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l1ra-0006Sz-00 for nemo@ietf.org; Fri, 08 Aug 2003 03:40:38 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19l1ra-0006Sl-00 for nemo@ietf.org; Fri, 08 Aug 2003 03:40:38 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Aug 2003 09:39:42 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h787bpmR025009; Fri, 8 Aug 2003 09:37:54 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Aug 2003 09:39:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] crossover tunnel.... Date: Fri, 8 Aug 2003 08:39:43 +0100 Message-ID: Thread-Topic: [nemo] crossover tunnel.... Thread-Index: AcNdRgc+S69+tS2wRvaE6tk08qRZqAAOf/Nw From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Ryuji Wakikawa" Cc: , X-OriginalArrivalTime: 08 Aug 2003 07:39:44.0450 (UTC) FILETIME=[3C3F8A20:01C35D80] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable So just say a node :) Pascal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: vendredi 8 ao=FBt 2003 02:42 > To: Ryuji Wakikawa > Cc: Pascal Thubert (pthubert); jkna@popeye.snu.ac.kr; nemo@ietf.org > Subject: Re: [nemo] crossover tunnel.... >=20 > Ryuji Wakikawa wrote: > > > > > > > > I think we should write up a short separate specification on > > > how a VMN is supposed to behave in a Mobile Network. here is > > > an outline. > > > > > > 1. VMN attaches to Mobile Network and acquires a CoA from MNP. > > > 2. if it wants to start a session with an LFN, and if the session > > > is a short lived one, uses CoA as source address. > > > 3. if the session is a long lived one, uses MIPv6 Route = Optimization > > > 4. performs Return Routability with LFN > > > 5. if LFN does not support Route Optimization, it sends ICMP error > > > message (from MIPv6 spec). > > > 6. VMN reverse tunnels through its Home Agent > > > 7. if MR is not connected to a network, both step 5 and 6 will = fail. > > > then VMN defaults to using CoA. if the VMN moves in the middle > > > of the session, the session just breaks. hard luck. since the > > > MR is disconnected, LFN cant be reached anyway. > > > > > > comments? > > > > How does VMN can determine whether a destination is LFN or not. > > If LFN is subset of VMN, LFN can suddenly become VMN and vice versa. > > Actually if LMN is attached to the home (i.e. mobile network), it = can > > be treated as LFN. > > > > Unless there is some trick to determine the type of destination = node, > > there is no advantage to use LFN term in this texts. > > > > can't we use MNN term instead of LFN? > > Even if I replaced LFN to MNN, your texts works fine. >=20 > you are right. just use MNN (Mobile Network Node). the > VMN (Visiting Mobile Node) cannot figure out if a host > in the mobile network is a fixed node or a mobile node. >=20 > Vijay From nemo-admin@ietf.org Fri Aug 8 04:29:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03622 for ; Fri, 8 Aug 2003 04:29:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2cQ-0008Ui-9O; Fri, 08 Aug 2003 04:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2bs-0008UI-1G for nemo@optimus.ietf.org; Fri, 08 Aug 2003 04:28:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03583 for ; Fri, 8 Aug 2003 04:28:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l2bo-0006lv-00 for nemo@ietf.org; Fri, 08 Aug 2003 04:28:25 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 19l2bn-0006ls-00 for nemo@ietf.org; Fri, 08 Aug 2003 04:28:24 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h788SKL5021069; Fri, 8 Aug 2003 01:28:20 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h787SFRI023338; Fri, 8 Aug 2003 03:28:16 -0400 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id B69F92EC86; Fri, 8 Aug 2003 10:28:15 +0200 (CEST) Message-ID: <3F335F1F.1050904@motorola.com> Date: Fri, 08 Aug 2003 10:28:15 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Muhammad Ali Malik , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F3211E5.1020807@motorola.com> <3F329C66.3C933B7E@iprg.nokia.com> In-Reply-To: <3F329C66.3C933B7E@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> however, LFN is said to not have Mobile IPv6 capabilities and thus >> can't support the CN side, so communication will necessarily go >> through HA of VMN. > > > MIPv6 requirements are split into CN, HA, and MN requirements. I > understood LFN to mean that there is no MIPv6 MN capability. I dont > it means there is no MIPv6 CN functionality. Right, so there is a world where LFN supports CN. I always thought that "LFN" stands for no MIPv6 functionality whatever that is. Maybe we can suggest clarification to the terminology document and say that LFN does support CN, but does not support MN. At which point I will propose FN to stand for an IPv6 host that does not support neither MH nor CN nor HA. Alex GBU From exim@www1.ietf.org Fri Aug 8 04:29:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03637 for ; Fri, 8 Aug 2003 04:29:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2cW-00005R-9j for nemo-archive@odin.ietf.org; Fri, 08 Aug 2003 04:29:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h788T8Ht000327 for nemo-archive@odin.ietf.org; Fri, 8 Aug 2003 04:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2cV-00005C-Vl for nemo-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 04:29:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03613 for ; Fri, 8 Aug 2003 04:29:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l2cT-0006mT-00 for nemo-web-archive@ietf.org; Fri, 08 Aug 2003 04:29:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19l2cS-0006mQ-00 for nemo-web-archive@ietf.org; Fri, 08 Aug 2003 04:29:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2cQ-0008Ui-9O; Fri, 08 Aug 2003 04:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2bs-0008UI-1G for nemo@optimus.ietf.org; Fri, 08 Aug 2003 04:28:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03583 for ; Fri, 8 Aug 2003 04:28:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l2bo-0006lv-00 for nemo@ietf.org; Fri, 08 Aug 2003 04:28:25 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 19l2bn-0006ls-00 for nemo@ietf.org; Fri, 08 Aug 2003 04:28:24 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h788SKL5021069; Fri, 8 Aug 2003 01:28:20 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h787SFRI023338; Fri, 8 Aug 2003 03:28:16 -0400 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id B69F92EC86; Fri, 8 Aug 2003 10:28:15 +0200 (CEST) Message-ID: <3F335F1F.1050904@motorola.com> Date: Fri, 08 Aug 2003 10:28:15 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Muhammad Ali Malik , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F3211E5.1020807@motorola.com> <3F329C66.3C933B7E@iprg.nokia.com> In-Reply-To: <3F329C66.3C933B7E@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> however, LFN is said to not have Mobile IPv6 capabilities and thus >> can't support the CN side, so communication will necessarily go >> through HA of VMN. > > > MIPv6 requirements are split into CN, HA, and MN requirements. I > understood LFN to mean that there is no MIPv6 MN capability. I dont > it means there is no MIPv6 CN functionality. Right, so there is a world where LFN supports CN. I always thought that "LFN" stands for no MIPv6 functionality whatever that is. Maybe we can suggest clarification to the terminology document and say that LFN does support CN, but does not support MN. At which point I will propose FN to stand for an IPv6 host that does not support neither MH nor CN nor HA. Alex GBU From nemo-admin@ietf.org Fri Aug 8 04:30:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03676 for ; Fri, 8 Aug 2003 04:30:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2dO-0000CA-Mh; Fri, 08 Aug 2003 04:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2d5-0000BY-1z for nemo@optimus.ietf.org; Fri, 08 Aug 2003 04:29:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03653 for ; Fri, 8 Aug 2003 04:29:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l2d2-0006mp-00 for nemo@ietf.org; Fri, 08 Aug 2003 04:29:40 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19l2d1-0006mW-00 for nemo@ietf.org; Fri, 08 Aug 2003 04:29:39 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Aug 2003 10:28:43 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h788QuJl003325; Fri, 8 Aug 2003 10:26:56 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Aug 2003 10:29:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] crossover tunnel.... Date: Fri, 8 Aug 2003 09:29:08 +0100 Message-ID: Thread-Topic: [nemo] crossover tunnel.... Thread-Index: AcNdFQqbCyBCYJuJSNWBOhbiTRf03wAaxw8A From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: "Jongkeun Na" , X-OriginalArrivalTime: 08 Aug 2003 08:29:09.0556 (UTC) FILETIME=[2396CF40:01C35D87] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Vijay: I like your text, I'm OK to add it, and it answers the initial question. But it misses my point quite completely. I was not talking about a mobile network specifically but any mobile = node visiting a link and starting a connection with an IPv6 node on that = link. The mobile node being a host or a router. I was talking about a MR behavior for SAS when not at home. When a MR joins a new link, there's more that happens than we actually = described.=20 I suggest to insert a 5.7 chapter: SAS for mobile router In the process of Source Address Selection, the MRHA tunnel is = considered as Any other link, with the restriction that only a global address may be = selected. So when the MR is not at Home, the Home Address will be selected as = source=20 address when and only when the destination is reached via the MRHA = tunnel. =20 The MR has a set of connected routes for its attached MNPs. It may also = have some static routes and a set of routes obtained from a routing = protocol. For all these routes, SAS takes place normally and if the MRHA tunnel = is not the link to the next hop, the best scoped global address on that link = should=20 be preferred, avoiding the MIP encapsulation and the dog leg. In particular, when a MR forms a CoA from a visited prefix, it inserts = a connected route to that prefix, over the associated egress interface, = in=20 its routing table. So when the MR initiates a socket to a node on that = link, SAS will select the CareOf address as source. Now if the MR acts as the VMN in your text, the question is how does the = MR know whether the connection will be still running when the MR moves, = and if in that case using the mechanism you describe should be = preferred? Hard to know. Maybe some mobility heuristics. But I believe = this is all optimizations, or maybe a config option to override the = default operation that I just presented (note it's mostly a description = of the current standards). Pascal =20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: jeudi 7 ao=FBt 2003 20:52 > To: Pascal Thubert (pthubert) > Cc: Jongkeun Na; nemo@ietf.org > Subject: Re: [nemo] crossover tunnel.... >=20 > "Pascal Thubert (pthubert)" wrote: >=20 > > Now for an MN talking to an FN on the same network (FN's address has = same prefix as MN's > CareOf), they both have a connected route to the prefix; so for the = MN, the next hop is not > over the tunnel but over the roaming interface, and the CareOf is the = natural global address > there, thus it's selected as source. > > > > This is even more crucial for a Mobile Router since it also has = connected routes to the > Mobile Network Prefix, and it's much better for a MR to use its MNP = based address to talk to > a device on the mobile network, isn't it? > > > > This all works fine even if the HA is not reachable; but if the MN = moves, the connections > will be broken. Trade Off. > > > > Should we make an issue of this? >=20 > I think so. >=20 > > Discuss a little bit SAS in the basic Nemo draft? Personally I'd go = for it. >=20 > I think we should write up a short separate specification on > how a VMN is supposed to behave in a Mobile Network. here is > an outline. >=20 > 1. VMN attaches to Mobile Network and acquires a CoA from MNP. > 2. if it wants to start a session with an LFN, and if the session > is a short lived one, uses CoA as source address. > 3. if the session is a long lived one, uses MIPv6 Route Optimization > 4. performs Return Routability with LFN > 5. if LFN does not support Route Optimization, it sends ICMP error > message (from MIPv6 spec). > 6. VMN reverse tunnels through its Home Agent > 7. if MR is not connected to a network, both step 5 and 6 will fail. > then VMN defaults to using CoA. if the VMN moves in the middle > of the session, the session just breaks. hard luck. since the > MR is disconnected, LFN cant be reached anyway. >=20 > comments? >=20 > Vijay From exim@www1.ietf.org Fri Aug 8 04:30:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03691 for ; Fri, 8 Aug 2003 04:30:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2dQ-0000EK-9c for nemo-archive@odin.ietf.org; Fri, 08 Aug 2003 04:30:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h788U4qt000878 for nemo-archive@odin.ietf.org; Fri, 8 Aug 2003 04:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2dQ-0000Dp-2L for nemo-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 04:30:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03660 for ; Fri, 8 Aug 2003 04:29:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l2dN-0006n4-00 for nemo-web-archive@ietf.org; Fri, 08 Aug 2003 04:30:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19l2dM-0006mz-00 for nemo-web-archive@ietf.org; Fri, 08 Aug 2003 04:30:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2dO-0000CA-Mh; Fri, 08 Aug 2003 04:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2d5-0000BY-1z for nemo@optimus.ietf.org; Fri, 08 Aug 2003 04:29:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03653 for ; Fri, 8 Aug 2003 04:29:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l2d2-0006mp-00 for nemo@ietf.org; Fri, 08 Aug 2003 04:29:40 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19l2d1-0006mW-00 for nemo@ietf.org; Fri, 08 Aug 2003 04:29:39 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Aug 2003 10:28:43 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h788QuJl003325; Fri, 8 Aug 2003 10:26:56 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Aug 2003 10:29:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] crossover tunnel.... Date: Fri, 8 Aug 2003 09:29:08 +0100 Message-ID: Thread-Topic: [nemo] crossover tunnel.... Thread-Index: AcNdFQqbCyBCYJuJSNWBOhbiTRf03wAaxw8A From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: "Jongkeun Na" , X-OriginalArrivalTime: 08 Aug 2003 08:29:09.0556 (UTC) FILETIME=[2396CF40:01C35D87] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Vijay: I like your text, I'm OK to add it, and it answers the initial question. But it misses my point quite completely. I was not talking about a mobile network specifically but any mobile = node visiting a link and starting a connection with an IPv6 node on that = link. The mobile node being a host or a router. I was talking about a MR behavior for SAS when not at home. When a MR joins a new link, there's more that happens than we actually = described.=20 I suggest to insert a 5.7 chapter: SAS for mobile router In the process of Source Address Selection, the MRHA tunnel is = considered as Any other link, with the restriction that only a global address may be = selected. So when the MR is not at Home, the Home Address will be selected as = source=20 address when and only when the destination is reached via the MRHA = tunnel. =20 The MR has a set of connected routes for its attached MNPs. It may also = have some static routes and a set of routes obtained from a routing = protocol. For all these routes, SAS takes place normally and if the MRHA tunnel = is not the link to the next hop, the best scoped global address on that link = should=20 be preferred, avoiding the MIP encapsulation and the dog leg. In particular, when a MR forms a CoA from a visited prefix, it inserts = a connected route to that prefix, over the associated egress interface, = in=20 its routing table. So when the MR initiates a socket to a node on that = link, SAS will select the CareOf address as source. Now if the MR acts as the VMN in your text, the question is how does the = MR know whether the connection will be still running when the MR moves, = and if in that case using the mechanism you describe should be = preferred? Hard to know. Maybe some mobility heuristics. But I believe = this is all optimizations, or maybe a config option to override the = default operation that I just presented (note it's mostly a description = of the current standards). Pascal =20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: jeudi 7 ao=FBt 2003 20:52 > To: Pascal Thubert (pthubert) > Cc: Jongkeun Na; nemo@ietf.org > Subject: Re: [nemo] crossover tunnel.... >=20 > "Pascal Thubert (pthubert)" wrote: >=20 > > Now for an MN talking to an FN on the same network (FN's address has = same prefix as MN's > CareOf), they both have a connected route to the prefix; so for the = MN, the next hop is not > over the tunnel but over the roaming interface, and the CareOf is the = natural global address > there, thus it's selected as source. > > > > This is even more crucial for a Mobile Router since it also has = connected routes to the > Mobile Network Prefix, and it's much better for a MR to use its MNP = based address to talk to > a device on the mobile network, isn't it? > > > > This all works fine even if the HA is not reachable; but if the MN = moves, the connections > will be broken. Trade Off. > > > > Should we make an issue of this? >=20 > I think so. >=20 > > Discuss a little bit SAS in the basic Nemo draft? Personally I'd go = for it. >=20 > I think we should write up a short separate specification on > how a VMN is supposed to behave in a Mobile Network. here is > an outline. >=20 > 1. VMN attaches to Mobile Network and acquires a CoA from MNP. > 2. if it wants to start a session with an LFN, and if the session > is a short lived one, uses CoA as source address. > 3. if the session is a long lived one, uses MIPv6 Route Optimization > 4. performs Return Routability with LFN > 5. if LFN does not support Route Optimization, it sends ICMP error > message (from MIPv6 spec). > 6. VMN reverse tunnels through its Home Agent > 7. if MR is not connected to a network, both step 5 and 6 will fail. > then VMN defaults to using CoA. if the VMN moves in the middle > of the session, the session just breaks. hard luck. since the > MR is disconnected, LFN cant be reached anyway. >=20 > comments? >=20 > Vijay From nemo-admin@ietf.org Fri Aug 8 04:42:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03953 for ; Fri, 8 Aug 2003 04:42:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2p0-0000uW-Jo; Fri, 08 Aug 2003 04:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2o3-0000lr-GW for nemo@optimus.ietf.org; Fri, 08 Aug 2003 04:41:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03879 for ; Fri, 8 Aug 2003 04:40:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l2o0-0006pU-00 for nemo@ietf.org; Fri, 08 Aug 2003 04:41:00 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19l2nz-0006pR-00 for nemo@ietf.org; Fri, 08 Aug 2003 04:40:59 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Aug 2003 10:40:03 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h788cGSI005572; Fri, 8 Aug 2003 10:38:17 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Aug 2003 10:40:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Aug 2003 09:40:28 +0100 Message-ID: Thread-Topic: Text changes to close issue 10 Thread-Index: AcNdCHj0BsaHZTHjQ+KgZ2xIudifIwAfrlxg From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 08 Aug 2003 08:40:29.0748 (UTC) FILETIME=[B903DF40:01C35D88] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Text changes to close issue 10 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sorry for being unclear I agree other OGP stuff should be a side discussion. My point about that bit for issue 10 is that to answer 143, the HA must = know that the MR expects implicit. Maybe that MR will use explicit later = but does not want the HA to get its prefixes yet. Maybe the prefixes = will come from PD over the tunnel. Also this may be useful for = multihoming probes sometime.=20 So the HA can not reject blindly all BUs with no prefixes by saying = sorry, 143, I do not have a prefix for you.=20 I told you I did not want a 143 in the first place... If you have it you = want to make sure that both ends understand they are in the implicit = situation. Hence the return of the implicit bit. In issue 6, it was = about the HA internal behavior, for setting routes and there was no 143 = code in the picture.=20 It all pains me. I feel it's all useless complexity. You think it's = important for the consistency of the protocol. What does the rest of the = list say? Pascal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: jeudi 7 ao=FBt 2003 19:22 > To: Pascal Thubert (pthubert) > Cc: nemo@ietf.org > Subject: Re: Text changes to close issue 10 >=20 > "Pascal Thubert (pthubert)" wrote: > > > > I Vijay: > > > > I favor these changes too. Thanks for all the work. > > > > There's still the original question of differentiating implicit and = IGP? >=20 > ??? this was issue 6. please read your own comments. > the concensus was it is a matter of config at the > HA and the HA would be able to distinguish between > implicit mode and running an IGP over the MR-HA > tunnel. >=20 > moreover, it would be a good idea to keep the IGP > part separate from rest of the specification. I dont > think we have considered all the issues. >=20 > > > > Also, MUST is a bit severe for the 143, ain't it? >=20 > MUST is needed. we dont want the MR assuming everything > is fine, when the HA actually couldnt setup forwarding > for the Mobile Network. >=20 > Vijay From exim@www1.ietf.org Fri Aug 8 04:42:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03968 for ; Fri, 8 Aug 2003 04:42:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2p6-0000vl-RP for nemo-archive@odin.ietf.org; Fri, 08 Aug 2003 04:42:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h788g8dG003578 for nemo-archive@odin.ietf.org; Fri, 8 Aug 2003 04:42:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2p6-0000vd-I7 for nemo-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 04:42:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03935 for ; Fri, 8 Aug 2003 04:42:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l2p3-0006q0-00 for nemo-web-archive@ietf.org; Fri, 08 Aug 2003 04:42:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19l2p3-0006pw-00 for nemo-web-archive@ietf.org; Fri, 08 Aug 2003 04:42:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2p0-0000uW-Jo; Fri, 08 Aug 2003 04:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2o3-0000lr-GW for nemo@optimus.ietf.org; Fri, 08 Aug 2003 04:41:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03879 for ; Fri, 8 Aug 2003 04:40:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l2o0-0006pU-00 for nemo@ietf.org; Fri, 08 Aug 2003 04:41:00 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19l2nz-0006pR-00 for nemo@ietf.org; Fri, 08 Aug 2003 04:40:59 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Aug 2003 10:40:03 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h788cGSI005572; Fri, 8 Aug 2003 10:38:17 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Aug 2003 10:40:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Aug 2003 09:40:28 +0100 Message-ID: Thread-Topic: Text changes to close issue 10 Thread-Index: AcNdCHj0BsaHZTHjQ+KgZ2xIudifIwAfrlxg From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 08 Aug 2003 08:40:29.0748 (UTC) FILETIME=[B903DF40:01C35D88] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Text changes to close issue 10 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sorry for being unclear I agree other OGP stuff should be a side discussion. My point about that bit for issue 10 is that to answer 143, the HA must = know that the MR expects implicit. Maybe that MR will use explicit later = but does not want the HA to get its prefixes yet. Maybe the prefixes = will come from PD over the tunnel. Also this may be useful for = multihoming probes sometime.=20 So the HA can not reject blindly all BUs with no prefixes by saying = sorry, 143, I do not have a prefix for you.=20 I told you I did not want a 143 in the first place... If you have it you = want to make sure that both ends understand they are in the implicit = situation. Hence the return of the implicit bit. In issue 6, it was = about the HA internal behavior, for setting routes and there was no 143 = code in the picture.=20 It all pains me. I feel it's all useless complexity. You think it's = important for the consistency of the protocol. What does the rest of the = list say? Pascal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: jeudi 7 ao=FBt 2003 19:22 > To: Pascal Thubert (pthubert) > Cc: nemo@ietf.org > Subject: Re: Text changes to close issue 10 >=20 > "Pascal Thubert (pthubert)" wrote: > > > > I Vijay: > > > > I favor these changes too. Thanks for all the work. > > > > There's still the original question of differentiating implicit and = IGP? >=20 > ??? this was issue 6. please read your own comments. > the concensus was it is a matter of config at the > HA and the HA would be able to distinguish between > implicit mode and running an IGP over the MR-HA > tunnel. >=20 > moreover, it would be a good idea to keep the IGP > part separate from rest of the specification. I dont > think we have considered all the issues. >=20 > > > > Also, MUST is a bit severe for the 143, ain't it? >=20 > MUST is needed. we dont want the MR assuming everything > is fine, when the HA actually couldnt setup forwarding > for the Mobile Network. >=20 > Vijay From nemo-admin@ietf.org Fri Aug 8 04:48:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04079 for ; Fri, 8 Aug 2003 04:48:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2un-0001AK-TA; Fri, 08 Aug 2003 04:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2u7-00019u-Fe for nemo@optimus.ietf.org; Fri, 08 Aug 2003 04:47:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04070 for ; Fri, 8 Aug 2003 04:47:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l2u4-0006sB-00 for nemo@ietf.org; Fri, 08 Aug 2003 04:47:16 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 19l2u3-0006s8-00 for nemo@ietf.org; Fri, 08 Aug 2003 04:47:15 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h788l2PP001491; Fri, 8 Aug 2003 01:47:03 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h787kvRI000793; Fri, 8 Aug 2003 03:46:59 -0400 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 461132EC86; Fri, 8 Aug 2003 10:46:58 +0200 (CEST) Message-ID: <3F336381.8020601@motorola.com> Date: Fri, 08 Aug 2003 10:46:57 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: "Pascal Thubert (pthubert)" , Jongkeun Na , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F329FBF.EE0F3B1C@iprg.nokia.com> In-Reply-To: <3F329FBF.EE0F3B1C@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > I think we should write up a short separate specification on > how a VMN is supposed to behave in a Mobile Network. here is > an outline. > > 1. VMN attaches to Mobile Network and acquires a CoA from MNP. > 2. if it wants to start a session with an LFN, and if the session > is a short lived one, uses CoA as source address. > 3. if the session is a long lived one, uses MIPv6 Route Optimization > 4. performs Return Routability with LFN > 5. if LFN does not support Route Optimization, it sends ICMP error > message (from MIPv6 spec). > 6. VMN reverse tunnels through its Home Agent > 7. if MR is not connected to a network, both step 5 and 6 will fail. > then VMN defaults to using CoA. if the VMN moves in the middle > of the session, the session just breaks. hard luck. since the > MR is disconnected, LFN cant be reached anyway. That sounds like the seeds of a good technique for VMN to efficiently talk to LFN, regardless of MR being or not connected. Alex GBU From exim@www1.ietf.org Fri Aug 8 04:48:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04094 for ; Fri, 8 Aug 2003 04:48:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2uq-0001BC-6k for nemo-archive@odin.ietf.org; Fri, 08 Aug 2003 04:48:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h788m4Np004533 for nemo-archive@odin.ietf.org; Fri, 8 Aug 2003 04:48:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2up-0001B2-L3 for nemo-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 04:48:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04075 for ; Fri, 8 Aug 2003 04:47:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l2um-0006sO-00 for nemo-web-archive@ietf.org; Fri, 08 Aug 2003 04:48:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19l2um-0006sL-00 for nemo-web-archive@ietf.org; Fri, 08 Aug 2003 04:48:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2un-0001AK-TA; Fri, 08 Aug 2003 04:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l2u7-00019u-Fe for nemo@optimus.ietf.org; Fri, 08 Aug 2003 04:47:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04070 for ; Fri, 8 Aug 2003 04:47:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l2u4-0006sB-00 for nemo@ietf.org; Fri, 08 Aug 2003 04:47:16 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 19l2u3-0006s8-00 for nemo@ietf.org; Fri, 08 Aug 2003 04:47:15 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h788l2PP001491; Fri, 8 Aug 2003 01:47:03 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h787kvRI000793; Fri, 8 Aug 2003 03:46:59 -0400 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 461132EC86; Fri, 8 Aug 2003 10:46:58 +0200 (CEST) Message-ID: <3F336381.8020601@motorola.com> Date: Fri, 08 Aug 2003 10:46:57 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: "Pascal Thubert (pthubert)" , Jongkeun Na , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F329FBF.EE0F3B1C@iprg.nokia.com> In-Reply-To: <3F329FBF.EE0F3B1C@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > I think we should write up a short separate specification on > how a VMN is supposed to behave in a Mobile Network. here is > an outline. > > 1. VMN attaches to Mobile Network and acquires a CoA from MNP. > 2. if it wants to start a session with an LFN, and if the session > is a short lived one, uses CoA as source address. > 3. if the session is a long lived one, uses MIPv6 Route Optimization > 4. performs Return Routability with LFN > 5. if LFN does not support Route Optimization, it sends ICMP error > message (from MIPv6 spec). > 6. VMN reverse tunnels through its Home Agent > 7. if MR is not connected to a network, both step 5 and 6 will fail. > then VMN defaults to using CoA. if the VMN moves in the middle > of the session, the session just breaks. hard luck. since the > MR is disconnected, LFN cant be reached anyway. That sounds like the seeds of a good technique for VMN to efficiently talk to LFN, regardless of MR being or not connected. Alex GBU From nemo-admin@ietf.org Fri Aug 8 13:34:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18628 for ; Fri, 8 Aug 2003 13:34:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lB7o-0006o6-JT; Fri, 08 Aug 2003 13:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lB70-0006nX-VS for nemo@optimus.ietf.org; Fri, 08 Aug 2003 13:33:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18589 for ; Fri, 8 Aug 2003 13:33:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lB6y-0002L6-00 for nemo@ietf.org; Fri, 08 Aug 2003 13:33:08 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19lB6x-0002L2-00 for nemo@ietf.org; Fri, 08 Aug 2003 13:33:08 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h78HWYD26491; Fri, 8 Aug 2003 10:32:34 -0700 X-mProtect: <200308081732> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdf2r1hV; Fri, 08 Aug 2003 10:32:32 PDT Message-ID: <3F33DEB1.61624EA4@iprg.nokia.com> Date: Fri, 08 Aug 2003 10:32:33 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: Muhammad Ali Malik , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F3211E5.1020807@motorola.com> <3F329C66.3C933B7E@iprg.nokia.com> <3F335F1F.1050904@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > Vijay Devarapalli wrote: > >> however, LFN is said to not have Mobile IPv6 capabilities and thus > >> can't support the CN side, so communication will necessarily go > >> through HA of VMN. > > > > > > MIPv6 requirements are split into CN, HA, and MN requirements. I > > understood LFN to mean that there is no MIPv6 MN capability. I dont > > it means there is no MIPv6 CN functionality. > > Right, so there is a world where LFN supports CN. I always thought that > "LFN" stands for no MIPv6 functionality whatever that is. > > Maybe we can suggest clarification to the terminology document and say > that LFN does support CN, but does not support MN. IMO, there is no need to make such a distinction. LFN is just a fixed IPv6 host. it might or might not implement MIPv6 CN functionality. any mobile node that attempts to do route optimization with the LFN will be able to figure out whether the LFN supports route optimization. Vijay From exim@www1.ietf.org Fri Aug 8 13:34:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18643 for ; Fri, 8 Aug 2003 13:34:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lB7v-0006p3-BT for nemo-archive@odin.ietf.org; Fri, 08 Aug 2003 13:34:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78HY7rs026222 for nemo-archive@odin.ietf.org; Fri, 8 Aug 2003 13:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lB7v-0006or-5Q for nemo-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 13:34:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18605 for ; Fri, 8 Aug 2003 13:34:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lB7t-0002LI-00 for nemo-web-archive@ietf.org; Fri, 08 Aug 2003 13:34:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lB7s-0002LF-00 for nemo-web-archive@ietf.org; Fri, 08 Aug 2003 13:34:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lB7o-0006o6-JT; Fri, 08 Aug 2003 13:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lB70-0006nX-VS for nemo@optimus.ietf.org; Fri, 08 Aug 2003 13:33:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18589 for ; Fri, 8 Aug 2003 13:33:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lB6y-0002L6-00 for nemo@ietf.org; Fri, 08 Aug 2003 13:33:08 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19lB6x-0002L2-00 for nemo@ietf.org; Fri, 08 Aug 2003 13:33:08 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h78HWYD26491; Fri, 8 Aug 2003 10:32:34 -0700 X-mProtect: <200308081732> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdf2r1hV; Fri, 08 Aug 2003 10:32:32 PDT Message-ID: <3F33DEB1.61624EA4@iprg.nokia.com> Date: Fri, 08 Aug 2003 10:32:33 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: Muhammad Ali Malik , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F3211E5.1020807@motorola.com> <3F329C66.3C933B7E@iprg.nokia.com> <3F335F1F.1050904@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > Vijay Devarapalli wrote: > >> however, LFN is said to not have Mobile IPv6 capabilities and thus > >> can't support the CN side, so communication will necessarily go > >> through HA of VMN. > > > > > > MIPv6 requirements are split into CN, HA, and MN requirements. I > > understood LFN to mean that there is no MIPv6 MN capability. I dont > > it means there is no MIPv6 CN functionality. > > Right, so there is a world where LFN supports CN. I always thought that > "LFN" stands for no MIPv6 functionality whatever that is. > > Maybe we can suggest clarification to the terminology document and say > that LFN does support CN, but does not support MN. IMO, there is no need to make such a distinction. LFN is just a fixed IPv6 host. it might or might not implement MIPv6 CN functionality. any mobile node that attempts to do route optimization with the LFN will be able to figure out whether the LFN supports route optimization. Vijay From nemo-admin@ietf.org Fri Aug 8 13:43:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18862 for ; Fri, 8 Aug 2003 13:43:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lBGW-0007M5-UU; Fri, 08 Aug 2003 13:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lBFp-0007IV-48 for nemo@optimus.ietf.org; Fri, 08 Aug 2003 13:42:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18790 for ; Fri, 8 Aug 2003 13:42:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lBFm-0002NK-00 for nemo@ietf.org; Fri, 08 Aug 2003 13:42:15 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19lBFl-0002NA-00 for nemo@ietf.org; Fri, 08 Aug 2003 13:42:14 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h78Hfc503915; Fri, 8 Aug 2003 10:41:38 -0700 X-mProtect: <200308081741> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd86fPWc; Fri, 08 Aug 2003 10:41:36 PDT Message-ID: <3F33E0D1.B09E5F04@iprg.nokia.com> Date: Fri, 08 Aug 2003 10:41:37 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: nemo@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Text changes to close issue 10 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Pascal Thubert (pthubert)" wrote: > > Sorry for being unclear > > I agree other OGP stuff should be a side discussion. > > My point about that bit for issue 10 is that to answer 143, the HA must know that the MR expects implicit. Maybe that MR will use explicit later but does not want the HA to get its prefixes yet. Maybe the prefixes will come from PD over the tunnel. Also this may be useful for multihoming probes sometime. hmm.... if the MR does not want the HA to setup forwarding yet, then it is better off sending a binding update with the R flag turned off. and when it is ready to send prefixes through explicit, send another binding update with R flag turned on. isnt that a better solution? I am not sure how multi-homing fits in here. > > So the HA can not reject blindly all BUs with no prefixes by saying sorry, 143, I do not have a prefix for you. > > I told you I did not want a 143 in the first place... If you have it you want to make sure that both ends understand they are in the implicit situation. Hence the return of the implicit bit. In issue 6, it was about the HA internal behavior, for setting routes and there was no 143 code in the picture. > > It all pains me. I feel it's all useless complexity. You think it's important for the consistency of the protocol. I think it is far more important to take care of all the error conditions, then to optimize the protocol right from the start. Vijay From exim@www1.ietf.org Fri Aug 8 13:43:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18877 for ; Fri, 8 Aug 2003 13:43:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lBGY-0007OA-3a for nemo-archive@odin.ietf.org; Fri, 08 Aug 2003 13:43:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78Hh2n8028398 for nemo-archive@odin.ietf.org; Fri, 8 Aug 2003 13:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lBGX-0007Nx-Vx for nemo-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 13:43:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18813 for ; Fri, 8 Aug 2003 13:42:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lBGV-0002Nb-00 for nemo-web-archive@ietf.org; Fri, 08 Aug 2003 13:42:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lBGV-0002NY-00 for nemo-web-archive@ietf.org; Fri, 08 Aug 2003 13:42:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lBGW-0007M5-UU; Fri, 08 Aug 2003 13:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lBFp-0007IV-48 for nemo@optimus.ietf.org; Fri, 08 Aug 2003 13:42:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18790 for ; Fri, 8 Aug 2003 13:42:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lBFm-0002NK-00 for nemo@ietf.org; Fri, 08 Aug 2003 13:42:15 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19lBFl-0002NA-00 for nemo@ietf.org; Fri, 08 Aug 2003 13:42:14 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h78Hfc503915; Fri, 8 Aug 2003 10:41:38 -0700 X-mProtect: <200308081741> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd86fPWc; Fri, 08 Aug 2003 10:41:36 PDT Message-ID: <3F33E0D1.B09E5F04@iprg.nokia.com> Date: Fri, 08 Aug 2003 10:41:37 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: nemo@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Text changes to close issue 10 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Pascal Thubert (pthubert)" wrote: > > Sorry for being unclear > > I agree other OGP stuff should be a side discussion. > > My point about that bit for issue 10 is that to answer 143, the HA must know that the MR expects implicit. Maybe that MR will use explicit later but does not want the HA to get its prefixes yet. Maybe the prefixes will come from PD over the tunnel. Also this may be useful for multihoming probes sometime. hmm.... if the MR does not want the HA to setup forwarding yet, then it is better off sending a binding update with the R flag turned off. and when it is ready to send prefixes through explicit, send another binding update with R flag turned on. isnt that a better solution? I am not sure how multi-homing fits in here. > > So the HA can not reject blindly all BUs with no prefixes by saying sorry, 143, I do not have a prefix for you. > > I told you I did not want a 143 in the first place... If you have it you want to make sure that both ends understand they are in the implicit situation. Hence the return of the implicit bit. In issue 6, it was about the HA internal behavior, for setting routes and there was no 143 code in the picture. > > It all pains me. I feel it's all useless complexity. You think it's important for the consistency of the protocol. I think it is far more important to take care of all the error conditions, then to optimize the protocol right from the start. Vijay From exim@www1.ietf.org Fri Aug 8 13:57:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19270 for ; Fri, 8 Aug 2003 13:57:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lBU7-0007oA-Vs for nemo-archive@odin.ietf.org; Fri, 08 Aug 2003 13:57:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78Hv3ei030010 for nemo-archive@odin.ietf.org; Fri, 8 Aug 2003 13:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lBU7-0007nx-RF for nemo-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 13:57:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19244 for ; Fri, 8 Aug 2003 13:56:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lBU5-0002Sl-00 for nemo-web-archive@ietf.org; Fri, 08 Aug 2003 13:57:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lBU5-0002Sh-00 for nemo-web-archive@ietf.org; Fri, 08 Aug 2003 13:57:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lBU5-0007n2-8O; Fri, 08 Aug 2003 13:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lBTv-0007mk-Nj for nemo@optimus.ietf.org; Fri, 08 Aug 2003 13:56:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19234 for ; Fri, 8 Aug 2003 13:56:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lBTt-0002ST-00 for nemo@ietf.org; Fri, 08 Aug 2003 13:56:49 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19lBTs-0002Ry-00 for nemo@ietf.org; Fri, 08 Aug 2003 13:56:48 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h78HtxP18431; Fri, 8 Aug 2003 10:55:59 -0700 X-mProtect: <200308081755> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdPfdGNK; Fri, 08 Aug 2003 10:55:57 PDT Message-ID: <3F33E42D.FF460E5D@iprg.nokia.com> Date: Fri, 08 Aug 2003 10:55:57 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: "Pascal Thubert (pthubert)" , Jongkeun Na , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F329FBF.EE0F3B1C@iprg.nokia.com> <3F336381.8020601@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I prefer a short spec on this. or do you think it could go into a appendix for the basic support draft? Vijay Alexandru Petrescu wrote: > > Vijay Devarapalli wrote: > > I think we should write up a short separate specification on > > how a VMN is supposed to behave in a Mobile Network. here is > > an outline. > > > > 1. VMN attaches to Mobile Network and acquires a CoA from MNP. > > 2. if it wants to start a session with an LFN, and if the session > > is a short lived one, uses CoA as source address. > > 3. if the session is a long lived one, uses MIPv6 Route Optimization > > 4. performs Return Routability with LFN > > 5. if LFN does not support Route Optimization, it sends ICMP error > > message (from MIPv6 spec). > > 6. VMN reverse tunnels through its Home Agent > > 7. if MR is not connected to a network, both step 5 and 6 will fail. > > then VMN defaults to using CoA. if the VMN moves in the middle > > of the session, the session just breaks. hard luck. since the > > MR is disconnected, LFN cant be reached anyway. > > That sounds like the seeds of a good technique for VMN to efficiently > talk to LFN, regardless of MR being or not connected. From nemo-admin@ietf.org Fri Aug 8 14:47:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19269 for ; Fri, 8 Aug 2003 13:57:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lBU5-0007n2-8O; Fri, 08 Aug 2003 13:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lBTv-0007mk-Nj for nemo@optimus.ietf.org; Fri, 08 Aug 2003 13:56:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19234 for ; Fri, 8 Aug 2003 13:56:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lBTt-0002ST-00 for nemo@ietf.org; Fri, 08 Aug 2003 13:56:49 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19lBTs-0002Ry-00 for nemo@ietf.org; Fri, 08 Aug 2003 13:56:48 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h78HtxP18431; Fri, 8 Aug 2003 10:55:59 -0700 X-mProtect: <200308081755> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdPfdGNK; Fri, 08 Aug 2003 10:55:57 PDT Message-ID: <3F33E42D.FF460E5D@iprg.nokia.com> Date: Fri, 08 Aug 2003 10:55:57 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: "Pascal Thubert (pthubert)" , Jongkeun Na , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F329FBF.EE0F3B1C@iprg.nokia.com> <3F336381.8020601@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I prefer a short spec on this. or do you think it could go into a appendix for the basic support draft? Vijay Alexandru Petrescu wrote: > > Vijay Devarapalli wrote: > > I think we should write up a short separate specification on > > how a VMN is supposed to behave in a Mobile Network. here is > > an outline. > > > > 1. VMN attaches to Mobile Network and acquires a CoA from MNP. > > 2. if it wants to start a session with an LFN, and if the session > > is a short lived one, uses CoA as source address. > > 3. if the session is a long lived one, uses MIPv6 Route Optimization > > 4. performs Return Routability with LFN > > 5. if LFN does not support Route Optimization, it sends ICMP error > > message (from MIPv6 spec). > > 6. VMN reverse tunnels through its Home Agent > > 7. if MR is not connected to a network, both step 5 and 6 will fail. > > then VMN defaults to using CoA. if the VMN moves in the middle > > of the session, the session just breaks. hard luck. since the > > MR is disconnected, LFN cant be reached anyway. > > That sounds like the seeds of a good technique for VMN to efficiently > talk to LFN, regardless of MR being or not connected. From nemo-admin@ietf.org Mon Aug 11 02:55:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08477 for ; Mon, 11 Aug 2003 02:55:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m6a6-0006r9-0t; Mon, 11 Aug 2003 02:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m6ZR-0006pZ-OG for nemo@optimus.ietf.org; Mon, 11 Aug 2003 02:54:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08448 for ; Mon, 11 Aug 2003 02:54:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m6ZN-0003Y3-00 for nemo@ietf.org; Mon, 11 Aug 2003 02:54:17 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19m6ZN-0003Xl-00 for nemo@ietf.org; Mon, 11 Aug 2003 02:54:17 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 423395D092 for ; Mon, 11 Aug 2003 15:53:46 +0900 (JST) Date: Mon, 11 Aug 2003 15:50:09 +0900 From: Thierry Ernst To: nemo Message-Id: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO Basic Support: About terminology Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all, draft-ietf-nemo-basic-support-pre01.txt Mobile Network Prefix The IPv6 prefix advertised in the Mobile Network by one or more Mobile Routers. There could be multiple prefixes in the Mobile Network. This is already defined in the terminology drafts (seamoby and NEMO): draft-ietf-seamoby-mobility-terminology-04.txt Mobile Network Prefix A bit string that consists of some number of initial bits of an IP address which identifies the entire mobile network within the Internet topology. All nodes in a mobile network necessarily have an address named after this prefix. draft-ietf-neno-terminology-00.txt MNP An acronym for Mobile Network Prefix (defined in [Mobility]) So, I think it's useless to define it here again in basic-support. Besides this, I would also like to propose to add a term to distinguish Mobile IPv6 BU and NEMO BU: PBU for "Prefix Binding Update". At some point in time, it will allow to avoid confusion between the 2 protocols. Thierry From exim@www1.ietf.org Mon Aug 11 02:55:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08492 for ; Mon, 11 Aug 2003 02:55:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m6aE-0006sF-L6 for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 02:55:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7B6tAKd026417 for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 02:55:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m6aE-0006s0-EU for nemo-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 02:55:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08471 for ; Mon, 11 Aug 2003 02:55:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m6aA-0003YU-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 02:55:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19m6aA-0003YQ-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 02:55:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m6a6-0006r9-0t; Mon, 11 Aug 2003 02:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m6ZR-0006pZ-OG for nemo@optimus.ietf.org; Mon, 11 Aug 2003 02:54:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08448 for ; Mon, 11 Aug 2003 02:54:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m6ZN-0003Y3-00 for nemo@ietf.org; Mon, 11 Aug 2003 02:54:17 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19m6ZN-0003Xl-00 for nemo@ietf.org; Mon, 11 Aug 2003 02:54:17 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 423395D092 for ; Mon, 11 Aug 2003 15:53:46 +0900 (JST) Date: Mon, 11 Aug 2003 15:50:09 +0900 From: Thierry Ernst To: nemo Message-Id: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO Basic Support: About terminology Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, draft-ietf-nemo-basic-support-pre01.txt Mobile Network Prefix The IPv6 prefix advertised in the Mobile Network by one or more Mobile Routers. There could be multiple prefixes in the Mobile Network. This is already defined in the terminology drafts (seamoby and NEMO): draft-ietf-seamoby-mobility-terminology-04.txt Mobile Network Prefix A bit string that consists of some number of initial bits of an IP address which identifies the entire mobile network within the Internet topology. All nodes in a mobile network necessarily have an address named after this prefix. draft-ietf-neno-terminology-00.txt MNP An acronym for Mobile Network Prefix (defined in [Mobility]) So, I think it's useless to define it here again in basic-support. Besides this, I would also like to propose to add a term to distinguish Mobile IPv6 BU and NEMO BU: PBU for "Prefix Binding Update". At some point in time, it will allow to avoid confusion between the 2 protocols. Thierry From nemo-admin@ietf.org Mon Aug 11 09:59:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16261 for ; Mon, 11 Aug 2003 09:59:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDCQ-000426-1F; Mon, 11 Aug 2003 09:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDBx-0003yG-DZ for nemo@optimus.ietf.org; Mon, 11 Aug 2003 09:58:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16211 for ; Mon, 11 Aug 2003 09:58:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mDBv-00064D-00 for nemo@ietf.org; Mon, 11 Aug 2003 09:58:31 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19mDBu-000646-00 for nemo@ietf.org; Mon, 11 Aug 2003 09:58:30 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h7BDwPfG013075; Mon, 11 Aug 2003 06:58:26 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h7BDwL85028977; Mon, 11 Aug 2003 08:58:22 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 05C302EC8B; Mon, 11 Aug 2003 15:58:20 +0200 (CEST) Message-ID: <3F37A0FC.4030104@nal.motlabs.com> Date: Mon, 11 Aug 2003 15:58:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Muhammad Ali Malik , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F3211E5.1020807@motorola.com> <3F329C66.3C933B7E@iprg.nokia.com> <3F335F1F.1050904@motorola.com> <3F33DEB1.61624EA4@iprg.nokia.com> In-Reply-To: <3F33DEB1.61624EA4@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> Maybe we can suggest clarification to the terminology document and >> say that LFN does support CN, but does not support MN. > > > IMO, there is no need to make such a distinction. LFN is just a fixed > IPv6 host. it might or might not implement MIPv6 CN functionality. > any mobile node that attempts to do route optimization with the LFN > will be able to figure out whether the LFN supports route > optimization. Ok. Alex GBU From exim@www1.ietf.org Mon Aug 11 09:59:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16288 for ; Mon, 11 Aug 2003 09:59:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDCZ-00044T-Sw for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 09:59:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BDxBZZ015645 for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 09:59:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDCZ-00044G-OA for nemo-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 09:59:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16237 for ; Mon, 11 Aug 2003 09:59:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mDCX-00064j-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 09:59:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mDCW-00064d-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 09:59:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDCP-00041X-7Y; Mon, 11 Aug 2003 09:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDBg-0003xu-O7 for nemo@optimus.ietf.org; Mon, 11 Aug 2003 09:58:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16190 for ; Mon, 11 Aug 2003 09:58:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mDBe-00063o-00 for nemo@ietf.org; Mon, 11 Aug 2003 09:58:14 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19mDBd-00063h-00 for nemo@ietf.org; Mon, 11 Aug 2003 09:58:14 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h7BDva1s007792; Mon, 11 Aug 2003 06:57:37 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h7BDvK01013213; Mon, 11 Aug 2003 08:57:21 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id B3CDB2EC86; Mon, 11 Aug 2003 15:57:31 +0200 (CEST) Message-ID: <3F37A0CB.6000502@nal.motlabs.com> Date: Mon, 11 Aug 2003 15:57:31 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: nemo@ietf.org, pthubert@cisco.com Subject: Re: [nemo] Text changes to close issue 10 References: <3F314269.90BD06E4@iprg.nokia.com> In-Reply-To: <3F314269.90BD06E4@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think that the prefix table concept and its relation to implicit and explicit modes look much more clearer now. The minor thing I wish to avoid happening is falsely interpreting "implicit mode has no Prefix Table" as "implicit is no secure". The intention is for implicit mode to rely as much as possible on existing security mechanisms (other than "prefix ownership" induced by Prefix Table used in explicit mode). But I think this is captured somewhere in the text; otherwise maybe the security section. Vijay Devarapalli wrote: > I made some significant changes to the text. this is for closing > issue 10. I realised that the Prefix Table and implict mode has > been a source for lot of confusion. many people dont seem to > like what was intended to be a simple solution. anyway here is > what I propose we should do. > 1. use Prefix Table only for verification in explicit mode. it > is used only if the HA needs to be prevent misbehaving MRs from > claiming prefixes that belong to other MRs. if a particular > deployment is such that the HA does not expect MRs to misbehave > then the Prefix Table is not required. > > 2. make it clear in Implicit mode that any mechanism can be used. > it is totally internal to the Home Agent. remove all refereces to > using Prefix Table in implicit mode. Sounds good to me. > 3. change Binding Ack status 143 to 'Forwarding Setup failed'. it > is used to indicate that the HA was unable to setup forwarding > for the Mobile Network when it received a Binding Update from the > MR in implicit mode. Good. I can't think of name alternatives. Maybe 'Can't Forward'. > replace > >> Prefix Table >> >> It is a list of a mobile network prefixes indexed >> by the extended Home Address of a Mobile Router. The >> prefix table is managed by the Home Agent. When a Home >> Agent receives a Binding Update without any options, >> it searches a correspondent Mobile Network Prefix in >> the prefix table, keying with the Home Address of the >> requesting Mobile Router. This is an optional data >> structure. > > > with > Prefix Table > > It is a list of a mobile network prefixes indexed > by the extended Home Address of a Mobile Router. The > prefix table is managed by the Home Agent. This is an > optional data structure. Sounds good. > > replace > >> 143 Mobile Network Prefix information unavailable. > > > with > 143 Forwarding Setup failed > > > replace > >> The Home Agent can use any mechanism (not defined >> in this document) to determine the Mobile Network Prefix(es) >> owned by the Mobile Router. One of the possible mechanisms is >> where the Home Agent maintains a pre-configured Prefix Table >> listing all the Mobile Network prefixes owned by a particular >> Mobile Router. This table is keyed on the Home Address of the >> Mobile Router. > > > with > > The Home Agent can use any mechanism (not defined > in this document) to determine the Mobile Network Prefix(es) > owned by the Mobile Router and setup forwarding for the Mobile > Network. One example would be manual configuration at the > Home Agent mapping the Mobile Router's home address to the > information required for setting up forwarding for the Mobile > Network. Agreed. > replace > >> In some scenarios, the Home Agent might need to maintain a Prefix >> Table of Mobile Routers and the IPv6 prefixes owned by Mobile >> Routers. The Home Agent MUST maintain this table if the Mobile >> Routers operate under the implicit mode where they do not include any >> prefix information in the Binding Updates. >> >> Each entry in the Prefix Table conceptually contains the following >> fields: >> >> - The Home Address of the Mobile Router. This field is used as the >> key for searching the pre-configured prefix table. >> >> - The Mobile Network Prefix of the Mobile Router associated with >> the Home Address. >> >> In some deployment scenarios, it is necessary for Home Agent to >> prevent a misbehaving Mobile Router from claiming mobile network >> prefixes belonging to another Mobile Router. The Home Agent can >> prevent such attacks if it maintains the Prefix Table and verifies >> the Prefix Information provided by the Mobile Router against the >> if the Binding Update contained explicit prefix information in the >> form of either the Mobile Network Prefix Option or the Mobile Network >> Prefix Length Option. > > > with > > In some deployment scenarios it may be necessary for the Home Agent > to prevent a misbehaving Mobile Router from claiming mobile network > prefixes belonging to another Mobile Router. The Home Agent can > prevent such attacks if it maintains the Prefix Table and verifies > the Prefix Information provided by the Mobile Router against the > entries in the Prefix Table. However, this verification is done only > if the Binding Update contained explicit prefix information in the > form of either the Mobile Network Prefix Option or the Mobile Network > Prefix Length Option. > > Each entry in the Prefix Table conceptually contains the following > fields: > > - The Home Address of the Mobile Router. This field is used as the > key for searching the pre-configured prefix table. > > - The Mobile Network Prefix of the Mobile Router associated with > the Home Address. Good. > replace > >> - If there are no options in the Binding Update, the Home Agent >> figures out which prefixes are assigned to the Mobile Router >> from the Pre-configured Prefix Table. If the Home Agent can not >> find the correspondent Mobile Network Prefix, it MUST reject the >> Binding Update and send a Binding Acknowledgement with the Status >> field set to 143 (Prefix Information unavailable). > > > to > - If there are no options in the Binding Update, the Home Agent > uses manual pre-configured information to determine the manually > prefixes assigned to the Mobile Router and for setting up > forwarding for the Mobile Network. If there is no information > that the Home Agent can use, it MUST reject the Binding Update > and send a Binding Acknowledgement with status set to 143 > (Forwarding Setup failed). > > replace > >> The Home Agent sets the status code in the Binding Acknowledgement >> to '143' (Mobile Network Prefix information unavailable) in order >> to indicate the Mobile Router that the received Home Address in the >> Binding Update does not match any prefix entry in the pre-configured >> prefix table. This is used in the Implicit case where the Mobile >> Router does not include any prefix information in the Binding Update. > > > > with > > The Home Agent sets the status code to 143 (Forwarding Setup > failed) if it is unable to determine the information needed to setup > forwarding for the Mobile Network. This is used in the Implicit mode > where the Mobile Router does not include any prefix information in > the Binding Update. Ok. Alex GBU From exim@www1.ietf.org Mon Aug 11 09:59:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16303 for ; Mon, 11 Aug 2003 09:59:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDCb-00044m-9W for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 09:59:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BDxDi0015662 for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 09:59:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDCZ-00044F-NK for nemo-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 09:59:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16238 for ; Mon, 11 Aug 2003 09:59:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mDCX-00064i-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 09:59:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mDCW-00064c-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 09:59:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDCQ-000426-1F; Mon, 11 Aug 2003 09:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDBx-0003yG-DZ for nemo@optimus.ietf.org; Mon, 11 Aug 2003 09:58:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16211 for ; Mon, 11 Aug 2003 09:58:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mDBv-00064D-00 for nemo@ietf.org; Mon, 11 Aug 2003 09:58:31 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 19mDBu-000646-00 for nemo@ietf.org; Mon, 11 Aug 2003 09:58:30 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h7BDwPfG013075; Mon, 11 Aug 2003 06:58:26 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h7BDwL85028977; Mon, 11 Aug 2003 08:58:22 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 05C302EC8B; Mon, 11 Aug 2003 15:58:20 +0200 (CEST) Message-ID: <3F37A0FC.4030104@nal.motlabs.com> Date: Mon, 11 Aug 2003 15:58:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Muhammad Ali Malik , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F3211E5.1020807@motorola.com> <3F329C66.3C933B7E@iprg.nokia.com> <3F335F1F.1050904@motorola.com> <3F33DEB1.61624EA4@iprg.nokia.com> In-Reply-To: <3F33DEB1.61624EA4@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> Maybe we can suggest clarification to the terminology document and >> say that LFN does support CN, but does not support MN. > > > IMO, there is no need to make such a distinction. LFN is just a fixed > IPv6 host. it might or might not implement MIPv6 CN functionality. > any mobile node that attempts to do route optimization with the LFN > will be able to figure out whether the LFN supports route > optimization. Ok. Alex GBU From nemo-admin@ietf.org Mon Aug 11 10:04:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16553 for ; Mon, 11 Aug 2003 10:04:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDHE-0004IN-Lu; Mon, 11 Aug 2003 10:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDGR-0004I9-IT for nemo@optimus.ietf.org; Mon, 11 Aug 2003 10:03:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16422 for ; Mon, 11 Aug 2003 10:03:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mDGP-00065s-00 for nemo@ietf.org; Mon, 11 Aug 2003 10:03:09 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19mDGO-00065p-00 for nemo@ietf.org; Mon, 11 Aug 2003 10:03:08 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h7BE2xSr028774; Mon, 11 Aug 2003 07:03:04 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h7BE2r85000697; Mon, 11 Aug 2003 09:02:54 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 769952EC86; Mon, 11 Aug 2003 16:02:51 +0200 (CEST) Message-ID: <3F37A20B.50003@nal.motlabs.com> Date: Mon, 11 Aug 2003 16:02:51 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Alexandru Petrescu , "Pascal Thubert (pthubert)" , Jongkeun Na , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F329FBF.EE0F3B1C@iprg.nokia.com> <3F336381.8020601@motorola.com> <3F33E42D.FF460E5D@iprg.nokia.com> In-Reply-To: <3F33E42D.FF460E5D@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > I prefer a short spec on this. or do you think it could > go into a appendix for the basic support draft? Depends on what members want. My oppinion is that this is like part of initial steps in the RO work, not basic work. >>>1. VMN attaches to Mobile Network and acquires a CoA from MNP. >>>2. if it wants to start a session with an LFN, and if the session >>> is a short lived one, uses CoA as source address. >>>3. if the session is a long lived one, uses MIPv6 Route Optimization >>>4. performs Return Routability with LFN >>>5. if LFN does not support Route Optimization, it sends ICMP error >>> message (from MIPv6 spec). >>>6. VMN reverse tunnels through its Home Agent >>>7. if MR is not connected to a network, both step 5 and 6 will fail. >>> then VMN defaults to using CoA. if the VMN moves in the middle >>> of the session, the session just breaks. hard luck. since the >>> MR is disconnected, LFN cant be reached anyway. The technique should be modified/enhanced to also work for an LFN of a VMR (or MR for that matter) that attaches under another MR, and that talks to a LFN of the latter. Alex GBU From exim@www1.ietf.org Mon Aug 11 10:04:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16570 for ; Mon, 11 Aug 2003 10:04:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDHI-0004JK-8H for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 10:04:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BE443n016564 for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 10:04:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDHI-0004J5-2K for nemo-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 10:04:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16495 for ; Mon, 11 Aug 2003 10:03:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mDHG-00066C-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 10:04:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mDHF-000669-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 10:04:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDHE-0004IN-Lu; Mon, 11 Aug 2003 10:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDGR-0004I9-IT for nemo@optimus.ietf.org; Mon, 11 Aug 2003 10:03:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16422 for ; Mon, 11 Aug 2003 10:03:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mDGP-00065s-00 for nemo@ietf.org; Mon, 11 Aug 2003 10:03:09 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19mDGO-00065p-00 for nemo@ietf.org; Mon, 11 Aug 2003 10:03:08 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h7BE2xSr028774; Mon, 11 Aug 2003 07:03:04 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h7BE2r85000697; Mon, 11 Aug 2003 09:02:54 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 769952EC86; Mon, 11 Aug 2003 16:02:51 +0200 (CEST) Message-ID: <3F37A20B.50003@nal.motlabs.com> Date: Mon, 11 Aug 2003 16:02:51 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Alexandru Petrescu , "Pascal Thubert (pthubert)" , Jongkeun Na , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F329FBF.EE0F3B1C@iprg.nokia.com> <3F336381.8020601@motorola.com> <3F33E42D.FF460E5D@iprg.nokia.com> In-Reply-To: <3F33E42D.FF460E5D@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > I prefer a short spec on this. or do you think it could > go into a appendix for the basic support draft? Depends on what members want. My oppinion is that this is like part of initial steps in the RO work, not basic work. >>>1. VMN attaches to Mobile Network and acquires a CoA from MNP. >>>2. if it wants to start a session with an LFN, and if the session >>> is a short lived one, uses CoA as source address. >>>3. if the session is a long lived one, uses MIPv6 Route Optimization >>>4. performs Return Routability with LFN >>>5. if LFN does not support Route Optimization, it sends ICMP error >>> message (from MIPv6 spec). >>>6. VMN reverse tunnels through its Home Agent >>>7. if MR is not connected to a network, both step 5 and 6 will fail. >>> then VMN defaults to using CoA. if the VMN moves in the middle >>> of the session, the session just breaks. hard luck. since the >>> MR is disconnected, LFN cant be reached anyway. The technique should be modified/enhanced to also work for an LFN of a VMR (or MR for that matter) that attaches under another MR, and that talks to a LFN of the latter. Alex GBU From nemo-admin@ietf.org Mon Aug 11 10:47:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16262 for ; Mon, 11 Aug 2003 09:59:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDCP-00041X-7Y; Mon, 11 Aug 2003 09:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mDBg-0003xu-O7 for nemo@optimus.ietf.org; Mon, 11 Aug 2003 09:58:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16190 for ; Mon, 11 Aug 2003 09:58:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mDBe-00063o-00 for nemo@ietf.org; Mon, 11 Aug 2003 09:58:14 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19mDBd-00063h-00 for nemo@ietf.org; Mon, 11 Aug 2003 09:58:14 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h7BDva1s007792; Mon, 11 Aug 2003 06:57:37 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h7BDvK01013213; Mon, 11 Aug 2003 08:57:21 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id B3CDB2EC86; Mon, 11 Aug 2003 15:57:31 +0200 (CEST) Message-ID: <3F37A0CB.6000502@nal.motlabs.com> Date: Mon, 11 Aug 2003 15:57:31 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: nemo@ietf.org, pthubert@cisco.com Subject: Re: [nemo] Text changes to close issue 10 References: <3F314269.90BD06E4@iprg.nokia.com> In-Reply-To: <3F314269.90BD06E4@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think that the prefix table concept and its relation to implicit and explicit modes look much more clearer now. The minor thing I wish to avoid happening is falsely interpreting "implicit mode has no Prefix Table" as "implicit is no secure". The intention is for implicit mode to rely as much as possible on existing security mechanisms (other than "prefix ownership" induced by Prefix Table used in explicit mode). But I think this is captured somewhere in the text; otherwise maybe the security section. Vijay Devarapalli wrote: > I made some significant changes to the text. this is for closing > issue 10. I realised that the Prefix Table and implict mode has > been a source for lot of confusion. many people dont seem to > like what was intended to be a simple solution. anyway here is > what I propose we should do. > 1. use Prefix Table only for verification in explicit mode. it > is used only if the HA needs to be prevent misbehaving MRs from > claiming prefixes that belong to other MRs. if a particular > deployment is such that the HA does not expect MRs to misbehave > then the Prefix Table is not required. > > 2. make it clear in Implicit mode that any mechanism can be used. > it is totally internal to the Home Agent. remove all refereces to > using Prefix Table in implicit mode. Sounds good to me. > 3. change Binding Ack status 143 to 'Forwarding Setup failed'. it > is used to indicate that the HA was unable to setup forwarding > for the Mobile Network when it received a Binding Update from the > MR in implicit mode. Good. I can't think of name alternatives. Maybe 'Can't Forward'. > replace > >> Prefix Table >> >> It is a list of a mobile network prefixes indexed >> by the extended Home Address of a Mobile Router. The >> prefix table is managed by the Home Agent. When a Home >> Agent receives a Binding Update without any options, >> it searches a correspondent Mobile Network Prefix in >> the prefix table, keying with the Home Address of the >> requesting Mobile Router. This is an optional data >> structure. > > > with > Prefix Table > > It is a list of a mobile network prefixes indexed > by the extended Home Address of a Mobile Router. The > prefix table is managed by the Home Agent. This is an > optional data structure. Sounds good. > > replace > >> 143 Mobile Network Prefix information unavailable. > > > with > 143 Forwarding Setup failed > > > replace > >> The Home Agent can use any mechanism (not defined >> in this document) to determine the Mobile Network Prefix(es) >> owned by the Mobile Router. One of the possible mechanisms is >> where the Home Agent maintains a pre-configured Prefix Table >> listing all the Mobile Network prefixes owned by a particular >> Mobile Router. This table is keyed on the Home Address of the >> Mobile Router. > > > with > > The Home Agent can use any mechanism (not defined > in this document) to determine the Mobile Network Prefix(es) > owned by the Mobile Router and setup forwarding for the Mobile > Network. One example would be manual configuration at the > Home Agent mapping the Mobile Router's home address to the > information required for setting up forwarding for the Mobile > Network. Agreed. > replace > >> In some scenarios, the Home Agent might need to maintain a Prefix >> Table of Mobile Routers and the IPv6 prefixes owned by Mobile >> Routers. The Home Agent MUST maintain this table if the Mobile >> Routers operate under the implicit mode where they do not include any >> prefix information in the Binding Updates. >> >> Each entry in the Prefix Table conceptually contains the following >> fields: >> >> - The Home Address of the Mobile Router. This field is used as the >> key for searching the pre-configured prefix table. >> >> - The Mobile Network Prefix of the Mobile Router associated with >> the Home Address. >> >> In some deployment scenarios, it is necessary for Home Agent to >> prevent a misbehaving Mobile Router from claiming mobile network >> prefixes belonging to another Mobile Router. The Home Agent can >> prevent such attacks if it maintains the Prefix Table and verifies >> the Prefix Information provided by the Mobile Router against the >> if the Binding Update contained explicit prefix information in the >> form of either the Mobile Network Prefix Option or the Mobile Network >> Prefix Length Option. > > > with > > In some deployment scenarios it may be necessary for the Home Agent > to prevent a misbehaving Mobile Router from claiming mobile network > prefixes belonging to another Mobile Router. The Home Agent can > prevent such attacks if it maintains the Prefix Table and verifies > the Prefix Information provided by the Mobile Router against the > entries in the Prefix Table. However, this verification is done only > if the Binding Update contained explicit prefix information in the > form of either the Mobile Network Prefix Option or the Mobile Network > Prefix Length Option. > > Each entry in the Prefix Table conceptually contains the following > fields: > > - The Home Address of the Mobile Router. This field is used as the > key for searching the pre-configured prefix table. > > - The Mobile Network Prefix of the Mobile Router associated with > the Home Address. Good. > replace > >> - If there are no options in the Binding Update, the Home Agent >> figures out which prefixes are assigned to the Mobile Router >> from the Pre-configured Prefix Table. If the Home Agent can not >> find the correspondent Mobile Network Prefix, it MUST reject the >> Binding Update and send a Binding Acknowledgement with the Status >> field set to 143 (Prefix Information unavailable). > > > to > - If there are no options in the Binding Update, the Home Agent > uses manual pre-configured information to determine the manually > prefixes assigned to the Mobile Router and for setting up > forwarding for the Mobile Network. If there is no information > that the Home Agent can use, it MUST reject the Binding Update > and send a Binding Acknowledgement with status set to 143 > (Forwarding Setup failed). > > replace > >> The Home Agent sets the status code in the Binding Acknowledgement >> to '143' (Mobile Network Prefix information unavailable) in order >> to indicate the Mobile Router that the received Home Address in the >> Binding Update does not match any prefix entry in the pre-configured >> prefix table. This is used in the Implicit case where the Mobile >> Router does not include any prefix information in the Binding Update. > > > > with > > The Home Agent sets the status code to 143 (Forwarding Setup > failed) if it is unable to determine the information needed to setup > forwarding for the Mobile Network. This is used in the Implicit mode > where the Mobile Router does not include any prefix information in > the Binding Update. Ok. Alex GBU From nemo-admin@ietf.org Mon Aug 11 13:01:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23036 for ; Mon, 11 Aug 2003 13:01:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mG2X-0003V3-Hu; Mon, 11 Aug 2003 13:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mG1a-0003U1-RH for nemo@optimus.ietf.org; Mon, 11 Aug 2003 13:00:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22968; Mon, 11 Aug 2003 12:59:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mG1Y-0007Bu-00; Mon, 11 Aug 2003 13:00:00 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19mG1X-0007Bh-00; Mon, 11 Aug 2003 12:59:59 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7BGxPT04669; Mon, 11 Aug 2003 09:59:25 -0700 X-mProtect: <200308111659> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdN6gMSi; Mon, 11 Aug 2003 09:59:24 PDT Message-ID: <3F37CB6C.3C9D9956@iprg.nokia.com> Date: Mon, 11 Aug 2003 09:59:24 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Thierry Ernst CC: nemo , seamoby@ietf.org Subject: Re: [nemo] NEMO Basic Support: About terminology References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I have cc'ed Seamoby list. Thierry Ernst wrote: > > Dear all, > > draft-ietf-nemo-basic-support-pre01.txt > > Mobile Network Prefix > > The IPv6 prefix advertised in the Mobile Network > by one or more Mobile Routers. There could be multiple > prefixes in the Mobile Network. > > This is already defined in the terminology drafts (seamoby and NEMO): > > draft-ietf-seamoby-mobility-terminology-04.txt > > Mobile Network Prefix > > A bit string that consists of some number of initial bits of an > IP address which identifies the entire mobile network within the > Internet topology. All nodes in a mobile network necessarily have > an address named after this prefix. > > draft-ietf-neno-terminology-00.txt > > MNP > An acronym for Mobile Network Prefix (defined in [Mobility]) > > So, I think it's useless to define it here again in basic-support. that was deliberately added. I didnt want a normative reference to a draft which is not controlled by this WG. what is the status of this draft in the Seamoby WG? Vijay From exim@www1.ietf.org Mon Aug 11 13:01:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23052 for ; Mon, 11 Aug 2003 13:01:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mG2k-0003Wy-4w for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 13:01:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BH1Edv013569 for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 13:01:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mG2j-0003WZ-V4 for nemo-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 13:01:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23024 for ; Mon, 11 Aug 2003 13:01:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mG2e-0007Ca-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 13:01:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mG2e-0007CX-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 13:01:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mG2X-0003V3-Hu; Mon, 11 Aug 2003 13:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mG1a-0003U1-RH for nemo@optimus.ietf.org; Mon, 11 Aug 2003 13:00:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22968; Mon, 11 Aug 2003 12:59:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mG1Y-0007Bu-00; Mon, 11 Aug 2003 13:00:00 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19mG1X-0007Bh-00; Mon, 11 Aug 2003 12:59:59 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7BGxPT04669; Mon, 11 Aug 2003 09:59:25 -0700 X-mProtect: <200308111659> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdN6gMSi; Mon, 11 Aug 2003 09:59:24 PDT Message-ID: <3F37CB6C.3C9D9956@iprg.nokia.com> Date: Mon, 11 Aug 2003 09:59:24 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Thierry Ernst CC: nemo , seamoby@ietf.org Subject: Re: [nemo] NEMO Basic Support: About terminology References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have cc'ed Seamoby list. Thierry Ernst wrote: > > Dear all, > > draft-ietf-nemo-basic-support-pre01.txt > > Mobile Network Prefix > > The IPv6 prefix advertised in the Mobile Network > by one or more Mobile Routers. There could be multiple > prefixes in the Mobile Network. > > This is already defined in the terminology drafts (seamoby and NEMO): > > draft-ietf-seamoby-mobility-terminology-04.txt > > Mobile Network Prefix > > A bit string that consists of some number of initial bits of an > IP address which identifies the entire mobile network within the > Internet topology. All nodes in a mobile network necessarily have > an address named after this prefix. > > draft-ietf-neno-terminology-00.txt > > MNP > An acronym for Mobile Network Prefix (defined in [Mobility]) > > So, I think it's useless to define it here again in basic-support. that was deliberately added. I didnt want a normative reference to a draft which is not controlled by this WG. what is the status of this draft in the Seamoby WG? Vijay From nemo-admin@ietf.org Mon Aug 11 13:02:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23107 for ; Mon, 11 Aug 2003 13:02:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mG3V-0003eQ-Mf; Mon, 11 Aug 2003 13:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mG3O-0003eF-P7 for nemo@optimus.ietf.org; Mon, 11 Aug 2003 13:01:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23085 for ; Mon, 11 Aug 2003 13:01:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mG3M-0007D5-00 for nemo@ietf.org; Mon, 11 Aug 2003 13:01:53 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19mG3L-0007Ck-00 for nemo@ietf.org; Mon, 11 Aug 2003 13:01:51 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7BH1Hq06389; Mon, 11 Aug 2003 10:01:17 -0700 X-mProtect: <200308111701> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5FDb5W; Mon, 11 Aug 2003 10:01:15 PDT Message-ID: <3F37CBDC.CBA696D9@iprg.nokia.com> Date: Mon, 11 Aug 2003 10:01:16 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Thierry Ernst CC: nemo Subject: Re: [nemo] NEMO Basic Support: About terminology References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > > Besides this, I would also like to propose to add a term to distinguish > Mobile IPv6 BU and NEMO BU: PBU for "Prefix Binding Update". At some > point in time, it will allow to avoid confusion between the 2 protocols. in the implicit mode, the Binding Update does not contain any prefix information. also when a routing protocol is being run over the MR-HA tunnel, there is no prefix information in the Binding Update. so I am not sure it is correct to call the NEMO BU, Prefix Binding Update. Vijay From exim@www1.ietf.org Mon Aug 11 13:02:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23122 for ; Mon, 11 Aug 2003 13:02:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mG3X-0003fN-Fz for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 13:02:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BH23VK014087 for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 13:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mG3X-0003f8-B0 for nemo-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 13:02:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23089 for ; Mon, 11 Aug 2003 13:01:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mG3V-0007DB-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 13:02:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mG3U-0007D8-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 13:02:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mG3V-0003eQ-Mf; Mon, 11 Aug 2003 13:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mG3O-0003eF-P7 for nemo@optimus.ietf.org; Mon, 11 Aug 2003 13:01:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23085 for ; Mon, 11 Aug 2003 13:01:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mG3M-0007D5-00 for nemo@ietf.org; Mon, 11 Aug 2003 13:01:53 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19mG3L-0007Ck-00 for nemo@ietf.org; Mon, 11 Aug 2003 13:01:51 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7BH1Hq06389; Mon, 11 Aug 2003 10:01:17 -0700 X-mProtect: <200308111701> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5FDb5W; Mon, 11 Aug 2003 10:01:15 PDT Message-ID: <3F37CBDC.CBA696D9@iprg.nokia.com> Date: Mon, 11 Aug 2003 10:01:16 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Thierry Ernst CC: nemo Subject: Re: [nemo] NEMO Basic Support: About terminology References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > > Besides this, I would also like to propose to add a term to distinguish > Mobile IPv6 BU and NEMO BU: PBU for "Prefix Binding Update". At some > point in time, it will allow to avoid confusion between the 2 protocols. in the implicit mode, the Binding Update does not contain any prefix information. also when a routing protocol is being run over the MR-HA tunnel, there is no prefix information in the Binding Update. so I am not sure it is correct to call the NEMO BU, Prefix Binding Update. Vijay From nemo-admin@ietf.org Mon Aug 11 13:09:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23401 for ; Mon, 11 Aug 2003 13:09:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGAH-00043N-Sn; Mon, 11 Aug 2003 13:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mG9S-00041v-53 for nemo@optimus.ietf.org; Mon, 11 Aug 2003 13:08:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23254; Mon, 11 Aug 2003 13:08:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mG9Q-0007F3-00; Mon, 11 Aug 2003 13:08:08 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19mG9P-0007Eu-00; Mon, 11 Aug 2003 13:08:07 -0400 Message-ID: <025a01c3602b$26e46b70$9f6015ac@dclkempt40> From: "James Kempf" To: "Vijay Devarapalli" , "Thierry Ernst" Cc: "nemo" , References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> <3F37CB6C.3C9D9956@iprg.nokia.com> Subject: Re: [Seamoby] Re: [nemo] NEMO Basic Support: About terminology Date: Mon, 11 Aug 2003 10:08:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The draft is currently with the IESG, recommended to be published as Informational. According to Draft Tracker, the state is AD Evaluation. jak ----- Original Message ----- From: "Vijay Devarapalli" To: "Thierry Ernst" Cc: "nemo" ; Sent: Monday, August 11, 2003 9:59 AM Subject: [Seamoby] Re: [nemo] NEMO Basic Support: About terminology > I have cc'ed Seamoby list. > > Thierry Ernst wrote: > > > > Dear all, > > > > draft-ietf-nemo-basic-support-pre01.txt > > > > Mobile Network Prefix > > > > The IPv6 prefix advertised in the Mobile Network > > by one or more Mobile Routers. There could be multiple > > prefixes in the Mobile Network. > > > > This is already defined in the terminology drafts (seamoby and NEMO): > > > > draft-ietf-seamoby-mobility-terminology-04.txt > > > > Mobile Network Prefix > > > > A bit string that consists of some number of initial bits of an > > IP address which identifies the entire mobile network within the > > Internet topology. All nodes in a mobile network necessarily have > > an address named after this prefix. > > > > draft-ietf-neno-terminology-00.txt > > > > MNP > > An acronym for Mobile Network Prefix (defined in [Mobility]) > > > > So, I think it's useless to define it here again in basic-support. > > that was deliberately added. I didnt want a normative > reference to a draft which is not controlled by this > WG. what is the status of this draft in the Seamoby > WG? > > Vijay > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > From exim@www1.ietf.org Mon Aug 11 13:09:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23424 for ; Mon, 11 Aug 2003 13:09:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGAJ-00044I-8t for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 13:09:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BH93ka015634 for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 13:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGAJ-000445-48 for nemo-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 13:09:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23319 for ; Mon, 11 Aug 2003 13:08:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGAH-0007Gr-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 13:09:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mGAG-0007Go-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 13:09:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGAH-00043N-Sn; Mon, 11 Aug 2003 13:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mG9S-00041v-53 for nemo@optimus.ietf.org; Mon, 11 Aug 2003 13:08:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23254; Mon, 11 Aug 2003 13:08:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mG9Q-0007F3-00; Mon, 11 Aug 2003 13:08:08 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19mG9P-0007Eu-00; Mon, 11 Aug 2003 13:08:07 -0400 Message-ID: <025a01c3602b$26e46b70$9f6015ac@dclkempt40> From: "James Kempf" To: "Vijay Devarapalli" , "Thierry Ernst" Cc: "nemo" , References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> <3F37CB6C.3C9D9956@iprg.nokia.com> Subject: Re: [Seamoby] Re: [nemo] NEMO Basic Support: About terminology Date: Mon, 11 Aug 2003 10:08:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The draft is currently with the IESG, recommended to be published as Informational. According to Draft Tracker, the state is AD Evaluation. jak ----- Original Message ----- From: "Vijay Devarapalli" To: "Thierry Ernst" Cc: "nemo" ; Sent: Monday, August 11, 2003 9:59 AM Subject: [Seamoby] Re: [nemo] NEMO Basic Support: About terminology > I have cc'ed Seamoby list. > > Thierry Ernst wrote: > > > > Dear all, > > > > draft-ietf-nemo-basic-support-pre01.txt > > > > Mobile Network Prefix > > > > The IPv6 prefix advertised in the Mobile Network > > by one or more Mobile Routers. There could be multiple > > prefixes in the Mobile Network. > > > > This is already defined in the terminology drafts (seamoby and NEMO): > > > > draft-ietf-seamoby-mobility-terminology-04.txt > > > > Mobile Network Prefix > > > > A bit string that consists of some number of initial bits of an > > IP address which identifies the entire mobile network within the > > Internet topology. All nodes in a mobile network necessarily have > > an address named after this prefix. > > > > draft-ietf-neno-terminology-00.txt > > > > MNP > > An acronym for Mobile Network Prefix (defined in [Mobility]) > > > > So, I think it's useless to define it here again in basic-support. > > that was deliberately added. I didnt want a normative > reference to a draft which is not controlled by this > WG. what is the status of this draft in the Seamoby > WG? > > Vijay > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > From nemo-admin@ietf.org Mon Aug 11 13:12:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23876 for ; Mon, 11 Aug 2003 13:12:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGDB-0004H4-OQ; Mon, 11 Aug 2003 13:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGCS-0004Gq-9r for nemo@optimus.ietf.org; Mon, 11 Aug 2003 13:11:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23762 for ; Mon, 11 Aug 2003 13:11:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGCQ-0007NO-00 for nemo@ietf.org; Mon, 11 Aug 2003 13:11:14 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19mGCP-0007ME-00 for nemo@ietf.org; Mon, 11 Aug 2003 13:11:13 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7BHAFJ16865; Mon, 11 Aug 2003 10:10:15 -0700 X-mProtect: <200308111710> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdUEp8qz; Mon, 11 Aug 2003 10:10:13 PDT Message-ID: <3F37CDF6.C5890294@iprg.nokia.com> Date: Mon, 11 Aug 2003 10:10:14 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: Alexandru Petrescu , "Pascal Thubert (pthubert)" , Jongkeun Na , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F329FBF.EE0F3B1C@iprg.nokia.com> <3F336381.8020601@motorola.com> <3F33E42D.FF460E5D@iprg.nokia.com> <3F37A20B.50003@nal.motlabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > Vijay Devarapalli wrote: > > I prefer a short spec on this. or do you think it could > > go into a appendix for the basic support draft? > > Depends on what members want. > > My oppinion is that this is like part of initial steps in the RO work, > not basic work. all right then. we wont add anything to the NEMO Basic support spec. Vijay From exim@www1.ietf.org Mon Aug 11 13:12:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23891 for ; Mon, 11 Aug 2003 13:12:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGDE-0004JI-Pw for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 13:12:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BHC4Fm016562 for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 13:12:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGDE-0004J3-Jk for nemo-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 13:12:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23852 for ; Mon, 11 Aug 2003 13:11:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGDC-0007PT-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 13:12:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mGDC-0007PQ-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 13:12:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGDB-0004H4-OQ; Mon, 11 Aug 2003 13:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGCS-0004Gq-9r for nemo@optimus.ietf.org; Mon, 11 Aug 2003 13:11:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23762 for ; Mon, 11 Aug 2003 13:11:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGCQ-0007NO-00 for nemo@ietf.org; Mon, 11 Aug 2003 13:11:14 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19mGCP-0007ME-00 for nemo@ietf.org; Mon, 11 Aug 2003 13:11:13 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7BHAFJ16865; Mon, 11 Aug 2003 10:10:15 -0700 X-mProtect: <200308111710> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdUEp8qz; Mon, 11 Aug 2003 10:10:13 PDT Message-ID: <3F37CDF6.C5890294@iprg.nokia.com> Date: Mon, 11 Aug 2003 10:10:14 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: Alexandru Petrescu , "Pascal Thubert (pthubert)" , Jongkeun Na , nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F329FBF.EE0F3B1C@iprg.nokia.com> <3F336381.8020601@motorola.com> <3F33E42D.FF460E5D@iprg.nokia.com> <3F37A20B.50003@nal.motlabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > Vijay Devarapalli wrote: > > I prefer a short spec on this. or do you think it could > > go into a appendix for the basic support draft? > > Depends on what members want. > > My oppinion is that this is like part of initial steps in the RO work, > not basic work. all right then. we wont add anything to the NEMO Basic support spec. Vijay From nemo-admin@ietf.org Mon Aug 11 13:21:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24646 for ; Mon, 11 Aug 2003 13:21:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGLu-0004j9-Hb; Mon, 11 Aug 2003 13:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGLa-0004hq-KF for nemo@optimus.ietf.org; Mon, 11 Aug 2003 13:20:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24598; Mon, 11 Aug 2003 13:20:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGLY-0007fK-00; Mon, 11 Aug 2003 13:20:40 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19mGLX-0007eE-00; Mon, 11 Aug 2003 13:20:39 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7BHK5429197; Mon, 11 Aug 2003 10:20:05 -0700 X-mProtect: <200308111720> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd25SKBS; Mon, 11 Aug 2003 10:20:03 PDT Message-ID: <3F37D044.F2099D78@iprg.nokia.com> Date: Mon, 11 Aug 2003 10:20:04 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Thierry Ernst , nemo , seamoby@ietf.org Subject: Re: [Seamoby] Re: [nemo] NEMO Basic Support: About terminology References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> <3F37CB6C.3C9D9956@iprg.nokia.com> <025a01c3602b$26e46b70$9f6015ac@dclkempt40> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I should have checked the ID tracker before sending the mail. sorry. James Kempf wrote: > > The draft is currently with the IESG, recommended to be published as > Informational. According to Draft Tracker, the state is AD Evaluation. great. that means we can have a reference to this draft in the NEMO drafts. Vijay > > jak > > ----- Original Message ----- > From: "Vijay Devarapalli" > To: "Thierry Ernst" > Cc: "nemo" ; > Sent: Monday, August 11, 2003 9:59 AM > Subject: [Seamoby] Re: [nemo] NEMO Basic Support: About terminology > > > I have cc'ed Seamoby list. > > > > Thierry Ernst wrote: > > > > > > Dear all, > > > > > > draft-ietf-nemo-basic-support-pre01.txt > > > > > > Mobile Network Prefix > > > > > > The IPv6 prefix advertised in the Mobile Network > > > by one or more Mobile Routers. There could be multiple > > > prefixes in the Mobile Network. > > > > > > This is already defined in the terminology drafts (seamoby and NEMO): > > > > > > draft-ietf-seamoby-mobility-terminology-04.txt > > > > > > Mobile Network Prefix > > > > > > A bit string that consists of some number of initial bits of an > > > IP address which identifies the entire mobile network within the > > > Internet topology. All nodes in a mobile network necessarily have > > > an address named after this prefix. > > > > > > draft-ietf-neno-terminology-00.txt > > > > > > MNP > > > An acronym for Mobile Network Prefix (defined in [Mobility]) > > > > > > So, I think it's useless to define it here again in basic-support. > > > > that was deliberately added. I didnt want a normative > > reference to a draft which is not controlled by this > > WG. what is the status of this draft in the Seamoby > > WG? > > > > Vijay > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > From exim@www1.ietf.org Mon Aug 11 13:21:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24661 for ; Mon, 11 Aug 2003 13:21:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGLw-0004k2-92 for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 13:21:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BHL4tR018224 for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 13:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGLw-0004jr-4T for nemo-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 13:21:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24633 for ; Mon, 11 Aug 2003 13:20:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGLu-0007fa-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 13:21:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mGLt-0007fX-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 13:21:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGLu-0004j9-Hb; Mon, 11 Aug 2003 13:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGLa-0004hq-KF for nemo@optimus.ietf.org; Mon, 11 Aug 2003 13:20:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24598; Mon, 11 Aug 2003 13:20:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGLY-0007fK-00; Mon, 11 Aug 2003 13:20:40 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19mGLX-0007eE-00; Mon, 11 Aug 2003 13:20:39 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7BHK5429197; Mon, 11 Aug 2003 10:20:05 -0700 X-mProtect: <200308111720> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd25SKBS; Mon, 11 Aug 2003 10:20:03 PDT Message-ID: <3F37D044.F2099D78@iprg.nokia.com> Date: Mon, 11 Aug 2003 10:20:04 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Thierry Ernst , nemo , seamoby@ietf.org Subject: Re: [Seamoby] Re: [nemo] NEMO Basic Support: About terminology References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> <3F37CB6C.3C9D9956@iprg.nokia.com> <025a01c3602b$26e46b70$9f6015ac@dclkempt40> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I should have checked the ID tracker before sending the mail. sorry. James Kempf wrote: > > The draft is currently with the IESG, recommended to be published as > Informational. According to Draft Tracker, the state is AD Evaluation. great. that means we can have a reference to this draft in the NEMO drafts. Vijay > > jak > > ----- Original Message ----- > From: "Vijay Devarapalli" > To: "Thierry Ernst" > Cc: "nemo" ; > Sent: Monday, August 11, 2003 9:59 AM > Subject: [Seamoby] Re: [nemo] NEMO Basic Support: About terminology > > > I have cc'ed Seamoby list. > > > > Thierry Ernst wrote: > > > > > > Dear all, > > > > > > draft-ietf-nemo-basic-support-pre01.txt > > > > > > Mobile Network Prefix > > > > > > The IPv6 prefix advertised in the Mobile Network > > > by one or more Mobile Routers. There could be multiple > > > prefixes in the Mobile Network. > > > > > > This is already defined in the terminology drafts (seamoby and NEMO): > > > > > > draft-ietf-seamoby-mobility-terminology-04.txt > > > > > > Mobile Network Prefix > > > > > > A bit string that consists of some number of initial bits of an > > > IP address which identifies the entire mobile network within the > > > Internet topology. All nodes in a mobile network necessarily have > > > an address named after this prefix. > > > > > > draft-ietf-neno-terminology-00.txt > > > > > > MNP > > > An acronym for Mobile Network Prefix (defined in [Mobility]) > > > > > > So, I think it's useless to define it here again in basic-support. > > > > that was deliberately added. I didnt want a normative > > reference to a draft which is not controlled by this > > WG. what is the status of this draft in the Seamoby > > WG? > > > > Vijay > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > From nemo-admin@ietf.org Mon Aug 11 21:17:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12664 for ; Mon, 11 Aug 2003 21:17:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mNmX-0003Z5-Qj; Mon, 11 Aug 2003 21:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mNls-0003Yp-E6 for nemo@optimus.ietf.org; Mon, 11 Aug 2003 21:16:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12622 for ; Mon, 11 Aug 2003 21:16:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mNlp-0003YN-00 for nemo@ietf.org; Mon, 11 Aug 2003 21:16:17 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19mNlo-0003Y8-00 for nemo@ietf.org; Mon, 11 Aug 2003 21:16:16 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 8A3EE5D098 for ; Tue, 12 Aug 2003 10:15:40 +0900 (JST) Date: Tue, 12 Aug 2003 10:12:01 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] NEMO Basic Support: About terminology Message-Id: <20030812101201.0f34fbf2.ernst@sfc.wide.ad.jp> In-Reply-To: <3F37CBDC.CBA696D9@iprg.nokia.com> References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> <3F37CBDC.CBA696D9@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Vijay, > > Besides this, I would also like to propose to add a term to distinguish > > Mobile IPv6 BU and NEMO BU: PBU for "Prefix Binding Update". At some > > point in time, it will allow to avoid confusion between the 2 protocols. > > in the implicit mode, the Binding Update does not contain > any prefix information. also when a routing protocol is > being run over the MR-HA tunnel, there is no prefix > information in the Binding Update. so I am not sure it is > correct to call the NEMO BU, Prefix Binding Update. Wether is it implicit or explicit, it's a BU to instruct the HA to redirect packets for an entire BU, so it could be called PBU. But if you don't like PBU, I still recommend we find a term to distinguish MIPv6 BU from NEMO BU (NBU ?). Thierry. From exim@www1.ietf.org Mon Aug 11 21:17:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12679 for ; Mon, 11 Aug 2003 21:17:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mNmd-0003a7-En for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 21:17:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7C1H7mM013762 for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 21:17:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mNmd-0003Zt-A4 for nemo-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 21:17:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12647 for ; Mon, 11 Aug 2003 21:17:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mNma-0003Yk-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 21:17:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mNma-0003Yh-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 21:17:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mNmX-0003Z5-Qj; Mon, 11 Aug 2003 21:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mNls-0003Yp-E6 for nemo@optimus.ietf.org; Mon, 11 Aug 2003 21:16:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12622 for ; Mon, 11 Aug 2003 21:16:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mNlp-0003YN-00 for nemo@ietf.org; Mon, 11 Aug 2003 21:16:17 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19mNlo-0003Y8-00 for nemo@ietf.org; Mon, 11 Aug 2003 21:16:16 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 8A3EE5D098 for ; Tue, 12 Aug 2003 10:15:40 +0900 (JST) Date: Tue, 12 Aug 2003 10:12:01 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] NEMO Basic Support: About terminology Message-Id: <20030812101201.0f34fbf2.ernst@sfc.wide.ad.jp> In-Reply-To: <3F37CBDC.CBA696D9@iprg.nokia.com> References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> <3F37CBDC.CBA696D9@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Vijay, > > Besides this, I would also like to propose to add a term to distinguish > > Mobile IPv6 BU and NEMO BU: PBU for "Prefix Binding Update". At some > > point in time, it will allow to avoid confusion between the 2 protocols. > > in the implicit mode, the Binding Update does not contain > any prefix information. also when a routing protocol is > being run over the MR-HA tunnel, there is no prefix > information in the Binding Update. so I am not sure it is > correct to call the NEMO BU, Prefix Binding Update. Wether is it implicit or explicit, it's a BU to instruct the HA to redirect packets for an entire BU, so it could be called PBU. But if you don't like PBU, I still recommend we find a term to distinguish MIPv6 BU from NEMO BU (NBU ?). Thierry. From nemo-admin@ietf.org Mon Aug 11 21:21:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12772 for ; Mon, 11 Aug 2003 21:21:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mNqP-0003hj-Fa; Mon, 11 Aug 2003 21:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mNpW-0003hH-GF for nemo@optimus.ietf.org; Mon, 11 Aug 2003 21:20:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12751 for ; Mon, 11 Aug 2003 21:20:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mNpT-0003a4-00 for nemo@ietf.org; Mon, 11 Aug 2003 21:20:03 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19mNpT-0003Zv-00 for nemo@ietf.org; Mon, 11 Aug 2003 21:20:03 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 84E155D098 for ; Tue, 12 Aug 2003 10:19:33 +0900 (JST) Date: Tue, 12 Aug 2003 10:15:54 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... Message-Id: <20030812101554.464fbd66.ernst@sfc.wide.ad.jp> In-Reply-To: <3F37CDF6.C5890294@iprg.nokia.com> References: <3F329FBF.EE0F3B1C@iprg.nokia.com> <3F336381.8020601@motorola.com> <3F33E42D.FF460E5D@iprg.nokia.com> <3F37A20B.50003@nal.motlabs.com> <3F37CDF6.C5890294@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Alexandru Petrescu wrote: > > > > Vijay Devarapalli wrote: > > > I prefer a short spec on this. or do you think it could > > > go into a appendix for the basic support draft? > > > > Depends on what members want. > > > > My oppinion is that this is like part of initial steps in the RO work, > > not basic work. > > all right then. we wont add anything to the NEMO Basic > support spec. I tend to agree. So, would be good to have a separate specification for that. The question is shall we work on it right now (if someone volunteer) ? Thierry From exim@www1.ietf.org Mon Aug 11 21:21:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12788 for ; Mon, 11 Aug 2003 21:21:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mNqR-0003k6-2L for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 21:21:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7C1L3Pd014377 for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 21:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mNqQ-0003jm-SM for nemo-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 21:21:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12760 for ; Mon, 11 Aug 2003 21:20:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mNqO-0003aH-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 21:21:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mNqN-0003aE-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 21:20:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mNqP-0003hj-Fa; Mon, 11 Aug 2003 21:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mNpW-0003hH-GF for nemo@optimus.ietf.org; Mon, 11 Aug 2003 21:20:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12751 for ; Mon, 11 Aug 2003 21:20:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mNpT-0003a4-00 for nemo@ietf.org; Mon, 11 Aug 2003 21:20:03 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19mNpT-0003Zv-00 for nemo@ietf.org; Mon, 11 Aug 2003 21:20:03 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 84E155D098 for ; Tue, 12 Aug 2003 10:19:33 +0900 (JST) Date: Tue, 12 Aug 2003 10:15:54 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... Message-Id: <20030812101554.464fbd66.ernst@sfc.wide.ad.jp> In-Reply-To: <3F37CDF6.C5890294@iprg.nokia.com> References: <3F329FBF.EE0F3B1C@iprg.nokia.com> <3F336381.8020601@motorola.com> <3F33E42D.FF460E5D@iprg.nokia.com> <3F37A20B.50003@nal.motlabs.com> <3F37CDF6.C5890294@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Alexandru Petrescu wrote: > > > > Vijay Devarapalli wrote: > > > I prefer a short spec on this. or do you think it could > > > go into a appendix for the basic support draft? > > > > Depends on what members want. > > > > My oppinion is that this is like part of initial steps in the RO work, > > not basic work. > > all right then. we wont add anything to the NEMO Basic > support spec. I tend to agree. So, would be good to have a separate specification for that. The question is shall we work on it right now (if someone volunteer) ? Thierry From nemo-admin@ietf.org Mon Aug 11 22:28:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14181 for ; Mon, 11 Aug 2003 22:28:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mOtF-0005ta-Ay; Mon, 11 Aug 2003 22:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mOsb-0005sf-Pn for nemo@optimus.ietf.org; Mon, 11 Aug 2003 22:27:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14153 for ; Mon, 11 Aug 2003 22:27:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mOsY-0003wN-00 for nemo@ietf.org; Mon, 11 Aug 2003 22:27:18 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19mOsX-0003wK-00 for nemo@ietf.org; Mon, 11 Aug 2003 22:27:17 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7C2Qki07874; Mon, 11 Aug 2003 19:26:46 -0700 X-mProtect: <200308120226> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxb5Eay; Mon, 11 Aug 2003 19:26:44 PDT Message-ID: <3F385064.1D07D41@iprg.nokia.com> Date: Mon, 11 Aug 2003 19:26:44 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Thierry Ernst CC: nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F329FBF.EE0F3B1C@iprg.nokia.com> <3F336381.8020601@motorola.com> <3F33E42D.FF460E5D@iprg.nokia.com> <3F37A20B.50003@nal.motlabs.com> <3F37CDF6.C5890294@iprg.nokia.com> <20030812101554.464fbd66.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > > > Alexandru Petrescu wrote: > > > > > > Vijay Devarapalli wrote: > > > > I prefer a short spec on this. or do you think it could > > > > go into a appendix for the basic support draft? > > > > > > Depends on what members want. > > > > > > My oppinion is that this is like part of initial steps in the RO work, > > > not basic work. > > > > all right then. we wont add anything to the NEMO Basic > > support spec. > > I tend to agree. So, would be good to have a separate specification for > that. The question is shall we work on it right now (if someone > volunteer) ? I can write up something short based on 1. VMN attaches to Mobile Network and acquires a CoA from MNP. 2. if it wants to start a session with an MNN, and if the session is a short lived one, uses CoA as source address. 3. if the session is a long lived one, uses MIPv6 Route Optimization 4. performs Return Routability with MNN 5. if MNN does not support Route Optimization, it sends ICMP error message (from MIPv6 spec). 6. VMN reverse tunnels through its Home Agent 7. if MR is not connected to a network, both step 5 and 6 will fail. then VMN defaults to using CoA. if the VMN moves in the middle of the session, the session just breaks. hard luck. since the MR is disconnected, MNN cant be reached anyway. Vijay From exim@www1.ietf.org Mon Aug 11 22:28:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14196 for ; Mon, 11 Aug 2003 22:28:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mOtJ-0005uY-1E for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 22:28:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7C2S5ee022716 for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 22:28:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mOtI-0005uJ-TP for nemo-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 22:28:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14173 for ; Mon, 11 Aug 2003 22:27:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mOtF-0003wU-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 22:28:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mOtF-0003wR-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 22:28:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mOtF-0005ta-Ay; Mon, 11 Aug 2003 22:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mOsb-0005sf-Pn for nemo@optimus.ietf.org; Mon, 11 Aug 2003 22:27:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14153 for ; Mon, 11 Aug 2003 22:27:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mOsY-0003wN-00 for nemo@ietf.org; Mon, 11 Aug 2003 22:27:18 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19mOsX-0003wK-00 for nemo@ietf.org; Mon, 11 Aug 2003 22:27:17 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7C2Qki07874; Mon, 11 Aug 2003 19:26:46 -0700 X-mProtect: <200308120226> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxb5Eay; Mon, 11 Aug 2003 19:26:44 PDT Message-ID: <3F385064.1D07D41@iprg.nokia.com> Date: Mon, 11 Aug 2003 19:26:44 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Thierry Ernst CC: nemo@ietf.org Subject: Re: [nemo] crossover tunnel.... References: <3F329FBF.EE0F3B1C@iprg.nokia.com> <3F336381.8020601@motorola.com> <3F33E42D.FF460E5D@iprg.nokia.com> <3F37A20B.50003@nal.motlabs.com> <3F37CDF6.C5890294@iprg.nokia.com> <20030812101554.464fbd66.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > > > Alexandru Petrescu wrote: > > > > > > Vijay Devarapalli wrote: > > > > I prefer a short spec on this. or do you think it could > > > > go into a appendix for the basic support draft? > > > > > > Depends on what members want. > > > > > > My oppinion is that this is like part of initial steps in the RO work, > > > not basic work. > > > > all right then. we wont add anything to the NEMO Basic > > support spec. > > I tend to agree. So, would be good to have a separate specification for > that. The question is shall we work on it right now (if someone > volunteer) ? I can write up something short based on 1. VMN attaches to Mobile Network and acquires a CoA from MNP. 2. if it wants to start a session with an MNN, and if the session is a short lived one, uses CoA as source address. 3. if the session is a long lived one, uses MIPv6 Route Optimization 4. performs Return Routability with MNN 5. if MNN does not support Route Optimization, it sends ICMP error message (from MIPv6 spec). 6. VMN reverse tunnels through its Home Agent 7. if MR is not connected to a network, both step 5 and 6 will fail. then VMN defaults to using CoA. if the VMN moves in the middle of the session, the session just breaks. hard luck. since the MR is disconnected, MNN cant be reached anyway. Vijay From nemo-admin@ietf.org Mon Aug 11 22:37:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14335 for ; Mon, 11 Aug 2003 22:37:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mP1x-00069C-I0; Mon, 11 Aug 2003 22:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mP13-00068Q-Pz for nemo@optimus.ietf.org; Mon, 11 Aug 2003 22:36:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14328 for ; Mon, 11 Aug 2003 22:35:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mP10-0003yh-00 for nemo@ietf.org; Mon, 11 Aug 2003 22:36:02 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19mP0z-0003yT-00 for nemo@ietf.org; Mon, 11 Aug 2003 22:36:01 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7C2ZUW13504; Mon, 11 Aug 2003 19:35:30 -0700 X-mProtect: <200308120235> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpWXnUv; Mon, 11 Aug 2003 19:35:29 PDT Message-ID: <3F385271.C7E9283C@iprg.nokia.com> Date: Mon, 11 Aug 2003 19:35:29 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Thierry Ernst CC: nemo@ietf.org Subject: Re: [nemo] NEMO Basic Support: About terminology References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> <3F37CBDC.CBA696D9@iprg.nokia.com> <20030812101201.0f34fbf2.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > > > in the implicit mode, the Binding Update does not contain > > any prefix information. also when a routing protocol is > > being run over the MR-HA tunnel, there is no prefix > > information in the Binding Update. so I am not sure it is > > correct to call the NEMO BU, Prefix Binding Update. > > Wether is it implicit or explicit, it's a BU to instruct the HA to > redirect packets for an entire BU, so it could be called PBU. But if you > don't like PBU, I still recommend we find a term to distinguish > MIPv6 BU from NEMO BU (NBU ?). why? since we are not defining a new Mobility Message type value for the Nemo BU, why would you want two different names for the same Mobility Header message? there is the 'R' flag in the BU to distinguish Nemo BU. Vijay From exim@www1.ietf.org Mon Aug 11 22:37:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14350 for ; Mon, 11 Aug 2003 22:37:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mP1z-0006Ak-4O for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 22:37:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7C2b37h023715 for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 22:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mP1y-0006AQ-T8 for nemo-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 22:37:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14332 for ; Mon, 11 Aug 2003 22:36:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mP1v-0003yn-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 22:36:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mP1v-0003yk-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 22:36:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mP1x-00069C-I0; Mon, 11 Aug 2003 22:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mP13-00068Q-Pz for nemo@optimus.ietf.org; Mon, 11 Aug 2003 22:36:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14328 for ; Mon, 11 Aug 2003 22:35:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mP10-0003yh-00 for nemo@ietf.org; Mon, 11 Aug 2003 22:36:02 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19mP0z-0003yT-00 for nemo@ietf.org; Mon, 11 Aug 2003 22:36:01 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7C2ZUW13504; Mon, 11 Aug 2003 19:35:30 -0700 X-mProtect: <200308120235> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpWXnUv; Mon, 11 Aug 2003 19:35:29 PDT Message-ID: <3F385271.C7E9283C@iprg.nokia.com> Date: Mon, 11 Aug 2003 19:35:29 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Thierry Ernst CC: nemo@ietf.org Subject: Re: [nemo] NEMO Basic Support: About terminology References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> <3F37CBDC.CBA696D9@iprg.nokia.com> <20030812101201.0f34fbf2.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > > > in the implicit mode, the Binding Update does not contain > > any prefix information. also when a routing protocol is > > being run over the MR-HA tunnel, there is no prefix > > information in the Binding Update. so I am not sure it is > > correct to call the NEMO BU, Prefix Binding Update. > > Wether is it implicit or explicit, it's a BU to instruct the HA to > redirect packets for an entire BU, so it could be called PBU. But if you > don't like PBU, I still recommend we find a term to distinguish > MIPv6 BU from NEMO BU (NBU ?). why? since we are not defining a new Mobility Message type value for the Nemo BU, why would you want two different names for the same Mobility Header message? there is the 'R' flag in the BU to distinguish Nemo BU. Vijay From nemo-admin@ietf.org Mon Aug 11 22:56:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14639 for ; Mon, 11 Aug 2003 22:56:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mPKM-0006jL-Jo; Mon, 11 Aug 2003 22:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mPK6-0006j0-Uy for nemo@optimus.ietf.org; Mon, 11 Aug 2003 22:55:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14613 for ; Mon, 11 Aug 2003 22:55:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mPK3-000421-00 for nemo@ietf.org; Mon, 11 Aug 2003 22:55:43 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19mPK2-00041s-00 for nemo@ietf.org; Mon, 11 Aug 2003 22:55:42 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id A62675D0A6 for ; Tue, 12 Aug 2003 11:55:10 +0900 (JST) Date: Tue, 12 Aug 2003 11:51:31 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] NEMO Basic Support: About terminology Message-Id: <20030812115131.7719fde1.ernst@sfc.wide.ad.jp> In-Reply-To: <3F385271.C7E9283C@iprg.nokia.com> References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> <3F37CBDC.CBA696D9@iprg.nokia.com> <20030812101201.0f34fbf2.ernst@sfc.wide.ad.jp> <3F385271.C7E9283C@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > > in the implicit mode, the Binding Update does not contain > > > any prefix information. also when a routing protocol is > > > being run over the MR-HA tunnel, there is no prefix > > > information in the Binding Update. so I am not sure it is > > > correct to call the NEMO BU, Prefix Binding Update. > > > > Wether is it implicit or explicit, it's a BU to instruct the HA to > > redirect packets for an entire BU, so it could be called PBU. But if you > > don't like PBU, I still recommend we find a term to distinguish > > MIPv6 BU from NEMO BU (NBU ?). > > why? since we are not defining a new Mobility Message type > value for the Nemo BU, why would you want two different > names for the same Mobility Header message? > > there is the 'R' flag in the BU to distinguish Nemo BU. To avoid the confusion about what we are speaking about when we say "BU" [when will be talking about mobility management for the VMN and mobility management for the MR. Also, when the MR is acting as a host vs as a router]. It's better to define the term now so that people get the habbit to use it. Thierry From exim@www1.ietf.org Mon Aug 11 22:56:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14654 for ; Mon, 11 Aug 2003 22:56:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mPKP-0006kU-4Y for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 22:56:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7C2u5CZ025936 for nemo-archive@odin.ietf.org; Mon, 11 Aug 2003 22:56:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mPKO-0006kF-VJ for nemo-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 22:56:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14633 for ; Mon, 11 Aug 2003 22:55:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mPKL-00042U-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 22:56:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mPKL-00042R-00 for nemo-web-archive@ietf.org; Mon, 11 Aug 2003 22:56:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mPKM-0006jL-Jo; Mon, 11 Aug 2003 22:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mPK6-0006j0-Uy for nemo@optimus.ietf.org; Mon, 11 Aug 2003 22:55:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14613 for ; Mon, 11 Aug 2003 22:55:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mPK3-000421-00 for nemo@ietf.org; Mon, 11 Aug 2003 22:55:43 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19mPK2-00041s-00 for nemo@ietf.org; Mon, 11 Aug 2003 22:55:42 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id A62675D0A6 for ; Tue, 12 Aug 2003 11:55:10 +0900 (JST) Date: Tue, 12 Aug 2003 11:51:31 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] NEMO Basic Support: About terminology Message-Id: <20030812115131.7719fde1.ernst@sfc.wide.ad.jp> In-Reply-To: <3F385271.C7E9283C@iprg.nokia.com> References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> <3F37CBDC.CBA696D9@iprg.nokia.com> <20030812101201.0f34fbf2.ernst@sfc.wide.ad.jp> <3F385271.C7E9283C@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > in the implicit mode, the Binding Update does not contain > > > any prefix information. also when a routing protocol is > > > being run over the MR-HA tunnel, there is no prefix > > > information in the Binding Update. so I am not sure it is > > > correct to call the NEMO BU, Prefix Binding Update. > > > > Wether is it implicit or explicit, it's a BU to instruct the HA to > > redirect packets for an entire BU, so it could be called PBU. But if you > > don't like PBU, I still recommend we find a term to distinguish > > MIPv6 BU from NEMO BU (NBU ?). > > why? since we are not defining a new Mobility Message type > value for the Nemo BU, why would you want two different > names for the same Mobility Header message? > > there is the 'R' flag in the BU to distinguish Nemo BU. To avoid the confusion about what we are speaking about when we say "BU" [when will be talking about mobility management for the VMN and mobility management for the MR. Also, when the MR is acting as a host vs as a router]. It's better to define the term now so that people get the habbit to use it. Thierry From nemo-admin@ietf.org Tue Aug 12 04:50:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05404 for ; Tue, 12 Aug 2003 04:50:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mUqx-0002wI-Fc; Tue, 12 Aug 2003 04:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mUqU-0002vE-T0 for nemo@optimus.ietf.org; Tue, 12 Aug 2003 04:49:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05354 for ; Tue, 12 Aug 2003 04:49:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mUqR-0006Fz-00 for nemo@ietf.org; Tue, 12 Aug 2003 04:49:31 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19mUqR-0006Fq-00 for nemo@ietf.org; Tue, 12 Aug 2003 04:49:31 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h7C8nQfP027388; Tue, 12 Aug 2003 01:49:26 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h7C8nMI2020679; Tue, 12 Aug 2003 03:49:24 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id D9E332EC86; Tue, 12 Aug 2003 10:49:21 +0200 (CEST) Message-ID: <3F38AA11.5080305@nal.motlabs.com> Date: Tue, 12 Aug 2003 10:49:21 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: nemo@ietf.org Subject: Re: [nemo] NEMO Basic Support: About terminology References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> <3F37CBDC.CBA696D9@iprg.nokia.com> <20030812101201.0f34fbf2.ernst@sfc.wide.ad.jp> <3F385271.C7E9283C@iprg.nokia.com> <20030812115131.7719fde1.ernst@sfc.wide.ad.jp> In-Reply-To: <20030812115131.7719fde1.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thierry Ernst wrote: >>>> in the implicit mode, the Binding Update does not contain any >>>> prefix information. also when a routing protocol is being run >>>> over the MR-HA tunnel, there is no prefix information in the >>>> Binding Update. so I am not sure it is correct to call the NEMO >>>> BU, Prefix Binding Update. >>> >>> Wether is it implicit or explicit, it's a BU to instruct the HA >>> to redirect packets for an entire BU, so it could be called PBU. >>> But if you don't like PBU, I still recommend we find a term to >>> distinguish MIPv6 BU from NEMO BU (NBU ?). >> >> why? since we are not defining a new Mobility Message type value >> for the Nemo BU, why would you want two different names for the >> same Mobility Header message? >> >> there is the 'R' flag in the BU to distinguish Nemo BU. > > > To avoid the confusion about what we are speaking about when we say > "BU" [when will be talking about mobility management for the VMN and > mobility management for the MR. Also, when the MR is acting as a > host vs as a router]. It's better to define the term now so that > people get the habbit to use it. If someone absolutely needs to distinguish a NEMO BU from a non-NEMO BU then I would suggest R-BU (instead of PBU) simply because PBU does not cover implicit mode, it explicitely covers explicit modes, and R-BU covers all three modes. Alternatively, we can talk about: IBU (implicit mode BU), ENBU (explicit network BU) or EPLBU (explicit prefix length BU). Or EBU (explicit BU) that covers both ENBU and EPLBU... Alex GBU From exim@www1.ietf.org Tue Aug 12 04:50:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05419 for ; Tue, 12 Aug 2003 04:50:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mUr6-0002xb-2T for nemo-archive@odin.ietf.org; Tue, 12 Aug 2003 04:50:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7C8oBxZ011378 for nemo-archive@odin.ietf.org; Tue, 12 Aug 2003 04:50:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mUr4-0002xN-F1 for nemo-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 04:50:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05396 for ; Tue, 12 Aug 2003 04:50:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mUr1-0006Gp-00 for nemo-web-archive@ietf.org; Tue, 12 Aug 2003 04:50:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mUr0-0006Gl-00 for nemo-web-archive@ietf.org; Tue, 12 Aug 2003 04:50:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mUqx-0002wI-Fc; Tue, 12 Aug 2003 04:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mUqU-0002vE-T0 for nemo@optimus.ietf.org; Tue, 12 Aug 2003 04:49:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05354 for ; Tue, 12 Aug 2003 04:49:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mUqR-0006Fz-00 for nemo@ietf.org; Tue, 12 Aug 2003 04:49:31 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19mUqR-0006Fq-00 for nemo@ietf.org; Tue, 12 Aug 2003 04:49:31 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h7C8nQfP027388; Tue, 12 Aug 2003 01:49:26 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h7C8nMI2020679; Tue, 12 Aug 2003 03:49:24 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id D9E332EC86; Tue, 12 Aug 2003 10:49:21 +0200 (CEST) Message-ID: <3F38AA11.5080305@nal.motlabs.com> Date: Tue, 12 Aug 2003 10:49:21 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: nemo@ietf.org Subject: Re: [nemo] NEMO Basic Support: About terminology References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> <3F37CBDC.CBA696D9@iprg.nokia.com> <20030812101201.0f34fbf2.ernst@sfc.wide.ad.jp> <3F385271.C7E9283C@iprg.nokia.com> <20030812115131.7719fde1.ernst@sfc.wide.ad.jp> In-Reply-To: <20030812115131.7719fde1.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thierry Ernst wrote: >>>> in the implicit mode, the Binding Update does not contain any >>>> prefix information. also when a routing protocol is being run >>>> over the MR-HA tunnel, there is no prefix information in the >>>> Binding Update. so I am not sure it is correct to call the NEMO >>>> BU, Prefix Binding Update. >>> >>> Wether is it implicit or explicit, it's a BU to instruct the HA >>> to redirect packets for an entire BU, so it could be called PBU. >>> But if you don't like PBU, I still recommend we find a term to >>> distinguish MIPv6 BU from NEMO BU (NBU ?). >> >> why? since we are not defining a new Mobility Message type value >> for the Nemo BU, why would you want two different names for the >> same Mobility Header message? >> >> there is the 'R' flag in the BU to distinguish Nemo BU. > > > To avoid the confusion about what we are speaking about when we say > "BU" [when will be talking about mobility management for the VMN and > mobility management for the MR. Also, when the MR is acting as a > host vs as a router]. It's better to define the term now so that > people get the habbit to use it. If someone absolutely needs to distinguish a NEMO BU from a non-NEMO BU then I would suggest R-BU (instead of PBU) simply because PBU does not cover implicit mode, it explicitely covers explicit modes, and R-BU covers all three modes. Alternatively, we can talk about: IBU (implicit mode BU), ENBU (explicit network BU) or EPLBU (explicit prefix length BU). Or EBU (explicit BU) that covers both ENBU and EPLBU... Alex GBU From nemo-admin@ietf.org Tue Aug 12 13:26:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22103 for ; Tue, 12 Aug 2003 13:26:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcuI-0003dx-0D; Tue, 12 Aug 2003 13:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcu8-0003dk-FO for nemo@optimus.ietf.org; Tue, 12 Aug 2003 13:25:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22086 for ; Tue, 12 Aug 2003 13:25:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mcu6-0002SB-00 for nemo@ietf.org; Tue, 12 Aug 2003 13:25:50 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19mcu5-0002Rs-00 for nemo@ietf.org; Tue, 12 Aug 2003 13:25:49 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7CHP5k15984; Tue, 12 Aug 2003 10:25:05 -0700 X-mProtect: <200308121725> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdwDl6I7; Tue, 12 Aug 2003 10:25:03 PDT Message-ID: <3F3922F0.DCA465D9@iprg.nokia.com> Date: Tue, 12 Aug 2003 10:25:04 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Thierry Ernst CC: Alexandru Petrescu , nemo@ietf.org Subject: Re: [nemo] NEMO Basic Support: About terminology References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> <3F37CBDC.CBA696D9@iprg.nokia.com> <20030812101201.0f34fbf2.ernst@sfc.wide.ad.jp> <3F385271.C7E9283C@iprg.nokia.com> <2003081211513 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I prefer to continue with the term Binding Update. I dont see the need to call it by a different name, especially when it is the same Mobility Header message type. and I dont see anybody confused currently :) Vijay Alexandru Petrescu wrote: > > Thierry Ernst wrote: > >>>> in the implicit mode, the Binding Update does not contain any > >>>> prefix information. also when a routing protocol is being run > >>>> over the MR-HA tunnel, there is no prefix information in the > >>>> Binding Update. so I am not sure it is correct to call the NEMO > >>>> BU, Prefix Binding Update. > >>> > >>> Wether is it implicit or explicit, it's a BU to instruct the HA > >>> to redirect packets for an entire BU, so it could be called PBU. > >>> But if you don't like PBU, I still recommend we find a term to > >>> distinguish MIPv6 BU from NEMO BU (NBU ?). > >> > >> why? since we are not defining a new Mobility Message type value > >> for the Nemo BU, why would you want two different names for the > >> same Mobility Header message? > >> > >> there is the 'R' flag in the BU to distinguish Nemo BU. > > > > > > To avoid the confusion about what we are speaking about when we say > > "BU" [when will be talking about mobility management for the VMN and > > mobility management for the MR. Also, when the MR is acting as a > > host vs as a router]. It's better to define the term now so that > > people get the habbit to use it. > > If someone absolutely needs to distinguish a NEMO BU from a non-NEMO BU > then I would suggest R-BU (instead of PBU) simply because PBU does not > cover implicit mode, it explicitely covers explicit modes, and R-BU > covers all three modes. > > Alternatively, we can talk about: IBU (implicit mode BU), ENBU (explicit > network BU) or EPLBU (explicit prefix length BU). Or EBU (explicit BU) > that covers both ENBU and EPLBU... > > Alex > GBU From exim@www1.ietf.org Tue Aug 12 13:26:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22118 for ; Tue, 12 Aug 2003 13:26:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcuP-0003eq-9T for nemo-archive@odin.ietf.org; Tue, 12 Aug 2003 13:26:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CHQ9rT014059 for nemo-archive@odin.ietf.org; Tue, 12 Aug 2003 13:26:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcuP-0003eg-4S for nemo-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 13:26:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22099 for ; Tue, 12 Aug 2003 13:26:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mcuN-0002SM-00 for nemo-web-archive@ietf.org; Tue, 12 Aug 2003 13:26:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mcuM-0002SJ-00 for nemo-web-archive@ietf.org; Tue, 12 Aug 2003 13:26:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcuI-0003dx-0D; Tue, 12 Aug 2003 13:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcu8-0003dk-FO for nemo@optimus.ietf.org; Tue, 12 Aug 2003 13:25:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22086 for ; Tue, 12 Aug 2003 13:25:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mcu6-0002SB-00 for nemo@ietf.org; Tue, 12 Aug 2003 13:25:50 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19mcu5-0002Rs-00 for nemo@ietf.org; Tue, 12 Aug 2003 13:25:49 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7CHP5k15984; Tue, 12 Aug 2003 10:25:05 -0700 X-mProtect: <200308121725> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdwDl6I7; Tue, 12 Aug 2003 10:25:03 PDT Message-ID: <3F3922F0.DCA465D9@iprg.nokia.com> Date: Tue, 12 Aug 2003 10:25:04 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Thierry Ernst CC: Alexandru Petrescu , nemo@ietf.org Subject: Re: [nemo] NEMO Basic Support: About terminology References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> <3F37CBDC.CBA696D9@iprg.nokia.com> <20030812101201.0f34fbf2.ernst@sfc.wide.ad.jp> <3F385271.C7E9283C@iprg.nokia.com> <2003081211513 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I prefer to continue with the term Binding Update. I dont see the need to call it by a different name, especially when it is the same Mobility Header message type. and I dont see anybody confused currently :) Vijay Alexandru Petrescu wrote: > > Thierry Ernst wrote: > >>>> in the implicit mode, the Binding Update does not contain any > >>>> prefix information. also when a routing protocol is being run > >>>> over the MR-HA tunnel, there is no prefix information in the > >>>> Binding Update. so I am not sure it is correct to call the NEMO > >>>> BU, Prefix Binding Update. > >>> > >>> Wether is it implicit or explicit, it's a BU to instruct the HA > >>> to redirect packets for an entire BU, so it could be called PBU. > >>> But if you don't like PBU, I still recommend we find a term to > >>> distinguish MIPv6 BU from NEMO BU (NBU ?). > >> > >> why? since we are not defining a new Mobility Message type value > >> for the Nemo BU, why would you want two different names for the > >> same Mobility Header message? > >> > >> there is the 'R' flag in the BU to distinguish Nemo BU. > > > > > > To avoid the confusion about what we are speaking about when we say > > "BU" [when will be talking about mobility management for the VMN and > > mobility management for the MR. Also, when the MR is acting as a > > host vs as a router]. It's better to define the term now so that > > people get the habbit to use it. > > If someone absolutely needs to distinguish a NEMO BU from a non-NEMO BU > then I would suggest R-BU (instead of PBU) simply because PBU does not > cover implicit mode, it explicitely covers explicit modes, and R-BU > covers all three modes. > > Alternatively, we can talk about: IBU (implicit mode BU), ENBU (explicit > network BU) or EPLBU (explicit prefix length BU). Or EBU (explicit BU) > that covers both ENBU and EPLBU... > > Alex > GBU From nemo-admin@ietf.org Tue Aug 12 21:41:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06370 for ; Tue, 12 Aug 2003 21:41:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mkdL-0004UT-Ct; Tue, 12 Aug 2003 21:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mkcj-0004U5-Sg for nemo@optimus.ietf.org; Tue, 12 Aug 2003 21:40:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06358 for ; Tue, 12 Aug 2003 21:40:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mkch-0005FR-00 for nemo@ietf.org; Tue, 12 Aug 2003 21:40:23 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19mkcg-0005FI-00 for nemo@ietf.org; Tue, 12 Aug 2003 21:40:22 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 634F35D09B for ; Wed, 13 Aug 2003 10:39:51 +0900 (JST) Date: Wed, 13 Aug 2003 10:36:09 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] NEMO Basic Support: About terminology Message-Id: <20030813103609.382da869.ernst@sfc.wide.ad.jp> In-Reply-To: <3F3922F0.DCA465D9@iprg.nokia.com> References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> <3F37CBDC.CBA696D9@iprg.nokia.com> <20030812101201.0f34fbf2.ernst@sfc.wide.ad.jp> <3F385271.C7E9283C@iprg.nokia.com> <3F3922F0.DCA465D9@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear Vijay, > I prefer to continue with the term Binding Update. I > dont see the need to call it by a different name, > especially when it is the same Mobility Header message > type. and I dont see anybody confused currently :) The content is not the same. The aim of making the distinction is to avoid forthcoming confusion. It will be much harder to expect people making good use of terms if we don't introduce it today. The cost to introduce the term today is 0, while the benefit, in terms of clarity, could be high. Besides this, I've already seen some confusions in RO discussion, although not on this mailing list. So, please use a different term. R-BU, as suggested by Alex seems good to me. Thierry > > Vijay > > > Alexandru Petrescu wrote: > > > > Thierry Ernst wrote: > > >>>> in the implicit mode, the Binding Update does not contain any > > >>>> prefix information. also when a routing protocol is being run > > >>>> over the MR-HA tunnel, there is no prefix information in the > > >>>> Binding Update. so I am not sure it is correct to call the NEMO > > >>>> BU, Prefix Binding Update. > > >>> > > >>> Wether is it implicit or explicit, it's a BU to instruct the HA > > >>> to redirect packets for an entire BU, so it could be called PBU. > > >>> But if you don't like PBU, I still recommend we find a term to > > >>> distinguish MIPv6 BU from NEMO BU (NBU ?). > > >> > > >> why? since we are not defining a new Mobility Message type value > > >> for the Nemo BU, why would you want two different names for the > > >> same Mobility Header message? > > >> > > >> there is the 'R' flag in the BU to distinguish Nemo BU. > > > > > > > > > To avoid the confusion about what we are speaking about when we say > > > "BU" [when will be talking about mobility management for the VMN and > > > mobility management for the MR. Also, when the MR is acting as a > > > host vs as a router]. It's better to define the term now so that > > > people get the habbit to use it. > > > > If someone absolutely needs to distinguish a NEMO BU from a non-NEMO BU > > then I would suggest R-BU (instead of PBU) simply because PBU does not > > cover implicit mode, it explicitely covers explicit modes, and R-BU > > covers all three modes. > > > > Alternatively, we can talk about: IBU (implicit mode BU), ENBU (explicit > > network BU) or EPLBU (explicit prefix length BU). Or EBU (explicit BU) > > that covers both ENBU and EPLBU... From exim@www1.ietf.org Tue Aug 12 21:41:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06385 for ; Tue, 12 Aug 2003 21:41:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mkdU-0004VR-I1 for nemo-archive@odin.ietf.org; Tue, 12 Aug 2003 21:41:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7D1fCR0017317 for nemo-archive@odin.ietf.org; Tue, 12 Aug 2003 21:41:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mkdU-0004VE-4c for nemo-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 21:41:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06367 for ; Tue, 12 Aug 2003 21:41:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mkdR-0005FY-00 for nemo-web-archive@ietf.org; Tue, 12 Aug 2003 21:41:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mkdQ-0005FV-00 for nemo-web-archive@ietf.org; Tue, 12 Aug 2003 21:41:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mkdL-0004UT-Ct; Tue, 12 Aug 2003 21:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mkcj-0004U5-Sg for nemo@optimus.ietf.org; Tue, 12 Aug 2003 21:40:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06358 for ; Tue, 12 Aug 2003 21:40:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mkch-0005FR-00 for nemo@ietf.org; Tue, 12 Aug 2003 21:40:23 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19mkcg-0005FI-00 for nemo@ietf.org; Tue, 12 Aug 2003 21:40:22 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 634F35D09B for ; Wed, 13 Aug 2003 10:39:51 +0900 (JST) Date: Wed, 13 Aug 2003 10:36:09 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] NEMO Basic Support: About terminology Message-Id: <20030813103609.382da869.ernst@sfc.wide.ad.jp> In-Reply-To: <3F3922F0.DCA465D9@iprg.nokia.com> References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> <3F37CBDC.CBA696D9@iprg.nokia.com> <20030812101201.0f34fbf2.ernst@sfc.wide.ad.jp> <3F385271.C7E9283C@iprg.nokia.com> <3F3922F0.DCA465D9@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear Vijay, > I prefer to continue with the term Binding Update. I > dont see the need to call it by a different name, > especially when it is the same Mobility Header message > type. and I dont see anybody confused currently :) The content is not the same. The aim of making the distinction is to avoid forthcoming confusion. It will be much harder to expect people making good use of terms if we don't introduce it today. The cost to introduce the term today is 0, while the benefit, in terms of clarity, could be high. Besides this, I've already seen some confusions in RO discussion, although not on this mailing list. So, please use a different term. R-BU, as suggested by Alex seems good to me. Thierry > > Vijay > > > Alexandru Petrescu wrote: > > > > Thierry Ernst wrote: > > >>>> in the implicit mode, the Binding Update does not contain any > > >>>> prefix information. also when a routing protocol is being run > > >>>> over the MR-HA tunnel, there is no prefix information in the > > >>>> Binding Update. so I am not sure it is correct to call the NEMO > > >>>> BU, Prefix Binding Update. > > >>> > > >>> Wether is it implicit or explicit, it's a BU to instruct the HA > > >>> to redirect packets for an entire BU, so it could be called PBU. > > >>> But if you don't like PBU, I still recommend we find a term to > > >>> distinguish MIPv6 BU from NEMO BU (NBU ?). > > >> > > >> why? since we are not defining a new Mobility Message type value > > >> for the Nemo BU, why would you want two different names for the > > >> same Mobility Header message? > > >> > > >> there is the 'R' flag in the BU to distinguish Nemo BU. > > > > > > > > > To avoid the confusion about what we are speaking about when we say > > > "BU" [when will be talking about mobility management for the VMN and > > > mobility management for the MR. Also, when the MR is acting as a > > > host vs as a router]. It's better to define the term now so that > > > people get the habbit to use it. > > > > If someone absolutely needs to distinguish a NEMO BU from a non-NEMO BU > > then I would suggest R-BU (instead of PBU) simply because PBU does not > > cover implicit mode, it explicitely covers explicit modes, and R-BU > > covers all three modes. > > > > Alternatively, we can talk about: IBU (implicit mode BU), ENBU (explicit > > network BU) or EPLBU (explicit prefix length BU). Or EBU (explicit BU) > > that covers both ENBU and EPLBU... From nemo-admin@ietf.org Wed Aug 13 04:06:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11920 for ; Wed, 13 Aug 2003 04:06:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mqcw-0004IC-Ad; Wed, 13 Aug 2003 04:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mqca-0004H8-Kh for nemo@optimus.ietf.org; Wed, 13 Aug 2003 04:04:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11869 for ; Wed, 13 Aug 2003 04:04:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mqcY-0007VH-00 for nemo@ietf.org; Wed, 13 Aug 2003 04:04:38 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19mqcX-0007VD-00 for nemo@ietf.org; Wed, 13 Aug 2003 04:04:37 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h7D84X6n007466; Wed, 13 Aug 2003 01:04:37 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h7D84SN7017091; Wed, 13 Aug 2003 03:04:29 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id AAFB92EC86; Wed, 13 Aug 2003 10:04:28 +0200 (CEST) Message-ID: <3F39F10C.30302@nal.motlabs.com> Date: Wed, 13 Aug 2003 10:04:28 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: nemo@ietf.org Subject: Re: [nemo] NEMO Basic Support: About terminology References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> <3F37CBDC.CBA696D9@iprg.nokia.com> <20030812101201.0f34fbf2.ernst@sfc.wide.ad.jp> <3F385271.C7E9283C@iprg.nokia.com> <3F3922F0.DCA465D9@iprg.nokia.com> <20030813103609.382da869.ernst@sfc.wide.ad.jp> In-Reply-To: <20030813103609.382da869.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > Besides this, I've already seen some confusions in RO discussion, > although not on this mailing list. On which list have you seen RO discussions (confusion included)? I'm going to subscribe. Alex GBU From exim@www1.ietf.org Wed Aug 13 04:06:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11935 for ; Wed, 13 Aug 2003 04:06:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mqdg-0004Ky-Jf for nemo-archive@odin.ietf.org; Wed, 13 Aug 2003 04:05:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7D85mpx016664 for nemo-archive@odin.ietf.org; Wed, 13 Aug 2003 04:05:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mqdf-0004Kh-Vm for nemo-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 04:05:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11902 for ; Wed, 13 Aug 2003 04:05:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mqdd-0007VZ-00 for nemo-web-archive@ietf.org; Wed, 13 Aug 2003 04:05:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mqdc-0007VW-00 for nemo-web-archive@ietf.org; Wed, 13 Aug 2003 04:05:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mqcw-0004IC-Ad; Wed, 13 Aug 2003 04:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mqca-0004H8-Kh for nemo@optimus.ietf.org; Wed, 13 Aug 2003 04:04:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11869 for ; Wed, 13 Aug 2003 04:04:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mqcY-0007VH-00 for nemo@ietf.org; Wed, 13 Aug 2003 04:04:38 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19mqcX-0007VD-00 for nemo@ietf.org; Wed, 13 Aug 2003 04:04:37 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h7D84X6n007466; Wed, 13 Aug 2003 01:04:37 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h7D84SN7017091; Wed, 13 Aug 2003 03:04:29 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id AAFB92EC86; Wed, 13 Aug 2003 10:04:28 +0200 (CEST) Message-ID: <3F39F10C.30302@nal.motlabs.com> Date: Wed, 13 Aug 2003 10:04:28 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: nemo@ietf.org Subject: Re: [nemo] NEMO Basic Support: About terminology References: <20030811155009.7dc7339a.ernst@sfc.wide.ad.jp> <3F37CBDC.CBA696D9@iprg.nokia.com> <20030812101201.0f34fbf2.ernst@sfc.wide.ad.jp> <3F385271.C7E9283C@iprg.nokia.com> <3F3922F0.DCA465D9@iprg.nokia.com> <20030813103609.382da869.ernst@sfc.wide.ad.jp> In-Reply-To: <20030813103609.382da869.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > Besides this, I've already seen some confusions in RO discussion, > although not on this mailing list. On which list have you seen RO discussions (confusion included)? I'm going to subscribe. Alex GBU From nemo-admin@ietf.org Fri Aug 15 16:39:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12979 for ; Fri, 15 Aug 2003 16:39:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlLh-0002N1-T4; Fri, 15 Aug 2003 16:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlLS-0002Mk-4W for nemo@optimus.ietf.org; Fri, 15 Aug 2003 16:38:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12956 for ; Fri, 15 Aug 2003 16:38:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nlLQ-0005yC-00 for nemo@ietf.org; Fri, 15 Aug 2003 16:38:44 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19nlLO-0005y8-00 for nemo@ietf.org; Fri, 15 Aug 2003 16:38:43 -0400 Message-ID: <03b101c3636d$3d97a7c0$976015ac@dclkempt40> From: "James Kempf" To: Date: Fri, 15 Aug 2003 13:38:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Call for Journal Papers: Next Generation Mobile Security Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Wireless Personal Communications special issue on: "Security for Next Generation Mobile Communications" Guest Editors: Anand Prasad, DoCoMo Comm. Labs. Europe GmbH James Kempf, DoCoMo Comm. Labs. USA, Inc. The special session on "Security for Next Generation Mobile Communications" in WPMC 2003 held in Yokosuka, Japan, received five high quality papers which inspired the editors of the Kulwer journal to publish a special issue. This call for papers requests researchers interested in publishing a high quality paper in the field of next generation communications security for mobile communications systems to contribute papers to the journal. We are moving towards an era where "always-on" devices will provide communication anywhere, anytime and any kind of service. The "always-on" mobile device usage model faces new security issues. Long term secure sessions and simple security for multiple services challenge the current state of security technology. In addition, the trend towards heterogeneous networks, also known as "Beyond 3G" or B3G, integrates various heterogeneous access network technologies underneath a common IP layer. The different access network technologies have their own security requirements and mechanisms, making the integration of multiple access technologies for simple network access more challenging. In addition, many existing security protocols re- implement common security operations at different layers of the stack. A more modularized architecture, allowing common operations like certificate exchanged to be reused, would simplify many protocols and reduce implementation overhead. Finally, the trend toward software defined radio may require a new approach to security in order to accommodate dynamically reconfigurable spectrum usage. In this special issue our focus will be particularly on network layer security for next generation mobile networks. Possible topics are: . Modularized security architectures and implementations for reduced footprint, . Security issues related to mobility in heterogonous networks . Location privacy, . Opportunistic security, . Security for ad hoc networks, . Lightweight security infrastructure (ex. lightweight key distribution), . Bridging the divide between traditional AAA and e-commerce techniques for authentication and authorization, . Security techniques for software defined radio and dynamic spectrum usage. More information about the journal, including formatting instructions, can be found at: http://www.kluweronline.com/issn/0929-6212 Important dates: Submission of manuscripts : 1 December 2003 Notification of acceptance : 1 March 2004 Final Manuscripts Due : 1 April 2004 Publication of Feature Topic : second half 2004 Submissions should be sent to one of the guest editors: Anand R. Prasad Dr. James Kempf DoCoMo Comm. Labs. Europe GmbH DoCoMo Comm. Labs. USA, Inc. Landsberger strasse 308-312 181 Metro Drive, Suite 300 80687 Munich San Jose, CA 95110 Germany USA E-mail: prasad@docomolab-euro.com E-mail: kempf@docomolabs-usa.com From exim@www1.ietf.org Fri Aug 15 16:39:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12995 for ; Fri, 15 Aug 2003 16:39:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlLo-0002Nn-VK for nemo-archive@odin.ietf.org; Fri, 15 Aug 2003 16:39:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FKd8jX009155 for nemo-archive@odin.ietf.org; Fri, 15 Aug 2003 16:39:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlLo-0002Na-Qm for nemo-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 16:39:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12966 for ; Fri, 15 Aug 2003 16:39:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nlLn-0005yP-00 for nemo-web-archive@ietf.org; Fri, 15 Aug 2003 16:39:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nlLm-0005yL-00 for nemo-web-archive@ietf.org; Fri, 15 Aug 2003 16:39:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlLh-0002N1-T4; Fri, 15 Aug 2003 16:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlLS-0002Mk-4W for nemo@optimus.ietf.org; Fri, 15 Aug 2003 16:38:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12956 for ; Fri, 15 Aug 2003 16:38:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nlLQ-0005yC-00 for nemo@ietf.org; Fri, 15 Aug 2003 16:38:44 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19nlLO-0005y8-00 for nemo@ietf.org; Fri, 15 Aug 2003 16:38:43 -0400 Message-ID: <03b101c3636d$3d97a7c0$976015ac@dclkempt40> From: "James Kempf" To: Date: Fri, 15 Aug 2003 13:38:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Call for Journal Papers: Next Generation Mobile Security Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Wireless Personal Communications special issue on: "Security for Next Generation Mobile Communications" Guest Editors: Anand Prasad, DoCoMo Comm. Labs. Europe GmbH James Kempf, DoCoMo Comm. Labs. USA, Inc. The special session on "Security for Next Generation Mobile Communications" in WPMC 2003 held in Yokosuka, Japan, received five high quality papers which inspired the editors of the Kulwer journal to publish a special issue. This call for papers requests researchers interested in publishing a high quality paper in the field of next generation communications security for mobile communications systems to contribute papers to the journal. We are moving towards an era where "always-on" devices will provide communication anywhere, anytime and any kind of service. The "always-on" mobile device usage model faces new security issues. Long term secure sessions and simple security for multiple services challenge the current state of security technology. In addition, the trend towards heterogeneous networks, also known as "Beyond 3G" or B3G, integrates various heterogeneous access network technologies underneath a common IP layer. The different access network technologies have their own security requirements and mechanisms, making the integration of multiple access technologies for simple network access more challenging. In addition, many existing security protocols re- implement common security operations at different layers of the stack. A more modularized architecture, allowing common operations like certificate exchanged to be reused, would simplify many protocols and reduce implementation overhead. Finally, the trend toward software defined radio may require a new approach to security in order to accommodate dynamically reconfigurable spectrum usage. In this special issue our focus will be particularly on network layer security for next generation mobile networks. Possible topics are: . Modularized security architectures and implementations for reduced footprint, . Security issues related to mobility in heterogonous networks . Location privacy, . Opportunistic security, . Security for ad hoc networks, . Lightweight security infrastructure (ex. lightweight key distribution), . Bridging the divide between traditional AAA and e-commerce techniques for authentication and authorization, . Security techniques for software defined radio and dynamic spectrum usage. More information about the journal, including formatting instructions, can be found at: http://www.kluweronline.com/issn/0929-6212 Important dates: Submission of manuscripts : 1 December 2003 Notification of acceptance : 1 March 2004 Final Manuscripts Due : 1 April 2004 Publication of Feature Topic : second half 2004 Submissions should be sent to one of the guest editors: Anand R. Prasad Dr. James Kempf DoCoMo Comm. Labs. Europe GmbH DoCoMo Comm. Labs. USA, Inc. Landsberger strasse 308-312 181 Metro Drive, Suite 300 80687 Munich San Jose, CA 95110 Germany USA E-mail: prasad@docomolab-euro.com E-mail: kempf@docomolabs-usa.com From nemo-admin@ietf.org Mon Aug 18 06:27:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15013 for ; Mon, 18 Aug 2003 06:27:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ohE5-0000JX-9W; Mon, 18 Aug 2003 06:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ohDg-0000IB-Od for nemo@optimus.ietf.org; Mon, 18 Aug 2003 06:26:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14998 for ; Mon, 18 Aug 2003 06:26:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ohDc-0006Ft-00 for nemo@ietf.org; Mon, 18 Aug 2003 06:26:32 -0400 Received: from smtp-3.hut.fi ([130.233.228.93] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19ohDb-0006Fq-00 for nemo@ietf.org; Mon, 18 Aug 2003 06:26:32 -0400 Received: from tml.hut.fi (tcs-pc-5.tcs.hut.fi [130.233.215.132]) by smtp-3.hut.fi (8.12.9/8.12.9) with ESMTP id h7IAQV0H008682 for ; Mon, 18 Aug 2003 13:26:32 +0300 Message-ID: <3F40AC6F.4070302@tml.hut.fi> Date: Mon, 18 Aug 2003 13:37:35 +0300 From: Henrik Petander User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-3.hut.fi) X-DCC-HUTCC-Metrics: smtp-3.hut.fi 1165; Body=2 Fuz1=2 Fuz2=2 Content-Transfer-Encoding: 7bit Subject: [nemo] Implementation requirements and IPR Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, The IPR issue was left open at the last IETF. Is there any new information about the Cisco claims? IMHO the coverage of the Cisco claims should be known before deciding which part of the protocol is a MUST to implement. That is unless we accept that all implementations of the basic protocol depend or might depend on non-royalty-free patents. Henrik From exim@www1.ietf.org Mon Aug 18 06:27:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15043 for ; Mon, 18 Aug 2003 06:27:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ohE9-0000Ku-S6 for nemo-archive@odin.ietf.org; Mon, 18 Aug 2003 06:27:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IAR5Lv001286 for nemo-archive@odin.ietf.org; Mon, 18 Aug 2003 06:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ohE9-0000Kf-NX for nemo-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 06:27:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15010 for ; Mon, 18 Aug 2003 06:26:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ohE5-0006G6-00 for nemo-web-archive@ietf.org; Mon, 18 Aug 2003 06:27:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ohE5-0006G2-00 for nemo-web-archive@ietf.org; Mon, 18 Aug 2003 06:27:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ohE5-0000JX-9W; Mon, 18 Aug 2003 06:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ohDg-0000IB-Od for nemo@optimus.ietf.org; Mon, 18 Aug 2003 06:26:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14998 for ; Mon, 18 Aug 2003 06:26:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ohDc-0006Ft-00 for nemo@ietf.org; Mon, 18 Aug 2003 06:26:32 -0400 Received: from smtp-3.hut.fi ([130.233.228.93] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19ohDb-0006Fq-00 for nemo@ietf.org; Mon, 18 Aug 2003 06:26:32 -0400 Received: from tml.hut.fi (tcs-pc-5.tcs.hut.fi [130.233.215.132]) by smtp-3.hut.fi (8.12.9/8.12.9) with ESMTP id h7IAQV0H008682 for ; Mon, 18 Aug 2003 13:26:32 +0300 Message-ID: <3F40AC6F.4070302@tml.hut.fi> Date: Mon, 18 Aug 2003 13:37:35 +0300 From: Henrik Petander User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-3.hut.fi) X-DCC-HUTCC-Metrics: smtp-3.hut.fi 1165; Body=2 Fuz1=2 Fuz2=2 Content-Transfer-Encoding: 7bit Subject: [nemo] Implementation requirements and IPR Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, The IPR issue was left open at the last IETF. Is there any new information about the Cisco claims? IMHO the coverage of the Cisco claims should be known before deciding which part of the protocol is a MUST to implement. That is unless we accept that all implementations of the basic protocol depend or might depend on non-royalty-free patents. Henrik From nemo-admin@ietf.org Mon Aug 18 08:11:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17239 for ; Mon, 18 Aug 2003 08:11:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oiqj-0003ep-7y; Mon, 18 Aug 2003 08:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oiq7-0003eN-R7 for nemo@optimus.ietf.org; Mon, 18 Aug 2003 08:10:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17219 for ; Mon, 18 Aug 2003 08:10:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oiq6-0006p2-00 for nemo@ietf.org; Mon, 18 Aug 2003 08:10:22 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19oiq6-0006oz-00 for nemo@ietf.org; Mon, 18 Aug 2003 08:10:22 -0400 Received: from barbapapa.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Aug 2003 14:09:12 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h7IC7ZEi008968 for ; Mon, 18 Aug 2003 14:07:35 +0200 (MET DST) Received: from barbapapa.cisco.com (barbapapa.cisco.com [64.103.26.250]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id OAA27328 for ; Mon, 18 Aug 2003 14:09:50 +0200 (MET DST) Received: (qmail 1341 invoked by uid 1000); 18 Aug 2003 12:09:49 -0000 Date: Mon, 18 Aug 2003 14:09:49 +0200 From: Marco Molteni To: nemo@ietf.org Message-Id: <20030818140949.30477635.mmolteni@cisco.com> In-Reply-To: <3F40AC6F.4070302@tml.hut.fi> References: <3F40AC6F.4070302@tml.hut.fi> X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Implementation requirements and IPR Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mon, 18 Aug 2003 13:37:35 +0300 Henrik Petander wrote: FYI Pascal is on holiday this week so his reply may delay a few days. Marco > Hi, > > The IPR issue was left open at the last IETF. Is there any new > information about the Cisco claims? > > IMHO the coverage of the Cisco claims should be known before deciding > which part of the protocol is a MUST to implement. That is unless we > accept that all implementations of the basic protocol depend or might > depend on non-royalty-free patents. > > Henrik From exim@www1.ietf.org Mon Aug 18 08:11:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17256 for ; Mon, 18 Aug 2003 08:11:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oiqo-0003fd-1n for nemo-archive@odin.ietf.org; Mon, 18 Aug 2003 08:11:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7ICB6Uk014101 for nemo-archive@odin.ietf.org; Mon, 18 Aug 2003 08:11:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oiqn-0003fM-TW for nemo-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 08:11:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17227 for ; Mon, 18 Aug 2003 08:11:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oiqm-0006p8-00 for nemo-web-archive@ietf.org; Mon, 18 Aug 2003 08:11:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19oiqm-0006p5-00 for nemo-web-archive@ietf.org; Mon, 18 Aug 2003 08:11:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oiqj-0003ep-7y; Mon, 18 Aug 2003 08:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oiq7-0003eN-R7 for nemo@optimus.ietf.org; Mon, 18 Aug 2003 08:10:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17219 for ; Mon, 18 Aug 2003 08:10:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oiq6-0006p2-00 for nemo@ietf.org; Mon, 18 Aug 2003 08:10:22 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19oiq6-0006oz-00 for nemo@ietf.org; Mon, 18 Aug 2003 08:10:22 -0400 Received: from barbapapa.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Aug 2003 14:09:12 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h7IC7ZEi008968 for ; Mon, 18 Aug 2003 14:07:35 +0200 (MET DST) Received: from barbapapa.cisco.com (barbapapa.cisco.com [64.103.26.250]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id OAA27328 for ; Mon, 18 Aug 2003 14:09:50 +0200 (MET DST) Received: (qmail 1341 invoked by uid 1000); 18 Aug 2003 12:09:49 -0000 Date: Mon, 18 Aug 2003 14:09:49 +0200 From: Marco Molteni To: nemo@ietf.org Message-Id: <20030818140949.30477635.mmolteni@cisco.com> In-Reply-To: <3F40AC6F.4070302@tml.hut.fi> References: <3F40AC6F.4070302@tml.hut.fi> X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Implementation requirements and IPR Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 18 Aug 2003 13:37:35 +0300 Henrik Petander wrote: FYI Pascal is on holiday this week so his reply may delay a few days. Marco > Hi, > > The IPR issue was left open at the last IETF. Is there any new > information about the Cisco claims? > > IMHO the coverage of the Cisco claims should be known before deciding > which part of the protocol is a MUST to implement. That is unless we > accept that all implementations of the basic protocol depend or might > depend on non-royalty-free patents. > > Henrik From nemo-admin@ietf.org Mon Aug 18 14:53:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29319 for ; Mon, 18 Aug 2003 14:53:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19op7l-0000tS-Iw; Mon, 18 Aug 2003 14:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ofrr-0006Nw-V5 for nemo@optimus.ietf.org; Mon, 18 Aug 2003 04:59:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14030 for ; Mon, 18 Aug 2003 04:59:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ofrm-0005sQ-00 for nemo@ietf.org; Mon, 18 Aug 2003 04:59:54 -0400 Received: from smtp-3.hut.fi ([130.233.228.93] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19ofrl-0005sM-00 for nemo@ietf.org; Mon, 18 Aug 2003 04:59:54 -0400 Received: from tcs.hut.fi (tcs-pc-5.tcs.hut.fi [130.233.215.132]) by smtp-3.hut.fi (8.12.9/8.12.9) with ESMTP id h7I8xr0H014907 for ; Mon, 18 Aug 2003 11:59:53 +0300 Message-ID: <3F409820.4010003@tcs.hut.fi> Date: Mon, 18 Aug 2003 12:10:56 +0300 From: Henrik Petander User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-3.hut.fi) X-DCC-HUTCC-Metrics: smtp-3.hut.fi 1165; Body=2 Fuz1=2 Fuz2=2 Content-Transfer-Encoding: 7bit Subject: [nemo] Implementation requirements and IPR Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, The IPR issue was left open at the last IETF. Is there any new information about the Cisco claims? IMHO the coverage of the Cisco claims should be known before deciding which part of the protocol is a MUST to implement. That is unless we accept that the the basic protocol depends or might depend on non-royalty-free patents. Development of an open source implementation is risky as long as both the coverage of the Cisco IPR and the decision of the WG wrt. including the Cisco IPR in the basic protocol remain uncertain. Henrik From exim@www1.ietf.org Mon Aug 18 14:53:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29334 for ; Mon, 18 Aug 2003 14:53:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19op7q-0000uo-KS for nemo-archive@odin.ietf.org; Mon, 18 Aug 2003 14:53:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IIr66f003512 for nemo-archive@odin.ietf.org; Mon, 18 Aug 2003 14:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19op7q-0000uZ-Fs for nemo-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 14:53:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29307 for ; Mon, 18 Aug 2003 14:53:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19op7n-0001hv-00 for nemo-web-archive@ietf.org; Mon, 18 Aug 2003 14:53:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19op7n-0001hs-00 for nemo-web-archive@ietf.org; Mon, 18 Aug 2003 14:53:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19op7l-0000tS-Iw; Mon, 18 Aug 2003 14:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ofrr-0006Nw-V5 for nemo@optimus.ietf.org; Mon, 18 Aug 2003 04:59:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14030 for ; Mon, 18 Aug 2003 04:59:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ofrm-0005sQ-00 for nemo@ietf.org; Mon, 18 Aug 2003 04:59:54 -0400 Received: from smtp-3.hut.fi ([130.233.228.93] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19ofrl-0005sM-00 for nemo@ietf.org; Mon, 18 Aug 2003 04:59:54 -0400 Received: from tcs.hut.fi (tcs-pc-5.tcs.hut.fi [130.233.215.132]) by smtp-3.hut.fi (8.12.9/8.12.9) with ESMTP id h7I8xr0H014907 for ; Mon, 18 Aug 2003 11:59:53 +0300 Message-ID: <3F409820.4010003@tcs.hut.fi> Date: Mon, 18 Aug 2003 12:10:56 +0300 From: Henrik Petander User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-3.hut.fi) X-DCC-HUTCC-Metrics: smtp-3.hut.fi 1165; Body=2 Fuz1=2 Fuz2=2 Content-Transfer-Encoding: 7bit Subject: [nemo] Implementation requirements and IPR Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, The IPR issue was left open at the last IETF. Is there any new information about the Cisco claims? IMHO the coverage of the Cisco claims should be known before deciding which part of the protocol is a MUST to implement. That is unless we accept that the the basic protocol depends or might depend on non-royalty-free patents. Development of an open source implementation is risky as long as both the coverage of the Cisco IPR and the decision of the WG wrt. including the Cisco IPR in the basic protocol remain uncertain. Henrik From nemo-admin@ietf.org Mon Aug 18 16:09:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02839 for ; Mon, 18 Aug 2003 16:09:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqJJ-0003N9-5l; Mon, 18 Aug 2003 16:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqIl-0003KA-TH for nemo@optimus.ietf.org; Mon, 18 Aug 2003 16:08:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02806 for ; Mon, 18 Aug 2003 16:08:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oqIk-00029k-00 for nemo@ietf.org; Mon, 18 Aug 2003 16:08:26 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19oqIj-00029h-00 for nemo@ietf.org; Mon, 18 Aug 2003 16:08:25 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7IK7sY24445 for ; Mon, 18 Aug 2003 13:07:54 -0700 X-mProtect: <200308182007> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.111, claiming to be "kniveton.com") by darkstar.iprg.nokia.com smtpdo51m7M; Mon, 18 Aug 2003 13:07:51 PDT Message-ID: <3F413217.98BE4316@kniveton.com> Date: Mon, 18 Aug 2003 13:07:51 -0700 From: "T.J. Kniveton" X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: multipart/mixed; boundary="------------0414F8D4619790C3CF10D1F5" Subject: [nemo] NEMO Meeting minutes Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------0414F8D4619790C3CF10D1F5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here are the IETF57 NEMO meeting minutes that I reconstructed from the video. They are also posted on the web page. I have been having some difficulty editing the MPEG1 video of the meeting, but as soon as that's done, I'll post it as well. -TJ --------------0414F8D4619790C3CF10D1F5 Content-Type: text/plain; charset=us-ascii; name="nemo-minutes-ietf57.txt" Content-Disposition: inline; filename="nemo-minutes-ietf57.txt" Content-Transfer-Encoding: 7bit IETF57 Network Mobility (NEMO) Working Group Minutes - July 16, 2003 Working Group Chairs: Thierry Ernst, T.J. Kniveton Minutes by T.J. Kniveton Thanks to note-taker Karim El-Malki. Wednesday July 16th 13:00-15:00; Vienna, Austria. ------------------------------------------------- 1) Brief intro and Agenda Bashing - TJ - No comments on agenda. 2) NEMO status and milestones - TJ - Charter updated at beginning of year - Review - do some milestones need updates? - Will wait until terminology, requirements, and basic solution are done and submit all three together - More discussion necessary on security analysis after basic support draft complete - Need to identify someone who can work on MIB for basic support 3) NEMO Basic Support - Ryuji Wakikawa * draft-ietf-nemo-basic-support-00.txt - Design team formed at last IETF - Initial draft has been submitted - Issue list home page at http://people.nokia.net/vijayd/nemo/issues.html - Ryuji explains slides of how basic support draft works Comments on issues raised: * Issue 6 - How does HA distinguish between implicit mode and dynamic routing protocol? - Add an explicit flag to the binding update? - Do we need to check the consistency of prefixes between routing protocol and BU signaling? Pascal Thubert: It's quite common to have a route advertised from different sources; e.g. OSPF and RIP at the same time. They don't have to talk to each other and check consistency. The router has to decide which route is used. - We may be able to accept prefix information by binding update and by proto Erik Nordmark: If MR is allowed to inject any prefix into routing system, no problem. But if it is authorized to only inject certain prefixes, you need to check, i.e. as part of binding update or rt proto, if it is authorized. Ryuji: Do we need to say something in base spec? Erik: You might want to point out authorization issue, but not necessarily say how it can be solved. Felix Wu: In 6.1, you have a prefix table. The check for the table does the authorization check. So you might want to be more explicit about doing the check there Pascal: We mentioned that we could use prefix table to check BUs in explicit mode. For routing protocol, OSPF has its own way of authorizing. We don't expect to change the routing protocols. Is this if we have to introduce a new rt proto Felix: If you receive BU from MR, you need to do authorization check to see if the MR really owns this prefix. Pascal: Question is if you want to run rt protocol as it exists today. If you have concern, just don't configure routing protocol on the tunnel. Erik: If that's the approach the WG wants to take, you should document it, i.e. if you want to run a routing protocol over this, it will inject routes for any prefix. In multihoming case, if you have 2 tunnels in a single routing domain, you only inject one prefix. * Issue 3 - Should HA forward packets for the MNNs to the MR if the R flag was set to 0? - Resolution: no, if R is 0, the MR is only a mobile host. - Should HA store prefix info in BCE? - Resolution: Yes, in explicit case, useful for deleting prefix route when BCE deleted. Chan-wah Ng: In implicit mode, how does the home agent generate the prefix to be stored in bindiing cache? Ryuji: In proposed text, we didn't say anything about implicit case. It might limit the implementation too much. Pascal: This is being debated now on the mailing list. It's not important what caused MR to inject route, but you must be able to clean it up. In implicit, the MR is not injecting routes, so you don't need this information. * Issue 5 - presented by Pascal Thubert - Chapter 7 needs to be made clearer. - We would like to have aggregation of mobile networks that can be advertised without injecting individual prefixes, called Extended Homne Network - Considered like a pie cut into pieces, with each piece given to a MR - EHN can be "the" home network, or you can have it in a virtual network - Figure shown on how to bring mobile network home in EHN Erik: picture shows /48 assigned to a wire. Pascal: This is just an example. You can make home network <=> EHN Erik: I don't understand problem. Config you described falls out of how basic support works. If running rt proto, when you move home, run it where you attach. Pascal: Want to avoid encapsulation. Erik: Assuming you're not running IGP. OK I understand problem. - Also intended to keep things open, not to prevent multihoming Greg Daley: Arrival home (w/o rt proto) is less likely to occur in most cases. Maybe this could be a separate draft, with options available in base draft. Pascal: Wanted basic to be small, and write side draft if needed. So nothing about multihoming, route optimization, multicast. TJ: Design team will issue -01 draft before next IETF, already in progress. 4) Multihoming - Chan-Wah Ng * draft-ng-nemo-multihoming-issues-01 * draft-charbon-nemo-multihoming-evaluation-00 - Multihoming issues draft: last IETF suggested more clearly organized multihoming taxonomy, hence the new draft. - Julian Charbon and Chan-Wah evaluated basic support for multihoming reqs - But it missed draft deadline. URL published on mailing list. - 4 Problem categories identified on on mailing list. - They have been renamed according to (x,y,z). - x is single MR vs. multiple MRs. - y is single HA vs. multiple HAs. - z is single MNP vs. multiple MNPs. * Issue: registration of multiple CoAs - More of a MIPv6 problem - Addressed by Ryuji's multiple CoA draft in MIP WG * Issue: registration of multiple MNPs - Support already available in the basic support draft (issue can be closed) Pascal: There is no equivalent of DAD test for MNPs in base draft. I.e. two links can believe they're the same prefix. So we have to test regs so we don't have a double registration. With multihoming you want to accept the second registration. So we have to be able to detect the difference. Erik: Desire to have same prefix advertised (explicit or through BUs) at different places, to allow redundancy. But that doesn't mean address of router has to appear in multiple places. HoA -> CoA is 1:1 mapping, but MNP can show up in multiple places. * Issue: BU registration to different HAs with same HoA - Also MIPv6 specific. Can HA be in different domains? - Suggestion on ML not to support case when HAs are in different domains John _: What happens if home network is multihomed? Does it support HA in different domains? Chan-Wah: When home net is multihomed, it is not a NEMO concern. Pascal: If you have prefix 1 registered to HA1, you can have prefix2 to register with HA2, so you can stay available. John: Connection to prefix1 is broken. Better to have connection through ISP Pascal: Just a matter of trust; it's hard to sign a BU for a prefix. * Issue: Need for MR to indicate policy preference for different MNPs, CoAs, HoAs Felix: If I have 2 MNPs belonging to 2 admin domains (2 HAs), will packet with SRC in MNP1 be sent through HA2? Pascal: We should add something about source address selection. Interface selection should choose the address corresponding to that HA. Felix: Within mobile net, we use ad-hoc protocol with 2 MRs. The proto has to be defined carefully, or it would go to the wrong MR. Routing would have to consider source address, not just destination addr. Erik: Interaction between source addr selection, multihoming not NEMO-specific Outer address has to be topologically significant for ingress, and inner address has to be topologically significant for HA. Chan-Wah: Can this be handled by multi6 WG? We can restrict each MNP so it can only be registered to one HA. * Issue: Fault Tolerance - When egress interface of MR fails, we should have alternate path. But this could be a problem with ingress filtering in the other domain. * Eliminating Scenarios - (See slides for summary of each case) Ryuji: Question on 3rd and 4th case. I gave presentation at MIP WG today. I would like to know if there is functionality missing from our draft for NEMO Erik: There is a way of simplifying two bottom ones. Such a MR with multiple tunnels, if it has 2 HoAs, you don't need to do multiple CoA registrations. You can just use two HoAs that are for the same MNP. Ryuji: Idea to register multiple CoAs proposed by Pascal first. If MR must have multiple HoAs, for each interface I need different HoAs. If all interf bound to same HoA, we can hide the number of interfaces on MR. Erik: If you want to test whether tunnel/interface working, can't use HoA in that case. Not unique. - This scenario can be supported by basic NEMO solution be restricting interface to a single HoA, or by using Ryuji's multiple CoA draft. - Conclusion: Basic NEMO support can support these scenarios. - Next 4 involve multiple HAs. Can HAs be in different domains? - Suggestion to restrict basic NEMO support on multihoming to HAs in same domain. Felix: Another question for (1,1,0). Assuming they belong to same domain, can I announce one prefix to one HA, and a sub-portion of that prefix to another HA? Chan-wah: might still have problem of ingress filtering. Let's move it to the list. Pascal: With basic, it will be difficult. The EHN is the only thing that leaks out of HAs. It could be configured, but that's not what we had in mind. - Moving forward, question about introducing text for Multiple CoAs and MNPs - Preference Indication in BU? MNP preference in RA? - Fault Tolerance - devise solution to enable fault tolerance - Is WG interested in these? Karim: Didn't you say multiple CoAs would be solved in MIPv6? Chan-Wah: Multiple prefix registration could cause problem with multiple CoA _: We are working on this problem in the multi6 WG. TJ: Consensus sounds like this will be solved in multi6 /other groups _: Multi6 has taken years to get to nowhere. If you want a solution, move forward. But don't just toss it to multi6 now - Preference Indication: Erik: Prefixes are tricky because you don't know how to interpret them. You might be able to convey some info, like you have a primary and backup tunnel, i.e. on 802.11 and GPRS. But you have to be careful how it is used. - We are running out of time, so the rest will be on the list. Thierry: Status of multihoming documents: should they be a working group item? For: approx. 14. Against: 0. 5) IPR Issues - T.J. Kniveton - Companies participating in IETF process are required to inform WGs about IPR - Status of IPR on basic draft: Nokia and Cisco have said there may be IPR related to basic draft. - TJ has attempted to clear up licensing position on these - Within the last couple of weeks, Nokia has posted an IPR licensing statement for the basic draft on the IETF IPR web page, as has Cisco. - Nokia has arranged Royalty Free (RF) license for open-source implementations - Cisco has granted Reasonable and Non-Discriminatory (RAND) license, based on reciprocity. * Does WG feel that RF is necessary, or is RAND ok? - If RF desired, we need to get more information George Tsirtis: RF (Nokia) is for open source only. So not even RAND otherwise TJ: For non open-source, general patent license applies (RAND) conforming to IETF requirements, as stated in the licensing statement. - Not clear whether Cisco does RF licensing. What does WG wish to do? Kent Leung: Nokia and Cisco both have RAND at this point, for non-open-source Erik: Another possibility is to find out more about Nokia IPR, if people are interested in non-open source implementations. I can also answer general questions. But this is up to the WG to decide how to proceed. Once we know something about the claims from patent published or application or another way, then we have more info about how to proceed. But we have to have well-informed opinions on how to proceed. Greg Daley: I had some experience with non-RF licenses in GPL development, and it really stops the development dead for Linux. So further info from Cisco would be good; Nokia is cleared up for GPL. Chan-Wah: Important thing is to know which portion of NEMO basic support the IPR covers. Can we have scaled-down version not covered by IPR? Erik: If people want to try to find out more, they could ask companies which have submitted notices for more info. But you might not get a response from the lawyers. If people are willing to provide more info, that might be useful for WG. If WG believes RF for open source, or RF in general is critical, then we can send that message to the people holding the IPR, and they might come up with better terms. That has happened in the past in other working groups. - Since we are running over time, let's continue this discussion on the list. 6) Threat Analysis - Souhwan Jung - Topics: - Three-layer threat model - Generic threats to NEMO - Discussion: What are threats specific to NEMO basic draft? * draft-jung-nemo-threat-analysis-00 - provides a generic approach to protocol threat analysis - Example NEMO configuration shown in figure - Threats to signaling and data path: MR-HA, MR-MNN, MNN-CN - Compromise of MR or HA - DoS, Traffic Analysis - What are the threat issues to NEMO basic support draft? - This draft was written before the basic support draft. Still in progress. * Issue 1: Threat to MR - MR is most important entity in NEMO. IPsec protects signaling b/t MR & HA - Compromise of MR can cause serious problems in NEMO operation. - Correctness of BU is critical. HA must double-check John: MN is as important as MR. Is there a serious difference? Souhwan: compromise of single node might not be problem, but MR causes problem for every MNN. MN has same problem, but we don't need mechanism for MN. Alper Yegin: I agree there is a threat, but in context of NEMO, what should we be looking at? Should we be detecting when MR is compromised? We might be trying to do things not doable with NEMO protocol. Souhwan: We did not come up with solution, but maybe something like RR in MIPv6 can show if MR not working correctly. Felix: One of the problems with MR being compromised is that he can announce any BU, and suck in other address traffic to this mobile net, if HA does not perform prefix table check as performed in basic solution. Alper: Compromise of MR in NEMO is same as compromise of access router in fixed network. Hesham Soliman: How are these threats different than threats to any generic host on the Internet? Why is IPsec not enough? Associating HoA with SA is enough. Why is this specific to mobility? Souhwan: MR is so important for NEMO operations, we need to doublecheck whether packet is delivered to correct node Hesham: Same problem for nodes in Mobile IPv6. Not specific to NEMO. * Issue 2: Threat to HA * Issue 3: Threat related to multi-homing - (This is basically the same issue with address selection and multiple HAs discussed earlier -- see figure in slides) - DoS attack may be related to this phenomenon - Comments? None. * Issue 4: Traffic Analysis - Traffic from mobile networks go through bi-directional tunnel. So it is the same as in Mobile IP, but more severe because traffic goes through tunnel. Hesham: So where is the threat in this? Souhwan: DoS attack can be connected to this, if we change the routing mechanism. So routing to MR2 can cause packets to be blocked. Hesham: Again, this is not NEMO-specific. In any multihomed site, you need to route things so that packets won't be blocked. There's no NEMO protocol inside the yellow cloud [Mobile Network]. Pascal: Key thing here is that we wanted NEMO to be a stub network. So we cut routing paths that would end up having HA2's routes to be advertised at HA1. Hesham: OK, but we don't do any routing inside mobile network cloud. It's normal routing. Alper: I agree with Hesham here. What we are looking at are not NEMO-specific threats, they are general Internet architecture issues with security. What we should be addressing are threats specifically created by NEMO scenarios. - Location information of MR may be extracted by traffic analysis. - This is also arguable whether this is a specific problem to NEMO. Felix: I would like to comment about some of the questions asked earlier regarding what we are doing here is generic to all protocols. It was mentioned that IPsec can be broken or compromised. When we say IPsec is insufficient, it is because it provides confidentiality and authenticity. But it does not provide authorization. But in NEMO, the requirement is for a relationship between MR and HA allowing authorization. So the protocol has to handle this issue in some way. So that particular problem is very NEMO- specific. As for multihoming, it is probably going to be dealt with by Multi6. 7) Updates of Terminology and Requirements Drafts - Thierry Ernst * draft-ietf-nemo-terminology-00 - Was personal submission first; is now a WG document. - General terminology has been moved to SeaMoby terminology draft. - May be useful to add new terms related to multihoming. Already a section on multihoming and nested mobile networks. - Terms specific to NEMO Basic Support should be defined in Basic Support draft. Perhaps we need to remove/add new terms. Pascal: We are using "top-level mobile router". Could you bring the term back from the dead? Thierry: Synonym is "root MR". You can use it as well. - Would be best to submit this draft at the same time as NEMO Basic Support * draft-ietf-nemo-requirements-01 - Title has been slightly changed from NEMO Requirements to NEMO Goals and Requirements, because some sections are not mandatory. - Section 4 renamed to NEMO Design Goals. - Removed MAY and MUST. - Section 5 contains the actual requirements for basic support. - [Various changes to requirements reviewed; see slides for exact changes] Pascal: on R02, it seems all tunnels must be active at any point in time, which is not really what we want. Maybe the second MR can be a backup. Thierry: When we say must set up a bi-directional tunnel, probably doesn't have to be set up all the time. It's tricky. - Should we put reference to MIPv6 (R09)under 17? Who doesn't want to change? - Take it to the list - Multihoming (R12) - changed from MUST to SHOULD. 12.1,.2,.3 may not be necessary, because they are contained in terminology. (No comments). - NEMO support signaling over tunnel must be minimized - should we bring this requirement back? TJ: It's hard to tell what criteria are and whether the requirement has been met, when you say signaling must be minimized. - R17 - Please state what protocols are important to be backward compatible with. Please send this information to the mailing list so we know what is important. - R18 - Should we put this into the requirements as well? Pascal: It seems fair if one egress interface fails, and MR has 2nd interface, that it carries on with that one. Now with two mobile routers, it's hard to detect; it's the same multihoming problem again. Thierry: Doesn't mean NEMO basic support must support it, but if we agree it's important, we can work on it. I put it as a SHOULD so if someone wants to work on it. Greg Daley: It's a little unclear, because it's talking about "should preserve sessions" as if it's participating in the sessions or has some state. So we should change wording to reflect "should allow sessions to continue uninterrupted" so it's not misleading. Thierry: Please propose on mailing list. 8) Conclusions and Next Steps - Basic support draft - we had some good input today - There are some remaining issues to resolve - -01 draft alpha version is already complete; based on today's issue discussion and mailing list discussion, it will be finished before next IETF meeting - Threats analaysis and security considerations discussion needs continued work - i.e. which threats are specific to NEMO; guarding against NEMO-specific vs. Mobile IP threats. - Identify parties to work on MIB milestone - Gather information and get clarification on IPR - Develop WG consensus on how to proceed with IPR stakeholders - WG meeting today identified multihoming as a working group topic - Perhaps add this as a milestone to charter Erik: In terms of getting documents finished, it might make sense to be more structured to track issues on mailing list, propose text, and close issues to get them finished quicker. --------------0414F8D4619790C3CF10D1F5-- From exim@www1.ietf.org Mon Aug 18 16:09:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02870 for ; Mon, 18 Aug 2003 16:09:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqJP-0003O5-Aj for nemo-archive@odin.ietf.org; Mon, 18 Aug 2003 16:09:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IK97I6013015 for nemo-archive@odin.ietf.org; Mon, 18 Aug 2003 16:09:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqJO-0003Nq-Ri for nemo-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 16:09:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02825 for ; Mon, 18 Aug 2003 16:09:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oqJN-0002AB-00 for nemo-web-archive@ietf.org; Mon, 18 Aug 2003 16:09:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19oqJM-0002A8-00 for nemo-web-archive@ietf.org; Mon, 18 Aug 2003 16:09:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqJJ-0003N9-5l; Mon, 18 Aug 2003 16:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oqIl-0003KA-TH for nemo@optimus.ietf.org; Mon, 18 Aug 2003 16:08:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02806 for ; Mon, 18 Aug 2003 16:08:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oqIk-00029k-00 for nemo@ietf.org; Mon, 18 Aug 2003 16:08:26 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19oqIj-00029h-00 for nemo@ietf.org; Mon, 18 Aug 2003 16:08:25 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7IK7sY24445 for ; Mon, 18 Aug 2003 13:07:54 -0700 X-mProtect: <200308182007> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.111, claiming to be "kniveton.com") by darkstar.iprg.nokia.com smtpdo51m7M; Mon, 18 Aug 2003 13:07:51 PDT Message-ID: <3F413217.98BE4316@kniveton.com> Date: Mon, 18 Aug 2003 13:07:51 -0700 From: "T.J. Kniveton" X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: multipart/mixed; boundary="------------0414F8D4619790C3CF10D1F5" Subject: [nemo] NEMO Meeting minutes Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------0414F8D4619790C3CF10D1F5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here are the IETF57 NEMO meeting minutes that I reconstructed from the video. They are also posted on the web page. I have been having some difficulty editing the MPEG1 video of the meeting, but as soon as that's done, I'll post it as well. -TJ --------------0414F8D4619790C3CF10D1F5 Content-Type: text/plain; charset=us-ascii; name="nemo-minutes-ietf57.txt" Content-Disposition: inline; filename="nemo-minutes-ietf57.txt" Content-Transfer-Encoding: 7bit IETF57 Network Mobility (NEMO) Working Group Minutes - July 16, 2003 Working Group Chairs: Thierry Ernst, T.J. Kniveton Minutes by T.J. Kniveton Thanks to note-taker Karim El-Malki. Wednesday July 16th 13:00-15:00; Vienna, Austria. ------------------------------------------------- 1) Brief intro and Agenda Bashing - TJ - No comments on agenda. 2) NEMO status and milestones - TJ - Charter updated at beginning of year - Review - do some milestones need updates? - Will wait until terminology, requirements, and basic solution are done and submit all three together - More discussion necessary on security analysis after basic support draft complete - Need to identify someone who can work on MIB for basic support 3) NEMO Basic Support - Ryuji Wakikawa * draft-ietf-nemo-basic-support-00.txt - Design team formed at last IETF - Initial draft has been submitted - Issue list home page at http://people.nokia.net/vijayd/nemo/issues.html - Ryuji explains slides of how basic support draft works Comments on issues raised: * Issue 6 - How does HA distinguish between implicit mode and dynamic routing protocol? - Add an explicit flag to the binding update? - Do we need to check the consistency of prefixes between routing protocol and BU signaling? Pascal Thubert: It's quite common to have a route advertised from different sources; e.g. OSPF and RIP at the same time. They don't have to talk to each other and check consistency. The router has to decide which route is used. - We may be able to accept prefix information by binding update and by proto Erik Nordmark: If MR is allowed to inject any prefix into routing system, no problem. But if it is authorized to only inject certain prefixes, you need to check, i.e. as part of binding update or rt proto, if it is authorized. Ryuji: Do we need to say something in base spec? Erik: You might want to point out authorization issue, but not necessarily say how it can be solved. Felix Wu: In 6.1, you have a prefix table. The check for the table does the authorization check. So you might want to be more explicit about doing the check there Pascal: We mentioned that we could use prefix table to check BUs in explicit mode. For routing protocol, OSPF has its own way of authorizing. We don't expect to change the routing protocols. Is this if we have to introduce a new rt proto Felix: If you receive BU from MR, you need to do authorization check to see if the MR really owns this prefix. Pascal: Question is if you want to run rt protocol as it exists today. If you have concern, just don't configure routing protocol on the tunnel. Erik: If that's the approach the WG wants to take, you should document it, i.e. if you want to run a routing protocol over this, it will inject routes for any prefix. In multihoming case, if you have 2 tunnels in a single routing domain, you only inject one prefix. * Issue 3 - Should HA forward packets for the MNNs to the MR if the R flag was set to 0? - Resolution: no, if R is 0, the MR is only a mobile host. - Should HA store prefix info in BCE? - Resolution: Yes, in explicit case, useful for deleting prefix route when BCE deleted. Chan-wah Ng: In implicit mode, how does the home agent generate the prefix to be stored in bindiing cache? Ryuji: In proposed text, we didn't say anything about implicit case. It might limit the implementation too much. Pascal: This is being debated now on the mailing list. It's not important what caused MR to inject route, but you must be able to clean it up. In implicit, the MR is not injecting routes, so you don't need this information. * Issue 5 - presented by Pascal Thubert - Chapter 7 needs to be made clearer. - We would like to have aggregation of mobile networks that can be advertised without injecting individual prefixes, called Extended Homne Network - Considered like a pie cut into pieces, with each piece given to a MR - EHN can be "the" home network, or you can have it in a virtual network - Figure shown on how to bring mobile network home in EHN Erik: picture shows /48 assigned to a wire. Pascal: This is just an example. You can make home network <=> EHN Erik: I don't understand problem. Config you described falls out of how basic support works. If running rt proto, when you move home, run it where you attach. Pascal: Want to avoid encapsulation. Erik: Assuming you're not running IGP. OK I understand problem. - Also intended to keep things open, not to prevent multihoming Greg Daley: Arrival home (w/o rt proto) is less likely to occur in most cases. Maybe this could be a separate draft, with options available in base draft. Pascal: Wanted basic to be small, and write side draft if needed. So nothing about multihoming, route optimization, multicast. TJ: Design team will issue -01 draft before next IETF, already in progress. 4) Multihoming - Chan-Wah Ng * draft-ng-nemo-multihoming-issues-01 * draft-charbon-nemo-multihoming-evaluation-00 - Multihoming issues draft: last IETF suggested more clearly organized multihoming taxonomy, hence the new draft. - Julian Charbon and Chan-Wah evaluated basic support for multihoming reqs - But it missed draft deadline. URL published on mailing list. - 4 Problem categories identified on on mailing list. - They have been renamed according to (x,y,z). - x is single MR vs. multiple MRs. - y is single HA vs. multiple HAs. - z is single MNP vs. multiple MNPs. * Issue: registration of multiple CoAs - More of a MIPv6 problem - Addressed by Ryuji's multiple CoA draft in MIP WG * Issue: registration of multiple MNPs - Support already available in the basic support draft (issue can be closed) Pascal: There is no equivalent of DAD test for MNPs in base draft. I.e. two links can believe they're the same prefix. So we have to test regs so we don't have a double registration. With multihoming you want to accept the second registration. So we have to be able to detect the difference. Erik: Desire to have same prefix advertised (explicit or through BUs) at different places, to allow redundancy. But that doesn't mean address of router has to appear in multiple places. HoA -> CoA is 1:1 mapping, but MNP can show up in multiple places. * Issue: BU registration to different HAs with same HoA - Also MIPv6 specific. Can HA be in different domains? - Suggestion on ML not to support case when HAs are in different domains John _: What happens if home network is multihomed? Does it support HA in different domains? Chan-Wah: When home net is multihomed, it is not a NEMO concern. Pascal: If you have prefix 1 registered to HA1, you can have prefix2 to register with HA2, so you can stay available. John: Connection to prefix1 is broken. Better to have connection through ISP Pascal: Just a matter of trust; it's hard to sign a BU for a prefix. * Issue: Need for MR to indicate policy preference for different MNPs, CoAs, HoAs Felix: If I have 2 MNPs belonging to 2 admin domains (2 HAs), will packet with SRC in MNP1 be sent through HA2? Pascal: We should add something about source address selection. Interface selection should choose the address corresponding to that HA. Felix: Within mobile net, we use ad-hoc protocol with 2 MRs. The proto has to be defined carefully, or it would go to the wrong MR. Routing would have to consider source address, not just destination addr. Erik: Interaction between source addr selection, multihoming not NEMO-specific Outer address has to be topologically significant for ingress, and inner address has to be topologically significant for HA. Chan-Wah: Can this be handled by multi6 WG? We can restrict each MNP so it can only be registered to one HA. * Issue: Fault Tolerance - When egress interface of MR fails, we should have alternate path. But this could be a problem with ingress filtering in the other domain. * Eliminating Scenarios - (See slides for summary of each case) Ryuji: Question on 3rd and 4th case. I gave presentation at MIP WG today. I would like to know if there is functionality missing from our draft for NEMO Erik: There is a way of simplifying two bottom ones. Such a MR with multiple tunnels, if it has 2 HoAs, you don't need to do multiple CoA registrations. You can just use two HoAs that are for the same MNP. Ryuji: Idea to register multiple CoAs proposed by Pascal first. If MR must have multiple HoAs, for each interface I need different HoAs. If all interf bound to same HoA, we can hide the number of interfaces on MR. Erik: If you want to test whether tunnel/interface working, can't use HoA in that case. Not unique. - This scenario can be supported by basic NEMO solution be restricting interface to a single HoA, or by using Ryuji's multiple CoA draft. - Conclusion: Basic NEMO support can support these scenarios. - Next 4 involve multiple HAs. Can HAs be in different domains? - Suggestion to restrict basic NEMO support on multihoming to HAs in same domain. Felix: Another question for (1,1,0). Assuming they belong to same domain, can I announce one prefix to one HA, and a sub-portion of that prefix to another HA? Chan-wah: might still have problem of ingress filtering. Let's move it to the list. Pascal: With basic, it will be difficult. The EHN is the only thing that leaks out of HAs. It could be configured, but that's not what we had in mind. - Moving forward, question about introducing text for Multiple CoAs and MNPs - Preference Indication in BU? MNP preference in RA? - Fault Tolerance - devise solution to enable fault tolerance - Is WG interested in these? Karim: Didn't you say multiple CoAs would be solved in MIPv6? Chan-Wah: Multiple prefix registration could cause problem with multiple CoA _: We are working on this problem in the multi6 WG. TJ: Consensus sounds like this will be solved in multi6 /other groups _: Multi6 has taken years to get to nowhere. If you want a solution, move forward. But don't just toss it to multi6 now - Preference Indication: Erik: Prefixes are tricky because you don't know how to interpret them. You might be able to convey some info, like you have a primary and backup tunnel, i.e. on 802.11 and GPRS. But you have to be careful how it is used. - We are running out of time, so the rest will be on the list. Thierry: Status of multihoming documents: should they be a working group item? For: approx. 14. Against: 0. 5) IPR Issues - T.J. Kniveton - Companies participating in IETF process are required to inform WGs about IPR - Status of IPR on basic draft: Nokia and Cisco have said there may be IPR related to basic draft. - TJ has attempted to clear up licensing position on these - Within the last couple of weeks, Nokia has posted an IPR licensing statement for the basic draft on the IETF IPR web page, as has Cisco. - Nokia has arranged Royalty Free (RF) license for open-source implementations - Cisco has granted Reasonable and Non-Discriminatory (RAND) license, based on reciprocity. * Does WG feel that RF is necessary, or is RAND ok? - If RF desired, we need to get more information George Tsirtis: RF (Nokia) is for open source only. So not even RAND otherwise TJ: For non open-source, general patent license applies (RAND) conforming to IETF requirements, as stated in the licensing statement. - Not clear whether Cisco does RF licensing. What does WG wish to do? Kent Leung: Nokia and Cisco both have RAND at this point, for non-open-source Erik: Another possibility is to find out more about Nokia IPR, if people are interested in non-open source implementations. I can also answer general questions. But this is up to the WG to decide how to proceed. Once we know something about the claims from patent published or application or another way, then we have more info about how to proceed. But we have to have well-informed opinions on how to proceed. Greg Daley: I had some experience with non-RF licenses in GPL development, and it really stops the development dead for Linux. So further info from Cisco would be good; Nokia is cleared up for GPL. Chan-Wah: Important thing is to know which portion of NEMO basic support the IPR covers. Can we have scaled-down version not covered by IPR? Erik: If people want to try to find out more, they could ask companies which have submitted notices for more info. But you might not get a response from the lawyers. If people are willing to provide more info, that might be useful for WG. If WG believes RF for open source, or RF in general is critical, then we can send that message to the people holding the IPR, and they might come up with better terms. That has happened in the past in other working groups. - Since we are running over time, let's continue this discussion on the list. 6) Threat Analysis - Souhwan Jung - Topics: - Three-layer threat model - Generic threats to NEMO - Discussion: What are threats specific to NEMO basic draft? * draft-jung-nemo-threat-analysis-00 - provides a generic approach to protocol threat analysis - Example NEMO configuration shown in figure - Threats to signaling and data path: MR-HA, MR-MNN, MNN-CN - Compromise of MR or HA - DoS, Traffic Analysis - What are the threat issues to NEMO basic support draft? - This draft was written before the basic support draft. Still in progress. * Issue 1: Threat to MR - MR is most important entity in NEMO. IPsec protects signaling b/t MR & HA - Compromise of MR can cause serious problems in NEMO operation. - Correctness of BU is critical. HA must double-check John: MN is as important as MR. Is there a serious difference? Souhwan: compromise of single node might not be problem, but MR causes problem for every MNN. MN has same problem, but we don't need mechanism for MN. Alper Yegin: I agree there is a threat, but in context of NEMO, what should we be looking at? Should we be detecting when MR is compromised? We might be trying to do things not doable with NEMO protocol. Souhwan: We did not come up with solution, but maybe something like RR in MIPv6 can show if MR not working correctly. Felix: One of the problems with MR being compromised is that he can announce any BU, and suck in other address traffic to this mobile net, if HA does not perform prefix table check as performed in basic solution. Alper: Compromise of MR in NEMO is same as compromise of access router in fixed network. Hesham Soliman: How are these threats different than threats to any generic host on the Internet? Why is IPsec not enough? Associating HoA with SA is enough. Why is this specific to mobility? Souhwan: MR is so important for NEMO operations, we need to doublecheck whether packet is delivered to correct node Hesham: Same problem for nodes in Mobile IPv6. Not specific to NEMO. * Issue 2: Threat to HA * Issue 3: Threat related to multi-homing - (This is basically the same issue with address selection and multiple HAs discussed earlier -- see figure in slides) - DoS attack may be related to this phenomenon - Comments? None. * Issue 4: Traffic Analysis - Traffic from mobile networks go through bi-directional tunnel. So it is the same as in Mobile IP, but more severe because traffic goes through tunnel. Hesham: So where is the threat in this? Souhwan: DoS attack can be connected to this, if we change the routing mechanism. So routing to MR2 can cause packets to be blocked. Hesham: Again, this is not NEMO-specific. In any multihomed site, you need to route things so that packets won't be blocked. There's no NEMO protocol inside the yellow cloud [Mobile Network]. Pascal: Key thing here is that we wanted NEMO to be a stub network. So we cut routing paths that would end up having HA2's routes to be advertised at HA1. Hesham: OK, but we don't do any routing inside mobile network cloud. It's normal routing. Alper: I agree with Hesham here. What we are looking at are not NEMO-specific threats, they are general Internet architecture issues with security. What we should be addressing are threats specifically created by NEMO scenarios. - Location information of MR may be extracted by traffic analysis. - This is also arguable whether this is a specific problem to NEMO. Felix: I would like to comment about some of the questions asked earlier regarding what we are doing here is generic to all protocols. It was mentioned that IPsec can be broken or compromised. When we say IPsec is insufficient, it is because it provides confidentiality and authenticity. But it does not provide authorization. But in NEMO, the requirement is for a relationship between MR and HA allowing authorization. So the protocol has to handle this issue in some way. So that particular problem is very NEMO- specific. As for multihoming, it is probably going to be dealt with by Multi6. 7) Updates of Terminology and Requirements Drafts - Thierry Ernst * draft-ietf-nemo-terminology-00 - Was personal submission first; is now a WG document. - General terminology has been moved to SeaMoby terminology draft. - May be useful to add new terms related to multihoming. Already a section on multihoming and nested mobile networks. - Terms specific to NEMO Basic Support should be defined in Basic Support draft. Perhaps we need to remove/add new terms. Pascal: We are using "top-level mobile router". Could you bring the term back from the dead? Thierry: Synonym is "root MR". You can use it as well. - Would be best to submit this draft at the same time as NEMO Basic Support * draft-ietf-nemo-requirements-01 - Title has been slightly changed from NEMO Requirements to NEMO Goals and Requirements, because some sections are not mandatory. - Section 4 renamed to NEMO Design Goals. - Removed MAY and MUST. - Section 5 contains the actual requirements for basic support. - [Various changes to requirements reviewed; see slides for exact changes] Pascal: on R02, it seems all tunnels must be active at any point in time, which is not really what we want. Maybe the second MR can be a backup. Thierry: When we say must set up a bi-directional tunnel, probably doesn't have to be set up all the time. It's tricky. - Should we put reference to MIPv6 (R09)under 17? Who doesn't want to change? - Take it to the list - Multihoming (R12) - changed from MUST to SHOULD. 12.1,.2,.3 may not be necessary, because they are contained in terminology. (No comments). - NEMO support signaling over tunnel must be minimized - should we bring this requirement back? TJ: It's hard to tell what criteria are and whether the requirement has been met, when you say signaling must be minimized. - R17 - Please state what protocols are important to be backward compatible with. Please send this information to the mailing list so we know what is important. - R18 - Should we put this into the requirements as well? Pascal: It seems fair if one egress interface fails, and MR has 2nd interface, that it carries on with that one. Now with two mobile routers, it's hard to detect; it's the same multihoming problem again. Thierry: Doesn't mean NEMO basic support must support it, but if we agree it's important, we can work on it. I put it as a SHOULD so if someone wants to work on it. Greg Daley: It's a little unclear, because it's talking about "should preserve sessions" as if it's participating in the sessions or has some state. So we should change wording to reflect "should allow sessions to continue uninterrupted" so it's not misleading. Thierry: Please propose on mailing list. 8) Conclusions and Next Steps - Basic support draft - we had some good input today - There are some remaining issues to resolve - -01 draft alpha version is already complete; based on today's issue discussion and mailing list discussion, it will be finished before next IETF meeting - Threats analaysis and security considerations discussion needs continued work - i.e. which threats are specific to NEMO; guarding against NEMO-specific vs. Mobile IP threats. - Identify parties to work on MIB milestone - Gather information and get clarification on IPR - Develop WG consensus on how to proceed with IPR stakeholders - WG meeting today identified multihoming as a working group topic - Perhaps add this as a milestone to charter Erik: In terms of getting documents finished, it might make sense to be more structured to track issues on mailing list, propose text, and close issues to get them finished quicker. --------------0414F8D4619790C3CF10D1F5-- From nemo-admin@ietf.org Mon Aug 18 21:16:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11365 for ; Mon, 18 Aug 2003 21:16:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ov6Q-0005Rm-3X; Mon, 18 Aug 2003 21:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ov66-0005RD-6Y for nemo@optimus.ietf.org; Mon, 18 Aug 2003 21:15:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11349 for ; Mon, 18 Aug 2003 21:15:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ov63-0003xQ-00 for nemo@ietf.org; Mon, 18 Aug 2003 21:15:39 -0400 Received: from mobqos.ee.unsw.edu.au ([129.94.230.70]) by ietf-mx with esmtp (Exim 4.12) id 19ov62-0003xM-00 for nemo@ietf.org; Mon, 18 Aug 2003 21:15:38 -0400 Received: from eranga (helo=localhost) by mobqos.ee.unsw.edu.au with local-esmtp (Exim 3.35 #1 (Debian)) id 19ov5X-00011s-00 for ; Tue, 19 Aug 2003 11:15:07 +1000 Date: Tue, 19 Aug 2003 11:15:07 +1000 (EST) From: Eranga Perera To: nemo@ietf.org Subject: [NEMO] Draft on Extended Network Mobility Support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Everyone, We have submitted a draft on Extended Mobility Support and we'd like to get some feedback. The URL for the draft is : http://www.ietf.org/internet-drafts/draft-perera-nemo-extended-00.txt The table given below summarizes the main characteristics of our scheme against the MIPv6 protocol and the NEMO Basic Protocol. Layer 2 Handoff Prefix Change Route Optimization MIPv6 yes yes yes NEMO Basic no no no Our Scheme no yes yes Hope to hear from you guys soon, Eranga From exim@www1.ietf.org Mon Aug 18 21:16:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11380 for ; Mon, 18 Aug 2003 21:16:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ov6W-0005Sj-Bj for nemo-archive@odin.ietf.org; Mon, 18 Aug 2003 21:16:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7J1G8Z3020991 for nemo-archive@odin.ietf.org; Mon, 18 Aug 2003 21:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ov6W-0005SU-7G for nemo-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 21:16:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11356 for ; Mon, 18 Aug 2003 21:16:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ov6T-0003xY-00 for nemo-web-archive@ietf.org; Mon, 18 Aug 2003 21:16:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ov6T-0003xV-00 for nemo-web-archive@ietf.org; Mon, 18 Aug 2003 21:16:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ov6Q-0005Rm-3X; Mon, 18 Aug 2003 21:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ov66-0005RD-6Y for nemo@optimus.ietf.org; Mon, 18 Aug 2003 21:15:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11349 for ; Mon, 18 Aug 2003 21:15:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ov63-0003xQ-00 for nemo@ietf.org; Mon, 18 Aug 2003 21:15:39 -0400 Received: from mobqos.ee.unsw.edu.au ([129.94.230.70]) by ietf-mx with esmtp (Exim 4.12) id 19ov62-0003xM-00 for nemo@ietf.org; Mon, 18 Aug 2003 21:15:38 -0400 Received: from eranga (helo=localhost) by mobqos.ee.unsw.edu.au with local-esmtp (Exim 3.35 #1 (Debian)) id 19ov5X-00011s-00 for ; Tue, 19 Aug 2003 11:15:07 +1000 Date: Tue, 19 Aug 2003 11:15:07 +1000 (EST) From: Eranga Perera To: nemo@ietf.org Subject: [NEMO] Draft on Extended Network Mobility Support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Everyone, We have submitted a draft on Extended Mobility Support and we'd like to get some feedback. The URL for the draft is : http://www.ietf.org/internet-drafts/draft-perera-nemo-extended-00.txt The table given below summarizes the main characteristics of our scheme against the MIPv6 protocol and the NEMO Basic Protocol. Layer 2 Handoff Prefix Change Route Optimization MIPv6 yes yes yes NEMO Basic no no no Our Scheme no yes yes Hope to hear from you guys soon, Eranga From nemo-admin@ietf.org Tue Aug 19 04:55:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02088 for ; Tue, 19 Aug 2003 04:55:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p2Gc-0004Ig-8W; Tue, 19 Aug 2003 04:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p2GK-0004I0-LK for nemo@optimus.ietf.org; Tue, 19 Aug 2003 04:54:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02056 for ; Tue, 19 Aug 2003 04:54:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p2GH-0005xd-00 for nemo@ietf.org; Tue, 19 Aug 2003 04:54:41 -0400 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 19p2GG-0005xa-00 for nemo@ietf.org; Tue, 19 Aug 2003 04:54:41 -0400 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 454A66A903; Tue, 19 Aug 2003 11:54:34 +0300 (EEST) Message-ID: <3F41E528.10007@kolumbus.fi> Date: Tue, 19 Aug 2003 11:51:52 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Petander Cc: nemo@ietf.org Subject: Re: [nemo] Implementation requirements and IPR References: <3F409820.4010003@tcs.hut.fi> In-Reply-To: <3F409820.4010003@tcs.hut.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Henrik Petander wrote: > IMHO the coverage of the Cisco claims should be known before deciding Agree. > which part of the protocol is a MUST to implement. That is unless we > accept that the the basic protocol depends or might depend on > non-royalty-free patents. I don't think it is acceptable. We should wait for more information or for better license statement. In many other cases, royalty free licenses have been available to either all (e.g. Ericsson and Microsoft in SEND) or at the very least public domain implementations (e.g. Nokia's statement on NEMO). --Jari From exim@www1.ietf.org Tue Aug 19 04:55:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02103 for ; Tue, 19 Aug 2003 04:55:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p2Gl-0004JT-63 for nemo-archive@odin.ietf.org; Tue, 19 Aug 2003 04:55:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7J8tBgg016573 for nemo-archive@odin.ietf.org; Tue, 19 Aug 2003 04:55:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p2Gk-0004JE-L0 for nemo-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 04:55:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02073 for ; Tue, 19 Aug 2003 04:55:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p2Gh-0005xx-00 for nemo-web-archive@ietf.org; Tue, 19 Aug 2003 04:55:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p2Gh-0005xu-00 for nemo-web-archive@ietf.org; Tue, 19 Aug 2003 04:55:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p2Gc-0004Ig-8W; Tue, 19 Aug 2003 04:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p2GK-0004I0-LK for nemo@optimus.ietf.org; Tue, 19 Aug 2003 04:54:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02056 for ; Tue, 19 Aug 2003 04:54:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p2GH-0005xd-00 for nemo@ietf.org; Tue, 19 Aug 2003 04:54:41 -0400 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 19p2GG-0005xa-00 for nemo@ietf.org; Tue, 19 Aug 2003 04:54:41 -0400 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 454A66A903; Tue, 19 Aug 2003 11:54:34 +0300 (EEST) Message-ID: <3F41E528.10007@kolumbus.fi> Date: Tue, 19 Aug 2003 11:51:52 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Petander Cc: nemo@ietf.org Subject: Re: [nemo] Implementation requirements and IPR References: <3F409820.4010003@tcs.hut.fi> In-Reply-To: <3F409820.4010003@tcs.hut.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henrik Petander wrote: > IMHO the coverage of the Cisco claims should be known before deciding Agree. > which part of the protocol is a MUST to implement. That is unless we > accept that the the basic protocol depends or might depend on > non-royalty-free patents. I don't think it is acceptable. We should wait for more information or for better license statement. In many other cases, royalty free licenses have been available to either all (e.g. Ericsson and Microsoft in SEND) or at the very least public domain implementations (e.g. Nokia's statement on NEMO). --Jari From nemo-admin@ietf.org Tue Aug 19 18:26:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13206 for ; Tue, 19 Aug 2003 18:26:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pEvR-0007D5-7W; Tue, 19 Aug 2003 18:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pEul-00077k-1j for nemo@optimus.ietf.org; Tue, 19 Aug 2003 18:25:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13054 for ; Tue, 19 Aug 2003 18:25:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pEui-0000x3-00 for nemo@ietf.org; Tue, 19 Aug 2003 18:25:16 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19pEue-0000vE-00 for nemo@ietf.org; Tue, 19 Aug 2003 18:25:12 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7JMOGW20921; Tue, 19 Aug 2003 15:24:16 -0700 X-mProtect: <200308192224> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd77mtW7; Tue, 19 Aug 2003 15:24:14 PDT Message-ID: <3F42A38F.2C5358DF@iprg.nokia.com> Date: Tue, 19 Aug 2003 15:24:15 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: Jongkeun Na , nemo@ietf.org Subject: Source Address Selection (was Re: [nemo] crossover tunnel....) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Pascal Thubert (pthubert)" wrote: > When a MR joins a new link, there's more that happens than we actually described. > > I suggest to insert a 5.7 chapter: SAS for mobile router > > In the process of Source Address Selection, the MRHA tunnel is considered as > any other link, with the restriction that only a global address may be selected. this is not necessarily true. link local addresses can be used as source and destination address in the inner IPv6 header. infact link local address are used, for example, if DHCPv6 messages are exchanged over the MR-HA tunnel. the outer IPv6 header ofcourse will contain MR's CoA and HA's address. > So when the MR is not at Home, the Home Address will be selected as source > address when and only when the destination is reached via the MRHA tunnel. right. > > The MR has a set of connected routes for its attached MNPs. It may also > have some static routes and a set of routes obtained from a routing protocol. > For all these routes, SAS takes place normally and if the MRHA tunnel is not > the link to the next hop, the best scoped global address on that link should > be preferred, avoiding the MIP encapsulation and the need for global connectivity. I am not sure what you mean by global connectivity here? the rest of the paragraph makes sense. > In particular, when a MR forms a CoA from a visited prefix, it inserts a > connected route to that prefix, over the associated egress interface, in > its routing table. So when the MR initiates a socket to a node on that link, > SAS will select the CareOf address as source. why? the MR may want to use Route Optimization with the node on the visited link. in this case, the MR-HA tunnel wouldnt be outgoing interface. the application on the MR may initiate a socket with the home address and depend on the kernel to add the Home Address option. when the packet is actually sent out on the visited link, the source address would be the CoA with the home address in the Home Address Option. but I agree with the general idea in your text. and I think it can be simplified. For any packet, if the interface through which the packet is sent out is the MR-HA tunnel, then the Home Address must be selected as the source address. The source must be set to the link local address, if the destination of the packet is a link local address. The Mobile Router MUST NOT set the source address to Home Address if the packets are sent to the visited link. Vijay From exim@www1.ietf.org Tue Aug 19 18:26:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13224 for ; Tue, 19 Aug 2003 18:26:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pEvV-0007FG-Iu for nemo-archive@odin.ietf.org; Tue, 19 Aug 2003 18:26:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JMQ54s027846 for nemo-archive@odin.ietf.org; Tue, 19 Aug 2003 18:26:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pEvV-0007F3-D4 for nemo-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 18:26:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13182 for ; Tue, 19 Aug 2003 18:25:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pEvS-0000zi-00 for nemo-web-archive@ietf.org; Tue, 19 Aug 2003 18:26:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pEvS-0000ze-00 for nemo-web-archive@ietf.org; Tue, 19 Aug 2003 18:26:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pEvR-0007D5-7W; Tue, 19 Aug 2003 18:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pEul-00077k-1j for nemo@optimus.ietf.org; Tue, 19 Aug 2003 18:25:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13054 for ; Tue, 19 Aug 2003 18:25:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pEui-0000x3-00 for nemo@ietf.org; Tue, 19 Aug 2003 18:25:16 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19pEue-0000vE-00 for nemo@ietf.org; Tue, 19 Aug 2003 18:25:12 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7JMOGW20921; Tue, 19 Aug 2003 15:24:16 -0700 X-mProtect: <200308192224> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd77mtW7; Tue, 19 Aug 2003 15:24:14 PDT Message-ID: <3F42A38F.2C5358DF@iprg.nokia.com> Date: Tue, 19 Aug 2003 15:24:15 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: Jongkeun Na , nemo@ietf.org Subject: Source Address Selection (was Re: [nemo] crossover tunnel....) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Pascal Thubert (pthubert)" wrote: > When a MR joins a new link, there's more that happens than we actually described. > > I suggest to insert a 5.7 chapter: SAS for mobile router > > In the process of Source Address Selection, the MRHA tunnel is considered as > any other link, with the restriction that only a global address may be selected. this is not necessarily true. link local addresses can be used as source and destination address in the inner IPv6 header. infact link local address are used, for example, if DHCPv6 messages are exchanged over the MR-HA tunnel. the outer IPv6 header ofcourse will contain MR's CoA and HA's address. > So when the MR is not at Home, the Home Address will be selected as source > address when and only when the destination is reached via the MRHA tunnel. right. > > The MR has a set of connected routes for its attached MNPs. It may also > have some static routes and a set of routes obtained from a routing protocol. > For all these routes, SAS takes place normally and if the MRHA tunnel is not > the link to the next hop, the best scoped global address on that link should > be preferred, avoiding the MIP encapsulation and the need for global connectivity. I am not sure what you mean by global connectivity here? the rest of the paragraph makes sense. > In particular, when a MR forms a CoA from a visited prefix, it inserts a > connected route to that prefix, over the associated egress interface, in > its routing table. So when the MR initiates a socket to a node on that link, > SAS will select the CareOf address as source. why? the MR may want to use Route Optimization with the node on the visited link. in this case, the MR-HA tunnel wouldnt be outgoing interface. the application on the MR may initiate a socket with the home address and depend on the kernel to add the Home Address option. when the packet is actually sent out on the visited link, the source address would be the CoA with the home address in the Home Address Option. but I agree with the general idea in your text. and I think it can be simplified. For any packet, if the interface through which the packet is sent out is the MR-HA tunnel, then the Home Address must be selected as the source address. The source must be set to the link local address, if the destination of the packet is a link local address. The Mobile Router MUST NOT set the source address to Home Address if the packets are sent to the visited link. Vijay From nemo-admin@ietf.org Thu Aug 21 05:45:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25254 for ; Thu, 21 Aug 2003 05:45:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pm05-0006LL-Rv; Thu, 21 Aug 2003 05:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19plzy-0006K8-EE for nemo@optimus.ietf.org; Thu, 21 Aug 2003 05:44:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25218 for ; Thu, 21 Aug 2003 05:44:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19plzu-0000nW-00 for nemo@ietf.org; Thu, 21 Aug 2003 05:44:51 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19plzu-0000nS-00 for nemo@ietf.org; Thu, 21 Aug 2003 05:44:50 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h7L9ioLf027916; Thu, 21 Aug 2003 02:44:50 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h7L9iiBh026315; Thu, 21 Aug 2003 04:44:45 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 460492EC86; Thu, 21 Aug 2003 11:44:45 +0200 (CEST) Message-ID: <3F44948D.6050009@nal.motlabs.com> Date: Thu, 21 Aug 2003 11:44:45 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eranga Perera Cc: nemo@ietf.org Subject: Re: [NEMO] Draft on Extended Network Mobility Support References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi and thank you for this draft. Is there any relation between the Extended Network Mobility Support and the Extended Home Network and the Extended Home Address section 7 on the draft of the Nemo Basic Support Protocol draft? Or maybe this likely to be simply a terminology issue? Thanks, Alex GBU Eranga Perera wrote: > Hi Everyone, We have submitted a draft on Extended Mobility Support > and we'd like to get some feedback. > > The URL for the draft is : > http://www.ietf.org/internet-drafts/draft-perera-nemo-extended-00.txt > > > > The table given below summarizes the main characteristics of our > scheme against the MIPv6 protocol and the NEMO Basic Protocol. > > Layer 2 Handoff Prefix Change Route Optimization MIPv6 yes > yes yes NEMO Basic no no > no Our Scheme no yes yes > > Hope to hear from you guys soon, Eranga > > From exim@www1.ietf.org Thu Aug 21 05:45:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25270 for ; Thu, 21 Aug 2003 05:45:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pm0B-0006Mw-L2 for nemo-archive@odin.ietf.org; Thu, 21 Aug 2003 05:45:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7L9j7cc024478 for nemo-archive@odin.ietf.org; Thu, 21 Aug 2003 05:45:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pm0B-0006Mj-Gf for nemo-web-archive@optimus.ietf.org; Thu, 21 Aug 2003 05:45:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25231 for ; Thu, 21 Aug 2003 05:45:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pm08-0000nt-00 for nemo-web-archive@ietf.org; Thu, 21 Aug 2003 05:45:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pm07-0000np-00 for nemo-web-archive@ietf.org; Thu, 21 Aug 2003 05:45:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pm05-0006LL-Rv; Thu, 21 Aug 2003 05:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19plzy-0006K8-EE for nemo@optimus.ietf.org; Thu, 21 Aug 2003 05:44:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25218 for ; Thu, 21 Aug 2003 05:44:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19plzu-0000nW-00 for nemo@ietf.org; Thu, 21 Aug 2003 05:44:51 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19plzu-0000nS-00 for nemo@ietf.org; Thu, 21 Aug 2003 05:44:50 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h7L9ioLf027916; Thu, 21 Aug 2003 02:44:50 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h7L9iiBh026315; Thu, 21 Aug 2003 04:44:45 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 460492EC86; Thu, 21 Aug 2003 11:44:45 +0200 (CEST) Message-ID: <3F44948D.6050009@nal.motlabs.com> Date: Thu, 21 Aug 2003 11:44:45 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eranga Perera Cc: nemo@ietf.org Subject: Re: [NEMO] Draft on Extended Network Mobility Support References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi and thank you for this draft. Is there any relation between the Extended Network Mobility Support and the Extended Home Network and the Extended Home Address section 7 on the draft of the Nemo Basic Support Protocol draft? Or maybe this likely to be simply a terminology issue? Thanks, Alex GBU Eranga Perera wrote: > Hi Everyone, We have submitted a draft on Extended Mobility Support > and we'd like to get some feedback. > > The URL for the draft is : > http://www.ietf.org/internet-drafts/draft-perera-nemo-extended-00.txt > > > > The table given below summarizes the main characteristics of our > scheme against the MIPv6 protocol and the NEMO Basic Protocol. > > Layer 2 Handoff Prefix Change Route Optimization MIPv6 yes > yes yes NEMO Basic no no > no Our Scheme no yes yes > > Hope to hear from you guys soon, Eranga > > From nemo-admin@ietf.org Thu Aug 21 09:02:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03197 for ; Thu, 21 Aug 2003 09:02:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pp4j-0005jC-MI; Thu, 21 Aug 2003 09:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pp4V-0005ir-8M for nemo@optimus.ietf.org; Thu, 21 Aug 2003 09:01:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03131 for ; Thu, 21 Aug 2003 09:01:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pp4T-0002tI-00 for nemo@ietf.org; Thu, 21 Aug 2003 09:01:45 -0400 Received: from mobqos.ee.unsw.edu.au ([129.94.230.70]) by ietf-mx with esmtp (Exim 4.12) id 19pp4S-0002so-00 for nemo@ietf.org; Thu, 21 Aug 2003 09:01:45 -0400 Received: from eranga (helo=localhost) by mobqos.ee.unsw.edu.au with local-esmtp (Exim 3.35 #1 (Debian)) id 19pp3n-0008G0-00; Thu, 21 Aug 2003 23:01:03 +1000 Date: Thu, 21 Aug 2003 23:01:03 +1000 (EST) From: Eranga Perera To: Alexandru Petrescu cc: nemo@ietf.org Subject: Re: [NEMO] Draft on Extended Network Mobility Support In-Reply-To: <3F44948D.6050009@nal.motlabs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Alex, Thank you for your interest. No there is no relation between them. What we mean by Extended Network Mobility Support is route optimization for NEMO as opposed to bidirectional tunneling (NEMO Basic). Cheers, Eranga On Thu, 21 Aug 2003, Alexandru Petrescu wrote: > Hi and thank you for this draft. Is there any relation between the > Extended Network Mobility Support and the Extended Home Network and the > Extended Home Address section 7 on the draft of the Nemo Basic Support > Protocol draft? Or maybe this likely to be simply a terminology issue? > > Thanks, > > Alex > GBU > > Eranga Perera wrote: > > Hi Everyone, We have submitted a draft on Extended Mobility Support > > and we'd like to get some feedback. > > > > The URL for the draft is : > > http://www.ietf.org/internet-drafts/draft-perera-nemo-extended-00.txt > > > > > > > > The table given below summarizes the main characteristics of our > > scheme against the MIPv6 protocol and the NEMO Basic Protocol. > > > > L2 Handoff Prefix Change Route Opt > > MIPv6 yes yes yes > > > > NEMO Basic no no no > > > > Our Scheme no yes yes > > > > Hope to hear from you guys soon, Eranga > > > > > > > From exim@www1.ietf.org Thu Aug 21 09:02:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03220 for ; Thu, 21 Aug 2003 09:02:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pp4o-0005kb-Lc for nemo-archive@odin.ietf.org; Thu, 21 Aug 2003 09:02:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7LD26fG022099 for nemo-archive@odin.ietf.org; Thu, 21 Aug 2003 09:02:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pp4o-0005kM-Ec for nemo-web-archive@optimus.ietf.org; Thu, 21 Aug 2003 09:02:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03146 for ; Thu, 21 Aug 2003 09:02:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pp4n-0002tj-00 for nemo-web-archive@ietf.org; Thu, 21 Aug 2003 09:02:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pp4m-0002tg-00 for nemo-web-archive@ietf.org; Thu, 21 Aug 2003 09:02:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pp4j-0005jC-MI; Thu, 21 Aug 2003 09:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pp4V-0005ir-8M for nemo@optimus.ietf.org; Thu, 21 Aug 2003 09:01:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03131 for ; Thu, 21 Aug 2003 09:01:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pp4T-0002tI-00 for nemo@ietf.org; Thu, 21 Aug 2003 09:01:45 -0400 Received: from mobqos.ee.unsw.edu.au ([129.94.230.70]) by ietf-mx with esmtp (Exim 4.12) id 19pp4S-0002so-00 for nemo@ietf.org; Thu, 21 Aug 2003 09:01:45 -0400 Received: from eranga (helo=localhost) by mobqos.ee.unsw.edu.au with local-esmtp (Exim 3.35 #1 (Debian)) id 19pp3n-0008G0-00; Thu, 21 Aug 2003 23:01:03 +1000 Date: Thu, 21 Aug 2003 23:01:03 +1000 (EST) From: Eranga Perera To: Alexandru Petrescu cc: nemo@ietf.org Subject: Re: [NEMO] Draft on Extended Network Mobility Support In-Reply-To: <3F44948D.6050009@nal.motlabs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Alex, Thank you for your interest. No there is no relation between them. What we mean by Extended Network Mobility Support is route optimization for NEMO as opposed to bidirectional tunneling (NEMO Basic). Cheers, Eranga On Thu, 21 Aug 2003, Alexandru Petrescu wrote: > Hi and thank you for this draft. Is there any relation between the > Extended Network Mobility Support and the Extended Home Network and the > Extended Home Address section 7 on the draft of the Nemo Basic Support > Protocol draft? Or maybe this likely to be simply a terminology issue? > > Thanks, > > Alex > GBU > > Eranga Perera wrote: > > Hi Everyone, We have submitted a draft on Extended Mobility Support > > and we'd like to get some feedback. > > > > The URL for the draft is : > > http://www.ietf.org/internet-drafts/draft-perera-nemo-extended-00.txt > > > > > > > > The table given below summarizes the main characteristics of our > > scheme against the MIPv6 protocol and the NEMO Basic Protocol. > > > > L2 Handoff Prefix Change Route Opt > > MIPv6 yes yes yes > > > > NEMO Basic no no no > > > > Our Scheme no yes yes > > > > Hope to hear from you guys soon, Eranga > > > > > > > From nemo-admin@ietf.org Thu Aug 21 20:36:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11219 for ; Thu, 21 Aug 2003 20:36:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pzuL-0001U4-Ft; Thu, 21 Aug 2003 20:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pztY-0001Ql-G0 for nemo@optimus.ietf.org; Thu, 21 Aug 2003 20:35:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11123 for ; Thu, 21 Aug 2003 20:35:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pztW-00048a-00 for nemo@ietf.org; Thu, 21 Aug 2003 20:35:10 -0400 Received: from mobqos.ee.unsw.edu.au ([129.94.230.70]) by ietf-mx with esmtp (Exim 4.12) id 19pztV-00047w-00 for nemo@ietf.org; Thu, 21 Aug 2003 20:35:09 -0400 Received: from eranga (helo=localhost) by mobqos.ee.unsw.edu.au with local-esmtp (Exim 3.35 #1 (Debian)) id 19pzsv-0006XS-00; Fri, 22 Aug 2003 10:34:33 +1000 Date: Fri, 22 Aug 2003 10:34:33 +1000 (EST) From: Eranga Perera To: ernst@sfc.wide.ad.jp cc: nemo@ietf.org Subject: [NEMO] LFN terminology Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Thierry, I need to clarify why is it that the general assumption within the group is that a LFN has no MIPv6 MN capability. The fact that the LFNs are 'fixed' w.r.t. the MR's topology does not mean that these nodes are fixed w.r.t to the global topology. So isn't it correct to assume that these nodes may or may not be MIPv6-enabled? Thank you, Eranga From exim@www1.ietf.org Thu Aug 21 20:36:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11237 for ; Thu, 21 Aug 2003 20:36:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pzuQ-0001VB-5O for nemo-archive@odin.ietf.org; Thu, 21 Aug 2003 20:36:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7M0a6Xa005767 for nemo-archive@odin.ietf.org; Thu, 21 Aug 2003 20:36:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pzuQ-0001Uw-1V for nemo-web-archive@optimus.ietf.org; Thu, 21 Aug 2003 20:36:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11187 for ; Thu, 21 Aug 2003 20:36:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pzuN-000498-00 for nemo-web-archive@ietf.org; Thu, 21 Aug 2003 20:36:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pzuN-000494-00 for nemo-web-archive@ietf.org; Thu, 21 Aug 2003 20:36:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pzuL-0001U4-Ft; Thu, 21 Aug 2003 20:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pztY-0001Ql-G0 for nemo@optimus.ietf.org; Thu, 21 Aug 2003 20:35:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11123 for ; Thu, 21 Aug 2003 20:35:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pztW-00048a-00 for nemo@ietf.org; Thu, 21 Aug 2003 20:35:10 -0400 Received: from mobqos.ee.unsw.edu.au ([129.94.230.70]) by ietf-mx with esmtp (Exim 4.12) id 19pztV-00047w-00 for nemo@ietf.org; Thu, 21 Aug 2003 20:35:09 -0400 Received: from eranga (helo=localhost) by mobqos.ee.unsw.edu.au with local-esmtp (Exim 3.35 #1 (Debian)) id 19pzsv-0006XS-00; Fri, 22 Aug 2003 10:34:33 +1000 Date: Fri, 22 Aug 2003 10:34:33 +1000 (EST) From: Eranga Perera To: ernst@sfc.wide.ad.jp cc: nemo@ietf.org Subject: [NEMO] LFN terminology Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Thierry, I need to clarify why is it that the general assumption within the group is that a LFN has no MIPv6 MN capability. The fact that the LFNs are 'fixed' w.r.t. the MR's topology does not mean that these nodes are fixed w.r.t to the global topology. So isn't it correct to assume that these nodes may or may not be MIPv6-enabled? Thank you, Eranga From nemo-admin@ietf.org Thu Aug 21 23:09:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17006 for ; Thu, 21 Aug 2003 23:09:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q2IQ-0007xr-Ar; Thu, 21 Aug 2003 23:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q2Hs-0007xZ-BC for nemo@optimus.ietf.org; Thu, 21 Aug 2003 23:08:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16938 for ; Thu, 21 Aug 2003 23:08:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q2Hn-0005cZ-00 for nemo@ietf.org; Thu, 21 Aug 2003 23:08:23 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19q2Hm-0005c8-00 for nemo@ietf.org; Thu, 21 Aug 2003 23:08:23 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 3943C5D0EC; Fri, 22 Aug 2003 12:07:50 +0900 (JST) Date: Fri, 22 Aug 2003 12:03:46 +0900 From: Thierry Ernst To: Eranga Perera Cc: nemo@ietf.org Subject: Re: [NEMO] LFN terminology Message-Id: <20030822120346.6a025861.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > I need to clarify why is it that the general assumption within the group > is that a LFN has no MIPv6 MN capability. The fact that the LFNs are > 'fixed' w.r.t. the MR's topology does not mean that these nodes are fixed > w.r.t to the global topology. So isn't it correct to assume that these > nodes may or may not be MIPv6-enabled? If MNNs are operating the MN Operation of MIPv6, you would call them LMNs. The reason behind the definition of the LFN vs VMN vs LMN is that there are MNNs not who don't have MIPv6 capabilities at all. It helped fixing the requirements for Basic Support. I hope this does answer the question. Thierry From exim@www1.ietf.org Thu Aug 21 23:09:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17028 for ; Thu, 21 Aug 2003 23:09:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q2IY-0007yr-Q1 for nemo-archive@odin.ietf.org; Thu, 21 Aug 2003 23:09:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7M39AQh030670 for nemo-archive@odin.ietf.org; Thu, 21 Aug 2003 23:09:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q2IW-0007ya-Vn for nemo-web-archive@optimus.ietf.org; Thu, 21 Aug 2003 23:09:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16978 for ; Thu, 21 Aug 2003 23:09:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q2IT-0005dD-00 for nemo-web-archive@ietf.org; Thu, 21 Aug 2003 23:09:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19q2IS-0005dA-00 for nemo-web-archive@ietf.org; Thu, 21 Aug 2003 23:09:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q2IQ-0007xr-Ar; Thu, 21 Aug 2003 23:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q2Hs-0007xZ-BC for nemo@optimus.ietf.org; Thu, 21 Aug 2003 23:08:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16938 for ; Thu, 21 Aug 2003 23:08:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q2Hn-0005cZ-00 for nemo@ietf.org; Thu, 21 Aug 2003 23:08:23 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19q2Hm-0005c8-00 for nemo@ietf.org; Thu, 21 Aug 2003 23:08:23 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 3943C5D0EC; Fri, 22 Aug 2003 12:07:50 +0900 (JST) Date: Fri, 22 Aug 2003 12:03:46 +0900 From: Thierry Ernst To: Eranga Perera Cc: nemo@ietf.org Subject: Re: [NEMO] LFN terminology Message-Id: <20030822120346.6a025861.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > I need to clarify why is it that the general assumption within the group > is that a LFN has no MIPv6 MN capability. The fact that the LFNs are > 'fixed' w.r.t. the MR's topology does not mean that these nodes are fixed > w.r.t to the global topology. So isn't it correct to assume that these > nodes may or may not be MIPv6-enabled? If MNNs are operating the MN Operation of MIPv6, you would call them LMNs. The reason behind the definition of the LFN vs VMN vs LMN is that there are MNNs not who don't have MIPv6 capabilities at all. It helped fixing the requirements for Basic Support. I hope this does answer the question. Thierry From nemo-admin@ietf.org Thu Aug 21 23:49:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18662 for ; Thu, 21 Aug 2003 23:49:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q2v6-0000x6-Sy; Thu, 21 Aug 2003 23:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q2uD-0000wD-Ft for nemo@optimus.ietf.org; Thu, 21 Aug 2003 23:48:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18602 for ; Thu, 21 Aug 2003 23:47:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q2uB-00061x-00 for nemo@ietf.org; Thu, 21 Aug 2003 23:48:03 -0400 Received: from mobqos.ee.unsw.edu.au ([129.94.230.70]) by ietf-mx with esmtp (Exim 4.12) id 19q2uA-00061j-00 for nemo@ietf.org; Thu, 21 Aug 2003 23:48:02 -0400 Received: from eranga (helo=localhost) by mobqos.ee.unsw.edu.au with local-esmtp (Exim 3.35 #1 (Debian)) id 19q2tb-0008Ez-00; Fri, 22 Aug 2003 13:47:27 +1000 Date: Fri, 22 Aug 2003 13:47:27 +1000 (EST) From: Eranga Perera To: Thierry Ernst cc: nemo@ietf.org Subject: Re: [NEMO] LFN terminology In-Reply-To: <20030822120346.6a025861.ernst@sfc.wide.ad.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Thierry, sorry to bother you again. But don't you think that in that case we need to redefine the terminology cause IMHO both these types of nodes i.e. LFNs and LMNs are mobile w.r.t. to the global topology. Shouldn't the term fixed be used to imply that the node is fixed w.r.t. to the MR and this has nothing to do with MIPv6 capability. Possible scenario: an audio player of a car capable of downloading MP3 files (MIPv6 or MIP enabled) Would you categorize such a node as a LFN or a LMN ? Basically what I am trying to humbly point out is that Fixed w.r.t the MR doesn't mean that a node can be categorised as MIPv6 incapable. Thank You, Eranga On Fri, 22 Aug 2003, Thierry Ernst wrote: > > Hi, > > > I need to clarify why is it that the general assumption within the group > > is that a LFN has no MIPv6 MN capability. The fact that the LFNs are > > 'fixed' w.r.t. the MR's topology does not mean that these nodes are fixed > > w.r.t to the global topology. So isn't it correct to assume that these > > nodes may or may not be MIPv6-enabled? > > If MNNs are operating the MN Operation of MIPv6, you would call them > LMNs. The reason behind the definition of the LFN vs VMN vs LMN is that > there are MNNs not who don't have MIPv6 capabilities at all. It helped > fixing the requirements for Basic Support. > > I hope this does answer the question. > Thierry > From exim@www1.ietf.org Thu Aug 21 23:49:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18680 for ; Thu, 21 Aug 2003 23:49:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q2vA-0000yH-46 for nemo-archive@odin.ietf.org; Thu, 21 Aug 2003 23:49:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7M3n4CI003727 for nemo-archive@odin.ietf.org; Thu, 21 Aug 2003 23:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q2v9-0000y2-Un for nemo-web-archive@optimus.ietf.org; Thu, 21 Aug 2003 23:49:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18631 for ; Thu, 21 Aug 2003 23:48:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q2v7-00062Y-00 for nemo-web-archive@ietf.org; Thu, 21 Aug 2003 23:49:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19q2v7-00062V-00 for nemo-web-archive@ietf.org; Thu, 21 Aug 2003 23:49:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q2v6-0000x6-Sy; Thu, 21 Aug 2003 23:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q2uD-0000wD-Ft for nemo@optimus.ietf.org; Thu, 21 Aug 2003 23:48:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18602 for ; Thu, 21 Aug 2003 23:47:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q2uB-00061x-00 for nemo@ietf.org; Thu, 21 Aug 2003 23:48:03 -0400 Received: from mobqos.ee.unsw.edu.au ([129.94.230.70]) by ietf-mx with esmtp (Exim 4.12) id 19q2uA-00061j-00 for nemo@ietf.org; Thu, 21 Aug 2003 23:48:02 -0400 Received: from eranga (helo=localhost) by mobqos.ee.unsw.edu.au with local-esmtp (Exim 3.35 #1 (Debian)) id 19q2tb-0008Ez-00; Fri, 22 Aug 2003 13:47:27 +1000 Date: Fri, 22 Aug 2003 13:47:27 +1000 (EST) From: Eranga Perera To: Thierry Ernst cc: nemo@ietf.org Subject: Re: [NEMO] LFN terminology In-Reply-To: <20030822120346.6a025861.ernst@sfc.wide.ad.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Thierry, sorry to bother you again. But don't you think that in that case we need to redefine the terminology cause IMHO both these types of nodes i.e. LFNs and LMNs are mobile w.r.t. to the global topology. Shouldn't the term fixed be used to imply that the node is fixed w.r.t. to the MR and this has nothing to do with MIPv6 capability. Possible scenario: an audio player of a car capable of downloading MP3 files (MIPv6 or MIP enabled) Would you categorize such a node as a LFN or a LMN ? Basically what I am trying to humbly point out is that Fixed w.r.t the MR doesn't mean that a node can be categorised as MIPv6 incapable. Thank You, Eranga On Fri, 22 Aug 2003, Thierry Ernst wrote: > > Hi, > > > I need to clarify why is it that the general assumption within the group > > is that a LFN has no MIPv6 MN capability. The fact that the LFNs are > > 'fixed' w.r.t. the MR's topology does not mean that these nodes are fixed > > w.r.t to the global topology. So isn't it correct to assume that these > > nodes may or may not be MIPv6-enabled? > > If MNNs are operating the MN Operation of MIPv6, you would call them > LMNs. The reason behind the definition of the LFN vs VMN vs LMN is that > there are MNNs not who don't have MIPv6 capabilities at all. It helped > fixing the requirements for Basic Support. > > I hope this does answer the question. > Thierry > From nemo-admin@ietf.org Thu Aug 21 23:58:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18936 for ; Thu, 21 Aug 2003 23:58:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q33p-0001CH-C8; Thu, 21 Aug 2003 23:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q32z-0001Ab-Ij for nemo@optimus.ietf.org; Thu, 21 Aug 2003 23:57:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18883 for ; Thu, 21 Aug 2003 23:57:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q32x-000668-00 for nemo@ietf.org; Thu, 21 Aug 2003 23:57:07 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19q32w-00065y-00 for nemo@ietf.org; Thu, 21 Aug 2003 23:57:06 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 22D7A5D0CA; Fri, 22 Aug 2003 12:56:37 +0900 (JST) Date: Fri, 22 Aug 2003 12:52:33 +0900 From: Thierry Ernst To: Eranga Perera Cc: nemo@ietf.org Subject: Re: [NEMO] LFN terminology Message-Id: <20030822125233.772ff430.ernst@sfc.wide.ad.jp> In-Reply-To: References: <20030822120346.6a025861.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > sorry to bother you again. But don't you think that in that case we need > to redefine the terminology cause IMHO both these types of nodes i.e. LFNs > and LMNs are mobile w.r.t. to the global topology. Shouldn't the term > fixed be used to imply that the node is fixed w.r.t. to the MR and this > has nothing to do with MIPv6 capability. > Possible scenario: > an audio player of a car capable of downloading MP3 files (MIPv6 or MIP > enabled) Would you categorize such a node as a LFN or a LMN ? > Basically what I am trying to humbly point out is that Fixed w.r.t the MR > doesn't mean that a node can be categorised as MIPv6 incapable. I think we already came across this discussion, so please check the archives. A node that doesn't change its point of attachment is fixed; if it's a MNN in the context of NEMO, it's a LFN. The LFN is no thing else that a standard IPv6 node, but in order to avoid saying "the fixed node located in the mobile network", we use the term LFN. On the other hand, a mobile node is a node that change its point of attachment. If this is operated by using mobile-IPv6, it's a MIPv6-enabled mobile node. If it's operated by NEMO Basic Support, it's a NEMO-enabled mobile node; it's it's by operating ad-hoc protocol AODV it's an AODV-enabled mobile node. If this node is located in the mobile network, it could either be a VMN or a LFN. Thierry. > > Thank You, > Eranga > > > > > On Fri, 22 Aug 2003, Thierry Ernst wrote: > > > > > Hi, > > > > > I need to clarify why is it that the general assumption within the group > > > is that a LFN has no MIPv6 MN capability. The fact that the LFNs are > > > 'fixed' w.r.t. the MR's topology does not mean that these nodes are fixed > > > w.r.t to the global topology. So isn't it correct to assume that these > > > nodes may or may not be MIPv6-enabled? > > > > If MNNs are operating the MN Operation of MIPv6, you would call them > > LMNs. The reason behind the definition of the LFN vs VMN vs LMN is that > > there are MNNs not who don't have MIPv6 capabilities at all. It helped > > fixing the requirements for Basic Support. > > > > I hope this does answer the question. > > Thierry > > > > > -- Thierry Ernst, WIDE at Keio University, Japan E-mail: ernst@sfc.wide.ad.jp Web: http://www.sfc.wide.ad.jp/~ernst/ -- Jun Murai Lab Keio University K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki Kanagawa, 212-0054 Japan Phone : +81-44-580-1600 Fax : +81-44-580-1437 Mobile: 090-9815-8023 From exim@www1.ietf.org Thu Aug 21 23:58:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18954 for ; Thu, 21 Aug 2003 23:58:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q33r-0001Da-ET for nemo-archive@odin.ietf.org; Thu, 21 Aug 2003 23:58:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7M3w3YY004676 for nemo-archive@odin.ietf.org; Thu, 21 Aug 2003 23:58:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q33r-0001DH-7P for nemo-web-archive@optimus.ietf.org; Thu, 21 Aug 2003 23:58:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18897 for ; Thu, 21 Aug 2003 23:57:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q33o-00066R-00 for nemo-web-archive@ietf.org; Thu, 21 Aug 2003 23:58:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19q33n-00066N-00 for nemo-web-archive@ietf.org; Thu, 21 Aug 2003 23:57:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q33p-0001CH-C8; Thu, 21 Aug 2003 23:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q32z-0001Ab-Ij for nemo@optimus.ietf.org; Thu, 21 Aug 2003 23:57:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18883 for ; Thu, 21 Aug 2003 23:57:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q32x-000668-00 for nemo@ietf.org; Thu, 21 Aug 2003 23:57:07 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19q32w-00065y-00 for nemo@ietf.org; Thu, 21 Aug 2003 23:57:06 -0400 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 22D7A5D0CA; Fri, 22 Aug 2003 12:56:37 +0900 (JST) Date: Fri, 22 Aug 2003 12:52:33 +0900 From: Thierry Ernst To: Eranga Perera Cc: nemo@ietf.org Subject: Re: [NEMO] LFN terminology Message-Id: <20030822125233.772ff430.ernst@sfc.wide.ad.jp> In-Reply-To: References: <20030822120346.6a025861.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > sorry to bother you again. But don't you think that in that case we need > to redefine the terminology cause IMHO both these types of nodes i.e. LFNs > and LMNs are mobile w.r.t. to the global topology. Shouldn't the term > fixed be used to imply that the node is fixed w.r.t. to the MR and this > has nothing to do with MIPv6 capability. > Possible scenario: > an audio player of a car capable of downloading MP3 files (MIPv6 or MIP > enabled) Would you categorize such a node as a LFN or a LMN ? > Basically what I am trying to humbly point out is that Fixed w.r.t the MR > doesn't mean that a node can be categorised as MIPv6 incapable. I think we already came across this discussion, so please check the archives. A node that doesn't change its point of attachment is fixed; if it's a MNN in the context of NEMO, it's a LFN. The LFN is no thing else that a standard IPv6 node, but in order to avoid saying "the fixed node located in the mobile network", we use the term LFN. On the other hand, a mobile node is a node that change its point of attachment. If this is operated by using mobile-IPv6, it's a MIPv6-enabled mobile node. If it's operated by NEMO Basic Support, it's a NEMO-enabled mobile node; it's it's by operating ad-hoc protocol AODV it's an AODV-enabled mobile node. If this node is located in the mobile network, it could either be a VMN or a LFN. Thierry. > > Thank You, > Eranga > > > > > On Fri, 22 Aug 2003, Thierry Ernst wrote: > > > > > Hi, > > > > > I need to clarify why is it that the general assumption within the group > > > is that a LFN has no MIPv6 MN capability. The fact that the LFNs are > > > 'fixed' w.r.t. the MR's topology does not mean that these nodes are fixed > > > w.r.t to the global topology. So isn't it correct to assume that these > > > nodes may or may not be MIPv6-enabled? > > > > If MNNs are operating the MN Operation of MIPv6, you would call them > > LMNs. The reason behind the definition of the LFN vs VMN vs LMN is that > > there are MNNs not who don't have MIPv6 capabilities at all. It helped > > fixing the requirements for Basic Support. > > > > I hope this does answer the question. > > Thierry > > > > > -- Thierry Ernst, WIDE at Keio University, Japan E-mail: ernst@sfc.wide.ad.jp Web: http://www.sfc.wide.ad.jp/~ernst/ -- Jun Murai Lab Keio University K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki Kanagawa, 212-0054 Japan Phone : +81-44-580-1600 Fax : +81-44-580-1437 Mobile: 090-9815-8023 From nemo-admin@ietf.org Fri Aug 22 00:30:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20099 for ; Fri, 22 Aug 2003 00:30:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q3Yo-0002VU-5D; Fri, 22 Aug 2003 00:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q3Xr-0002V5-Vm for nemo@optimus.ietf.org; Fri, 22 Aug 2003 00:29:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20054 for ; Fri, 22 Aug 2003 00:28:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q3Xp-0006OI-00 for nemo@ietf.org; Fri, 22 Aug 2003 00:29:01 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 19q3Xo-0006Nw-00 for nemo@ietf.org; Fri, 22 Aug 2003 00:29:00 -0400 Received: from [64.36.73.245] (home5.kniveton.com [64.36.73.245]) by multihop.net (8.12.9/8.12.9) with ESMTP id h7M4Voql035803; Thu, 21 Aug 2003 21:31:51 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 21 Aug 2003 21:28:53 -0700 Subject: Re: [NEMO] LFN terminology From: "T.J. Kniveton" To: Eranga Perera CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 8/21/03 8:47 PM, "Eranga Perera" wrote: > > Hi Thierry, > sorry to bother you again. But don't you think that in that case we need > to redefine the terminology cause IMHO both these types of nodes i.e. LFNs > and LMNs are mobile w.r.t. to the global topology. Shouldn't the term > fixed be used to imply that the node is fixed w.r.t. to the MR and this > has nothing to do with MIPv6 capability. > Possible scenario: > an audio player of a car capable of downloading MP3 files (MIPv6 or MIP > enabled) Would you categorize such a node as a LFN or a LMN ? > Basically what I am trying to humbly point out is that Fixed w.r.t the MR > doesn't mean that a node can be categorised as MIPv6 incapable. > > Thank You, > Eranga Forget about NEMO for a second. If a node uses Mobile IPv6, it is a mobile node. If it is on its home network, call it a local mobile node. If it is visiting from another network and is using a CoA, it's a visiting mobile node. If the node is at home and doesn't use mobile IPv6 (whether it is capable to or not), it is a local fixed node. Now, let the MR pick up the network's root point of attachment and move it around. The nodes on that network remain LMNs, VMNs, and LFNs as they were before. This identity is relative to the network, and hence relative to the MR. In NEMO basic support, the nodes need not know they are on a mobile network at all. TJ From exim@www1.ietf.org Fri Aug 22 00:30:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20117 for ; Fri, 22 Aug 2003 00:30:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q3Yw-0002Xx-Sr for nemo-archive@odin.ietf.org; Fri, 22 Aug 2003 00:30:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7M4UAxv009783 for nemo-archive@odin.ietf.org; Fri, 22 Aug 2003 00:30:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q3Yw-0002Xi-NO for nemo-web-archive@optimus.ietf.org; Fri, 22 Aug 2003 00:30:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20079 for ; Fri, 22 Aug 2003 00:30:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q3Yu-0006OV-00 for nemo-web-archive@ietf.org; Fri, 22 Aug 2003 00:30:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19q3Yt-0006OS-00 for nemo-web-archive@ietf.org; Fri, 22 Aug 2003 00:30:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q3Yo-0002VU-5D; Fri, 22 Aug 2003 00:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q3Xr-0002V5-Vm for nemo@optimus.ietf.org; Fri, 22 Aug 2003 00:29:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20054 for ; Fri, 22 Aug 2003 00:28:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q3Xp-0006OI-00 for nemo@ietf.org; Fri, 22 Aug 2003 00:29:01 -0400 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 19q3Xo-0006Nw-00 for nemo@ietf.org; Fri, 22 Aug 2003 00:29:00 -0400 Received: from [64.36.73.245] (home5.kniveton.com [64.36.73.245]) by multihop.net (8.12.9/8.12.9) with ESMTP id h7M4Voql035803; Thu, 21 Aug 2003 21:31:51 -0700 (PDT) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 21 Aug 2003 21:28:53 -0700 Subject: Re: [NEMO] LFN terminology From: "T.J. Kniveton" To: Eranga Perera CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 8/21/03 8:47 PM, "Eranga Perera" wrote: > > Hi Thierry, > sorry to bother you again. But don't you think that in that case we need > to redefine the terminology cause IMHO both these types of nodes i.e. LFNs > and LMNs are mobile w.r.t. to the global topology. Shouldn't the term > fixed be used to imply that the node is fixed w.r.t. to the MR and this > has nothing to do with MIPv6 capability. > Possible scenario: > an audio player of a car capable of downloading MP3 files (MIPv6 or MIP > enabled) Would you categorize such a node as a LFN or a LMN ? > Basically what I am trying to humbly point out is that Fixed w.r.t the MR > doesn't mean that a node can be categorised as MIPv6 incapable. > > Thank You, > Eranga Forget about NEMO for a second. If a node uses Mobile IPv6, it is a mobile node. If it is on its home network, call it a local mobile node. If it is visiting from another network and is using a CoA, it's a visiting mobile node. If the node is at home and doesn't use mobile IPv6 (whether it is capable to or not), it is a local fixed node. Now, let the MR pick up the network's root point of attachment and move it around. The nodes on that network remain LMNs, VMNs, and LFNs as they were before. This identity is relative to the network, and hence relative to the MR. In NEMO basic support, the nodes need not know they are on a mobile network at all. TJ From nemo-admin@ietf.org Fri Aug 22 06:46:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16246 for ; Fri, 22 Aug 2003 06:46:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q9Qh-0003zO-09; Fri, 22 Aug 2003 06:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q9Qe-0003yv-4Q for nemo@optimus.ietf.org; Fri, 22 Aug 2003 06:46:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16199 for ; Fri, 22 Aug 2003 06:45:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q9Qa-0002An-00 for nemo@ietf.org; Fri, 22 Aug 2003 06:45:56 -0400 Received: from mobqos.ee.unsw.edu.au ([129.94.230.70]) by ietf-mx with esmtp (Exim 4.12) id 19q9QZ-0002AS-00 for nemo@ietf.org; Fri, 22 Aug 2003 06:45:55 -0400 Received: from eranga (helo=localhost) by mobqos.ee.unsw.edu.au with local-esmtp (Exim 3.35 #1 (Debian)) id 19q9Pt-0003VU-00; Fri, 22 Aug 2003 20:45:13 +1000 Date: Fri, 22 Aug 2003 20:45:12 +1000 (EST) From: Eranga Perera To: Thierry Ernst , "T.J. Kniveton" cc: nemo@ietf.org Subject: Re: [NEMO] LFN terminology In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi guys, Thank you for clarifying this issue. Regards, Eranga On Thu, 21 Aug 2003, T.J. Kniveton wrote: > On 8/21/03 8:47 PM, "Eranga Perera" wrote: > > > > > Hi Thierry, > > sorry to bother you again. But don't you think that in that case we need > > to redefine the terminology cause IMHO both these types of nodes i.e. LFNs > > and LMNs are mobile w.r.t. to the global topology. Shouldn't the term > > fixed be used to imply that the node is fixed w.r.t. to the MR and this > > has nothing to do with MIPv6 capability. > > Possible scenario: > > an audio player of a car capable of downloading MP3 files (MIPv6 or MIP > > enabled) Would you categorize such a node as a LFN or a LMN ? > > Basically what I am trying to humbly point out is that Fixed w.r.t the MR > > doesn't mean that a node can be categorised as MIPv6 incapable. > > > > Thank You, > > Eranga > > Forget about NEMO for a second. If a node uses Mobile IPv6, it is a mobile > node. If it is on its home network, call it a local mobile node. If it is > visiting from another network and is using a CoA, it's a visiting mobile > node. > > If the node is at home and doesn't use mobile IPv6 (whether it is capable to > or not), it is a local fixed node. > > Now, let the MR pick up the network's root point of attachment and move it > around. The nodes on that network remain LMNs, VMNs, and LFNs as they were > before. This identity is relative to the network, and hence relative to the > MR. In NEMO basic support, the nodes need not know they are on a mobile > network at all. > > TJ > > From exim@www1.ietf.org Fri Aug 22 06:46:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16267 for ; Fri, 22 Aug 2003 06:46:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q9Ql-00040Q-JW for nemo-archive@odin.ietf.org; Fri, 22 Aug 2003 06:46:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MAk7fb015399 for nemo-archive@odin.ietf.org; Fri, 22 Aug 2003 06:46:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q9Ql-00040I-CP for nemo-web-archive@optimus.ietf.org; Fri, 22 Aug 2003 06:46:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16210 for ; Fri, 22 Aug 2003 06:46:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q9Qh-0002B8-00 for nemo-web-archive@ietf.org; Fri, 22 Aug 2003 06:46:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19q9Qg-0002B5-00 for nemo-web-archive@ietf.org; Fri, 22 Aug 2003 06:46:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q9Qh-0003zO-09; Fri, 22 Aug 2003 06:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q9Qe-0003yv-4Q for nemo@optimus.ietf.org; Fri, 22 Aug 2003 06:46:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16199 for ; Fri, 22 Aug 2003 06:45:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q9Qa-0002An-00 for nemo@ietf.org; Fri, 22 Aug 2003 06:45:56 -0400 Received: from mobqos.ee.unsw.edu.au ([129.94.230.70]) by ietf-mx with esmtp (Exim 4.12) id 19q9QZ-0002AS-00 for nemo@ietf.org; Fri, 22 Aug 2003 06:45:55 -0400 Received: from eranga (helo=localhost) by mobqos.ee.unsw.edu.au with local-esmtp (Exim 3.35 #1 (Debian)) id 19q9Pt-0003VU-00; Fri, 22 Aug 2003 20:45:13 +1000 Date: Fri, 22 Aug 2003 20:45:12 +1000 (EST) From: Eranga Perera To: Thierry Ernst , "T.J. Kniveton" cc: nemo@ietf.org Subject: Re: [NEMO] LFN terminology In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi guys, Thank you for clarifying this issue. Regards, Eranga On Thu, 21 Aug 2003, T.J. Kniveton wrote: > On 8/21/03 8:47 PM, "Eranga Perera" wrote: > > > > > Hi Thierry, > > sorry to bother you again. But don't you think that in that case we need > > to redefine the terminology cause IMHO both these types of nodes i.e. LFNs > > and LMNs are mobile w.r.t. to the global topology. Shouldn't the term > > fixed be used to imply that the node is fixed w.r.t. to the MR and this > > has nothing to do with MIPv6 capability. > > Possible scenario: > > an audio player of a car capable of downloading MP3 files (MIPv6 or MIP > > enabled) Would you categorize such a node as a LFN or a LMN ? > > Basically what I am trying to humbly point out is that Fixed w.r.t the MR > > doesn't mean that a node can be categorised as MIPv6 incapable. > > > > Thank You, > > Eranga > > Forget about NEMO for a second. If a node uses Mobile IPv6, it is a mobile > node. If it is on its home network, call it a local mobile node. If it is > visiting from another network and is using a CoA, it's a visiting mobile > node. > > If the node is at home and doesn't use mobile IPv6 (whether it is capable to > or not), it is a local fixed node. > > Now, let the MR pick up the network's root point of attachment and move it > around. The nodes on that network remain LMNs, VMNs, and LFNs as they were > before. This identity is relative to the network, and hence relative to the > MR. In NEMO basic support, the nodes need not know they are on a mobile > network at all. > > TJ > > From nemo-admin@ietf.org Thu Aug 28 09:04:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11220 for ; Thu, 28 Aug 2003 09:04:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sKJw-0007c2-C7; Thu, 28 Aug 2003 06:48:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sGvs-0003EZ-8K for nemo@optimus.ietf.org; Thu, 28 Aug 2003 03:11:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10124 for ; Thu, 28 Aug 2003 03:10:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sGvn-0005jj-00 for nemo@ietf.org; Thu, 28 Aug 2003 03:10:55 -0400 Received: from ns.sait.samsung.co.kr ([202.20.142.13]) by ietf-mx with esmtp (Exim 4.12) id 19sGvm-0005j4-00 for nemo@ietf.org; Thu, 28 Aug 2003 03:10:54 -0400 Received: from sait1000 (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.9/8.12.1) with SMTP id h7S7AIJ4008682 for ; Thu, 28 Aug 2003 16:10:19 +0900 (KST) Message-ID: <009e01c36d33$6fa91ee0$ed2f024b@sait1000> Reply-To: "Jung-Hoon Cheon" From: "Jung-Hoon Cheon" To: Subject: [nemo] RA with router lifetime set to zero Date: Thu, 28 Aug 2003 16:10:17 +0900 Organization: Samsung AIT MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGkgYWxsOw0KDQpJIGhhdmUgYSBjb21tZW50Lg0KDQpBY2NvcmRpbmcgdG8gdGhlIFtSRkMyNDYx XSwNClJBIHdpdGggUm91dGVyIExpZmV0aW1lIGZpZWxkIHNldCB0byB6ZXJvIGluZGljYXRlcyB0 aGF0IHRoZSByb3V0ZXIgaXMgbm90DQphIGRlZmF1bHQgcm91dGVyIGFuZCBTSE9VTEQgTk9UIGFw cGVhciBvbiB0aGUgZGVmYXVsdCByb3V0ZXIgbGlzdC4NCg0KSW4gTkVNTyBiYXNpYyBzdXBwb3J0 IGRyYWZ0W1NlYy4gNS42XSwgDQpBIE1SIE1BWSBiZSBjb25maWd1cmVkIHRvIHNlbmQgYSBSQSBv biB0aGUgaW50ZXJmYWNlIGF0dGFjaGVkIHRvIHRoZSBob21lDQpsaW5rLiBUaGUgdmFsdWUgb2Yg dGhlIFJvdXRlciBMaWZldGltZSBmaWVsZCBNVVNUIHNldCB0byB6ZXJvIHRvIHByZXZlbnQgDQpv dGhlciBub2RlcyBmcm9tIGNvbmZpZ3VyaW5nIHRoZSBNUiBhcyB0aGUgZGVmYXVsdCByb3V0ZXIu DQoNCldoZW4gaG9zdHMgb24gdGhlIGxpbmsgcmVjZWl2ZSB0aGUgUkEocm91dGVyIGxpZmV0aW1l IHNldCB0byB6ZXJvKSwgdGhleSBzaG91bGQgZGVsZXRlIHRoZSBlbnRyeSBvbiB0aGUgZGVmYXVs dCByb3V0ZXIgbGlzdC4NClVubGlrZSBJUHY0LCB0aGUgUkEgZG9lc24ndCBjb250YWluIGEgcHJl ZmVyZW5jZSBmaWVsZCwgd2hpY2ggaGVscHMgc2V0IHRvIHNwZWNpZmljIHJvdXRlcihlLmcuIE1S KSBvbiB0aGUgZGVmYXVsdCByb3V0ZXIgbGlzdC4NCg0KSSB0aGluayB0aGF0IGl0J3MgdG9vIHN0 cmljdCB0byBNUiBvbiB0aGUgaG9tZSBsaW5rLg0KQWxzbywgaWYgdGhlcmUgaXMgbm8gcm91dGVy IHdpdGhpbiB0aGUgbGluaywgaG93IGNhbiBkbyByb3V0aW5nIGZvciBob3N0cz8NCg0KSG93IGFi b3V0IHRoYXQ/DQoNCkJlc3QgUmVnYXJkcy4NCkp1bmctSG9vbiBDaGVvbg== From exim@www1.ietf.org Thu Aug 28 15:51:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12951 for ; Thu, 28 Aug 2003 15:51:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sQ7W-0001Dz-QF for nemo-archive@odin.ietf.org; Thu, 28 Aug 2003 12:59:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SGxc1L004703 for nemo-archive@odin.ietf.org; Thu, 28 Aug 2003 12:59:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sMRP-0007tj-2h for nemo-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 09:03:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11138 for ; Thu, 28 Aug 2003 09:03:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sMRN-0006DZ-00 for nemo-web-archive@ietf.org; Thu, 28 Aug 2003 09:03:53 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sMRN-0006DT-00 for nemo-web-archive@ietf.org; Thu, 28 Aug 2003 09:03:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sKJw-0007c2-C7; Thu, 28 Aug 2003 06:48:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sGvs-0003EZ-8K for nemo@optimus.ietf.org; Thu, 28 Aug 2003 03:11:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10124 for ; Thu, 28 Aug 2003 03:10:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sGvn-0005jj-00 for nemo@ietf.org; Thu, 28 Aug 2003 03:10:55 -0400 Received: from ns.sait.samsung.co.kr ([202.20.142.13]) by ietf-mx with esmtp (Exim 4.12) id 19sGvm-0005j4-00 for nemo@ietf.org; Thu, 28 Aug 2003 03:10:54 -0400 Received: from sait1000 (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.9/8.12.1) with SMTP id h7S7AIJ4008682 for ; Thu, 28 Aug 2003 16:10:19 +0900 (KST) Message-ID: <009e01c36d33$6fa91ee0$ed2f024b@sait1000> Reply-To: "Jung-Hoon Cheon" From: "Jung-Hoon Cheon" To: Subject: [nemo] RA with router lifetime set to zero Date: Thu, 28 Aug 2003 16:10:17 +0900 Organization: Samsung AIT MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgYWxsOw0KDQpJIGhhdmUgYSBjb21tZW50Lg0KDQpBY2NvcmRpbmcgdG8gdGhlIFtSRkMyNDYx XSwNClJBIHdpdGggUm91dGVyIExpZmV0aW1lIGZpZWxkIHNldCB0byB6ZXJvIGluZGljYXRlcyB0 aGF0IHRoZSByb3V0ZXIgaXMgbm90DQphIGRlZmF1bHQgcm91dGVyIGFuZCBTSE9VTEQgTk9UIGFw cGVhciBvbiB0aGUgZGVmYXVsdCByb3V0ZXIgbGlzdC4NCg0KSW4gTkVNTyBiYXNpYyBzdXBwb3J0 IGRyYWZ0W1NlYy4gNS42XSwgDQpBIE1SIE1BWSBiZSBjb25maWd1cmVkIHRvIHNlbmQgYSBSQSBv biB0aGUgaW50ZXJmYWNlIGF0dGFjaGVkIHRvIHRoZSBob21lDQpsaW5rLiBUaGUgdmFsdWUgb2Yg dGhlIFJvdXRlciBMaWZldGltZSBmaWVsZCBNVVNUIHNldCB0byB6ZXJvIHRvIHByZXZlbnQgDQpv dGhlciBub2RlcyBmcm9tIGNvbmZpZ3VyaW5nIHRoZSBNUiBhcyB0aGUgZGVmYXVsdCByb3V0ZXIu DQoNCldoZW4gaG9zdHMgb24gdGhlIGxpbmsgcmVjZWl2ZSB0aGUgUkEocm91dGVyIGxpZmV0aW1l IHNldCB0byB6ZXJvKSwgdGhleSBzaG91bGQgZGVsZXRlIHRoZSBlbnRyeSBvbiB0aGUgZGVmYXVs dCByb3V0ZXIgbGlzdC4NClVubGlrZSBJUHY0LCB0aGUgUkEgZG9lc24ndCBjb250YWluIGEgcHJl ZmVyZW5jZSBmaWVsZCwgd2hpY2ggaGVscHMgc2V0IHRvIHNwZWNpZmljIHJvdXRlcihlLmcuIE1S KSBvbiB0aGUgZGVmYXVsdCByb3V0ZXIgbGlzdC4NCg0KSSB0aGluayB0aGF0IGl0J3MgdG9vIHN0 cmljdCB0byBNUiBvbiB0aGUgaG9tZSBsaW5rLg0KQWxzbywgaWYgdGhlcmUgaXMgbm8gcm91dGVy IHdpdGhpbiB0aGUgbGluaywgaG93IGNhbiBkbyByb3V0aW5nIGZvciBob3N0cz8NCg0KSG93IGFi b3V0IHRoYXQ/DQoNCkJlc3QgUmVnYXJkcy4NCkp1bmctSG9vbiBDaGVvbg== From nemo-admin@ietf.org Thu Aug 28 20:37:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05001 for ; Thu, 28 Aug 2003 20:37:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sSw6-0001lB-WA; Thu, 28 Aug 2003 16:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sQIa-0001xy-NB for nemo@optimus.ietf.org; Thu, 28 Aug 2003 13:11:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01046 for ; Thu, 28 Aug 2003 13:10:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sQIY-00031W-00 for nemo@ietf.org; Thu, 28 Aug 2003 13:11:02 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19sQIX-00030t-00 for nemo@ietf.org; Thu, 28 Aug 2003 13:11:01 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7SHAQK26354; Thu, 28 Aug 2003 10:10:26 -0700 X-mProtect: <200308281710> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhBx8yT; Thu, 28 Aug 2003 10:10:25 PDT Message-ID: <3F4E3782.DC4A7E68@iprg.nokia.com> Date: Thu, 28 Aug 2003 10:10:26 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jung-Hoon Cheon CC: nemo@ietf.org Subject: Re: [nemo] RA with router lifetime set to zero References: <009e01c36d33$6fa91ee0$ed2f024b@sait1000> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit in one of the earlier discussions on the mailing list (I dont remember which thread) it was concluded that the Mobile Network will not be a transit network. no node on the home link should configure the MR as the default router. MR should be default router only for nodes inside the Mobile Network. thats why the draft says the lifetime for the RA sent on the MR's "egress" interface MUST be set to zero. Jung-Hoon Cheon wrote: > > I think that it's too strict to MR on the home link. its not. that is the correct behavior. > Also, if there is no router within the link, how can do routing for hosts? there is atleast the Home Agent. and theres got a router which aggregates the home link (and the Mobile Networks that belong to the home link). Vijay From exim@www1.ietf.org Fri Aug 29 02:19:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14839 for ; Fri, 29 Aug 2003 02:19:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sZr4-0005nO-LS for nemo-archive@odin.ietf.org; Thu, 28 Aug 2003 23:23:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T3NIC3022267 for nemo-archive@odin.ietf.org; Thu, 28 Aug 2003 23:23:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sXGP-00060A-Vl for nemo-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 20:37:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04966 for ; Thu, 28 Aug 2003 20:37:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sXGN-0002dT-00 for nemo-web-archive@ietf.org; Thu, 28 Aug 2003 20:37:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sXGN-0002dP-00 for nemo-web-archive@ietf.org; Thu, 28 Aug 2003 20:37:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sSw6-0001lB-WA; Thu, 28 Aug 2003 16:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sQIa-0001xy-NB for nemo@optimus.ietf.org; Thu, 28 Aug 2003 13:11:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01046 for ; Thu, 28 Aug 2003 13:10:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sQIY-00031W-00 for nemo@ietf.org; Thu, 28 Aug 2003 13:11:02 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19sQIX-00030t-00 for nemo@ietf.org; Thu, 28 Aug 2003 13:11:01 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7SHAQK26354; Thu, 28 Aug 2003 10:10:26 -0700 X-mProtect: <200308281710> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhBx8yT; Thu, 28 Aug 2003 10:10:25 PDT Message-ID: <3F4E3782.DC4A7E68@iprg.nokia.com> Date: Thu, 28 Aug 2003 10:10:26 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jung-Hoon Cheon CC: nemo@ietf.org Subject: Re: [nemo] RA with router lifetime set to zero References: <009e01c36d33$6fa91ee0$ed2f024b@sait1000> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit in one of the earlier discussions on the mailing list (I dont remember which thread) it was concluded that the Mobile Network will not be a transit network. no node on the home link should configure the MR as the default router. MR should be default router only for nodes inside the Mobile Network. thats why the draft says the lifetime for the RA sent on the MR's "egress" interface MUST be set to zero. Jung-Hoon Cheon wrote: > > I think that it's too strict to MR on the home link. its not. that is the correct behavior. > Also, if there is no router within the link, how can do routing for hosts? there is atleast the Home Agent. and theres got a router which aggregates the home link (and the Mobile Networks that belong to the home link). Vijay From nemo-admin@ietf.org Fri Aug 29 02:51:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18608 for ; Fri, 29 Aug 2003 02:51:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sZOn-000475-50; Thu, 28 Aug 2003 22:54:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sZIY-0003tU-D3 for nemo@optimus.ietf.org; Thu, 28 Aug 2003 22:47:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14859 for ; Thu, 28 Aug 2003 22:47:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sZIU-00053R-00 for nemo@ietf.org; Thu, 28 Aug 2003 22:47:34 -0400 Received: from ns.sait.samsung.co.kr ([202.20.142.13]) by ietf-mx with esmtp (Exim 4.12) id 19sZIT-00053D-00 for nemo@ietf.org; Thu, 28 Aug 2003 22:47:34 -0400 Received: from sait1000 (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.9/8.12.1) with SMTP id h7T2kuJ4026454 for ; Fri, 29 Aug 2003 11:46:57 +0900 (KST) Message-ID: <003901c36dd7$cfaeee10$ed2f024b@sait1000> Reply-To: "Jung-Hoon Cheon" From: "Jung-Hoon Cheon" To: References: <009e01c36d33$6fa91ee0$ed2f024b@sait1000> <3F4E3782.DC4A7E68@iprg.nokia.com> Subject: Re: [nemo] RA with router lifetime set to zero Date: Fri, 29 Aug 2003 11:46:56 +0900 Organization: Samsung AIT MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGkgVmlqYXksDQogDQogTm93LCBpdCdzIGNsZWFyIHRvIG1lLg0KVGhhbmsgeW91IGZvciBjbGFy aWZpbmcgdGhlIHBvaW50Lg0KIA0KIFJlZ2FyZHMuDQpKdW5nLUhvb24NCg0KLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJWaWpheSBEZXZhcmFwYWxsaSIgPHZpamF5ZEBpcHJn Lm5va2lhLmNvbT4NClRvOiAiSnVuZy1Ib29uIENoZW9uIiA8amhjaEBzYWl0LnNhbXN1bmcuY28u a3I+DQpDYzogPG5lbW9AaWV0Zi5vcmc+DQpTZW50OiBGcmlkYXksIEF1Z3VzdCAyOSwgMjAwMyAy OjEwIEFNDQpTdWJqZWN0OiBSZTogW25lbW9dIFJBIHdpdGggcm91dGVyIGxpZmV0aW1lIHNldCB0 byB6ZXJvDQoNCg0KPiANCj4gaW4gb25lIG9mIHRoZSBlYXJsaWVyIGRpc2N1c3Npb25zIG9uIHRo ZSBtYWlsaW5nIGxpc3QgKEkgZG9udA0KPiByZW1lbWJlciB3aGljaCB0aHJlYWQpIGl0IHdhcyBj b25jbHVkZWQgdGhhdCB0aGUgTW9iaWxlIE5ldHdvcmsNCj4gd2lsbCBub3QgYmUgYSB0cmFuc2l0 IG5ldHdvcmsuIG5vIG5vZGUgb24gdGhlIGhvbWUgbGluayBzaG91bGQNCj4gY29uZmlndXJlIHRo ZSBNUiBhcyB0aGUgZGVmYXVsdCByb3V0ZXIuIE1SIHNob3VsZCBiZSBkZWZhdWx0DQo+IHJvdXRl ciBvbmx5IGZvciBub2RlcyBpbnNpZGUgdGhlIE1vYmlsZSBOZXR3b3JrLg0KPiANCj4gdGhhdHMg d2h5IHRoZSBkcmFmdCBzYXlzIHRoZSBsaWZldGltZSBmb3IgdGhlIFJBIHNlbnQNCj4gb24gdGhl IE1SJ3MgImVncmVzcyIgaW50ZXJmYWNlIE1VU1QgYmUgc2V0IHRvIHplcm8uDQo+IA0KPiBKdW5n LUhvb24gQ2hlb24gd3JvdGU6DQo+ID4gDQo+ID4gSSB0aGluayB0aGF0IGl0J3MgdG9vIHN0cmlj dCB0byBNUiBvbiB0aGUgaG9tZSBsaW5rLg0KPiANCj4gaXRzIG5vdC4gdGhhdCBpcyB0aGUgY29y cmVjdCBiZWhhdmlvci4NCj4gDQo+ID4gQWxzbywgaWYgdGhlcmUgaXMgbm8gcm91dGVyIHdpdGhp biB0aGUgbGluaywgaG93IGNhbiBkbyByb3V0aW5nIGZvciBob3N0cz8NCj4gDQo+IHRoZXJlIGlz IGF0bGVhc3QgdGhlIEhvbWUgQWdlbnQuIGFuZCB0aGVyZXMgZ290IGEgcm91dGVyIA0KPiB3aGlj aCBhZ2dyZWdhdGVzIHRoZSBob21lIGxpbmsgKGFuZCB0aGUgTW9iaWxlIE5ldHdvcmtzIA0KPiB0 aGF0IGJlbG9uZyB0byB0aGUgaG9tZSBsaW5rKS4NCj4gDQo+IFZpamF5DQo+IA0KPiA= From exim@www1.ietf.org Fri Aug 29 03:32:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22023 for ; Fri, 29 Aug 2003 03:32:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sdUF-0003sX-Bb for nemo-archive@odin.ietf.org; Fri, 29 Aug 2003 03:15:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T7FxF9014910 for nemo-archive@odin.ietf.org; Fri, 29 Aug 2003 03:15:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sd5v-0002iU-Vl for nemo-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 02:50:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18581 for ; Fri, 29 Aug 2003 02:50:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sd5s-0002ZY-00 for nemo-web-archive@ietf.org; Fri, 29 Aug 2003 02:50:48 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sd5r-0002ZV-00 for nemo-web-archive@ietf.org; Fri, 29 Aug 2003 02:50:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sZOn-000475-50; Thu, 28 Aug 2003 22:54:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sZIY-0003tU-D3 for nemo@optimus.ietf.org; Thu, 28 Aug 2003 22:47:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14859 for ; Thu, 28 Aug 2003 22:47:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sZIU-00053R-00 for nemo@ietf.org; Thu, 28 Aug 2003 22:47:34 -0400 Received: from ns.sait.samsung.co.kr ([202.20.142.13]) by ietf-mx with esmtp (Exim 4.12) id 19sZIT-00053D-00 for nemo@ietf.org; Thu, 28 Aug 2003 22:47:34 -0400 Received: from sait1000 (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.9/8.12.1) with SMTP id h7T2kuJ4026454 for ; Fri, 29 Aug 2003 11:46:57 +0900 (KST) Message-ID: <003901c36dd7$cfaeee10$ed2f024b@sait1000> Reply-To: "Jung-Hoon Cheon" From: "Jung-Hoon Cheon" To: References: <009e01c36d33$6fa91ee0$ed2f024b@sait1000> <3F4E3782.DC4A7E68@iprg.nokia.com> Subject: Re: [nemo] RA with router lifetime set to zero Date: Fri, 29 Aug 2003 11:46:56 +0900 Organization: Samsung AIT MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgVmlqYXksDQogDQogTm93LCBpdCdzIGNsZWFyIHRvIG1lLg0KVGhhbmsgeW91IGZvciBjbGFy aWZpbmcgdGhlIHBvaW50Lg0KIA0KIFJlZ2FyZHMuDQpKdW5nLUhvb24NCg0KLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJWaWpheSBEZXZhcmFwYWxsaSIgPHZpamF5ZEBpcHJn Lm5va2lhLmNvbT4NClRvOiAiSnVuZy1Ib29uIENoZW9uIiA8amhjaEBzYWl0LnNhbXN1bmcuY28u a3I+DQpDYzogPG5lbW9AaWV0Zi5vcmc+DQpTZW50OiBGcmlkYXksIEF1Z3VzdCAyOSwgMjAwMyAy OjEwIEFNDQpTdWJqZWN0OiBSZTogW25lbW9dIFJBIHdpdGggcm91dGVyIGxpZmV0aW1lIHNldCB0 byB6ZXJvDQoNCg0KPiANCj4gaW4gb25lIG9mIHRoZSBlYXJsaWVyIGRpc2N1c3Npb25zIG9uIHRo ZSBtYWlsaW5nIGxpc3QgKEkgZG9udA0KPiByZW1lbWJlciB3aGljaCB0aHJlYWQpIGl0IHdhcyBj b25jbHVkZWQgdGhhdCB0aGUgTW9iaWxlIE5ldHdvcmsNCj4gd2lsbCBub3QgYmUgYSB0cmFuc2l0 IG5ldHdvcmsuIG5vIG5vZGUgb24gdGhlIGhvbWUgbGluayBzaG91bGQNCj4gY29uZmlndXJlIHRo ZSBNUiBhcyB0aGUgZGVmYXVsdCByb3V0ZXIuIE1SIHNob3VsZCBiZSBkZWZhdWx0DQo+IHJvdXRl ciBvbmx5IGZvciBub2RlcyBpbnNpZGUgdGhlIE1vYmlsZSBOZXR3b3JrLg0KPiANCj4gdGhhdHMg d2h5IHRoZSBkcmFmdCBzYXlzIHRoZSBsaWZldGltZSBmb3IgdGhlIFJBIHNlbnQNCj4gb24gdGhl IE1SJ3MgImVncmVzcyIgaW50ZXJmYWNlIE1VU1QgYmUgc2V0IHRvIHplcm8uDQo+IA0KPiBKdW5n LUhvb24gQ2hlb24gd3JvdGU6DQo+ID4gDQo+ID4gSSB0aGluayB0aGF0IGl0J3MgdG9vIHN0cmlj dCB0byBNUiBvbiB0aGUgaG9tZSBsaW5rLg0KPiANCj4gaXRzIG5vdC4gdGhhdCBpcyB0aGUgY29y cmVjdCBiZWhhdmlvci4NCj4gDQo+ID4gQWxzbywgaWYgdGhlcmUgaXMgbm8gcm91dGVyIHdpdGhp biB0aGUgbGluaywgaG93IGNhbiBkbyByb3V0aW5nIGZvciBob3N0cz8NCj4gDQo+IHRoZXJlIGlz IGF0bGVhc3QgdGhlIEhvbWUgQWdlbnQuIGFuZCB0aGVyZXMgZ290IGEgcm91dGVyIA0KPiB3aGlj aCBhZ2dyZWdhdGVzIHRoZSBob21lIGxpbmsgKGFuZCB0aGUgTW9iaWxlIE5ldHdvcmtzIA0KPiB0 aGF0IGJlbG9uZyB0byB0aGUgaG9tZSBsaW5rKS4NCj4gDQo+IFZpamF5DQo+IA0KPiA=