From mailman-admin@ietf.org Sun Feb 1 09:11:57 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13086 for ; Sun, 1 Feb 2004 09:11:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnIJv-00040C-5C for nemo-archive@lists.ietf.org; Sun, 01 Feb 2004 09:11:31 -0500 Date: Sun, 01 Feb 2004 09:11:31 -0500 Message-ID: <20040201141131.1364.83897.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 Sun Feb 1 10:14:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24828 for ; Sun, 1 Feb 2004 10:14:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnJIq-00042e-MP for nemo-archive@odin.ietf.org; Sun, 01 Feb 2004 10:14:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i11FESWZ015530 for nemo-archive@odin.ietf.org; Sun, 1 Feb 2004 10:14:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnJIq-00042P-H7 for nemo-web-archive@optimus.ietf.org; Sun, 01 Feb 2004 10:14:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24427 for ; Sun, 1 Feb 2004 10:14:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnJIn-00055K-00 for nemo-web-archive@ietf.org; Sun, 01 Feb 2004 10:14:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnInu-0004n9-00 for nemo-web-archive@ietf.org; Sun, 01 Feb 2004 09:42:32 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AnIPX-0006hK-00 for nemo-web-archive@ietf.org; Sun, 01 Feb 2004 09:17:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AnIBa-0003sJ-GO for nemo-web-archive@ietf.org; Sun, 01 Feb 2004 09:02:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnIBZ-0003PH-Ly for nemo-web-archive@ietf.org; Sun, 01 Feb 2004 09:02:53 -0500 Date: Sun, 01 Feb 2004 09:02:53 -0500 Message-ID: <20040201140253.1364.73158.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 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 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 Feb 2 17:28:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18534 for ; Mon, 2 Feb 2004 17:28:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmXy-0006tw-1k; Mon, 02 Feb 2004 17:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnirE-0000rH-Ul for nemo@optimus.ietf.org; Mon, 02 Feb 2004 13:31:40 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29191 for ; Mon, 2 Feb 2004 13:31:38 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1Aniqe-0002oR-Cp; Mon, 02 Feb 2004 13:31:04 -0500 X-test-idtracker: no To: IETF-Announce :; From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Mon, 02 Feb 2004 13:31:04 -0500 Subject: [nemo] Last Call: 'Nemo Basic Support Protocol' to Proposed Standard 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: , The IESG has received a request from the Network Mobility WG to consider the following document: - 'Nemo Basic Support Protocol' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-02-16. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-02.txt From exim@www1.ietf.org Mon Feb 2 17:30:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18639 for ; Mon, 2 Feb 2004 17:30:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmZv-00077M-8E for nemo-archive@odin.ietf.org; Mon, 02 Feb 2004 17:30:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12MU3Hu027354 for nemo-archive@odin.ietf.org; Mon, 2 Feb 2004 17:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmZu-000774-Ub for nemo-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 17:30:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18593 for ; Mon, 2 Feb 2004 17:29:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnmZs-0006H2-00 for nemo-web-archive@ietf.org; Mon, 02 Feb 2004 17:30:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnmYr-00069F-00 for nemo-web-archive@ietf.org; Mon, 02 Feb 2004 17:28:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnmY2-000630-00 for nemo-web-archive@ietf.org; Mon, 02 Feb 2004 17:28:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmXy-0006tw-1k; Mon, 02 Feb 2004 17:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnirE-0000rH-Ul for nemo@optimus.ietf.org; Mon, 02 Feb 2004 13:31:40 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29191 for ; Mon, 2 Feb 2004 13:31:38 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1Aniqe-0002oR-Cp; Mon, 02 Feb 2004 13:31:04 -0500 X-test-idtracker: no To: IETF-Announce :; From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Mon, 02 Feb 2004 13:31:04 -0500 Subject: [nemo] Last Call: 'Nemo Basic Support Protocol' to Proposed Standard 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,TO_HAS_SPACES autolearn=no version=2.60 The IESG has received a request from the Network Mobility WG to consider the following document: - 'Nemo Basic Support Protocol' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-02-16. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-02.txt From nemo-admin@ietf.org Fri Feb 6 03:39:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16667 for ; Fri, 6 Feb 2004 03:39:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap1Vu-0000uK-5d; Fri, 06 Feb 2004 03:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap1VP-0000pC-ER for nemo@optimus.ietf.org; Fri, 06 Feb 2004 03:38:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16632 for ; Fri, 6 Feb 2004 03:38:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap1VN-0004Q2-00 for nemo@ietf.org; Fri, 06 Feb 2004 03:38:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap1UO-0004Nq-00 for nemo@ietf.org; Fri, 06 Feb 2004 03:37:29 -0500 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1Ap1TQ-0004Kc-00 for nemo@ietf.org; Fri, 06 Feb 2004 03:36:29 -0500 Received: from popeye.snu.ac.kr (localhost [127.0.0.1]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i168XYTk022790 for ; Fri, 6 Feb 2004 17:33:34 +0900 Received: (from shcho@localhost) by popeye.snu.ac.kr (8.12.2/8.12.2/Submit) id i168XYCZ022789 for nemo@ietf.org; Fri, 6 Feb 2004 17:33:34 +0900 Date: Fri, 6 Feb 2004 17:33:34 +0900 From: Seongho Cho To: nemo@ietf.org Message-ID: <20040206173334.A22740@popeye.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [nemo] FW: I-D ACTION:draft-cho-nemo-threat-multihoming-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: , Hi all, Just to inform you that we have submitted a new I-D on threats for multihoming. We tried to write possible attack scenarios for multi-homed mobile networks and hope that this I-D will initiate some discussions on this topic. ----- Forwarded message from Internet-Drafts@ietf.org ----- To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-cho-nemo-threat-multihoming-00.txt Date: Thu, 05 Feb 2004 15:43:47 -0500 Precedence: bulk A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Threat for Multi-homed Mobile Networks Author(s) : S. Cho Filename : draft-cho-nemo-threat-multihoming-00.txt Pages : 8 Date : 2004-2-5 In mobile networks, the Mobile Router (MR) is an operational main entity. With multiple MRs, mobile networks can provide the stability of service. And, there already exist various multi-homing scenarios. However, because of mobility and MR-HA relations, there are several security problems in multi-homed mobile networks. In this draft, we identify threats to multi-homed mobile networks. And we will illustrate several scenarios of Denial-of-Service (DoS) attacks, Redirection attacks, and Replay attacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cho-nemo-threat-multihoming-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-cho-nemo-threat-multihoming-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-cho-nemo-threat-multihoming-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. ----- End forwarded message ----- -- ------------------------------------------------------------------------ Cho, Seongho (Ph.D. candidate) Information Networking & Computing Laboratory, School of Computer Science and Engineering, Seoul National University San 56-1, Shillim dong, Gwanak gu, Seoul, 151-744, Korea. TEL: +82-2-884-3936 FAX: +82-2-871-4912 http://popeye.snu.ac.kr/~shcho ; mailto:shcho@popeye.snu.ac.kr ------------------------------------------------------------------------ From exim@www1.ietf.org Fri Feb 6 03:41:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16729 for ; Fri, 6 Feb 2004 03:41:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap1XR-0001CF-PZ for nemo-archive@odin.ietf.org; Fri, 06 Feb 2004 03:40:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i168ebSN004593 for nemo-archive@odin.ietf.org; Fri, 6 Feb 2004 03:40:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap1XR-0001C0-7z for nemo-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 03:40:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16708 for ; Fri, 6 Feb 2004 03:40:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap1XO-0004YP-00 for nemo-web-archive@ietf.org; Fri, 06 Feb 2004 03:40:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap1WU-0004Uu-00 for nemo-web-archive@ietf.org; Fri, 06 Feb 2004 03:39:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap1Vx-0004SH-00 for nemo-web-archive@ietf.org; Fri, 06 Feb 2004 03:39:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap1Vu-0000uK-5d; Fri, 06 Feb 2004 03:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap1VP-0000pC-ER for nemo@optimus.ietf.org; Fri, 06 Feb 2004 03:38:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16632 for ; Fri, 6 Feb 2004 03:38:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap1VN-0004Q2-00 for nemo@ietf.org; Fri, 06 Feb 2004 03:38:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap1UO-0004Nq-00 for nemo@ietf.org; Fri, 06 Feb 2004 03:37:29 -0500 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1Ap1TQ-0004Kc-00 for nemo@ietf.org; Fri, 06 Feb 2004 03:36:29 -0500 Received: from popeye.snu.ac.kr (localhost [127.0.0.1]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id i168XYTk022790 for ; Fri, 6 Feb 2004 17:33:34 +0900 Received: (from shcho@localhost) by popeye.snu.ac.kr (8.12.2/8.12.2/Submit) id i168XYCZ022789 for nemo@ietf.org; Fri, 6 Feb 2004 17:33:34 +0900 Date: Fri, 6 Feb 2004 17:33:34 +0900 From: Seongho Cho To: nemo@ietf.org Message-ID: <20040206173334.A22740@popeye.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [nemo] FW: I-D ACTION:draft-cho-nemo-threat-multihoming-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Hi all, Just to inform you that we have submitted a new I-D on threats for multihoming. We tried to write possible attack scenarios for multi-homed mobile networks and hope that this I-D will initiate some discussions on this topic. ----- Forwarded message from Internet-Drafts@ietf.org ----- To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-cho-nemo-threat-multihoming-00.txt Date: Thu, 05 Feb 2004 15:43:47 -0500 Precedence: bulk A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Threat for Multi-homed Mobile Networks Author(s) : S. Cho Filename : draft-cho-nemo-threat-multihoming-00.txt Pages : 8 Date : 2004-2-5 In mobile networks, the Mobile Router (MR) is an operational main entity. With multiple MRs, mobile networks can provide the stability of service. And, there already exist various multi-homing scenarios. However, because of mobility and MR-HA relations, there are several security problems in multi-homed mobile networks. In this draft, we identify threats to multi-homed mobile networks. And we will illustrate several scenarios of Denial-of-Service (DoS) attacks, Redirection attacks, and Replay attacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cho-nemo-threat-multihoming-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-cho-nemo-threat-multihoming-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-cho-nemo-threat-multihoming-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. ----- End forwarded message ----- -- ------------------------------------------------------------------------ Cho, Seongho (Ph.D. candidate) Information Networking & Computing Laboratory, School of Computer Science and Engineering, Seoul National University San 56-1, Shillim dong, Gwanak gu, Seoul, 151-744, Korea. TEL: +82-2-884-3936 FAX: +82-2-871-4912 http://popeye.snu.ac.kr/~shcho ; mailto:shcho@popeye.snu.ac.kr ------------------------------------------------------------------------ From nemo-admin@ietf.org Mon Feb 16 13:11:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09856 for ; Mon, 16 Feb 2004 13:11:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsnCw-000310-2o; Mon, 16 Feb 2004 13:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asm2s-0005WU-4U for nemo@optimus.ietf.org; Mon, 16 Feb 2004 11:56:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04773 for ; Mon, 16 Feb 2004 11:56:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asm2q-0000CO-00 for nemo@ietf.org; Mon, 16 Feb 2004 11:56:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asm23-00005W-00 for nemo@ietf.org; Mon, 16 Feb 2004 11:55:43 -0500 Received: from host10.root-name-server.net ([69.57.175.42]) by ietf-mx with esmtp (Exim 4.12) id 1Asm1C-0007nD-00 for nemo@ietf.org; Mon, 16 Feb 2004 11:54:50 -0500 Received: from nobody by host10.root-name-server.net with local (Exim 4.24) id 1Asm1C-0005MM-Kq for nemo@ietf.org; Mon, 16 Feb 2004 11:54:50 -0500 To: nemo@ietf.org FROM: <> Message-Id: Date: Mon, 16 Feb 2004 11:54:50 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host10.root-name-server.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=FROM_NO_LOWER autolearn=no version=2.60 Subject: [nemo] (no subject) 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: , From exim@www1.ietf.org Mon Feb 16 13:12:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09947 for ; Mon, 16 Feb 2004 13:12:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsnEP-00038V-24 for nemo-archive@odin.ietf.org; Mon, 16 Feb 2004 13:12:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GICXk1012051 for nemo-archive@odin.ietf.org; Mon, 16 Feb 2004 13:12:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsnEO-00038I-TH for nemo-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 13:12:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09911 for ; Mon, 16 Feb 2004 13:12:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsnEM-00075v-00 for nemo-web-archive@ietf.org; Mon, 16 Feb 2004 13:12:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsnDT-000727-00 for nemo-web-archive@ietf.org; Mon, 16 Feb 2004 13:11:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsnCy-0006yB-00 for nemo-web-archive@ietf.org; Mon, 16 Feb 2004 13:11:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsnCw-000310-2o; Mon, 16 Feb 2004 13:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asm2s-0005WU-4U for nemo@optimus.ietf.org; Mon, 16 Feb 2004 11:56:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04773 for ; Mon, 16 Feb 2004 11:56:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asm2q-0000CO-00 for nemo@ietf.org; Mon, 16 Feb 2004 11:56:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asm23-00005W-00 for nemo@ietf.org; Mon, 16 Feb 2004 11:55:43 -0500 Received: from host10.root-name-server.net ([69.57.175.42]) by ietf-mx with esmtp (Exim 4.12) id 1Asm1C-0007nD-00 for nemo@ietf.org; Mon, 16 Feb 2004 11:54:50 -0500 Received: from nobody by host10.root-name-server.net with local (Exim 4.24) id 1Asm1C-0005MM-Kq for nemo@ietf.org; Mon, 16 Feb 2004 11:54:50 -0500 To: nemo@ietf.org FROM: <> Message-Id: Date: Mon, 16 Feb 2004 11:54:50 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host10.root-name-server.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - Subject: [nemo] (no subject) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.2 required=5.0 tests=FROM_NO_LOWER,FROM_NO_USER autolearn=no version=2.60 From nemo-admin@ietf.org Wed Feb 18 04:35:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03725 for ; Wed, 18 Feb 2004 04:35:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtO6i-00069J-BS; Wed, 18 Feb 2004 04:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtMvq-0000CC-1J for nemo@optimus.ietf.org; Wed, 18 Feb 2004 03:19:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01762 for ; Wed, 18 Feb 2004 03:19:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtMvn-0005OX-00 for nemo@ietf.org; Wed, 18 Feb 2004 03:19:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtMus-0005L7-00 for nemo@ietf.org; Wed, 18 Feb 2004 03:18:47 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1AtMtv-0005Ec-00 for nemo@ietf.org; Wed, 18 Feb 2004 03:17:48 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HT900H47TO1HD@mailout1.samsung.com> for nemo@ietf.org; Wed, 18 Feb 2004 17:16:49 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HT900CPDTNJV8@mailout1.samsung.com> for nemo@ietf.org; Wed, 18 Feb 2004 17:16:31 +0900 (KST) Received: from LocalHost ([75.2.47.28]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HT900DFATNJ4H@mmp1.samsung.com> for nemo@ietf.org; Wed, 18 Feb 2004 17:16:31 +0900 (KST) Date: Wed, 18 Feb 2004 17:16:31 +0900 From: Sung-Hyuck Lee To: nemo@ietf.org Message-id: <002d01c3f5f7$83d5a5d0$1c2f024b@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [nemo] FYI: IETF Seoul Meeting 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, IETF Seoul meeting is coming ... However, If you did not make any reservation for accommodation yet, please let me know. I can help the folks who have not found an appropriate hotel. p.s. This mail is not ad. Thanks & Regards, Sung-Hyuck Lee ---------------------------------------------- NPTG, i-Networking Lab. Samsung Advanced Institute of Technology (SAIT) Tel: +82-31-280-9585 Fax: +82-31-280-9569 Cellular: +82-11-9039-2615 e-mail: starsu.lee@samsung.com ---------------------------------------------- From exim@www1.ietf.org Wed Feb 18 04:37:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03772 for ; Wed, 18 Feb 2004 04:37:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtO8Q-0006Fw-Ke for nemo-archive@odin.ietf.org; Wed, 18 Feb 2004 04:36:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1I9an1Z024037 for nemo-archive@odin.ietf.org; Wed, 18 Feb 2004 04:36:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtO8O-0006Fc-V2 for nemo-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 04:36:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03762 for ; Wed, 18 Feb 2004 04:36:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtO8L-0001Wv-00 for nemo-web-archive@ietf.org; Wed, 18 Feb 2004 04:36:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtO7M-0001Tx-00 for nemo-web-archive@ietf.org; Wed, 18 Feb 2004 04:35:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtO6l-0001RE-00 for nemo-web-archive@ietf.org; Wed, 18 Feb 2004 04:35:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtO6i-00069J-BS; Wed, 18 Feb 2004 04:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtMvq-0000CC-1J for nemo@optimus.ietf.org; Wed, 18 Feb 2004 03:19:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01762 for ; Wed, 18 Feb 2004 03:19:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtMvn-0005OX-00 for nemo@ietf.org; Wed, 18 Feb 2004 03:19:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtMus-0005L7-00 for nemo@ietf.org; Wed, 18 Feb 2004 03:18:47 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1AtMtv-0005Ec-00 for nemo@ietf.org; Wed, 18 Feb 2004 03:17:48 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HT900H47TO1HD@mailout1.samsung.com> for nemo@ietf.org; Wed, 18 Feb 2004 17:16:49 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HT900CPDTNJV8@mailout1.samsung.com> for nemo@ietf.org; Wed, 18 Feb 2004 17:16:31 +0900 (KST) Received: from LocalHost ([75.2.47.28]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HT900DFATNJ4H@mmp1.samsung.com> for nemo@ietf.org; Wed, 18 Feb 2004 17:16:31 +0900 (KST) Date: Wed, 18 Feb 2004 17:16:31 +0900 From: Sung-Hyuck Lee To: nemo@ietf.org Message-id: <002d01c3f5f7$83d5a5d0$1c2f024b@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [nemo] FYI: IETF Seoul Meeting 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Dear all, IETF Seoul meeting is coming ... However, If you did not make any reservation for accommodation yet, please let me know. I can help the folks who have not found an appropriate hotel. p.s. This mail is not ad. Thanks & Regards, Sung-Hyuck Lee ---------------------------------------------- NPTG, i-Networking Lab. Samsung Advanced Institute of Technology (SAIT) Tel: +82-31-280-9585 Fax: +82-31-280-9569 Cellular: +82-11-9039-2615 e-mail: starsu.lee@samsung.com ---------------------------------------------- From nemo-admin@ietf.org Wed Feb 18 10:02:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16287 for ; Wed, 18 Feb 2004 10:02:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTCH-00066h-4a; Wed, 18 Feb 2004 10:01:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTC7-0005zq-Oi for nemo@optimus.ietf.org; Wed, 18 Feb 2004 10:00:59 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15972; Wed, 18 Feb 2004 10:00:56 -0500 (EST) Message-Id: <200402181500.KAA15972@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: Wed, 18 Feb 2004 10:00:55 -0500 Subject: [nemo] I-D ACTION:draft-ietf-nemo-requirements-02.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. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Network Mobility Support Goals and Requirements Author(s) : T. Ernst Filename : draft-ietf-nemo-requirements-02.txt Pages : 13 Date : 2004-2-18 Network mobility arises when a router connecting an entire network to the Internet dynamically changes its point of attachment to the Internet therefrom causing the reachability of the entire network to be changed in the topology. Such kind of network is referred to as a mobile network. Without appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet cannot be maintained while the mobile router changes its point of attachment. The required support mechanisms will be provided in two phases. The first phase, referred to as NEMO Basic Support is to provide session continuity while the necessary optimizations mechanims referred to as NEMO Extended Support might be provided later. This document outlines the goals expected from network mobility support and defines the requirements that must be met by NEMO Basic Support solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-02.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-ietf-nemo-requirements-02.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-ietf-nemo-requirements-02.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: <2004-2-18101420.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-requirements-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18101420.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-admin@ietf.org Wed Feb 18 10:02:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16328 for ; Wed, 18 Feb 2004 10:02:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTD8-0006kY-0q; Wed, 18 Feb 2004 10:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTCJ-000674-Js for nemo@optimus.ietf.org; Wed, 18 Feb 2004 10:01:11 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16004; Wed, 18 Feb 2004 10:01:07 -0500 (EST) Message-Id: <200402181501.KAA16004@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: Wed, 18 Feb 2004 10:01:07 -0500 Subject: [nemo] I-D ACTION:draft-ietf-nemo-terminology-01.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. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Network Mobility Support Terminology Author(s) : T. Ernst, H. Lach Filename : draft-ietf-nemo-terminology-01.txt Pages : 21 Date : 2004-2-18 This document defines a terminology for discussing network mobility problems and solution requirements. Network mobility arises when a router connecting an entire network to the Internet dynamically changes its point of attachment to the Internet therefrom causing the reachability of the entire network to be changed in the topology. Such kind of network is referred to as a mobile network. Without appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet cannot be maintained while the mobile router changes its point of attachment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-01.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-ietf-nemo-terminology-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-terminology-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <2004-2-18101440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-terminology-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-terminology-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18101440.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Wed Feb 18 10:05:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16977 for ; Wed, 18 Feb 2004 10:05:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTFu-0000cI-P7 for nemo-archive@odin.ietf.org; Wed, 18 Feb 2004 10:04:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IF4s0x002362 for nemo-archive@odin.ietf.org; Wed, 18 Feb 2004 10:04:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTFu-0000c0-Lh for nemo-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 10:04:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16896 for ; Wed, 18 Feb 2004 10:04:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtTFs-0006AA-00 for nemo-web-archive@ietf.org; Wed, 18 Feb 2004 10:04:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtTEk-0005wV-00 for nemo-web-archive@ietf.org; Wed, 18 Feb 2004 10:03:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtTD6-0005e0-00 for nemo-web-archive@ietf.org; Wed, 18 Feb 2004 10:02:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTD8-0006kY-0q; Wed, 18 Feb 2004 10:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTCJ-000674-Js for nemo@optimus.ietf.org; Wed, 18 Feb 2004 10:01:11 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16004; Wed, 18 Feb 2004 10:01:07 -0500 (EST) Message-Id: <200402181501.KAA16004@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: Wed, 18 Feb 2004 10:01:07 -0500 Subject: [nemo] I-D ACTION:draft-ietf-nemo-terminology-01.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Network Mobility Support Terminology Author(s) : T. Ernst, H. Lach Filename : draft-ietf-nemo-terminology-01.txt Pages : 21 Date : 2004-2-18 This document defines a terminology for discussing network mobility problems and solution requirements. Network mobility arises when a router connecting an entire network to the Internet dynamically changes its point of attachment to the Internet therefrom causing the reachability of the entire network to be changed in the topology. Such kind of network is referred to as a mobile network. Without appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet cannot be maintained while the mobile router changes its point of attachment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-01.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-ietf-nemo-terminology-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-terminology-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <2004-2-18101440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-terminology-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-terminology-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18101440.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-admin@ietf.org Wed Feb 18 12:43:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01994 for ; Wed, 18 Feb 2004 12:43:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtViv-0000ie-EN; Wed, 18 Feb 2004 12:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtViD-0000eI-UK for nemo@optimus.ietf.org; Wed, 18 Feb 2004 12:42:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01882 for ; Wed, 18 Feb 2004 12:42:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtViC-00009e-00 for nemo@ietf.org; Wed, 18 Feb 2004 12:42:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtVg6-0007VI-00 for nemo@ietf.org; Wed, 18 Feb 2004 12:40:07 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AtVeI-00074I-00 for nemo@ietf.org; Wed, 18 Feb 2004 12:38:14 -0500 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1IHaoFg006915; Wed, 18 Feb 2004 18:36:51 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Feb 2004 17:37:15 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Feb 2004 17:37:14 -0000 Message-ID: Thread-Topic: checking the Nemo tunnel Thread-Index: AcPY94C5wbTn/N+AT1+16JosJK2QEQAAHQ4QB1L444A= From: "Pascal Thubert (pthubert)" To: , , "Alexandru Petrescu" Cc: X-OriginalArrivalTime: 18 Feb 2004 17:37:15.0639 (UTC) FILETIME=[D95C5870:01C3F645] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] FW: checking the Nemo 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: , Content-Transfer-Encoding: quoted-printable Hi: I believe that the text about nemo mrha tunnel handling could be improved a bit:=20 --------------------------------------------------------------------- Let me suggest a little rephrasing for this paragraph: =20 > > The Home Agent has to verify that packets received through the > > bi-directional tunnel belong to the mobile network. This check is > > necessary in order to prevent nodes from using the Home Agent to > > launch attacks that would have otherwise been prevented by ingress > > filtering. The source address of the outer IPv6 header MUST be set > > to the Mobile Router's current Care-of address. The source address > > of the inner IPv6 header MUST be a topologically correct address with > > respect to the IPv6 prefixes used in the mobile network. =20 =20 The Home Agent MUST validate the packets received through a bi-directional tunnel. This check is necessary in order to prevent nodes from using the Home Agent to launch attacks that would have otherwise been prevented by ingress filtering. The source address of the outer IPv6 header MUST correspond to the primary careof Address of an active registration. The source address of the inner IPv6 header MUST be a topologically correct address, meaning that it is reachable via the home address for That active registration. The source address of the inner IPv6 header may be either: a) the Home address for that registration (MN or MR) b) a global address from an MNP associated to that registration for a registration with the 'R' bit set c) ) more generally, if some additional routing takes place, an address from a prefix that is routed via the registration home address, for a registration with the 'R' bit set. =20 ------------------------------------------------------------ I believe we should open an issue for it. Note that MIPv6 is clear and right about the fact that the inner packet has to be checked to make sure that the tunnel is used by MN. Checking that the tunnel source exists is not enough for basic Nemo. We have to do a reverse lookup.=20 One important consequence of that is that the degraded mode (with non Nemo enable HAs) does not work for basic Nemo Mobile Networks. Say you have a static route to a MR MNP in a non Nemo MIPv6 HA. If you ping an address on the MNP from the HA, the packet will be encapsulated and responded to. But when the HA gets the tunneled response back, it checks the inner packet source, and expects only a Home Address. Since the source is not the MR Home Address but a MNP address, the HA drops the packet. Too bad ain't it?=20 The consequence of all this is that a MR registering to a non Nemo HA can only register as a MIP MN, and can not expect to use the MRHA tunnel to serve its MNPs... What do you think? Pascal From exim@www1.ietf.org Wed Feb 18 13:05:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05387 for ; Wed, 18 Feb 2004 13:05:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtW4V-0002lq-6u for nemo-archive@odin.ietf.org; Wed, 18 Feb 2004 13:05:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1II5JTW010644 for nemo-archive@odin.ietf.org; Wed, 18 Feb 2004 13:05:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtW4V-0002la-0r for nemo-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 13:05:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05287 for ; Wed, 18 Feb 2004 13:05:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtW4T-0004IJ-00 for nemo-web-archive@ietf.org; Wed, 18 Feb 2004 13:05:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtW2E-0003m4-00 for nemo-web-archive@ietf.org; Wed, 18 Feb 2004 13:03:00 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AtVzH-0003Cx-02 for nemo-web-archive@ietf.org; Wed, 18 Feb 2004 12:59:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AtVj2-0008VR-IA for nemo-web-archive@ietf.org; Wed, 18 Feb 2004 12:43:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtViv-0000ie-EN; Wed, 18 Feb 2004 12:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtViD-0000eI-UK for nemo@optimus.ietf.org; Wed, 18 Feb 2004 12:42:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01882 for ; Wed, 18 Feb 2004 12:42:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtViC-00009e-00 for nemo@ietf.org; Wed, 18 Feb 2004 12:42:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtVg6-0007VI-00 for nemo@ietf.org; Wed, 18 Feb 2004 12:40:07 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AtVeI-00074I-00 for nemo@ietf.org; Wed, 18 Feb 2004 12:38:14 -0500 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1IHaoFg006915; Wed, 18 Feb 2004 18:36:51 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Feb 2004 17:37:15 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Feb 2004 17:37:14 -0000 Message-ID: Thread-Topic: checking the Nemo tunnel Thread-Index: AcPY94C5wbTn/N+AT1+16JosJK2QEQAAHQ4QB1L444A= From: "Pascal Thubert (pthubert)" To: , , "Alexandru Petrescu" Cc: X-OriginalArrivalTime: 18 Feb 2004 17:37:15.0639 (UTC) FILETIME=[D95C5870:01C3F645] Content-Transfer-Encoding: quoted-printable Subject: [nemo] FW: checking the Nemo 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi: I believe that the text about nemo mrha tunnel handling could be improved a bit:=20 --------------------------------------------------------------------- Let me suggest a little rephrasing for this paragraph: =20 > > The Home Agent has to verify that packets received through the > > bi-directional tunnel belong to the mobile network. This check is > > necessary in order to prevent nodes from using the Home Agent to > > launch attacks that would have otherwise been prevented by ingress > > filtering. The source address of the outer IPv6 header MUST be set > > to the Mobile Router's current Care-of address. The source address > > of the inner IPv6 header MUST be a topologically correct address with > > respect to the IPv6 prefixes used in the mobile network. =20 =20 The Home Agent MUST validate the packets received through a bi-directional tunnel. This check is necessary in order to prevent nodes from using the Home Agent to launch attacks that would have otherwise been prevented by ingress filtering. The source address of the outer IPv6 header MUST correspond to the primary careof Address of an active registration. The source address of the inner IPv6 header MUST be a topologically correct address, meaning that it is reachable via the home address for That active registration. The source address of the inner IPv6 header may be either: a) the Home address for that registration (MN or MR) b) a global address from an MNP associated to that registration for a registration with the 'R' bit set c) ) more generally, if some additional routing takes place, an address from a prefix that is routed via the registration home address, for a registration with the 'R' bit set. =20 ------------------------------------------------------------ I believe we should open an issue for it. Note that MIPv6 is clear and right about the fact that the inner packet has to be checked to make sure that the tunnel is used by MN. Checking that the tunnel source exists is not enough for basic Nemo. We have to do a reverse lookup.=20 One important consequence of that is that the degraded mode (with non Nemo enable HAs) does not work for basic Nemo Mobile Networks. Say you have a static route to a MR MNP in a non Nemo MIPv6 HA. If you ping an address on the MNP from the HA, the packet will be encapsulated and responded to. But when the HA gets the tunneled response back, it checks the inner packet source, and expects only a Home Address. Since the source is not the MR Home Address but a MNP address, the HA drops the packet. Too bad ain't it?=20 The consequence of all this is that a MR registering to a non Nemo HA can only register as a MIP MN, and can not expect to use the MRHA tunnel to serve its MNPs... What do you think? Pascal From nemo-admin@ietf.org Thu Feb 19 21:31:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12328 for ; Thu, 19 Feb 2004 21:31:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au0RS-0007aA-1W; Thu, 19 Feb 2004 21:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au0RE-0007ZU-4L for nemo@optimus.ietf.org; Thu, 19 Feb 2004 21:30:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12320 for ; Thu, 19 Feb 2004 21:30:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au0RB-0007jJ-00 for nemo@ietf.org; Thu, 19 Feb 2004 21:30:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au0Q9-0007gt-00 for nemo@ietf.org; Thu, 19 Feb 2004 21:29:41 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1Au0Ps-0007dJ-00 for nemo@ietf.org; Thu, 19 Feb 2004 21:29:25 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1K2Koe4003346; Fri, 20 Feb 2004 10:20:50 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 2BD92B240A7; Fri, 20 Feb 2004 10:23:50 +0800 (SGT) From: Chan-Wah NG To: IETF NEMO WG Content-Type: multipart/mixed; boundary="=-yy/Qp2SU+S1MuF/hDz/B" Organization: Panasonic Singapore Labs Message-Id: <1077243829.5488.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 20 Feb 2004 10:23:49 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-multihoming-issues-03.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: , --=-yy/Qp2SU+S1MuF/hDz/B Content-Type: text/plain Content-Transfer-Encoding: 7bit -----Forwarded Message----- From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ng-nemo-multihoming-issues-03.txt Date: Wed, 18 Feb 2004 09:40:17 -0500 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multi-Homing Issues in Bi-Directional Tunneling Author(s) : C. Ng, J. Charbon Filename : draft-ng-nemo-multihoming-issues-03.txt Pages : 30 Date : 2004-2-18 This document describes deployment scenario of multi-homed Network in Motion (NEMO) and attempts to identify issues that arises when supporting multi-homing in NEMO. It is also the objective of this document to build a full taxonomy covering multi-homed scenarios in NEMO, so as to facilitate explorations into this aspect of NEMO. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.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-ng-nemo-multihoming-issues-03.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-ng-nemo-multihoming-issues-03.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. ________________________________________________________________________ Content-Type: text/plain Content-ID: <2004-2-18095316.I-D@ietf.org> --=-yy/Qp2SU+S1MuF/hDz/B Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-2-18095316.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ng-nemo-multihoming-issues-03.txt --=-yy/Qp2SU+S1MuF/hDz/B Content-Type: Message/External-body; name="draft-ng-nemo-multihoming-issues-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-2-18095316.I-D@ietf.org> --=-yy/Qp2SU+S1MuF/hDz/B-- From exim@www1.ietf.org Thu Feb 19 21:33:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12424 for ; Thu, 19 Feb 2004 21:33:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au0T7-0007k6-BB for nemo-archive@odin.ietf.org; Thu, 19 Feb 2004 21:32:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K2WjZR029756 for nemo-archive@odin.ietf.org; Thu, 19 Feb 2004 21:32:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au0T7-0007jr-6y for nemo-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 21:32:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12401 for ; Thu, 19 Feb 2004 21:32:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au0T4-00005S-00 for nemo-web-archive@ietf.org; Thu, 19 Feb 2004 21:32:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au0SC-00001P-00 for nemo-web-archive@ietf.org; Thu, 19 Feb 2004 21:31:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au0RT-0007l3-00 for nemo-web-archive@ietf.org; Thu, 19 Feb 2004 21:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au0RS-0007aA-1W; Thu, 19 Feb 2004 21:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au0RE-0007ZU-4L for nemo@optimus.ietf.org; Thu, 19 Feb 2004 21:30:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12320 for ; Thu, 19 Feb 2004 21:30:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au0RB-0007jJ-00 for nemo@ietf.org; Thu, 19 Feb 2004 21:30:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au0Q9-0007gt-00 for nemo@ietf.org; Thu, 19 Feb 2004 21:29:41 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1Au0Ps-0007dJ-00 for nemo@ietf.org; Thu, 19 Feb 2004 21:29:25 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1K2Koe4003346; Fri, 20 Feb 2004 10:20:50 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 2BD92B240A7; Fri, 20 Feb 2004 10:23:50 +0800 (SGT) From: Chan-Wah NG To: IETF NEMO WG Content-Type: multipart/mixed; boundary="=-yy/Qp2SU+S1MuF/hDz/B" Organization: Panasonic Singapore Labs Message-Id: <1077243829.5488.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 20 Feb 2004 10:23:49 +0800 Subject: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-multihoming-issues-03.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-yy/Qp2SU+S1MuF/hDz/B Content-Type: text/plain Content-Transfer-Encoding: 7bit -----Forwarded Message----- From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ng-nemo-multihoming-issues-03.txt Date: Wed, 18 Feb 2004 09:40:17 -0500 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multi-Homing Issues in Bi-Directional Tunneling Author(s) : C. Ng, J. Charbon Filename : draft-ng-nemo-multihoming-issues-03.txt Pages : 30 Date : 2004-2-18 This document describes deployment scenario of multi-homed Network in Motion (NEMO) and attempts to identify issues that arises when supporting multi-homing in NEMO. It is also the objective of this document to build a full taxonomy covering multi-homed scenarios in NEMO, so as to facilitate explorations into this aspect of NEMO. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.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-ng-nemo-multihoming-issues-03.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-ng-nemo-multihoming-issues-03.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. ________________________________________________________________________ Content-Type: text/plain Content-ID: <2004-2-18095316.I-D@ietf.org> --=-yy/Qp2SU+S1MuF/hDz/B Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-2-18095316.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ng-nemo-multihoming-issues-03.txt --=-yy/Qp2SU+S1MuF/hDz/B Content-Type: Message/External-body; name="draft-ng-nemo-multihoming-issues-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-2-18095316.I-D@ietf.org> --=-yy/Qp2SU+S1MuF/hDz/B-- From nemo-admin@ietf.org Fri Feb 20 03:08:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09141 for ; Fri, 20 Feb 2004 03:08:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au5hb-0000nB-A8; Fri, 20 Feb 2004 03:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au5hM-0000jZ-O3 for nemo@optimus.ietf.org; Fri, 20 Feb 2004 03:07:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09132 for ; Fri, 20 Feb 2004 03:07:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au5hI-0000Vr-00 for nemo@ietf.org; Fri, 20 Feb 2004 03:07:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au5gV-0000TV-00 for nemo@ietf.org; Fri, 20 Feb 2004 03:06:56 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1Au5gD-0000PW-00 for nemo@ietf.org; Fri, 20 Feb 2004 03:06:37 -0500 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1K85YFm018254 for ; Fri, 20 Feb 2004 09:05:41 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Feb 2004 08:06:04 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3F788.62BEA419" Date: Fri, 20 Feb 2004 08:06:04 -0000 Message-ID: X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-thubert-nemo-basic-usages-01.txt Thread-Index: AcP00MtPbRoKhoHOQwuy/BdFEi4DzACttuMQ From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 20 Feb 2004 08:06:04.0717 (UTC) FILETIME=[632025D0:01C3F788] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [nemo] FW: I-D ACTION:draft-thubert-nemo-basic-usages-01.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: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F788.62BEA419 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org] = On Behalf Of Internet-Drafts@ietf.org Sent: lundi 16 f=E9vrier 2004 21:35 Subject: I-D ACTION:draft-thubert-nemo-basic-usages-01.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Examples of basic Nemo usage Author(s) : P. Thubert, R. Wakikawa, V. Devarapalli Filename : draft-thubert-nemo-basic-usages-01.txt Pages : 20 Date : 2004-2-16 This paper documents some practical scenarios and the associated issues when deploying Mobile Routers, conforming the Nemo Basic Support draft [6]. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in the Nemo and Nemo Design mailing lists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-thubert-nemo-basic-usages-01.tx= t 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-thubert-nemo-basic-usages-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-thubert-nemo-basic-usages-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C3F788.62BEA419 Content-Type: application/octet-stream; name="draft-thubert-nemo-basic-usages-01.URL" Content-Description: draft-thubert-nemo-basic-usages-01.URL Content-Disposition: attachment; filename="draft-thubert-nemo-basic-usages-01.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC10aHViZXJ0LW5lbW8tYmFzaWMtdXNhZ2VzLTAxLnR4dA0K ------_=_NextPart_001_01C3F788.62BEA419-- From exim@www1.ietf.org Fri Feb 20 03:10:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09232 for ; Fri, 20 Feb 2004 03:10:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au5jK-0001FY-Gb for nemo-archive@odin.ietf.org; Fri, 20 Feb 2004 03:09:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K89o97004802 for nemo-archive@odin.ietf.org; Fri, 20 Feb 2004 03:09:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au5jJ-0001FN-No for nemo-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 03:09:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09211 for ; Fri, 20 Feb 2004 03:09:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au5jF-0000d9-00 for nemo-web-archive@ietf.org; Fri, 20 Feb 2004 03:09:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au5iI-0000Zc-00 for nemo-web-archive@ietf.org; Fri, 20 Feb 2004 03:08:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au5hb-0000Wr-00 for nemo-web-archive@ietf.org; Fri, 20 Feb 2004 03:08:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au5hd-0000nd-DP; Fri, 20 Feb 2004 03:08:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au5hN-0000jq-G1 for nemo@optimus.ietf.org; Fri, 20 Feb 2004 03:07:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09135 for ; Fri, 20 Feb 2004 03:07:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au5hJ-0000Vy-00 for nemo@ietf.org; Fri, 20 Feb 2004 03:07:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au5gW-0000Te-00 for nemo@ietf.org; Fri, 20 Feb 2004 03:06:56 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1Au5gE-0000PW-00 for nemo@ietf.org; Fri, 20 Feb 2004 03:06:38 -0500 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1K85YG0018254 for ; Fri, 20 Feb 2004 09:05:49 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Feb 2004 08:06:09 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3F788.65CA4656" Date: Fri, 20 Feb 2004 08:06:09 -0000 Message-ID: X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-droms-nemo-dhcpv6-pd-01.txt Thread-Index: AcP0zy17sZbH/eWBSyWO7hTn5nvBygCuJYlw From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 20 Feb 2004 08:06:09.0811 (UTC) FILETIME=[66296E30:01C3F788] Subject: [nemo] FW: I-D ACTION:draft-droms-nemo-dhcpv6-pd-01.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F788.65CA4656 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org] = On Behalf Of Internet-Drafts@ietf.org Sent: lundi 16 f=E9vrier 2004 21:35 Subject: I-D ACTION:draft-droms-nemo-dhcpv6-pd-01.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : DHCPv6 Prefix Delegation for NEMO Author(s) : R. Droms, P. Thubert Filename : draft-droms-nemo-dhcpv6-pd-01.txt Pages : 12 Date : 2004-2-16 One aspect of network mobility support is the assignment of a prefix or prefixes to a mobile router (MR) for use on the links in the mobile network. DHCPv6 prefix delegation can be used for this configuration task. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-droms-nemo-dhcpv6-pd-01.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-droms-nemo-dhcpv6-pd-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-droms-nemo-dhcpv6-pd-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C3F788.65CA4656 Content-Type: application/octet-stream; name="draft-droms-nemo-dhcpv6-pd-01.URL" Content-Description: draft-droms-nemo-dhcpv6-pd-01.URL Content-Disposition: attachment; filename="draft-droms-nemo-dhcpv6-pd-01.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1kcm9tcy1uZW1vLWRoY3B2Ni1wZC0wMS50eHQNCg== ------_=_NextPart_001_01C3F788.65CA4656-- From exim@www1.ietf.org Fri Feb 20 03:10:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09236 for ; Fri, 20 Feb 2004 03:10:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au5jK-0001Fw-UX for nemo-archive@odin.ietf.org; Fri, 20 Feb 2004 03:09:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K89oAR004815 for nemo-archive@odin.ietf.org; Fri, 20 Feb 2004 03:09:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au5jK-0001FU-CK for nemo-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 03:09:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09214 for ; Fri, 20 Feb 2004 03:09:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au5jG-0000dE-00 for nemo-web-archive@ietf.org; Fri, 20 Feb 2004 03:09:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au5iJ-0000Zk-00 for nemo-web-archive@ietf.org; Fri, 20 Feb 2004 03:08:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au5hb-0000Ws-00 for nemo-web-archive@ietf.org; Fri, 20 Feb 2004 03:08:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au5hb-0000nB-A8; Fri, 20 Feb 2004 03:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au5hM-0000jZ-O3 for nemo@optimus.ietf.org; Fri, 20 Feb 2004 03:07:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09132 for ; Fri, 20 Feb 2004 03:07:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au5hI-0000Vr-00 for nemo@ietf.org; Fri, 20 Feb 2004 03:07:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au5gV-0000TV-00 for nemo@ietf.org; Fri, 20 Feb 2004 03:06:56 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1Au5gD-0000PW-00 for nemo@ietf.org; Fri, 20 Feb 2004 03:06:37 -0500 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1K85YFm018254 for ; Fri, 20 Feb 2004 09:05:41 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Feb 2004 08:06:04 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3F788.62BEA419" Date: Fri, 20 Feb 2004 08:06:04 -0000 Message-ID: X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-thubert-nemo-basic-usages-01.txt Thread-Index: AcP00MtPbRoKhoHOQwuy/BdFEi4DzACttuMQ From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 20 Feb 2004 08:06:04.0717 (UTC) FILETIME=[632025D0:01C3F788] Subject: [nemo] FW: I-D ACTION:draft-thubert-nemo-basic-usages-01.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F788.62BEA419 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org] = On Behalf Of Internet-Drafts@ietf.org Sent: lundi 16 f=E9vrier 2004 21:35 Subject: I-D ACTION:draft-thubert-nemo-basic-usages-01.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Examples of basic Nemo usage Author(s) : P. Thubert, R. Wakikawa, V. Devarapalli Filename : draft-thubert-nemo-basic-usages-01.txt Pages : 20 Date : 2004-2-16 This paper documents some practical scenarios and the associated issues when deploying Mobile Routers, conforming the Nemo Basic Support draft [6]. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in the Nemo and Nemo Design mailing lists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-thubert-nemo-basic-usages-01.tx= t 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-thubert-nemo-basic-usages-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-thubert-nemo-basic-usages-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C3F788.62BEA419 Content-Type: application/octet-stream; name="draft-thubert-nemo-basic-usages-01.URL" Content-Description: draft-thubert-nemo-basic-usages-01.URL Content-Disposition: attachment; filename="draft-thubert-nemo-basic-usages-01.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC10aHViZXJ0LW5lbW8tYmFzaWMtdXNhZ2VzLTAxLnR4dA0K ------_=_NextPart_001_01C3F788.62BEA419-- From nemo-admin@ietf.org Fri Feb 20 03:55:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09143 for ; Fri, 20 Feb 2004 03:08:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au5hd-0000nd-DP; Fri, 20 Feb 2004 03:08:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au5hN-0000jq-G1 for nemo@optimus.ietf.org; Fri, 20 Feb 2004 03:07:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09135 for ; Fri, 20 Feb 2004 03:07:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au5hJ-0000Vy-00 for nemo@ietf.org; Fri, 20 Feb 2004 03:07:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au5gW-0000Te-00 for nemo@ietf.org; Fri, 20 Feb 2004 03:06:56 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1Au5gE-0000PW-00 for nemo@ietf.org; Fri, 20 Feb 2004 03:06:38 -0500 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1K85YG0018254 for ; Fri, 20 Feb 2004 09:05:49 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Feb 2004 08:06:09 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3F788.65CA4656" Date: Fri, 20 Feb 2004 08:06:09 -0000 Message-ID: X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-droms-nemo-dhcpv6-pd-01.txt Thread-Index: AcP0zy17sZbH/eWBSyWO7hTn5nvBygCuJYlw From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 20 Feb 2004 08:06:09.0811 (UTC) FILETIME=[66296E30:01C3F788] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [nemo] FW: I-D ACTION:draft-droms-nemo-dhcpv6-pd-01.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: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F788.65CA4656 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org] = On Behalf Of Internet-Drafts@ietf.org Sent: lundi 16 f=E9vrier 2004 21:35 Subject: I-D ACTION:draft-droms-nemo-dhcpv6-pd-01.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : DHCPv6 Prefix Delegation for NEMO Author(s) : R. Droms, P. Thubert Filename : draft-droms-nemo-dhcpv6-pd-01.txt Pages : 12 Date : 2004-2-16 One aspect of network mobility support is the assignment of a prefix or prefixes to a mobile router (MR) for use on the links in the mobile network. DHCPv6 prefix delegation can be used for this configuration task. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-droms-nemo-dhcpv6-pd-01.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-droms-nemo-dhcpv6-pd-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-droms-nemo-dhcpv6-pd-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C3F788.65CA4656 Content-Type: application/octet-stream; name="draft-droms-nemo-dhcpv6-pd-01.URL" Content-Description: draft-droms-nemo-dhcpv6-pd-01.URL Content-Disposition: attachment; filename="draft-droms-nemo-dhcpv6-pd-01.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1kcm9tcy1uZW1vLWRoY3B2Ni1wZC0wMS50eHQNCg== ------_=_NextPart_001_01C3F788.65CA4656-- From nemo-admin@ietf.org Fri Feb 20 07:13:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17683 for ; Fri, 20 Feb 2004 07:13:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9Wd-0003cK-BK; Fri, 20 Feb 2004 07:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9Wa-0003bi-1p for nemo@optimus.ietf.org; Fri, 20 Feb 2004 07:12:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17672 for ; Fri, 20 Feb 2004 07:12:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au9WZ-0001P3-00 for nemo@ietf.org; Fri, 20 Feb 2004 07:12:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au9Va-0001Lb-00 for nemo@ietf.org; Fri, 20 Feb 2004 07:11:55 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1Au9Um-0001Em-00 for nemo@ietf.org; Fri, 20 Feb 2004 07:11:04 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 6C0A75D0C8 for ; Fri, 20 Feb 2004 21:10:34 +0900 (JST) Date: Fri, 20 Feb 2004 21:10:13 +0900 From: Thierry Ernst To: nemo Message-Id: <20040220211013.651bc2c0.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 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] Summary of recent drafts relevant to 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: , Content-Transfer-Encoding: 7bit Dear all, The IETF meeting is fast approaching but we haven't had discussion recently. This is amazing. I've been personaly very busy, I know that other active members too, but isn't there any concern to be discussed ? Many drafts have been submitted, indeed. So here is a summary of what was announced or not (may I remind authors to tell internet-draft@ietf.org to cc announcements to NEMO WG when they submit and to try to raise some discussion about their draft on the ML?). If you have submitted a draft since IETF Minnepolis Nov.2003 that is not listed below, please let us know. Similarly, feel free to announce any draft that you think is useful for the NEMO discussions. Thierry. # -------------------------------------------------------- Drafts Submitted Recently # -------------------------------------------------------- Network Mobility Support Terminology http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-01.txt Network Mobility Support Goals and Requirements http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-02.txt Network Mobility (NEMO) Basic Support Protocol http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-02.txt Multi-Homing Issues in Bi-Directional Tunneling http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt Examples of basic Nemo usage http://www.ietf.org/internet-drafts/draft-thubert-nemo-basic-usages-01.txt Threats for Basic Network Mobility Support (NEMO threats) http://www.ietf.org/internet-drafts/draft-petrescu-nemo-threats-01.txt Threat for Multi-homed Mobile Networks http://www.ietf.org/internet-drafts/draft-cho-nemo-threat-multihoming-00.txt DHCPv6 Prefix Delegation for NEMO http://www.ietf.org/internet-drafts/draft-droms-nemo-dhcpv6-pd-01.txt Inter Home Agents Protocol (HAHA) http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-haha-01.txt Hierarchical Mobile Router Advertisement for nested mobile networks http://www.ietf.org/internet-drafts/draft-cho-nemo-hmra-00.txt ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-02.txt Taxonomy of Route Optimization models in the Nemo Context http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-02.txt Route Optimization for Mobile Nodes in Mobile Network http://www.ietf.org/internet-drafts/draft-leekj-nemo-ro-pd-02.txt # -------------------------------------------------------- # Non NEMO drafts that may be useful for NEMO discussions # -------------------------------------------------------- Goals and Benefits of Multihoming http://www.ietf.org/internet-drafts/draft-multihoming-generic-goals-and-benefits-00.txt IPv6 addressing in a heterogeneous MANET-network http://www.ietf.org/internet-drafts/draft-paakkonen-addressing-htr-manet-00.txt From exim@www1.ietf.org Fri Feb 20 07:15:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17720 for ; Fri, 20 Feb 2004 07:15:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9YV-0003ot-Ov for nemo-archive@odin.ietf.org; Fri, 20 Feb 2004 07:14:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KCEtB6014679 for nemo-archive@odin.ietf.org; Fri, 20 Feb 2004 07:14:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9YV-0003og-Jp for nemo-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 07:14:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17715 for ; Fri, 20 Feb 2004 07:14:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au9YV-0001Vw-00 for nemo-web-archive@ietf.org; Fri, 20 Feb 2004 07:14:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au9XX-0001Sr-00 for nemo-web-archive@ietf.org; Fri, 20 Feb 2004 07:13:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au9Wh-0001QC-00 for nemo-web-archive@ietf.org; Fri, 20 Feb 2004 07:13:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9Wd-0003cK-BK; Fri, 20 Feb 2004 07:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au9Wa-0003bi-1p for nemo@optimus.ietf.org; Fri, 20 Feb 2004 07:12:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17672 for ; Fri, 20 Feb 2004 07:12:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au9WZ-0001P3-00 for nemo@ietf.org; Fri, 20 Feb 2004 07:12:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au9Va-0001Lb-00 for nemo@ietf.org; Fri, 20 Feb 2004 07:11:55 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1Au9Um-0001Em-00 for nemo@ietf.org; Fri, 20 Feb 2004 07:11:04 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 6C0A75D0C8 for ; Fri, 20 Feb 2004 21:10:34 +0900 (JST) Date: Fri, 20 Feb 2004 21:10:13 +0900 From: Thierry Ernst To: nemo Message-Id: <20040220211013.651bc2c0.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 Subject: [nemo] Summary of recent drafts relevant to 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, The IETF meeting is fast approaching but we haven't had discussion recently. This is amazing. I've been personaly very busy, I know that other active members too, but isn't there any concern to be discussed ? Many drafts have been submitted, indeed. So here is a summary of what was announced or not (may I remind authors to tell internet-draft@ietf.org to cc announcements to NEMO WG when they submit and to try to raise some discussion about their draft on the ML?). If you have submitted a draft since IETF Minnepolis Nov.2003 that is not listed below, please let us know. Similarly, feel free to announce any draft that you think is useful for the NEMO discussions. Thierry. # -------------------------------------------------------- Drafts Submitted Recently # -------------------------------------------------------- Network Mobility Support Terminology http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-01.txt Network Mobility Support Goals and Requirements http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-02.txt Network Mobility (NEMO) Basic Support Protocol http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-02.txt Multi-Homing Issues in Bi-Directional Tunneling http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt Examples of basic Nemo usage http://www.ietf.org/internet-drafts/draft-thubert-nemo-basic-usages-01.txt Threats for Basic Network Mobility Support (NEMO threats) http://www.ietf.org/internet-drafts/draft-petrescu-nemo-threats-01.txt Threat for Multi-homed Mobile Networks http://www.ietf.org/internet-drafts/draft-cho-nemo-threat-multihoming-00.txt DHCPv6 Prefix Delegation for NEMO http://www.ietf.org/internet-drafts/draft-droms-nemo-dhcpv6-pd-01.txt Inter Home Agents Protocol (HAHA) http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-haha-01.txt Hierarchical Mobile Router Advertisement for nested mobile networks http://www.ietf.org/internet-drafts/draft-cho-nemo-hmra-00.txt ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-02.txt Taxonomy of Route Optimization models in the Nemo Context http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-02.txt Route Optimization for Mobile Nodes in Mobile Network http://www.ietf.org/internet-drafts/draft-leekj-nemo-ro-pd-02.txt # -------------------------------------------------------- # Non NEMO drafts that may be useful for NEMO discussions # -------------------------------------------------------- Goals and Benefits of Multihoming http://www.ietf.org/internet-drafts/draft-multihoming-generic-goals-and-benefits-00.txt IPv6 addressing in a heterogeneous MANET-network http://www.ietf.org/internet-drafts/draft-paakkonen-addressing-htr-manet-00.txt From nemo-admin@ietf.org Fri Feb 20 12:56:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04067 for ; Fri, 20 Feb 2004 12:56:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuEsb-0007Ew-Rg; Fri, 20 Feb 2004 12:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuEXI-0004P6-Jw for nemo@optimus.ietf.org; Fri, 20 Feb 2004 12:34:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02937 for ; Fri, 20 Feb 2004 12:33:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuEXH-00021F-00 for nemo@ietf.org; Fri, 20 Feb 2004 12:33:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuEWN-0001yx-00 for nemo@ietf.org; Fri, 20 Feb 2004 12:33:03 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AuEVR-0001tw-00 for nemo@ietf.org; Fri, 20 Feb 2004 12:32:05 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1KHVXD18093 for ; Fri, 20 Feb 2004 09:31:33 -0800 X-mProtect: <200402201731> Nokia Silicon Valley Messaging Protection Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "nokia.com") by darkstar.iprg.nokia.com smtpdWjdN9f; Fri, 20 Feb 2004 09:31:31 PST Message-ID: <40364469.9193260B@nokia.com> Date: Fri, 20 Feb 2004 09:31:21 -0800 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 Subject: Re: [nemo] Summary of recent drafts relevant to NEMO References: <20040220211013.651bc2c0.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Thanks for the list of drafts, Thierry. I would like to add one more (RFC): Thierry Ernst wrote: > # -------------------------------------------------------- > # Non NEMO drafts that may be useful for NEMO discussions > # -------------------------------------------------------- RFC 3669 Title: Guidelines for Working Groups on Intellectual Property Issues Author(s): S. Brim Status: Informational Date: February 2004 Mailbox: sbrim@cisco.com Pages: 17 Characters: 40946 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipr-wg-guidelines-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3669.txt It is informational and doesn't give us new rules, but it is good reading for everyone interested in IPR. For the IPR guidelines, see RFC 3667-8. RFC 3669 is useful because it gives some past experiences of how IPR has been dealt with in other WGs, some of the same issues that have come up in NEMO. -TJ From exim@www1.ietf.org Fri Feb 20 12:58:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04151 for ; Fri, 20 Feb 2004 12:58:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuEub-0007UR-6G for nemo-archive@odin.ietf.org; Fri, 20 Feb 2004 12:58:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KHw5MF028785 for nemo-archive@odin.ietf.org; Fri, 20 Feb 2004 12:58:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuEua-0007TH-8G for nemo-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 12:58:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04122 for ; Fri, 20 Feb 2004 12:58:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuEuY-0003lO-00 for nemo-web-archive@ietf.org; Fri, 20 Feb 2004 12:58:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuEtc-0003iD-00 for nemo-web-archive@ietf.org; Fri, 20 Feb 2004 12:57:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuEsf-0003fX-00 for nemo-web-archive@ietf.org; Fri, 20 Feb 2004 12:56:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuEsb-0007Ew-Rg; Fri, 20 Feb 2004 12:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuEXI-0004P6-Jw for nemo@optimus.ietf.org; Fri, 20 Feb 2004 12:34:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02937 for ; Fri, 20 Feb 2004 12:33:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuEXH-00021F-00 for nemo@ietf.org; Fri, 20 Feb 2004 12:33:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuEWN-0001yx-00 for nemo@ietf.org; Fri, 20 Feb 2004 12:33:03 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AuEVR-0001tw-00 for nemo@ietf.org; Fri, 20 Feb 2004 12:32:05 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1KHVXD18093 for ; Fri, 20 Feb 2004 09:31:33 -0800 X-mProtect: <200402201731> Nokia Silicon Valley Messaging Protection Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "nokia.com") by darkstar.iprg.nokia.com smtpdWjdN9f; Fri, 20 Feb 2004 09:31:31 PST Message-ID: <40364469.9193260B@nokia.com> Date: Fri, 20 Feb 2004 09:31:21 -0800 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 Subject: Re: [nemo] Summary of recent drafts relevant to NEMO References: <20040220211013.651bc2c0.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for the list of drafts, Thierry. I would like to add one more (RFC): Thierry Ernst wrote: > # -------------------------------------------------------- > # Non NEMO drafts that may be useful for NEMO discussions > # -------------------------------------------------------- RFC 3669 Title: Guidelines for Working Groups on Intellectual Property Issues Author(s): S. Brim Status: Informational Date: February 2004 Mailbox: sbrim@cisco.com Pages: 17 Characters: 40946 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipr-wg-guidelines-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3669.txt It is informational and doesn't give us new rules, but it is good reading for everyone interested in IPR. For the IPR guidelines, see RFC 3667-8. RFC 3669 is useful because it gives some past experiences of how IPR has been dealt with in other WGs, some of the same issues that have come up in NEMO. -TJ From nemo-admin@ietf.org Sun Feb 22 10:49:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00088 for ; Sun, 22 Feb 2004 10:49:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Auvqn-0003xo-6o; Sun, 22 Feb 2004 10:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuvqI-0003wm-0n for nemo@optimus.ietf.org; Sun, 22 Feb 2004 10:48:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00023 for ; Sun, 22 Feb 2004 10:48:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuvqF-0000V2-00 for nemo@ietf.org; Sun, 22 Feb 2004 10:48:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuvpH-0000R9-00 for nemo@ietf.org; Sun, 22 Feb 2004 10:47:27 -0500 Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx with esmtp (Exim 4.12) id 1AuvoI-0000Mp-00 for nemo@ietf.org; Sun, 22 Feb 2004 10:46:27 -0500 Received: (from eun@localhost) by mmlab.snu.ac.kr (8.11.6/8.11.6) id i1MFkIu48278; Mon, 23 Feb 2004 00:46:18 +0900 (KST) (envelope-from eun) Date: Mon, 23 Feb 2004 00:46:18 +0900 From: Eun Kyoung Paik To: nemo@ietf.org Message-ID: <20040223004618.A48134@mmlab.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [nemo] merged multihoming draft 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 all, As the result of last IETF meeting, we merged three of multihoming related drafts into one. http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt Your comments on this draft are welcome. Regards, Eun Kyoung From exim@www1.ietf.org Sun Feb 22 10:51:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00158 for ; Sun, 22 Feb 2004 10:51:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuvsO-00046o-89 for nemo-archive@odin.ietf.org; Sun, 22 Feb 2004 10:50:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1MFoeZB015788 for nemo-archive@odin.ietf.org; Sun, 22 Feb 2004 10:50:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuvsO-00046Z-1V for nemo-web-archive@optimus.ietf.org; Sun, 22 Feb 2004 10:50:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00147 for ; Sun, 22 Feb 2004 10:50:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuvsL-0000en-00 for nemo-web-archive@ietf.org; Sun, 22 Feb 2004 10:50:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuvrP-0000b3-00 for nemo-web-archive@ietf.org; Sun, 22 Feb 2004 10:49:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Auvqq-0000XP-00 for nemo-web-archive@ietf.org; Sun, 22 Feb 2004 10:49:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Auvqn-0003xo-6o; Sun, 22 Feb 2004 10:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuvqI-0003wm-0n for nemo@optimus.ietf.org; Sun, 22 Feb 2004 10:48:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00023 for ; Sun, 22 Feb 2004 10:48:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuvqF-0000V2-00 for nemo@ietf.org; Sun, 22 Feb 2004 10:48:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuvpH-0000R9-00 for nemo@ietf.org; Sun, 22 Feb 2004 10:47:27 -0500 Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx with esmtp (Exim 4.12) id 1AuvoI-0000Mp-00 for nemo@ietf.org; Sun, 22 Feb 2004 10:46:27 -0500 Received: (from eun@localhost) by mmlab.snu.ac.kr (8.11.6/8.11.6) id i1MFkIu48278; Mon, 23 Feb 2004 00:46:18 +0900 (KST) (envelope-from eun) Date: Mon, 23 Feb 2004 00:46:18 +0900 From: Eun Kyoung Paik To: nemo@ietf.org Message-ID: <20040223004618.A48134@mmlab.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [nemo] merged multihoming draft 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi all, As the result of last IETF meeting, we merged three of multihoming related drafts into one. http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt Your comments on this draft are welcome. Regards, Eun Kyoung From nemo-admin@ietf.org Sun Feb 22 21:52:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20180 for ; Sun, 22 Feb 2004 21:52:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av6CP-0006SU-MH; Sun, 22 Feb 2004 21:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av6CH-0006RO-9F for nemo@optimus.ietf.org; Sun, 22 Feb 2004 21:51:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20177 for ; Sun, 22 Feb 2004 21:51:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av6CE-00004h-00 for nemo@ietf.org; Sun, 22 Feb 2004 21:51:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av6BI-00002L-00 for nemo@ietf.org; Sun, 22 Feb 2004 21:50:52 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1Av6B7-0007nQ-00 for nemo@ietf.org; Sun, 22 Feb 2004 21:50:41 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1N2g0N7013551; Mon, 23 Feb 2004 10:42:00 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 98095B240A7; Mon, 23 Feb 2004 10:44:53 +0800 (SGT) Subject: Re: [nemo] merged multihoming draft From: Chan-Wah NG To: Eun Kyoung Paik Cc: IETF NEMO WG In-Reply-To: <20040223004618.A48134@mmlab.snu.ac.kr> References: <20040223004618.A48134@mmlab.snu.ac.kr> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1077504292.5628.45.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 23 Feb 2004 10:44:53 +0800 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Sun, 2004-02-22 at 23:46, Eun Kyoung Paik wrote: > Hi all, > > As the result of last IETF meeting, we merged three of > multihoming related drafts into one. > > http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt > > Your comments on this draft are welcome. > > Regards, > Eun Kyoung Thank you, Eun-Kyoung. Like to take this opportunity to describe more on the changes to this draft. Firstly, Eun-Kyoung's problem statement draft is merged to this draft, so she won't be releasing an update of her draft. Secondly, we decided to combine effort with people working on multihoming issues in Mobile IPv6. For this purpose, we released draft-multihoming-generic-goals-and-benefits-00.txt. This draft contains general description of multihoming, and listed the benefits of multihoming. draft-ng-nemo-multihoming-issues-04.txt uses this generic draft as a baseline, and discusses the NEMO specific issues. Thirdly, we tried to shorten the draft. Well, we managed to shorten the main text of the draft, by moving some sections to the appendix. We felt that it is not necessary to list 3 different approaches to the taxonomy, and the WG largely is comfortable with the {w,x,y} (now called {x,y,z}) approach. Our next task is to focus on the scenario that is relevant to NEMO, and hopefully the next release of this draft will be a WG document. As always, comments and bashing of this drafts are always welcomed. /rgds /cwng From exim@www1.ietf.org Sun Feb 22 21:54:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20246 for ; Sun, 22 Feb 2004 21:54:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av6EG-0006dn-Uy for nemo-archive@odin.ietf.org; Sun, 22 Feb 2004 21:53:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N2ruME025523 for nemo-archive@odin.ietf.org; Sun, 22 Feb 2004 21:53:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av6EG-0006da-QH for nemo-web-archive@optimus.ietf.org; Sun, 22 Feb 2004 21:53:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20243 for ; Sun, 22 Feb 2004 21:53:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av6ED-0000BW-00 for nemo-web-archive@ietf.org; Sun, 22 Feb 2004 21:53:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av6DH-00008f-00 for nemo-web-archive@ietf.org; Sun, 22 Feb 2004 21:52:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Av6CW-00005U-00 for nemo-web-archive@ietf.org; Sun, 22 Feb 2004 21:52:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av6CP-0006SU-MH; Sun, 22 Feb 2004 21:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av6CH-0006RO-9F for nemo@optimus.ietf.org; Sun, 22 Feb 2004 21:51:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20177 for ; Sun, 22 Feb 2004 21:51:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av6CE-00004h-00 for nemo@ietf.org; Sun, 22 Feb 2004 21:51:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av6BI-00002L-00 for nemo@ietf.org; Sun, 22 Feb 2004 21:50:52 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1Av6B7-0007nQ-00 for nemo@ietf.org; Sun, 22 Feb 2004 21:50:41 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1N2g0N7013551; Mon, 23 Feb 2004 10:42:00 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 98095B240A7; Mon, 23 Feb 2004 10:44:53 +0800 (SGT) Subject: Re: [nemo] merged multihoming draft From: Chan-Wah NG To: Eun Kyoung Paik Cc: IETF NEMO WG In-Reply-To: <20040223004618.A48134@mmlab.snu.ac.kr> References: <20040223004618.A48134@mmlab.snu.ac.kr> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1077504292.5628.45.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 23 Feb 2004 10:44:53 +0800 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Sun, 2004-02-22 at 23:46, Eun Kyoung Paik wrote: > Hi all, > > As the result of last IETF meeting, we merged three of > multihoming related drafts into one. > > http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt > > Your comments on this draft are welcome. > > Regards, > Eun Kyoung Thank you, Eun-Kyoung. Like to take this opportunity to describe more on the changes to this draft. Firstly, Eun-Kyoung's problem statement draft is merged to this draft, so she won't be releasing an update of her draft. Secondly, we decided to combine effort with people working on multihoming issues in Mobile IPv6. For this purpose, we released draft-multihoming-generic-goals-and-benefits-00.txt. This draft contains general description of multihoming, and listed the benefits of multihoming. draft-ng-nemo-multihoming-issues-04.txt uses this generic draft as a baseline, and discusses the NEMO specific issues. Thirdly, we tried to shorten the draft. Well, we managed to shorten the main text of the draft, by moving some sections to the appendix. We felt that it is not necessary to list 3 different approaches to the taxonomy, and the WG largely is comfortable with the {w,x,y} (now called {x,y,z}) approach. Our next task is to focus on the scenario that is relevant to NEMO, and hopefully the next release of this draft will be a WG document. As always, comments and bashing of this drafts are always welcomed. /rgds /cwng From nemo-admin@ietf.org Mon Feb 23 01:36:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26664 for ; Mon, 23 Feb 2004 01:36:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av9hD-0002AX-LD; Mon, 23 Feb 2004 01:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av9h9-00029o-7r for nemo@optimus.ietf.org; Mon, 23 Feb 2004 01:35:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26652 for ; Mon, 23 Feb 2004 01:35:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av9h6-0005Rl-00 for nemo@ietf.org; Mon, 23 Feb 2004 01:35:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av9g7-0005OJ-00 for nemo@ietf.org; Mon, 23 Feb 2004 01:34:56 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1Av9f8-0005J2-00 for nemo@ietf.org; Mon, 23 Feb 2004 01:33:55 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id EC3885D0FA; Mon, 23 Feb 2004 15:33:23 +0900 (JST) Date: Mon, 23 Feb 2004 15:33:05 +0900 From: Thierry Ernst To: Chan-Wah NG Cc: eun@mmlab.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] merged multihoming draft Message-Id: <20040223153305.060206bb.ernst@sfc.wide.ad.jp> In-Reply-To: <1077504292.5628.45.camel@localhost> References: <20040223004618.A48134@mmlab.snu.ac.kr> <1077504292.5628.45.camel@localhost> 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 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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, By the way, the generic draft Goals and Benefits of Multihoming" has been badly referenced into draft draft-ng-nemo-multihoming-issues-03.txt. Reference 6 should read: [6] Ernst, T., "Goals and Benefits of Multihoming", draft-multihoming-generic-goals-and-benefits-00 (work in progress), February 2004. I recommend people interested in the multihoming discussion to read this draft as it will serve as a basement to motivate the needs and benefits for multihoming in NEMO. The draft lists a number of scenarios. Some scenarios apply to fixed nodes, while other apply to mobile nodes, or fixed nodes in mobile networks, but usually all scenarios could apply to either cases. This is the reason why the document has not been submitted to a particular WG. As a result of this generic draft, all non NEMO-issues are expected to be moved out of draft-ng-nemo-multihoming-issues; some non NEMO-specific paragraphs may remain but will be removed as we improve both documents. Thierry. On Mon, 23 Feb 2004 10:44:53 +0800 Chan-Wah NG wrote: > On Sun, 2004-02-22 at 23:46, Eun Kyoung Paik wrote: > > Hi all, > > > > As the result of last IETF meeting, we merged three of > > multihoming related drafts into one. > > > > http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt > > > > Your comments on this draft are welcome. > > > > Regards, > > Eun Kyoung > > > Thank you, Eun-Kyoung. > > Like to take this opportunity to describe more on the changes to this > draft. > > Firstly, Eun-Kyoung's problem statement draft is merged to this draft, > so she won't be releasing an update of her draft. > > Secondly, we decided to combine effort with people working on > multihoming issues in Mobile IPv6. For this purpose, we released > draft-multihoming-generic-goals-and-benefits-00.txt. This draft > contains general description of multihoming, and listed the benefits of > multihoming. draft-ng-nemo-multihoming-issues-04.txt uses this generic > draft as a baseline, and discusses the NEMO specific issues. > > Thirdly, we tried to shorten the draft. Well, we managed to shorten the > main text of the draft, by moving some sections to the appendix. We > felt that it is not necessary to list 3 different approaches to the > taxonomy, and the WG largely is comfortable with the {w,x,y} (now called > {x,y,z}) approach. > > Our next task is to focus on the scenario that is relevant to NEMO, and > hopefully the next release of this draft will be a WG document. > > As always, comments and bashing of this drafts are always welcomed. > > /rgds > /cwng From exim@www1.ietf.org Mon Feb 23 01:38:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26828 for ; Mon, 23 Feb 2004 01:38:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av9jD-0002j1-OR for nemo-archive@odin.ietf.org; Mon, 23 Feb 2004 01:38:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N6c7xM010464 for nemo-archive@odin.ietf.org; Mon, 23 Feb 2004 01:38:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av9jC-0002if-NC for nemo-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 01:38:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26771 for ; Mon, 23 Feb 2004 01:38:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av9j9-0005eF-00 for nemo-web-archive@ietf.org; Mon, 23 Feb 2004 01:38:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av9iC-0005Y1-00 for nemo-web-archive@ietf.org; Mon, 23 Feb 2004 01:37:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Av9hC-0005Sx-00 for nemo-web-archive@ietf.org; Mon, 23 Feb 2004 01:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av9hD-0002AX-LD; Mon, 23 Feb 2004 01:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av9h9-00029o-7r for nemo@optimus.ietf.org; Mon, 23 Feb 2004 01:35:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26652 for ; Mon, 23 Feb 2004 01:35:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av9h6-0005Rl-00 for nemo@ietf.org; Mon, 23 Feb 2004 01:35:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av9g7-0005OJ-00 for nemo@ietf.org; Mon, 23 Feb 2004 01:34:56 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1Av9f8-0005J2-00 for nemo@ietf.org; Mon, 23 Feb 2004 01:33:55 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id EC3885D0FA; Mon, 23 Feb 2004 15:33:23 +0900 (JST) Date: Mon, 23 Feb 2004 15:33:05 +0900 From: Thierry Ernst To: Chan-Wah NG Cc: eun@mmlab.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] merged multihoming draft Message-Id: <20040223153305.060206bb.ernst@sfc.wide.ad.jp> In-Reply-To: <1077504292.5628.45.camel@localhost> References: <20040223004618.A48134@mmlab.snu.ac.kr> <1077504292.5628.45.camel@localhost> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, By the way, the generic draft Goals and Benefits of Multihoming" has been badly referenced into draft draft-ng-nemo-multihoming-issues-03.txt. Reference 6 should read: [6] Ernst, T., "Goals and Benefits of Multihoming", draft-multihoming-generic-goals-and-benefits-00 (work in progress), February 2004. I recommend people interested in the multihoming discussion to read this draft as it will serve as a basement to motivate the needs and benefits for multihoming in NEMO. The draft lists a number of scenarios. Some scenarios apply to fixed nodes, while other apply to mobile nodes, or fixed nodes in mobile networks, but usually all scenarios could apply to either cases. This is the reason why the document has not been submitted to a particular WG. As a result of this generic draft, all non NEMO-issues are expected to be moved out of draft-ng-nemo-multihoming-issues; some non NEMO-specific paragraphs may remain but will be removed as we improve both documents. Thierry. On Mon, 23 Feb 2004 10:44:53 +0800 Chan-Wah NG wrote: > On Sun, 2004-02-22 at 23:46, Eun Kyoung Paik wrote: > > Hi all, > > > > As the result of last IETF meeting, we merged three of > > multihoming related drafts into one. > > > > http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt > > > > Your comments on this draft are welcome. > > > > Regards, > > Eun Kyoung > > > Thank you, Eun-Kyoung. > > Like to take this opportunity to describe more on the changes to this > draft. > > Firstly, Eun-Kyoung's problem statement draft is merged to this draft, > so she won't be releasing an update of her draft. > > Secondly, we decided to combine effort with people working on > multihoming issues in Mobile IPv6. For this purpose, we released > draft-multihoming-generic-goals-and-benefits-00.txt. This draft > contains general description of multihoming, and listed the benefits of > multihoming. draft-ng-nemo-multihoming-issues-04.txt uses this generic > draft as a baseline, and discusses the NEMO specific issues. > > Thirdly, we tried to shorten the draft. Well, we managed to shorten the > main text of the draft, by moving some sections to the appendix. We > felt that it is not necessary to list 3 different approaches to the > taxonomy, and the WG largely is comfortable with the {w,x,y} (now called > {x,y,z}) approach. > > Our next task is to focus on the scenario that is relevant to NEMO, and > hopefully the next release of this draft will be a WG document. > > As always, comments and bashing of this drafts are always welcomed. > > /rgds > /cwng From nemo-admin@ietf.org Mon Feb 23 01:43:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26988 for ; Mon, 23 Feb 2004 01:43:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av9nx-00038e-Il; Mon, 23 Feb 2004 01:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av9my-00037N-CE for nemo@optimus.ietf.org; Mon, 23 Feb 2004 01:42:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26969 for ; Mon, 23 Feb 2004 01:41:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av9mu-0005sy-00 for nemo@ietf.org; Mon, 23 Feb 2004 01:41:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av9m0-0005qe-00 for nemo@ietf.org; Mon, 23 Feb 2004 01:41:01 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1Av9lM-0005kb-00 for nemo@ietf.org; Mon, 23 Feb 2004 01:40:20 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id E21555D36D; Mon, 23 Feb 2004 15:38:38 +0900 (JST) Date: Mon, 23 Feb 2004 15:38:20 +0900 From: Thierry Ernst To: Chan-Wah NG Cc: eun@mmlab.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] merged multihoming draft Message-Id: <20040223153820.10f6a14c.ernst@sfc.wide.ad.jp> In-Reply-To: <1077504292.5628.45.camel@localhost> References: <20040223004618.A48134@mmlab.snu.ac.kr> <1077504292.5628.45.camel@localhost> 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 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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 again, Chan-Wah NG wrote: > http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt > Our next task is to focus on the scenario that is relevant to NEMO, and > hopefully the next release of this draft will be a WG document. Another point: I would like to raise this to the attention of the working group. Now than multihoming drafts have been merged, we would like to decide if the document as it is now corresponds to the needs of the NEMO WG. If yes, it should become a WG document as we have said in Minneapolis. We also expect feedback from the WG concerning the structure and content of the document: - any specific section you may consider useless - any specific section you may consider missing - etc. Thank you, Thierry. From exim@www1.ietf.org Mon Feb 23 01:45:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27045 for ; Mon, 23 Feb 2004 01:45:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av9pr-0003JK-Ls for nemo-archive@odin.ietf.org; Mon, 23 Feb 2004 01:44:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N6ix11012720 for nemo-archive@odin.ietf.org; Mon, 23 Feb 2004 01:44:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av9pr-0003J5-Gf for nemo-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 01:44:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27023 for ; Mon, 23 Feb 2004 01:44:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av9po-00062s-00 for nemo-web-archive@ietf.org; Mon, 23 Feb 2004 01:44:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av9or-0005z4-00 for nemo-web-archive@ietf.org; Mon, 23 Feb 2004 01:43:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Av9nw-0005wO-00 for nemo-web-archive@ietf.org; Mon, 23 Feb 2004 01:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av9nx-00038e-Il; Mon, 23 Feb 2004 01:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av9my-00037N-CE for nemo@optimus.ietf.org; Mon, 23 Feb 2004 01:42:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26969 for ; Mon, 23 Feb 2004 01:41:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av9mu-0005sy-00 for nemo@ietf.org; Mon, 23 Feb 2004 01:41:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av9m0-0005qe-00 for nemo@ietf.org; Mon, 23 Feb 2004 01:41:01 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1Av9lM-0005kb-00 for nemo@ietf.org; Mon, 23 Feb 2004 01:40:20 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id E21555D36D; Mon, 23 Feb 2004 15:38:38 +0900 (JST) Date: Mon, 23 Feb 2004 15:38:20 +0900 From: Thierry Ernst To: Chan-Wah NG Cc: eun@mmlab.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] merged multihoming draft Message-Id: <20040223153820.10f6a14c.ernst@sfc.wide.ad.jp> In-Reply-To: <1077504292.5628.45.camel@localhost> References: <20040223004618.A48134@mmlab.snu.ac.kr> <1077504292.5628.45.camel@localhost> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all again, Chan-Wah NG wrote: > http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt > Our next task is to focus on the scenario that is relevant to NEMO, and > hopefully the next release of this draft will be a WG document. Another point: I would like to raise this to the attention of the working group. Now than multihoming drafts have been merged, we would like to decide if the document as it is now corresponds to the needs of the NEMO WG. If yes, it should become a WG document as we have said in Minneapolis. We also expect feedback from the WG concerning the structure and content of the document: - any specific section you may consider useless - any specific section you may consider missing - etc. Thank you, Thierry. From nemo-admin@ietf.org Mon Feb 23 11:12:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04246 for ; Mon, 23 Feb 2004 11:12:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvIga-0003Bs-Vg; Mon, 23 Feb 2004 11:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvIg0-00036A-DC for nemo@optimus.ietf.org; Mon, 23 Feb 2004 11:11:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04168 for ; Mon, 23 Feb 2004 11:11:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvIfx-0001EC-00 for nemo@ietf.org; Mon, 23 Feb 2004 11:11:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvIf4-0001AA-00 for nemo@ietf.org; Mon, 23 Feb 2004 11:10:27 -0500 Received: from smtp.irisa.fr ([131.254.130.26]) by ietf-mx with esmtp (Exim 4.12) id 1AvIeg-00016B-00 for nemo@ietf.org; Mon, 23 Feb 2004 11:10:02 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.irisa.fr (Postfix) with ESMTP id D3278FB44; Mon, 23 Feb 2004 17:10:01 +0100 (CET) Received: from smtp.irisa.fr ([131.254.130.26]) by localhost (meli.irisa.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15980-04; Mon, 23 Feb 2004 17:10:01 +0100 (CET) Received: from irisa.fr (pc-valis.rennes.enst-bretagne.fr [193.52.74.205]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.irisa.fr (Postfix) with ESMTP id 62267FB3F; Mon, 23 Feb 2004 17:10:01 +0100 (CET) Message-ID: <403A25C2.8060307@irisa.fr> Date: Mon, 23 Feb 2004 17:09:38 +0100 From: Laurent Toutain User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at irisa.fr X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] autoconfiguration with DHCPv6 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'm not familiar with the network mobility vocabulary, I'm little confused but all NEMO acronyms (but I will learn them I promise), but I was very interested by the draft-droms-nemo-dhcpv6-pd-01.txt since it covers some concerns we got in the late ZEROUTER BOF.It could be important to have solution that works either when the MN is in its home network and away and with any kind of architecture, not only a single homed network. I will compare this draft to the proposal we published sevral month away and that can be found at http://internet.motlabs.com/zerouter/drafts/draft-chelius-router-autoconf-00.txt If I understand the draft is for asking the HA to assign a prefix to the Mobile Network either when the MR is at home or in a visiting network. I think this solution works well for a Mobile Network with only one MR, but it will be very difficult to generalize it to Home Networking autoconfiguration (like DSLAC) for several reasons : - in a home network, you may have several routers on a same link. In that case, all the routers will asks for a prefix using DHCPv6 and you may have several prefixes for each link. - in a home network, at least during the boot phase, it is not guaranteed that you have access to a DHCPv6 server since prefixes allocation and routing are not establish (it is not the case in NEMO, you assume a certain stability in visited networks). Laurent From exim@www1.ietf.org Mon Feb 23 11:13:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04293 for ; Mon, 23 Feb 2004 11:13:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvIhy-0003OZ-BU for nemo-archive@odin.ietf.org; Mon, 23 Feb 2004 11:13:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NGDQ5Q013042 for nemo-archive@odin.ietf.org; Mon, 23 Feb 2004 11:13:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvIhy-0003OH-5i for nemo-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 11:13:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04285 for ; Mon, 23 Feb 2004 11:13:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvIhx-0001P9-00 for nemo-web-archive@ietf.org; Mon, 23 Feb 2004 11:13:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvIhB-0001LA-00 for nemo-web-archive@ietf.org; Mon, 23 Feb 2004 11:12:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvIgc-0001Fo-00 for nemo-web-archive@ietf.org; Mon, 23 Feb 2004 11:12:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvIga-0003Bs-Vg; Mon, 23 Feb 2004 11:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvIg0-00036A-DC for nemo@optimus.ietf.org; Mon, 23 Feb 2004 11:11:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04168 for ; Mon, 23 Feb 2004 11:11:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvIfx-0001EC-00 for nemo@ietf.org; Mon, 23 Feb 2004 11:11:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvIf4-0001AA-00 for nemo@ietf.org; Mon, 23 Feb 2004 11:10:27 -0500 Received: from smtp.irisa.fr ([131.254.130.26]) by ietf-mx with esmtp (Exim 4.12) id 1AvIeg-00016B-00 for nemo@ietf.org; Mon, 23 Feb 2004 11:10:02 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.irisa.fr (Postfix) with ESMTP id D3278FB44; Mon, 23 Feb 2004 17:10:01 +0100 (CET) Received: from smtp.irisa.fr ([131.254.130.26]) by localhost (meli.irisa.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15980-04; Mon, 23 Feb 2004 17:10:01 +0100 (CET) Received: from irisa.fr (pc-valis.rennes.enst-bretagne.fr [193.52.74.205]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.irisa.fr (Postfix) with ESMTP id 62267FB3F; Mon, 23 Feb 2004 17:10:01 +0100 (CET) Message-ID: <403A25C2.8060307@irisa.fr> Date: Mon, 23 Feb 2004 17:09:38 +0100 From: Laurent Toutain User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at irisa.fr Content-Transfer-Encoding: 7bit Subject: [nemo] autoconfiguration with DHCPv6 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm not familiar with the network mobility vocabulary, I'm little confused but all NEMO acronyms (but I will learn them I promise), but I was very interested by the draft-droms-nemo-dhcpv6-pd-01.txt since it covers some concerns we got in the late ZEROUTER BOF.It could be important to have solution that works either when the MN is in its home network and away and with any kind of architecture, not only a single homed network. I will compare this draft to the proposal we published sevral month away and that can be found at http://internet.motlabs.com/zerouter/drafts/draft-chelius-router-autoconf-00.txt If I understand the draft is for asking the HA to assign a prefix to the Mobile Network either when the MR is at home or in a visiting network. I think this solution works well for a Mobile Network with only one MR, but it will be very difficult to generalize it to Home Networking autoconfiguration (like DSLAC) for several reasons : - in a home network, you may have several routers on a same link. In that case, all the routers will asks for a prefix using DHCPv6 and you may have several prefixes for each link. - in a home network, at least during the boot phase, it is not guaranteed that you have access to a DHCPv6 server since prefixes allocation and routing are not establish (it is not the case in NEMO, you assume a certain stability in visited networks). Laurent From nemo-admin@ietf.org Tue Feb 24 07:21:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16102 for ; Tue, 24 Feb 2004 07:21:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbYc-0001Tr-Pl; Tue, 24 Feb 2004 07:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbY8-0001Sh-0r for nemo@optimus.ietf.org; Tue, 24 Feb 2004 07:20:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15988 for ; Tue, 24 Feb 2004 07:20:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvbY7-0006JF-00 for nemo@ietf.org; Tue, 24 Feb 2004 07:20:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvbXE-0006AK-00 for nemo@ietf.org; Tue, 24 Feb 2004 07:19:37 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AvbWH-0005zq-00 for nemo@ietf.org; Tue, 24 Feb 2004 07:18:38 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1OCIaqY019954 for ; Tue, 24 Feb 2004 13:18:36 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 13:18:36 +0100 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FMHBV04R; Tue, 24 Feb 2004 13:18:44 +0100 Message-ID: <403B4083.5080501@ericsson.com> Date: Tue, 24 Feb 2004 13:16:03 +0100 X-Sybari-Trust: b50f2c3d c77f3eb6 59788f6c 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst CC: Chan-Wah NG , eun@mmlab.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] merged multihoming draft References: <20040223004618.A48134@mmlab.snu.ac.kr> <1077504292.5628.45.camel@localhost> <20040223153820.10f6a14c.ernst@sfc.wide.ad.jp> In-Reply-To: <20040223153820.10f6a14c.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2004 12:18:36.0797 (UTC) FILETIME=[541F12D0:01C3FAD0] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Thierry, Thierry Ernst wrote: > Dear all again, > > Chan-Wah NG wrote: > >> http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt >>Our next task is to focus on the scenario that is relevant to NEMO, and >>hopefully the next release of this draft will be a WG document. > > > Another point: I would like to raise this to the attention of the > working group. Now than multihoming drafts have been merged, we would > like to decide if the document as it is now corresponds to the needs of > the NEMO WG. If yes, it should become a WG document as we have said > in Minneapolis. IMO this I-D should be made a WG doc. I have a comment on chapter 5: > o (N,1,N) Mobile Network > > The (N,1,N) mobile network has multiple active egress mobile > routers registering to the same home-agent, and advertising > multiple prefixes. If a mobile router is advertising more than one > prefix, we have the same problem as (1,1,N) as in how to register > more than one NEMO-prefix to the same home-agent. > > On the other hand, if each mobile router take cares of a separate > (and only one) NEMO-prefix, then there should not be any > NEMO-specific problem. As I remember Erik once said to me in an earlier NEMO discussion: we don't want to go down the second alternative. MRs should not advertise different prefixes to the same link - they must advertise the same prefix set (or otherwise be coordinated and able to route traffic on behalf of each other). For an MNN, each MR is a just default router and all default routers must be able to route all traffic. We don't want to put such requirements on the MNNs to map each prefix to a specific exit router and remembering to use the correct source address when sending to a specific default router. Such a general host behaviour may be required for multihoming to work in IPv6 some day, but we have not reached that point yet. /Mattias This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From exim@www1.ietf.org Tue Feb 24 07:23:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16239 for ; Tue, 24 Feb 2004 07:23:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbaZ-0001iu-2S for nemo-archive@odin.ietf.org; Tue, 24 Feb 2004 07:23:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OCN30M006618 for nemo-archive@odin.ietf.org; Tue, 24 Feb 2004 07:23:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbaY-0001if-RW for nemo-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 07:23:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16199 for ; Tue, 24 Feb 2004 07:23:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvbaY-0006dP-00 for nemo-web-archive@ietf.org; Tue, 24 Feb 2004 07:23:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvbZb-0006XD-00 for nemo-web-archive@ietf.org; Tue, 24 Feb 2004 07:22:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvbYf-0006PD-00 for nemo-web-archive@ietf.org; Tue, 24 Feb 2004 07:21:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbYc-0001Tr-Pl; Tue, 24 Feb 2004 07:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbY8-0001Sh-0r for nemo@optimus.ietf.org; Tue, 24 Feb 2004 07:20:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15988 for ; Tue, 24 Feb 2004 07:20:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvbY7-0006JF-00 for nemo@ietf.org; Tue, 24 Feb 2004 07:20:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvbXE-0006AK-00 for nemo@ietf.org; Tue, 24 Feb 2004 07:19:37 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AvbWH-0005zq-00 for nemo@ietf.org; Tue, 24 Feb 2004 07:18:38 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1OCIaqY019954 for ; Tue, 24 Feb 2004 13:18:36 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 13:18:36 +0100 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FMHBV04R; Tue, 24 Feb 2004 13:18:44 +0100 Message-ID: <403B4083.5080501@ericsson.com> Date: Tue, 24 Feb 2004 13:16:03 +0100 X-Sybari-Trust: b50f2c3d c77f3eb6 59788f6c 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst CC: Chan-Wah NG , eun@mmlab.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] merged multihoming draft References: <20040223004618.A48134@mmlab.snu.ac.kr> <1077504292.5628.45.camel@localhost> <20040223153820.10f6a14c.ernst@sfc.wide.ad.jp> In-Reply-To: <20040223153820.10f6a14c.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2004 12:18:36.0797 (UTC) FILETIME=[541F12D0:01C3FAD0] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Thierry, Thierry Ernst wrote: > Dear all again, > > Chan-Wah NG wrote: > >> http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt >>Our next task is to focus on the scenario that is relevant to NEMO, and >>hopefully the next release of this draft will be a WG document. > > > Another point: I would like to raise this to the attention of the > working group. Now than multihoming drafts have been merged, we would > like to decide if the document as it is now corresponds to the needs of > the NEMO WG. If yes, it should become a WG document as we have said > in Minneapolis. IMO this I-D should be made a WG doc. I have a comment on chapter 5: > o (N,1,N) Mobile Network > > The (N,1,N) mobile network has multiple active egress mobile > routers registering to the same home-agent, and advertising > multiple prefixes. If a mobile router is advertising more than one > prefix, we have the same problem as (1,1,N) as in how to register > more than one NEMO-prefix to the same home-agent. > > On the other hand, if each mobile router take cares of a separate > (and only one) NEMO-prefix, then there should not be any > NEMO-specific problem. As I remember Erik once said to me in an earlier NEMO discussion: we don't want to go down the second alternative. MRs should not advertise different prefixes to the same link - they must advertise the same prefix set (or otherwise be coordinated and able to route traffic on behalf of each other). For an MNN, each MR is a just default router and all default routers must be able to route all traffic. We don't want to put such requirements on the MNNs to map each prefix to a specific exit router and remembering to use the correct source address when sending to a specific default router. Such a general host behaviour may be required for multihoming to work in IPv6 some day, but we have not reached that point yet. /Mattias This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From nemo-admin@ietf.org Tue Feb 24 09:50:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23085 for ; Tue, 24 Feb 2004 09:50:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avdso-00033N-Ow; Tue, 24 Feb 2004 09:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avdrr-0002zl-SD for nemo@optimus.ietf.org; Tue, 24 Feb 2004 09:49:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22977 for ; Tue, 24 Feb 2004 09:49:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avdrp-0004rf-00 for nemo@ietf.org; Tue, 24 Feb 2004 09:49:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avdqu-0004lW-00 for nemo@ietf.org; Tue, 24 Feb 2004 09:48:05 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1Avdpx-0004az-00 for nemo@ietf.org; Tue, 24 Feb 2004 09:47:05 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 6BD665D0F8; Tue, 24 Feb 2004 23:46:34 +0900 (JST) Date: Tue, 24 Feb 2004 23:46:12 +0900 From: Thierry Ernst To: nemo Cc: tj Message-Id: <20040224234612.05cc7fe8.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 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO Agenda 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 # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # NEMO WG - 59th IETF Seoul - Monday 1st March 2004 9.00 AM # # WG Page: http://www.ietf.org/html.charters/nemo-charter.html # All drafts available directly from http://www.mobilenetworks.org/nemo/ # or from the IETF web page: http://www.ietf.org/internet-drafts/ # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ o Agenda Bashing ............................................ 5 mins Chairs o NEMO status and milestones ................................ 5 mins Chairs o NEMO Basic Support Specification...........................10 mins TJ Kniveton To be read: ~~~~~~~~~~~ Network Mobility (NEMO) Basic Support Protocol http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-02.txt Issue List http://people.nokia.net/vijayd/nemo/issues.html To be discussed: ~~~~~~~~~~~~~~~~ - documnet status - report on San Jose's Connectathlon (Feb.04) o NEMO Basic Support Usages .................................10 mins. To be read: ~~~~~~~~~~~ Examples of Basic NEMO Usage http://www.ietf.org/internet-drafts/draft-thubert-nemo-basic-usages-01.txt To be discussed: ~~~~~~~~~~~~~~~~ - make draft-thubert a WG doc - agree on the exact content of the document o Threat in NEMO Basic Support...............................10 mins To be read: ~~~~~~~~~~~ Threats for Basic Network Mobility Support (NEMO threats) http://www.ietf.org/internet-drafts/draft-petrescu-nemo-threats-01.txt Threat Analysis for NEMO http://www.ietf.org/internet-drafts/draft-jung-nemo-threat-analysis-01.txt To be discussed: ~~~~~~~~~~~~~~~~ - how to proceed to have a WG document o Prefix Delegation..........................................10 mins To be read: ~~~~~~~~~~~ DHCPv6 Prefix Delegation for NEMO http://www.ietf.org/internet-drafts/draft-droms-nemo-dhcpv6-pd-01.txt o Multihoming Pb Statement...................................30 mins Nicolas Montavont, ChanWah Ng, EunKyoung Paik To be read: ~~~~~~~~~~~ Goals and Benefits of Multihoming http://www.ietf.org/internet-drafts/draft-multihoming-generic-goals-and-benefits-00.txt Multihoming Issues in Bi-Directional Tunneling http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt To be discussed: ~~~~~~~~~~~~~~~ - make draft-ng a WG doc - agree on exact content of WG doc o Threat in multihoming......................................10 mins Seongho Cho To be read: ~~~~~~~~~~~ Threat for Multi-homed Mobile Networks http://www.ietf.org/internet-drafts/draft-cho-nemo-threat-multihoming-00.txt o NEMO Terminology Upates .................................. 10 mins Thierry Ernst To be read: ~~~~~~~~~~~ Network Mobility Support Terminology http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-01.txt To be discussed: ~~~~~~~~~~~~~~~~ - document should go to last call - do we keep the multihoming and 'nested + multihoming' examples within this document ? o NEMO Goals and Requirements Update ....................... 5 mins Thierry Ernst To be read: ~~~~~~~~~~~ Network Mobility Support Goals and Requirements http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-02.txt To be discussed: ~~~~~~~~~~~~~~~~ - document should go to last call - is section 5 "NEMO Basic Support One-liner Requirements" still meaningful ? o IPR........................................................10 mins TJ To be read: ~~~~~~~~~~~ Guidelines for Working Groups on Intellectual Property Issues (RFC3669) http://www.ietf.org/rfc/rfc3669.txt?number=3669 o Analysis of the Solution Space for Route Optimization......10 mins To be read: ~~~~~~~~~~~ Several solution drafts have been submitted last year (see below) To be discussed: ~~~~~~~~~~~~~~~~ - at this point, we don't intent to speak about solutions, but only the problem statement and analysis of the solution space. - how are we going to proceed with this item ? o Conclusion and next steps.................................. 5 mins # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Other Internet Drafts Recently Submitted to the NEMO WG # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Inter Home Agents Protocol (HAHA) http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-haha-01.txt Hierarchical Mobile Router Advertisement for nested mobile networks http://www.ietf.org/internet-drafts/draft-cho-nemo-hmra-00.txt ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-02.txt Taxonomy of Route Optimization models in the Nemo Context http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-02.txt Route Optimization for Mobile Nodes in Mobile Network http://www.ietf.org/internet-drafts/draft-leekj-nemo-ro-pd-02.txt Issues in Designing Mobile IPv6 Network Mobility http://www.ietf.org/internet-drafts/draft-petrescu-nemo-mrha-03.txt Laboratory and "Field" Experiments with IPv6 Mobile Networks in Vehicular Environments October 03 http://www.ietf.org/internet-drafts/draft-lach-nemo-experiments-overdrive-01.txt ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network Feb.04 http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-02.txt Route Optimization for Mobile Nodes in Mobile Network based on Prefix Delegation Feb.04 http://www.ietf.org/internet-drafts/draft-leekj-nemo-ro-pd-02.txt Secure Nested Tunnels Optimization using Nested Path Information Sept.03 http://www.ietf.org/internet-drafts/draft-na-nemo-nested-path-info-00.txt HMIP based Route optimization method in a mobile network Oct.03 http://www.ietf.org/internet-drafts/draft-ohnishi-nemo-ro-hmip-00.txt Mobile Network Prefix Delegation extension for Mobile IPv6 March 03 http://www.ietf.org/internet-drafts/draft-paakkonen-nemo-prefix-delegation-00.txt IPv6 Reverse Routing Header and its application to Mobile Networks Feb. 04 http://www.ietf.org/internet-drafts/draft-thubert-nemo-reverse-routing-header-04.txt # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Related Documents Useful for Today's Meeting # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Goals and Benefits of Multihoming http://www.ietf.org/internet-drafts/draft-multihoming-generic-goals-and-benefits-00.txt IPv6 addressing in a heterogeneous MANET-network http://www.ietf.org/internet-drafts/draft-paakkonen-addressing-htr-manet-00.txt # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Older Draft Submitted to the NEMO WG (expired) # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - draft-thubert-nemo-ipv4-traversal-01.txt (expired) IPv4 traversal for MIPv6 based Mobile Routers May 03 - http://www.ietf.org/internet-drafts/draft-perera-nemo-extended-00.txt Extended Network Mobility Support (expired) - draft-hkang-nemo-ro-tlmr-00.txt (expired) Route Optimization for Mobile Network by Using Bi-directional Between Home Agent and Top Level Mobile Router June 03 # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # WG Milestones # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ o Former milestones as currently shown on the web: 1. Mar 03 Submit terminology and requirements documents (for Basic support). 2. May 03 Submit Threat analysis and security requirements for NEMO. 3. Aug 03 Submit solution for basic support to IESG. 4. Nov 03 Submit MIB for Basic support to the IESG. 5. Mar 04 Submit the analysis of the solution space for route optimization. 6. Jun 04 Shut down or recharter the WG to solve the route optimization. o New milestones as the web page should show very soon: 1. DONE Submit WG draft -00 on Terminology and Requirements (for Basic Support) 3. DONE Submit NEMO Basic Support to IESG 2. Mar 04 Submit WG draft -00 on Threat Analysis and Security Requirements for NEMO. 7. Mar 04 Submit WG draft -00 on Multihoming Problem Statement 8. Mar 04 Submit WG draft -00 on NEMO Basic Support Usages 9. Apr 04 Submit Terminology as Informational to IETG 10 Apr 04 Submit Goals and Requirements as Informational to IESG 11 Apr 04 Submit WG draft -00 on Prefix Delegation for NEMO 4. May 04 Submit WG draft -00 on MIB for NEMO Basic Support 5. Jun 04 Submit WG draft -00 on Analysis of the Solution Space for Route Optimization 6. Aug 04 Shut down or recharter the WG to solve route optimization From exim@www1.ietf.org Tue Feb 24 09:52:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23215 for ; Tue, 24 Feb 2004 09:52:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avduv-0003bH-H5 for nemo-archive@odin.ietf.org; Tue, 24 Feb 2004 09:52:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OEqDY8013833 for nemo-archive@odin.ietf.org; Tue, 24 Feb 2004 09:52:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avduv-0003b2-BS for nemo-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 09:52:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23140 for ; Tue, 24 Feb 2004 09:52:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avdut-0005Jb-00 for nemo-web-archive@ietf.org; Tue, 24 Feb 2004 09:52:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avdts-00058M-00 for nemo-web-archive@ietf.org; Tue, 24 Feb 2004 09:51:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avdsq-00050T-00 for nemo-web-archive@ietf.org; Tue, 24 Feb 2004 09:50:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avdso-00033N-Ow; Tue, 24 Feb 2004 09:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avdrr-0002zl-SD for nemo@optimus.ietf.org; Tue, 24 Feb 2004 09:49:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22977 for ; Tue, 24 Feb 2004 09:49:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avdrp-0004rf-00 for nemo@ietf.org; Tue, 24 Feb 2004 09:49:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avdqu-0004lW-00 for nemo@ietf.org; Tue, 24 Feb 2004 09:48:05 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1Avdpx-0004az-00 for nemo@ietf.org; Tue, 24 Feb 2004 09:47:05 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 6BD665D0F8; Tue, 24 Feb 2004 23:46:34 +0900 (JST) Date: Tue, 24 Feb 2004 23:46:12 +0900 From: Thierry Ernst To: nemo Cc: tj Message-Id: <20040224234612.05cc7fe8.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 Subject: [nemo] NEMO Agenda 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # NEMO WG - 59th IETF Seoul - Monday 1st March 2004 9.00 AM # # WG Page: http://www.ietf.org/html.charters/nemo-charter.html # All drafts available directly from http://www.mobilenetworks.org/nemo/ # or from the IETF web page: http://www.ietf.org/internet-drafts/ # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ o Agenda Bashing ............................................ 5 mins Chairs o NEMO status and milestones ................................ 5 mins Chairs o NEMO Basic Support Specification...........................10 mins TJ Kniveton To be read: ~~~~~~~~~~~ Network Mobility (NEMO) Basic Support Protocol http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-02.txt Issue List http://people.nokia.net/vijayd/nemo/issues.html To be discussed: ~~~~~~~~~~~~~~~~ - documnet status - report on San Jose's Connectathlon (Feb.04) o NEMO Basic Support Usages .................................10 mins. To be read: ~~~~~~~~~~~ Examples of Basic NEMO Usage http://www.ietf.org/internet-drafts/draft-thubert-nemo-basic-usages-01.txt To be discussed: ~~~~~~~~~~~~~~~~ - make draft-thubert a WG doc - agree on the exact content of the document o Threat in NEMO Basic Support...............................10 mins To be read: ~~~~~~~~~~~ Threats for Basic Network Mobility Support (NEMO threats) http://www.ietf.org/internet-drafts/draft-petrescu-nemo-threats-01.txt Threat Analysis for NEMO http://www.ietf.org/internet-drafts/draft-jung-nemo-threat-analysis-01.txt To be discussed: ~~~~~~~~~~~~~~~~ - how to proceed to have a WG document o Prefix Delegation..........................................10 mins To be read: ~~~~~~~~~~~ DHCPv6 Prefix Delegation for NEMO http://www.ietf.org/internet-drafts/draft-droms-nemo-dhcpv6-pd-01.txt o Multihoming Pb Statement...................................30 mins Nicolas Montavont, ChanWah Ng, EunKyoung Paik To be read: ~~~~~~~~~~~ Goals and Benefits of Multihoming http://www.ietf.org/internet-drafts/draft-multihoming-generic-goals-and-benefits-00.txt Multihoming Issues in Bi-Directional Tunneling http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt To be discussed: ~~~~~~~~~~~~~~~ - make draft-ng a WG doc - agree on exact content of WG doc o Threat in multihoming......................................10 mins Seongho Cho To be read: ~~~~~~~~~~~ Threat for Multi-homed Mobile Networks http://www.ietf.org/internet-drafts/draft-cho-nemo-threat-multihoming-00.txt o NEMO Terminology Upates .................................. 10 mins Thierry Ernst To be read: ~~~~~~~~~~~ Network Mobility Support Terminology http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-01.txt To be discussed: ~~~~~~~~~~~~~~~~ - document should go to last call - do we keep the multihoming and 'nested + multihoming' examples within this document ? o NEMO Goals and Requirements Update ....................... 5 mins Thierry Ernst To be read: ~~~~~~~~~~~ Network Mobility Support Goals and Requirements http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-02.txt To be discussed: ~~~~~~~~~~~~~~~~ - document should go to last call - is section 5 "NEMO Basic Support One-liner Requirements" still meaningful ? o IPR........................................................10 mins TJ To be read: ~~~~~~~~~~~ Guidelines for Working Groups on Intellectual Property Issues (RFC3669) http://www.ietf.org/rfc/rfc3669.txt?number=3669 o Analysis of the Solution Space for Route Optimization......10 mins To be read: ~~~~~~~~~~~ Several solution drafts have been submitted last year (see below) To be discussed: ~~~~~~~~~~~~~~~~ - at this point, we don't intent to speak about solutions, but only the problem statement and analysis of the solution space. - how are we going to proceed with this item ? o Conclusion and next steps.................................. 5 mins # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Other Internet Drafts Recently Submitted to the NEMO WG # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Inter Home Agents Protocol (HAHA) http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-haha-01.txt Hierarchical Mobile Router Advertisement for nested mobile networks http://www.ietf.org/internet-drafts/draft-cho-nemo-hmra-00.txt ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-02.txt Taxonomy of Route Optimization models in the Nemo Context http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-02.txt Route Optimization for Mobile Nodes in Mobile Network http://www.ietf.org/internet-drafts/draft-leekj-nemo-ro-pd-02.txt Issues in Designing Mobile IPv6 Network Mobility http://www.ietf.org/internet-drafts/draft-petrescu-nemo-mrha-03.txt Laboratory and "Field" Experiments with IPv6 Mobile Networks in Vehicular Environments October 03 http://www.ietf.org/internet-drafts/draft-lach-nemo-experiments-overdrive-01.txt ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network Feb.04 http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-02.txt Route Optimization for Mobile Nodes in Mobile Network based on Prefix Delegation Feb.04 http://www.ietf.org/internet-drafts/draft-leekj-nemo-ro-pd-02.txt Secure Nested Tunnels Optimization using Nested Path Information Sept.03 http://www.ietf.org/internet-drafts/draft-na-nemo-nested-path-info-00.txt HMIP based Route optimization method in a mobile network Oct.03 http://www.ietf.org/internet-drafts/draft-ohnishi-nemo-ro-hmip-00.txt Mobile Network Prefix Delegation extension for Mobile IPv6 March 03 http://www.ietf.org/internet-drafts/draft-paakkonen-nemo-prefix-delegation-00.txt IPv6 Reverse Routing Header and its application to Mobile Networks Feb. 04 http://www.ietf.org/internet-drafts/draft-thubert-nemo-reverse-routing-header-04.txt # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Related Documents Useful for Today's Meeting # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Goals and Benefits of Multihoming http://www.ietf.org/internet-drafts/draft-multihoming-generic-goals-and-benefits-00.txt IPv6 addressing in a heterogeneous MANET-network http://www.ietf.org/internet-drafts/draft-paakkonen-addressing-htr-manet-00.txt # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Older Draft Submitted to the NEMO WG (expired) # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - draft-thubert-nemo-ipv4-traversal-01.txt (expired) IPv4 traversal for MIPv6 based Mobile Routers May 03 - http://www.ietf.org/internet-drafts/draft-perera-nemo-extended-00.txt Extended Network Mobility Support (expired) - draft-hkang-nemo-ro-tlmr-00.txt (expired) Route Optimization for Mobile Network by Using Bi-directional Between Home Agent and Top Level Mobile Router June 03 # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # WG Milestones # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ o Former milestones as currently shown on the web: 1. Mar 03 Submit terminology and requirements documents (for Basic support). 2. May 03 Submit Threat analysis and security requirements for NEMO. 3. Aug 03 Submit solution for basic support to IESG. 4. Nov 03 Submit MIB for Basic support to the IESG. 5. Mar 04 Submit the analysis of the solution space for route optimization. 6. Jun 04 Shut down or recharter the WG to solve the route optimization. o New milestones as the web page should show very soon: 1. DONE Submit WG draft -00 on Terminology and Requirements (for Basic Support) 3. DONE Submit NEMO Basic Support to IESG 2. Mar 04 Submit WG draft -00 on Threat Analysis and Security Requirements for NEMO. 7. Mar 04 Submit WG draft -00 on Multihoming Problem Statement 8. Mar 04 Submit WG draft -00 on NEMO Basic Support Usages 9. Apr 04 Submit Terminology as Informational to IETG 10 Apr 04 Submit Goals and Requirements as Informational to IESG 11 Apr 04 Submit WG draft -00 on Prefix Delegation for NEMO 4. May 04 Submit WG draft -00 on MIB for NEMO Basic Support 5. Jun 04 Submit WG draft -00 on Analysis of the Solution Space for Route Optimization 6. Aug 04 Shut down or recharter the WG to solve route optimization From nemo-admin@ietf.org Wed Feb 25 00:38:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28482 for ; Wed, 25 Feb 2004 00:38:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvrkA-0004Jw-47; Wed, 25 Feb 2004 00:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avrjc-0004BF-1r for nemo@optimus.ietf.org; Wed, 25 Feb 2004 00:37:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28431 for ; Wed, 25 Feb 2004 00:37:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvrjZ-0005lg-00 for nemo@ietf.org; Wed, 25 Feb 2004 00:37:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avrie-0005gY-00 for nemo@ietf.org; Wed, 25 Feb 2004 00:36:28 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1Avrhk-0005YG-00 for nemo@ietf.org; Wed, 25 Feb 2004 00:35:32 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 6E92E5D09A; Wed, 25 Feb 2004 14:35:02 +0900 (JST) Date: Wed, 25 Feb 2004 14:34:39 +0900 From: Thierry Ernst To: Mattias Pettersson Cc: cwng@psl.com.sg, eun@mmlab.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] merged multihoming draft Message-Id: <20040225143439.29254724.ernst@sfc.wide.ad.jp> In-Reply-To: <403B4083.5080501@ericsson.com> References: <20040223004618.A48134@mmlab.snu.ac.kr> <1077504292.5628.45.camel@localhost> <20040223153820.10f6a14c.ernst@sfc.wide.ad.jp> <403B4083.5080501@ericsson.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 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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 Mattias, Mattias Pettersson wrote: > IMO this I-D should be made a WG doc. With the content as is ? > I have a comment on chapter 5: > > > o (N,1,N) Mobile Network > > > > The (N,1,N) mobile network has multiple active egress mobile > > routers registering to the same home-agent, and advertising > > multiple prefixes. If a mobile router is advertising more than one > > prefix, we have the same problem as (1,1,N) as in how to register > > more than one NEMO-prefix to the same home-agent. > > > > On the other hand, if each mobile router take cares of a separate > > (and only one) NEMO-prefix, then there should not be any > > NEMO-specific problem. > > As I remember Erik once said to me in an earlier NEMO discussion: we > don't want to go down the second alternative. MRs should not advertise > different prefixes to the same link - they must advertise the same > prefix set (or otherwise be coordinated and able to route traffic on > behalf of each other). For an MNN, each MR is a just default router and > all default routers must be able to route all traffic. We don't want to > put such requirements on the MNNs to map each prefix to a specific exit > router and remembering to use the correct source address when sending to > a specific default router. > > Such a general host behaviour may be required for multihoming to work in > IPv6 some day, but we have not reached that point yet. IMHO, it depends on what scenarios we consider useful or not (this is unfortunately still an open question). Then, based on the conclusion of what scenerios are useful, we may prioritize the work if one particular scenario is cumbersome to handle. But I wouldn't decide not to allow a scenario just based on the fact it may be difficult to handle. The question is "will people want such kind of configuration". My personal opinion is that they would, and as such we shouldn't disallow it. Thierry. From exim@www1.ietf.org Wed Feb 25 00:40:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28524 for ; Wed, 25 Feb 2004 00:40:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avrlc-0004YJ-T5 for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 00:39:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P5dWi7017495 for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 00:39:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avrlc-0004Y6-LY for nemo-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 00:39:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28518 for ; Wed, 25 Feb 2004 00:39:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avrla-0005vs-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 00:39:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avrke-0005rx-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 00:38:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvrkD-0005nc-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 00:38:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvrkA-0004Jw-47; Wed, 25 Feb 2004 00:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avrjc-0004BF-1r for nemo@optimus.ietf.org; Wed, 25 Feb 2004 00:37:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28431 for ; Wed, 25 Feb 2004 00:37:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvrjZ-0005lg-00 for nemo@ietf.org; Wed, 25 Feb 2004 00:37:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avrie-0005gY-00 for nemo@ietf.org; Wed, 25 Feb 2004 00:36:28 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1Avrhk-0005YG-00 for nemo@ietf.org; Wed, 25 Feb 2004 00:35:32 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 6E92E5D09A; Wed, 25 Feb 2004 14:35:02 +0900 (JST) Date: Wed, 25 Feb 2004 14:34:39 +0900 From: Thierry Ernst To: Mattias Pettersson Cc: cwng@psl.com.sg, eun@mmlab.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] merged multihoming draft Message-Id: <20040225143439.29254724.ernst@sfc.wide.ad.jp> In-Reply-To: <403B4083.5080501@ericsson.com> References: <20040223004618.A48134@mmlab.snu.ac.kr> <1077504292.5628.45.camel@localhost> <20040223153820.10f6a14c.ernst@sfc.wide.ad.jp> <403B4083.5080501@ericsson.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Mattias, Mattias Pettersson wrote: > IMO this I-D should be made a WG doc. With the content as is ? > I have a comment on chapter 5: > > > o (N,1,N) Mobile Network > > > > The (N,1,N) mobile network has multiple active egress mobile > > routers registering to the same home-agent, and advertising > > multiple prefixes. If a mobile router is advertising more than one > > prefix, we have the same problem as (1,1,N) as in how to register > > more than one NEMO-prefix to the same home-agent. > > > > On the other hand, if each mobile router take cares of a separate > > (and only one) NEMO-prefix, then there should not be any > > NEMO-specific problem. > > As I remember Erik once said to me in an earlier NEMO discussion: we > don't want to go down the second alternative. MRs should not advertise > different prefixes to the same link - they must advertise the same > prefix set (or otherwise be coordinated and able to route traffic on > behalf of each other). For an MNN, each MR is a just default router and > all default routers must be able to route all traffic. We don't want to > put such requirements on the MNNs to map each prefix to a specific exit > router and remembering to use the correct source address when sending to > a specific default router. > > Such a general host behaviour may be required for multihoming to work in > IPv6 some day, but we have not reached that point yet. IMHO, it depends on what scenarios we consider useful or not (this is unfortunately still an open question). Then, based on the conclusion of what scenerios are useful, we may prioritize the work if one particular scenario is cumbersome to handle. But I wouldn't decide not to allow a scenario just based on the fact it may be difficult to handle. The question is "will people want such kind of configuration". My personal opinion is that they would, and as such we shouldn't disallow it. Thierry. From nemo-admin@ietf.org Wed Feb 25 01:07:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29581 for ; Wed, 25 Feb 2004 01:07:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvsCD-0005vB-Je; Wed, 25 Feb 2004 01:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvsBm-0005u3-Qs for nemo@optimus.ietf.org; Wed, 25 Feb 2004 01:06:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29529 for ; Wed, 25 Feb 2004 01:06:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvsBj-0000dG-00 for nemo@ietf.org; Wed, 25 Feb 2004 01:06:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvsAq-0000Wy-00 for nemo@ietf.org; Wed, 25 Feb 2004 01:05:37 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AvsA2-0000Ks-00 for nemo@ietf.org; Wed, 25 Feb 2004 01:04:46 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1P5u57p011265 for ; Wed, 25 Feb 2004 13:56:05 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id C0FEFB23984 for ; Wed, 25 Feb 2004 13:58:54 +0800 (SGT) From: Chan-Wah NG To: IETF NEMO WG Content-Type: multipart/mixed; boundary="=-DZSYe6HuLkZrqPjnRRAQ" Organization: Panasonic Singapore Labs Message-Id: <1077688734.6799.59.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 25 Feb 2004 13:58:54 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [nemo] [Fwd: I-D ACTION:draft-thubert-nemo-ro-taxonomy-02.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: , --=-DZSYe6HuLkZrqPjnRRAQ Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello, I didn't realize that Pascal did not forward this to the NEMO ML... or perhaps he did, but I couldn't find it in my own archive. So, there you guys go. Apologize if it is a duplicate. This draft gives an analysis of the possible RO Solution Space in NEMO. It is our intention (well, at least mine) that this draft be considered as a starting point for the RO Solution Space Analysis, which is a milestone in the WG charter. Comments are always welcome. /rgds /cwng -----Forwarded Message----- From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-thubert-nemo-ro-taxonomy-02.txt Date: Tue, 17 Feb 2004 16:37:32 -0500 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Taxonomy of Route Optimization models in the Nemo Context Author(s) : P. Thubert, M. Molteni, C. Ng Filename : draft-thubert-nemo-ro-taxonomy-02.txt Pages : 20 Date : 2004-2-17 Nemo enables Mobile Networks by extending Mobile IP to support Mobile Routers. This paper documents how the MIPv6 concept of Route Optimization can to be adapted for Nemo to optimize: 1) the nested tunnels of the nested Nemo configuration 2) router-to-router within the infrastructure as opposed to end-to- end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-02.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-thubert-nemo-ro-taxonomy-02.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-thubert-nemo-ro-taxonomy-02.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. ________________________________________________________________________ Content-Type: text/plain Content-ID: <2004-2-17165631.I-D@ietf.org> --=-DZSYe6HuLkZrqPjnRRAQ Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-2-17165631.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-thubert-nemo-ro-taxonomy-02.txt --=-DZSYe6HuLkZrqPjnRRAQ Content-Type: Message/External-body; name="draft-thubert-nemo-ro-taxonomy-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-2-17165631.I-D@ietf.org> --=-DZSYe6HuLkZrqPjnRRAQ-- From exim@www1.ietf.org Wed Feb 25 01:09:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29645 for ; Wed, 25 Feb 2004 01:09:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvsDp-0006Up-09 for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 01:08:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P68e57024964 for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 01:08:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvsDl-0006UO-IC for nemo-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 01:08:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29635 for ; Wed, 25 Feb 2004 01:08:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvsDi-0000ps-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 01:08:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvsCq-0000l1-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 01:07:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvsCF-0000fc-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 01:07:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvsCD-0005vB-Je; Wed, 25 Feb 2004 01:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvsBm-0005u3-Qs for nemo@optimus.ietf.org; Wed, 25 Feb 2004 01:06:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29529 for ; Wed, 25 Feb 2004 01:06:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvsBj-0000dG-00 for nemo@ietf.org; Wed, 25 Feb 2004 01:06:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvsAq-0000Wy-00 for nemo@ietf.org; Wed, 25 Feb 2004 01:05:37 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AvsA2-0000Ks-00 for nemo@ietf.org; Wed, 25 Feb 2004 01:04:46 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1P5u57p011265 for ; Wed, 25 Feb 2004 13:56:05 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id C0FEFB23984 for ; Wed, 25 Feb 2004 13:58:54 +0800 (SGT) From: Chan-Wah NG To: IETF NEMO WG Content-Type: multipart/mixed; boundary="=-DZSYe6HuLkZrqPjnRRAQ" Organization: Panasonic Singapore Labs Message-Id: <1077688734.6799.59.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 25 Feb 2004 13:58:54 +0800 Subject: [nemo] [Fwd: I-D ACTION:draft-thubert-nemo-ro-taxonomy-02.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-DZSYe6HuLkZrqPjnRRAQ Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello, I didn't realize that Pascal did not forward this to the NEMO ML... or perhaps he did, but I couldn't find it in my own archive. So, there you guys go. Apologize if it is a duplicate. This draft gives an analysis of the possible RO Solution Space in NEMO. It is our intention (well, at least mine) that this draft be considered as a starting point for the RO Solution Space Analysis, which is a milestone in the WG charter. Comments are always welcome. /rgds /cwng -----Forwarded Message----- From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-thubert-nemo-ro-taxonomy-02.txt Date: Tue, 17 Feb 2004 16:37:32 -0500 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Taxonomy of Route Optimization models in the Nemo Context Author(s) : P. Thubert, M. Molteni, C. Ng Filename : draft-thubert-nemo-ro-taxonomy-02.txt Pages : 20 Date : 2004-2-17 Nemo enables Mobile Networks by extending Mobile IP to support Mobile Routers. This paper documents how the MIPv6 concept of Route Optimization can to be adapted for Nemo to optimize: 1) the nested tunnels of the nested Nemo configuration 2) router-to-router within the infrastructure as opposed to end-to- end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-02.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-thubert-nemo-ro-taxonomy-02.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-thubert-nemo-ro-taxonomy-02.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. ________________________________________________________________________ Content-Type: text/plain Content-ID: <2004-2-17165631.I-D@ietf.org> --=-DZSYe6HuLkZrqPjnRRAQ Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-2-17165631.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-thubert-nemo-ro-taxonomy-02.txt --=-DZSYe6HuLkZrqPjnRRAQ Content-Type: Message/External-body; name="draft-thubert-nemo-ro-taxonomy-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-2-17165631.I-D@ietf.org> --=-DZSYe6HuLkZrqPjnRRAQ-- From nemo-admin@ietf.org Wed Feb 25 01:44:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00806 for ; Wed, 25 Feb 2004 01:44:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avsm1-00012g-6c; Wed, 25 Feb 2004 01:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvslX-00010d-Cr for nemo@optimus.ietf.org; Wed, 25 Feb 2004 01:43:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00781 for ; Wed, 25 Feb 2004 01:43:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvslU-0003vH-00 for nemo@ietf.org; Wed, 25 Feb 2004 01:43:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvskV-0003qq-00 for nemo@ietf.org; Wed, 25 Feb 2004 01:42:28 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1Avsjg-0003j3-00 for nemo@ietf.org; Wed, 25 Feb 2004 01:41:37 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1P6WqNi012430; Wed, 25 Feb 2004 14:32:52 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id B2374B23984; Wed, 25 Feb 2004 14:35:41 +0800 (SGT) Subject: Re: [nemo] merged multihoming draft From: Chan-Wah NG To: Mattias Pettersson Cc: Thierry Ernst , Eun Kyoung Paik , IETF NEMO WG In-Reply-To: <403B4083.5080501@ericsson.com> References: <20040223004618.A48134@mmlab.snu.ac.kr> <1077504292.5628.45.camel@localhost> <20040223153820.10f6a14c.ernst@sfc.wide.ad.jp> <403B4083.5080501@ericsson.com> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1077690940.6796.76.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 25 Feb 2004 14:35:41 +0800 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Hello Mattias On Tue, 2004-02-24 at 20:16, Mattias Pettersson wrote: > IMO this I-D should be made a WG doc. > Thank you for supporting this ;) > I have a comment on chapter 5: > > > o (N,1,N) Mobile Network > > > > The (N,1,N) mobile network has multiple active egress mobile > > routers registering to the same home-agent, and advertising > > multiple prefixes. If a mobile router is advertising more than one > > prefix, we have the same problem as (1,1,N) as in how to register > > more than one NEMO-prefix to the same home-agent. > > > > On the other hand, if each mobile router take cares of a separate > > (and only one) NEMO-prefix, then there should not be any > > NEMO-specific problem. > > As I remember Erik once said to me in an earlier NEMO discussion: we > don't want to go down the second alternative. MRs should not advertise > different prefixes to the same link - they must advertise the same > prefix set (or otherwise be coordinated and able to route traffic on > behalf of each other). For an MNN, each MR is a just default router and > all default routers must be able to route all traffic. We don't want to > put such requirements on the MNNs to map each prefix to a specific exit > router and remembering to use the correct source address when sending to > a specific default router. > Alternatively, the routers can silently re-distribute these packets among themselves, thus shifting the burden of any requirements to the mobile routers instead. > Such a general host behaviour may be required for multihoming to work in > IPv6 some day, but we have not reached that point yet. > I am more towards agreeing with Thierry on this. We would have to determine the requirements based on the benefits it brings. If the benefits is great enough, then we shall strive to solve the problem. /rgds /cwng From exim@www1.ietf.org Wed Feb 25 01:46:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00866 for ; Wed, 25 Feb 2004 01:46:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avsnc-0001IH-B3 for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 01:45:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P6je4n004967 for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 01:45:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avsnc-0001I2-5u for nemo-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 01:45:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00844 for ; Wed, 25 Feb 2004 01:45:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvsnZ-00047b-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 01:45:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avsmc-00042B-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 01:44:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avsm1-0003xE-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 01:44:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avsm1-00012g-6c; Wed, 25 Feb 2004 01:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvslX-00010d-Cr for nemo@optimus.ietf.org; Wed, 25 Feb 2004 01:43:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00781 for ; Wed, 25 Feb 2004 01:43:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvslU-0003vH-00 for nemo@ietf.org; Wed, 25 Feb 2004 01:43:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvskV-0003qq-00 for nemo@ietf.org; Wed, 25 Feb 2004 01:42:28 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1Avsjg-0003j3-00 for nemo@ietf.org; Wed, 25 Feb 2004 01:41:37 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1P6WqNi012430; Wed, 25 Feb 2004 14:32:52 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id B2374B23984; Wed, 25 Feb 2004 14:35:41 +0800 (SGT) Subject: Re: [nemo] merged multihoming draft From: Chan-Wah NG To: Mattias Pettersson Cc: Thierry Ernst , Eun Kyoung Paik , IETF NEMO WG In-Reply-To: <403B4083.5080501@ericsson.com> References: <20040223004618.A48134@mmlab.snu.ac.kr> <1077504292.5628.45.camel@localhost> <20040223153820.10f6a14c.ernst@sfc.wide.ad.jp> <403B4083.5080501@ericsson.com> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1077690940.6796.76.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 25 Feb 2004 14:35:41 +0800 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Mattias On Tue, 2004-02-24 at 20:16, Mattias Pettersson wrote: > IMO this I-D should be made a WG doc. > Thank you for supporting this ;) > I have a comment on chapter 5: > > > o (N,1,N) Mobile Network > > > > The (N,1,N) mobile network has multiple active egress mobile > > routers registering to the same home-agent, and advertising > > multiple prefixes. If a mobile router is advertising more than one > > prefix, we have the same problem as (1,1,N) as in how to register > > more than one NEMO-prefix to the same home-agent. > > > > On the other hand, if each mobile router take cares of a separate > > (and only one) NEMO-prefix, then there should not be any > > NEMO-specific problem. > > As I remember Erik once said to me in an earlier NEMO discussion: we > don't want to go down the second alternative. MRs should not advertise > different prefixes to the same link - they must advertise the same > prefix set (or otherwise be coordinated and able to route traffic on > behalf of each other). For an MNN, each MR is a just default router and > all default routers must be able to route all traffic. We don't want to > put such requirements on the MNNs to map each prefix to a specific exit > router and remembering to use the correct source address when sending to > a specific default router. > Alternatively, the routers can silently re-distribute these packets among themselves, thus shifting the burden of any requirements to the mobile routers instead. > Such a general host behaviour may be required for multihoming to work in > IPv6 some day, but we have not reached that point yet. > I am more towards agreeing with Thierry on this. We would have to determine the requirements based on the benefits it brings. If the benefits is great enough, then we shall strive to solve the problem. /rgds /cwng From nemo-admin@ietf.org Wed Feb 25 04:32:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05988 for ; Wed, 25 Feb 2004 04:32:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvOc-0005Xm-6Z; Wed, 25 Feb 2004 04:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvOD-0005Vh-Jg for nemo@optimus.ietf.org; Wed, 25 Feb 2004 04:31:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05971 for ; Wed, 25 Feb 2004 04:31:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvvOA-0006nA-00 for nemo@ietf.org; Wed, 25 Feb 2004 04:31:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvvNE-0006gp-00 for nemo@ietf.org; Wed, 25 Feb 2004 04:30:37 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AvvML-0006YO-00 for nemo@ietf.org; Wed, 25 Feb 2004 04:29:41 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1P9TgAh018906 for ; Wed, 25 Feb 2004 10:29:42 +0100 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Feb 2004 10:29:39 +0100 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSMBLS36; Wed, 25 Feb 2004 10:29:38 +0100 Message-ID: <403C6A63.50401@ericsson.com> Date: Wed, 25 Feb 2004 10:26:59 +0100 X-Sybari-Trust: 5e9c40ca c77f3eb6 b2f8f052 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst CC: cwng@psl.com.sg, eun@mmlab.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] merged multihoming draft References: <20040223004618.A48134@mmlab.snu.ac.kr> <1077504292.5628.45.camel@localhost> <20040223153820.10f6a14c.ernst@sfc.wide.ad.jp> <403B4083.5080501@ericsson.com> <20040225143439.29254724.ernst@sfc.wide.ad.jp> In-Reply-To: <20040225143439.29254724.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2004 09:29:39.0421 (UTC) FILETIME=[E43000D0:01C3FB81] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: > Hi Mattias, > > Mattias Pettersson wrote: > >>IMO this I-D should be made a WG doc. > > > With the content as is ? Why not? What do others think? We need a doc about MH for NEMO. > > >>I have a comment on chapter 5: >> >> >>> o (N,1,N) Mobile Network >>> >>> The (N,1,N) mobile network has multiple active egress mobile >>> routers registering to the same home-agent, and advertising >>> multiple prefixes. If a mobile router is advertising more than one >>> prefix, we have the same problem as (1,1,N) as in how to register >>> more than one NEMO-prefix to the same home-agent. >>> >>> On the other hand, if each mobile router take cares of a separate >>> (and only one) NEMO-prefix, then there should not be any >>> NEMO-specific problem. >> >>As I remember Erik once said to me in an earlier NEMO discussion: we >>don't want to go down the second alternative. MRs should not advertise >>different prefixes to the same link - they must advertise the same >>prefix set (or otherwise be coordinated and able to route traffic on >>behalf of each other). For an MNN, each MR is a just default router and >>all default routers must be able to route all traffic. We don't want to >>put such requirements on the MNNs to map each prefix to a specific exit >>router and remembering to use the correct source address when sending to >>a specific default router. >> >>Such a general host behaviour may be required for multihoming to work in >>IPv6 some day, but we have not reached that point yet. > > > IMHO, it depends on what scenarios we consider useful or not (this is > unfortunately still an open question). Then, based on the conclusion of > what scenerios are useful, we may prioritize the work if one particular > scenario is cumbersome to handle. But I wouldn't decide not to allow a > scenario just based on the fact it may be difficult to handle. The > question is "will people want such kind of configuration". My personal > opinion is that they would, and as such we shouldn't disallow it. Thierry, Chan-Wah [I answer you both here], It is a question on what entities should carry out the dirty work. Either the MRs or the MNNs. To me it is important that legacy IPv6 hosts can still get connectivity in a moving network without having to implement new proposals such as draft-huitema-multi6-hosts-xx. So what is most important: to support standard IPv6 hosts or to simplify the MR? It seems like in order to simplify the MR we are proposing to introduce a NEMO scenario that was considered "broken" in the IPv6 WG earlier. All routers on a link are equal, from the host's point of view! The ND model builds on that. I agree that we have arguments both in NEMO and in multi6 to question that model, but we do we want to change that model just to allow a variant of a scenario? /Mattias This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From exim@www1.ietf.org Wed Feb 25 04:48:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07122 for ; Wed, 25 Feb 2004 04:48:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avve3-0007Xg-KG for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 04:48:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P9lxrx028985 for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 04:47:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avve1-0007XQ-JB for nemo-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 04:47:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07117 for ; Wed, 25 Feb 2004 04:47:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avvdy-0001Fw-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 04:47:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvvdE-00019s-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 04:47:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvvcW-00011j-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 04:46:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvOc-0005Xm-6Z; Wed, 25 Feb 2004 04:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvOD-0005Vh-Jg for nemo@optimus.ietf.org; Wed, 25 Feb 2004 04:31:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05971 for ; Wed, 25 Feb 2004 04:31:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvvOA-0006nA-00 for nemo@ietf.org; Wed, 25 Feb 2004 04:31:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvvNE-0006gp-00 for nemo@ietf.org; Wed, 25 Feb 2004 04:30:37 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AvvML-0006YO-00 for nemo@ietf.org; Wed, 25 Feb 2004 04:29:41 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1P9TgAh018906 for ; Wed, 25 Feb 2004 10:29:42 +0100 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Feb 2004 10:29:39 +0100 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSMBLS36; Wed, 25 Feb 2004 10:29:38 +0100 Message-ID: <403C6A63.50401@ericsson.com> Date: Wed, 25 Feb 2004 10:26:59 +0100 X-Sybari-Trust: 5e9c40ca c77f3eb6 b2f8f052 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst CC: cwng@psl.com.sg, eun@mmlab.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] merged multihoming draft References: <20040223004618.A48134@mmlab.snu.ac.kr> <1077504292.5628.45.camel@localhost> <20040223153820.10f6a14c.ernst@sfc.wide.ad.jp> <403B4083.5080501@ericsson.com> <20040225143439.29254724.ernst@sfc.wide.ad.jp> In-Reply-To: <20040225143439.29254724.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2004 09:29:39.0421 (UTC) FILETIME=[E43000D0:01C3FB81] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > Hi Mattias, > > Mattias Pettersson wrote: > >>IMO this I-D should be made a WG doc. > > > With the content as is ? Why not? What do others think? We need a doc about MH for NEMO. > > >>I have a comment on chapter 5: >> >> >>> o (N,1,N) Mobile Network >>> >>> The (N,1,N) mobile network has multiple active egress mobile >>> routers registering to the same home-agent, and advertising >>> multiple prefixes. If a mobile router is advertising more than one >>> prefix, we have the same problem as (1,1,N) as in how to register >>> more than one NEMO-prefix to the same home-agent. >>> >>> On the other hand, if each mobile router take cares of a separate >>> (and only one) NEMO-prefix, then there should not be any >>> NEMO-specific problem. >> >>As I remember Erik once said to me in an earlier NEMO discussion: we >>don't want to go down the second alternative. MRs should not advertise >>different prefixes to the same link - they must advertise the same >>prefix set (or otherwise be coordinated and able to route traffic on >>behalf of each other). For an MNN, each MR is a just default router and >>all default routers must be able to route all traffic. We don't want to >>put such requirements on the MNNs to map each prefix to a specific exit >>router and remembering to use the correct source address when sending to >>a specific default router. >> >>Such a general host behaviour may be required for multihoming to work in >>IPv6 some day, but we have not reached that point yet. > > > IMHO, it depends on what scenarios we consider useful or not (this is > unfortunately still an open question). Then, based on the conclusion of > what scenerios are useful, we may prioritize the work if one particular > scenario is cumbersome to handle. But I wouldn't decide not to allow a > scenario just based on the fact it may be difficult to handle. The > question is "will people want such kind of configuration". My personal > opinion is that they would, and as such we shouldn't disallow it. Thierry, Chan-Wah [I answer you both here], It is a question on what entities should carry out the dirty work. Either the MRs or the MNNs. To me it is important that legacy IPv6 hosts can still get connectivity in a moving network without having to implement new proposals such as draft-huitema-multi6-hosts-xx. So what is most important: to support standard IPv6 hosts or to simplify the MR? It seems like in order to simplify the MR we are proposing to introduce a NEMO scenario that was considered "broken" in the IPv6 WG earlier. All routers on a link are equal, from the host's point of view! The ND model builds on that. I agree that we have arguments both in NEMO and in multi6 to question that model, but we do we want to change that model just to allow a variant of a scenario? /Mattias This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From nemo-admin@ietf.org Wed Feb 25 06:51:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11815 for ; Wed, 25 Feb 2004 06:51:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvxZ9-0000JN-BC; Wed, 25 Feb 2004 06:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvxYu-0000IW-2I for nemo@optimus.ietf.org; Wed, 25 Feb 2004 06:50:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11810 for ; Wed, 25 Feb 2004 06:50:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvxYp-0005Jb-00 for nemo@ietf.org; Wed, 25 Feb 2004 06:50:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvxXs-0005Es-00 for nemo@ietf.org; Wed, 25 Feb 2004 06:49:44 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1AvxXY-0005A9-00 for nemo@ietf.org; Wed, 25 Feb 2004 06:49:24 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 706C27D1A; Wed, 25 Feb 2004 12:48:55 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp02.uc3m.es (Postfix) with SMTP id 581A97D57; Wed, 25 Feb 2004 12:48:55 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Mattias Pettersson" , "Thierry Ernst" Cc: , , Subject: RE: [nemo] merged multihoming draft Date: Wed, 25 Feb 2004 12:47:03 +0100 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <403C6A63.50401@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 is a question on what entities should carry out the dirty work. > Either the MRs or the MNNs. Perhaps in the case of multiple prefixes, the dirty work has to be carried by the Home Network Site Exit routers? > > To me it is important that legacy IPv6 hosts can still get connectivity > in a moving network without having to implement new proposals such as > draft-huitema-multi6-hosts-xx. Fully agree with the first statement. But Host centric (draft-huitema-multi6-hosts) approach allows exactly this for multihomed network. That is, that a regular IPv6 host is connected to the multihomed network and still works properly. Clearly, there some benefits, like preserving established communications through outages, that it will not be able to obtain, but at least it will work fine and its operation won't be disturbed because of multihoming. > > So what is most important: to support standard IPv6 hosts or to simplify > the MR? I fully agree that standard IPv6 have to keep on working properly. Perhaps they won't obtain all the multihoming benefits, though > It seems like in order to simplify the MR we are proposing to > introduce a NEMO scenario that was considered "broken" in the IPv6 WG > earlier. All routers on a link are equal, from the host's point of view! Well, again this IMHO is generic to multihoming and not specific to nemo. I guess that if a hosts has to be updated to obtain full multihoming benefits in a fixed network, it would be reasonable that it also has to be updated in order to obtain multihoming benefits in nemo. Regards, marcelo > The ND model builds on that. I agree that we have arguments both in NEMO > and in multi6 to question that model, but we do we want to change that > model just to allow a variant of a scenario? > > /Mattias > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you believe this message has been > sent to you in error, please notify the sender by replying to > this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and > we only send and receive e-mails on the basis that we are not > liable for any such corruption, interception, amendment, > tampering or viruses or any consequences thereof. > > From exim@www1.ietf.org Wed Feb 25 06:53:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11882 for ; Wed, 25 Feb 2004 06:53:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avxal-0000V3-3L for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 06:52:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PBqhZP001917 for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 06:52:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avxak-0000Uq-SK for nemo-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 06:52:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11866 for ; Wed, 25 Feb 2004 06:52:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avxag-0005T6-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 06:52:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvxZn-0005OY-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 06:51:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvxZ9-0005K9-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 06:51:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvxZ9-0000JN-BC; Wed, 25 Feb 2004 06:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvxYu-0000IW-2I for nemo@optimus.ietf.org; Wed, 25 Feb 2004 06:50:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11810 for ; Wed, 25 Feb 2004 06:50:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvxYp-0005Jb-00 for nemo@ietf.org; Wed, 25 Feb 2004 06:50:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvxXs-0005Es-00 for nemo@ietf.org; Wed, 25 Feb 2004 06:49:44 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1AvxXY-0005A9-00 for nemo@ietf.org; Wed, 25 Feb 2004 06:49:24 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 706C27D1A; Wed, 25 Feb 2004 12:48:55 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp02.uc3m.es (Postfix) with SMTP id 581A97D57; Wed, 25 Feb 2004 12:48:55 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Mattias Pettersson" , "Thierry Ernst" Cc: , , Subject: RE: [nemo] merged multihoming draft Date: Wed, 25 Feb 2004 12:47:03 +0100 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <403C6A63.50401@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > It is a question on what entities should carry out the dirty work. > Either the MRs or the MNNs. Perhaps in the case of multiple prefixes, the dirty work has to be carried by the Home Network Site Exit routers? > > To me it is important that legacy IPv6 hosts can still get connectivity > in a moving network without having to implement new proposals such as > draft-huitema-multi6-hosts-xx. Fully agree with the first statement. But Host centric (draft-huitema-multi6-hosts) approach allows exactly this for multihomed network. That is, that a regular IPv6 host is connected to the multihomed network and still works properly. Clearly, there some benefits, like preserving established communications through outages, that it will not be able to obtain, but at least it will work fine and its operation won't be disturbed because of multihoming. > > So what is most important: to support standard IPv6 hosts or to simplify > the MR? I fully agree that standard IPv6 have to keep on working properly. Perhaps they won't obtain all the multihoming benefits, though > It seems like in order to simplify the MR we are proposing to > introduce a NEMO scenario that was considered "broken" in the IPv6 WG > earlier. All routers on a link are equal, from the host's point of view! Well, again this IMHO is generic to multihoming and not specific to nemo. I guess that if a hosts has to be updated to obtain full multihoming benefits in a fixed network, it would be reasonable that it also has to be updated in order to obtain multihoming benefits in nemo. Regards, marcelo > The ND model builds on that. I agree that we have arguments both in NEMO > and in multi6 to question that model, but we do we want to change that > model just to allow a variant of a scenario? > > /Mattias > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you believe this message has been > sent to you in error, please notify the sender by replying to > this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and > we only send and receive e-mails on the basis that we are not > liable for any such corruption, interception, amendment, > tampering or viruses or any consequences thereof. > > From exim@www1.ietf.org Wed Feb 25 06:53:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11883 for ; Wed, 25 Feb 2004 06:53:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avxal-0000VL-Jw for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 06:52:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PBqh3g001933 for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 06:52:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avxal-0000V6-EM for nemo-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 06:52:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11870 for ; Wed, 25 Feb 2004 06:52:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avxah-0005TB-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 06:52:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvxZo-0005Og-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 06:51:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvxZ9-0005KA-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 06:51:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvxZ8-0000JF-O1; Wed, 25 Feb 2004 06:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvxYs-0000IR-Qw for nemo@optimus.ietf.org; Wed, 25 Feb 2004 06:50:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11807 for ; Wed, 25 Feb 2004 06:50:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvxYo-0005JO-00 for nemo@ietf.org; Wed, 25 Feb 2004 06:50:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvxXr-0005Eh-00 for nemo@ietf.org; Wed, 25 Feb 2004 06:49:44 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1AvxXY-0005A8-00 for nemo@ietf.org; Wed, 25 Feb 2004 06:49:24 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 495307D56; Wed, 25 Feb 2004 12:48:55 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp02.uc3m.es (Postfix) with SMTP id 3225D7D1A; Wed, 25 Feb 2004 12:48:55 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Mattias Pettersson" , "Thierry Ernst" Cc: "Chan-Wah NG" , , Subject: RE: [nemo] merged multihoming draft Date: Wed, 25 Feb 2004 12:47:03 +0100 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <403B4083.5080501@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Mattias, > As I remember Erik once said to me in an earlier NEMO discussion: we > don't want to go down the second alternative. MRs should not advertise > different prefixes to the same link - they must advertise the same > prefix set (or otherwise be coordinated and able to route traffic on > behalf of each other). For an MNN, each MR is a just default router and > all default routers must be able to route all traffic. We don't want to > put such requirements on the MNNs to map each prefix to a specific exit > router and remembering to use the correct source address when sending to > a specific default router. Well, i wouldn't say that the MNN have to select the appropriate prefix in order to send to a specific default router, but IMHO it is clear that in order to deal with ingress filtering, the prefix included in the source address will have to match with the selected ISP (if not the packet is discarded) So, IMHO not a specific prefix per default router but a prefix per isp. One possible way to match a prefix with an isp could be to use a different default route, but i don't really think that would be a good option, since it would impose several restrictions on the topology, but this is still on discussion i guess. So, i agree that a different prefix per default router doesn't seems appealing for now at least, but something that allows to match a prefix with an exit isp is required. I have an additional question about this draft: Why do you consider that a mobile network that has several prefixes is multihomed. I mean, i would say that a natural case for this is that the Home network is multihomed, but not really the Mobile Network. In this case, i guess that there is nothing NEMO specific, only that general multi6 solutions have to be supported. Am i missing something? ( i haven't been around for long, so i have missed previous discussions on this topic) Regards, marcelo > > Such a general host behaviour may be required for multihoming to work in > IPv6 some day, but we have not reached that point yet. > > /Mattias > > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you believe this message has been > sent to you in error, please notify the sender by replying to > this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and > we only send and receive e-mails on the basis that we are not > liable for any such corruption, interception, amendment, > tampering or viruses or any consequences thereof. > > From nemo-admin@ietf.org Wed Feb 25 07:39:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11816 for ; Wed, 25 Feb 2004 06:51:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvxZ8-0000JF-O1; Wed, 25 Feb 2004 06:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvxYs-0000IR-Qw for nemo@optimus.ietf.org; Wed, 25 Feb 2004 06:50:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11807 for ; Wed, 25 Feb 2004 06:50:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvxYo-0005JO-00 for nemo@ietf.org; Wed, 25 Feb 2004 06:50:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvxXr-0005Eh-00 for nemo@ietf.org; Wed, 25 Feb 2004 06:49:44 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx with esmtp (Exim 4.12) id 1AvxXY-0005A8-00 for nemo@ietf.org; Wed, 25 Feb 2004 06:49:24 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 495307D56; Wed, 25 Feb 2004 12:48:55 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp02.uc3m.es (Postfix) with SMTP id 3225D7D1A; Wed, 25 Feb 2004 12:48:55 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Mattias Pettersson" , "Thierry Ernst" Cc: "Chan-Wah NG" , , Subject: RE: [nemo] merged multihoming draft Date: Wed, 25 Feb 2004 12:47:03 +0100 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <403B4083.5080501@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Mattias, > As I remember Erik once said to me in an earlier NEMO discussion: we > don't want to go down the second alternative. MRs should not advertise > different prefixes to the same link - they must advertise the same > prefix set (or otherwise be coordinated and able to route traffic on > behalf of each other). For an MNN, each MR is a just default router and > all default routers must be able to route all traffic. We don't want to > put such requirements on the MNNs to map each prefix to a specific exit > router and remembering to use the correct source address when sending to > a specific default router. Well, i wouldn't say that the MNN have to select the appropriate prefix in order to send to a specific default router, but IMHO it is clear that in order to deal with ingress filtering, the prefix included in the source address will have to match with the selected ISP (if not the packet is discarded) So, IMHO not a specific prefix per default router but a prefix per isp. One possible way to match a prefix with an isp could be to use a different default route, but i don't really think that would be a good option, since it would impose several restrictions on the topology, but this is still on discussion i guess. So, i agree that a different prefix per default router doesn't seems appealing for now at least, but something that allows to match a prefix with an exit isp is required. I have an additional question about this draft: Why do you consider that a mobile network that has several prefixes is multihomed. I mean, i would say that a natural case for this is that the Home network is multihomed, but not really the Mobile Network. In this case, i guess that there is nothing NEMO specific, only that general multi6 solutions have to be supported. Am i missing something? ( i haven't been around for long, so i have missed previous discussions on this topic) Regards, marcelo > > Such a general host behaviour may be required for multihoming to work in > IPv6 some day, but we have not reached that point yet. > > /Mattias > > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you believe this message has been > sent to you in error, please notify the sender by replying to > this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and > we only send and receive e-mails on the basis that we are not > liable for any such corruption, interception, amendment, > tampering or viruses or any consequences thereof. > > From nemo-admin@ietf.org Wed Feb 25 09:48:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18650 for ; Wed, 25 Feb 2004 09:48:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0KP-0007cA-5f; Wed, 25 Feb 2004 09:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0KD-0007a9-Lj for nemo@optimus.ietf.org; Wed, 25 Feb 2004 09:47:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18641 for ; Wed, 25 Feb 2004 09:47:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0KB-00079T-00 for nemo@ietf.org; Wed, 25 Feb 2004 09:47:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw0JH-00075P-00 for nemo@ietf.org; Wed, 25 Feb 2004 09:46:52 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0Ig-000717-00 for nemo@ietf.org; Wed, 25 Feb 2004 09:46:14 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1PEkCqY003209 for ; Wed, 25 Feb 2004 15:46:13 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Feb 2004 15:46:12 +0100 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSLDNH6W; Wed, 25 Feb 2004 15:46:12 +0100 Message-ID: <403CB495.1060005@ericsson.com> Date: Wed, 25 Feb 2004 15:43:33 +0100 X-Sybari-Trust: fafb2135 c77f3eb6 0a449737 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: Thierry Ernst , cwng@psl.com.sg, eun@mmlab.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] merged multihoming draft References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2004 14:46:12.0925 (UTC) FILETIME=[1D32B6D0:01C3FBAE] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Marcelo, marcelo bagnulo wrote: > >>It is a question on what entities should carry out the dirty work. >>Either the MRs or the MNNs. > > > Perhaps in the case of multiple prefixes, the dirty work has to be carried > by the Home Network Site Exit routers? Oh yes. I was thinking of scenario N,N,N where all MRs are very independent. > > >>To me it is important that legacy IPv6 hosts can still get connectivity >>in a moving network without having to implement new proposals such as >>draft-huitema-multi6-hosts-xx. > > > Fully agree with the first statement. > But Host centric (draft-huitema-multi6-hosts) approach allows exactly this > for multihomed network. > > That is, that a regular IPv6 host is connected to the multihomed network and > still works properly. > Clearly, there some benefits, like preserving established communications > through outages, that it will not be able to obtain, but at least it will > work fine and its operation won't be disturbed because of multihoming. > Yes, that is a requirement. But the NEMO-MH here tries to take the requirements a step further than what multi6 does. If the MNN sends its traffic to the wrong default router/MR it will be dropped due to ingress filtering policies when checking the source address. At least draft-huitema-multi6-hosts doesn't require legacy IPv6 hosts to have to send to the correct default router, because the sites are often arranged so that the hosts are not on the same link as the site exit routers. An intermediate router can inspect the source address and send it off to the right site exit router. If there is no intermediate router, then at least the site exit routers cooperate. And this is not even a matter of multihoming to survive outages. The MNN won't be able to communicate unless it by luck selects the correct source address for the DR it has chosen. > >>So what is most important: to support standard IPv6 hosts or to simplify >>the MR? > > > I fully agree that standard IPv6 have to keep on working properly. > Perhaps they won't obtain all the multihoming benefits, though > > >>It seems like in order to simplify the MR we are proposing to >>introduce a NEMO scenario that was considered "broken" in the IPv6 WG >>earlier. All routers on a link are equal, from the host's point of view! > > > Well, again this IMHO is generic to multihoming and not specific to nemo. > I guess that if a hosts has to be updated to obtain full multihoming > benefits in a fixed network, it would be reasonable that it also has to be > updated in order to obtain multihoming benefits in nemo. > As far as I know nobody will build a fixed network that is broken, meaning that router R1 advertises P1 only and R2 advertises P2 only and they only forward traffic using the respectively derived addresses. But this seems to me what we're suggesting for NEMO to do. And I don't support that idea. IMHO this NEMO scenario breaks the ND model and general MH approaches don't do that. /Mattias > Regards, marcelo > > >>The ND model builds on that. I agree that we have arguments both in NEMO >>and in multi6 to question that model, but we do we want to change that >>model just to allow a variant of a scenario? >> >>/Mattias >> > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From exim@www1.ietf.org Wed Feb 25 09:50:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18709 for ; Wed, 25 Feb 2004 09:50:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0MH-0007iG-2c for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 09:49:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PEnvHw029642 for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 09:49:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0MG-0007i1-Ry for nemo-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 09:49:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18696 for ; Wed, 25 Feb 2004 09:49:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0MF-0007Je-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 09:49:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw0LC-0007Ee-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 09:48:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0KU-0007AA-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 09:48:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0KP-0007cA-5f; Wed, 25 Feb 2004 09:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0KD-0007a9-Lj for nemo@optimus.ietf.org; Wed, 25 Feb 2004 09:47:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18641 for ; Wed, 25 Feb 2004 09:47:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0KB-00079T-00 for nemo@ietf.org; Wed, 25 Feb 2004 09:47:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw0JH-00075P-00 for nemo@ietf.org; Wed, 25 Feb 2004 09:46:52 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0Ig-000717-00 for nemo@ietf.org; Wed, 25 Feb 2004 09:46:14 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1PEkCqY003209 for ; Wed, 25 Feb 2004 15:46:13 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Feb 2004 15:46:12 +0100 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSLDNH6W; Wed, 25 Feb 2004 15:46:12 +0100 Message-ID: <403CB495.1060005@ericsson.com> Date: Wed, 25 Feb 2004 15:43:33 +0100 X-Sybari-Trust: fafb2135 c77f3eb6 0a449737 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: Thierry Ernst , cwng@psl.com.sg, eun@mmlab.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] merged multihoming draft References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2004 14:46:12.0925 (UTC) FILETIME=[1D32B6D0:01C3FBAE] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Marcelo, marcelo bagnulo wrote: > >>It is a question on what entities should carry out the dirty work. >>Either the MRs or the MNNs. > > > Perhaps in the case of multiple prefixes, the dirty work has to be carried > by the Home Network Site Exit routers? Oh yes. I was thinking of scenario N,N,N where all MRs are very independent. > > >>To me it is important that legacy IPv6 hosts can still get connectivity >>in a moving network without having to implement new proposals such as >>draft-huitema-multi6-hosts-xx. > > > Fully agree with the first statement. > But Host centric (draft-huitema-multi6-hosts) approach allows exactly this > for multihomed network. > > That is, that a regular IPv6 host is connected to the multihomed network and > still works properly. > Clearly, there some benefits, like preserving established communications > through outages, that it will not be able to obtain, but at least it will > work fine and its operation won't be disturbed because of multihoming. > Yes, that is a requirement. But the NEMO-MH here tries to take the requirements a step further than what multi6 does. If the MNN sends its traffic to the wrong default router/MR it will be dropped due to ingress filtering policies when checking the source address. At least draft-huitema-multi6-hosts doesn't require legacy IPv6 hosts to have to send to the correct default router, because the sites are often arranged so that the hosts are not on the same link as the site exit routers. An intermediate router can inspect the source address and send it off to the right site exit router. If there is no intermediate router, then at least the site exit routers cooperate. And this is not even a matter of multihoming to survive outages. The MNN won't be able to communicate unless it by luck selects the correct source address for the DR it has chosen. > >>So what is most important: to support standard IPv6 hosts or to simplify >>the MR? > > > I fully agree that standard IPv6 have to keep on working properly. > Perhaps they won't obtain all the multihoming benefits, though > > >>It seems like in order to simplify the MR we are proposing to >>introduce a NEMO scenario that was considered "broken" in the IPv6 WG >>earlier. All routers on a link are equal, from the host's point of view! > > > Well, again this IMHO is generic to multihoming and not specific to nemo. > I guess that if a hosts has to be updated to obtain full multihoming > benefits in a fixed network, it would be reasonable that it also has to be > updated in order to obtain multihoming benefits in nemo. > As far as I know nobody will build a fixed network that is broken, meaning that router R1 advertises P1 only and R2 advertises P2 only and they only forward traffic using the respectively derived addresses. But this seems to me what we're suggesting for NEMO to do. And I don't support that idea. IMHO this NEMO scenario breaks the ND model and general MH approaches don't do that. /Mattias > Regards, marcelo > > >>The ND model builds on that. I agree that we have arguments both in NEMO >>and in multi6 to question that model, but we do we want to change that >>model just to allow a variant of a scenario? >> >>/Mattias >> > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From nemo-admin@ietf.org Wed Feb 25 10:37:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22329 for ; Wed, 25 Feb 2004 10:37:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw15o-0001yg-Ef; Wed, 25 Feb 2004 10:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw14t-0001pI-Ak for nemo@optimus.ietf.org; Wed, 25 Feb 2004 10:36:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22260 for ; Wed, 25 Feb 2004 10:35:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw14q-0004XY-00 for nemo@ietf.org; Wed, 25 Feb 2004 10:36:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw13w-0004Rn-00 for nemo@ietf.org; Wed, 25 Feb 2004 10:35:05 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1Aw13b-0004Le-00 for nemo@ietf.org; Wed, 25 Feb 2004 10:34:43 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1PFYgAh006960 for ; Wed, 25 Feb 2004 16:34:43 +0100 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Feb 2004 16:34:41 +0100 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSLDNWNG; Wed, 25 Feb 2004 16:34:41 +0100 Message-ID: <403CBFF0.8060008@ericsson.com> Date: Wed, 25 Feb 2004 16:32:00 +0100 X-Sybari-Trust: 4ae6fbfb c77f3eb6 0a449737 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah NG CC: IETF NEMO WG Subject: Re: [nemo] [Fwd: I-D ACTION:draft-thubert-nemo-ro-taxonomy-02.txt] References: <1077688734.6799.59.camel@localhost> In-Reply-To: <1077688734.6799.59.camel@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2004 15:34:41.0384 (UTC) FILETIME=[E2C65680:01C3FBB4] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Chan-Wah NG wrote: > Hello, > > I didn't realize that Pascal did not forward this to the NEMO ML... or > perhaps he did, but I couldn't find it in my own archive. So, there you > guys go. Apologize if it is a duplicate. > > This draft gives an analysis of the possible RO Solution Space in NEMO. > It is our intention (well, at least mine) that this draft be considered > as a starting point for the RO Solution Space Analysis, which is a > milestone in the WG charter. > > Comments are always welcome. > Short comment: chapter 1-5 and 7 are very good and they reflect what we now know and I agree on them. But chapter 6 is difficult to grasp and I would prefer it to be more elaborate. Simply more text and an easier level. Chapter 7 doesn't summarise anything from chapter 6, shouldn't it? /Mattias This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From exim@www1.ietf.org Wed Feb 25 10:39:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22614 for ; Wed, 25 Feb 2004 10:39:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw17u-0002QI-Bx for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 10:39:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PFdAPX009308 for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 10:39:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw17u-0002Q3-5P for nemo-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 10:39:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22529 for ; Wed, 25 Feb 2004 10:39:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw17r-00054O-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 10:39:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw16n-0004rd-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 10:38:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw15q-0004fv-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 10:37:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw15o-0001yg-Ef; Wed, 25 Feb 2004 10:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw14t-0001pI-Ak for nemo@optimus.ietf.org; Wed, 25 Feb 2004 10:36:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22260 for ; Wed, 25 Feb 2004 10:35:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw14q-0004XY-00 for nemo@ietf.org; Wed, 25 Feb 2004 10:36:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw13w-0004Rn-00 for nemo@ietf.org; Wed, 25 Feb 2004 10:35:05 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1Aw13b-0004Le-00 for nemo@ietf.org; Wed, 25 Feb 2004 10:34:43 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1PFYgAh006960 for ; Wed, 25 Feb 2004 16:34:43 +0100 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Feb 2004 16:34:41 +0100 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSLDNWNG; Wed, 25 Feb 2004 16:34:41 +0100 Message-ID: <403CBFF0.8060008@ericsson.com> Date: Wed, 25 Feb 2004 16:32:00 +0100 X-Sybari-Trust: 4ae6fbfb c77f3eb6 0a449737 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah NG CC: IETF NEMO WG Subject: Re: [nemo] [Fwd: I-D ACTION:draft-thubert-nemo-ro-taxonomy-02.txt] References: <1077688734.6799.59.camel@localhost> In-Reply-To: <1077688734.6799.59.camel@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2004 15:34:41.0384 (UTC) FILETIME=[E2C65680:01C3FBB4] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chan-Wah NG wrote: > Hello, > > I didn't realize that Pascal did not forward this to the NEMO ML... or > perhaps he did, but I couldn't find it in my own archive. So, there you > guys go. Apologize if it is a duplicate. > > This draft gives an analysis of the possible RO Solution Space in NEMO. > It is our intention (well, at least mine) that this draft be considered > as a starting point for the RO Solution Space Analysis, which is a > milestone in the WG charter. > > Comments are always welcome. > Short comment: chapter 1-5 and 7 are very good and they reflect what we now know and I agree on them. But chapter 6 is difficult to grasp and I would prefer it to be more elaborate. Simply more text and an easier level. Chapter 7 doesn't summarise anything from chapter 6, shouldn't it? /Mattias This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From nemo-admin@ietf.org Wed Feb 25 14:01:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05349 for ; Wed, 25 Feb 2004 14:01:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4HE-0003BL-4d; Wed, 25 Feb 2004 14:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4GI-00039w-Ua for nemo@optimus.ietf.org; Wed, 25 Feb 2004 14:00:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05289 for ; Wed, 25 Feb 2004 14:00:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4GG-0005PT-00 for nemo@ietf.org; Wed, 25 Feb 2004 14:00:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw4FH-0005Kf-00 for nemo@ietf.org; Wed, 25 Feb 2004 13:59:00 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4Eh-0005Eo-00 for nemo@ietf.org; Wed, 25 Feb 2004 13:58:24 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 38C199E85; Wed, 25 Feb 2004 19:57:53 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id 207C29E0D; Wed, 25 Feb 2004 19:57:53 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Mattias Pettersson" Cc: "Thierry Ernst" , , , Subject: RE: [nemo] merged multihoming draft Date: Wed, 25 Feb 2004 19:56:01 +0100 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <403CB495.1060005@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 > Yes, that is a requirement. But the NEMO-MH here tries to take the > requirements a step further than what multi6 does. If the MNN sends its > traffic to the wrong default router/MR it will be dropped due to ingress > filtering policies when checking the source address. Well, i don't see any need for that. Moreover, i think this imposes important requirements to the topology of the mobile network, I mean, if you associate a prefix to a default router, you basically have to have two different disjoint paths to each one of the prefix, i guess, without any common router. so i guess i agree with you, i don't think that a prefix should be linked to a default router. I would consider to work in the general case, where a default router can handle all the prefixes. > > At least draft-huitema-multi6-hosts doesn't require legacy IPv6 hosts to > have to send to the correct default router, because the sites are often > arranged so that the hosts are not on the same link as the site exit > routers. An intermediate router can inspect the source address and send > it off to the right site exit router. that is one of the options. The other option is that the host itsef knows about which exit router to use. The other option is what you mention next, i.e. cooperation between exit routers. > If there is no intermediate > router, then at least the site exit routers cooperate. > > And this is not even a matter of multihoming to survive outages. The MNN > won't be able to communicate unless it by luck selects the correct > source address for the DR it has chosen. This is also the case in any multihomed network, mobile or fixed, since iwhen there are multiple prefixes available, it has to select the one that matches with the ISP through which the packet will be carried. that is why i was asking why do you think that the multiple prefix case has something NEMO specific. I would say that fixed multihoming solutions should deal with this case, just as any other part of the Home Network, (which is actually the multihomed network in this case, not the mobile network, as far as i can see) > > > > >>So what is most important: to support standard IPv6 hosts or to simplify > >>the MR? > > > > > > I fully agree that standard IPv6 have to keep on working properly. > > Perhaps they won't obtain all the multihoming benefits, though > > > > > >>It seems like in order to simplify the MR we are proposing to > >>introduce a NEMO scenario that was considered "broken" in the IPv6 WG > >>earlier. All routers on a link are equal, from the host's point of view! > > > > > > Well, again this IMHO is generic to multihoming and not > specific to nemo. > > I guess that if a hosts has to be updated to obtain full multihoming > > benefits in a fixed network, it would be reasonable that it > also has to be > > updated in order to obtain multihoming benefits in nemo. > > > > As far as I know nobody will build a fixed network that is broken, > meaning that router R1 advertises P1 only and R2 advertises P2 only and > they only forward traffic using the respectively derived addresses. But > this seems to me what we're suggesting for NEMO to do. And I don't > support that idea. > i agree with your pov (i think) But a similar problems remain in multihomed networks in general which is related to ingress filtering and how to select the apropriate source address when the hosts have multiple addresses. But again, this is not NEMO specific, as far as i can see. regards, marcelo > IMHO this NEMO scenario breaks the ND model and general MH approaches > don't do that. > > /Mattias > > > Regards, marcelo > > > > > >>The ND model builds on that. I agree that we have arguments both in NEMO > >>and in multi6 to question that model, but we do we want to change that > >>model just to allow a variant of a scenario? > >> > >>/Mattias > >> > > > > > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you believe this message has been > sent to you in error, please notify the sender by replying to > this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and > we only send and receive e-mails on the basis that we are not > liable for any such corruption, interception, amendment, > tampering or viruses or any consequences thereof. > > From exim@www1.ietf.org Wed Feb 25 14:03:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05453 for ; Wed, 25 Feb 2004 14:03:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4J5-0003f3-DS for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 14:03:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PJ2tjU014068 for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 14:02:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4J5-0003ep-6d for nemo-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 14:02:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05434 for ; Wed, 25 Feb 2004 14:02:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4J2-0005fw-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 14:02:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw4I7-0005aU-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 14:01:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4HE-0005V1-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 14:01:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4HE-0003BL-4d; Wed, 25 Feb 2004 14:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4GI-00039w-Ua for nemo@optimus.ietf.org; Wed, 25 Feb 2004 14:00:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05289 for ; Wed, 25 Feb 2004 14:00:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4GG-0005PT-00 for nemo@ietf.org; Wed, 25 Feb 2004 14:00:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw4FH-0005Kf-00 for nemo@ietf.org; Wed, 25 Feb 2004 13:59:00 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4Eh-0005Eo-00 for nemo@ietf.org; Wed, 25 Feb 2004 13:58:24 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 38C199E85; Wed, 25 Feb 2004 19:57:53 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id 207C29E0D; Wed, 25 Feb 2004 19:57:53 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Mattias Pettersson" Cc: "Thierry Ernst" , , , Subject: RE: [nemo] merged multihoming draft Date: Wed, 25 Feb 2004 19:56:01 +0100 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <403CB495.1060005@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Yes, that is a requirement. But the NEMO-MH here tries to take the > requirements a step further than what multi6 does. If the MNN sends its > traffic to the wrong default router/MR it will be dropped due to ingress > filtering policies when checking the source address. Well, i don't see any need for that. Moreover, i think this imposes important requirements to the topology of the mobile network, I mean, if you associate a prefix to a default router, you basically have to have two different disjoint paths to each one of the prefix, i guess, without any common router. so i guess i agree with you, i don't think that a prefix should be linked to a default router. I would consider to work in the general case, where a default router can handle all the prefixes. > > At least draft-huitema-multi6-hosts doesn't require legacy IPv6 hosts to > have to send to the correct default router, because the sites are often > arranged so that the hosts are not on the same link as the site exit > routers. An intermediate router can inspect the source address and send > it off to the right site exit router. that is one of the options. The other option is that the host itsef knows about which exit router to use. The other option is what you mention next, i.e. cooperation between exit routers. > If there is no intermediate > router, then at least the site exit routers cooperate. > > And this is not even a matter of multihoming to survive outages. The MNN > won't be able to communicate unless it by luck selects the correct > source address for the DR it has chosen. This is also the case in any multihomed network, mobile or fixed, since iwhen there are multiple prefixes available, it has to select the one that matches with the ISP through which the packet will be carried. that is why i was asking why do you think that the multiple prefix case has something NEMO specific. I would say that fixed multihoming solutions should deal with this case, just as any other part of the Home Network, (which is actually the multihomed network in this case, not the mobile network, as far as i can see) > > > > >>So what is most important: to support standard IPv6 hosts or to simplify > >>the MR? > > > > > > I fully agree that standard IPv6 have to keep on working properly. > > Perhaps they won't obtain all the multihoming benefits, though > > > > > >>It seems like in order to simplify the MR we are proposing to > >>introduce a NEMO scenario that was considered "broken" in the IPv6 WG > >>earlier. All routers on a link are equal, from the host's point of view! > > > > > > Well, again this IMHO is generic to multihoming and not > specific to nemo. > > I guess that if a hosts has to be updated to obtain full multihoming > > benefits in a fixed network, it would be reasonable that it > also has to be > > updated in order to obtain multihoming benefits in nemo. > > > > As far as I know nobody will build a fixed network that is broken, > meaning that router R1 advertises P1 only and R2 advertises P2 only and > they only forward traffic using the respectively derived addresses. But > this seems to me what we're suggesting for NEMO to do. And I don't > support that idea. > i agree with your pov (i think) But a similar problems remain in multihomed networks in general which is related to ingress filtering and how to select the apropriate source address when the hosts have multiple addresses. But again, this is not NEMO specific, as far as i can see. regards, marcelo > IMHO this NEMO scenario breaks the ND model and general MH approaches > don't do that. > > /Mattias > > > Regards, marcelo > > > > > >>The ND model builds on that. I agree that we have arguments both in NEMO > >>and in multi6 to question that model, but we do we want to change that > >>model just to allow a variant of a scenario? > >> > >>/Mattias > >> > > > > > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you believe this message has been > sent to you in error, please notify the sender by replying to > this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and > we only send and receive e-mails on the basis that we are not > liable for any such corruption, interception, amendment, > tampering or viruses or any consequences thereof. > > From nemo-admin@ietf.org Wed Feb 25 21:56:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01340 for ; Wed, 25 Feb 2004 21:56:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwBgv-0005wV-61; Wed, 25 Feb 2004 21:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwBgA-0005ve-3R for nemo@optimus.ietf.org; Wed, 25 Feb 2004 21:55:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01325 for ; Wed, 25 Feb 2004 21:55:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwBg7-0000Wf-00 for nemo@ietf.org; Wed, 25 Feb 2004 21:55:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwBfK-0000Sk-00 for nemo@ietf.org; Wed, 25 Feb 2004 21:54:23 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AwBej-0000It-00 for nemo@ietf.org; Wed, 25 Feb 2004 21:53:46 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1Q2ipb6029938; Thu, 26 Feb 2004 10:44:51 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 86E75B23984; Thu, 26 Feb 2004 10:47:39 +0800 (SGT) Subject: RE: [nemo] merged multihoming draft From: Chan-Wah NG To: mbagnulo@ing.uc3m.es Cc: Mattias Pettersson , Thierry Ernst , Eun Kyoung Paik , IETF NEMO WG In-Reply-To: References: Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1077763658.5418.23.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 26 Feb 2004 10:47:38 +0800 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Hello Marcelo, On Wed, 2004-02-25 at 19:47, marcelo bagnulo wrote: > Hi Mattias, > > > > As I remember Erik once said to me in an earlier NEMO discussion: we > > don't want to go down the second alternative. MRs should not advertise > > different prefixes to the same link - they must advertise the same > > prefix set (or otherwise be coordinated and able to route traffic on > > behalf of each other). For an MNN, each MR is a just default router and > > all default routers must be able to route all traffic. We don't want to > > put such requirements on the MNNs to map each prefix to a specific exit > > router and remembering to use the correct source address when sending to > > a specific default router. > > Well, i wouldn't say that the MNN have to select the appropriate prefix in > order to send to a specific default router, but IMHO it is clear that in > order to deal with ingress filtering, the prefix included in the source > address will have to match with the selected ISP (if not the packet is > discarded) > So, IMHO not a specific prefix per default router but a prefix per isp. > > One possible way to match a prefix with an isp could be to use a different > default route, but i don't really think that would be a good option, since > it would impose several restrictions on the topology, but this is still on > discussion i guess. > > So, i agree that a different prefix per default router doesn't seems > appealing for now at least, but something that allows to match a prefix with > an exit isp is required. > > I have an additional question about this draft: > > Why do you consider that a mobile network that has several prefixes is > multihomed. In this case, it is not the mobile network that is multihomed, but the MNN is multihomed. And MR shouldn't prevent it (as per draft-ietf-nemo-requirements) > I mean, i would say that a natural case for this is that the Home network is > multihomed, but not really the Mobile Network. > In this case, i guess that there is nothing NEMO specific, only that general > multi6 solutions have to be supported. > In a fixed network, as you or Mattias mentioned in an earlier post, no administrator would be crazy enough to build a network, configured it with multiple prefixes but have each router handles only one prefix and discards packets with source addresses from the other prefixes. In NEMO, this scenario becomes possible. Consider two NEMOs coming together, or a NEMO with two MRs, each subscribing to services from different ISPs. It may not be NEMO-specific, depending on your interpretation of "NEMO-specific". But IMHO its clear that NEMO make the problem more "real". The draft's objective to raise the readers' awareness to this kind of problems. Having done that, if the WG feels that it is worthwhile to solve it here, we then discuss how to solve it. If the WG feels that this is better left until a candidate solution emerged from multi6, we mention this is the document, and points interested implementors to consider the solutions coming out of the multi6 group. Does this make sense? /rgds /cwng From exim@www1.ietf.org Wed Feb 25 21:57:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01395 for ; Wed, 25 Feb 2004 21:57:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwBi9-00067O-Ri for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 21:57:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q2vH2R023515 for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 21:57:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwBi9-00067C-Kp for nemo-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 21:57:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01382 for ; Wed, 25 Feb 2004 21:57:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwBi6-0000gZ-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 21:57:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwBhA-0000bz-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 21:56:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwBgw-0000XT-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 21:56:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwBgv-0005wV-61; Wed, 25 Feb 2004 21:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwBgA-0005ve-3R for nemo@optimus.ietf.org; Wed, 25 Feb 2004 21:55:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01325 for ; Wed, 25 Feb 2004 21:55:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwBg7-0000Wf-00 for nemo@ietf.org; Wed, 25 Feb 2004 21:55:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwBfK-0000Sk-00 for nemo@ietf.org; Wed, 25 Feb 2004 21:54:23 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AwBej-0000It-00 for nemo@ietf.org; Wed, 25 Feb 2004 21:53:46 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1Q2ipb6029938; Thu, 26 Feb 2004 10:44:51 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 86E75B23984; Thu, 26 Feb 2004 10:47:39 +0800 (SGT) Subject: RE: [nemo] merged multihoming draft From: Chan-Wah NG To: mbagnulo@ing.uc3m.es Cc: Mattias Pettersson , Thierry Ernst , Eun Kyoung Paik , IETF NEMO WG In-Reply-To: References: Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1077763658.5418.23.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 26 Feb 2004 10:47:38 +0800 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Marcelo, On Wed, 2004-02-25 at 19:47, marcelo bagnulo wrote: > Hi Mattias, > > > > As I remember Erik once said to me in an earlier NEMO discussion: we > > don't want to go down the second alternative. MRs should not advertise > > different prefixes to the same link - they must advertise the same > > prefix set (or otherwise be coordinated and able to route traffic on > > behalf of each other). For an MNN, each MR is a just default router and > > all default routers must be able to route all traffic. We don't want to > > put such requirements on the MNNs to map each prefix to a specific exit > > router and remembering to use the correct source address when sending to > > a specific default router. > > Well, i wouldn't say that the MNN have to select the appropriate prefix in > order to send to a specific default router, but IMHO it is clear that in > order to deal with ingress filtering, the prefix included in the source > address will have to match with the selected ISP (if not the packet is > discarded) > So, IMHO not a specific prefix per default router but a prefix per isp. > > One possible way to match a prefix with an isp could be to use a different > default route, but i don't really think that would be a good option, since > it would impose several restrictions on the topology, but this is still on > discussion i guess. > > So, i agree that a different prefix per default router doesn't seems > appealing for now at least, but something that allows to match a prefix with > an exit isp is required. > > I have an additional question about this draft: > > Why do you consider that a mobile network that has several prefixes is > multihomed. In this case, it is not the mobile network that is multihomed, but the MNN is multihomed. And MR shouldn't prevent it (as per draft-ietf-nemo-requirements) > I mean, i would say that a natural case for this is that the Home network is > multihomed, but not really the Mobile Network. > In this case, i guess that there is nothing NEMO specific, only that general > multi6 solutions have to be supported. > In a fixed network, as you or Mattias mentioned in an earlier post, no administrator would be crazy enough to build a network, configured it with multiple prefixes but have each router handles only one prefix and discards packets with source addresses from the other prefixes. In NEMO, this scenario becomes possible. Consider two NEMOs coming together, or a NEMO with two MRs, each subscribing to services from different ISPs. It may not be NEMO-specific, depending on your interpretation of "NEMO-specific". But IMHO its clear that NEMO make the problem more "real". The draft's objective to raise the readers' awareness to this kind of problems. Having done that, if the WG feels that it is worthwhile to solve it here, we then discuss how to solve it. If the WG feels that this is better left until a candidate solution emerged from multi6, we mention this is the document, and points interested implementors to consider the solutions coming out of the multi6 group. Does this make sense? /rgds /cwng From nemo-admin@ietf.org Wed Feb 25 22:20:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02153 for ; Wed, 25 Feb 2004 22:20:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwC4C-0000L7-2i; Wed, 25 Feb 2004 22:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwC3U-0000GD-05 for nemo@optimus.ietf.org; Wed, 25 Feb 2004 22:19:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02109 for ; Wed, 25 Feb 2004 22:19:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwC3Q-0002bz-00 for nemo@ietf.org; Wed, 25 Feb 2004 22:19:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwC2d-0002WA-00 for nemo@ietf.org; Wed, 25 Feb 2004 22:18:27 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AwC1f-0002K3-00 for nemo@ietf.org; Wed, 25 Feb 2004 22:17:28 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1Q38qvj000948; Thu, 26 Feb 2004 11:08:52 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id BAD25B23984; Thu, 26 Feb 2004 11:11:40 +0800 (SGT) Subject: Re: [nemo] NEMO Agenda From: Chan-Wah NG To: Thierry Ernst Cc: IETF NEMO WG , tj In-Reply-To: <20040224234612.05cc7fe8.ernst@sfc.wide.ad.jp> References: <20040224234612.05cc7fe8.ernst@sfc.wide.ad.jp> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1077765100.5422.30.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 26 Feb 2004 11:11:40 +0800 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Tue, 2004-02-24 at 22:46, Thierry Ernst wrote: > # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > o NEMO Terminology Upates .................................. 10 mins > Thierry Ernst > > To be read: > ~~~~~~~~~~~ > Network Mobility Support Terminology > http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-01.txt > > To be discussed: > ~~~~~~~~~~~~~~~~ > - document should go to last call > - do we keep the multihoming and 'nested + multihoming' examples > within this document ? Alternatives is to move it to the soon to appear draft-ietf-nemo-multihoming-xxx. > > > # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > # Older Draft Submitted to the NEMO WG (expired) > # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > - draft-thubert-nemo-ipv4-traversal-01.txt (expired) > IPv4 traversal for MIPv6 based Mobile Routers > May 03 > > - http://www.ietf.org/internet-drafts/draft-perera-nemo-extended-00.txt > Extended Network Mobility Support (expired) > > - draft-hkang-nemo-ro-tlmr-00.txt (expired) > Route Optimization for Mobile Network by Using Bi-directional > Between Home Agent and Top Level Mobile Router > June 03 > Pardon me for doing a bit of self-advertising, but you may have missed one more expired draft on RO: - draft-ng-nemo-access-router-option-00.txt (expired) Securing Nested Tunnel Optimizations with Access Router Option http://www.psl.com.sg/draft-ng-nemo-access-router-option-00.txt Oct 2002 /rgds /cwng From exim@www1.ietf.org Wed Feb 25 22:21:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02202 for ; Wed, 25 Feb 2004 22:21:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwC5P-0000Sz-CU for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 22:21:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q3LJjX001793 for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 22:21:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwC5P-0000Sq-6j for nemo-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 22:21:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02193 for ; Wed, 25 Feb 2004 22:21:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwC5M-0002m9-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 22:21:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwC4O-0002hI-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 22:20:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwC4B-0002cu-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 22:20:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwC4C-0000L7-2i; Wed, 25 Feb 2004 22:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwC3U-0000GD-05 for nemo@optimus.ietf.org; Wed, 25 Feb 2004 22:19:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02109 for ; Wed, 25 Feb 2004 22:19:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwC3Q-0002bz-00 for nemo@ietf.org; Wed, 25 Feb 2004 22:19:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwC2d-0002WA-00 for nemo@ietf.org; Wed, 25 Feb 2004 22:18:27 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AwC1f-0002K3-00 for nemo@ietf.org; Wed, 25 Feb 2004 22:17:28 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1Q38qvj000948; Thu, 26 Feb 2004 11:08:52 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id BAD25B23984; Thu, 26 Feb 2004 11:11:40 +0800 (SGT) Subject: Re: [nemo] NEMO Agenda From: Chan-Wah NG To: Thierry Ernst Cc: IETF NEMO WG , tj In-Reply-To: <20040224234612.05cc7fe8.ernst@sfc.wide.ad.jp> References: <20040224234612.05cc7fe8.ernst@sfc.wide.ad.jp> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1077765100.5422.30.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 26 Feb 2004 11:11:40 +0800 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 2004-02-24 at 22:46, Thierry Ernst wrote: > # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > o NEMO Terminology Upates .................................. 10 mins > Thierry Ernst > > To be read: > ~~~~~~~~~~~ > Network Mobility Support Terminology > http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-01.txt > > To be discussed: > ~~~~~~~~~~~~~~~~ > - document should go to last call > - do we keep the multihoming and 'nested + multihoming' examples > within this document ? Alternatives is to move it to the soon to appear draft-ietf-nemo-multihoming-xxx. > > > # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > # Older Draft Submitted to the NEMO WG (expired) > # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > - draft-thubert-nemo-ipv4-traversal-01.txt (expired) > IPv4 traversal for MIPv6 based Mobile Routers > May 03 > > - http://www.ietf.org/internet-drafts/draft-perera-nemo-extended-00.txt > Extended Network Mobility Support (expired) > > - draft-hkang-nemo-ro-tlmr-00.txt (expired) > Route Optimization for Mobile Network by Using Bi-directional > Between Home Agent and Top Level Mobile Router > June 03 > Pardon me for doing a bit of self-advertising, but you may have missed one more expired draft on RO: - draft-ng-nemo-access-router-option-00.txt (expired) Securing Nested Tunnel Optimizations with Access Router Option http://www.psl.com.sg/draft-ng-nemo-access-router-option-00.txt Oct 2002 /rgds /cwng From nemo-admin@ietf.org Wed Feb 25 23:14:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03664 for ; Wed, 25 Feb 2004 23:14:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwCuQ-0004LI-He; Wed, 25 Feb 2004 23:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwCtq-0004KR-Iz for nemo@optimus.ietf.org; Wed, 25 Feb 2004 23:13:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03615 for ; Wed, 25 Feb 2004 23:13:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwCto-0007Oj-00 for nemo@ietf.org; Wed, 25 Feb 2004 23:13:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwCsf-0007DD-00 for nemo@ietf.org; Wed, 25 Feb 2004 23:12:14 -0500 Received: from jens246.inetcore.com ([202.33.8.246] helo=chappy.inetcore.com) by ietf-mx with esmtp (Exim 4.12) id 1AwCrO-00074z-00 for nemo@ietf.org; Wed, 25 Feb 2004 23:10:54 -0500 Received: from n-t23.wide.ad.jp (n-t23 [172.16.2.1]) by chappy.inetcore.com (8.11.6/8.11.3) with ESMTP id i1Q4AaS01774 for ; Thu, 26 Feb 2004 13:10:36 +0900 (JST) Message-Id: <6.0.0.20.2.20040226124851.04a4f310@gw.inetcore.com> X-Sender: nagami@gw.inetcore.com X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Thu, 26 Feb 2004 13:10:36 +0900 To: nemo@ietf.org From: Ken Nagami Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] Multi-homing using 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: , Content-Transfer-Encoding: 7bit Hi all, We are interested in multi-homed network using NEMO. Currently, we implemented the following architecture and evaluate in a experimental network. Attached document is our motivation and idea for multi-homing using NEMO. Since I did not submit by deadline as I-D, I send this draft to NEMO ML. I think some of them is merged into scenario or problem statement draft for multi-homing. If you have any comment or questions, please let us know. Regards, Ken Nagami -------------------------------------------------------------------------------- Multi-homing for small scale fixed network Using Mobile IP and NEMO Kenichi Nagami(INTEC Netcore) Satoshi Uda (JAIST) Nobuo Ogashiwa (JAIST) Ryuji Wakikawa(Keio Univ.) Hiroshi Esaki(Univ. Tokyo) Hiroyuki Ohnishi(NTT) Abstract Multi-homing technology improves the availability of host and network connectivity. Since the node and network behavior of mobile networking and fixed networking are different, the different architecture has been discussed and proposed. This document proposes the common architecture both for mobile and fixed networking environment, using the mobile IP and NEMO. The proposed architecture only requires a modification of the mobile IP and NEMO so that multiple-CoA can be used. In addition, multiple HAs which are located in different place, are required for redundancy. 1. Motivation Users of small scale network need to improve the network availability and to get load balance of several links by easy method. Multi-homing technology is one of solutions to improve the availability. Conventional major multi-homing network uses BGP. But it has some issues as followings. Therefore, we propose a multi-homing architecture using the mobile IP and NEMO for small-scale fixed network. (1) Increasing route entries in the Internet In the multi-homing environments, each user's network needs to advertise its address block to all ISPs connected to them. If multi-homed user connects only one ISP, the ISP can advertise routing information to aggregate them. But some multi-homed user needs to connect with different ISPs in preparation for failure of ISP. In this case, ISPs need to advertise routing information for multi-homed user without aggregation. Therefore, the number of routing entries in the Internet is increasing one by one. (2) Difficulty to efficiently use multiple links It is not easy to control in-coming traffics in the case of the conventional multi-homing architecture using BGP. Therefore, load balancing of connected links are difficult. 2. Multi-homing for small scale fixed network Using Mobile IP and NEMO 2.1 Mobile network includes fixed network NEMO and Mobile IP must work with multi-homing by its nature. This is because mobile nodes need to use multiple links for improving the availability of network connectivity since the wireless link is not always stable. Therefore, we propose that multihoming for fixed nodes (routers and hosts) use the framework of NEMO and Mobile IP. 2.2 Overview multi-homing network architecture using Mobile IP Figure 1 shows basic multi-homing network architecture. In this architecture, a mobile router (MR), which is boarder router of multi-homed network, sets up several tunnels between the MR and the HA by multiple-CoA registration to provide redundancy and load balancing. A HA or a router which the HA belongs advertise user's network prefix to ISPs via routing protocol. If HA has several multi-homed network, they can advertise an aggregated network prefix to ISPs. Therefore, the Internet routing entries do not increase one by one when multi-homed user is increased. Packets to multi-homed users go to HA and the HA sends packets to MR using CoA1 and CoA2. The HA select a route which CoA is used. The route selection algorithm is out of scope of this document. This can improve availability of user network and control an in-coming traffic between ISP and MR. In the basic architecture, HA1 is single point of failure. In order to improve availability of user network, multiple HA is needed. This is described in later section. HA1 | ISP A--ISP B | | CoA1| |CoA2 Mobile Router (MR) | Multi-homed user network Fig.1 Basic Architecture 3. Requirements for Mobile IP and NEMO 3.1 Multiple Care-of-Addresses (CoA) Multiple Care-of-Addresses needs to improve the availability and to control in coming and out going traffic. 3.2 Multiple Home Agents Multiple Home Agents should be geographically distributed across the Internet, for the improvement of service availability and for the load balancing of HA. When all the networks that have HA advertise the same network prefix to their adjacent router/network, the traffic is automatically routed to the nearest Home Agent from the view point of routing protocol topology. This operation has been already proven operational technology in the area of web server application, such as CDN (contents Delivery Network), regarding IGP and EGP. In order to operate multiple HAs, all HAs must have the same information such as binding information. This is the synchronization of database among the HA. This is the same architecture as I-BGP. The database is synchronized by full-mesh topology. In addition, in order to simplify operation of HA, the database is synchronized using star topology. This is analogy with I-BGP route reflector. HA1 HA1 | | ISP A--ISP B | | CoA1| |CoA2 Mobile Router (MR) | Multi-homed user network Fig.2 Architecture with HA redundancy 4. Security considerations This draft does not raise specific security issues beyond those of existing mobile IP and NEMO and routing protocols. From exim@www1.ietf.org Wed Feb 25 23:16:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03924 for ; Wed, 25 Feb 2004 23:16:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwCwc-0004Se-RJ for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 23:16:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q4GIg4017128 for nemo-archive@odin.ietf.org; Wed, 25 Feb 2004 23:16:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwCwc-0004S7-FD for nemo-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 23:16:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03910 for ; Wed, 25 Feb 2004 23:16:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwCwa-00001q-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 23:16:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwCvr-0007iD-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 23:15:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwCuZ-0007Ty-00 for nemo-web-archive@ietf.org; Wed, 25 Feb 2004 23:14:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwCuQ-0004LI-He; Wed, 25 Feb 2004 23:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwCtq-0004KR-Iz for nemo@optimus.ietf.org; Wed, 25 Feb 2004 23:13:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03615 for ; Wed, 25 Feb 2004 23:13:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwCto-0007Oj-00 for nemo@ietf.org; Wed, 25 Feb 2004 23:13:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwCsf-0007DD-00 for nemo@ietf.org; Wed, 25 Feb 2004 23:12:14 -0500 Received: from jens246.inetcore.com ([202.33.8.246] helo=chappy.inetcore.com) by ietf-mx with esmtp (Exim 4.12) id 1AwCrO-00074z-00 for nemo@ietf.org; Wed, 25 Feb 2004 23:10:54 -0500 Received: from n-t23.wide.ad.jp (n-t23 [172.16.2.1]) by chappy.inetcore.com (8.11.6/8.11.3) with ESMTP id i1Q4AaS01774 for ; Thu, 26 Feb 2004 13:10:36 +0900 (JST) Message-Id: <6.0.0.20.2.20040226124851.04a4f310@gw.inetcore.com> X-Sender: nagami@gw.inetcore.com X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Thu, 26 Feb 2004 13:10:36 +0900 To: nemo@ietf.org From: Ken Nagami Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Multi-homing using 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, We are interested in multi-homed network using NEMO. Currently, we implemented the following architecture and evaluate in a experimental network. Attached document is our motivation and idea for multi-homing using NEMO. Since I did not submit by deadline as I-D, I send this draft to NEMO ML. I think some of them is merged into scenario or problem statement draft for multi-homing. If you have any comment or questions, please let us know. Regards, Ken Nagami -------------------------------------------------------------------------------- Multi-homing for small scale fixed network Using Mobile IP and NEMO Kenichi Nagami(INTEC Netcore) Satoshi Uda (JAIST) Nobuo Ogashiwa (JAIST) Ryuji Wakikawa(Keio Univ.) Hiroshi Esaki(Univ. Tokyo) Hiroyuki Ohnishi(NTT) Abstract Multi-homing technology improves the availability of host and network connectivity. Since the node and network behavior of mobile networking and fixed networking are different, the different architecture has been discussed and proposed. This document proposes the common architecture both for mobile and fixed networking environment, using the mobile IP and NEMO. The proposed architecture only requires a modification of the mobile IP and NEMO so that multiple-CoA can be used. In addition, multiple HAs which are located in different place, are required for redundancy. 1. Motivation Users of small scale network need to improve the network availability and to get load balance of several links by easy method. Multi-homing technology is one of solutions to improve the availability. Conventional major multi-homing network uses BGP. But it has some issues as followings. Therefore, we propose a multi-homing architecture using the mobile IP and NEMO for small-scale fixed network. (1) Increasing route entries in the Internet In the multi-homing environments, each user's network needs to advertise its address block to all ISPs connected to them. If multi-homed user connects only one ISP, the ISP can advertise routing information to aggregate them. But some multi-homed user needs to connect with different ISPs in preparation for failure of ISP. In this case, ISPs need to advertise routing information for multi-homed user without aggregation. Therefore, the number of routing entries in the Internet is increasing one by one. (2) Difficulty to efficiently use multiple links It is not easy to control in-coming traffics in the case of the conventional multi-homing architecture using BGP. Therefore, load balancing of connected links are difficult. 2. Multi-homing for small scale fixed network Using Mobile IP and NEMO 2.1 Mobile network includes fixed network NEMO and Mobile IP must work with multi-homing by its nature. This is because mobile nodes need to use multiple links for improving the availability of network connectivity since the wireless link is not always stable. Therefore, we propose that multihoming for fixed nodes (routers and hosts) use the framework of NEMO and Mobile IP. 2.2 Overview multi-homing network architecture using Mobile IP Figure 1 shows basic multi-homing network architecture. In this architecture, a mobile router (MR), which is boarder router of multi-homed network, sets up several tunnels between the MR and the HA by multiple-CoA registration to provide redundancy and load balancing. A HA or a router which the HA belongs advertise user's network prefix to ISPs via routing protocol. If HA has several multi-homed network, they can advertise an aggregated network prefix to ISPs. Therefore, the Internet routing entries do not increase one by one when multi-homed user is increased. Packets to multi-homed users go to HA and the HA sends packets to MR using CoA1 and CoA2. The HA select a route which CoA is used. The route selection algorithm is out of scope of this document. This can improve availability of user network and control an in-coming traffic between ISP and MR. In the basic architecture, HA1 is single point of failure. In order to improve availability of user network, multiple HA is needed. This is described in later section. HA1 | ISP A--ISP B | | CoA1| |CoA2 Mobile Router (MR) | Multi-homed user network Fig.1 Basic Architecture 3. Requirements for Mobile IP and NEMO 3.1 Multiple Care-of-Addresses (CoA) Multiple Care-of-Addresses needs to improve the availability and to control in coming and out going traffic. 3.2 Multiple Home Agents Multiple Home Agents should be geographically distributed across the Internet, for the improvement of service availability and for the load balancing of HA. When all the networks that have HA advertise the same network prefix to their adjacent router/network, the traffic is automatically routed to the nearest Home Agent from the view point of routing protocol topology. This operation has been already proven operational technology in the area of web server application, such as CDN (contents Delivery Network), regarding IGP and EGP. In order to operate multiple HAs, all HAs must have the same information such as binding information. This is the synchronization of database among the HA. This is the same architecture as I-BGP. The database is synchronized by full-mesh topology. In addition, in order to simplify operation of HA, the database is synchronized using star topology. This is analogy with I-BGP route reflector. HA1 HA1 | | ISP A--ISP B | | CoA1| |CoA2 Mobile Router (MR) | Multi-homed user network Fig.2 Architecture with HA redundancy 4. Security considerations This draft does not raise specific security issues beyond those of existing mobile IP and NEMO and routing protocols. From nemo-admin@ietf.org Thu Feb 26 01:05:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07916 for ; Thu, 26 Feb 2004 01:05:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwEdp-0002nT-72; Thu, 26 Feb 2004 01:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwEd8-0002m8-6M for nemo@optimus.ietf.org; Thu, 26 Feb 2004 01:04:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07881 for ; Thu, 26 Feb 2004 01:04:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwEd5-00025L-00 for nemo@ietf.org; Thu, 26 Feb 2004 01:04:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwEcA-0001zo-00 for nemo@ietf.org; Thu, 26 Feb 2004 01:03:18 -0500 Received: from mobqos.ee.unsw.edu.au ([129.94.230.70]) by ietf-mx with esmtp (Exim 4.12) id 1AwEbM-0001pV-00 for nemo@ietf.org; Thu, 26 Feb 2004 01:02:28 -0500 Received: from eranga (helo=localhost) by mobqos.ee.unsw.edu.au with local-esmtp (Exim 3.35 #1 (Debian)) id 1AwEar-0006tz-00 for ; Thu, 26 Feb 2004 17:01:57 +1100 Date: Thu, 26 Feb 2004 17:01:57 +1100 (EST) From: Eranga Perera To: nemo@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [nemo] Visiting Nodes 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 All, Would someone be able to clarify why is it that all visiting nodes to a mobile network are assumed to be mobile nodes? More precisely how about the nodes that belong to another network (not mobile network) but has no mobility capabilities? (scenario - commuter with a PDA with no mobility capabilities obtain connectivity via a MR deployed on a bus) Thankx in advance, Eranga From exim@www1.ietf.org Thu Feb 26 01:06:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07976 for ; Thu, 26 Feb 2004 01:06:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwEf8-00036z-BF for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 01:06:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q66MsZ011955 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 01:06:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwEf8-00036X-20 for nemo-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 01:06:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07973 for ; Thu, 26 Feb 2004 01:06:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwEf5-0002HN-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 01:06:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwEeE-0002Cw-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 01:05:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwEdt-00027i-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 01:05:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwEdp-0002nT-72; Thu, 26 Feb 2004 01:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwEd8-0002m8-6M for nemo@optimus.ietf.org; Thu, 26 Feb 2004 01:04:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07881 for ; Thu, 26 Feb 2004 01:04:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwEd5-00025L-00 for nemo@ietf.org; Thu, 26 Feb 2004 01:04:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwEcA-0001zo-00 for nemo@ietf.org; Thu, 26 Feb 2004 01:03:18 -0500 Received: from mobqos.ee.unsw.edu.au ([129.94.230.70]) by ietf-mx with esmtp (Exim 4.12) id 1AwEbM-0001pV-00 for nemo@ietf.org; Thu, 26 Feb 2004 01:02:28 -0500 Received: from eranga (helo=localhost) by mobqos.ee.unsw.edu.au with local-esmtp (Exim 3.35 #1 (Debian)) id 1AwEar-0006tz-00 for ; Thu, 26 Feb 2004 17:01:57 +1100 Date: Thu, 26 Feb 2004 17:01:57 +1100 (EST) From: Eranga Perera To: nemo@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [nemo] Visiting Nodes 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi All, Would someone be able to clarify why is it that all visiting nodes to a mobile network are assumed to be mobile nodes? More precisely how about the nodes that belong to another network (not mobile network) but has no mobility capabilities? (scenario - commuter with a PDA with no mobility capabilities obtain connectivity via a MR deployed on a bus) Thankx in advance, Eranga From nemo-admin@ietf.org Thu Feb 26 02:06:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17428 for ; Thu, 26 Feb 2004 02:06:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwFar-0001q9-RH; Thu, 26 Feb 2004 02:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwFaJ-0001Yx-6g for nemo@optimus.ietf.org; Thu, 26 Feb 2004 02:05:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16183 for ; Thu, 26 Feb 2004 02:05:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwFaF-0007jK-00 for nemo@ietf.org; Thu, 26 Feb 2004 02:05:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwFZF-0007es-00 for nemo@ietf.org; Thu, 26 Feb 2004 02:04:22 -0500 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx with smtp (Exim 4.12) id 1AwFYU-0007aN-00 for nemo@ietf.org; Thu, 26 Feb 2004 02:03:34 -0500 Received: From mustafa ([129.94.172.200] == mustafa.cse.unsw.EDU.AU) (for ) (for ) By note With Smtp ; Thu, 26 Feb 2004 18:03:32 +1100 From: "Muhammad Ali Malik" To: "Eranga Perera" , Date: Thu, 26 Feb 2004 18:03:32 +1100 Subject: RE: [nemo] Visiting Nodes Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Since they r moving with mobile network, therefore they r mobile. In fact they r moving transparently with mobile network. For MN, the mobility is static. =Muhammad -----Original Message----- From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]On Behalf Of Eranga Perera Sent: Thursday, February 26, 2004 5:02 PM To: nemo@ietf.org Subject: [nemo] Visiting Nodes Hi All, Would someone be able to clarify why is it that all visiting nodes to a mobile network are assumed to be mobile nodes? More precisely how about the nodes that belong to another network (not mobile network) but has no mobility capabilities? (scenario - commuter with a PDA with no mobility capabilities obtain connectivity via a MR deployed on a bus) Thankx in advance, Eranga From exim@www1.ietf.org Thu Feb 26 02:07:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19153 for ; Thu, 26 Feb 2004 02:07:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwFcH-0002l1-Sg for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 02:07:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q77TqG010579 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 02:07:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwFcG-0002jq-E8 for nemo-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 02:07:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18462 for ; Thu, 26 Feb 2004 02:07:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwFcC-00007F-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 02:07:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwFbJ-00002E-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 02:06:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwFat-0007kh-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 02:06:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwFar-0001q9-RH; Thu, 26 Feb 2004 02:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwFaJ-0001Yx-6g for nemo@optimus.ietf.org; Thu, 26 Feb 2004 02:05:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16183 for ; Thu, 26 Feb 2004 02:05:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwFaF-0007jK-00 for nemo@ietf.org; Thu, 26 Feb 2004 02:05:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwFZF-0007es-00 for nemo@ietf.org; Thu, 26 Feb 2004 02:04:22 -0500 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx with smtp (Exim 4.12) id 1AwFYU-0007aN-00 for nemo@ietf.org; Thu, 26 Feb 2004 02:03:34 -0500 Received: From mustafa ([129.94.172.200] == mustafa.cse.unsw.EDU.AU) (for ) (for ) By note With Smtp ; Thu, 26 Feb 2004 18:03:32 +1100 From: "Muhammad Ali Malik" To: "Eranga Perera" , Date: Thu, 26 Feb 2004 18:03:32 +1100 Subject: RE: [nemo] Visiting Nodes Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Since they r moving with mobile network, therefore they r mobile. In fact they r moving transparently with mobile network. For MN, the mobility is static. =Muhammad -----Original Message----- From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]On Behalf Of Eranga Perera Sent: Thursday, February 26, 2004 5:02 PM To: nemo@ietf.org Subject: [nemo] Visiting Nodes Hi All, Would someone be able to clarify why is it that all visiting nodes to a mobile network are assumed to be mobile nodes? More precisely how about the nodes that belong to another network (not mobile network) but has no mobility capabilities? (scenario - commuter with a PDA with no mobility capabilities obtain connectivity via a MR deployed on a bus) Thankx in advance, Eranga From nemo-admin@ietf.org Thu Feb 26 03:33:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27256 for ; Thu, 26 Feb 2004 03:33:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwGx3-00076z-6g; Thu, 26 Feb 2004 03:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwGwY-00076R-Dt for nemo@optimus.ietf.org; Thu, 26 Feb 2004 03:32:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27217 for ; Thu, 26 Feb 2004 03:32:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwGwW-0000J7-00 for nemo@ietf.org; Thu, 26 Feb 2004 03:32:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwGvd-0000DJ-00 for nemo@ietf.org; Thu, 26 Feb 2004 03:31:34 -0500 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx with esmtp (Exim 4.12) id 1AwGuu-00002j-00 for nemo@ietf.org; Thu, 26 Feb 2004 03:30:48 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E2615AC52; Thu, 26 Feb 2004 09:30:18 +0100 (CET) Received: from acorde.it.uc3m.es (acorde.it.uc3m.es [163.117.139.72]) by smtp03.uc3m.es (Postfix) with ESMTP id CAD57AC28; Thu, 26 Feb 2004 09:30:18 +0100 (CET) Subject: Re: [nemo] Visiting Nodes From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Eranga Perera Cc: nemo@ietf.org In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-mXibPm516lTlaJgjSs1y" Organization: Universidad Carlos III de Madrid Message-Id: <1077784218.790.15.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 26 Feb 2004 09:30:18 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , --=-mXibPm516lTlaJgjSs1y Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Eranga, All MNNs (Mobile Network Nodes) move with the mobile network, but not all of them are "mobile nodes" (i.e. have MIPv6 support and can move topologically with respect to the MR). Local Fixed Nodes (LFNs) are nodes that belong to the mobile network and which do not move with respect to the MR (like the node you pointed in your example). In the other hand, there are nodes with mobility capabilities: Visiting Mobile Nodes (VMNs) and Local Mobile Nodes (LMNs). Perhaps the term "visiting" is not very clear and could lead to confusion, but IMHO it does not mean that other nodes-with no mobility capabilities-could not visit a mobile network (i.e. a node with portability-DHCPv6 support). Best regards, Carlos J. El jue, 26-02-2004 a las 07:01, Eranga Perera escribi=F3: > Hi All, > Would someone be able to clarify why is it that all visiting nodes to a > mobile network are assumed to be mobile nodes? > More precisely how about the nodes that belong to another network (not > mobile network) but has no mobility capabilities? > (scenario - commuter with a PDA with no mobility capabilities obtain > connectivity via a MR deployed on a bus) >=20 > Thankx in advance, > Eranga --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 1880 80D3 8004 25C7 6537 8E02 252A D295 9CFF DEAF --=-mXibPm516lTlaJgjSs1y Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAPa6aJSrSlZz/3q8RAickAJ4ySRHBjkm+x+MfR9lDZel5mqVbnwCfcDmb PNB0V3M4C+B/k/ZFXii83UQ= =GJ84 -----END PGP SIGNATURE----- --=-mXibPm516lTlaJgjSs1y-- From exim@www1.ietf.org Thu Feb 26 03:35:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27445 for ; Thu, 26 Feb 2004 03:35:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwGyn-0007NB-D6 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 03:34:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q8Yn52028327 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 03:34:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwGyl-0007MY-Vj for nemo-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 03:34:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27402 for ; Thu, 26 Feb 2004 03:34:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwGyj-0000dX-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 03:34:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwGxn-0000Ug-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 03:33:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwGx4-0000Mc-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 03:33:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwGx3-00076z-6g; Thu, 26 Feb 2004 03:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwGwY-00076R-Dt for nemo@optimus.ietf.org; Thu, 26 Feb 2004 03:32:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27217 for ; Thu, 26 Feb 2004 03:32:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwGwW-0000J7-00 for nemo@ietf.org; Thu, 26 Feb 2004 03:32:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwGvd-0000DJ-00 for nemo@ietf.org; Thu, 26 Feb 2004 03:31:34 -0500 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx with esmtp (Exim 4.12) id 1AwGuu-00002j-00 for nemo@ietf.org; Thu, 26 Feb 2004 03:30:48 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E2615AC52; Thu, 26 Feb 2004 09:30:18 +0100 (CET) Received: from acorde.it.uc3m.es (acorde.it.uc3m.es [163.117.139.72]) by smtp03.uc3m.es (Postfix) with ESMTP id CAD57AC28; Thu, 26 Feb 2004 09:30:18 +0100 (CET) Subject: Re: [nemo] Visiting Nodes From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Eranga Perera Cc: nemo@ietf.org In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-mXibPm516lTlaJgjSs1y" Organization: Universidad Carlos III de Madrid Message-Id: <1077784218.790.15.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 26 Feb 2004 09:30:18 +0100 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --=-mXibPm516lTlaJgjSs1y Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Eranga, All MNNs (Mobile Network Nodes) move with the mobile network, but not all of them are "mobile nodes" (i.e. have MIPv6 support and can move topologically with respect to the MR). Local Fixed Nodes (LFNs) are nodes that belong to the mobile network and which do not move with respect to the MR (like the node you pointed in your example). In the other hand, there are nodes with mobility capabilities: Visiting Mobile Nodes (VMNs) and Local Mobile Nodes (LMNs). Perhaps the term "visiting" is not very clear and could lead to confusion, but IMHO it does not mean that other nodes-with no mobility capabilities-could not visit a mobile network (i.e. a node with portability-DHCPv6 support). Best regards, Carlos J. El jue, 26-02-2004 a las 07:01, Eranga Perera escribi=F3: > Hi All, > Would someone be able to clarify why is it that all visiting nodes to a > mobile network are assumed to be mobile nodes? > More precisely how about the nodes that belong to another network (not > mobile network) but has no mobility capabilities? > (scenario - commuter with a PDA with no mobility capabilities obtain > connectivity via a MR deployed on a bus) >=20 > Thankx in advance, > Eranga --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 1880 80D3 8004 25C7 6537 8E02 252A D295 9CFF DEAF --=-mXibPm516lTlaJgjSs1y Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAPa6aJSrSlZz/3q8RAickAJ4ySRHBjkm+x+MfR9lDZel5mqVbnwCfcDmb PNB0V3M4C+B/k/ZFXii83UQ= =GJ84 -----END PGP SIGNATURE----- --=-mXibPm516lTlaJgjSs1y-- From nemo-admin@ietf.org Thu Feb 26 03:35:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27540 for ; Thu, 26 Feb 2004 03:35:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwGz3-0007RL-Oq; Thu, 26 Feb 2004 03:35:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwGyp-0007O9-48 for nemo@optimus.ietf.org; Thu, 26 Feb 2004 03:34:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27418 for ; Thu, 26 Feb 2004 03:34:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwGym-0000dw-00 for nemo@ietf.org; Thu, 26 Feb 2004 03:34:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwGxq-0000VN-00 for nemo@ietf.org; Thu, 26 Feb 2004 03:33:51 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1AwGx9-0000Km-00 for nemo@ietf.org; Thu, 26 Feb 2004 03:33:07 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 08BE7A7EF; Thu, 26 Feb 2004 09:32:38 +0100 (CET) Received: from pandereta (pandereta.it.uc3m.es [163.117.139.129]) by smtp01.uc3m.es (Postfix) with ESMTP id DCCFFA7A1; Thu, 26 Feb 2004 09:32:37 +0100 (CET) Reply-To: From: =?iso-8859-1?Q?Mar=EDa_Calder=F3n?= To: "'Eranga Perera'" Cc: Subject: RE: [nemo] Visiting Nodes Date: Thu, 26 Feb 2004 09:32:37 +0100 Message-ID: <000c01c3fc43$172895d0$818b75a3@pandereta> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Eranga, In my understanding in the scenario you propose the PDA is not a visiting node to the mobile network on the bus. I guess the PDA is getting dinamically an IP address by DHCP and it is getting access to Internet via the MR deployed on the bus. But in this scenario the PDA with no mobility capabilities hasn't a Home Agent that receives packets send to the HoA_PDA, and forwards them to the CoA_PDA. Thus the PDA after obtaining connectivity via the MR will be a Local Fixed Node of the mobile network. Best regards Maria -----Mensaje original----- De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] En nombre de Eranga Perera Enviado el: jueves, 26 de febrero de 2004 7:02 Para: nemo@ietf.org Asunto: [nemo] Visiting Nodes Hi All, Would someone be able to clarify why is it that all visiting nodes to a mobile network are assumed to be mobile nodes? More precisely how about the nodes that belong to another network (not mobile network) but has no mobility capabilities? (scenario - commuter with a PDA with no mobility capabilities obtain connectivity via a MR deployed on a bus) Thankx in advance, Eranga From exim@www1.ietf.org Thu Feb 26 03:37:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27592 for ; Thu, 26 Feb 2004 03:37:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwH0a-0007eC-HY for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 03:36:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q8aeJ0029389 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 03:36:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwH0a-0007dw-Br for nemo-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 03:36:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27579 for ; Thu, 26 Feb 2004 03:36:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwH0Y-0000ql-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 03:36:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwGzW-0000kh-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 03:35:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwGz3-0000eu-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 03:35:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwGz3-0007RL-Oq; Thu, 26 Feb 2004 03:35:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwGyp-0007O9-48 for nemo@optimus.ietf.org; Thu, 26 Feb 2004 03:34:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27418 for ; Thu, 26 Feb 2004 03:34:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwGym-0000dw-00 for nemo@ietf.org; Thu, 26 Feb 2004 03:34:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwGxq-0000VN-00 for nemo@ietf.org; Thu, 26 Feb 2004 03:33:51 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1AwGx9-0000Km-00 for nemo@ietf.org; Thu, 26 Feb 2004 03:33:07 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 08BE7A7EF; Thu, 26 Feb 2004 09:32:38 +0100 (CET) Received: from pandereta (pandereta.it.uc3m.es [163.117.139.129]) by smtp01.uc3m.es (Postfix) with ESMTP id DCCFFA7A1; Thu, 26 Feb 2004 09:32:37 +0100 (CET) Reply-To: From: =?iso-8859-1?Q?Mar=EDa_Calder=F3n?= To: "'Eranga Perera'" Cc: Subject: RE: [nemo] Visiting Nodes Date: Thu, 26 Feb 2004 09:32:37 +0100 Message-ID: <000c01c3fc43$172895d0$818b75a3@pandereta> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Eranga, In my understanding in the scenario you propose the PDA is not a visiting node to the mobile network on the bus. I guess the PDA is getting dinamically an IP address by DHCP and it is getting access to Internet via the MR deployed on the bus. But in this scenario the PDA with no mobility capabilities hasn't a Home Agent that receives packets send to the HoA_PDA, and forwards them to the CoA_PDA. Thus the PDA after obtaining connectivity via the MR will be a Local Fixed Node of the mobile network. Best regards Maria -----Mensaje original----- De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] En nombre de Eranga Perera Enviado el: jueves, 26 de febrero de 2004 7:02 Para: nemo@ietf.org Asunto: [nemo] Visiting Nodes Hi All, Would someone be able to clarify why is it that all visiting nodes to a mobile network are assumed to be mobile nodes? More precisely how about the nodes that belong to another network (not mobile network) but has no mobility capabilities? (scenario - commuter with a PDA with no mobility capabilities obtain connectivity via a MR deployed on a bus) Thankx in advance, Eranga From nemo-admin@ietf.org Thu Feb 26 04:34:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00845 for ; Thu, 26 Feb 2004 04:34:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwHu6-0004t5-LO; Thu, 26 Feb 2004 04:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwHtd-0004mV-EY for nemo@optimus.ietf.org; Thu, 26 Feb 2004 04:33:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00819 for ; Thu, 26 Feb 2004 04:33:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwHta-0006sE-00 for nemo@ietf.org; Thu, 26 Feb 2004 04:33:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwHsj-0006nd-00 for nemo@ietf.org; Thu, 26 Feb 2004 04:32:37 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AwHsF-0006hw-00 for nemo@ietf.org; Thu, 26 Feb 2004 04:32:07 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i1Q9W7pK017826; Thu, 26 Feb 2004 02:32:08 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i1Q9SX11010810; Thu, 26 Feb 2004 03:28:33 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 956F985272D; Thu, 26 Feb 2004 10:28:32 +0100 (CET) Message-ID: <403DBC40.3090907@motorola.com> Date: Thu, 26 Feb 2004 10:28:32 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eranga Perera Cc: nemo@ietf.org Subject: Re: [nemo] Visiting Nodes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Eranga Perera wrote: > Hi All, > Would someone be able to clarify why is it that all visiting nodes to a > mobile network are assumed to be mobile nodes? > More precisely how about the nodes that belong to another network (not > mobile network) but has no mobility capabilities? > (scenario - commuter with a PDA with no mobility capabilities obtain > connectivity via a MR deployed on a bus) If the node entering the train has no mobility capabilities (i.e. no Mobile IPv6 MN code) then it will loose all ongoing connections once it obtains a new address inside the train. This is not necessarily meaning that its new connections will not work, it is just that ongoing applications will have to be restarted; for some applications this is probably not even noticeable, for others it is bad enough. However, since in NEMO the Mobile IPv6 protocol is used, it is natural to assume that the VMN's do use Mobile IPv6, and it is also natural to look at the Mobile IPv6 problems that might (or might not occur) when that node enters a train. If a node not using Mobile IPv6 enters a train moving network, then problems related to DHCPv6, or other means of acquiring a new address (without caring about continuing ongoing applications), or routing, maybe could be treated in other places; this is to say that the moving network looks to the respective node as any other fixed network, no difference... Otherwise, what do you think are the problems of a non-Mobile IPv6 node jumping from a bus to a train? My oppinion, Alex From exim@www1.ietf.org Thu Feb 26 04:35:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00891 for ; Thu, 26 Feb 2004 04:35:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwHvW-00059C-3G for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 04:35:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q9ZTba019773 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 04:35:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwHvU-00058n-2d for nemo-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 04:35:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00883 for ; Thu, 26 Feb 2004 04:35:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwHvR-00071w-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 04:35:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwHuW-0006xk-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 04:34:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwHuB-0006tF-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 04:34:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwHu6-0004t5-LO; Thu, 26 Feb 2004 04:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwHtd-0004mV-EY for nemo@optimus.ietf.org; Thu, 26 Feb 2004 04:33:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00819 for ; Thu, 26 Feb 2004 04:33:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwHta-0006sE-00 for nemo@ietf.org; Thu, 26 Feb 2004 04:33:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwHsj-0006nd-00 for nemo@ietf.org; Thu, 26 Feb 2004 04:32:37 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AwHsF-0006hw-00 for nemo@ietf.org; Thu, 26 Feb 2004 04:32:07 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i1Q9W7pK017826; Thu, 26 Feb 2004 02:32:08 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i1Q9SX11010810; Thu, 26 Feb 2004 03:28:33 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 956F985272D; Thu, 26 Feb 2004 10:28:32 +0100 (CET) Message-ID: <403DBC40.3090907@motorola.com> Date: Thu, 26 Feb 2004 10:28:32 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eranga Perera Cc: nemo@ietf.org Subject: Re: [nemo] Visiting Nodes References: In-Reply-To: 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eranga Perera wrote: > Hi All, > Would someone be able to clarify why is it that all visiting nodes to a > mobile network are assumed to be mobile nodes? > More precisely how about the nodes that belong to another network (not > mobile network) but has no mobility capabilities? > (scenario - commuter with a PDA with no mobility capabilities obtain > connectivity via a MR deployed on a bus) If the node entering the train has no mobility capabilities (i.e. no Mobile IPv6 MN code) then it will loose all ongoing connections once it obtains a new address inside the train. This is not necessarily meaning that its new connections will not work, it is just that ongoing applications will have to be restarted; for some applications this is probably not even noticeable, for others it is bad enough. However, since in NEMO the Mobile IPv6 protocol is used, it is natural to assume that the VMN's do use Mobile IPv6, and it is also natural to look at the Mobile IPv6 problems that might (or might not occur) when that node enters a train. If a node not using Mobile IPv6 enters a train moving network, then problems related to DHCPv6, or other means of acquiring a new address (without caring about continuing ongoing applications), or routing, maybe could be treated in other places; this is to say that the moving network looks to the respective node as any other fixed network, no difference... Otherwise, what do you think are the problems of a non-Mobile IPv6 node jumping from a bus to a train? My oppinion, Alex From nemo-admin@ietf.org Thu Feb 26 04:52:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01396 for ; Thu, 26 Feb 2004 04:52:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIBV-0006Zz-Ko; Thu, 26 Feb 2004 04:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIAx-0006Xv-FR for nemo@optimus.ietf.org; Thu, 26 Feb 2004 04:51:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01322 for ; Thu, 26 Feb 2004 04:51:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwIAu-0000SX-00 for nemo@ietf.org; Thu, 26 Feb 2004 04:51:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwI9y-0000O1-00 for nemo@ietf.org; Thu, 26 Feb 2004 04:50:27 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AwI9R-0000Je-00 for nemo@ietf.org; Thu, 26 Feb 2004 04:49:53 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1Q9nrYG016330 for ; Thu, 26 Feb 2004 10:49:53 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Feb 2004 10:49:53 +0100 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSMBW8XM; Thu, 26 Feb 2004 10:49:53 +0100 Message-ID: <403DC0A1.6010000@ericsson.com> Date: Thu, 26 Feb 2004 10:47:13 +0100 X-Sybari-Trust: 81537d22 c77f3eb6 6298249a 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: Thierry Ernst , cwng@psl.com.sg, eun@mmlab.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] merged multihoming draft References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2004 09:49:53.0328 (UTC) FILETIME=[E2254300:01C3FC4D] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 marcelo bagnulo wrote: >>If there is no intermediate >>router, then at least the site exit routers cooperate. >> >>And this is not even a matter of multihoming to survive outages. The MNN >>won't be able to communicate unless it by luck selects the correct >>source address for the DR it has chosen. > > > This is also the case in any multihomed network, mobile or fixed, since > iwhen there are multiple prefixes available, it has to select the one that > matches with the ISP through which the packet will be carried. > > that is why i was asking why do you think that the multiple prefix case has > something NEMO specific. > > I would say that fixed multihoming solutions should deal with this case, > just as any other part of the Home Network, (which is actually the > multihomed network in this case, not the mobile network, as far as i can > see) Yes, sorry, for case N,1,N I fully agree. It is the home network that is multihomed and it will ultimately have to deal with this. The MRs can get away with their behaviour. > o (N,N,N) Mobile Network > > The (N,N,N) mobile network has multiple mobile routers, > registering to multiple home-agents and advertising prefixes. > This may be a case of multiple non-multihomed network superimposed > together, i.e. each mobile router take cares of one prefix, and > register to separate home agents. It is the N, N, N (alternative 1, see above) that I've drifted into. This is the case where NEMO introduces more requirements on hosts than what ND does. Look at this case from the MNN's point of view. It hears two routers (MRs) advertising themselves as capable of routing all traffic (i.e. stating that they are default routers). To follow the example in draft-huitema-multi6-hosts section 3.3 we have MNN as X with two addresses A:X and B:X. It wants to communicate with Y both available at C:Y and D:Y. If X can't be allowed to establish a communication between any of the four combinations {ax-cy, bx-cy, ax-dy, bx-dy} then something is seriously wrong with the configuration of the network. As far as X goes it MUST NOT have to know that site-exit router R-A only accepts packets with source address with prefix A. Why is a default router claiming that it can route all traffic only to drop some of it the next minute? None of the cases that I've seen in IPv6 and multi6 claim that X must select the correct default router in order to communicate. Yes, the packet must have the right source address to be carried over the ISP's network, but that is something the routers have to deal with. Yes, ISP B may be "better" in some sense (and sometimes routers only route on destination addresses, which is bad in this case), but unless X knows that, how can it know what source address to use for its default traffic? To me it is a serious mistake by a router to claim it is a default router if it really isn't. Until the hosts get more information about ISP preferences and ingress filtering policies, the router must deal with this mess. So, yes, to answer your question: NEMO case N,N,N introduces a (broken) network configuration previously unknown to/unsupported by IPv6 and multi6. /Mattias This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From exim@www1.ietf.org Thu Feb 26 04:54:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01444 for ; Thu, 26 Feb 2004 04:54:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwICx-0006jV-Rb for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 04:53:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q9rVl5025875 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 04:53:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwICx-0006jG-7a for nemo-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 04:53:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01438 for ; Thu, 26 Feb 2004 04:53:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwICu-0000fm-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 04:53:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwIC3-0000aj-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 04:52:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwIBc-0000V6-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 04:52:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIBV-0006Zz-Ko; Thu, 26 Feb 2004 04:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIAx-0006Xv-FR for nemo@optimus.ietf.org; Thu, 26 Feb 2004 04:51:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01322 for ; Thu, 26 Feb 2004 04:51:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwIAu-0000SX-00 for nemo@ietf.org; Thu, 26 Feb 2004 04:51:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwI9y-0000O1-00 for nemo@ietf.org; Thu, 26 Feb 2004 04:50:27 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AwI9R-0000Je-00 for nemo@ietf.org; Thu, 26 Feb 2004 04:49:53 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1Q9nrYG016330 for ; Thu, 26 Feb 2004 10:49:53 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Feb 2004 10:49:53 +0100 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FSMBW8XM; Thu, 26 Feb 2004 10:49:53 +0100 Message-ID: <403DC0A1.6010000@ericsson.com> Date: Thu, 26 Feb 2004 10:47:13 +0100 X-Sybari-Trust: 81537d22 c77f3eb6 6298249a 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: Thierry Ernst , cwng@psl.com.sg, eun@mmlab.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] merged multihoming draft References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2004 09:49:53.0328 (UTC) FILETIME=[E2254300:01C3FC4D] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: >>If there is no intermediate >>router, then at least the site exit routers cooperate. >> >>And this is not even a matter of multihoming to survive outages. The MNN >>won't be able to communicate unless it by luck selects the correct >>source address for the DR it has chosen. > > > This is also the case in any multihomed network, mobile or fixed, since > iwhen there are multiple prefixes available, it has to select the one that > matches with the ISP through which the packet will be carried. > > that is why i was asking why do you think that the multiple prefix case has > something NEMO specific. > > I would say that fixed multihoming solutions should deal with this case, > just as any other part of the Home Network, (which is actually the > multihomed network in this case, not the mobile network, as far as i can > see) Yes, sorry, for case N,1,N I fully agree. It is the home network that is multihomed and it will ultimately have to deal with this. The MRs can get away with their behaviour. > o (N,N,N) Mobile Network > > The (N,N,N) mobile network has multiple mobile routers, > registering to multiple home-agents and advertising prefixes. > This may be a case of multiple non-multihomed network superimposed > together, i.e. each mobile router take cares of one prefix, and > register to separate home agents. It is the N, N, N (alternative 1, see above) that I've drifted into. This is the case where NEMO introduces more requirements on hosts than what ND does. Look at this case from the MNN's point of view. It hears two routers (MRs) advertising themselves as capable of routing all traffic (i.e. stating that they are default routers). To follow the example in draft-huitema-multi6-hosts section 3.3 we have MNN as X with two addresses A:X and B:X. It wants to communicate with Y both available at C:Y and D:Y. If X can't be allowed to establish a communication between any of the four combinations {ax-cy, bx-cy, ax-dy, bx-dy} then something is seriously wrong with the configuration of the network. As far as X goes it MUST NOT have to know that site-exit router R-A only accepts packets with source address with prefix A. Why is a default router claiming that it can route all traffic only to drop some of it the next minute? None of the cases that I've seen in IPv6 and multi6 claim that X must select the correct default router in order to communicate. Yes, the packet must have the right source address to be carried over the ISP's network, but that is something the routers have to deal with. Yes, ISP B may be "better" in some sense (and sometimes routers only route on destination addresses, which is bad in this case), but unless X knows that, how can it know what source address to use for its default traffic? To me it is a serious mistake by a router to claim it is a default router if it really isn't. Until the hosts get more information about ISP preferences and ingress filtering policies, the router must deal with this mess. So, yes, to answer your question: NEMO case N,N,N introduces a (broken) network configuration previously unknown to/unsupported by IPv6 and multi6. /Mattias This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From nemo-admin@ietf.org Thu Feb 26 05:06:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01931 for ; Thu, 26 Feb 2004 05:06:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIP3-000807-B8; Thu, 26 Feb 2004 05:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIOT-0007yV-4D for nemo@optimus.ietf.org; Thu, 26 Feb 2004 05:05:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01896 for ; Thu, 26 Feb 2004 05:05:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwIOP-0001ku-00 for nemo@ietf.org; Thu, 26 Feb 2004 05:05:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwINV-0001hA-00 for nemo@ietf.org; Thu, 26 Feb 2004 05:04:26 -0500 Received: from mobqos.ee.unsw.edu.au ([129.94.230.70]) by ietf-mx with esmtp (Exim 4.12) id 1AwIN1-0001aW-00 for nemo@ietf.org; Thu, 26 Feb 2004 05:03:55 -0500 Received: from eranga (helo=localhost) by mobqos.ee.unsw.edu.au with local-esmtp (Exim 3.35 #1 (Debian)) id 1AwIMU-00027t-00; Thu, 26 Feb 2004 21:03:22 +1100 Date: Thu, 26 Feb 2004 21:03:21 +1100 (EST) From: Eranga Perera To: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano cc: nemo@ietf.org Subject: Re: [nemo] Visiting Nodes In-Reply-To: <1077784218.790.15.camel@acorde> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Carlos, Thanks for the reply. By visiting I mean nodes which belong to another network as opposed to local nodes. If we agree that there could be nodes that are not MIPv6 capable and also belongs to another network then shouldn't we witihn the NEMO group give emphasis to such nodes too. I believe that there is alot to do in order to enable mobility for such nodes in a NEMO setting. What do you think? Regrds, Eranga On Thu, 26 Feb 2004, Carlos [ISO-8859-1] Jes=FAs Bernardos Cano wrote: > Hi Eranga, > > =09All MNNs (Mobile Network Nodes) move with the mobile network, but not > all of them are "mobile nodes" (i.e. have MIPv6 support and can move > topologically with respect to the MR). Local Fixed Nodes (LFNs) are > nodes that belong to the mobile network and which do not move with > respect to the MR (like the node you pointed in your example). In the > other hand, there are nodes with mobility capabilities: Visiting Mobile > Nodes (VMNs) and Local Mobile Nodes (LMNs). Perhaps the term "visiting" > is not very clear and could lead to confusion, but IMHO it does not mean > that other nodes-with no mobility capabilities-could not visit a mobile > network (i.e. a node with portability-DHCPv6 support). > > =09Best regards, > > =09Carlos J. > > El jue, 26-02-2004 a las 07:01, Eranga Perera escribi=F3: > > Hi All, > > Would someone be able to clarify why is it that all visiting nodes to a > > mobile network are assumed to be mobile nodes? > > More precisely how about the nodes that belong to another network (not > > mobile network) but has no mobility capabilities? > > (scenario - commuter with a PDA with no mobility capabilities obtain > > connectivity via a MR deployed on a bus) > > > > Thankx in advance, > > Eranga > -- > Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ > GPG FP: 1880 80D3 8004 25C7 6537 8E02 252A D295 9CFF DEAF > From nemo-admin@ietf.org Thu Feb 26 06:18:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04844 for ; Thu, 26 Feb 2004 06:18:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJWj-0006DR-BX; Thu, 26 Feb 2004 06:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJWN-0006Cc-Dg for nemo@optimus.ietf.org; Thu, 26 Feb 2004 06:17:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04816 for ; Thu, 26 Feb 2004 06:17:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwJWJ-0000wz-00 for nemo@ietf.org; Thu, 26 Feb 2004 06:17:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwJVO-0000rI-00 for nemo@ietf.org; Thu, 26 Feb 2004 06:16:38 -0500 Received: from mobqos.ee.unsw.edu.au ([129.94.230.70]) by ietf-mx with esmtp (Exim 4.12) id 1AwJUh-0000fm-00 for nemo@ietf.org; Thu, 26 Feb 2004 06:15:55 -0500 Received: from eranga (helo=localhost) by mobqos.ee.unsw.edu.au with local-esmtp (Exim 3.35 #1 (Debian)) id 1AwJU6-0003Ap-00; Thu, 26 Feb 2004 22:15:18 +1100 Date: Thu, 26 Feb 2004 22:15:18 +1100 (EST) From: Eranga Perera To: nemo@ietf.org cc: mamalik@cse.unsw.edu.au, , , Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [nemo] Visiting Nodes 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, Thanks for the replies. Thought I'll express my humble opinion in one go! I agree with Maria and Pascal in the sense that if a commuter obtains connectivity via a MR then his/her device will be operating in a manner similar to a LFN. But shouldn't our objective be to enable these nodes to run any application not just browse the web. How about accessing VPNs? Alex, A non MIPv6 node sure enough would loose the connection when hopping from a bus to a train. But say for example a commuter needs to synchonize his calendar on his PDA with the PC in his office. If we assume that visiting nodes without MIPv6 capabilities are like LFNs then such applications cannot be supported unless we take care of the security issues. So isn't it necessary to give emphasis to visiting nodes without MIPv6 capabilities and try to solve these issues. Basically if these visiting nodes have permanent IP addresses then how does NEMO protocol handle such nodes - bidirectional tunneling via double Home Agents ? Or can we safely assume that all viising nodes will have MIPv6 capabilities and not address the above issues? Are all future devices going to be embeddded with MIPv6?? I guess this is a point to ponder! Sorry if I've misinterpreted something. Regards, Eranga From exim@www1.ietf.org Thu Feb 26 06:20:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04958 for ; Thu, 26 Feb 2004 06:20:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJYM-0006JN-Jv for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 06:19:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QBJgeX024257 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 06:19:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJYM-0006JA-9A for nemo-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 06:19:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04948 for ; Thu, 26 Feb 2004 06:19:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwJYI-0001AC-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 06:19:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwJXK-00013a-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 06:18:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwJWg-0000y8-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 06:17:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJWj-0006DR-BX; Thu, 26 Feb 2004 06:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJWN-0006Cc-Dg for nemo@optimus.ietf.org; Thu, 26 Feb 2004 06:17:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04816 for ; Thu, 26 Feb 2004 06:17:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwJWJ-0000wz-00 for nemo@ietf.org; Thu, 26 Feb 2004 06:17:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwJVO-0000rI-00 for nemo@ietf.org; Thu, 26 Feb 2004 06:16:38 -0500 Received: from mobqos.ee.unsw.edu.au ([129.94.230.70]) by ietf-mx with esmtp (Exim 4.12) id 1AwJUh-0000fm-00 for nemo@ietf.org; Thu, 26 Feb 2004 06:15:55 -0500 Received: from eranga (helo=localhost) by mobqos.ee.unsw.edu.au with local-esmtp (Exim 3.35 #1 (Debian)) id 1AwJU6-0003Ap-00; Thu, 26 Feb 2004 22:15:18 +1100 Date: Thu, 26 Feb 2004 22:15:18 +1100 (EST) From: Eranga Perera To: nemo@ietf.org cc: mamalik@cse.unsw.edu.au, , , Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [nemo] Visiting Nodes 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi, Thanks for the replies. Thought I'll express my humble opinion in one go! I agree with Maria and Pascal in the sense that if a commuter obtains connectivity via a MR then his/her device will be operating in a manner similar to a LFN. But shouldn't our objective be to enable these nodes to run any application not just browse the web. How about accessing VPNs? Alex, A non MIPv6 node sure enough would loose the connection when hopping from a bus to a train. But say for example a commuter needs to synchonize his calendar on his PDA with the PC in his office. If we assume that visiting nodes without MIPv6 capabilities are like LFNs then such applications cannot be supported unless we take care of the security issues. So isn't it necessary to give emphasis to visiting nodes without MIPv6 capabilities and try to solve these issues. Basically if these visiting nodes have permanent IP addresses then how does NEMO protocol handle such nodes - bidirectional tunneling via double Home Agents ? Or can we safely assume that all viising nodes will have MIPv6 capabilities and not address the above issues? Are all future devices going to be embeddded with MIPv6?? I guess this is a point to ponder! Sorry if I've misinterpreted something. Regards, Eranga From nemo-admin@ietf.org Thu Feb 26 08:14:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10255 for ; Thu, 26 Feb 2004 08:14:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLKy-0001A1-Uk; Thu, 26 Feb 2004 08:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLKs-00017C-HG for nemo@optimus.ietf.org; Thu, 26 Feb 2004 08:13:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10240 for ; Thu, 26 Feb 2004 08:13:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwLKr-0005c5-00 for nemo@ietf.org; Thu, 26 Feb 2004 08:13:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwLJy-0005VI-00 for nemo@ietf.org; Thu, 26 Feb 2004 08:12:58 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1AwLJ5-0005N5-00 for nemo@ietf.org; Thu, 26 Feb 2004 08:12:03 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1QDBqVD012847; Thu, 26 Feb 2004 22:11:52 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1QDBqEi004777; Thu, 26 Feb 2004 22:11:52 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1QDBpDU014099; Thu, 26 Feb 2004 22:11:51 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1QDBpVR014087; Thu, 26 Feb 2004 22:11:51 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1QDBo84019485; Thu, 26 Feb 2004 22:11:50 +0900 (JST) Received: from imd.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id WAA09378; Thu, 26 Feb 2004 22:11:50 +0900 (JST) Received: from [127.0.0.1] by imd.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id WAA26427; Thu, 26 Feb 2004 22:11:49 +0900 (JST) Date: Thu, 26 Feb 2004 22:13:32 +0900 From: Hiroyuki OHNISHI To: Mattias Pettersson Subject: Re: [nemo] [Fwd: I-D ACTION:draft-thubert-nemo-ro-taxonomy-02.txt] Cc: Chan-Wah NG , IETF NEMO WG In-Reply-To: <403CBFF0.8060008@ericsson.com> References: <1077688734.6799.59.camel@localhost> <403CBFF0.8060008@ericsson.com> Message-Id: <20040226220005.4564.OHNISHI.HIROYUKI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 am co-author of this draft. On Wed, 25 Feb 2004 16:32:00 +0100 Mattias Pettersson wrote: > > > Chan-Wah NG wrote: > > Hello, > > > > I didn't realize that Pascal did not forward this to the NEMO ML... or > > perhaps he did, but I couldn't find it in my own archive. So, there you > > guys go. Apologize if it is a duplicate. > > > > This draft gives an analysis of the possible RO Solution Space in NEMO. > > It is our intention (well, at least mine) that this draft be considered > > as a starting point for the RO Solution Space Analysis, which is a > > milestone in the WG charter. > > > > Comments are always welcome. > > > > Short comment: chapter 1-5 and 7 are very good and they reflect what we > now know and I agree on them. But chapter 6 is difficult to grasp and I > would prefer it to be more elaborate. Simply more text and an easier > level. Chapter 7 doesn't summarise anything from chapter 6, shouldn't it? > We need to brush-up Chapter 6 and Chapter 7(chapter 6 does not reflect to chapter 7 now as you mentioned). Current chapter 6 just shows some points that we think are important points to design solution for RO in nested NEMO. Do you have any point to add this Chapter? > /Mattias > > > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. > -- Hiroyuki OHNISHI NTT Network Service Systems Laboratories Phone: +81-422-59-4132, Fax: +81-422-60-7460 mailto: ohnishi.hiroyuki@lab.ntt.co.jp From exim@www1.ietf.org Thu Feb 26 08:17:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10410 for ; Thu, 26 Feb 2004 08:17:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLNQ-0001mN-D8 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 08:16:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QDGWl8006833 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 08:16:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLNQ-0001m8-7w for nemo-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 08:16:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10378 for ; Thu, 26 Feb 2004 08:16:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwLNP-00067Q-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 08:16:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwLM7-0005om-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 08:15:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwLL0-0005dh-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 08:14:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLKy-0001A1-Uk; Thu, 26 Feb 2004 08:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwLKs-00017C-HG for nemo@optimus.ietf.org; Thu, 26 Feb 2004 08:13:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10240 for ; Thu, 26 Feb 2004 08:13:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwLKr-0005c5-00 for nemo@ietf.org; Thu, 26 Feb 2004 08:13:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwLJy-0005VI-00 for nemo@ietf.org; Thu, 26 Feb 2004 08:12:58 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1AwLJ5-0005N5-00 for nemo@ietf.org; Thu, 26 Feb 2004 08:12:03 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1QDBqVD012847; Thu, 26 Feb 2004 22:11:52 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1QDBqEi004777; Thu, 26 Feb 2004 22:11:52 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1QDBpDU014099; Thu, 26 Feb 2004 22:11:51 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1QDBpVR014087; Thu, 26 Feb 2004 22:11:51 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i1QDBo84019485; Thu, 26 Feb 2004 22:11:50 +0900 (JST) Received: from imd.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id WAA09378; Thu, 26 Feb 2004 22:11:50 +0900 (JST) Received: from [127.0.0.1] by imd.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id WAA26427; Thu, 26 Feb 2004 22:11:49 +0900 (JST) Date: Thu, 26 Feb 2004 22:13:32 +0900 From: Hiroyuki OHNISHI To: Mattias Pettersson Subject: Re: [nemo] [Fwd: I-D ACTION:draft-thubert-nemo-ro-taxonomy-02.txt] Cc: Chan-Wah NG , IETF NEMO WG In-Reply-To: <403CBFF0.8060008@ericsson.com> References: <1077688734.6799.59.camel@localhost> <403CBFF0.8060008@ericsson.com> Message-Id: <20040226220005.4564.OHNISHI.HIROYUKI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I am co-author of this draft. On Wed, 25 Feb 2004 16:32:00 +0100 Mattias Pettersson wrote: > > > Chan-Wah NG wrote: > > Hello, > > > > I didn't realize that Pascal did not forward this to the NEMO ML... or > > perhaps he did, but I couldn't find it in my own archive. So, there you > > guys go. Apologize if it is a duplicate. > > > > This draft gives an analysis of the possible RO Solution Space in NEMO. > > It is our intention (well, at least mine) that this draft be considered > > as a starting point for the RO Solution Space Analysis, which is a > > milestone in the WG charter. > > > > Comments are always welcome. > > > > Short comment: chapter 1-5 and 7 are very good and they reflect what we > now know and I agree on them. But chapter 6 is difficult to grasp and I > would prefer it to be more elaborate. Simply more text and an easier > level. Chapter 7 doesn't summarise anything from chapter 6, shouldn't it? > We need to brush-up Chapter 6 and Chapter 7(chapter 6 does not reflect to chapter 7 now as you mentioned). Current chapter 6 just shows some points that we think are important points to design solution for RO in nested NEMO. Do you have any point to add this Chapter? > /Mattias > > > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. > -- Hiroyuki OHNISHI NTT Network Service Systems Laboratories Phone: +81-422-59-4132, Fax: +81-422-60-7460 mailto: ohnishi.hiroyuki@lab.ntt.co.jp From nemo-admin@ietf.org Thu Feb 26 09:05:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13822 for ; Thu, 26 Feb 2004 09:05:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwM8L-0006ON-U9; Thu, 26 Feb 2004 09:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwM7s-0006NR-Sh for nemo@optimus.ietf.org; Thu, 26 Feb 2004 09:04:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13785 for ; Thu, 26 Feb 2004 09:04:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwM7r-0004Yh-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:04:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwM6s-0004QO-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:03:31 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1AwM5w-0004Du-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:02:32 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6CFDAA90B; Thu, 26 Feb 2004 15:02:01 +0100 (CET) Received: from acorde.it.uc3m.es (acorde.it.uc3m.es [163.117.139.72]) by smtp01.uc3m.es (Postfix) with ESMTP id 57E3AA904; Thu, 26 Feb 2004 15:02:01 +0100 (CET) Subject: Re: [nemo] Visiting Nodes From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Eranga Perera Cc: nemo@ietf.org In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-eRa04oOwUAZOw+bxV4uv" Organization: Universidad Carlos III de Madrid Message-Id: <1077804121.823.22.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 26 Feb 2004 15:02:01 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , --=-eRa04oOwUAZOw+bxV4uv Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Eranga, El jue, 26-02-2004 a las 11:03, Eranga Perera escribi=F3: > Hi Carlos, > Thanks for the reply. By visiting I mean nodes which belong to another > network as opposed to local nodes. If we agree that there could be nodes > that are not MIPv6 capable and also belongs to another network then > shouldn't we witihn the NEMO group give emphasis to such nodes too. I > believe that there is alot to do in order to enable mobility for such > nodes in a NEMO setting. What do you think? I agree with Alexandru that there is no difference, from the NEMO point of view, between a LFN belonging to the mobile network and other node belonging to a different network, that attaches to the mobile network. This node, due to its lack of mobility support can not preserve previous established communications (transparent mobility support), but by using mechanisms like DHCPv6 or IPv6 stateless autoconfiguration, it is able to gain connectivity in the new location at the visited mobile network (portability). Once this node is attached to the mobile network, it is treated like a LFN from the point of view of NEMO support mechanisms and it will preserve communications despite possible mobile network movements. On the other hand, IMHO it is very interesting the topic of practical usage scenarios in which network mobility could be involved. I mean, what is more likely to occur, nodes with ongoing communications that enters in a train or nodes that enter in a train and start browsing the Internet, for example? Best regards, Carlos J. > Regrds, > Eranga >=20 > On Thu, 26 Feb 2004, Carlos [ISO-8859-1] Jess Bernardos Cano wrote: >=20 > > Hi Eranga, > > > > All MNNs (Mobile Network Nodes) move with the mobile network, but not > > all of them are "mobile nodes" (i.e. have MIPv6 support and can move > > topologically with respect to the MR). Local Fixed Nodes (LFNs) are > > nodes that belong to the mobile network and which do not move with > > respect to the MR (like the node you pointed in your example). In the > > other hand, there are nodes with mobility capabilities: Visiting Mobile > > Nodes (VMNs) and Local Mobile Nodes (LMNs). Perhaps the term "visiting" > > is not very clear and could lead to confusion, but IMHO it does not mea= n > > that other nodes-with no mobility capabilities-could not visit a mobile > > network (i.e. a node with portability-DHCPv6 support). > > > > Best regards, > > > > Carlos J. > > > > El jue, 26-02-2004 a las 07:01, Eranga Perera escribi: > > > Hi All, > > > Would someone be able to clarify why is it that all visiting nodes to= a > > > mobile network are assumed to be mobile nodes? > > > More precisely how about the nodes that belong to another network (no= t > > > mobile network) but has no mobility capabilities? > > > (scenario - commuter with a PDA with no mobility capabilities obtain > > > connectivity via a MR deployed on a bus) > > > > > > Thankx in advance, > > > Eranga > > -- > > Carlos Jess Bernardos Cano - http://www.it.uc3m.es/cjbc/ > > GPG FP: 1880 80D3 8004 25C7 6537 8E02 252A D295 9CFF DEAF > > --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 1880 80D3 8004 25C7 6537 8E02 252A D295 9CFF DEAF --=-eRa04oOwUAZOw+bxV4uv Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAPfxYJSrSlZz/3q8RAlTTAKCoKPw9FoCHyc9GzVh5R01lON7ZRgCeKtjD Qr9SeL+k12gw4N6rdoRpf94= =Hs2d -----END PGP SIGNATURE----- --=-eRa04oOwUAZOw+bxV4uv-- From exim@www1.ietf.org Thu Feb 26 09:22:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14649 for ; Thu, 26 Feb 2004 09:22:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMOZ-0008LS-LS for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 09:21:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QELloo032077 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 09:21:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMOZ-0008LA-6s for nemo-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 09:21:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14547 for ; Thu, 26 Feb 2004 09:21:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMOX-0006IH-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 09:21:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMNK-00061N-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 09:20:31 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AwMM9-0005nt-04 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 09:19:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AwM8Y-0005fo-6H for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 09:05:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwM8L-0006ON-U9; Thu, 26 Feb 2004 09:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwM7s-0006NR-Sh for nemo@optimus.ietf.org; Thu, 26 Feb 2004 09:04:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13785 for ; Thu, 26 Feb 2004 09:04:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwM7r-0004Yh-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:04:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwM6s-0004QO-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:03:31 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1AwM5w-0004Du-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:02:32 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6CFDAA90B; Thu, 26 Feb 2004 15:02:01 +0100 (CET) Received: from acorde.it.uc3m.es (acorde.it.uc3m.es [163.117.139.72]) by smtp01.uc3m.es (Postfix) with ESMTP id 57E3AA904; Thu, 26 Feb 2004 15:02:01 +0100 (CET) Subject: Re: [nemo] Visiting Nodes From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Eranga Perera Cc: nemo@ietf.org In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-eRa04oOwUAZOw+bxV4uv" Organization: Universidad Carlos III de Madrid Message-Id: <1077804121.823.22.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 26 Feb 2004 15:02:01 +0100 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --=-eRa04oOwUAZOw+bxV4uv Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Eranga, El jue, 26-02-2004 a las 11:03, Eranga Perera escribi=F3: > Hi Carlos, > Thanks for the reply. By visiting I mean nodes which belong to another > network as opposed to local nodes. If we agree that there could be nodes > that are not MIPv6 capable and also belongs to another network then > shouldn't we witihn the NEMO group give emphasis to such nodes too. I > believe that there is alot to do in order to enable mobility for such > nodes in a NEMO setting. What do you think? I agree with Alexandru that there is no difference, from the NEMO point of view, between a LFN belonging to the mobile network and other node belonging to a different network, that attaches to the mobile network. This node, due to its lack of mobility support can not preserve previous established communications (transparent mobility support), but by using mechanisms like DHCPv6 or IPv6 stateless autoconfiguration, it is able to gain connectivity in the new location at the visited mobile network (portability). Once this node is attached to the mobile network, it is treated like a LFN from the point of view of NEMO support mechanisms and it will preserve communications despite possible mobile network movements. On the other hand, IMHO it is very interesting the topic of practical usage scenarios in which network mobility could be involved. I mean, what is more likely to occur, nodes with ongoing communications that enters in a train or nodes that enter in a train and start browsing the Internet, for example? Best regards, Carlos J. > Regrds, > Eranga >=20 > On Thu, 26 Feb 2004, Carlos [ISO-8859-1] Jess Bernardos Cano wrote: >=20 > > Hi Eranga, > > > > All MNNs (Mobile Network Nodes) move with the mobile network, but not > > all of them are "mobile nodes" (i.e. have MIPv6 support and can move > > topologically with respect to the MR). Local Fixed Nodes (LFNs) are > > nodes that belong to the mobile network and which do not move with > > respect to the MR (like the node you pointed in your example). In the > > other hand, there are nodes with mobility capabilities: Visiting Mobile > > Nodes (VMNs) and Local Mobile Nodes (LMNs). Perhaps the term "visiting" > > is not very clear and could lead to confusion, but IMHO it does not mea= n > > that other nodes-with no mobility capabilities-could not visit a mobile > > network (i.e. a node with portability-DHCPv6 support). > > > > Best regards, > > > > Carlos J. > > > > El jue, 26-02-2004 a las 07:01, Eranga Perera escribi: > > > Hi All, > > > Would someone be able to clarify why is it that all visiting nodes to= a > > > mobile network are assumed to be mobile nodes? > > > More precisely how about the nodes that belong to another network (no= t > > > mobile network) but has no mobility capabilities? > > > (scenario - commuter with a PDA with no mobility capabilities obtain > > > connectivity via a MR deployed on a bus) > > > > > > Thankx in advance, > > > Eranga > > -- > > Carlos Jess Bernardos Cano - http://www.it.uc3m.es/cjbc/ > > GPG FP: 1880 80D3 8004 25C7 6537 8E02 252A D295 9CFF DEAF > > --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 1880 80D3 8004 25C7 6537 8E02 252A D295 9CFF DEAF --=-eRa04oOwUAZOw+bxV4uv Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAPfxYJSrSlZz/3q8RAlTTAKCoKPw9FoCHyc9GzVh5R01lON7ZRgCeKtjD Qr9SeL+k12gw4N6rdoRpf94= =Hs2d -----END PGP SIGNATURE----- --=-eRa04oOwUAZOw+bxV4uv-- From nemo-admin@ietf.org Thu Feb 26 09:41:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15864 for ; Thu, 26 Feb 2004 09:41:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMhC-0001oa-GQ; Thu, 26 Feb 2004 09:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMgl-0001mt-P2 for nemo@optimus.ietf.org; Thu, 26 Feb 2004 09:40:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15781 for ; Thu, 26 Feb 2004 09:40:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMgj-0000Xg-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:40:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMfq-0000Sl-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:39:38 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AwMf6-0000JT-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:38:52 -0500 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1QEbJ0e003660; Thu, 26 Feb 2004 15:37:21 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Feb 2004 14:37:47 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Visiting Nodes Date: Thu, 26 Feb 2004 14:37:47 -0000 Message-ID: Thread-Topic: [nemo] Visiting Nodes Thread-Index: AcP8ccYtGxUg+NbtTIyIJUg0JaHrBQAAmvAg From: "Pascal Thubert (pthubert)" To: =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= , "Eranga Perera" Cc: X-OriginalArrivalTime: 26 Feb 2004 14:37:47.0929 (UTC) FILETIME=[1A9C3090:01C3FC76] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 >=20 > On the other hand, IMHO it is very interesting the topic of practical > usage scenarios in which network mobility could be involved. I mean, > what is more likely to occur, nodes with ongoing communications that > enters in a train or nodes that enter in a train and start browsing = the > Internet, for example? Interesting question.=20 I think it's the chicken and the egg problem... The usage of the web is = mostly a pull model because of limitations of IPv4, NAT and so on, not = because it's the best way to do things. There's a lot of P2P = applications that would benefit from a direct and always on = connectivity. You can not just say that the next killer applications = will be a pull model just because that was the only way in the past... If your visitor has a few presence based apps (or some proprietary = Instant Messaging for that matter), he will have to reconnect to the = each and every one of those apps each time he moves to a different bus. = Lots of traffic, very low value. I wonder how many such users the IM can = sustain. If he supports IP mobility and registers to IM using a Home = Address, that's a different story. Also, this preserves the privacy of = the location of the user. Pascal From exim@www1.ietf.org Thu Feb 26 09:43:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15956 for ; Thu, 26 Feb 2004 09:43:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMit-00028u-0T for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 09:42:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QEgkqH008230 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 09:42:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMis-00028f-NC for nemo-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 09:42:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15925 for ; Thu, 26 Feb 2004 09:42:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMiq-0000lT-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 09:42:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMhz-0000fy-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 09:41:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwMhO-0000Zn-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 09:41:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMhC-0001oa-GQ; Thu, 26 Feb 2004 09:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMgl-0001mt-P2 for nemo@optimus.ietf.org; Thu, 26 Feb 2004 09:40:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15781 for ; Thu, 26 Feb 2004 09:40:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMgj-0000Xg-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:40:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMfq-0000Sl-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:39:38 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AwMf6-0000JT-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:38:52 -0500 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1QEbJ0e003660; Thu, 26 Feb 2004 15:37:21 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Feb 2004 14:37:47 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Visiting Nodes Date: Thu, 26 Feb 2004 14:37:47 -0000 Message-ID: Thread-Topic: [nemo] Visiting Nodes Thread-Index: AcP8ccYtGxUg+NbtTIyIJUg0JaHrBQAAmvAg From: "Pascal Thubert (pthubert)" To: =?iso-8859-1?Q?Carlos_Jes=FAs_Bernardos_Cano?= , "Eranga Perera" Cc: X-OriginalArrivalTime: 26 Feb 2004 14:37:47.0929 (UTC) FILETIME=[1A9C3090:01C3FC76] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > On the other hand, IMHO it is very interesting the topic of practical > usage scenarios in which network mobility could be involved. I mean, > what is more likely to occur, nodes with ongoing communications that > enters in a train or nodes that enter in a train and start browsing = the > Internet, for example? Interesting question.=20 I think it's the chicken and the egg problem... The usage of the web is = mostly a pull model because of limitations of IPv4, NAT and so on, not = because it's the best way to do things. There's a lot of P2P = applications that would benefit from a direct and always on = connectivity. You can not just say that the next killer applications = will be a pull model just because that was the only way in the past... If your visitor has a few presence based apps (or some proprietary = Instant Messaging for that matter), he will have to reconnect to the = each and every one of those apps each time he moves to a different bus. = Lots of traffic, very low value. I wonder how many such users the IM can = sustain. If he supports IP mobility and registers to IM using a Home = Address, that's a different story. Also, this preserves the privacy of = the location of the user. Pascal From nemo-admin@ietf.org Thu Feb 26 09:52:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16525 for ; Thu, 26 Feb 2004 09:52:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMrq-0002qC-6Z; Thu, 26 Feb 2004 09:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMlb-0002Ks-15 for nemo@optimus.ietf.org; Thu, 26 Feb 2004 09:45:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16103 for ; Thu, 26 Feb 2004 09:45:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMlZ-00013Z-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:45:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMke-0000x5-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:44:37 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AwMjk-0000r5-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:43:40 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1QEhdqY016240 for ; Thu, 26 Feb 2004 15:43:39 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Feb 2004 15:43:39 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Feb 2004 15:43:58 +0100 Message-ID: From: =?iso-8859-1?Q?Mikl=F3s_Aur=E9l_R=F3nai_=28IJ/ETH=29?= To: =?iso-8859-1?Q?=27Carlos_Jes=FAs_Bernardos_Cano=27?= , Eranga Perera Cc: nemo@ietf.org Subject: RE: [nemo] Visiting Nodes Date: Thu, 26 Feb 2004 15:47:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 26 Feb 2004 14:43:39.0233 (UTC) FILETIME=[EC00ED10:01C3FC76] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Carlos, I would like to reflect shortly on the paragraph below. > On the other hand, IMHO it is very interesting the > topic of practical usage scenarios in which network mobility > could be involved. I mean, what is more likely to occur, > nodes with ongoing communications that enters in a train or > nodes that enter in a train and start browsing the Internet, > for example? I think that the scenario where people enter a train and starts web browsing is more likely today ... but tomorrow where we will be able to make video conferences with our handhelds it will be more typical that we enter the metro or the train with ongoing communications. I am afraid that DHCPv6 or IPv6 stateless autoconfiguration are not able to handle movements of mobile nodes with ongoing transmissions. /Miklos This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From exim@www1.ietf.org Thu Feb 26 09:54:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16778 for ; Thu, 26 Feb 2004 09:54:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMtl-0003Ij-GY for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 09:54:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QEs1mT012680 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 09:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMtl-0003II-01 for nemo-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 09:54:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16741 for ; Thu, 26 Feb 2004 09:53:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMti-00029v-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 09:53:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMsy-00020P-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 09:53:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwMrs-0001pC-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 09:52:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMrq-0002qC-6Z; Thu, 26 Feb 2004 09:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMlb-0002Ks-15 for nemo@optimus.ietf.org; Thu, 26 Feb 2004 09:45:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16103 for ; Thu, 26 Feb 2004 09:45:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMlZ-00013Z-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:45:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMke-0000x5-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:44:37 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AwMjk-0000r5-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:43:40 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1QEhdqY016240 for ; Thu, 26 Feb 2004 15:43:39 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Feb 2004 15:43:39 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 26 Feb 2004 15:43:58 +0100 Message-ID: From: =?iso-8859-1?Q?Mikl=F3s_Aur=E9l_R=F3nai_=28IJ/ETH=29?= To: =?iso-8859-1?Q?=27Carlos_Jes=FAs_Bernardos_Cano=27?= , Eranga Perera Cc: nemo@ietf.org Subject: RE: [nemo] Visiting Nodes Date: Thu, 26 Feb 2004 15:47:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 26 Feb 2004 14:43:39.0233 (UTC) FILETIME=[EC00ED10:01C3FC76] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Carlos, I would like to reflect shortly on the paragraph below. > On the other hand, IMHO it is very interesting the > topic of practical usage scenarios in which network mobility > could be involved. I mean, what is more likely to occur, > nodes with ongoing communications that enters in a train or > nodes that enter in a train and start browsing the Internet, > for example? I think that the scenario where people enter a train and starts web browsing is more likely today ... but tomorrow where we will be able to make video conferences with our handhelds it will be more typical that we enter the metro or the train with ongoing communications. I am afraid that DHCPv6 or IPv6 stateless autoconfiguration are not able to handle movements of mobile nodes with ongoing transmissions. /Miklos This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From nemo-admin@ietf.org Thu Feb 26 10:00:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17246 for ; Thu, 26 Feb 2004 10:00:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMzZ-00046x-EA; Thu, 26 Feb 2004 10:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMz9-00044r-BK for nemo@optimus.ietf.org; Thu, 26 Feb 2004 09:59:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17189 for ; Thu, 26 Feb 2004 09:59:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMz7-0002xB-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:59:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMyB-0002pm-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:58:35 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AwMxG-0002dV-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:57:38 -0500 Received: from localhost.localdomain (unknown [147.46.252.130]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 98F385D288; Thu, 26 Feb 2004 23:56:20 +0900 (JST) Date: Thu, 26 Feb 2004 17:44:36 +0900 From: Thierry Ernst To: Mattias Pettersson Cc: nemo Subject: Re: [nemo] merged multihoming draft Message-Id: <20040226174436.2d0edbd9.ernst@sfc.wide.ad.jp> In-Reply-To: <403B4083.5080501@ericsson.com> References: <20040223004618.A48134@mmlab.snu.ac.kr> <1077504292.5628.45.camel@localhost> <20040223153820.10f6a14c.ernst@sfc.wide.ad.jp> <403B4083.5080501@ericsson.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=DATE_IN_PAST_06_12 autolearn=no version=2.60 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 > > o (N,1,N) Mobile Network > > > > The (N,1,N) mobile network has multiple active egress mobile > > routers registering to the same home-agent, and advertising > > multiple prefixes. If a mobile router is advertising more than one > > prefix, we have the same problem as (1,1,N) as in how to register > > more than one NEMO-prefix to the same home-agent. > > > > On the other hand, if each mobile router take cares of a separate > > (and only one) NEMO-prefix, then there should not be any > > NEMO-specific problem. > > As I remember Erik once said to me in an earlier NEMO discussion: we > don't want to go down the second alternative. MRs should not advertise > different prefixes to the same link - they must advertise the same > prefix set (or otherwise be coordinated and able to route traffic on > behalf of each other). For an MNN, each MR is a just default router and > all default routers must be able to route all traffic. We don't want to > put such requirements on the MNNs to map each prefix to a specific exit > router and remembering to use the correct source address when sending to > a specific default router. Just one more detail: the fact that multiple prefixes are advertised on the mobile network's egreess interface doesn't preclude that multiple NEMO-prefixes will be advertised down the mobile network. So, I guess there are several interpretations of this case. The sentence starting with 'since ...' in section 2.6 should be clarified (probably adding 'may be advertised'. Not allowing to advertise multiple prefixes may be one recommendation, but then, it means we have to design a protocol to synchronize MRs. On the other hand, if we allow the advertisement of multiple NEMO-prefixes, MNNs have to select their source address. What I said is of course orthogonal with multiple NEMO-prefix registration with the HA. > Such a general host behaviour may be required for multihoming to work in > IPv6 some day, but we have not reached that point yet. Thierry From nemo-admin@ietf.org Thu Feb 26 10:00:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17295 for ; Thu, 26 Feb 2004 10:00:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMzg-0004Gf-Gg; Thu, 26 Feb 2004 10:00:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMzP-00045V-5V for nemo@optimus.ietf.org; Thu, 26 Feb 2004 09:59:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17204 for ; Thu, 26 Feb 2004 09:59:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMzN-0002yo-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:59:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMyN-0002ro-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:58:48 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AwMxZ-0002de-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:57:57 -0500 Received: from localhost.localdomain (unknown [147.46.252.130]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 106455D28D; Thu, 26 Feb 2004 23:56:22 +0900 (JST) Date: Thu, 26 Feb 2004 18:00:43 +0900 From: Thierry Ernst To: Cc: mattias.l.pettersson@ericsson.com, cwng@psl.com.sg, eun@mmlab.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] merged multihoming draft Message-Id: <20040226180043.572c3fc1.ernst@sfc.wide.ad.jp> In-Reply-To: References: <403C6A63.50401@ericsson.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 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, > > It is a question on what entities should carry out the dirty work. > > Either the MRs or the MNNs. > > Perhaps in the case of multiple prefixes, the dirty work has to be carried > by the Home Network Site Exit routers? Can we be more specific with 'dirty work' ? > > To me it is important that legacy IPv6 hosts can still get connectivity > > in a moving network without having to implement new proposals such as > > draft-huitema-multi6-hosts-xx. > > Fully agree with the first statement. > But Host centric (draft-huitema-multi6-hosts) approach allows exactly this > for multihomed network. > > That is, that a regular IPv6 host is connected to the multihomed network and > still works properly. > Clearly, there some benefits, like preserving established communications > through outages, that it will not be able to obtain, but at least it will > work fine and its operation won't be disturbed because of multihoming. > > > > > So what is most important: to support standard IPv6 hosts or to simplify > > the MR? > > I fully agree that standard IPv6 have to keep on working properly. > Perhaps they won't obtain all the multihoming benefits, though > > > It seems like in order to simplify the MR we are proposing to > > introduce a NEMO scenario that was considered "broken" in the IPv6 WG > > earlier. All routers on a link are equal, from the host's point of view! > > Well, again this IMHO is generic to multihoming and not specific to nemo. > I guess that if a hosts has to be updated to obtain full multihoming > benefits in a fixed network, it would be reasonable that it also has to be > updated in order to obtain multihoming benefits in nemo. Fully agree. What is specific to NEMO WG is the ability to register several NEMO-prefixes with the HA, if we need to. Obtaining all potential benefits of multihoming is not a NEMO task. It should be carried on by another WG which doesn't focus on mobility. On the other hand, our goal is to document the issues; I suspect actions will have been taken by other WGs based on the conclusions of the NEMO Multihoming Pb Statement WG document. Thierry. From nemo-admin@ietf.org Thu Feb 26 10:00:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17318 for ; Thu, 26 Feb 2004 10:00:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMzj-0004Hd-OD; Thu, 26 Feb 2004 10:00:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMzR-00045j-Tq for nemo@optimus.ietf.org; Thu, 26 Feb 2004 09:59:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17213 for ; Thu, 26 Feb 2004 09:59:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMzP-0002z9-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:59:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMyR-0002sW-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:58:52 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AwMxc-0002dl-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:58:00 -0500 Received: from localhost.localdomain (unknown [147.46.252.130]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id D88555D28E; Thu, 26 Feb 2004 23:56:22 +0900 (JST) Date: Thu, 26 Feb 2004 18:05:57 +0900 From: Thierry Ernst To: Cc: nemo@ietf.org Subject: Re: [nemo] merged multihoming draft Message-Id: <20040226180557.37e4571d.ernst@sfc.wide.ad.jp> In-Reply-To: References: <403B4083.5080501@ericsson.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 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 an additional question about this draft: > > Why do you consider that a mobile network that has several prefixes is > multihomed. > I mean, i would say that a natural case for this is that the Home network is > multihomed, but not really the Mobile Network. > In this case, i guess that there is nothing NEMO specific, only that general > multi6 solutions have to be supported. > > Am i missing something? ( i haven't been around for long, so i have missed > previous discussions on this topic) Hi Marcelo, This is may be a definition issue ? I agree that taking the definition to the words may tell that any host in the Internet is multihomed since border routers usually are. I would indeed say that the MRs might be multihoming, but the MNNs might not be. I would appreciate if you could read through the multihoming section in draft-ietf-nemo-terminology and comment on the definition. That would be helpful for us. Thierry. From nemo-admin@ietf.org Thu Feb 26 10:18:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19121 for ; Thu, 26 Feb 2004 10:18:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwNGy-000384-O9; Thu, 26 Feb 2004 10:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwNGf-00031V-9G for nemo@optimus.ietf.org; Thu, 26 Feb 2004 10:17:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19037 for ; Thu, 26 Feb 2004 10:17:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwNGc-0005Hn-00 for nemo@ietf.org; Thu, 26 Feb 2004 10:17:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwNFo-0005DB-00 for nemo@ietf.org; Thu, 26 Feb 2004 10:16:49 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AwNFC-00055U-00 for nemo@ietf.org; Thu, 26 Feb 2004 10:16:10 -0500 Received: from localhost.localdomain (unknown [147.46.252.130]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 328575D22F for ; Fri, 27 Feb 2004 00:15:39 +0900 (JST) Date: Fri, 27 Feb 2004 00:16:26 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] NEMO Agenda Message-Id: <20040227001626.46f7226d.ernst@sfc.wide.ad.jp> In-Reply-To: <1077765100.5422.30.camel@localhost> References: <20040224234612.05cc7fe8.ernst@sfc.wide.ad.jp> <1077765100.5422.30.camel@localhost> Organization: Keio University X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 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 Chan-Wah NG wrote: > > o NEMO Terminology Upates .................................. 10 mins > > Thierry Ernst > > > > To be read: > > ~~~~~~~~~~~ > > Network Mobility Support Terminology > > http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-01.txt > > > > To be discussed: > > ~~~~~~~~~~~~~~~~ > > - document should go to last call > > - do we keep the multihoming and 'nested + multihoming' examples > > within this document ? > > Alternatives is to move it to the soon to appear > draft-ietf-nemo-multihoming-xxx. That could be possible, depending on the term I think. Need to be discussed. > > Pardon me for doing a bit of self-advertising, but you may have missed > one more expired draft on RO: > > - draft-ng-nemo-access-router-option-00.txt (expired) > Securing Nested Tunnel Optimizations with Access Router Option > http://www.psl.com.sg/draft-ng-nemo-access-router-option-00.txt > Oct 2002 Do you really think I don't have other things to do than looking that far ? :-) Thierry. From exim@www1.ietf.org Thu Feb 26 10:20:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19280 for ; Thu, 26 Feb 2004 10:20:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwNIb-0003rx-J6 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 10:19:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QFJfNi014872 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 10:19:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwNIb-0003rn-Bk for nemo-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 10:19:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19257 for ; Thu, 26 Feb 2004 10:19:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwNIZ-0005TG-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 10:19:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwNHg-0005OB-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 10:18:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwNH5-0005J6-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 10:18:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwNGy-000384-O9; Thu, 26 Feb 2004 10:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwNGf-00031V-9G for nemo@optimus.ietf.org; Thu, 26 Feb 2004 10:17:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19037 for ; Thu, 26 Feb 2004 10:17:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwNGc-0005Hn-00 for nemo@ietf.org; Thu, 26 Feb 2004 10:17:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwNFo-0005DB-00 for nemo@ietf.org; Thu, 26 Feb 2004 10:16:49 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AwNFC-00055U-00 for nemo@ietf.org; Thu, 26 Feb 2004 10:16:10 -0500 Received: from localhost.localdomain (unknown [147.46.252.130]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 328575D22F for ; Fri, 27 Feb 2004 00:15:39 +0900 (JST) Date: Fri, 27 Feb 2004 00:16:26 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] NEMO Agenda Message-Id: <20040227001626.46f7226d.ernst@sfc.wide.ad.jp> In-Reply-To: <1077765100.5422.30.camel@localhost> References: <20040224234612.05cc7fe8.ernst@sfc.wide.ad.jp> <1077765100.5422.30.camel@localhost> Organization: Keio University X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386-redhat-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chan-Wah NG wrote: > > o NEMO Terminology Upates .................................. 10 mins > > Thierry Ernst > > > > To be read: > > ~~~~~~~~~~~ > > Network Mobility Support Terminology > > http://www.ietf.org/internet-drafts/draft-ietf-nemo-terminology-01.txt > > > > To be discussed: > > ~~~~~~~~~~~~~~~~ > > - document should go to last call > > - do we keep the multihoming and 'nested + multihoming' examples > > within this document ? > > Alternatives is to move it to the soon to appear > draft-ietf-nemo-multihoming-xxx. That could be possible, depending on the term I think. Need to be discussed. > > Pardon me for doing a bit of self-advertising, but you may have missed > one more expired draft on RO: > > - draft-ng-nemo-access-router-option-00.txt (expired) > Securing Nested Tunnel Optimizations with Access Router Option > http://www.psl.com.sg/draft-ng-nemo-access-router-option-00.txt > Oct 2002 Do you really think I don't have other things to do than looking that far ? :-) Thierry. From nemo-admin@ietf.org Thu Feb 26 10:46:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17247 for ; Thu, 26 Feb 2004 10:00:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMzb-00047d-KS; Thu, 26 Feb 2004 10:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMzG-000451-T2 for nemo@optimus.ietf.org; Thu, 26 Feb 2004 09:59:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17195 for ; Thu, 26 Feb 2004 09:59:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMzE-0002yJ-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:59:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMyI-0002qy-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:58:43 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AwMxS-0002db-00 for nemo@ietf.org; Thu, 26 Feb 2004 09:57:51 -0500 Received: from localhost.localdomain (unknown [147.46.252.130]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 4854F5D28A; Thu, 26 Feb 2004 23:56:21 +0900 (JST) Date: Thu, 26 Feb 2004 17:52:59 +0900 From: Thierry Ernst To: Mattias Pettersson Cc: cwng@psl.com.sg, eun@mmlab.snu.ac.kr, nemo@ietf.org Subject: Re: [nemo] merged multihoming draft Message-Id: <20040226175259.10846d05.ernst@sfc.wide.ad.jp> In-Reply-To: <403C6A63.50401@ericsson.com> References: <20040223004618.A48134@mmlab.snu.ac.kr> <1077504292.5628.45.camel@localhost> <20040223153820.10f6a14c.ernst@sfc.wide.ad.jp> <403B4083.5080501@ericsson.com> <20040225143439.29254724.ernst@sfc.wide.ad.jp> <403C6A63.50401@ericsson.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=DATE_IN_PAST_06_12 autolearn=no version=2.60 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 Mattias, > >>> o (N,1,N) Mobile Network > Thierry, Chan-Wah [I answer you both here], > > It is a question on what entities should carry out the dirty work. > Either the MRs or the MNNs. It's not the same dirty work. On the MR, it's about registering several prefixes, or synchronisation On the MNN, it's about source address selection. Any host is considered to implement some source address selection mechanism. Or, is there anything else dirty to do ? > To me it is important that legacy IPv6 hosts can still get connectivity > in a moving network without having to implement new proposals such as > draft-huitema-multi6-hosts-xx. > > So what is most important: to support standard IPv6 hosts or to simplify > the MR? It seems like in order to simplify the MR we are proposing to > introduce a NEMO scenario that was considered "broken" in the IPv6 WG > earlier. All routers on a link are equal, from the host's point of view! > The ND model builds on that. I agree that we have arguments both in NEMO > and in multi6 to question that model, but we do we want to change that > model just to allow a variant of a scenario? I personaly wish to support standard IPv6 hosts. But I've never heard that advertising multiple prefixes would break the model. Do you have any reference to a possible decision made by the IPv6 WG to disallow such scenario ? Any document where this is documented ? Thierry From nemo-admin@ietf.org Thu Feb 26 10:50:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21026 for ; Thu, 26 Feb 2004 10:50:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwNlz-00075Y-87; Thu, 26 Feb 2004 10:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwNld-00072d-0M for nemo@optimus.ietf.org; Thu, 26 Feb 2004 10:49:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20984 for ; Thu, 26 Feb 2004 10:49:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwNla-0001Wh-00 for nemo@ietf.org; Thu, 26 Feb 2004 10:49:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwNkb-0001PS-00 for nemo@ietf.org; Thu, 26 Feb 2004 10:48:38 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AwNjc-0001Dw-00 for nemo@ietf.org; Thu, 26 Feb 2004 10:47:36 -0500 Received: from localhost.localdomain (unknown [147.46.252.130]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id A00445D0B5; Fri, 27 Feb 2004 00:46:37 +0900 (JST) Date: Fri, 27 Feb 2004 00:47:25 +0900 From: Thierry Ernst To: Eranga Perera Cc: nemo@ietf.org Subject: Re: [nemo] Visiting Nodes Message-Id: <20040227004725.7ed89dc1.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 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, What you are talking about it a LFN. It gets an address in the mobile network via DHCPv6 or anything, and then communicates with its peers using this address. I don't see what would prevent this node to run any kind of application. As pointed out by Pascal and Alex, it's just not efficient to do so as it breaks the connections and you need to restart them when getting in the mobile network. So, either you use some mobility support mechanims such as MIPv6 and your PDA is a VMN, or you restart the applications and its a LFN from a definition point of view and from the point of view of the MR. The PDA may need to authenticate itself first, but this is another story orthogonal to NEMO and mobility at large. Thierry. > Thanks for the replies. Thought I'll express my humble opinion in one go! > > I agree with Maria and Pascal in the sense that if a commuter obtains > connectivity via a MR then his/her device will be operating in a manner > similar to a LFN. But shouldn't our objective be to enable these nodes to > run any application not just browse the web. How about accessing VPNs? > > Alex, > A non MIPv6 node sure enough would loose the connection when hopping from > a bus to a train. But say for example a commuter needs to synchonize his > calendar on his PDA with the PC in his office. If we assume that visiting > nodes without MIPv6 capabilities are like LFNs then such applications > cannot be supported unless we take care of the security issues. So isn't > it necessary to give emphasis to visiting nodes without MIPv6 capabilities > and try to solve these issues. Basically if these visiting nodes have > permanent IP addresses then how does NEMO protocol handle such nodes - > bidirectional tunneling via double Home Agents ? > > Or can we safely assume that all viising nodes will have MIPv6 > capabilities and not address the above issues? Are all future devices > going to be embeddded with MIPv6?? I guess this is a point to ponder! > > Sorry if I've misinterpreted something. > > Regards, > Eranga > > > -- Thierry Ernst, PhD WIDE at Keio University, Japan IETF NEMO WG co-chair http://www.ietf.org/html.charters/nemo-charter.html WIDE NAUTILUS WG co-chair http://www.nautilus6.org -- 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 Feb 26 10:53:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21128 for ; Thu, 26 Feb 2004 10:53:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwNoZ-0007K9-LE for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 10:52:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QFqhXO028147 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 10:52:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwNoY-0007Ju-Q1 for nemo-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 10:52:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21106 for ; Thu, 26 Feb 2004 10:52:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwNoW-0001nz-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 10:52:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwNmp-0001fH-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 10:50:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwNm9-0001ZU-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 10:50:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwNlz-00075Y-87; Thu, 26 Feb 2004 10:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwNld-00072d-0M for nemo@optimus.ietf.org; Thu, 26 Feb 2004 10:49:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20984 for ; Thu, 26 Feb 2004 10:49:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwNla-0001Wh-00 for nemo@ietf.org; Thu, 26 Feb 2004 10:49:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwNkb-0001PS-00 for nemo@ietf.org; Thu, 26 Feb 2004 10:48:38 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AwNjc-0001Dw-00 for nemo@ietf.org; Thu, 26 Feb 2004 10:47:36 -0500 Received: from localhost.localdomain (unknown [147.46.252.130]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id A00445D0B5; Fri, 27 Feb 2004 00:46:37 +0900 (JST) Date: Fri, 27 Feb 2004 00:47:25 +0900 From: Thierry Ernst To: Eranga Perera Cc: nemo@ietf.org Subject: Re: [nemo] Visiting Nodes Message-Id: <20040227004725.7ed89dc1.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386-redhat-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, What you are talking about it a LFN. It gets an address in the mobile network via DHCPv6 or anything, and then communicates with its peers using this address. I don't see what would prevent this node to run any kind of application. As pointed out by Pascal and Alex, it's just not efficient to do so as it breaks the connections and you need to restart them when getting in the mobile network. So, either you use some mobility support mechanims such as MIPv6 and your PDA is a VMN, or you restart the applications and its a LFN from a definition point of view and from the point of view of the MR. The PDA may need to authenticate itself first, but this is another story orthogonal to NEMO and mobility at large. Thierry. > Thanks for the replies. Thought I'll express my humble opinion in one go! > > I agree with Maria and Pascal in the sense that if a commuter obtains > connectivity via a MR then his/her device will be operating in a manner > similar to a LFN. But shouldn't our objective be to enable these nodes to > run any application not just browse the web. How about accessing VPNs? > > Alex, > A non MIPv6 node sure enough would loose the connection when hopping from > a bus to a train. But say for example a commuter needs to synchonize his > calendar on his PDA with the PC in his office. If we assume that visiting > nodes without MIPv6 capabilities are like LFNs then such applications > cannot be supported unless we take care of the security issues. So isn't > it necessary to give emphasis to visiting nodes without MIPv6 capabilities > and try to solve these issues. Basically if these visiting nodes have > permanent IP addresses then how does NEMO protocol handle such nodes - > bidirectional tunneling via double Home Agents ? > > Or can we safely assume that all viising nodes will have MIPv6 > capabilities and not address the above issues? Are all future devices > going to be embeddded with MIPv6?? I guess this is a point to ponder! > > Sorry if I've misinterpreted something. > > Regards, > Eranga > > > -- Thierry Ernst, PhD WIDE at Keio University, Japan IETF NEMO WG co-chair http://www.ietf.org/html.charters/nemo-charter.html WIDE NAUTILUS WG co-chair http://www.nautilus6.org -- 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 Thu Feb 26 14:10:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03184 for ; Thu, 26 Feb 2004 14:10:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwQtV-00023l-Mh; Thu, 26 Feb 2004 14:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwQtH-000237-5L for nemo@optimus.ietf.org; Thu, 26 Feb 2004 14:09:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03172 for ; Thu, 26 Feb 2004 14:09:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwQtE-0000P5-00 for nemo@ietf.org; Thu, 26 Feb 2004 14:09:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwQsK-0000Jy-00 for nemo@ietf.org; Thu, 26 Feb 2004 14:08:49 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1AwQrL-00009d-00 for nemo@ietf.org; Thu, 26 Feb 2004 14:07:47 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 87263AA2A; Thu, 26 Feb 2004 20:07:16 +0100 (CET) Received: from acorde.it.uc3m.es (acorde.it.uc3m.es [163.117.139.72]) by smtp01.uc3m.es (Postfix) with ESMTP id 7056CAA27; Thu, 26 Feb 2004 20:07:16 +0100 (CET) Subject: RE: [nemo] Visiting Nodes From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: =?ISO-8859-1?Q?Mikl=F3s_Aur=E9l_R=F3nai?= "(IJ/ETH)" Cc: Eranga Perera , nemo@ietf.org In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/6rTE4lt2TeRSorRBeWe" Organization: Universidad Carlos III de Madrid Message-Id: <1077822435.819.35.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 26 Feb 2004 20:07:15 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , --=-/6rTE4lt2TeRSorRBeWe Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Mikl=F3s, El jue, 26-02-2004 a las 15:47, Mikl=F3s Aur=E9l R=F3nai (IJ/ETH) escribi= =F3: > Hi Carlos, >=20 > I would like to reflect shortly on the paragraph below. >=20 > > On the other hand, IMHO it is very interesting the=20 > > topic of practical usage scenarios in which network mobility=20 > > could be involved. I mean, what is more likely to occur,=20 > > nodes with ongoing communications that enters in a train or=20 > > nodes that enter in a train and start browsing the Internet,=20 > > for example? >=20 > I think that the scenario where people enter a train and starts web brows= ing is more likely today ... but tomorrow where we will be able to make vid= eo conferences with our handhelds it will be more typical that we enter the= metro or the train with ongoing communications. I am afraid that DHCPv6 or= IPv6 stateless autoconfiguration are not able to handle movements of mobil= e nodes with ongoing transmissions. Yes, you are right. I was also trying to start some discussion about the possible scenarios in which network mobility will be involved in the future. IMHO, it is very important to take into account the different possibilities and which ones are more likely. Depending on the usage scenarios, some kind of problems will be more critical than others, and maybe will require more effort in order to be solved. Why do you think about some kind of document/discussion about the NEMO potential scenarios and the identification of specific problems/needed optimisations? Perhaps this has been discussed in the mailing list before, sorry if it has been already done... Best regards, Carlos J. >=20 > /Miklos >=20 > This communication is confidential and intended solely for the addressee(= s). Any unauthorized review, use, disclosure or distribution is prohibited.= If you believe this message has been sent to you in error, please notify t= he sender by replying to this transmission and delete the message without d= isclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data corruption, interrupt= ion, unauthorized amendment, tampering and viruses, and we only send and re= ceive e-mails on the basis that we are not liable for any such corruption, = interception, amendment, tampering or viruses or any consequences thereof. --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 1880 80D3 8004 25C7 6537 8E02 252A D295 9CFF DEAF --=-/6rTE4lt2TeRSorRBeWe Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAPkPjJSrSlZz/3q8RApRsAKDGx2vrllnmFOXQ9IuVKGY9ONTglgCfWDVg GmBthh3I7WJFa/EvO3ICRhw= =/Ne2 -----END PGP SIGNATURE----- --=-/6rTE4lt2TeRSorRBeWe-- From exim@www1.ietf.org Thu Feb 26 14:12:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03228 for ; Thu, 26 Feb 2004 14:12:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwQvC-0002Ac-IV for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 14:11:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QJBk7I008336 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 14:11:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwQvC-0002AN-8J for nemo-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 14:11:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03214 for ; Thu, 26 Feb 2004 14:11:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwQv9-0000Zy-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 14:11:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwQuE-0000VB-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 14:10:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwQtZ-0000QS-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 14:10:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwQtV-00023l-Mh; Thu, 26 Feb 2004 14:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwQtH-000237-5L for nemo@optimus.ietf.org; Thu, 26 Feb 2004 14:09:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03172 for ; Thu, 26 Feb 2004 14:09:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwQtE-0000P5-00 for nemo@ietf.org; Thu, 26 Feb 2004 14:09:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwQsK-0000Jy-00 for nemo@ietf.org; Thu, 26 Feb 2004 14:08:49 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1AwQrL-00009d-00 for nemo@ietf.org; Thu, 26 Feb 2004 14:07:47 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 87263AA2A; Thu, 26 Feb 2004 20:07:16 +0100 (CET) Received: from acorde.it.uc3m.es (acorde.it.uc3m.es [163.117.139.72]) by smtp01.uc3m.es (Postfix) with ESMTP id 7056CAA27; Thu, 26 Feb 2004 20:07:16 +0100 (CET) Subject: RE: [nemo] Visiting Nodes From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: =?ISO-8859-1?Q?Mikl=F3s_Aur=E9l_R=F3nai?= "(IJ/ETH)" Cc: Eranga Perera , nemo@ietf.org In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/6rTE4lt2TeRSorRBeWe" Organization: Universidad Carlos III de Madrid Message-Id: <1077822435.819.35.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 26 Feb 2004 20:07:15 +0100 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --=-/6rTE4lt2TeRSorRBeWe Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Mikl=F3s, El jue, 26-02-2004 a las 15:47, Mikl=F3s Aur=E9l R=F3nai (IJ/ETH) escribi= =F3: > Hi Carlos, >=20 > I would like to reflect shortly on the paragraph below. >=20 > > On the other hand, IMHO it is very interesting the=20 > > topic of practical usage scenarios in which network mobility=20 > > could be involved. I mean, what is more likely to occur,=20 > > nodes with ongoing communications that enters in a train or=20 > > nodes that enter in a train and start browsing the Internet,=20 > > for example? >=20 > I think that the scenario where people enter a train and starts web brows= ing is more likely today ... but tomorrow where we will be able to make vid= eo conferences with our handhelds it will be more typical that we enter the= metro or the train with ongoing communications. I am afraid that DHCPv6 or= IPv6 stateless autoconfiguration are not able to handle movements of mobil= e nodes with ongoing transmissions. Yes, you are right. I was also trying to start some discussion about the possible scenarios in which network mobility will be involved in the future. IMHO, it is very important to take into account the different possibilities and which ones are more likely. Depending on the usage scenarios, some kind of problems will be more critical than others, and maybe will require more effort in order to be solved. Why do you think about some kind of document/discussion about the NEMO potential scenarios and the identification of specific problems/needed optimisations? Perhaps this has been discussed in the mailing list before, sorry if it has been already done... Best regards, Carlos J. >=20 > /Miklos >=20 > This communication is confidential and intended solely for the addressee(= s). Any unauthorized review, use, disclosure or distribution is prohibited.= If you believe this message has been sent to you in error, please notify t= he sender by replying to this transmission and delete the message without d= isclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data corruption, interrupt= ion, unauthorized amendment, tampering and viruses, and we only send and re= ceive e-mails on the basis that we are not liable for any such corruption, = interception, amendment, tampering or viruses or any consequences thereof. --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 1880 80D3 8004 25C7 6537 8E02 252A D295 9CFF DEAF --=-/6rTE4lt2TeRSorRBeWe Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAPkPjJSrSlZz/3q8RApRsAKDGx2vrllnmFOXQ9IuVKGY9ONTglgCfWDVg GmBthh3I7WJFa/EvO3ICRhw= =/Ne2 -----END PGP SIGNATURE----- --=-/6rTE4lt2TeRSorRBeWe-- From nemo-admin@ietf.org Thu Feb 26 21:58:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25107 for ; Thu, 26 Feb 2004 21:58:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwYCO-0000uW-TJ; Thu, 26 Feb 2004 21:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwYBV-0000rA-48 for nemo@optimus.ietf.org; Thu, 26 Feb 2004 21:57:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25015 for ; Thu, 26 Feb 2004 21:57:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwYBS-0002RJ-00 for nemo@ietf.org; Thu, 26 Feb 2004 21:57:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwYAU-0002Hn-00 for nemo@ietf.org; Thu, 26 Feb 2004 21:56:02 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AwY9V-0001xO-00 for nemo@ietf.org; Thu, 26 Feb 2004 21:55:02 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1R2kRWW004166; Fri, 27 Feb 2004 10:46:27 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 5EA69B23984; Fri, 27 Feb 2004 10:49:12 +0800 (SGT) Subject: Re: [nemo] Visiting Nodes From: Chan-Wah NG To: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Cc: Eranga Perera , IETF NEMO WG In-Reply-To: <1077784218.790.15.camel@acorde> References: <1077784218.790.15.camel@acorde> Content-Type: text/plain; charset=UTF-8 Organization: Panasonic Singapore Labs Message-Id: <1077850151.5540.30.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 27 Feb 2004 10:49:11 +0800 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailsrv.psl.com.sg id i1R2kRWW004166 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Hello all, One way to look at it is to restrict our interpretation of the terms used in the layer we are working on (i.e. IP: layer 3). With that, then "visiting" would implies the concept of 'Home network" and "foreign network". Thus it implicitly carry the concept of mobility protocols (MIPv4, MIPv6). The term "Local" would then refer to a node that is in its home domain, which may or may not use/know mobility protocols. Also, the term "Mobile node" implies a node that uses mobility protocols (MIPv4, MIPv6). The term "fixed node" would then refer to a node that does not use mobility protocols (though it may accept BU, send BA, implements BCE, etc). So, we say a node is "visiting" when its in a foreign domain, and a node is "local" when its in the home domain. Thus there can be no such thing as a Visiting fixed node. =20 In the eyes of IP, the PDA example would be a LFN, though in the eyes of the user it is definitely mobile, and in the eyes of the mobile router owner, it is a visitor. Does this makes sense? /rgds /cwng On Thu, 2004-02-26 at 16:30, Carlos Jes=C3=BAs Bernardos Cano wrote: > Hi Eranga, >=20 > All MNNs (Mobile Network Nodes) move with the mobile network, but not > all of them are "mobile nodes" (i.e. have MIPv6 support and can move > topologically with respect to the MR). Local Fixed Nodes (LFNs) are > nodes that belong to the mobile network and which do not move with > respect to the MR (like the node you pointed in your example). In the > other hand, there are nodes with mobility capabilities: Visiting Mobile > Nodes (VMNs) and Local Mobile Nodes (LMNs). Perhaps the term "visiting" > is not very clear and could lead to confusion, but IMHO it does not mea= n > that other nodes-with no mobility capabilities-could not visit a mobile > network (i.e. a node with portability-DHCPv6 support). >=20 > Best regards, >=20 > Carlos J. >=20 From exim@www1.ietf.org Thu Feb 26 22:00:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25218 for ; Thu, 26 Feb 2004 22:00:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwYEP-00016y-KY for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 22:00:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R305ND004268 for nemo-archive@odin.ietf.org; Thu, 26 Feb 2004 22:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwYEO-00016l-RB for nemo-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 22:00:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25203 for ; Thu, 26 Feb 2004 22:00:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwYEL-0002nE-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 22:00:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwYDU-0002hP-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 21:59:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwYCd-0002bG-00 for nemo-web-archive@ietf.org; Thu, 26 Feb 2004 21:58:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwYCO-0000uW-TJ; Thu, 26 Feb 2004 21:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwYBV-0000rA-48 for nemo@optimus.ietf.org; Thu, 26 Feb 2004 21:57:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25015 for ; Thu, 26 Feb 2004 21:57:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwYBS-0002RJ-00 for nemo@ietf.org; Thu, 26 Feb 2004 21:57:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwYAU-0002Hn-00 for nemo@ietf.org; Thu, 26 Feb 2004 21:56:02 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AwY9V-0001xO-00 for nemo@ietf.org; Thu, 26 Feb 2004 21:55:02 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i1R2kRWW004166; Fri, 27 Feb 2004 10:46:27 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 5EA69B23984; Fri, 27 Feb 2004 10:49:12 +0800 (SGT) Subject: Re: [nemo] Visiting Nodes From: Chan-Wah NG To: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Cc: Eranga Perera , IETF NEMO WG In-Reply-To: <1077784218.790.15.camel@acorde> References: <1077784218.790.15.camel@acorde> Content-Type: text/plain; charset=UTF-8 Organization: Panasonic Singapore Labs Message-Id: <1077850151.5540.30.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 27 Feb 2004 10:49:11 +0800 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailsrv.psl.com.sg id i1R2kRWW004166 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello all, One way to look at it is to restrict our interpretation of the terms used in the layer we are working on (i.e. IP: layer 3). With that, then "visiting" would implies the concept of 'Home network" and "foreign network". Thus it implicitly carry the concept of mobility protocols (MIPv4, MIPv6). The term "Local" would then refer to a node that is in its home domain, which may or may not use/know mobility protocols. Also, the term "Mobile node" implies a node that uses mobility protocols (MIPv4, MIPv6). The term "fixed node" would then refer to a node that does not use mobility protocols (though it may accept BU, send BA, implements BCE, etc). So, we say a node is "visiting" when its in a foreign domain, and a node is "local" when its in the home domain. Thus there can be no such thing as a Visiting fixed node. =20 In the eyes of IP, the PDA example would be a LFN, though in the eyes of the user it is definitely mobile, and in the eyes of the mobile router owner, it is a visitor. Does this makes sense? /rgds /cwng On Thu, 2004-02-26 at 16:30, Carlos Jes=C3=BAs Bernardos Cano wrote: > Hi Eranga, >=20 > All MNNs (Mobile Network Nodes) move with the mobile network, but not > all of them are "mobile nodes" (i.e. have MIPv6 support and can move > topologically with respect to the MR). Local Fixed Nodes (LFNs) are > nodes that belong to the mobile network and which do not move with > respect to the MR (like the node you pointed in your example). In the > other hand, there are nodes with mobility capabilities: Visiting Mobile > Nodes (VMNs) and Local Mobile Nodes (LMNs). Perhaps the term "visiting" > is not very clear and could lead to confusion, but IMHO it does not mea= n > that other nodes-with no mobility capabilities-could not visit a mobile > network (i.e. a node with portability-DHCPv6 support). >=20 > Best regards, >=20 > Carlos J. >=20 From nemo-admin@ietf.org Fri Feb 27 05:40:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24970 for ; Fri, 27 Feb 2004 05:40:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwfOY-0006X2-Bk; Fri, 27 Feb 2004 05:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwfNp-0006FJ-TO for nemo@optimus.ietf.org; Fri, 27 Feb 2004 05:38:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24936 for ; Fri, 27 Feb 2004 05:38:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwfNm-0002FM-00 for nemo@ietf.org; Fri, 27 Feb 2004 05:38:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwfMq-00029b-00 for nemo@ietf.org; Fri, 27 Feb 2004 05:37:17 -0500 Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx with esmtp (Exim 4.12) id 1AwfLr-0001yH-00 for nemo@ietf.org; Fri, 27 Feb 2004 05:36:15 -0500 Received: (from hscho@localhost) by mmlab.snu.ac.kr (8.11.6/8.11.6) id i1RAa4x50918; Fri, 27 Feb 2004 19:36:04 +0900 (KST) (envelope-from hscho) Date: Fri, 27 Feb 2004 19:36:04 +0900 From: Hosik Cho To: Alexandru.Petrescu@motorola.com Cc: nemo@ietf.org Message-ID: <20040227193604.A49960@mmlab.snu.ac.kr> References: <200402270916.i1R9GYv49711@mmlab.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200402270916.i1R9GYv49711@mmlab.snu.ac.kr>; from hscho@mmlab.snu.ac.kr on Fri, Feb 27, 2004 at 06:16:56PM +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [nemo] Re: Hierarchical Mobile Router Advertisement 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, Thanks for your detailed comment on my draft. "Hierarchical mobile router advertisement for nested mobile networks" http://www.ietf.org/internet-drafts/draft-cho-nemo-hmra-00.txt Please, read in lines. > > -----Original Message----- > From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] > Subject: Re: Hierarchical Mobile Router Advertisement > > Hello Eun Kyoung, thank you for asking me and sorry for not having > followed-up with this thread when it occured; I continue it now. Also, > feel free to continue or re-initiate the discussion on the public list, > I think it is benefic for the overall advancement. > > Eun Kyoung Paik wrote: > >>> Internet | AR | Parent MR | Child MR > >>> > >>> In the figure, Parent MR may autoconfigure its CoA after it > >>> listens RA of AR. Then, Child MR may autoconfigure its CoA after > >>> it listens RA of Parent MR. After that, if Parent MR listens > >>> Child MR's RA, Parent MR configures new CoA according to Child > >>> MR's RA ? > >> > >> In this particular configuration, I do not think that Parent MR > >> configures a CoA based on the Child MR RA. There are two reasons > >> for that. > >> > >> One is that according to the stateless autoconfiguration mechanisms > >> a router will not autoconfigure an address on an interface based > >> on received RA's. Parent MR is a router, so. > > > > Then, how MR's egress interface configures its CoA when it moves into > > a foreign link ? Doesn't it need RA from foreign link ? > > I agree with you that this behaviour might look questionable. Let me > bring back some text from the NEMO base spec: > > > A Mobile Router SHOULD NOT send unsolicited Router Advertisements and > > SHOULD NOT reply to Router Solicitations on any egress interface > > when that interface is attached to a visited link. > > So, applying it to your scenario, it would mean that the child MR would > not send RA's on its egress interface (directly connected to the parent > MR's ingress). > Basically, I assume that a MR has two interfaces. The child MR would not send RA's on its egress interface but would send RA's on its ingress interface. > > A router typically ignores router advertisements sent by other > > routers on a link. However, a Mobile Router MUST NOT ignore Router > > Advertisements received on the egress interface. The received Router > > Advertisements MAY be used for address configuration, default router > > selection or movement detection. > > This, applied to your scenario, would mean that the parent MR's egress > interface does obtain a CoA from the AR and that the child MR's egress > interface obtains a CoA from the parent MR's ingress interface's RA. > Right. I think that nested mobile networks are formed this way. > >> The other is that Child MR is, in fact, visiting the network of > >> Parent MR; when a MR is visiting, it acts as a host on its egress > >> interface, not as a router. Thus it will not send RA's on its > >> egress interface if it is not at home, so Parent MR does not get > >> RA's from Child MR. > > > > I wonder if parent MR's egress interrface listen the RA of child MR's > > ingress interface. (Child MR's ingress interface may broadcast its > > RA for its VMNs.) > > Right, this is a good question. I also think that in a nested mobile > networks configuration where all interfaces are wireless there is a > danger that some parent MR's egress interface might receive RA's emitted > by some child MR's ingress interface and might get confused and > configure a CoA and a default route that do not actually point to the > Internet. > My draft is focused on that situation when an MR uses both wireless interfaces for ingress and egress interface. > It is entirely true that in such a completely wireless nested > aggregation there might be a problem with RA's. And not only RA's, this > is only the initial problem, it could be even worse if all nodes in this > aggregation were sending all types of packets to all others if an IP > structuring (subnetting) were not respected. > > The reason I'm staying personally away from tackling this problem is > that in such an aggregation it is _first_ important to establish an L2 > connectivity graph, meaningfully. Let me explain, if I were to build > such an aggregated network for testing purposes with 802.11b, I would > first and foremost make sure that each subnet of each MR has a different > ESSID; this is in order for the LFN's of each MR's moving network be > able to consistently talk to their respective MR; now, if the two moving > networks have different ESSID's (and eventually different WEP keys), > then the RA's sent by the child MR's ingress interface will not be seen > at all by the parent MR's egress interface (even if in wireless range), > so no danger for the parent MR's to configure bad CoA and bad default route. > In my opinion, when ARs and MRs use different ESSID, if an MR is getting into the larger mobile network, the MR need to select which ESSID it will use. That is also a confliction problem. > If on the contrary the two moving networks have the same ESSID then not > only the RA does not work properly, but a thousand other things won't work. > > That's why, in my personal viewpoint, in a nested aggregation of moving > networks it is important to first establish the meaningful L2 > connectivity first that respects the definition of a moving network > itself (moving network is fixed subnet that moves homegeneously), on top > of which it is easy to set up the working L3 topology. > > Otherwise, if the L2 connectivity is not set correctly, then I think > this goes out of scope of the moving networks concepts and becomes very > much an manet issue, where everybody talks to everybody; that said, I > don't think that in the manet world they've considered such fine detail > as you do in your draft, but maybe they should. > > > And how can we distinguish egress interface from ingress interface > > physically ? > > Difficult to say indeed... > > >> There is also a widely acknolwedged problem of "disconnected" > >> operation that was mentioned very early. > > > > Could you breifly explain about "disconnected" operation ? > > It's presented in detail in section B.5 "Example of disconnected > operation issue" of draft-petrescu-nemo-mrha-03.txt (not expired). It > basically says that when two moving networks are nesting one under the > other and the parent MR gets disconnected from the AR, then any LFN > within the child MR's moving network is not able to talk to any other > LFN of the parent MR's moving network (even though the two moving > networks are physically attached). > > Now, let me get back to your draft. If I were to accept that that there > is a problem of RA between child MR and parent MR, as you propose it, > then I think that the proposed method is a potentially elegant solution > to solve that problem (_if_ that is indeed a problem). Also the > Security Considerations section shows a good case of risk. > I think, the risk of malicious RA is general problem of stateless address auto-configuration mechanism. So we need the method to secure the RA message. > Section 1 second paragraph, 9th line, 10th word: I think you meant > "ingress" and not "egress". > Right, that is "ingress". That's my mistake. > The Age field being on 3 bits it effectively limits the depth to 255 > levels no more, could be debatable. > I think that the length of age field can varied. But do we need so many level of hierarchy? > Overall, I could also say that the L2 solution I mentioned earlier > (where different ESSID's are assigned to different moving networks) is > transformed into a solution where the "Age" field is correctly used by > every MR. Both solutions could be correctly used, or abused :-) > > Thanks again for asking me and feel free to discuss it on the nemo list. > > Alex > Thanks, Hosik From exim@www1.ietf.org Fri Feb 27 05:41:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25169 for ; Fri, 27 Feb 2004 05:41:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwfQy-0006ox-KS for nemo-archive@odin.ietf.org; Fri, 27 Feb 2004 05:41:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RAfWhA026215 for nemo-archive@odin.ietf.org; Fri, 27 Feb 2004 05:41:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwfQy-0006ok-D9 for nemo-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 05:41:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25142 for ; Fri, 27 Feb 2004 05:41:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwfQv-0002cu-00 for nemo-web-archive@ietf.org; Fri, 27 Feb 2004 05:41:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwfQ4-0002Vy-00 for nemo-web-archive@ietf.org; Fri, 27 Feb 2004 05:40:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwfPA-0002OB-00 for nemo-web-archive@ietf.org; Fri, 27 Feb 2004 05:39:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwfOY-0006X2-Bk; Fri, 27 Feb 2004 05:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwfNp-0006FJ-TO for nemo@optimus.ietf.org; Fri, 27 Feb 2004 05:38:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24936 for ; Fri, 27 Feb 2004 05:38:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwfNm-0002FM-00 for nemo@ietf.org; Fri, 27 Feb 2004 05:38:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwfMq-00029b-00 for nemo@ietf.org; Fri, 27 Feb 2004 05:37:17 -0500 Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx with esmtp (Exim 4.12) id 1AwfLr-0001yH-00 for nemo@ietf.org; Fri, 27 Feb 2004 05:36:15 -0500 Received: (from hscho@localhost) by mmlab.snu.ac.kr (8.11.6/8.11.6) id i1RAa4x50918; Fri, 27 Feb 2004 19:36:04 +0900 (KST) (envelope-from hscho) Date: Fri, 27 Feb 2004 19:36:04 +0900 From: Hosik Cho To: Alexandru.Petrescu@motorola.com Cc: nemo@ietf.org Message-ID: <20040227193604.A49960@mmlab.snu.ac.kr> References: <200402270916.i1R9GYv49711@mmlab.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200402270916.i1R9GYv49711@mmlab.snu.ac.kr>; from hscho@mmlab.snu.ac.kr on Fri, Feb 27, 2004 at 06:16:56PM +0900 Subject: [nemo] Re: Hierarchical Mobile Router Advertisement 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Alex, Thanks for your detailed comment on my draft. "Hierarchical mobile router advertisement for nested mobile networks" http://www.ietf.org/internet-drafts/draft-cho-nemo-hmra-00.txt Please, read in lines. > > -----Original Message----- > From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] > Subject: Re: Hierarchical Mobile Router Advertisement > > Hello Eun Kyoung, thank you for asking me and sorry for not having > followed-up with this thread when it occured; I continue it now. Also, > feel free to continue or re-initiate the discussion on the public list, > I think it is benefic for the overall advancement. > > Eun Kyoung Paik wrote: > >>> Internet | AR | Parent MR | Child MR > >>> > >>> In the figure, Parent MR may autoconfigure its CoA after it > >>> listens RA of AR. Then, Child MR may autoconfigure its CoA after > >>> it listens RA of Parent MR. After that, if Parent MR listens > >>> Child MR's RA, Parent MR configures new CoA according to Child > >>> MR's RA ? > >> > >> In this particular configuration, I do not think that Parent MR > >> configures a CoA based on the Child MR RA. There are two reasons > >> for that. > >> > >> One is that according to the stateless autoconfiguration mechanisms > >> a router will not autoconfigure an address on an interface based > >> on received RA's. Parent MR is a router, so. > > > > Then, how MR's egress interface configures its CoA when it moves into > > a foreign link ? Doesn't it need RA from foreign link ? > > I agree with you that this behaviour might look questionable. Let me > bring back some text from the NEMO base spec: > > > A Mobile Router SHOULD NOT send unsolicited Router Advertisements and > > SHOULD NOT reply to Router Solicitations on any egress interface > > when that interface is attached to a visited link. > > So, applying it to your scenario, it would mean that the child MR would > not send RA's on its egress interface (directly connected to the parent > MR's ingress). > Basically, I assume that a MR has two interfaces. The child MR would not send RA's on its egress interface but would send RA's on its ingress interface. > > A router typically ignores router advertisements sent by other > > routers on a link. However, a Mobile Router MUST NOT ignore Router > > Advertisements received on the egress interface. The received Router > > Advertisements MAY be used for address configuration, default router > > selection or movement detection. > > This, applied to your scenario, would mean that the parent MR's egress > interface does obtain a CoA from the AR and that the child MR's egress > interface obtains a CoA from the parent MR's ingress interface's RA. > Right. I think that nested mobile networks are formed this way. > >> The other is that Child MR is, in fact, visiting the network of > >> Parent MR; when a MR is visiting, it acts as a host on its egress > >> interface, not as a router. Thus it will not send RA's on its > >> egress interface if it is not at home, so Parent MR does not get > >> RA's from Child MR. > > > > I wonder if parent MR's egress interrface listen the RA of child MR's > > ingress interface. (Child MR's ingress interface may broadcast its > > RA for its VMNs.) > > Right, this is a good question. I also think that in a nested mobile > networks configuration where all interfaces are wireless there is a > danger that some parent MR's egress interface might receive RA's emitted > by some child MR's ingress interface and might get confused and > configure a CoA and a default route that do not actually point to the > Internet. > My draft is focused on that situation when an MR uses both wireless interfaces for ingress and egress interface. > It is entirely true that in such a completely wireless nested > aggregation there might be a problem with RA's. And not only RA's, this > is only the initial problem, it could be even worse if all nodes in this > aggregation were sending all types of packets to all others if an IP > structuring (subnetting) were not respected. > > The reason I'm staying personally away from tackling this problem is > that in such an aggregation it is _first_ important to establish an L2 > connectivity graph, meaningfully. Let me explain, if I were to build > such an aggregated network for testing purposes with 802.11b, I would > first and foremost make sure that each subnet of each MR has a different > ESSID; this is in order for the LFN's of each MR's moving network be > able to consistently talk to their respective MR; now, if the two moving > networks have different ESSID's (and eventually different WEP keys), > then the RA's sent by the child MR's ingress interface will not be seen > at all by the parent MR's egress interface (even if in wireless range), > so no danger for the parent MR's to configure bad CoA and bad default route. > In my opinion, when ARs and MRs use different ESSID, if an MR is getting into the larger mobile network, the MR need to select which ESSID it will use. That is also a confliction problem. > If on the contrary the two moving networks have the same ESSID then not > only the RA does not work properly, but a thousand other things won't work. > > That's why, in my personal viewpoint, in a nested aggregation of moving > networks it is important to first establish the meaningful L2 > connectivity first that respects the definition of a moving network > itself (moving network is fixed subnet that moves homegeneously), on top > of which it is easy to set up the working L3 topology. > > Otherwise, if the L2 connectivity is not set correctly, then I think > this goes out of scope of the moving networks concepts and becomes very > much an manet issue, where everybody talks to everybody; that said, I > don't think that in the manet world they've considered such fine detail > as you do in your draft, but maybe they should. > > > And how can we distinguish egress interface from ingress interface > > physically ? > > Difficult to say indeed... > > >> There is also a widely acknolwedged problem of "disconnected" > >> operation that was mentioned very early. > > > > Could you breifly explain about "disconnected" operation ? > > It's presented in detail in section B.5 "Example of disconnected > operation issue" of draft-petrescu-nemo-mrha-03.txt (not expired). It > basically says that when two moving networks are nesting one under the > other and the parent MR gets disconnected from the AR, then any LFN > within the child MR's moving network is not able to talk to any other > LFN of the parent MR's moving network (even though the two moving > networks are physically attached). > > Now, let me get back to your draft. If I were to accept that that there > is a problem of RA between child MR and parent MR, as you propose it, > then I think that the proposed method is a potentially elegant solution > to solve that problem (_if_ that is indeed a problem). Also the > Security Considerations section shows a good case of risk. > I think, the risk of malicious RA is general problem of stateless address auto-configuration mechanism. So we need the method to secure the RA message. > Section 1 second paragraph, 9th line, 10th word: I think you meant > "ingress" and not "egress". > Right, that is "ingress". That's my mistake. > The Age field being on 3 bits it effectively limits the depth to 255 > levels no more, could be debatable. > I think that the length of age field can varied. But do we need so many level of hierarchy? > Overall, I could also say that the L2 solution I mentioned earlier > (where different ESSID's are assigned to different moving networks) is > transformed into a solution where the "Age" field is correctly used by > every MR. Both solutions could be correctly used, or abused :-) > > Thanks again for asking me and feel free to discuss it on the nemo list. > > Alex > Thanks, Hosik From nemo-admin@ietf.org Fri Feb 27 11:05:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10355 for ; Fri, 27 Feb 2004 11:05:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwkU2-0002BH-Si; Fri, 27 Feb 2004 11:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwkTh-0002AW-HG for nemo@optimus.ietf.org; Fri, 27 Feb 2004 11:04:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10320 for ; Fri, 27 Feb 2004 11:04:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwkTe-00017F-00 for nemo@ietf.org; Fri, 27 Feb 2004 11:04:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwkSu-00010e-00 for nemo@ietf.org; Fri, 27 Feb 2004 11:03:52 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AwkSC-0000sJ-00 for nemo@ietf.org; Fri, 27 Feb 2004 11:03:08 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i1QBqBUg028485; Thu, 26 Feb 2004 04:52:11 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i1QBq1SZ024096; Thu, 26 Feb 2004 05:52:04 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 1AAF2852732; Thu, 26 Feb 2004 12:52:01 +0100 (CET) Message-ID: <403DDDE0.7050107@motorola.com> Date: Thu, 26 Feb 2004 12:52:00 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eranga Perera Cc: nemo@ietf.org, mamalik@cse.unsw.edu.au, maria@it.uc3m.es, pthubert@cisco.com References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Visiting Nodes 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 Eranga Perera wrote: > But say for example a commuter needs to synchonize his calendar on > his PDA with the PC in his office. If we assume that visiting nodes > without MIPv6 capabilities are like LFNs then such applications > cannot be supported unless we take care of the security issues. I have nothing against commuters in need of access everywhere everytime and even would like to see IP access within NEMOed submarines, not only buses or trains. The security issues, how? A PDA entering a train would use IPsec between itself and its PC on its desktop at the office; the LFN-Desktop IPsec tunnel would be re-tunneled by the MR and by MR's HA. There would be no interaction between Node's IPsec and the MR-HA IPsec, a matter of modularity... or, do you think there should be some interaction, why? Otherwise, do you potentially have a specific security architecture in mind that would support the non-MIPv6 Nodes (but still physically mobile) in a way that is different than multiple IPsec encapsulation? Or, if there is concern in that traffic unoptimally goes through the MR's HA, then this is more or less an RO issue, no? Alex From exim@www1.ietf.org Fri Feb 27 11:06:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10453 for ; Fri, 27 Feb 2004 11:06:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwkVT-0002II-Px for nemo-archive@odin.ietf.org; Fri, 27 Feb 2004 11:06:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RG6V0m008812 for nemo-archive@odin.ietf.org; Fri, 27 Feb 2004 11:06:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwkVT-0002I3-JG for nemo-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 11:06:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10436 for ; Fri, 27 Feb 2004 11:06:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwkVR-0001Jd-00 for nemo-web-archive@ietf.org; Fri, 27 Feb 2004 11:06:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwkUb-0001EG-00 for nemo-web-archive@ietf.org; Fri, 27 Feb 2004 11:05:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwkU5-000185-00 for nemo-web-archive@ietf.org; Fri, 27 Feb 2004 11:05:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwkU2-0002BH-Si; Fri, 27 Feb 2004 11:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwkTh-0002AW-HG for nemo@optimus.ietf.org; Fri, 27 Feb 2004 11:04:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10320 for ; Fri, 27 Feb 2004 11:04:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwkTe-00017F-00 for nemo@ietf.org; Fri, 27 Feb 2004 11:04:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwkSu-00010e-00 for nemo@ietf.org; Fri, 27 Feb 2004 11:03:52 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AwkSC-0000sJ-00 for nemo@ietf.org; Fri, 27 Feb 2004 11:03:08 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i1QBqBUg028485; Thu, 26 Feb 2004 04:52:11 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i1QBq1SZ024096; Thu, 26 Feb 2004 05:52:04 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 1AAF2852732; Thu, 26 Feb 2004 12:52:01 +0100 (CET) Message-ID: <403DDDE0.7050107@motorola.com> Date: Thu, 26 Feb 2004 12:52:00 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eranga Perera Cc: nemo@ietf.org, mamalik@cse.unsw.edu.au, maria@it.uc3m.es, pthubert@cisco.com References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Visiting Nodes 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eranga Perera wrote: > But say for example a commuter needs to synchonize his calendar on > his PDA with the PC in his office. If we assume that visiting nodes > without MIPv6 capabilities are like LFNs then such applications > cannot be supported unless we take care of the security issues. I have nothing against commuters in need of access everywhere everytime and even would like to see IP access within NEMOed submarines, not only buses or trains. The security issues, how? A PDA entering a train would use IPsec between itself and its PC on its desktop at the office; the LFN-Desktop IPsec tunnel would be re-tunneled by the MR and by MR's HA. There would be no interaction between Node's IPsec and the MR-HA IPsec, a matter of modularity... or, do you think there should be some interaction, why? Otherwise, do you potentially have a specific security architecture in mind that would support the non-MIPv6 Nodes (but still physically mobile) in a way that is different than multiple IPsec encapsulation? Or, if there is concern in that traffic unoptimally goes through the MR's HA, then this is more or less an RO issue, no? Alex From nemo-admin@ietf.org Fri Feb 27 14:24:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19163 for ; Fri, 27 Feb 2004 14:24:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awnab-0006B2-Go; Fri, 27 Feb 2004 14:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwnaK-0006Ac-UI for nemo@optimus.ietf.org; Fri, 27 Feb 2004 14:23:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19146 for ; Fri, 27 Feb 2004 14:23:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwnaI-0001i8-00 for nemo@ietf.org; Fri, 27 Feb 2004 14:23:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwnZU-0001bw-00 for nemo@ietf.org; Fri, 27 Feb 2004 14:22:52 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AwnYk-0001Tw-00 for nemo@ietf.org; Fri, 27 Feb 2004 14:22:06 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i1RJM75h016156; Fri, 27 Feb 2004 12:22:07 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i1RJM1gK004135; Fri, 27 Feb 2004 13:22:02 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 240A285272D; Fri, 27 Feb 2004 20:22:01 +0100 (CET) Message-ID: <403F98D9.6080905@motorola.com> Date: Fri, 27 Feb 2004 20:22:01 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hosik Cho Cc: nemo@ietf.org Subject: Re: [nemo] Re: Hierarchical Mobile Router Advertisement References: <200402270916.i1R9GYv49711@mmlab.snu.ac.kr> <20040227193604.A49960@mmlab.snu.ac.kr> In-Reply-To: <20040227193604.A49960@mmlab.snu.ac.kr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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 Hosik Cho wrote: > My draft is focused on that situation when an MR uses both wireless > interfaces for ingress and egress interface. > > In my opinion, when ARs and MRs use different ESSID, if an MR is > getting into the larger mobile network, the MR need to select which > ESSID it will use. That is also a confliction problem. By the definition in the draft, this is a confliction problem _only_ if the two wireless interfaces have the same ESSID; not only will the egress interface of the parent MR receive RA's from the ingress interface of the child MR but the egress interface of the child MR too will receive RA's from the ingress interface of the same MR (child); in this way, there is a danger in that the egress interface of the child MR might form a CoA based on the RA emitted by its own ingress interface. But, if there are different ESSID's per each subnet (one ESSID for the link of the parent MR's moving network and another ESSID for the link of the child MR's link and yet another different ESSID for the AR) then I think there is no confliction problem, because RA's sent by various interfaces are visiblel only within the respective link. > I think, the risk of malicious RA is general problem of stateless > address auto-configuration mechanism. So we need the method to secure > the RA message. I think that securing RA's is tackled within SEND, maybe we can reuse from them, or inform about the necessity of it as suggested by your scenario. >> The Age field being on 3 bits it effectively limits the depth to >> 255 levels no more, could be debatable. > > I think that the length of age field can varied. But do we need so > many level of hierarchy? Probably not in my oppinion, I am not aware of scenarios requiring more than 4 levels... So overall, I think that if we acknowledge that there is a danger in that the parent MR egress interface accidentally uses the child MR's ingress RA's, then there are distinctive possibilities to deal with it: -define the right L2 reachability (for WLAN it's by using different ESSID's per subnet). -use RA Age mechanism described in your draft. -use SEND. Or? Alex From exim@www1.ietf.org Fri Feb 27 14:26:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19197 for ; Fri, 27 Feb 2004 14:26:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awnc5-0006Kp-GS for nemo-archive@odin.ietf.org; Fri, 27 Feb 2004 14:25:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RJPXgh024350 for nemo-archive@odin.ietf.org; Fri, 27 Feb 2004 14:25:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awnc5-0006Kf-Ar for nemo-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 14:25:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19187 for ; Fri, 27 Feb 2004 14:25:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awnc2-0001rh-00 for nemo-web-archive@ietf.org; Fri, 27 Feb 2004 14:25:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awnb4-0001mv-00 for nemo-web-archive@ietf.org; Fri, 27 Feb 2004 14:24:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Awnaf-0001iM-00 for nemo-web-archive@ietf.org; Fri, 27 Feb 2004 14:24:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awnab-0006B2-Go; Fri, 27 Feb 2004 14:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwnaK-0006Ac-UI for nemo@optimus.ietf.org; Fri, 27 Feb 2004 14:23:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19146 for ; Fri, 27 Feb 2004 14:23:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwnaI-0001i8-00 for nemo@ietf.org; Fri, 27 Feb 2004 14:23:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwnZU-0001bw-00 for nemo@ietf.org; Fri, 27 Feb 2004 14:22:52 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AwnYk-0001Tw-00 for nemo@ietf.org; Fri, 27 Feb 2004 14:22:06 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i1RJM75h016156; Fri, 27 Feb 2004 12:22:07 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i1RJM1gK004135; Fri, 27 Feb 2004 13:22:02 -0600 Received: from motorola.com (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 240A285272D; Fri, 27 Feb 2004 20:22:01 +0100 (CET) Message-ID: <403F98D9.6080905@motorola.com> Date: Fri, 27 Feb 2004 20:22:01 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hosik Cho Cc: nemo@ietf.org Subject: Re: [nemo] Re: Hierarchical Mobile Router Advertisement References: <200402270916.i1R9GYv49711@mmlab.snu.ac.kr> <20040227193604.A49960@mmlab.snu.ac.kr> In-Reply-To: <20040227193604.A49960@mmlab.snu.ac.kr> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hosik Cho wrote: > My draft is focused on that situation when an MR uses both wireless > interfaces for ingress and egress interface. > > In my opinion, when ARs and MRs use different ESSID, if an MR is > getting into the larger mobile network, the MR need to select which > ESSID it will use. That is also a confliction problem. By the definition in the draft, this is a confliction problem _only_ if the two wireless interfaces have the same ESSID; not only will the egress interface of the parent MR receive RA's from the ingress interface of the child MR but the egress interface of the child MR too will receive RA's from the ingress interface of the same MR (child); in this way, there is a danger in that the egress interface of the child MR might form a CoA based on the RA emitted by its own ingress interface. But, if there are different ESSID's per each subnet (one ESSID for the link of the parent MR's moving network and another ESSID for the link of the child MR's link and yet another different ESSID for the AR) then I think there is no confliction problem, because RA's sent by various interfaces are visiblel only within the respective link. > I think, the risk of malicious RA is general problem of stateless > address auto-configuration mechanism. So we need the method to secure > the RA message. I think that securing RA's is tackled within SEND, maybe we can reuse from them, or inform about the necessity of it as suggested by your scenario. >> The Age field being on 3 bits it effectively limits the depth to >> 255 levels no more, could be debatable. > > I think that the length of age field can varied. But do we need so > many level of hierarchy? Probably not in my oppinion, I am not aware of scenarios requiring more than 4 levels... So overall, I think that if we acknowledge that there is a danger in that the parent MR egress interface accidentally uses the child MR's ingress RA's, then there are distinctive possibilities to deal with it: -define the right L2 reachability (for WLAN it's by using different ESSID's per subnet). -use RA Age mechanism described in your draft. -use SEND. Or? Alex From nemo-admin@ietf.org Fri Feb 27 19:43:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06601 for ; Fri, 27 Feb 2004 19:43:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwsZJ-0000pP-4H; Fri, 27 Feb 2004 19:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwsZ0-0000oR-Fn for nemo@optimus.ietf.org; Fri, 27 Feb 2004 19:42:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06580 for ; Fri, 27 Feb 2004 19:42:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwsYy-0000Es-00 for nemo@ietf.org; Fri, 27 Feb 2004 19:42:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwsYF-00009P-00 for nemo@ietf.org; Fri, 27 Feb 2004 19:41:56 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AwsXf-00000V-00 for nemo@ietf.org; Fri, 27 Feb 2004 19:41:19 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1S0edn05862; Fri, 27 Feb 2004 16:40:39 -0800 X-mProtect: <200402280040> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlAB2qt; Fri, 27 Feb 2004 16:40:37 PST Message-ID: <403FE662.70708@iprg.nokia.com> Date: Fri, 27 Feb 2004 16:52:50 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@ietf.org Subject: Re: [nemo] MNP in the explicit BU when returning home? References: <3FF15879.4010404@motorola.com> In-Reply-To: <3FF15879.4010404@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Alex, sorry for the very late reply. :( Alexandru Petrescu wrote: > Hi, > > I suggest, if explicit mode is used, to have the MNP's Mobility Options > included in the Mobility Header of a BU sent by MR when it returns home. > > The existing section 5.8 Returning Home of basic support 02 is silent > about this. Or maybe it is understood that when MR comes back home > _all_ MNP's must be deregistered? If yes, this is IMHO a feature of > implicit mode, and for the explicit mode it should be stated. if the BU is a de-registration BU, the HA is not going to process any Mobile Network Prefix options in the BU. once it sees the lifetime set to 0, it just removes the binding cache entry for the MN and all the associated MNP routes for a particular MR. so there is no need for the MR to include MNPs in the BU in the explicit mode. the HA is going to ignore them anyway. I will add some text to make this more explicit. Vijay From exim@www1.ietf.org Fri Feb 27 19:45:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06783 for ; Fri, 27 Feb 2004 19:45:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwsbN-0000xj-TR for nemo-archive@odin.ietf.org; Fri, 27 Feb 2004 19:45:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1S0j9Ck003696 for nemo-archive@odin.ietf.org; Fri, 27 Feb 2004 19:45:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwsbN-0000xX-A1 for nemo-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 19:45:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06693 for ; Fri, 27 Feb 2004 19:45:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwsbL-0000bK-00 for nemo-web-archive@ietf.org; Fri, 27 Feb 2004 19:45:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwsaF-0000PO-00 for nemo-web-archive@ietf.org; Fri, 27 Feb 2004 19:44:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwsZK-0000Gr-00 for nemo-web-archive@ietf.org; Fri, 27 Feb 2004 19:43:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwsZJ-0000pP-4H; Fri, 27 Feb 2004 19:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwsZ0-0000oR-Fn for nemo@optimus.ietf.org; Fri, 27 Feb 2004 19:42:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06580 for ; Fri, 27 Feb 2004 19:42:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwsYy-0000Es-00 for nemo@ietf.org; Fri, 27 Feb 2004 19:42:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwsYF-00009P-00 for nemo@ietf.org; Fri, 27 Feb 2004 19:41:56 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AwsXf-00000V-00 for nemo@ietf.org; Fri, 27 Feb 2004 19:41:19 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1S0edn05862; Fri, 27 Feb 2004 16:40:39 -0800 X-mProtect: <200402280040> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlAB2qt; Fri, 27 Feb 2004 16:40:37 PST Message-ID: <403FE662.70708@iprg.nokia.com> Date: Fri, 27 Feb 2004 16:52:50 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@ietf.org Subject: Re: [nemo] MNP in the explicit BU when returning home? References: <3FF15879.4010404@motorola.com> In-Reply-To: <3FF15879.4010404@motorola.com> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Alex, sorry for the very late reply. :( Alexandru Petrescu wrote: > Hi, > > I suggest, if explicit mode is used, to have the MNP's Mobility Options > included in the Mobility Header of a BU sent by MR when it returns home. > > The existing section 5.8 Returning Home of basic support 02 is silent > about this. Or maybe it is understood that when MR comes back home > _all_ MNP's must be deregistered? If yes, this is IMHO a feature of > implicit mode, and for the explicit mode it should be stated. if the BU is a de-registration BU, the HA is not going to process any Mobile Network Prefix options in the BU. once it sees the lifetime set to 0, it just removes the binding cache entry for the MN and all the associated MNP routes for a particular MR. so there is no need for the MR to include MNPs in the BU in the explicit mode. the HA is going to ignore them anyway. I will add some text to make this more explicit. Vijay From nemo-admin@ietf.org Fri Feb 27 19:57:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07174 for ; Fri, 27 Feb 2004 19:57:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awsmr-0001N0-0E; Fri, 27 Feb 2004 19:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awsmf-0001Mf-VF for nemo@optimus.ietf.org; Fri, 27 Feb 2004 19:56:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07168 for ; Fri, 27 Feb 2004 19:56:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awsme-0001tA-00 for nemo@ietf.org; Fri, 27 Feb 2004 19:56:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awsli-0001nI-00 for nemo@ietf.org; Fri, 27 Feb 2004 19:55:51 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AwslL-0001gl-00 for nemo@ietf.org; Fri, 27 Feb 2004 19:55:32 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1S0sLD28562; Fri, 27 Feb 2004 16:54:21 -0800 X-mProtect: <200402280054> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpypmNj; Fri, 27 Feb 2004 16:54:19 PST Message-ID: <403FE998.5030101@iprg.nokia.com> Date: Fri, 27 Feb 2004 17:06:32 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: ryuji@sfc.wide.ad.jp, Alexandru Petrescu , nemo@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] Re: FW: checking the Nemo 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: , Content-Transfer-Encoding: 7bit Pascal, the current text says The source address of the inner IPv6 header MUST be a topologically correct address with respect to the IPv6 prefixes used in the mobile network. this text covers all three (a), (b) and (c) from the text you are proposing below. it does not exclude any of them. > That active registration. The source address of the inner IPv6 header > may be either: > a) the Home address for that registration (MN or MR) > b) a global address from an MNP associated to that registration for a > registration with the > 'R' bit set > c) ) more generally, if some additional routing takes place, an address > from a prefix that is > routed via the registration home address, for a registration with the > 'R' bit set. > > ------------------------------------------------------------ > > > I believe we should open an issue for it. Note that MIPv6 is clear and > right about the fact that the inner packet has to be checked to make > sure that the tunnel is used by MN. Checking that the tunnel source > exists is not enough for basic Nemo. thats not what the current text says. the source address should should belong to a MNP that the mobile router is known to use. Vijay From exim@www1.ietf.org Fri Feb 27 19:59:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07252 for ; Fri, 27 Feb 2004 19:59:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwsoY-0001VL-TS for nemo-archive@odin.ietf.org; Fri, 27 Feb 2004 19:58:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1S0wkru005777 for nemo-archive@odin.ietf.org; Fri, 27 Feb 2004 19:58:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwsoY-0001V6-MG for nemo-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 19:58:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07238 for ; Fri, 27 Feb 2004 19:58:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwsoW-00024z-00 for nemo-web-archive@ietf.org; Fri, 27 Feb 2004 19:58:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awsnh-0001zg-00 for nemo-web-archive@ietf.org; Fri, 27 Feb 2004 19:57:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Awsmr-0001tj-00 for nemo-web-archive@ietf.org; Fri, 27 Feb 2004 19:57:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awsmr-0001N0-0E; Fri, 27 Feb 2004 19:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awsmf-0001Mf-VF for nemo@optimus.ietf.org; Fri, 27 Feb 2004 19:56:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07168 for ; Fri, 27 Feb 2004 19:56:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awsme-0001tA-00 for nemo@ietf.org; Fri, 27 Feb 2004 19:56:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awsli-0001nI-00 for nemo@ietf.org; Fri, 27 Feb 2004 19:55:51 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AwslL-0001gl-00 for nemo@ietf.org; Fri, 27 Feb 2004 19:55:32 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1S0sLD28562; Fri, 27 Feb 2004 16:54:21 -0800 X-mProtect: <200402280054> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpypmNj; Fri, 27 Feb 2004 16:54:19 PST Message-ID: <403FE998.5030101@iprg.nokia.com> Date: Fri, 27 Feb 2004 17:06:32 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: ryuji@sfc.wide.ad.jp, Alexandru Petrescu , nemo@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: FW: checking the Nemo 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal, the current text says The source address of the inner IPv6 header MUST be a topologically correct address with respect to the IPv6 prefixes used in the mobile network. this text covers all three (a), (b) and (c) from the text you are proposing below. it does not exclude any of them. > That active registration. The source address of the inner IPv6 header > may be either: > a) the Home address for that registration (MN or MR) > b) a global address from an MNP associated to that registration for a > registration with the > 'R' bit set > c) ) more generally, if some additional routing takes place, an address > from a prefix that is > routed via the registration home address, for a registration with the > 'R' bit set. > > ------------------------------------------------------------ > > > I believe we should open an issue for it. Note that MIPv6 is clear and > right about the fact that the inner packet has to be checked to make > sure that the tunnel is used by MN. Checking that the tunnel source > exists is not enough for basic Nemo. thats not what the current text says. the source address should should belong to a MNP that the mobile router is known to use. Vijay From nemo-admin@ietf.org Sat Feb 28 20:24:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14224 for ; Sat, 28 Feb 2004 20:24:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFga-0005Vu-K0; Sat, 28 Feb 2004 20:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxEoh-0002Gx-Nn for nemo@optimus.ietf.org; Sat, 28 Feb 2004 19:28:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12287 for ; Sat, 28 Feb 2004 19:28:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxEoe-0005xd-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:28:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxEnL-0005kW-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:27:00 -0500 Received: from nam.ietf59.or.kr ([218.37.196.23]) by ietf-mx with esmtp (Exim 4.12) id 1AxEmZ-0005al-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:26:11 -0500 Received: from lolo (lolo.dhcp.ietf59.or.kr [218.37.225.195]) by nam.ietf59.or.kr (8.12.11/8.12.11) with SMTP id i1T0PsEf057749; Sun, 29 Feb 2004 09:26:02 +0900 (KST) (envelope-from mbagnulo@ing.uc3m.es) X-Authentication-Warning: nam.ietf59.or.kr: Host lolo.dhcp.ietf59.or.kr [218.37.225.195] claimed to be lolo Reply-To: From: "marcelo bagnulo" To: "Thierry Ernst" , "Mattias Pettersson" Cc: "nemo" Subject: RE: [nemo] merged multihoming draft Date: Sun, 29 Feb 2004 01:24:05 +0100 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20040226174436.2d0edbd9.ernst@sfc.wide.ad.jp> Importance: Normal X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.24.0.5; VDF 6.24.0.25 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 > Just one more detail: the fact that multiple prefixes are advertised on > the mobile network's egreess interface doesn't preclude that multiple > NEMO-prefixes will be advertised down the mobile network. But if you do that, the isp associated with the prefix that you are not announcing won't be used by the MNN (unless you rewrite the addresses at the exit or something like this) So you reduce the case to a single homed network. [...] > Not allowing to advertise multiple prefixes may be one recommendation, I don't think so, see above > but then, it means we have to design a protocol to synchronize MRs. I guess that you will need more than that, as stated above. > On > the other hand, if we allow the advertisement of multiple NEMO-prefixes, > MNNs have to select their source address. Yes, like in most of the multihomed site solutions. Regards, marcelo > > What I said is of course orthogonal with multiple NEMO-prefix > registration with the HA. > > > Such a general host behaviour may be required for multihoming > to work in > > IPv6 some day, but we have not reached that point yet. > > Thierry > From nemo-admin@ietf.org Sat Feb 28 20:24:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14220 for ; Sat, 28 Feb 2004 20:24:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFgb-0005W3-4M; Sat, 28 Feb 2004 20:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxEon-0002H7-Ky for nemo@optimus.ietf.org; Sat, 28 Feb 2004 19:28:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12298 for ; Sat, 28 Feb 2004 19:28:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxEol-00060W-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:28:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxEnO-0005kz-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:27:02 -0500 Received: from nam.ietf59.or.kr ([218.37.196.23]) by ietf-mx with esmtp (Exim 4.12) id 1AxEmb-0005au-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:26:13 -0500 Received: from lolo (lolo.dhcp.ietf59.or.kr [218.37.225.195]) by nam.ietf59.or.kr (8.12.11/8.12.11) with SMTP id i1T0PsEb057749; Sun, 29 Feb 2004 09:25:59 +0900 (KST) (envelope-from mbagnulo@ing.uc3m.es) X-Authentication-Warning: nam.ietf59.or.kr: Host lolo.dhcp.ietf59.or.kr [218.37.225.195] claimed to be lolo Reply-To: From: "marcelo bagnulo" To: "Thierry Ernst" Cc: , , , Subject: RE: [nemo] merged multihoming draft Date: Sun, 29 Feb 2004 01:24:02 +0100 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20040226180043.572c3fc1.ernst@sfc.wide.ad.jp> Importance: Normal X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.24.0.5; VDF 6.24.0.25 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 > -----Mensaje original----- > De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]En nombre de Thierry > Ernst > Enviado el: jueves, 26 de febrero de 2004 10:01 > Para: mbagnulo@ing.uc3m.es > CC: mattias.l.pettersson@ericsson.com; cwng@psl.com.sg; > eun@mmlab.snu.ac.kr; nemo@ietf.org > Asunto: Re: [nemo] merged multihoming draft > > > > > Hi, > > > > It is a question on what entities should carry out the dirty work. > > > Either the MRs or the MNNs. > > > > Perhaps in the case of multiple prefixes, the dirty work has to > be carried > > by the Home Network Site Exit routers? > > Can we be more specific with 'dirty work' ? Well,a possibility to solve this problem is to create a mesh of tunnels between the exit router, so that they forward the packet to the exit isp router that it is connected to the ISP that matches the source address included in the packet > > > > To me it is important that legacy IPv6 hosts can still get > connectivity > > > in a moving network without having to implement new proposals such as > > > draft-huitema-multi6-hosts-xx. > > > > Fully agree with the first statement. > > But Host centric (draft-huitema-multi6-hosts) approach allows > exactly this > > for multihomed network. > > > > That is, that a regular IPv6 host is connected to the > multihomed network and > > still works properly. > > Clearly, there some benefits, like preserving established communications > > through outages, that it will not be able to obtain, but at > least it will > > work fine and its operation won't be disturbed because of multihoming. > > > > > > > > So what is most important: to support standard IPv6 hosts or > to simplify > > > the MR? > > > > I fully agree that standard IPv6 have to keep on working properly. > > Perhaps they won't obtain all the multihoming benefits, though > > > > > It seems like in order to simplify the MR we are proposing to > > > introduce a NEMO scenario that was considered "broken" in the IPv6 WG > > > earlier. All routers on a link are equal, from the host's > point of view! > > > > Well, again this IMHO is generic to multihoming and not > specific to nemo. > > I guess that if a hosts has to be updated to obtain full multihoming > > benefits in a fixed network, it would be reasonable that it > also has to be > > updated in order to obtain multihoming benefits in nemo. > > Fully agree. > > What is specific to NEMO WG is the ability to register several > NEMO-prefixes with the HA, if we need to. > > Obtaining all potential benefits of multihoming is not a NEMO task. It > should be carried on by another WG which doesn't focus on mobility. On > the other hand, our goal is to document the issues; I suspect actions > will have been taken by other WGs based on the conclusions of the NEMO > Multihoming Pb Statement WG document. I agree. I guess that the problem here is to identify which are the NEMO specific issues that are not present in the general case of a multihomed site. See my answer to Mattias w.r.t. this Regards, marcelo > > Thierry. > > > > > From exim@www1.ietf.org Sat Feb 28 20:43:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15236 for ; Sat, 28 Feb 2004 20:43:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFyj-000816-8H for nemo-archive@odin.ietf.org; Sat, 28 Feb 2004 20:42:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T1gnke030810 for nemo-archive@odin.ietf.org; Sat, 28 Feb 2004 20:42:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFyi-00080n-UP for nemo-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 20:42:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15143 for ; Sat, 28 Feb 2004 20:42:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxFyg-0006HJ-00 for nemo-web-archive@ietf.org; Sat, 28 Feb 2004 20:42:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxFxQ-0005yD-00 for nemo-web-archive@ietf.org; Sat, 28 Feb 2004 20:41:29 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AxFvb-0005iI-05 for nemo-web-archive@ietf.org; Sat, 28 Feb 2004 20:39:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AxFgh-0007wX-L0 for nemo-web-archive@ietf.org; Sat, 28 Feb 2004 20:24:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFgc-0005WB-1t; Sat, 28 Feb 2004 20:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxEom-0002H6-Br for nemo@optimus.ietf.org; Sat, 28 Feb 2004 19:28:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12295 for ; Sat, 28 Feb 2004 19:28:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxEok-0005zD-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:28:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxEnN-0005ko-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:27:02 -0500 Received: from nam.ietf59.or.kr ([218.37.196.23]) by ietf-mx with esmtp (Exim 4.12) id 1AxEmb-0005at-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:26:13 -0500 Received: from lolo (lolo.dhcp.ietf59.or.kr [218.37.225.195]) by nam.ietf59.or.kr (8.12.11/8.12.11) with SMTP id i1T0PsEd057749; Sun, 29 Feb 2004 09:26:01 +0900 (KST) (envelope-from mbagnulo@ing.uc3m.es) X-Authentication-Warning: nam.ietf59.or.kr: Host lolo.dhcp.ietf59.or.kr [218.37.225.195] claimed to be lolo Reply-To: From: "marcelo bagnulo" To: "Chan-Wah NG" Cc: "Mattias Pettersson" , "Thierry Ernst" , "Eun Kyoung Paik" , "IETF NEMO WG" Subject: RE: [nemo] merged multihoming draft Date: Sun, 29 Feb 2004 01:24:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 V5.50.4522.1200 In-Reply-To: <1077763658.5418.23.camel@localhost> Importance: Normal X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.24.0.5; VDF 6.24.0.25 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > In this case, it is not the mobile network that is multihomed, but the > MNN is multihomed. And MR shouldn't prevent it (as per > draft-ietf-nemo-requirements) I don't really agree with this definition, see coments about the terminology draft > > > I mean, i would say that a natural case for this is that the > Home network is > > multihomed, but not really the Mobile Network. > > In this case, i guess that there is nothing NEMO specific, only > that general > > multi6 solutions have to be supported. > > > > In a fixed network, as you or Mattias mentioned in an earlier post, no > administrator would be crazy enough to build a network, configured it > with multiple prefixes but have each router handles only one prefix and > discards packets with source addresses from the other prefixes. > > In NEMO, this scenario becomes possible. Consider two NEMOs coming > together, or a NEMO with two MRs, each subscribing to services from > different ISPs. > > It may not be NEMO-specific, depending on your interpretation of > "NEMO-specific". But IMHO its clear that NEMO make the problem more > "real". > > The draft's objective to raise the readers' awareness to this kind of > problems. Having done that, if the WG feels that it is worthwhile to > solve it here, we then discuss how to solve it. If the WG feels that > this is better left until a candidate solution emerged from multi6, we > mention this is the document, and points interested implementors to > consider the solutions coming out of the multi6 group. > Does this make sense? Yes. Regards, marcelo > > /rgds > /cwng > From exim@www1.ietf.org Sat Feb 28 20:43:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15253 for ; Sat, 28 Feb 2004 20:43:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFyn-00082Y-Mi for nemo-archive@odin.ietf.org; Sat, 28 Feb 2004 20:42:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T1grXN030900 for nemo-archive@odin.ietf.org; Sat, 28 Feb 2004 20:42:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFyn-00082J-IT for nemo-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 20:42:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15165 for ; Sat, 28 Feb 2004 20:42:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxFyl-0006Hv-00 for nemo-web-archive@ietf.org; Sat, 28 Feb 2004 20:42:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxFxV-0005zZ-00 for nemo-web-archive@ietf.org; Sat, 28 Feb 2004 20:41:34 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AxFvb-0005iR-06 for nemo-web-archive@ietf.org; Sat, 28 Feb 2004 20:39:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AxFgh-0007wY-L5 for nemo-web-archive@ietf.org; Sat, 28 Feb 2004 20:24:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFga-0005Vi-4O; Sat, 28 Feb 2004 20:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxEoh-0002Gw-7B for nemo@optimus.ietf.org; Sat, 28 Feb 2004 19:28:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12277 for ; Sat, 28 Feb 2004 19:28:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxEob-0005xG-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:28:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxEnI-0005k7-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:26:57 -0500 Received: from nam.ietf59.or.kr ([218.37.196.23]) by ietf-mx with esmtp (Exim 4.12) id 1AxEmU-0005aa-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:26:06 -0500 Received: from lolo (lolo.dhcp.ietf59.or.kr [218.37.225.195]) by nam.ietf59.or.kr (8.12.11/8.12.11) with SMTP id i1T0PsEZ057749; Sun, 29 Feb 2004 09:25:57 +0900 (KST) (envelope-from mbagnulo@ing.uc3m.es) X-Authentication-Warning: nam.ietf59.or.kr: Host lolo.dhcp.ietf59.or.kr [218.37.225.195] claimed to be lolo Reply-To: From: "marcelo bagnulo" To: "Thierry Ernst" Cc: Subject: comments about the terminolohy draft (was: RE: [nemo] merged multihoming draft) Date: Sun, 29 Feb 2004 01:23:57 +0100 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20040226180557.37e4571d.ernst@sfc.wide.ad.jp> Importance: Normal X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.24.0.5; VDF 6.24.0.25 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Thierry, > This is may be a definition issue ? I agree that taking the definition > to the words may tell that any host in the Internet is multihomed since > border routers usually are. I would indeed say that the MRs might be > multihoming, but the MNNs might not be. Yes, agree with you. see my comments below. > > I would appreciate if you could read through the multihoming section in > draft-ietf-nemo-terminology and comment on the definition. That would be > helpful for us. Comments about the terminology draft: Section 3.4: i would include the definition of Mobile router, even if it would mean to copy it from draft-ietf-seambody-terminology, so that the draft it is self-contained. I mean, if it is not included, the draft is harder to read, since you have to check with the other document. Section 3.5 same comment than 3.4 Section 3.6 same comment than 3.4 Section 3.9 same comment than 3.4 Section 3.11 I think that this definition is confusing (as it was expressed by the visiting nodes thread recently IMHO) consider the case of a node that attaches the NEMO using dhcp because it just wants connectivity. This is not a VMN, it is just a LFN in this context. IMHO, the definition included in section 2. is much better since it reads: " fixed nodes(nodes unable to change their point of attachment while maintaining ongoing sessions)," this is IMHO the appropriate definition of LFN (and it is already included in the draft :-) Section 3.12 This definition is also confusing IMHO, since it includes as a mobile node, a node accessing through dhcp. There is also in Section 2 a more appropriate definition of mobile node: " mobile nodes (nodes able to change their point of attachment while maintaining ongoing sessions)." I would add that a LMN has it HoA that belongs to the MNP Section 3.13 This is also confusing IMHO. I would use the same definition proposed above for LMN but changing that the HoA does not belong to the MNP Section 3.17 does the CN support MIPv6 RO or not or it is indifferent? Section 5.1 If multiaddressed nodes are considered multihomed, then, as you already noted, all nodes are multihomed, at least in IPv6 because of link local addresses. IMHO, including multiaddressed nodes as they are into the multihomed node definition, greatly reduces the meaning of the expression, since all the nodes are now multihomed, so multihomed node is synonymous of node, at that is not what we want i guess. We could add an additional condition, requiring that both addresses are global, but again, both addresses could belong to the same site (for whatever reason) and this is not what multihomed means. OTOH, i do understand that a node that has obtained addresses from different ISP, these addresses may have different properties, and selecting one or other may imply different services. This is also true in the case of a mobile node that has the HoA and the CoA, in this case using one or the other impacts in the characteristics of the packet flow. However, i think that the first case, it is a node within a multihomed site i.e. a multihomed site node, if you wish, and we could define it as this (Multihomed Network node: a node with multiple addresses, from different providers) and the second case it is just a mobile node. So, in order to provide a definition that matches the expected meaning (at least the meaning that i expect :-) of a multihomed node, IMHO the multiaddress case should be omitted. Section 5.1 delete the multi-sited case, since site locals are being deprecated Section 5.2 Again, i would not include the multiaddressed case as it is, since it means that because of the link local case all routers are multihomed and that some degenerated cases like the ones mentioned above are included as multihomed MR. So, i would omit this case. However, i would include in the multiple interfaces case the case of a MR with multiple tunnel interfaces. This is particularly true IMHO for the multihomed MR, when it has two different HA and two different tunnels, since it has two different accesses to the internet, one per HA. Section 5.3 Here the definitions don't really match, IMHO I mean it is stated that the NEMO is multihomed if it has more than one active interface connected to the internet (which i agree) But then, it states that this happens when the MR is multihomed. The problem here is that if the MR is simply multiaddresses, it doesn't have multiple egress interfaces, so both definitions don't match. Again, i would remove the multiaddressed case as it is currently stated. Perhaps it would be interesting to include the definition of a multiconnected NEMO, which is the case that the NEMO has multiple connections with its home network, but it doesn't have multiple ISPs. Section 5.4 Same than the multihomed NEMO case, a multihomed MR as stated may not have multiple active egress interfaces. Mostly editorial: Section 3 states that: " LFN, VMN and LMN. The distinction is a property of how different types of nodes can move in the topology and is necessary to discuss issues related to mobility management and access control, but does not preclude that mobility should be handled differently." I don't understand the meaning of the last sentence. I mean, what mobility are you referring to, to network mobility or to host mobility. If it is the last, i don't understand what do you say "preclude", wouldn't have to be changed to another verb, like "imply" Section 3.3 s/DEPRECIATED/DEPRECATED ^ Section 3.3 add a " to the second MONET Section 3.7 NEMO-Prefix (MNP) the acronym doesn't match the meaning. Include Mobile Network Prefix Section 3.14 NEMO-enabled (NEMO-node) add ^ "node" Section 4.5 s/depreciated/deprecated Section 5.5 remove the 1 in NEMO-11 Section 6.1 It reads "It could be achieved using Mobile IPv6" I would rephrase it to "It can be achieved using Mobile IP or other mobility support mechanism" because in the way that it is stated to me it seems that perhaps MIPv6 doesn't achieve mobility :-) Section 6.3 It reads: " NEMO Basic Support is a solution to preserve session continuity by means of bidirectional tunneling much like what is done using [1] for mobile nodes." [1] also specifies RO for mobile nodes, so i would add a "when RO is not used" at the end. Section References split into Normative references > > Thierry. > > From exim@www1.ietf.org Sat Feb 28 20:43:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15270 for ; Sat, 28 Feb 2004 20:43:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFyr-00083P-Jq for nemo-archive@odin.ietf.org; Sat, 28 Feb 2004 20:42:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T1gvXF030953 for nemo-archive@odin.ietf.org; Sat, 28 Feb 2004 20:42:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFyr-00083A-FC for nemo-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 20:42:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15184 for ; Sat, 28 Feb 2004 20:42:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxFyp-0006IP-00 for nemo-web-archive@ietf.org; Sat, 28 Feb 2004 20:42:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxFxa-00060l-00 for nemo-web-archive@ietf.org; Sat, 28 Feb 2004 20:41:38 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AxFvb-0005iV-05 for nemo-web-archive@ietf.org; Sat, 28 Feb 2004 20:39:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AxFgh-0007wa-Mm for nemo-web-archive@ietf.org; Sat, 28 Feb 2004 20:24:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFga-0005Vu-K0; Sat, 28 Feb 2004 20:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxEoh-0002Gx-Nn for nemo@optimus.ietf.org; Sat, 28 Feb 2004 19:28:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12287 for ; Sat, 28 Feb 2004 19:28:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxEoe-0005xd-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:28:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxEnL-0005kW-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:27:00 -0500 Received: from nam.ietf59.or.kr ([218.37.196.23]) by ietf-mx with esmtp (Exim 4.12) id 1AxEmZ-0005al-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:26:11 -0500 Received: from lolo (lolo.dhcp.ietf59.or.kr [218.37.225.195]) by nam.ietf59.or.kr (8.12.11/8.12.11) with SMTP id i1T0PsEf057749; Sun, 29 Feb 2004 09:26:02 +0900 (KST) (envelope-from mbagnulo@ing.uc3m.es) X-Authentication-Warning: nam.ietf59.or.kr: Host lolo.dhcp.ietf59.or.kr [218.37.225.195] claimed to be lolo Reply-To: From: "marcelo bagnulo" To: "Thierry Ernst" , "Mattias Pettersson" Cc: "nemo" Subject: RE: [nemo] merged multihoming draft Date: Sun, 29 Feb 2004 01:24:05 +0100 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20040226174436.2d0edbd9.ernst@sfc.wide.ad.jp> Importance: Normal X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.24.0.5; VDF 6.24.0.25 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Just one more detail: the fact that multiple prefixes are advertised on > the mobile network's egreess interface doesn't preclude that multiple > NEMO-prefixes will be advertised down the mobile network. But if you do that, the isp associated with the prefix that you are not announcing won't be used by the MNN (unless you rewrite the addresses at the exit or something like this) So you reduce the case to a single homed network. [...] > Not allowing to advertise multiple prefixes may be one recommendation, I don't think so, see above > but then, it means we have to design a protocol to synchronize MRs. I guess that you will need more than that, as stated above. > On > the other hand, if we allow the advertisement of multiple NEMO-prefixes, > MNNs have to select their source address. Yes, like in most of the multihomed site solutions. Regards, marcelo > > What I said is of course orthogonal with multiple NEMO-prefix > registration with the HA. > > > Such a general host behaviour may be required for multihoming > to work in > > IPv6 some day, but we have not reached that point yet. > > Thierry > From exim@www1.ietf.org Sat Feb 28 20:43:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15287 for ; Sat, 28 Feb 2004 20:43:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFyt-00083q-7o for nemo-archive@odin.ietf.org; Sat, 28 Feb 2004 20:42:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T1gx5R030980 for nemo-archive@odin.ietf.org; Sat, 28 Feb 2004 20:42:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFyt-00083b-2X for nemo-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 20:42:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15191 for ; Sat, 28 Feb 2004 20:42:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxFyq-0006IY-00 for nemo-web-archive@ietf.org; Sat, 28 Feb 2004 20:42:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxFxb-000619-00 for nemo-web-archive@ietf.org; Sat, 28 Feb 2004 20:41:40 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AxFvc-0005iR-00 for nemo-web-archive@ietf.org; Sat, 28 Feb 2004 20:39:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AxFgh-0007wW-L9 for nemo-web-archive@ietf.org; Sat, 28 Feb 2004 20:24:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFgb-0005W3-4M; Sat, 28 Feb 2004 20:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxEon-0002H7-Ky for nemo@optimus.ietf.org; Sat, 28 Feb 2004 19:28:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12298 for ; Sat, 28 Feb 2004 19:28:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxEol-00060W-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:28:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxEnO-0005kz-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:27:02 -0500 Received: from nam.ietf59.or.kr ([218.37.196.23]) by ietf-mx with esmtp (Exim 4.12) id 1AxEmb-0005au-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:26:13 -0500 Received: from lolo (lolo.dhcp.ietf59.or.kr [218.37.225.195]) by nam.ietf59.or.kr (8.12.11/8.12.11) with SMTP id i1T0PsEb057749; Sun, 29 Feb 2004 09:25:59 +0900 (KST) (envelope-from mbagnulo@ing.uc3m.es) X-Authentication-Warning: nam.ietf59.or.kr: Host lolo.dhcp.ietf59.or.kr [218.37.225.195] claimed to be lolo Reply-To: From: "marcelo bagnulo" To: "Thierry Ernst" Cc: , , , Subject: RE: [nemo] merged multihoming draft Date: Sun, 29 Feb 2004 01:24:02 +0100 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20040226180043.572c3fc1.ernst@sfc.wide.ad.jp> Importance: Normal X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.24.0.5; VDF 6.24.0.25 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > -----Mensaje original----- > De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]En nombre de Thierry > Ernst > Enviado el: jueves, 26 de febrero de 2004 10:01 > Para: mbagnulo@ing.uc3m.es > CC: mattias.l.pettersson@ericsson.com; cwng@psl.com.sg; > eun@mmlab.snu.ac.kr; nemo@ietf.org > Asunto: Re: [nemo] merged multihoming draft > > > > > Hi, > > > > It is a question on what entities should carry out the dirty work. > > > Either the MRs or the MNNs. > > > > Perhaps in the case of multiple prefixes, the dirty work has to > be carried > > by the Home Network Site Exit routers? > > Can we be more specific with 'dirty work' ? Well,a possibility to solve this problem is to create a mesh of tunnels between the exit router, so that they forward the packet to the exit isp router that it is connected to the ISP that matches the source address included in the packet > > > > To me it is important that legacy IPv6 hosts can still get > connectivity > > > in a moving network without having to implement new proposals such as > > > draft-huitema-multi6-hosts-xx. > > > > Fully agree with the first statement. > > But Host centric (draft-huitema-multi6-hosts) approach allows > exactly this > > for multihomed network. > > > > That is, that a regular IPv6 host is connected to the > multihomed network and > > still works properly. > > Clearly, there some benefits, like preserving established communications > > through outages, that it will not be able to obtain, but at > least it will > > work fine and its operation won't be disturbed because of multihoming. > > > > > > > > So what is most important: to support standard IPv6 hosts or > to simplify > > > the MR? > > > > I fully agree that standard IPv6 have to keep on working properly. > > Perhaps they won't obtain all the multihoming benefits, though > > > > > It seems like in order to simplify the MR we are proposing to > > > introduce a NEMO scenario that was considered "broken" in the IPv6 WG > > > earlier. All routers on a link are equal, from the host's > point of view! > > > > Well, again this IMHO is generic to multihoming and not > specific to nemo. > > I guess that if a hosts has to be updated to obtain full multihoming > > benefits in a fixed network, it would be reasonable that it > also has to be > > updated in order to obtain multihoming benefits in nemo. > > Fully agree. > > What is specific to NEMO WG is the ability to register several > NEMO-prefixes with the HA, if we need to. > > Obtaining all potential benefits of multihoming is not a NEMO task. It > should be carried on by another WG which doesn't focus on mobility. On > the other hand, our goal is to document the issues; I suspect actions > will have been taken by other WGs based on the conclusions of the NEMO > Multihoming Pb Statement WG document. I agree. I guess that the problem here is to identify which are the NEMO specific issues that are not present in the general case of a multihomed site. See my answer to Mattias w.r.t. this Regards, marcelo > > Thierry. > > > > > From exim@www1.ietf.org Sat Feb 28 20:43:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15304 for ; Sat, 28 Feb 2004 20:43:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFyt-00084K-UB for nemo-archive@odin.ietf.org; Sat, 28 Feb 2004 20:42:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T1gx6Q031010 for nemo-archive@odin.ietf.org; Sat, 28 Feb 2004 20:42:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFyt-00083t-O6 for nemo-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 20:42:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15195 for ; Sat, 28 Feb 2004 20:42:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxFyr-0006Ik-00 for nemo-web-archive@ietf.org; Sat, 28 Feb 2004 20:42:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxFxc-00061M-00 for nemo-web-archive@ietf.org; Sat, 28 Feb 2004 20:41:41 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AxFvc-0005iV-00 for nemo-web-archive@ietf.org; Sat, 28 Feb 2004 20:39:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AxFgh-0007wZ-LE for nemo-web-archive@ietf.org; Sat, 28 Feb 2004 20:24:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFgc-0005Xh-VV; Sat, 28 Feb 2004 20:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxEop-0002HH-ME for nemo@optimus.ietf.org; Sat, 28 Feb 2004 19:28:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12307 for ; Sat, 28 Feb 2004 19:28:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxEon-00062V-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:28:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxEnQ-0005lN-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:27:05 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AxEmf-0005b4-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:26:17 -0500 Received: from nam.ietf59.or.kr ([218.37.196.23]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AxEme-0005pk-MI for nemo@ietf.org; Sat, 28 Feb 2004 19:26:17 -0500 Received: from lolo (lolo.dhcp.ietf59.or.kr [218.37.225.195]) by nam.ietf59.or.kr (8.12.11/8.12.11) with SMTP id i1T0PsEh057749; Sun, 29 Feb 2004 09:26:03 +0900 (KST) (envelope-from mbagnulo@ing.uc3m.es) X-Authentication-Warning: nam.ietf59.or.kr: Host lolo.dhcp.ietf59.or.kr [218.37.225.195] claimed to be lolo Reply-To: From: "marcelo bagnulo" To: "Mattias Pettersson" Cc: "Thierry Ernst" , , , Subject: RE: [nemo] merged multihoming draft Date: Sun, 29 Feb 2004 01:24:06 +0100 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <403DC0A1.6010000@ericsson.com> Importance: Normal X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.24.0.5; VDF 6.24.0.25 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Yes, sorry, for case N,1,N I fully agree. It is the home network that is > multihomed and it will ultimately have to deal with this. The MRs can > get away with their behaviour. So why don't we just split these two different cases: there are four different situations to be considered of NEMO with multiple prefixes, according to the draft: (sorry that i dont use the (x,y,z) notation, i am still getting used to it) Multiple prefixes with single home address and single MR Multiple prefixes with multiple home address and single MR Multiple prefixes with single home address and multiple MR Multiple prefixes with multiple home address and multiple MR IMHO, the first case and the third case are not about a multihomed NEMO but about a multihomed Home network I agree that the second and the fourth case can be about a multihomed nemo > > > o (N,N,N) Mobile Network > > > > The (N,N,N) mobile network has multiple mobile routers, > > registering to multiple home-agents and advertising prefixes. > > This may be a case of multiple non-multihomed network superimposed > > together, i.e. each mobile router take cares of one prefix, and > > register to separate home agents. > > It is the N, N, N (alternative 1, see above) that I've drifted into. > This is the case where NEMO introduces more requirements on hosts than > what ND does. > > Look at this case from the MNN's point of view. It hears two routers > (MRs) advertising themselves as capable of routing all traffic (i.e. > stating that they are default routers). To follow the example in > draft-huitema-multi6-hosts section 3.3 we have MNN as X with two > addresses A:X and B:X. It wants to communicate with Y both available at > C:Y and D:Y. If X can't be allowed to establish a communication between > any of the four combinations {ax-cy, bx-cy, ax-dy, bx-dy} then something > is seriously wrong with the configuration of the network. As far as X > goes it MUST NOT have to know that site-exit router R-A only accepts > packets with source address with prefix A. Why is a default router > claiming that it can route all traffic only to drop some of it the next > minute? Well, this is the site exit issue, decribedin the draft and it is common to all multihomed sites that have multiple prefixes. This is not specific to NEMO > > None of the cases that I've seen in IPv6 and multi6 claim that X must > select the correct default router in order to communicate. Well, i would state it otherwise. IMHO it is important that any multihoming solution supports "legacy" hosts that don't implement new mechanisms. So, i agree with you, and again this is common to any multihomed site However, some optimizations may require that the host selects the apropriate exit router or the apropriate prefix in order to reach a certain destiantion, but these must be only optimizations, and they must preclude the normal operation of legacy hosts. > Yes, the > packet must have the right source address to be carried over the ISP's > network, but that is something the routers have to deal with. Yes, ISP B > may be "better" in some sense (and sometimes routers only route on > destination addresses, which is bad in this case), but unless X knows > that, how can it know what source address to use for its default traffic? As mentioned, legacy host has to be supported in a multihoming solution, see RFC 3582 "3.2.3. Impact on Hosts The solution should not destroy IPv6 connectivity for a legacy host implementing RFC 3513 [3], RFC 2460 [4], RFC 3493 [5], and other basic IPv6 specifications current in April 2003. That is to say, if a host can work in a single-homed site, it should still be able to work in a multihomed site, even if it cannot benefit from site- multihoming." > > To me it is a serious mistake by a router to claim it is a default > router if it really isn't. Until the hosts get more information about > ISP preferences and ingress filtering policies, the router must deal > with this mess. I fully agree with you > > So, yes, to answer your question: NEMO case N,N,N introduces a (broken) > network configuration previously unknown to/unsupported by IPv6 > and multi6. Here is where we disagree :-) This is exactly the same situation than in any multihomed site that announces multiple prefixes. A multihoming solution has to provide a solution for this, fulfilling the requirement to honor legacy hosts as you require. Regards, marcelo > > /Mattias > > > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you believe this message has been > sent to you in error, please notify the sender by replying to > this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and > we only send and receive e-mails on the basis that we are not > liable for any such corruption, interception, amendment, > tampering or viruses or any consequences thereof. > From nemo-admin@ietf.org Sat Feb 28 21:11:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14219 for ; Sat, 28 Feb 2004 20:24:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFgc-0005WB-1t; Sat, 28 Feb 2004 20:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxEom-0002H6-Br for nemo@optimus.ietf.org; Sat, 28 Feb 2004 19:28:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12295 for ; Sat, 28 Feb 2004 19:28:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxEok-0005zD-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:28:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxEnN-0005ko-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:27:02 -0500 Received: from nam.ietf59.or.kr ([218.37.196.23]) by ietf-mx with esmtp (Exim 4.12) id 1AxEmb-0005at-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:26:13 -0500 Received: from lolo (lolo.dhcp.ietf59.or.kr [218.37.225.195]) by nam.ietf59.or.kr (8.12.11/8.12.11) with SMTP id i1T0PsEd057749; Sun, 29 Feb 2004 09:26:01 +0900 (KST) (envelope-from mbagnulo@ing.uc3m.es) X-Authentication-Warning: nam.ietf59.or.kr: Host lolo.dhcp.ietf59.or.kr [218.37.225.195] claimed to be lolo Reply-To: From: "marcelo bagnulo" To: "Chan-Wah NG" Cc: "Mattias Pettersson" , "Thierry Ernst" , "Eun Kyoung Paik" , "IETF NEMO WG" Subject: RE: [nemo] merged multihoming draft Date: Sun, 29 Feb 2004 01:24:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 V5.50.4522.1200 In-Reply-To: <1077763658.5418.23.camel@localhost> Importance: Normal X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.24.0.5; VDF 6.24.0.25 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 this case, it is not the mobile network that is multihomed, but the > MNN is multihomed. And MR shouldn't prevent it (as per > draft-ietf-nemo-requirements) I don't really agree with this definition, see coments about the terminology draft > > > I mean, i would say that a natural case for this is that the > Home network is > > multihomed, but not really the Mobile Network. > > In this case, i guess that there is nothing NEMO specific, only > that general > > multi6 solutions have to be supported. > > > > In a fixed network, as you or Mattias mentioned in an earlier post, no > administrator would be crazy enough to build a network, configured it > with multiple prefixes but have each router handles only one prefix and > discards packets with source addresses from the other prefixes. > > In NEMO, this scenario becomes possible. Consider two NEMOs coming > together, or a NEMO with two MRs, each subscribing to services from > different ISPs. > > It may not be NEMO-specific, depending on your interpretation of > "NEMO-specific". But IMHO its clear that NEMO make the problem more > "real". > > The draft's objective to raise the readers' awareness to this kind of > problems. Having done that, if the WG feels that it is worthwhile to > solve it here, we then discuss how to solve it. If the WG feels that > this is better left until a candidate solution emerged from multi6, we > mention this is the document, and points interested implementors to > consider the solutions coming out of the multi6 group. > Does this make sense? Yes. Regards, marcelo > > /rgds > /cwng > From nemo-admin@ietf.org Sat Feb 28 21:11:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14223 for ; Sat, 28 Feb 2004 20:24:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFgc-0005Xh-VV; Sat, 28 Feb 2004 20:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxEop-0002HH-ME for nemo@optimus.ietf.org; Sat, 28 Feb 2004 19:28:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12307 for ; Sat, 28 Feb 2004 19:28:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxEon-00062V-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:28:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxEnQ-0005lN-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:27:05 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AxEmf-0005b4-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:26:17 -0500 Received: from nam.ietf59.or.kr ([218.37.196.23]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AxEme-0005pk-MI for nemo@ietf.org; Sat, 28 Feb 2004 19:26:17 -0500 Received: from lolo (lolo.dhcp.ietf59.or.kr [218.37.225.195]) by nam.ietf59.or.kr (8.12.11/8.12.11) with SMTP id i1T0PsEh057749; Sun, 29 Feb 2004 09:26:03 +0900 (KST) (envelope-from mbagnulo@ing.uc3m.es) X-Authentication-Warning: nam.ietf59.or.kr: Host lolo.dhcp.ietf59.or.kr [218.37.225.195] claimed to be lolo Reply-To: From: "marcelo bagnulo" To: "Mattias Pettersson" Cc: "Thierry Ernst" , , , Subject: RE: [nemo] merged multihoming draft Date: Sun, 29 Feb 2004 01:24:06 +0100 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <403DC0A1.6010000@ericsson.com> Importance: Normal X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.24.0.5; VDF 6.24.0.25 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 > Yes, sorry, for case N,1,N I fully agree. It is the home network that is > multihomed and it will ultimately have to deal with this. The MRs can > get away with their behaviour. So why don't we just split these two different cases: there are four different situations to be considered of NEMO with multiple prefixes, according to the draft: (sorry that i dont use the (x,y,z) notation, i am still getting used to it) Multiple prefixes with single home address and single MR Multiple prefixes with multiple home address and single MR Multiple prefixes with single home address and multiple MR Multiple prefixes with multiple home address and multiple MR IMHO, the first case and the third case are not about a multihomed NEMO but about a multihomed Home network I agree that the second and the fourth case can be about a multihomed nemo > > > o (N,N,N) Mobile Network > > > > The (N,N,N) mobile network has multiple mobile routers, > > registering to multiple home-agents and advertising prefixes. > > This may be a case of multiple non-multihomed network superimposed > > together, i.e. each mobile router take cares of one prefix, and > > register to separate home agents. > > It is the N, N, N (alternative 1, see above) that I've drifted into. > This is the case where NEMO introduces more requirements on hosts than > what ND does. > > Look at this case from the MNN's point of view. It hears two routers > (MRs) advertising themselves as capable of routing all traffic (i.e. > stating that they are default routers). To follow the example in > draft-huitema-multi6-hosts section 3.3 we have MNN as X with two > addresses A:X and B:X. It wants to communicate with Y both available at > C:Y and D:Y. If X can't be allowed to establish a communication between > any of the four combinations {ax-cy, bx-cy, ax-dy, bx-dy} then something > is seriously wrong with the configuration of the network. As far as X > goes it MUST NOT have to know that site-exit router R-A only accepts > packets with source address with prefix A. Why is a default router > claiming that it can route all traffic only to drop some of it the next > minute? Well, this is the site exit issue, decribedin the draft and it is common to all multihomed sites that have multiple prefixes. This is not specific to NEMO > > None of the cases that I've seen in IPv6 and multi6 claim that X must > select the correct default router in order to communicate. Well, i would state it otherwise. IMHO it is important that any multihoming solution supports "legacy" hosts that don't implement new mechanisms. So, i agree with you, and again this is common to any multihomed site However, some optimizations may require that the host selects the apropriate exit router or the apropriate prefix in order to reach a certain destiantion, but these must be only optimizations, and they must preclude the normal operation of legacy hosts. > Yes, the > packet must have the right source address to be carried over the ISP's > network, but that is something the routers have to deal with. Yes, ISP B > may be "better" in some sense (and sometimes routers only route on > destination addresses, which is bad in this case), but unless X knows > that, how can it know what source address to use for its default traffic? As mentioned, legacy host has to be supported in a multihoming solution, see RFC 3582 "3.2.3. Impact on Hosts The solution should not destroy IPv6 connectivity for a legacy host implementing RFC 3513 [3], RFC 2460 [4], RFC 3493 [5], and other basic IPv6 specifications current in April 2003. That is to say, if a host can work in a single-homed site, it should still be able to work in a multihomed site, even if it cannot benefit from site- multihoming." > > To me it is a serious mistake by a router to claim it is a default > router if it really isn't. Until the hosts get more information about > ISP preferences and ingress filtering policies, the router must deal > with this mess. I fully agree with you > > So, yes, to answer your question: NEMO case N,N,N introduces a (broken) > network configuration previously unknown to/unsupported by IPv6 > and multi6. Here is where we disagree :-) This is exactly the same situation than in any multihomed site that announces multiple prefixes. A multihoming solution has to provide a solution for this, fulfilling the requirement to honor legacy hosts as you require. Regards, marcelo > > /Mattias > > > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you believe this message has been > sent to you in error, please notify the sender by replying to > this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and > we only send and receive e-mails on the basis that we are not > liable for any such corruption, interception, amendment, > tampering or viruses or any consequences thereof. > From nemo-admin@ietf.org Sat Feb 28 21:11:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14221 for ; Sat, 28 Feb 2004 20:24:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFga-0005Vi-4O; Sat, 28 Feb 2004 20:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxEoh-0002Gw-7B for nemo@optimus.ietf.org; Sat, 28 Feb 2004 19:28:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12277 for ; Sat, 28 Feb 2004 19:28:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxEob-0005xG-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:28:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxEnI-0005k7-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:26:57 -0500 Received: from nam.ietf59.or.kr ([218.37.196.23]) by ietf-mx with esmtp (Exim 4.12) id 1AxEmU-0005aa-00 for nemo@ietf.org; Sat, 28 Feb 2004 19:26:06 -0500 Received: from lolo (lolo.dhcp.ietf59.or.kr [218.37.225.195]) by nam.ietf59.or.kr (8.12.11/8.12.11) with SMTP id i1T0PsEZ057749; Sun, 29 Feb 2004 09:25:57 +0900 (KST) (envelope-from mbagnulo@ing.uc3m.es) X-Authentication-Warning: nam.ietf59.or.kr: Host lolo.dhcp.ietf59.or.kr [218.37.225.195] claimed to be lolo Reply-To: From: "marcelo bagnulo" To: "Thierry Ernst" Cc: Subject: comments about the terminolohy draft (was: RE: [nemo] merged multihoming draft) Date: Sun, 29 Feb 2004 01:23:57 +0100 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20040226180557.37e4571d.ernst@sfc.wide.ad.jp> Importance: Normal X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.24.0.5; VDF 6.24.0.25 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Thierry, > This is may be a definition issue ? I agree that taking the definition > to the words may tell that any host in the Internet is multihomed since > border routers usually are. I would indeed say that the MRs might be > multihoming, but the MNNs might not be. Yes, agree with you. see my comments below. > > I would appreciate if you could read through the multihoming section in > draft-ietf-nemo-terminology and comment on the definition. That would be > helpful for us. Comments about the terminology draft: Section 3.4: i would include the definition of Mobile router, even if it would mean to copy it from draft-ietf-seambody-terminology, so that the draft it is self-contained. I mean, if it is not included, the draft is harder to read, since you have to check with the other document. Section 3.5 same comment than 3.4 Section 3.6 same comment than 3.4 Section 3.9 same comment than 3.4 Section 3.11 I think that this definition is confusing (as it was expressed by the visiting nodes thread recently IMHO) consider the case of a node that attaches the NEMO using dhcp because it just wants connectivity. This is not a VMN, it is just a LFN in this context. IMHO, the definition included in section 2. is much better since it reads: " fixed nodes(nodes unable to change their point of attachment while maintaining ongoing sessions)," this is IMHO the appropriate definition of LFN (and it is already included in the draft :-) Section 3.12 This definition is also confusing IMHO, since it includes as a mobile node, a node accessing through dhcp. There is also in Section 2 a more appropriate definition of mobile node: " mobile nodes (nodes able to change their point of attachment while maintaining ongoing sessions)." I would add that a LMN has it HoA that belongs to the MNP Section 3.13 This is also confusing IMHO. I would use the same definition proposed above for LMN but changing that the HoA does not belong to the MNP Section 3.17 does the CN support MIPv6 RO or not or it is indifferent? Section 5.1 If multiaddressed nodes are considered multihomed, then, as you already noted, all nodes are multihomed, at least in IPv6 because of link local addresses. IMHO, including multiaddressed nodes as they are into the multihomed node definition, greatly reduces the meaning of the expression, since all the nodes are now multihomed, so multihomed node is synonymous of node, at that is not what we want i guess. We could add an additional condition, requiring that both addresses are global, but again, both addresses could belong to the same site (for whatever reason) and this is not what multihomed means. OTOH, i do understand that a node that has obtained addresses from different ISP, these addresses may have different properties, and selecting one or other may imply different services. This is also true in the case of a mobile node that has the HoA and the CoA, in this case using one or the other impacts in the characteristics of the packet flow. However, i think that the first case, it is a node within a multihomed site i.e. a multihomed site node, if you wish, and we could define it as this (Multihomed Network node: a node with multiple addresses, from different providers) and the second case it is just a mobile node. So, in order to provide a definition that matches the expected meaning (at least the meaning that i expect :-) of a multihomed node, IMHO the multiaddress case should be omitted. Section 5.1 delete the multi-sited case, since site locals are being deprecated Section 5.2 Again, i would not include the multiaddressed case as it is, since it means that because of the link local case all routers are multihomed and that some degenerated cases like the ones mentioned above are included as multihomed MR. So, i would omit this case. However, i would include in the multiple interfaces case the case of a MR with multiple tunnel interfaces. This is particularly true IMHO for the multihomed MR, when it has two different HA and two different tunnels, since it has two different accesses to the internet, one per HA. Section 5.3 Here the definitions don't really match, IMHO I mean it is stated that the NEMO is multihomed if it has more than one active interface connected to the internet (which i agree) But then, it states that this happens when the MR is multihomed. The problem here is that if the MR is simply multiaddresses, it doesn't have multiple egress interfaces, so both definitions don't match. Again, i would remove the multiaddressed case as it is currently stated. Perhaps it would be interesting to include the definition of a multiconnected NEMO, which is the case that the NEMO has multiple connections with its home network, but it doesn't have multiple ISPs. Section 5.4 Same than the multihomed NEMO case, a multihomed MR as stated may not have multiple active egress interfaces. Mostly editorial: Section 3 states that: " LFN, VMN and LMN. The distinction is a property of how different types of nodes can move in the topology and is necessary to discuss issues related to mobility management and access control, but does not preclude that mobility should be handled differently." I don't understand the meaning of the last sentence. I mean, what mobility are you referring to, to network mobility or to host mobility. If it is the last, i don't understand what do you say "preclude", wouldn't have to be changed to another verb, like "imply" Section 3.3 s/DEPRECIATED/DEPRECATED ^ Section 3.3 add a " to the second MONET Section 3.7 NEMO-Prefix (MNP) the acronym doesn't match the meaning. Include Mobile Network Prefix Section 3.14 NEMO-enabled (NEMO-node) add ^ "node" Section 4.5 s/depreciated/deprecated Section 5.5 remove the 1 in NEMO-11 Section 6.1 It reads "It could be achieved using Mobile IPv6" I would rephrase it to "It can be achieved using Mobile IP or other mobility support mechanism" because in the way that it is stated to me it seems that perhaps MIPv6 doesn't achieve mobility :-) Section 6.3 It reads: " NEMO Basic Support is a solution to preserve session continuity by means of bidirectional tunneling much like what is done using [1] for mobile nodes." [1] also specifies RO for mobile nodes, so i would add a "when RO is not used" at the end. Section References split into Normative references > > Thierry. > > From nemo-admin@ietf.org Sun Feb 29 03:56:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13295 for ; Sun, 29 Feb 2004 03:56:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMjz-0005gr-9m; Sun, 29 Feb 2004 03:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMjk-0005cX-Qk for nemo@optimus.ietf.org; Sun, 29 Feb 2004 03:55:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13273 for ; Sun, 29 Feb 2004 03:55:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxMji-0000GG-00 for nemo@ietf.org; Sun, 29 Feb 2004 03:55:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxMin-0000Bf-00 for nemo@ietf.org; Sun, 29 Feb 2004 03:54:50 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1AxMiK-00006c-00 for nemo@ietf.org; Sun, 29 Feb 2004 03:54:20 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i1T8s8ha019553; Sun, 29 Feb 2004 00:54:09 -0800 (PST) Message-ID: <404190B7.50302@cs.ucdavis.edu> Date: Sat, 28 Feb 2004 23:11:51 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG CC: "Fan Zhao" , Souhwan Jung , wu@cs.ucdavis.edu Subject: [nemo] can an HA itself be an MNN under NEMO? References: <1077784218.790.15.camel@acorde> <1077850151.5540.30.camel@localhost> In-Reply-To: <1077850151.5540.30.camel@localhost> Content-Type: multipart/mixed; boundary="------------060809070605000901050709" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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. --------------060809070605000901050709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, During our analysis of multi-homing and nested NEMO cases, we have encountered a question, hopefully get some clarifications from the NEMO working group: -- Can an HA itself be an MNN under the NEMO context? Please see our attached PDF file for our preliminary analysis on this issue. It seems to us that this can be allowed for MIPv6, but should NOT be allowed for NEMO (otherwise, we might have a loop, and the multi-homing issue might be more complex). -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- --------------060809070605000901050709 Content-Type: application/pdf; name="NEMO-HA-as-MNN.pdf" Content-Disposition: inline; filename="NEMO-HA-as-MNN.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjINJeLjz9MNCjMyIDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyAzNCANL0gg WyA2NjIgMjUxIF0gDS9MIDE0MDY0IA0vRSAzMzIyIA0vTiA5IA0vVCAxMzMwNiANPj4gDWVu ZG9iag0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB4cmVmDTMyIDEzIA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA2MDcg MDAwMDAgbg0KMDAwMDAwMDkxMyAwMDAwMCBuDQowMDAwMDAxMDY4IDAwMDAwIG4NCjAwMDAw MDEyMTUgMDAwMDAgbg0KMDAwMDAwMTM5NSAwMDAwMCBuDQowMDAwMDAxNzQ1IDAwMDAwIG4N CjAwMDAwMDIyOTMgMDAwMDAgbg0KMDAwMDAwMjQ4MCAwMDAwMCBuDQowMDAwMDAyNjgyIDAw MDAwIG4NCjAwMDAwMDMwOTIgMDAwMDAgbg0KMDAwMDAwMDY2MiAwMDAwMCBuDQowMDAwMDAw ODkyIDAwMDAwIG4NCnRyYWlsZXINPDwNL1NpemUgNDUNL0luZm8gMzEgMCBSIA0vUm9vdCAz MyAwIFIgDS9QcmV2IDEzMjk2IA0vSURbPDg1OGQ1Y2I3MDMwYzEzNmI3ZmM1ZWMyMTZiOWFm NGU2Pjw4NThkNWNiNzAzMGMxMzZiN2ZjNWVjMjE2YjlhZjRlNj5dDT4+DXN0YXJ0eHJlZg0w DSUlRU9GDSAgICAgDTMzIDAgb2JqDTw8IA0vVHlwZSAvQ2F0YWxvZyANL1BhZ2VzIDMwIDAg UiANPj4gDWVuZG9iag00MyAwIG9iag08PCAvUyAxMzAgL0ZpbHRlciAvRmxhdGVEZWNvZGUg L0xlbmd0aCA0NCAwIFIgPj4gDXN0cmVhbQ0KSIliYGBgZmBgmsbAAiSXMHAzIAA3UAwEORJA vKMLbRYLH2CoXc4swLsgZbpnuQNQMERDJXLN7ZagOStCNFw1T+0FsYB0q1MDo7AFAwcDo0to A4OQBoilZNzAwCjBwCDYwNCAYhbQGEkGBt3VQJoTiPnAdvsxcKpN9LnIt3HLTx8GNoEvzpEX GBgAAgwARjgleA1lbmRzdHJlYW0NZW5kb2JqDTQ0IDAgb2JqDTE0NSANZW5kb2JqDTM0IDAg b2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAzMCAwIFIgDS9SZXNvdXJjZXMgMzUgMCBS IA0vQ29udGVudHMgMzcgMCBSIA0vUm90YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5 MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDT4+IA1lbmRvYmoNMzUgMCBvYmoNPDwg DS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDM4IDAgUiAvVFQ0IDQx IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQyIDAgUiA+PiANL0NvbG9yU3BhY2UgPDwg L0NzNSAzNiAwIFIgPj4gDT4+IA1lbmRvYmoNMzYgMCBvYmoNWyANL0NhbFJHQiA8PCAvV2hp dGVQb2ludCBbIDAuOTUwNSAxIDEuMDg5IF0gL0dhbW1hIFsgMi4yMjIyMSAyLjIyMjIxIDIu MjIyMjEgXSANL01hdHJpeCBbIDAuNDEyNCAwLjIxMjYgMC4wMTkzIDAuMzU3NiAwLjcxNTE5 IDAuMTE5MiAwLjE4MDUgMC4wNzIyIDAuOTUwNSBdID4+IA0NXQ1lbmRvYmoNMzcgMCBvYmoN PDwgL0xlbmd0aCAyNzYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIlM0Etr wkAUBeD9/IqzjGCud16ZcVVaqy2CduFAoaWLqPFRbATTYH9+ZxIq5e6Gw7nf3NGksdg0kN00 GzF6WknsGyFxhNAFnC1gDSN3inGpxE48BDEKQcV42AmGYWJtLXI9pnEBhrSWCgOpNXmErxhJ E6vzmGTWCJv4Fq4im5Q1nu9x/G6q0w5YVyixWC7R1tvqgkH4FIYcW49ckmKpEB77Epk6suV0 8XKXUpFj/jjKU0yOkSvXc3TB5KLWKOLekxRdQ99VJMt7tjq3h2tZD3JlNZls3tb7IVaEWXU6 /uC1HaKst5hF8tuhPA8+wvzfGRxJr6NTkffeJGe3xd22KNX9eFatoZhNUk+D+BVgAATXVyYK ZW5kc3RyZWFtDWVuZG9iag0zOCAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9U cnVlVHlwZSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDE1MCANL1dpZHRocyBbIDI1MCAw IDAgNTAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMjUwIDMzMyAyNTAgMjc4IDUwMCA1MDAgNTAw IDUwMCA1MDAgDTUwMCA1MDAgNTAwIDUwMCAwIDI3OCAwIDAgMCAwIDQ0NCAwIDcyMiA2Njcg NjY3IDAgNjExIDU1NiAwIDcyMiANMzMzIDAgMCA2MTEgODg5IDcyMiA3MjIgNTU2IDAgNjY3 IDU1NiA2MTEgMCAwIDk0NCAwIDAgMCAwIDAgMCAwIA0wIDAgNDQ0IDUwMCA0NDQgNTAwIDQ0 NCAzMzMgNTAwIDUwMCAyNzggMCA1MDAgMjc4IDc3OCA1MDAgNTAwIDUwMCANMCAzMzMgMzg5 IDI3OCA1MDAgNTAwIDcyMiA1MDAgNTAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAxMDAwIDAg MCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDQ0NCA0NDQgMzUwIDUwMCBdIA0vRW5jb2Rpbmcg L1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9UaW1lc05ld1JvbWFuIA0vRm9udERlc2Ny aXB0b3IgMzkgMCBSIA0+PiANZW5kb2JqDTM5IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2Ny aXB0b3IgDS9Bc2NlbnQgODkxIA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTYgDS9GbGFn cyAzNCANL0ZvbnRCQm94IFsgLTU2OCAtMzA3IDIwMjggMTAwNyBdIA0vRm9udE5hbWUgL1Rp bWVzTmV3Um9tYW4gDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMCANPj4gDWVuZG9iag00MCAw IG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDg5MSANL0NhcEhlaWdo dCAwIA0vRGVzY2VudCAtMjE2IA0vRmxhZ3MgOTggDS9Gb250QkJveCBbIC01NDcgLTMwNyAx MjA2IDEwMzIgXSANL0ZvbnROYW1lIC9UaW1lc05ld1JvbWFuLEJvbGRJdGFsaWMgDS9JdGFs aWNBbmdsZSAtMTUgDS9TdGVtViAxMzMgDT4+IA1lbmRvYmoNNDEgMCBvYmoNPDwgDS9UeXBl IC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAx MjAgDS9XaWR0aHMgWyAyNTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI1MCAwIDI1MCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCANMCAwIDAgMCAwIDAgMCAwIDY2NyAwIDAgMCA1 MDAgMCAwIDAgMCAwIDAgMCAwIDU1NiAwIDAgMCA4ODkgMCAwIA02MTEgMCAwIDAgMCAwIDAg NTAwIDAgMCA1MDAgNDQ0IDAgNTAwIDU1NiAyNzggMCAwIDI3OCAwIDU1NiA1MDAgDTAgMCAw IDAgMCA1NTYgMCA2NjcgNTAwIF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFz ZUZvbnQgL1RpbWVzTmV3Um9tYW4sQm9sZEl0YWxpYyANL0ZvbnREZXNjcmlwdG9yIDQwIDAg UiANPj4gDWVuZG9iag00MiAwIG9iag08PCANL1R5cGUgL0V4dEdTdGF0ZSANL1NBIGZhbHNl IA0vU00gMC4wMiANL1RSIC9JZGVudGl0eSANPj4gDWVuZG9iag0xIDAgb2JqDTw8IA0vVHlw ZSAvUGFnZSANL1BhcmVudCAzMCAwIFIgDS9SZXNvdXJjZXMgMiAwIFIgDS9Db250ZW50cyAz IDAgUiANL1JvdGF0ZSA5MCANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3gg WyAwIDAgNjEyIDc5MiBdIA0+PiANZW5kb2JqDTIgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BE RiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDM4IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1Mx IDQyIDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAzNiAwIFIgPj4gDT4+IA1lbmRvYmoN MyAwIG9iag08PCAvTGVuZ3RoIDM5NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiVSRzW7UMBSF936Ks3SkxuP/JKuqFASDVIRU7yoW09RpQzNJNU4pL8AjwPNynQwdKm9O fHO/e3zu5jI5tAlqOallm4/XCveJKfRgxqNyHs5KlJWWOETWsXeBbULQ9HvomIS1QmljUZKQ FhLKOkFVXyPsqZ4PcUsppFQaoWVZyQbhhfFtwvzQJ+xG9Ck9R/QjrrZff/jzInynZqOFktKh JLHAtfbCWjQVjSD8QpV1pq7SZ+wN/12UtlGi5tuC7h2fkWLcJ4zT/Kv4Fj4TWteC/DQodSUa n9G+ErWFMuZ/tjmxzcr+U5RGOuEzWwnLj47PsMOnC7T0lNtI+uoL+jnFoaPCeJc11smils6A WnV2+/4Id69z1JLM0+4QxzkTX/phIMQ4PY9tpLging6x63+imw7L5xrVAlTViahPxKPzfeHJ 9nTbD5HAYrFTnvxYq1Vul6+NWr95suHXOc6KT2e0rnVzacrUmsdCE5uuxnsM/WPEGNMcqdTw u5yT5v8Wm6d+COyvAAMAWF2YgQplbmRzdHJlYW0NZW5kb2JqDTQgMCBvYmoNPDwgDS9UeXBl IC9QYWdlIA0vUGFyZW50IDMwIDAgUiANL1Jlc291cmNlcyA1IDAgUiANL0NvbnRlbnRzIDYg MCBSIA0vUm90YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBb IDAgMCA2MTIgNzkyIF0gDT4+IA1lbmRvYmoNNSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERG IC9UZXh0IF0gDS9Gb250IDw8IC9GMSAyNSAwIFIgL1RUMiAzOCAwIFIgL1RUNiAyNiAwIFIg L1RUOCAyNyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0MiAwIFIgPj4gDS9Db2xvclNw YWNlIDw8IC9DczUgMzYgMCBSID4+IA0+PiANZW5kb2JqDTYgMCBvYmoNPDwgL0xlbmd0aCA2 MDggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImMVNtq20AQfd+vmEepoPXO 7FWPaeq2CaQYrIdAyIOjyEFuLsU2tdvfaD+4M5Kl2JCWIvDOynM55+xZTc43HuoNYPdsajX5 NEd42CiEFpQNEH0A7wwUkQysG7VU7ys1qSri9GqpDDinkayDggPjwEAZNYHFqIOD6okz5OHO hdHGIEFV87tqp7LpfvH07bHJq5Wack9Bcj6HPn9+zgguOViB0ZFgB2jgCm5uDdwr64OmBBgS eKsdIHnZM7q5oDNAAsV7KEgA2YQMETB6zRUCiYGY1GG4erlrHxv4fCYoJh9xYIVJG2sjFJi4 gzNG2+MOeEoKR1I32Wzd5EHHbNl2yx6u89vqUhhimcAlxhOEEbJCDG8AfSzpKXxidgzfpTjA Px1uu+GvlGaLdfO8PVCSsayhIldCCAEYenLCRTbIq/eoYx865lEriSiaTrE+FdkCUi9rrSxa zYFsLPc4pErY10t0aHpIlVHD/Fpt3joi5C5cQKlk7zDFjpnxR7L+2mwX27aeLPOkMWv3zX3u tct+w8UMnpvt7mX9tdOZdQyjjtwlxpJnmN6a1pMAIsR+jNGEAYbfWIZRVUbFs7OLs5moyEdl LTFYo32ZWOYP419TIbOCnrYLvSFD+R/nakujk2Ot7JvnKqfJCK6+/NuZ2FF7bfKWM2+ya42d G8kOIqW/ikSEEpAbRRJhuKt+lQfdaDo/2P5l/wMW99+b9bb92T7nBd+V7CEviGQw34ple3QX pNQdND807n3Kb51L2jm2KqEZNo/9hm8PR0TH0ZjAn4CjbPajTRzdvVN/BBgAGfMJQwplbmRz dHJlYW0NZW5kb2JqDTcgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDMwIDAgUiAN L1Jlc291cmNlcyA4IDAgUiANL0NvbnRlbnRzIDkgMCBSIA0vUm90YXRlIDkwIA0vTWVkaWFC b3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDT4+IA1lbmRv YmoNOCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMSAy NSAwIFIgL1RUMiAzOCAwIFIgL1RUNiAyNiAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0 MiAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMzYgMCBSID4+IA0+PiANZW5kb2JqDTkg MCBvYmoNPDwgL0xlbmd0aCA2MTAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SImMU01PG0EMvc+v8HFTKZOxPZ9HmtIPJFCk7AEpcKDbpApKoEqQ4OfXns2mgKIKrZL1ztjP 783zTKb7AN0esD77zky+zRF+7w3CGgxHSCFC8A7GiRzslmZlPrdm0rYk6e3KOPDeIrGHsQTO g4OSLAEFWY7QbiVDH0EeO+scStUQemifTXP+crf9s1nCTdM9PjzZm9GovTfn0kOZTefQ18+n wuhCgntwNhE8Azq4hMWtg1+GQ7SUAWOGwNYDUtBvYTtXtg5IqYUAY1KCnFEoA6ZgpUIo9nRY mWnkciV2+fhzLby+nymhyVccBGO2jjnBGLOAeecsvwbDE3qdAi6a2W45ijY1q3V9vcD16La9 ULFYMvgs1KKKQ5Qj9Ef+r0/7rRISoaLE53Ro/u6w30ua3e2WD0+DpLaNR1hJSqkIrOtN5EBW nCdEMVOBLYmdw38q8dhEiAwKmx9nM0UW+swkJJ0NJUvrL8ct0cpRJyr2VsXyAZlcnM0eglSc kqniOvHr6v9GYZX2D+SUUYvm2mI1h/joDRc9CpR5ZVYePtv4AdYYSbOR8CRrruY006vDsaCM tkGZZJ9raYStIfS2iL+pmrGRjiSi5ER9wkNCzdfR2Rg1y+keq9CNWX0ycjF1oAJn5bA1nIpe zlJs6vFY51YWslbKfq61VFgv0Ea+SaebHeltrpBvU6SkCLm+hfc9ZqmkdMUNGcJZPVfESkU3 Bbgn6QvEqHIwe13VD5R3CKg8NfTiT2c0ouTq7e1TUYdU6vXdGUauVslPp+yQqmFfX0evBz2k aquhf2f25q8AAwBgtwkmCmVuZHN0cmVhbQ1lbmRvYmoNMTAgMCBvYmoNPDwgDS9UeXBlIC9Q YWdlIA0vUGFyZW50IDMwIDAgUiANL1Jlc291cmNlcyAxMSAwIFIgDS9Db250ZW50cyAxMiAw IFIgDS9Sb3RhdGUgOTAgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsg MCAwIDYxMiA3OTIgXSANPj4gDWVuZG9iag0xMSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERG IC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMzggMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEg NDIgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDM2IDAgUiA+PiANPj4gDWVuZG9iag0x MiAwIG9iag08PCAvTGVuZ3RoIDMxMiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiVSPy2oDIRSG9z7Fv3QgGnV0Ltu0oVBos4jQRekiTEwiJGOYMSQv0Cdo+741M71yQH4P x+/zTG96g6aHHKpvyPRuKbHtiYQHyQuUpoDRAqxUAp0jGzKzZGqtSuN2QwS05lLlGiwFoSEg teEKKq/SaQ9p4lqJzAQXQpSwDRlSDXsmz3R2ihP4Fo/zh0zzgi4ywSs6ec1e7H16nCsuhTBg KQx4pQquNepyxLNv1he1HKkfGdO15DV9Sria+rhD3Dk0oe392nWr6EOLsMFb6/ro1u9X/WKC UcorLSWY5LKuDOztl8RcJUOUZrScHQ5+u4vp45qiO7VpkfESsvQ89Vbowin6oddmiud0i30I x3E99qvSuf6jqn5UyvxbqKLLRJHUObTuEuEuq8Nx70bc3JJPAQYAZ0dvQgplbmRzdHJlYW0N ZW5kb2JqDTEzIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAzMCAwIFIgDS9SZXNv dXJjZXMgMTQgMCBSIA0vQ29udGVudHMgMTUgMCBSIA0vUm90YXRlIDkwIA0vTWVkaWFCb3gg WyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDT4+IA1lbmRvYmoN MTQgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjEgMjUg MCBSIC9UVDIgMzggMCBSIC9UVDYgMjYgMCBSIC9UVDggMjcgMCBSID4+IA0vRXh0R1N0YXRl IDw8IC9HUzEgNDIgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDM2IDAgUiA+PiANPj4g DWVuZG9iag0xNSAwIG9iag08PCAvTGVuZ3RoIDc3OSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiaRVy04bQRC8z1f00Y7k8XTPc48EkQQkEyvsgQhxIMYmS3hIthWT/Eby wemenbUNMQglssTWiJ7qnqra2eH+wsNkAZh/i4kavj9BuFoohAaUDRB9AO8MDCIZmE/VTL2t 1bCuicvrmTLgnEayDgYMjAMDVdT8zxC1g/qWC+THxAOjjUEP9URlFKFeqd7xwegjrJrlV7iA 2/svzc0UPuz162t1wF1ktv0TaClO9nmmIwbXYHQkWAEaGMHZuYFL5SgAcXdvuSuS15Rk2BMZ 1gDJZN7DgGQ+541ODghRhyQjtpPZbjKT8mSj7WmG77A7LyZtrI0wwCRk0cipN2T4+LyYWYXw rDeeT/tBx96syY8HOO2f10dyUkyBmRzYICdDZAXdev5tsR+fhNCy9uBS1/yJ2E+PNL6YT++W G4GRtVRYeQjBAI8u6qW8QDbbO69jyNAZDokSREHshlKKnkt5vzwninh8lzHFdaXAdrugwtlW 5kal+0QtdnmFPuX6ZDlTnVXGb4n6a7G8WDaT4ayfNPaah+ll32vX+w2HY7ibLlf3829ZZVYx rFVklhgr7mHayFIyWnJOpY3RhAG6v7EKa015Ku7dO9wbFw0lj4oSgec4tvEzuB2/5+2zJkgQ Pdu9yz4xjVuNPr0YQEtBzrAh2RXAZ7PHw6XnVTFVzrb1nSqiBLPrjR7o1hnzXcrvH37AxeX3 6XzZ/Gzu+gOvQ++qPyCSzjzIrNmKvmx1ReRCXGLJwXaknZNkVqlb3LSLKIjQbKOuQFzbLJjd WWL05Y1yluMdEzNaeWcytnzJBb4x2H+BPiCHUZCrguaNbaVzQpPyc6Jc5cRiWcjdWCoFttsF Fc5SKp267iXrr0nklvYvJzK/DbtiSUT/Fkui6v9j+YhEh9cE8/P6UpQjiGa2MmvHBIs53Klz jKItjpFJG8dQxLcpP9eOYfmalcoM83ZBhbOUSqeuuziWFXWy35bvTET9mlvapfy98e6vWzrL 2V4oo+PjF/X0hottVW3R7H7RTzVmIcl2Ov4RYADgzqNdCmVuZHN0cmVhbQ1lbmRvYmoNMTYg MCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDMwIDAgUiANL1Jlc291cmNlcyAxNyAw IFIgDS9Db250ZW50cyAxOCAwIFIgDS9Sb3RhdGUgOTAgDS9NZWRpYUJveCBbIDAgMCA2MTIg NzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANPj4gDWVuZG9iag0xNyAwIG9iag08 PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMSAyNSAwIFIgL1RUMiAz OCAwIFIgL1RUNiAyNiAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0MiAwIFIgPj4gDS9D b2xvclNwYWNlIDw8IC9DczUgMzYgMCBSID4+IA0+PiANZW5kb2JqDTE4IDAgb2JqDTw8IC9M ZW5ndGggMTUzNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiaRXzW4bNxC+ 71PwKBf1mjMckrtH122aBnBg1DqkSHJIFbl1YsVAbMDpA/S9O9+QXMmWLCcpAnhnxPn95ofM 0clNdIsbR/bvZtEd/XpO7q+bjtyl60JyOSYXxbvDzN59XnYX3U/z7mg+ZxWfX3TeifTEQdyh El6cd2Pu9XBgcPOVSuCfWj70vfekvy06UD64+V03m/+9dM+uru/c9YW7Vfrs3eLj8vbmYP6h +0UdIbyTc1eMnJ9oWC+U+OB8n9ndOfLu1L1+6937Tjg5Vpcx9OKIY88D4j1HvN4xgovRHTJC lOj7QRwT9WmwIBHQYAGdXv95ebV0z48RwtEzannS0PsQsjukARayR35rC3Q/TbI0YfD17Ozz 8iD1eXZxaZ8v7tXB2/kLpEeqC3BzRDrE3Oc0Bb0J8v3waYyKuWrmFv5952HCuKR09u7z8tPt UykxST9uWv32lLRNqPdDym7+s0q9UTk7v/5in3/cc/seH/jZmwPT0CTTlKS6yXnUJH3pJB58 j/bjoB1lVWJKrv3NY5qCY2ur2W/HZ7VxeNBMtDtKN3ja7IbHgQ0+oS8i7QYWcKqX09/34hg4 Ify1kV047u0K7e9OwuBSHtyqC4P2mNFB5zFpZysmIGMit+hAyZj6wK5IioiDNr6LTkZB7mDQ aVUSZFEHVW1WUXhq3hfdTUXsySpxiN9cJUyylYqZv69UzOP/L9U9I4rgVxTrj61ihdFPxQKN uqinVizOoRaL/bAuFgF31cZ3KhbVnVsljTR1UNVmFYWn5h3FMkQF+qGuwkz652k8ZbCVGIUe 4mlwlsqdvny5F8/oVTiM44aZ3c3/qicDksOEo14vpLdDCAhDhv6rFqGUZb8VszkLtgdnJy9r t1mpSOHTbCixelh1emP0oks4MEC9UocAHcMSqArEshW9nrLml3AWYOOqu/ihAE6jViDt3jYP Y9ZWR4Yh5Y27h6KF+tSGFrtUN1S/r103ctIENR6dUUmAHABMIDKNuGZwoh9ISj/obkiWn6Kh 0wN2hDEDAxJ6gwEKFc8ZB5wHaBm0WQAtDjw2m01+ZkCq1rQBIT6gX81a0I0iTWDVCVlhWLMn NnuiK1ZD5xQQ0Ko8AVIq9pp4xo1UDNr5gFSCNg521qCzVGwFvGP0l5HQD6syqRY3ZBVuHuxT 8kTgI4JiPdQQglbevGqSUmY+2k6FhDdArkAVWepDqoYishXyJcWghdEgog9TWNqNmltETxUJ QxNXm0amv6JVPTbvBmQxVXsipZe1RFSKi1+wHVLEZlmVVaHHGccihmfMoSCsBtGJ1gzYSYGA DMlom0cZzN8AEsPUGI9NVhkeTbaq8Gg/wlQlVdAGsZ2ktUqaTKXJg8ma4xrNAjE+XBEPLyhC f6gxQ//eZrOho2k9UOt7bwBj+K2zwJA+awG87ovUGBktg8bYWFQVGaLlT76RsJtwPdcTvfGa ipEmgWvQPBRZOG7RtFR33cCEJ7eM/DDBGW/lptdCsAZnzlZGQQBklRMrRWVCsoAKw6V+VYVL bWGKaxnR22k6kTSpSGqmQBUPRVaqCRn25qY3iRYvbBVvFh7mFtI03rE4VwaTiZAy8JwYwNmY sj2aSrRimqlCqmC2qOtJXqvkyVSePBRZOK7R7MktZDQmJ9nKTdoDCc22fkWJx1CgM6VcMmDC WBpqFHt5FKYE3hiTrSqc7UeYqqTaJeu5esJ+UjHSJECZhyILxy2aPRkKYTUpDFsZxt0ZAk/0 i/ZnBTmsoQ9+ow6M121jyBqzqRC1KlcSdq069QTlqSogi6mBm4cia482X7v38f7MmD3dRVsZ pscytMvWMrSWA4PI7Wq17qmMPQkbUzdoVZHW1I20+PuJ5Q2Vtam1hyKbqom0fwIHdKnE7QnM uzPEWzTmZK/hsj/xJshlf2ab/cokseEpTCzLparEsnhgKtYahtF2YmHFc1Mx0kwZVTwU2Vze 4vjum8MRNYxxu4YDMtx6wWmXqEE8g8r7zS6Z9X89Eq6Vw/asu+tmx5/e/+gub93V9fXHG3dx +Wn5b0XuvwEAU69+7wplbmRzdHJlYW0NZW5kb2JqDTE5IDAgb2JqDTw8IA0vVHlwZSAvUGFn ZSANL1BhcmVudCAzMCAwIFIgDS9SZXNvdXJjZXMgMjAgMCBSIA0vQ29udGVudHMgMjEgMCBS IA0vUm90YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAg MCA2MTIgNzkyIF0gDT4+IA1lbmRvYmoNMjAgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAv VGV4dCBdIA0vRm9udCA8PCAvRjEgMjUgMCBSIC9UVDIgMzggMCBSIC9UVDYgMjYgMCBSID4+ IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDIgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDM2 IDAgUiA+PiANPj4gDWVuZG9iag0yMSAwIG9iag08PCAvTGVuZ3RoIDEwNzIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImkVttuG0cMfd+vmEe5gMZDznUfHfeSBrVhxHpI kOQhUeTCgW0VUlCnH5D/Lg9ndiXZqi8NBGjJXQ7Jc8jhzOHxOpr52pD+1vPu8LdzMn+uOzKX pvPJ5JhMDM5MMzuzWnQX3YtZdzibsZjPLjpnQrDEPpipCC4YZ/ps2TCTTcHMrsUCP/E8ddY5 knfzDpLzZnbbTU6Wny6vFubktblZ3n63B7Mv3S8SAGkdn5u6+PxY0nklwhfjbGZza8iZE/Pu gzOfu+CLCUjS22CIo+WCPM+RpzOMpGI0U0ZqIbEtQR7epqLJIZGyncjLI6Rw+CsN+KhY5302 UyrwUBgoNx5oFx4pPDh8NzlbLQ6SzZOLS318M28OPsxeAR4JDZxBLuAQsxVlSHqb3N30KZBw bbiM6e8G9yO3FdLZx9Xi5utjkCg52297fT4kaQ+yrqRsZj+L1Xux0+/Lb/r4x7zU59GBm7w/ 0BUCMo0gJUzOvYB0tYOQESrKXjpJq8SUzPCf+zQmx9pOk9+PzlrjkEAIfWnd4Gi7Gx4gtte+ iC7uJRZ0SpST1w/yyKStsXGyj8cHu0L6u/O9N1la+rrjvoAFKMxsUmCbVIosW7aDFFwGwGbp pTewHM95F0q2IagSZSc2U4h1PaTqs1ki0BB93q0bY/9dJRbSYl393CphJws+ySqHZ5bKC+nY woV+oFTeF93F206EiCcU6+1OsUJ04FCKJcSJA8g+CMul14JAVLIhBelqrxUC5w5Ty+lTauES 0EOJkQdLiK1WkKrPZopIQ3QUqzJa5AO15s8kf0/hU1s/8b3WVzpr5U5OTx/hU1t/42R/67+x pDSyH1mUQwXD0PtaVPu0MVhH/f4O8DoFJ8enw0QAM+QzEqSEfpf0oow82UxJ982VBKQYdAim jIkMC1I94zOFrHNXzCXiVXfxU+M7SzKO93bw3aSl2wGRXL919FDUXB8Z0J70ZN1a+v+6dQuT TJdU84m6E0DBSCMn0mMpRhzh1xVmZChXHRiSZiaxoVS54D7h/GLnQYBwJ1BRUsJUUXLlSiAG XqpcyZVWLrDI1YJ6vSx4lq1dXYIJzYXEAAPlWkuIWScKiesCETQMiqAQ86ogoNi2JXCPl+Kq iXPtgDR+iWlcEtPgClKNoLYauGUzR453e/TeKSZ0y1eZzdJqOxtLi05jfzaocIyhLoRLpblO fZCqUJNNG8Vh/jelst6WAEVpJFVRDwo7qsybJTy64jECD4fMkM0Add8BoOezsHUX4ITvYZMb JBfF5mvwgjtiTSnXyE2pCVUlVdu2JNaXcBUHbEHXti+RxyUQqyuV1KraInDL5iFsQW+x6T42 D2z3pmivV7jcD0ehNsDmVOrHm1nQm9kfy+Vf5mK5Wvy9WJlPi6+3i8VN9SsXKeoj7lEyFszH m89mvMV9b6z+OwByu2HICmVuZHN0cmVhbQ1lbmRvYmoNMjIgMCBvYmoNPDwgDS9UeXBlIC9Q YWdlIA0vUGFyZW50IDMwIDAgUiANL1Jlc291cmNlcyAyMyAwIFIgDS9Db250ZW50cyAyNCAw IFIgDS9Sb3RhdGUgOTAgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsg MCAwIDYxMiA3OTIgXSANPj4gDWVuZG9iag0yMyAwIG9iag08PCANL1Byb2NTZXQgWyAvUERG IC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMzggMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEg NDIgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDM2IDAgUiA+PiANPj4gDWVuZG9iag0y NCAwIG9iag08PCAvTGVuZ3RoIDQyMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiZSSy47TMBSG936KX2LjSGPXtzgJGzQDCISgI4F3iEWaetqgTILqlIoH4Am4PC8nyYgp oFkgS9ZJfM73f7K8eppyNAl6XqlhqxfvNHaJabRg1qPIPXKnIAqjcIjshl0FtgrBUHu4YQrO SW2sg6BCOShol0sDY40sEW6pY1pEFkoqpWmqYXNlEU6Mv44pDX1CF+tDH7dfs/CRRmhYK5VD UDFDjfHSOVQFoQm6sKqZNWHe8x+ZcJWRFb/OhJaGfxrboX+kH2cfwivqMaVU2lQQppCVn4C+ kKWDtvacOAHnirJn7M9MWOWl5dsB6+uAustETindcMLLS9Rp+cSb9fou6R91q82U9L/q5kF1 mztp/lY/c9fuzD2Xjl9mhvZ+Em7qHpsI2sn4ApvjiHac//bxczxMZ0usLFVuMfkoXSA8u0ux 9ylmSfnW9k133Mbt98xLz7H5QsSE4UQRb+UME/c057z7TdPlH6KeX5FowY/jBfZ0v/VmIL1x P6SI2O72k2eKCS2Rj93YigdMz97Zwt8PtxndHW/73ZN55nlgvwQYAPutsycKZW5kc3RyZWFt DWVuZG9iag0yNSAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0Vu Y29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvQ291cmllciANPj4gDWVuZG9i ag0yNiAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0 Q2hhciA2NSANL0xhc3RDaGFyIDgwIA0vV2lkdGhzIFsgNzMxIDAgMCAwIDAgMCAwIDAgNTQ2 IDAgMCAwIDAgMCAwIDUyMSBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VG b250IC9Db21pY1NhbnNNUyANL0ZvbnREZXNjcmlwdG9yIDI4IDAgUiANPj4gDWVuZG9iag0y NyAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0Q2hh ciAzMiANL0xhc3RDaGFyIDEyMiANL1dpZHRocyBbIDIyOCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIA0wIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU0NyAwIDAgMCAwIDAgMCAwIDU0NyAwIDAgMCAwIDAg DTAgMCAwIDQ1NiAwIDAgNDU2IDQ1NiAyMjggNDU2IDAgMTgyIDAgMCAwIDAgNDU2IDQ1NiAw IDAgMjczIDAgMjI4IA0wIDQxMCAwIDQxMCA0MTAgNDEwIF0gDS9FbmNvZGluZyAvV2luQW5z aUVuY29kaW5nIA0vQmFzZUZvbnQgL0FyaWFsTmFycm93LEl0YWxpYyANL0ZvbnREZXNjcmlw dG9yIDI5IDAgUiANPj4gDWVuZG9iag0yOCAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlw dG9yIA0vQXNjZW50IDExMDIgDS9DYXBIZWlnaHQgMCANL0Rlc2NlbnQgLTI5MSANL0ZsYWdz IDQwIA0vRm9udEJCb3ggWyAtOTMgLTMxMiAxMTg3IDExMDIgXSANL0ZvbnROYW1lIC9Db21p Y1NhbnNNUyANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAwIA0+PiANZW5kb2JqDTI5IDAgb2Jq DTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgOTM1IA0vQ2FwSGVpZ2h0IDAg DS9EZXNjZW50IC0yMTEgDS9GbGFncyA5NiANL0ZvbnRCQm94IFsgLTIxNCAtMzA3IDEwMDAg MTA0OCBdIA0vRm9udE5hbWUgL0FyaWFsTmFycm93LEl0YWxpYyANL0l0YWxpY0FuZ2xlIC0x NSANL1N0ZW1WIDAgDT4+IA1lbmRvYmoNMzAgMCBvYmoNPDwgDS9UeXBlIC9QYWdlcyANL0tp ZHMgWyAzNCAwIFIgMSAwIFIgNCAwIFIgNyAwIFIgMTAgMCBSIDEzIDAgUiAxNiAwIFIgMTkg MCBSIDIyIDAgUiBdIA0vQ291bnQgOSANPj4gDWVuZG9iag0zMSAwIG9iag08PCANL0NyZWF0 aW9uRGF0ZSAoRDoyMDA0MDIyODIzMDQxOSkNL1Byb2R1Y2VyIChBY3JvYmF0IERpc3RpbGxl ciA0LjA1IGZvciBXaW5kb3dzKQ0vTW9kRGF0ZSAoRDoyMDA0MDIyODIzMDQ1OS0wOCcwMCcp DT4+IA1lbmRvYmoNeHJlZg0wIDMyIA0wMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDMxNzAg MDAwMDAgbg0KMDAwMDAwMzMyMiAwMDAwMCBuDQowMDAwMDAzNDU2IDAwMDAwIG4NCjAwMDAw MDM5MjUgMDAwMDAgbg0KMDAwMDAwNDA3NyAwMDAwMCBuDQowMDAwMDA0MjQ2IDAwMDAwIG4N CjAwMDAwMDQ5MjcgMDAwMDAgbg0KMDAwMDAwNTA3OSAwMDAwMCBuDQowMDAwMDA1MjM2IDAw MDAwIG4NCjAwMDAwMDU5MTkgMDAwMDAgbg0KMDAwMDAwNjA3NCAwMDAwMCBuDQowMDAwMDA2 MjA5IDAwMDAwIG4NCjAwMDAwMDY1OTUgMDAwMDAgbg0KMDAwMDAwNjc1MCAwMDAwMCBuDQow MDAwMDA2OTIwIDAwMDAwIG4NCjAwMDAwMDc3NzMgMDAwMDAgbg0KMDAwMDAwNzkyOCAwMDAw MCBuDQowMDAwMDA4MDg2IDAwMDAwIG4NCjAwMDAwMDk2OTcgMDAwMDAgbg0KMDAwMDAwOTg1 MiAwMDAwMCBuDQowMDAwMDEwMDEwIDAwMDAwIG4NCjAwMDAwMTExNTcgMDAwMDAgbg0KMDAw MDAxMTMxMiAwMDAwMCBuDQowMDAwMDExNDQ3IDAwMDAwIG4NCjAwMDAwMTE5NDIgMDAwMDAg bg0KMDAwMDAxMjA0NCAwMDAwMCBuDQowMDAwMDEyMjU3IDAwMDAwIG4NCjAwMDAwMTI2NTkg MDAwMDAgbg0KMDAwMDAxMjg0NCAwMDAwMCBuDQowMDAwMDEzMDM4IDAwMDAwIG4NCjAwMDAw MTMxNTcgMDAwMDAgbg0KdHJhaWxlcg08PA0vU2l6ZSAzMg0vSURbPDg1OGQ1Y2I3MDMwYzEz NmI3ZmM1ZWMyMTZiOWFmNGU2Pjw4NThkNWNiNzAzMGMxMzZiN2ZjNWVjMjE2YjlhZjRlNj5d DT4+DXN0YXJ0eHJlZg0xNzMNJSVFT0YN --------------060809070605000901050709-- From exim@www1.ietf.org Sun Feb 29 03:58:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13372 for ; Sun, 29 Feb 2004 03:58:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMlm-0005y7-GN for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 03:58:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T8vsEv022929 for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 03:57:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMlk-0005vr-LY for nemo-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 03:57:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13351 for ; Sun, 29 Feb 2004 03:57:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxMlg-0000RY-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 03:57:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxMkm-0000MO-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 03:56:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxMkI-0000H0-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 03:56:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMk0-0005hA-KK; Sun, 29 Feb 2004 03:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMjl-0005cg-Dc for nemo@optimus.ietf.org; Sun, 29 Feb 2004 03:55:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13276 for ; Sun, 29 Feb 2004 03:55:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxMji-0000GL-00 for nemo@ietf.org; Sun, 29 Feb 2004 03:55:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxMio-0000Bo-00 for nemo@ietf.org; Sun, 29 Feb 2004 03:54:51 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1AxMiK-00006d-00 for nemo@ietf.org; Sun, 29 Feb 2004 03:54:20 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i1T8sCha019556; Sun, 29 Feb 2004 00:54:13 -0800 (PST) Message-ID: <40419C64.4010509@cs.ucdavis.edu> Date: Sun, 29 Feb 2004 00:01:40 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eun Kyoung Paik CC: nemo@ietf.org Subject: Re: [nemo] merged multihoming draft References: <20040223004618.A48134@mmlab.snu.ac.kr> In-Reply-To: <20040223004618.A48134@mmlab.snu.ac.kr> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The merged draft is a very good step to comsolidate various interests in multi-homing NEMO. Thanks very much. After reading the draft, I have one comment regarding: > 2.4 (1,N,N): Single MR, Multiple HAs, Multiple Prefixes > > The (1,n,n) mobile network has only one mobile router. However, the > mobile router advertises more than one NEMO-prefix, and also > associates to multiple home agents at the same time, possibly one > home agent per home address. No assumptions is made on whether or > not the home agents belongs to the same administrative domain. and, > 5. Evaluation of Basic NEMO Solution > .... > o (1,N,N) Mobile Network > The (1,N,N) mobile network has one mobile router registering to > multiple home agents multiple NEMO-prefixes.The same question of > whether the same home-address can be simultaneously registered to > multiple home agents. It seems to me that, from the above segments of text in the draft, it is not clear whether different prefixes under the (1,N,N) and maybe (N,N,N) cases should be registered to different HAs. My concern is that this capability seems to me a key motivation to have multi-homing. I.e., when one of the N HA's is down, any CN in the public Internet, can still access the MN via other HAs. But, of course, we will get our routing table larger and larger... I heard a proposal (I forgot the source) that each MNN will have multiple IP addresses (so it will have one address in each prefix in this particular multihoming NEMO), and it is the responsibility of the CN to decide "which IP address to use to communicate with the MNN". Assuming that the CNN will be able to use DNS-like or other host identities to find out this multi-address binding. (may this is from the Multi6 working group). Certainly, under this proposal, we don't need to register different prefixes to different HAs. But, otherwise, it seems to me that this feature is very useful. -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 29 03:58:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13390 for ; Sun, 29 Feb 2004 03:58:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMlm-0005y8-Gi for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 03:58:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T8vsM6022930 for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 03:57:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMlk-0005xc-Fy for nemo-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 03:57:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13354 for ; Sun, 29 Feb 2004 03:57:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxMlg-0000Rd-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 03:57:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxMkn-0000MW-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 03:56:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxMkI-0000H2-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 03:56:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMjz-0005gr-9m; Sun, 29 Feb 2004 03:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMjk-0005cX-Qk for nemo@optimus.ietf.org; Sun, 29 Feb 2004 03:55:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13273 for ; Sun, 29 Feb 2004 03:55:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxMji-0000GG-00 for nemo@ietf.org; Sun, 29 Feb 2004 03:55:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxMin-0000Bf-00 for nemo@ietf.org; Sun, 29 Feb 2004 03:54:50 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1AxMiK-00006c-00 for nemo@ietf.org; Sun, 29 Feb 2004 03:54:20 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i1T8s8ha019553; Sun, 29 Feb 2004 00:54:09 -0800 (PST) Message-ID: <404190B7.50302@cs.ucdavis.edu> Date: Sat, 28 Feb 2004 23:11:51 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG CC: "Fan Zhao" , Souhwan Jung , wu@cs.ucdavis.edu Subject: [nemo] can an HA itself be an MNN under NEMO? References: <1077784218.790.15.camel@acorde> <1077850151.5540.30.camel@localhost> In-Reply-To: <1077850151.5540.30.camel@localhost> Content-Type: multipart/mixed; boundary="------------060809070605000901050709" 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format. --------------060809070605000901050709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, During our analysis of multi-homing and nested NEMO cases, we have encountered a question, hopefully get some clarifications from the NEMO working group: -- Can an HA itself be an MNN under the NEMO context? Please see our attached PDF file for our preliminary analysis on this issue. It seems to us that this can be allowed for MIPv6, but should NOT be allowed for NEMO (otherwise, we might have a loop, and the multi-homing issue might be more complex). -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- --------------060809070605000901050709 Content-Type: application/pdf; name="NEMO-HA-as-MNN.pdf" Content-Disposition: inline; filename="NEMO-HA-as-MNN.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjINJeLjz9MNCjMyIDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyAzNCANL0gg WyA2NjIgMjUxIF0gDS9MIDE0MDY0IA0vRSAzMzIyIA0vTiA5IA0vVCAxMzMwNiANPj4gDWVu ZG9iag0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB4cmVmDTMyIDEzIA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA2MDcg MDAwMDAgbg0KMDAwMDAwMDkxMyAwMDAwMCBuDQowMDAwMDAxMDY4IDAwMDAwIG4NCjAwMDAw MDEyMTUgMDAwMDAgbg0KMDAwMDAwMTM5NSAwMDAwMCBuDQowMDAwMDAxNzQ1IDAwMDAwIG4N CjAwMDAwMDIyOTMgMDAwMDAgbg0KMDAwMDAwMjQ4MCAwMDAwMCBuDQowMDAwMDAyNjgyIDAw MDAwIG4NCjAwMDAwMDMwOTIgMDAwMDAgbg0KMDAwMDAwMDY2MiAwMDAwMCBuDQowMDAwMDAw ODkyIDAwMDAwIG4NCnRyYWlsZXINPDwNL1NpemUgNDUNL0luZm8gMzEgMCBSIA0vUm9vdCAz MyAwIFIgDS9QcmV2IDEzMjk2IA0vSURbPDg1OGQ1Y2I3MDMwYzEzNmI3ZmM1ZWMyMTZiOWFm NGU2Pjw4NThkNWNiNzAzMGMxMzZiN2ZjNWVjMjE2YjlhZjRlNj5dDT4+DXN0YXJ0eHJlZg0w DSUlRU9GDSAgICAgDTMzIDAgb2JqDTw8IA0vVHlwZSAvQ2F0YWxvZyANL1BhZ2VzIDMwIDAg UiANPj4gDWVuZG9iag00MyAwIG9iag08PCAvUyAxMzAgL0ZpbHRlciAvRmxhdGVEZWNvZGUg L0xlbmd0aCA0NCAwIFIgPj4gDXN0cmVhbQ0KSIliYGBgZmBgmsbAAiSXMHAzIAA3UAwEORJA vKMLbRYLH2CoXc4swLsgZbpnuQNQMERDJXLN7ZagOStCNFw1T+0FsYB0q1MDo7AFAwcDo0to A4OQBoilZNzAwCjBwCDYwNCAYhbQGEkGBt3VQJoTiPnAdvsxcKpN9LnIt3HLTx8GNoEvzpEX GBgAAgwARjgleA1lbmRzdHJlYW0NZW5kb2JqDTQ0IDAgb2JqDTE0NSANZW5kb2JqDTM0IDAg b2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAzMCAwIFIgDS9SZXNvdXJjZXMgMzUgMCBS IA0vQ29udGVudHMgMzcgMCBSIA0vUm90YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5 MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDT4+IA1lbmRvYmoNMzUgMCBvYmoNPDwg DS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDM4IDAgUiAvVFQ0IDQx IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQyIDAgUiA+PiANL0NvbG9yU3BhY2UgPDwg L0NzNSAzNiAwIFIgPj4gDT4+IA1lbmRvYmoNMzYgMCBvYmoNWyANL0NhbFJHQiA8PCAvV2hp dGVQb2ludCBbIDAuOTUwNSAxIDEuMDg5IF0gL0dhbW1hIFsgMi4yMjIyMSAyLjIyMjIxIDIu MjIyMjEgXSANL01hdHJpeCBbIDAuNDEyNCAwLjIxMjYgMC4wMTkzIDAuMzU3NiAwLjcxNTE5 IDAuMTE5MiAwLjE4MDUgMC4wNzIyIDAuOTUwNSBdID4+IA0NXQ1lbmRvYmoNMzcgMCBvYmoN PDwgL0xlbmd0aCAyNzYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIlM0Etr wkAUBeD9/IqzjGCud16ZcVVaqy2CduFAoaWLqPFRbATTYH9+ZxIq5e6Gw7nf3NGksdg0kN00 GzF6WknsGyFxhNAFnC1gDSN3inGpxE48BDEKQcV42AmGYWJtLXI9pnEBhrSWCgOpNXmErxhJ E6vzmGTWCJv4Fq4im5Q1nu9x/G6q0w5YVyixWC7R1tvqgkH4FIYcW49ckmKpEB77Epk6suV0 8XKXUpFj/jjKU0yOkSvXc3TB5KLWKOLekxRdQ99VJMt7tjq3h2tZD3JlNZls3tb7IVaEWXU6 /uC1HaKst5hF8tuhPA8+wvzfGRxJr6NTkffeJGe3xd22KNX9eFatoZhNUk+D+BVgAATXVyYK ZW5kc3RyZWFtDWVuZG9iag0zOCAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9U cnVlVHlwZSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDE1MCANL1dpZHRocyBbIDI1MCAw IDAgNTAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMjUwIDMzMyAyNTAgMjc4IDUwMCA1MDAgNTAw IDUwMCA1MDAgDTUwMCA1MDAgNTAwIDUwMCAwIDI3OCAwIDAgMCAwIDQ0NCAwIDcyMiA2Njcg NjY3IDAgNjExIDU1NiAwIDcyMiANMzMzIDAgMCA2MTEgODg5IDcyMiA3MjIgNTU2IDAgNjY3 IDU1NiA2MTEgMCAwIDk0NCAwIDAgMCAwIDAgMCAwIA0wIDAgNDQ0IDUwMCA0NDQgNTAwIDQ0 NCAzMzMgNTAwIDUwMCAyNzggMCA1MDAgMjc4IDc3OCA1MDAgNTAwIDUwMCANMCAzMzMgMzg5 IDI3OCA1MDAgNTAwIDcyMiA1MDAgNTAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAxMDAwIDAg MCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDQ0NCA0NDQgMzUwIDUwMCBdIA0vRW5jb2Rpbmcg L1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9UaW1lc05ld1JvbWFuIA0vRm9udERlc2Ny aXB0b3IgMzkgMCBSIA0+PiANZW5kb2JqDTM5IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2Ny aXB0b3IgDS9Bc2NlbnQgODkxIA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTYgDS9GbGFn cyAzNCANL0ZvbnRCQm94IFsgLTU2OCAtMzA3IDIwMjggMTAwNyBdIA0vRm9udE5hbWUgL1Rp bWVzTmV3Um9tYW4gDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMCANPj4gDWVuZG9iag00MCAw IG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDg5MSANL0NhcEhlaWdo dCAwIA0vRGVzY2VudCAtMjE2IA0vRmxhZ3MgOTggDS9Gb250QkJveCBbIC01NDcgLTMwNyAx MjA2IDEwMzIgXSANL0ZvbnROYW1lIC9UaW1lc05ld1JvbWFuLEJvbGRJdGFsaWMgDS9JdGFs aWNBbmdsZSAtMTUgDS9TdGVtViAxMzMgDT4+IA1lbmRvYmoNNDEgMCBvYmoNPDwgDS9UeXBl IC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAx MjAgDS9XaWR0aHMgWyAyNTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI1MCAwIDI1MCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCANMCAwIDAgMCAwIDAgMCAwIDY2NyAwIDAgMCA1 MDAgMCAwIDAgMCAwIDAgMCAwIDU1NiAwIDAgMCA4ODkgMCAwIA02MTEgMCAwIDAgMCAwIDAg NTAwIDAgMCA1MDAgNDQ0IDAgNTAwIDU1NiAyNzggMCAwIDI3OCAwIDU1NiA1MDAgDTAgMCAw IDAgMCA1NTYgMCA2NjcgNTAwIF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFz ZUZvbnQgL1RpbWVzTmV3Um9tYW4sQm9sZEl0YWxpYyANL0ZvbnREZXNjcmlwdG9yIDQwIDAg UiANPj4gDWVuZG9iag00MiAwIG9iag08PCANL1R5cGUgL0V4dEdTdGF0ZSANL1NBIGZhbHNl IA0vU00gMC4wMiANL1RSIC9JZGVudGl0eSANPj4gDWVuZG9iag0xIDAgb2JqDTw8IA0vVHlw ZSAvUGFnZSANL1BhcmVudCAzMCAwIFIgDS9SZXNvdXJjZXMgMiAwIFIgDS9Db250ZW50cyAz IDAgUiANL1JvdGF0ZSA5MCANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3gg WyAwIDAgNjEyIDc5MiBdIA0+PiANZW5kb2JqDTIgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BE RiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDM4IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1Mx IDQyIDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAzNiAwIFIgPj4gDT4+IA1lbmRvYmoN MyAwIG9iag08PCAvTGVuZ3RoIDM5NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiVSRzW7UMBSF936Ks3SkxuP/JKuqFASDVIRU7yoW09RpQzNJNU4pL8AjwPNynQwdKm9O fHO/e3zu5jI5tAlqOallm4/XCveJKfRgxqNyHs5KlJWWOETWsXeBbULQ9HvomIS1QmljUZKQ FhLKOkFVXyPsqZ4PcUsppFQaoWVZyQbhhfFtwvzQJ+xG9Ck9R/QjrrZff/jzInynZqOFktKh JLHAtfbCWjQVjSD8QpV1pq7SZ+wN/12UtlGi5tuC7h2fkWLcJ4zT/Kv4Fj4TWteC/DQodSUa n9G+ErWFMuZ/tjmxzcr+U5RGOuEzWwnLj47PsMOnC7T0lNtI+uoL+jnFoaPCeJc11smils6A WnV2+/4Id69z1JLM0+4QxzkTX/phIMQ4PY9tpLging6x63+imw7L5xrVAlTViahPxKPzfeHJ 9nTbD5HAYrFTnvxYq1Vul6+NWr95suHXOc6KT2e0rnVzacrUmsdCE5uuxnsM/WPEGNMcqdTw u5yT5v8Wm6d+COyvAAMAWF2YgQplbmRzdHJlYW0NZW5kb2JqDTQgMCBvYmoNPDwgDS9UeXBl IC9QYWdlIA0vUGFyZW50IDMwIDAgUiANL1Jlc291cmNlcyA1IDAgUiANL0NvbnRlbnRzIDYg MCBSIA0vUm90YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBb IDAgMCA2MTIgNzkyIF0gDT4+IA1lbmRvYmoNNSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERG IC9UZXh0IF0gDS9Gb250IDw8IC9GMSAyNSAwIFIgL1RUMiAzOCAwIFIgL1RUNiAyNiAwIFIg L1RUOCAyNyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0MiAwIFIgPj4gDS9Db2xvclNw YWNlIDw8IC9DczUgMzYgMCBSID4+IA0+PiANZW5kb2JqDTYgMCBvYmoNPDwgL0xlbmd0aCA2 MDggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImMVNtq20AQfd+vmEepoPXO 7FWPaeq2CaQYrIdAyIOjyEFuLsU2tdvfaD+4M5Kl2JCWIvDOynM55+xZTc43HuoNYPdsajX5 NEd42CiEFpQNEH0A7wwUkQysG7VU7ys1qSri9GqpDDinkayDggPjwEAZNYHFqIOD6okz5OHO hdHGIEFV87tqp7LpfvH07bHJq5Wack9Bcj6HPn9+zgguOViB0ZFgB2jgCm5uDdwr64OmBBgS eKsdIHnZM7q5oDNAAsV7KEgA2YQMETB6zRUCiYGY1GG4erlrHxv4fCYoJh9xYIVJG2sjFJi4 gzNG2+MOeEoKR1I32Wzd5EHHbNl2yx6u89vqUhhimcAlxhOEEbJCDG8AfSzpKXxidgzfpTjA Px1uu+GvlGaLdfO8PVCSsayhIldCCAEYenLCRTbIq/eoYx865lEriSiaTrE+FdkCUi9rrSxa zYFsLPc4pErY10t0aHpIlVHD/Fpt3joi5C5cQKlk7zDFjpnxR7L+2mwX27aeLPOkMWv3zX3u tct+w8UMnpvt7mX9tdOZdQyjjtwlxpJnmN6a1pMAIsR+jNGEAYbfWIZRVUbFs7OLs5moyEdl LTFYo32ZWOYP419TIbOCnrYLvSFD+R/nakujk2Ot7JvnKqfJCK6+/NuZ2FF7bfKWM2+ya42d G8kOIqW/ikSEEpAbRRJhuKt+lQfdaDo/2P5l/wMW99+b9bb92T7nBd+V7CEviGQw34ple3QX pNQdND807n3Kb51L2jm2KqEZNo/9hm8PR0TH0ZjAn4CjbPajTRzdvVN/BBgAGfMJQwplbmRz dHJlYW0NZW5kb2JqDTcgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDMwIDAgUiAN L1Jlc291cmNlcyA4IDAgUiANL0NvbnRlbnRzIDkgMCBSIA0vUm90YXRlIDkwIA0vTWVkaWFC b3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDT4+IA1lbmRv YmoNOCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMSAy NSAwIFIgL1RUMiAzOCAwIFIgL1RUNiAyNiAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0 MiAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMzYgMCBSID4+IA0+PiANZW5kb2JqDTkg MCBvYmoNPDwgL0xlbmd0aCA2MTAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SImMU01PG0EMvc+v8HFTKZOxPZ9HmtIPJFCk7AEpcKDbpApKoEqQ4OfXns2mgKIKrZL1ztjP 783zTKb7AN0esD77zky+zRF+7w3CGgxHSCFC8A7GiRzslmZlPrdm0rYk6e3KOPDeIrGHsQTO g4OSLAEFWY7QbiVDH0EeO+scStUQemifTXP+crf9s1nCTdM9PjzZm9GovTfn0kOZTefQ18+n wuhCgntwNhE8Azq4hMWtg1+GQ7SUAWOGwNYDUtBvYTtXtg5IqYUAY1KCnFEoA6ZgpUIo9nRY mWnkciV2+fhzLby+nymhyVccBGO2jjnBGLOAeecsvwbDE3qdAi6a2W45ijY1q3V9vcD16La9 ULFYMvgs1KKKQ5Qj9Ef+r0/7rRISoaLE53Ro/u6w30ua3e2WD0+DpLaNR1hJSqkIrOtN5EBW nCdEMVOBLYmdw38q8dhEiAwKmx9nM0UW+swkJJ0NJUvrL8ct0cpRJyr2VsXyAZlcnM0eglSc kqniOvHr6v9GYZX2D+SUUYvm2mI1h/joDRc9CpR5ZVYePtv4AdYYSbOR8CRrruY006vDsaCM tkGZZJ9raYStIfS2iL+pmrGRjiSi5ER9wkNCzdfR2Rg1y+keq9CNWX0ycjF1oAJn5bA1nIpe zlJs6vFY51YWslbKfq61VFgv0Ea+SaebHeltrpBvU6SkCLm+hfc9ZqmkdMUNGcJZPVfESkU3 Bbgn6QvEqHIwe13VD5R3CKg8NfTiT2c0ouTq7e1TUYdU6vXdGUauVslPp+yQqmFfX0evBz2k aquhf2f25q8AAwBgtwkmCmVuZHN0cmVhbQ1lbmRvYmoNMTAgMCBvYmoNPDwgDS9UeXBlIC9Q YWdlIA0vUGFyZW50IDMwIDAgUiANL1Jlc291cmNlcyAxMSAwIFIgDS9Db250ZW50cyAxMiAw IFIgDS9Sb3RhdGUgOTAgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsg MCAwIDYxMiA3OTIgXSANPj4gDWVuZG9iag0xMSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERG IC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMzggMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEg NDIgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDM2IDAgUiA+PiANPj4gDWVuZG9iag0x MiAwIG9iag08PCAvTGVuZ3RoIDMxMiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiVSPy2oDIRSG9z7Fv3QgGnV0Ltu0oVBos4jQRekiTEwiJGOYMSQv0Cdo+741M71yQH4P x+/zTG96g6aHHKpvyPRuKbHtiYQHyQuUpoDRAqxUAp0jGzKzZGqtSuN2QwS05lLlGiwFoSEg teEKKq/SaQ9p4lqJzAQXQpSwDRlSDXsmz3R2ihP4Fo/zh0zzgi4ywSs6ec1e7H16nCsuhTBg KQx4pQquNepyxLNv1he1HKkfGdO15DV9Sria+rhD3Dk0oe392nWr6EOLsMFb6/ro1u9X/WKC UcorLSWY5LKuDOztl8RcJUOUZrScHQ5+u4vp45qiO7VpkfESsvQ89Vbowin6oddmiud0i30I x3E99qvSuf6jqn5UyvxbqKLLRJHUObTuEuEuq8Nx70bc3JJPAQYAZ0dvQgplbmRzdHJlYW0N ZW5kb2JqDTEzIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAzMCAwIFIgDS9SZXNv dXJjZXMgMTQgMCBSIA0vQ29udGVudHMgMTUgMCBSIA0vUm90YXRlIDkwIA0vTWVkaWFCb3gg WyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDT4+IA1lbmRvYmoN MTQgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjEgMjUg MCBSIC9UVDIgMzggMCBSIC9UVDYgMjYgMCBSIC9UVDggMjcgMCBSID4+IA0vRXh0R1N0YXRl IDw8IC9HUzEgNDIgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDM2IDAgUiA+PiANPj4g DWVuZG9iag0xNSAwIG9iag08PCAvTGVuZ3RoIDc3OSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiaRVy04bQRC8z1f00Y7k8XTPc48EkQQkEyvsgQhxIMYmS3hIthWT/Eby wemenbUNMQglssTWiJ7qnqra2eH+wsNkAZh/i4kavj9BuFoohAaUDRB9AO8MDCIZmE/VTL2t 1bCuicvrmTLgnEayDgYMjAMDVdT8zxC1g/qWC+THxAOjjUEP9URlFKFeqd7xwegjrJrlV7iA 2/svzc0UPuz162t1wF1ktv0TaClO9nmmIwbXYHQkWAEaGMHZuYFL5SgAcXdvuSuS15Rk2BMZ 1gDJZN7DgGQ+541ODghRhyQjtpPZbjKT8mSj7WmG77A7LyZtrI0wwCRk0cipN2T4+LyYWYXw rDeeT/tBx96syY8HOO2f10dyUkyBmRzYICdDZAXdev5tsR+fhNCy9uBS1/yJ2E+PNL6YT++W G4GRtVRYeQjBAI8u6qW8QDbbO69jyNAZDokSREHshlKKnkt5vzwninh8lzHFdaXAdrugwtlW 5kal+0QtdnmFPuX6ZDlTnVXGb4n6a7G8WDaT4ayfNPaah+ll32vX+w2HY7ibLlf3829ZZVYx rFVklhgr7mHayFIyWnJOpY3RhAG6v7EKa015Ku7dO9wbFw0lj4oSgec4tvEzuB2/5+2zJkgQ Pdu9yz4xjVuNPr0YQEtBzrAh2RXAZ7PHw6XnVTFVzrb1nSqiBLPrjR7o1hnzXcrvH37AxeX3 6XzZ/Gzu+gOvQ++qPyCSzjzIrNmKvmx1ReRCXGLJwXaknZNkVqlb3LSLKIjQbKOuQFzbLJjd WWL05Y1yluMdEzNaeWcytnzJBb4x2H+BPiCHUZCrguaNbaVzQpPyc6Jc5cRiWcjdWCoFttsF Fc5SKp267iXrr0nklvYvJzK/DbtiSUT/Fkui6v9j+YhEh9cE8/P6UpQjiGa2MmvHBIs53Klz jKItjpFJG8dQxLcpP9eOYfmalcoM83ZBhbOUSqeuuziWFXWy35bvTET9mlvapfy98e6vWzrL 2V4oo+PjF/X0hottVW3R7H7RTzVmIcl2Ov4RYADgzqNdCmVuZHN0cmVhbQ1lbmRvYmoNMTYg MCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDMwIDAgUiANL1Jlc291cmNlcyAxNyAw IFIgDS9Db250ZW50cyAxOCAwIFIgDS9Sb3RhdGUgOTAgDS9NZWRpYUJveCBbIDAgMCA2MTIg NzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANPj4gDWVuZG9iag0xNyAwIG9iag08 PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMSAyNSAwIFIgL1RUMiAz OCAwIFIgL1RUNiAyNiAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0MiAwIFIgPj4gDS9D b2xvclNwYWNlIDw8IC9DczUgMzYgMCBSID4+IA0+PiANZW5kb2JqDTE4IDAgb2JqDTw8IC9M ZW5ndGggMTUzNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiaRXzW4bNxC+ 71PwKBf1mjMckrtH122aBnBg1DqkSHJIFbl1YsVAbMDpA/S9O9+QXMmWLCcpAnhnxPn95ofM 0clNdIsbR/bvZtEd/XpO7q+bjtyl60JyOSYXxbvDzN59XnYX3U/z7mg+ZxWfX3TeifTEQdyh El6cd2Pu9XBgcPOVSuCfWj70vfekvy06UD64+V03m/+9dM+uru/c9YW7Vfrs3eLj8vbmYP6h +0UdIbyTc1eMnJ9oWC+U+OB8n9ndOfLu1L1+6937Tjg5Vpcx9OKIY88D4j1HvN4xgovRHTJC lOj7QRwT9WmwIBHQYAGdXv95ebV0z48RwtEzannS0PsQsjukARayR35rC3Q/TbI0YfD17Ozz 8iD1eXZxaZ8v7tXB2/kLpEeqC3BzRDrE3Oc0Bb0J8v3waYyKuWrmFv5952HCuKR09u7z8tPt UykxST9uWv32lLRNqPdDym7+s0q9UTk7v/5in3/cc/seH/jZmwPT0CTTlKS6yXnUJH3pJB58 j/bjoB1lVWJKrv3NY5qCY2ur2W/HZ7VxeNBMtDtKN3ja7IbHgQ0+oS8i7QYWcKqX09/34hg4 Ify1kV047u0K7e9OwuBSHtyqC4P2mNFB5zFpZysmIGMit+hAyZj6wK5IioiDNr6LTkZB7mDQ aVUSZFEHVW1WUXhq3hfdTUXsySpxiN9cJUyylYqZv69UzOP/L9U9I4rgVxTrj61ihdFPxQKN uqinVizOoRaL/bAuFgF31cZ3KhbVnVsljTR1UNVmFYWn5h3FMkQF+qGuwkz652k8ZbCVGIUe 4mlwlsqdvny5F8/oVTiM44aZ3c3/qicDksOEo14vpLdDCAhDhv6rFqGUZb8VszkLtgdnJy9r t1mpSOHTbCixelh1emP0oks4MEC9UocAHcMSqArEshW9nrLml3AWYOOqu/ihAE6jViDt3jYP Y9ZWR4Yh5Y27h6KF+tSGFrtUN1S/r103ctIENR6dUUmAHABMIDKNuGZwoh9ISj/obkiWn6Kh 0wN2hDEDAxJ6gwEKFc8ZB5wHaBm0WQAtDjw2m01+ZkCq1rQBIT6gX81a0I0iTWDVCVlhWLMn NnuiK1ZD5xQQ0Ko8AVIq9pp4xo1UDNr5gFSCNg521qCzVGwFvGP0l5HQD6syqRY3ZBVuHuxT 8kTgI4JiPdQQglbevGqSUmY+2k6FhDdArkAVWepDqoYishXyJcWghdEgog9TWNqNmltETxUJ QxNXm0amv6JVPTbvBmQxVXsipZe1RFSKi1+wHVLEZlmVVaHHGccihmfMoSCsBtGJ1gzYSYGA DMlom0cZzN8AEsPUGI9NVhkeTbaq8Gg/wlQlVdAGsZ2ktUqaTKXJg8ma4xrNAjE+XBEPLyhC f6gxQ//eZrOho2k9UOt7bwBj+K2zwJA+awG87ovUGBktg8bYWFQVGaLlT76RsJtwPdcTvfGa ipEmgWvQPBRZOG7RtFR33cCEJ7eM/DDBGW/lptdCsAZnzlZGQQBklRMrRWVCsoAKw6V+VYVL bWGKaxnR22k6kTSpSGqmQBUPRVaqCRn25qY3iRYvbBVvFh7mFtI03rE4VwaTiZAy8JwYwNmY sj2aSrRimqlCqmC2qOtJXqvkyVSePBRZOK7R7MktZDQmJ9nKTdoDCc22fkWJx1CgM6VcMmDC WBpqFHt5FKYE3hiTrSqc7UeYqqTaJeu5esJ+UjHSJECZhyILxy2aPRkKYTUpDFsZxt0ZAk/0 i/ZnBTmsoQ9+ow6M121jyBqzqRC1KlcSdq069QTlqSogi6mBm4cia482X7v38f7MmD3dRVsZ pscytMvWMrSWA4PI7Wq17qmMPQkbUzdoVZHW1I20+PuJ5Q2Vtam1hyKbqom0fwIHdKnE7QnM uzPEWzTmZK/hsj/xJshlf2ab/cokseEpTCzLparEsnhgKtYahtF2YmHFc1Mx0kwZVTwU2Vze 4vjum8MRNYxxu4YDMtx6wWmXqEE8g8r7zS6Z9X89Eq6Vw/asu+tmx5/e/+gub93V9fXHG3dx +Wn5b0XuvwEAU69+7wplbmRzdHJlYW0NZW5kb2JqDTE5IDAgb2JqDTw8IA0vVHlwZSAvUGFn ZSANL1BhcmVudCAzMCAwIFIgDS9SZXNvdXJjZXMgMjAgMCBSIA0vQ29udGVudHMgMjEgMCBS IA0vUm90YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAg MCA2MTIgNzkyIF0gDT4+IA1lbmRvYmoNMjAgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAv VGV4dCBdIA0vRm9udCA8PCAvRjEgMjUgMCBSIC9UVDIgMzggMCBSIC9UVDYgMjYgMCBSID4+ IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDIgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDM2 IDAgUiA+PiANPj4gDWVuZG9iag0yMSAwIG9iag08PCAvTGVuZ3RoIDEwNzIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImkVttuG0cMfd+vmEe5gMZDznUfHfeSBrVhxHpI kOQhUeTCgW0VUlCnH5D/Lg9ndiXZqi8NBGjJXQ7Jc8jhzOHxOpr52pD+1vPu8LdzMn+uOzKX pvPJ5JhMDM5MMzuzWnQX3YtZdzibsZjPLjpnQrDEPpipCC4YZ/ps2TCTTcHMrsUCP/E8ddY5 knfzDpLzZnbbTU6Wny6vFubktblZ3n63B7Mv3S8SAGkdn5u6+PxY0nklwhfjbGZza8iZE/Pu gzOfu+CLCUjS22CIo+WCPM+RpzOMpGI0U0ZqIbEtQR7epqLJIZGyncjLI6Rw+CsN+KhY5302 UyrwUBgoNx5oFx4pPDh8NzlbLQ6SzZOLS318M28OPsxeAR4JDZxBLuAQsxVlSHqb3N30KZBw bbiM6e8G9yO3FdLZx9Xi5utjkCg52297fT4kaQ+yrqRsZj+L1Xux0+/Lb/r4x7zU59GBm7w/ 0BUCMo0gJUzOvYB0tYOQESrKXjpJq8SUzPCf+zQmx9pOk9+PzlrjkEAIfWnd4Gi7Gx4gtte+ iC7uJRZ0SpST1w/yyKStsXGyj8cHu0L6u/O9N1la+rrjvoAFKMxsUmCbVIosW7aDFFwGwGbp pTewHM95F0q2IagSZSc2U4h1PaTqs1ki0BB93q0bY/9dJRbSYl393CphJws+ySqHZ5bKC+nY woV+oFTeF93F206EiCcU6+1OsUJ04FCKJcSJA8g+CMul14JAVLIhBelqrxUC5w5Ty+lTauES 0EOJkQdLiK1WkKrPZopIQ3QUqzJa5AO15s8kf0/hU1s/8b3WVzpr5U5OTx/hU1t/42R/67+x pDSyH1mUQwXD0PtaVPu0MVhH/f4O8DoFJ8enw0QAM+QzEqSEfpf0oow82UxJ982VBKQYdAim jIkMC1I94zOFrHNXzCXiVXfxU+M7SzKO93bw3aSl2wGRXL919FDUXB8Z0J70ZN1a+v+6dQuT TJdU84m6E0DBSCMn0mMpRhzh1xVmZChXHRiSZiaxoVS54D7h/GLnQYBwJ1BRUsJUUXLlSiAG XqpcyZVWLrDI1YJ6vSx4lq1dXYIJzYXEAAPlWkuIWScKiesCETQMiqAQ86ogoNi2JXCPl+Kq iXPtgDR+iWlcEtPgClKNoLYauGUzR453e/TeKSZ0y1eZzdJqOxtLi05jfzaocIyhLoRLpblO fZCqUJNNG8Vh/jelst6WAEVpJFVRDwo7qsybJTy64jECD4fMkM0Add8BoOezsHUX4ITvYZMb JBfF5mvwgjtiTSnXyE2pCVUlVdu2JNaXcBUHbEHXti+RxyUQqyuV1KraInDL5iFsQW+x6T42 D2z3pmivV7jcD0ehNsDmVOrHm1nQm9kfy+Vf5mK5Wvy9WJlPi6+3i8VN9SsXKeoj7lEyFszH m89mvMV9b6z+OwByu2HICmVuZHN0cmVhbQ1lbmRvYmoNMjIgMCBvYmoNPDwgDS9UeXBlIC9Q YWdlIA0vUGFyZW50IDMwIDAgUiANL1Jlc291cmNlcyAyMyAwIFIgDS9Db250ZW50cyAyNCAw IFIgDS9Sb3RhdGUgOTAgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsg MCAwIDYxMiA3OTIgXSANPj4gDWVuZG9iag0yMyAwIG9iag08PCANL1Byb2NTZXQgWyAvUERG IC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMzggMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEg NDIgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDM2IDAgUiA+PiANPj4gDWVuZG9iag0y NCAwIG9iag08PCAvTGVuZ3RoIDQyMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiZSSy47TMBSG936KX2LjSGPXtzgJGzQDCISgI4F3iEWaetqgTILqlIoH4Am4PC8nyYgp oFkgS9ZJfM73f7K8eppyNAl6XqlhqxfvNHaJabRg1qPIPXKnIAqjcIjshl0FtgrBUHu4YQrO SW2sg6BCOShol0sDY40sEW6pY1pEFkoqpWmqYXNlEU6Mv44pDX1CF+tDH7dfs/CRRmhYK5VD UDFDjfHSOVQFoQm6sKqZNWHe8x+ZcJWRFb/OhJaGfxrboX+kH2cfwivqMaVU2lQQppCVn4C+ kKWDtvacOAHnirJn7M9MWOWl5dsB6+uAustETindcMLLS9Rp+cSb9fou6R91q82U9L/q5kF1 mztp/lY/c9fuzD2Xjl9mhvZ+Em7qHpsI2sn4ApvjiHac//bxczxMZ0usLFVuMfkoXSA8u0ux 9ylmSfnW9k133Mbt98xLz7H5QsSE4UQRb+UME/c057z7TdPlH6KeX5FowY/jBfZ0v/VmIL1x P6SI2O72k2eKCS2Rj93YigdMz97Zwt8PtxndHW/73ZN55nlgvwQYAPutsycKZW5kc3RyZWFt DWVuZG9iag0yNSAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0Vu Y29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvQ291cmllciANPj4gDWVuZG9i ag0yNiAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0 Q2hhciA2NSANL0xhc3RDaGFyIDgwIA0vV2lkdGhzIFsgNzMxIDAgMCAwIDAgMCAwIDAgNTQ2 IDAgMCAwIDAgMCAwIDUyMSBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VG b250IC9Db21pY1NhbnNNUyANL0ZvbnREZXNjcmlwdG9yIDI4IDAgUiANPj4gDWVuZG9iag0y NyAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0Q2hh ciAzMiANL0xhc3RDaGFyIDEyMiANL1dpZHRocyBbIDIyOCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIA0wIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU0NyAwIDAgMCAwIDAgMCAwIDU0NyAwIDAgMCAwIDAg DTAgMCAwIDQ1NiAwIDAgNDU2IDQ1NiAyMjggNDU2IDAgMTgyIDAgMCAwIDAgNDU2IDQ1NiAw IDAgMjczIDAgMjI4IA0wIDQxMCAwIDQxMCA0MTAgNDEwIF0gDS9FbmNvZGluZyAvV2luQW5z aUVuY29kaW5nIA0vQmFzZUZvbnQgL0FyaWFsTmFycm93LEl0YWxpYyANL0ZvbnREZXNjcmlw dG9yIDI5IDAgUiANPj4gDWVuZG9iag0yOCAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlw dG9yIA0vQXNjZW50IDExMDIgDS9DYXBIZWlnaHQgMCANL0Rlc2NlbnQgLTI5MSANL0ZsYWdz IDQwIA0vRm9udEJCb3ggWyAtOTMgLTMxMiAxMTg3IDExMDIgXSANL0ZvbnROYW1lIC9Db21p Y1NhbnNNUyANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAwIA0+PiANZW5kb2JqDTI5IDAgb2Jq DTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgOTM1IA0vQ2FwSGVpZ2h0IDAg DS9EZXNjZW50IC0yMTEgDS9GbGFncyA5NiANL0ZvbnRCQm94IFsgLTIxNCAtMzA3IDEwMDAg MTA0OCBdIA0vRm9udE5hbWUgL0FyaWFsTmFycm93LEl0YWxpYyANL0l0YWxpY0FuZ2xlIC0x NSANL1N0ZW1WIDAgDT4+IA1lbmRvYmoNMzAgMCBvYmoNPDwgDS9UeXBlIC9QYWdlcyANL0tp ZHMgWyAzNCAwIFIgMSAwIFIgNCAwIFIgNyAwIFIgMTAgMCBSIDEzIDAgUiAxNiAwIFIgMTkg MCBSIDIyIDAgUiBdIA0vQ291bnQgOSANPj4gDWVuZG9iag0zMSAwIG9iag08PCANL0NyZWF0 aW9uRGF0ZSAoRDoyMDA0MDIyODIzMDQxOSkNL1Byb2R1Y2VyIChBY3JvYmF0IERpc3RpbGxl ciA0LjA1IGZvciBXaW5kb3dzKQ0vTW9kRGF0ZSAoRDoyMDA0MDIyODIzMDQ1OS0wOCcwMCcp DT4+IA1lbmRvYmoNeHJlZg0wIDMyIA0wMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDMxNzAg MDAwMDAgbg0KMDAwMDAwMzMyMiAwMDAwMCBuDQowMDAwMDAzNDU2IDAwMDAwIG4NCjAwMDAw MDM5MjUgMDAwMDAgbg0KMDAwMDAwNDA3NyAwMDAwMCBuDQowMDAwMDA0MjQ2IDAwMDAwIG4N CjAwMDAwMDQ5MjcgMDAwMDAgbg0KMDAwMDAwNTA3OSAwMDAwMCBuDQowMDAwMDA1MjM2IDAw MDAwIG4NCjAwMDAwMDU5MTkgMDAwMDAgbg0KMDAwMDAwNjA3NCAwMDAwMCBuDQowMDAwMDA2 MjA5IDAwMDAwIG4NCjAwMDAwMDY1OTUgMDAwMDAgbg0KMDAwMDAwNjc1MCAwMDAwMCBuDQow MDAwMDA2OTIwIDAwMDAwIG4NCjAwMDAwMDc3NzMgMDAwMDAgbg0KMDAwMDAwNzkyOCAwMDAw MCBuDQowMDAwMDA4MDg2IDAwMDAwIG4NCjAwMDAwMDk2OTcgMDAwMDAgbg0KMDAwMDAwOTg1 MiAwMDAwMCBuDQowMDAwMDEwMDEwIDAwMDAwIG4NCjAwMDAwMTExNTcgMDAwMDAgbg0KMDAw MDAxMTMxMiAwMDAwMCBuDQowMDAwMDExNDQ3IDAwMDAwIG4NCjAwMDAwMTE5NDIgMDAwMDAg bg0KMDAwMDAxMjA0NCAwMDAwMCBuDQowMDAwMDEyMjU3IDAwMDAwIG4NCjAwMDAwMTI2NTkg MDAwMDAgbg0KMDAwMDAxMjg0NCAwMDAwMCBuDQowMDAwMDEzMDM4IDAwMDAwIG4NCjAwMDAw MTMxNTcgMDAwMDAgbg0KdHJhaWxlcg08PA0vU2l6ZSAzMg0vSURbPDg1OGQ1Y2I3MDMwYzEz NmI3ZmM1ZWMyMTZiOWFmNGU2Pjw4NThkNWNiNzAzMGMxMzZiN2ZjNWVjMjE2YjlhZjRlNj5d DT4+DXN0YXJ0eHJlZg0xNzMNJSVFT0YN --------------060809070605000901050709-- From nemo-admin@ietf.org Sun Feb 29 04:43:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13294 for ; Sun, 29 Feb 2004 03:56:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMk0-0005hA-KK; Sun, 29 Feb 2004 03:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMjl-0005cg-Dc for nemo@optimus.ietf.org; Sun, 29 Feb 2004 03:55:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13276 for ; Sun, 29 Feb 2004 03:55:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxMji-0000GL-00 for nemo@ietf.org; Sun, 29 Feb 2004 03:55:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxMio-0000Bo-00 for nemo@ietf.org; Sun, 29 Feb 2004 03:54:51 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1AxMiK-00006d-00 for nemo@ietf.org; Sun, 29 Feb 2004 03:54:20 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i1T8sCha019556; Sun, 29 Feb 2004 00:54:13 -0800 (PST) Message-ID: <40419C64.4010509@cs.ucdavis.edu> Date: Sun, 29 Feb 2004 00:01:40 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eun Kyoung Paik CC: nemo@ietf.org Subject: Re: [nemo] merged multihoming draft References: <20040223004618.A48134@mmlab.snu.ac.kr> In-Reply-To: <20040223004618.A48134@mmlab.snu.ac.kr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 merged draft is a very good step to comsolidate various interests in multi-homing NEMO. Thanks very much. After reading the draft, I have one comment regarding: > 2.4 (1,N,N): Single MR, Multiple HAs, Multiple Prefixes > > The (1,n,n) mobile network has only one mobile router. However, the > mobile router advertises more than one NEMO-prefix, and also > associates to multiple home agents at the same time, possibly one > home agent per home address. No assumptions is made on whether or > not the home agents belongs to the same administrative domain. and, > 5. Evaluation of Basic NEMO Solution > .... > o (1,N,N) Mobile Network > The (1,N,N) mobile network has one mobile router registering to > multiple home agents multiple NEMO-prefixes.The same question of > whether the same home-address can be simultaneously registered to > multiple home agents. It seems to me that, from the above segments of text in the draft, it is not clear whether different prefixes under the (1,N,N) and maybe (N,N,N) cases should be registered to different HAs. My concern is that this capability seems to me a key motivation to have multi-homing. I.e., when one of the N HA's is down, any CN in the public Internet, can still access the MN via other HAs. But, of course, we will get our routing table larger and larger... I heard a proposal (I forgot the source) that each MNN will have multiple IP addresses (so it will have one address in each prefix in this particular multihoming NEMO), and it is the responsibility of the CN to decide "which IP address to use to communicate with the MNN". Assuming that the CNN will be able to use DNS-like or other host identities to find out this multi-address binding. (may this is from the Multi6 working group). Certainly, under this proposal, we don't need to register different prefixes to different HAs. But, otherwise, it seems to me that this feature is very useful. -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From nemo-admin@ietf.org Sun Feb 29 06:47:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17300 for ; Sun, 29 Feb 2004 06:47:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxPPQ-0000ZP-J7; Sun, 29 Feb 2004 06:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxPPL-0000ZE-VF for nemo@optimus.ietf.org; Sun, 29 Feb 2004 06:46:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17285 for ; Sun, 29 Feb 2004 06:46:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxPPH-0006iF-00 for nemo@ietf.org; Sun, 29 Feb 2004 06:46:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxPOM-0006by-00 for nemo@ietf.org; Sun, 29 Feb 2004 06:45:56 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1AxPNq-0006X9-00 for nemo@ietf.org; Sun, 29 Feb 2004 06:45:22 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i1TBjCha020217 for ; Sun, 29 Feb 2004 03:45:13 -0800 (PST) Message-ID: <4041D0D1.4060608@cs.ucdavis.edu> Date: Sun, 29 Feb 2004 03:45:21 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG Content-Type: multipart/mixed; boundary="------------050109070406020809090808" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [nemo] draft-jung-nemo-threat-analysis-02 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. --------------050109070406020809090808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Souhwan sent me this draft on Feb, 13, and asked me to submit. I appologize that I forgot to send it, so it didn't appear in submitted draft. This draft currently described mainly the attacks we presented in the previous IETF. (The draft we posted last time, version 01, didn't really reflect our presentation.) Attached is the draft. Any comments will be highly appreciated. Appologize again for the delay. -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- --------------050109070406020809090808 Content-Type: text/plain; name="draft-jung-nemo-threat-analysis-02.txt" Content-Disposition: inline; filename="draft-jung-nemo-threat-analysis-02.txt" Content-Transfer-Encoding: 7bit NEMO Working Group Souhwan Jung Internet-Draft Soongsil University Expires: August, 2004 Fan Zhao S. Felix Wu UC Davis HyunGon Kim SungWon Sohn ETRI February, 2004 Threat Analysis on NEMO Basic Operations draft-jung-nemo-threat-analysis-02 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes potential security threats to NEMO basic operations. The threats are mostly related to the integral use of IPsec and IP-in-IP tunnel between MR and HA. Threats related to the operations of nested MR, and multi-homing (multiple MRs) are also investigated. Finally,security requirements for NEMO basic protocols and specific implementation notes are described. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. S. Jung et. al. Expires August, 2004 [Page 1] Internet-Draft Threat Analysis on NEMO basic operations February 2004 Table of Contents 1. Motivations 2. Threats to MR-HA tunneling 2.1 Threats to the MR-HA IPsec Transport SA 2.2 Threats to IP-in-IP tunnel between MR and HA 3. Threats to error processing operations 3.1 DoS attack due to error processing of BU 4. Threats to interactions between MRs Changes from previous version References Authors' Addresses Intellectual Property and Copyright Statements S. Jung et. al. Expires August, 2004 [Page 2] Internet-Draft Threat Analysis on NEMO basic operations February 2004 1. Motivations Networks in motion (NEMO) introduces a network entity called Mobile Router(MR)[2]. MR has different features from Mobile Host that operates based on Mobile IP technologies[4]. Since MR functions both as a mobile node and a gateway to provide mobile network with Internet access to outside world, it needs specific treatment for managing operations and securities. The MobileIP/NEMO community has spent quite a lot of efforts in designing security mechanisms to protect critical control messages exchanged among protocol entities such as HA (Home Agent), MN (Mobile Node), or MR (Mobile Router in NEMO). In particular, the authenticity and integrity of the Binding Update (BU) messages must be protected very well. Otherwise, many malicious attacks such as traffic hijacking or denial of service are possible by intentionally injecting incorrect BU messages. Under both MobileIP and NEMO, IPsec Transport ESP (Encapsulating Security Payload) [8] is used to protect the binding update messages between HA and MN/MR. IPsec itself provides a network layer security service between two network entities, and it nicely integrates a number of strong cryptographic components under its architecture. Due to this strong fact of IPsec security, many Internet protocols, especially in the network layer, have been built on top of the security strength of IPsec. The list is currently growing, but at least, we can include OSPFv6, TRIP (Telephony Routing over IP, under the IP Telephony working group), RSVP/NSIS (Next Step in Signaling), L3VPN, PANA (Protocol for Authentication and Network Access), MobileIP and NEMO. While IPsec itself is indeed quite secure, the security of the protocols using IPsec might still be very questionable. In fact, through our security analysis toward NEMO, we realize that the IPsec architecture itself does NOT specify/mandate its relationship with other functional components (such as packet forwarding, ingress filtering, IP-in-IP tunnel, or application interface) in the same router. Therefore, as will be shown later, most of the IPsec implementers have not considered how to properly glue the IPsec engine with the rest of the system such that the whole system (such as the MR in NEMO) can be easily broken in. In short, IPsec by itself is indeed doing its job securely, but the component putting packets into the IPsec module might not. This draft describes vulnerabilities to the basic operations of NEMO (NEtworks in Motion), and discussed its potential security problems, especially, related to IPsec and other tunneling functions. Through our experiments (as well as our discussions with IPsec implementers from major router venders), we validated that the problems we raised here are practically possible. S. Jung et. al. Expires August, 2004 [Page 3] Internet-Draft Threat Analysis on NEMO basic operations February 2004 2 Potential threats to network in motion The major threats to the basic operations of mobile network are from the tunneling operations. Tunneled packet can disguise itself using fake source and destination addresses. The MR or HA should be responsible to verify the validity of those packets. Since the basic operation of mobile network is based on the IPsec tunnel and IP-in-IP tunnel between MR and HA, the threats to those tunneling operations will be investigated in this section. 2.1 Threats to the MR-HA IPsec Transport SA Three different potential attack scenarios are presented in this section. 2.1.1 BU spoofing: no ingress filtering at MR The first case assumes that there is no ingress filtering activated at MR. Figure 1 shows the attack scenario. MNN MR HA |--------| |----------------| |-----------| | | | |-------|| ESP | |-------| | |Attacker|---------->|-------| IPSec ||====================| | IPSec | | | | | | ^ |-------|| Transport | |-------| | |--------| | |-|--------------| | |-----------| | At this point, MR | checks the packet | cannot tell the fake | using ESP and |-----------| BU from a BU from |-----------| updates Binding |Src=HoA | itself, and applies |Src=CoA | Cache (corrupts |Dst=HA | IPSec ESP. |Dst=HA | binding cache) |... | |ESP | |BU(MNP,CoA)| |... | |-----------| |BU(MNP,CoA)| Attacker |-----------| generates Packet is a fake BU encapsulated with ESP Figure 1. MNN spoofs the BU of the MR without ingress filtering In the Figure 1, a malicious MNN generates a spoofed packet by setting source address to the HoA of the MR and destination address to the address of HA, and also includes the BU of MR as a payload. The format and contents of the BU message look exactly like a BU from the MR. When the MR received the packet from the attacker, it first saves the packet to the buffer, and checks the security policy database (SPD) of the packet. Since the MR cannot tell the fake packet from the packet from itself at this point, it finds that the packet requires the IPsec processing, and forwards it to the security interface for IPsec processing. Then the IPsec module encapsulates the packet using the ESP transport mode and the associated SA. When the HA received the packet, it verifies the packet by checking the IPsec ESP SA that will be valid because it is encapsulated by a valid MR. Finally, the HA is fooled to believe that the BU is from the MR, and updates the binding cache of itself. S. Jung et. al. Expires August, 2004 [Page 4] Internet-Draft Threat Analysis on NEMO basic operations February 2004 This attack is possible due to two reasons. The first one is that the MR is not using ingress filtering to check the topological correctness of the source address. If the MR checks the source address of the packet, and finds that the source address is set to itself, then it will drop the packet. Another reason is that the MR forgets where the packet came from, once it gets the packets and saves to a buffer. If the MR can distinct the packet stream generated by other nodes (Layer2) from those by itself (Layer4), then the fake packet will not be processed by IPsec, and will be forwarded to HA encapsulated in an IP-in-IP tunnel. Then the attack will fail to modify the binding cache of the HA. 2.1.2 BU spoofing: with ingress filtering at MR This attack scenario is similar to the first scenario, but assumes the ingress filtering at the MR. Figure 2 shows the attack scenario. MNN IP_in_IP MR HA |--------| packet is |----------------------------| |-----------| | | generated ||-------| |------| |-----|| ESP | |-------| | |Attacker|---------->||Ingress|-|tunnel|---|IPSec||===============| | IPSec | | | | | ||filter | |decap | ^ | || Transport | | | | | | | ||-------| |------| | |-----|| | | |-------| | |--------| | |-------------------|--------| | |-----------| | | | checks the |-------------| |-----------| |-----------| packet |Outer Src=MNN| |Src=HoA | |Src=CoA | using ESP |Outer Dst=MR | |Dst=HA | |Dst=HA | and updates |Src=HoA | |... | |ESP | binding |Dst=HA | |BU(MNP,CoA)| |... | cache |... | |-----------| |BU(MNP,CoA)| |BU(MNP,CoA) | At this point, MR cannot |-----------| |-------------| tell the fake BU from a BU Packet is Attacker generates from itself, and applies encapsulated a fake BU using IPSec ESP. with ESP IP-in-IP tunnel Figure 2. MNN spoofs a BU of MR with ingress filtering In this scenario, the attacker generates a spoofed BU message using IP-in-IP encapsulation as shown in the figure. Now, the outer source address is set to the address MNN and the destination address is set to the address of the MR. The inner source address is set to the HoA of MR and the inner destination address is set to the address of HA. This attack is possible due to the order of packet processing at the MR as shown in the figure. If the MR performs the ingress filtering at first, and then do the tunnel decapsulation, then the fake packet can get through the ingress filtering of the MR. The rest of the story is the same as the first scenario. If the MR do perform the ingress filtering after the tunnel decapsulation, the fake packet can be dropped at the MR in this scenario. Therefore, it is very important to implement multiple functions of the MR in the right order. In real world, the ingress filtering function of the routers are not activated in many cases, and then those routers are exposed to this type of attacks. S. Jung et. al. Expires August, 2004 [Page 5] Internet-Draft Threat Analysis on NEMO basic operations February 2004 2.2 Threats to IP-in-IP tunnel between MR and HA Processing IP-in-IP packets in a mobile router requires encapsulation and decapsulation module with a dedicated protocol number. Securing IP-in-IP tunneled packets requires a specific security mechanism like IPsec tunnel mode encapsulation. The attacks to the IP-in-IP tunnel can initiate from inside of the mobile network to MR or from outside directly to HA. We will investigate two attack scenarios using MR and HA as stepping stones. 2.2.1 Attack from inside Figure 3 shows an attack scenario from inside nodes. |--------| |--------| IP-in-IP |--------| |--------| | | | | tunnel | | | | | MNN |---------->| MR |==============| HA |-------->| Victim | | | | | | | | | | | | |--------| | |--------| | |--------| | |--------| inside | | | attacker | | |--------------| |--------------| |--------------| |Src=spoofed IP| |Ext. Src=MNN | |Ext. Src=CoA | |Dst=victim | |Ext. Dst=MR | |Ext. Dst=HA | |payload | |Src=spoofed IP| |Src=spoofed IP| |--------------| |Dst=victim | |Dst=victim | |payload | |payload | |--------------| |--------------| generates a spoofed IP packet Figure 3. Inside attack using MR and HA as stepping stone In the scenario, an attacker generates a fake IP-in-IP packet setting the external source address to the address of another MNN inside the mobile network and the external destination address to the address of MR. Inside the encapsulation, the internal source address is set to a spoofed IP address and the internal destination address is set to the address of victim machine. Once the MR receives the packets, the MR decapsulates the packets, and recognizes to process the packets using IP-in-IP encapsulation and forward to the HA. Therefore, the MR encapsulates the inside payload in IP-in-IP format (external source address = CoA of MR, external destination address = address of HA), and sends it to HA. HA forwards the packet to the victim machine. The possible attacks from this scenario are IP spoofing or DoS attack to the victim machine. Similar attacks have been known to mobile network communities for a while, but the main point here is that MR can prevent this attack by checking ingress filtering after the GRE decapsulation. S. Jung et. al. Expires August, 2004 [Page 6] Internet-Draft Threat Analysis on NEMO basic operations February 2004 2.2.2 Attack from outside In this scenario, similar attacks can be initiated from outside of a mobile network. Figure 4 shows the attack scenario. |--------| IP-in-IP |--------| |--------| | | tunnel | | | | | MR |==============| HA |--------------->| Victim | | | | | | | | |--------| |--------| | |--------| ^ | | |---------------| | |Src=spoofed IP | |---------------| | |Dst=victim | |Ext. Src=CoA | | |payload | |Ext. Dst=HA | | |---------------| |Src=spoofed IP |-------| |Dst=victim | | |payload | |---|outside |---------------| | |attacker generates a spoofed |---| IP-in-IP packet Figure 4. Outside attack using HA as a stepping stone In the Figure 4, an attacker from outside can generate a spoofed IP-in-IP packet with setting the external source address to the CoA of MR and the external destination address to the address of HA, which includes a spoofed IP address as the internal source address, and the address of the victim machine as the internal destination address. If the access router of the outside attacker activates ingress filtering, this packet can be dropped at the access router. But many routers without ingress filtering will pass through this packet, and then HA may forward the packet to the victim machine. Due to this security problem, most routers do not process the IP-in-IP packets, but MR and HA in mobile networks should process IP-in-IP packets for forwarding the packets from MNN or CN. S. Jung et. al. Expires August, 2004 [Page 7] Internet-Draft Threat Analysis on NEMO basic operations February 2004 3. Threats to error processing operations 3.1 DoS attack due to error processing of BU Section 5.4 of basic support draft[3], Error Processing of Binding Update, says that if the status is set to '142', the Mobile Router should send a similar Binding Update to another Home Agent on the same home link. If no Home Agent replies positively then Mobile Router SHOULD refrain from sending this Binding Updates to any Home Agent on the home link. Additionally, the Home Agent MUST stop advertising the respective prefix(es) in the mobile network with associated Router Advertisements, and modify its own forwarding information accordingly. Following this, the Mobile Router MAY send Binding Updates in another mode (e.g. implicit) to a Home Agent on the same home link.? If a malicious MR sends a BU on the explicit mode to its HA claiming a MNP belonging to another MR, the HA will notice the MNP is not valid, and send a BA with 142 code will be generated. According to the statement above, HA stops advertising this MNP, which will be a DoS attack to the MR that is already using the MNP. If the malicious MR keep sending other invalid MNPs to the HA, then those MNPs will be blocked for service. 4. Threats to interactions between MRs In case that two or more MR exists on a mobile subnet for multihoming, there may be multiple bi-directional paths to forward packet to a HA or multiple HAs respectively. If one of the tunnel paths is broken for any reason, the MR(MR1) associated with the faulty path loses Internet connection, and should find an alternative bi-directional tunnel path through another MR2. In this case, MR1 becomes a nested MR of MR2. NEMO basic draft[3] describes that MR SHOULD not respond to the unsolicited RA messages to its egress interface, but according to the MR operations by multihoming draft[6], the MR1 SHOULD listen the RA from alternative MR2 on its ingress interface. At this point, a malicious MR may advertise a RA with a fake CoA to MR1. Then the MR1 will get a wrong CoA information. This threat is not directly related to the NEMO basic operation, but to the inter-MR operations. There is no explicit security mechanism for inter-MR operations for multihoming cases, threats related to inter-MR operations should be considered. S. Jung et. al. Expires August, 2004 [Page 8] Internet-Draft Threat Analysis on NEMO basic operations February 2004 References [1] Ernst, T., et al, "Network Mobility Support Goals and Requirements", Internet Draft: draft-ietf-nemo-requirements-01.txt, Work In Progress, May 2003. [2] Ernst, T. and H. Lach, "Network Mobility Support Terminology", Internet Draft: draft-ietf-nemo-terminology-00.txt, Work In Progress, May 2003. [3] Devarapalli V., et al, "NEMO Basic Support Protocol", Internet Draft: draft-wakikawa-nemo-basic-02.txt, Work In Progress, December 2003. [4] Johnson, D. B., Perkins, C. E. and Arkko, J., "Mobility Support in IPv6", Internet Draft: draft-ietf-mobileip-ipv6-24.txt, Work In Progress, June 2003. [5] Petrescu, A., et al, "Issues in Designing Mobile IPv6 Network Mobility with the MR-HA Bidirectional Tunnel (MRHA)", Internet Draft: draft-petrescu-nemo-mrha-03.txt, Work In Progress, October 2003. [6] Ng, C. W. and Tanaka, T., "Multihoming Issues in Network Mobility Support", Internet Draft: draft-ng-nemo-multihoming-issues-02.txt, Work In Progress, October 2003. [7] Arkko, J. et. al. ,"Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents," Internet Draft: draft-ietf-mobileip-mipv6-ha-ipsec-06.txt, Work In Progress, June 2003. [8] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [9] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [10] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. Changes from the previous version 1. Removed the threat model and generic threat stuff. 2. Described threats specific to basic support protocol. 3. Described details of specific threats to MR-HA tunneling. 4. Added thretas due to error processing. 5. Added threats to multihoming S. Jung et. al. Expires August, 2004 [Page 9] Internet-Draft Threat Analysis on NEMO basic operations February 2004 Authors' Addresses Souhwan Jung Soongsil University 1-1, Sangdo-dong, Dongjak-ku Seoul 156-743 KOREA Phone: +82-2-820-0714 EMail: souhwanj@ssu.ac.kr Fan Zhao Department of Computer Science University of California, Davis One Shield Avenue Davis, CA 95616 USA Phone: +1-530-752-3128 EMail: fanzhao@ucdavis.edu Felix Wu Department of Computer Science University of California, Davis One Shield Avenue Davis, CA 95616 USA Phone: +1-530-754-7070 EMail: wu@cs.ucdavis.edu HyunGon Kim Network Security Department ETRI 161 Kajong-Dong, Yusong-Gu Taejon 305-600 KOREA Phone: +82-42-860-5428 Email: hyungon@etri.re.kr SungWon Sohn Network Security Department ETRI 161 Kajong-Dong, Yusong-Gu Taejon 305-600 KOREA Phone: +82-42-860-5072 Email: swsohn@etri.re.kr S. Jung et. al. Expires August, 2004 [Page 10] Internet-Draft Threat Analysis on NEMO basic operations February 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. S. Jung et. al. Expires August, 2004 [Page 11] Internet-Draft Threat Analysis on NEMO basic operations February 2004 --------------050109070406020809090808-- From exim@www1.ietf.org Sun Feb 29 06:49:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17413 for ; Sun, 29 Feb 2004 06:49:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxPRI-0000nX-Ea for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 06:48:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TBmuNC003063 for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 06:48:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxPRI-0000nK-8u for nemo-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 06:48:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17395 for ; Sun, 29 Feb 2004 06:48:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxPRE-0006wW-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 06:48:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxPQH-0006qZ-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 06:47:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxPPS-0006jv-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 06:47:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxPPQ-0000ZP-J7; Sun, 29 Feb 2004 06:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxPPL-0000ZE-VF for nemo@optimus.ietf.org; Sun, 29 Feb 2004 06:46:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17285 for ; Sun, 29 Feb 2004 06:46:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxPPH-0006iF-00 for nemo@ietf.org; Sun, 29 Feb 2004 06:46:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxPOM-0006by-00 for nemo@ietf.org; Sun, 29 Feb 2004 06:45:56 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1AxPNq-0006X9-00 for nemo@ietf.org; Sun, 29 Feb 2004 06:45:22 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i1TBjCha020217 for ; Sun, 29 Feb 2004 03:45:13 -0800 (PST) Message-ID: <4041D0D1.4060608@cs.ucdavis.edu> Date: Sun, 29 Feb 2004 03:45:21 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG Content-Type: multipart/mixed; boundary="------------050109070406020809090808" Subject: [nemo] draft-jung-nemo-threat-analysis-02 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format. --------------050109070406020809090808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Souhwan sent me this draft on Feb, 13, and asked me to submit. I appologize that I forgot to send it, so it didn't appear in submitted draft. This draft currently described mainly the attacks we presented in the previous IETF. (The draft we posted last time, version 01, didn't really reflect our presentation.) Attached is the draft. Any comments will be highly appreciated. Appologize again for the delay. -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- --------------050109070406020809090808 Content-Type: text/plain; name="draft-jung-nemo-threat-analysis-02.txt" Content-Disposition: inline; filename="draft-jung-nemo-threat-analysis-02.txt" Content-Transfer-Encoding: 7bit NEMO Working Group Souhwan Jung Internet-Draft Soongsil University Expires: August, 2004 Fan Zhao S. Felix Wu UC Davis HyunGon Kim SungWon Sohn ETRI February, 2004 Threat Analysis on NEMO Basic Operations draft-jung-nemo-threat-analysis-02 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes potential security threats to NEMO basic operations. The threats are mostly related to the integral use of IPsec and IP-in-IP tunnel between MR and HA. Threats related to the operations of nested MR, and multi-homing (multiple MRs) are also investigated. Finally,security requirements for NEMO basic protocols and specific implementation notes are described. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. S. Jung et. al. Expires August, 2004 [Page 1] Internet-Draft Threat Analysis on NEMO basic operations February 2004 Table of Contents 1. Motivations 2. Threats to MR-HA tunneling 2.1 Threats to the MR-HA IPsec Transport SA 2.2 Threats to IP-in-IP tunnel between MR and HA 3. Threats to error processing operations 3.1 DoS attack due to error processing of BU 4. Threats to interactions between MRs Changes from previous version References Authors' Addresses Intellectual Property and Copyright Statements S. Jung et. al. Expires August, 2004 [Page 2] Internet-Draft Threat Analysis on NEMO basic operations February 2004 1. Motivations Networks in motion (NEMO) introduces a network entity called Mobile Router(MR)[2]. MR has different features from Mobile Host that operates based on Mobile IP technologies[4]. Since MR functions both as a mobile node and a gateway to provide mobile network with Internet access to outside world, it needs specific treatment for managing operations and securities. The MobileIP/NEMO community has spent quite a lot of efforts in designing security mechanisms to protect critical control messages exchanged among protocol entities such as HA (Home Agent), MN (Mobile Node), or MR (Mobile Router in NEMO). In particular, the authenticity and integrity of the Binding Update (BU) messages must be protected very well. Otherwise, many malicious attacks such as traffic hijacking or denial of service are possible by intentionally injecting incorrect BU messages. Under both MobileIP and NEMO, IPsec Transport ESP (Encapsulating Security Payload) [8] is used to protect the binding update messages between HA and MN/MR. IPsec itself provides a network layer security service between two network entities, and it nicely integrates a number of strong cryptographic components under its architecture. Due to this strong fact of IPsec security, many Internet protocols, especially in the network layer, have been built on top of the security strength of IPsec. The list is currently growing, but at least, we can include OSPFv6, TRIP (Telephony Routing over IP, under the IP Telephony working group), RSVP/NSIS (Next Step in Signaling), L3VPN, PANA (Protocol for Authentication and Network Access), MobileIP and NEMO. While IPsec itself is indeed quite secure, the security of the protocols using IPsec might still be very questionable. In fact, through our security analysis toward NEMO, we realize that the IPsec architecture itself does NOT specify/mandate its relationship with other functional components (such as packet forwarding, ingress filtering, IP-in-IP tunnel, or application interface) in the same router. Therefore, as will be shown later, most of the IPsec implementers have not considered how to properly glue the IPsec engine with the rest of the system such that the whole system (such as the MR in NEMO) can be easily broken in. In short, IPsec by itself is indeed doing its job securely, but the component putting packets into the IPsec module might not. This draft describes vulnerabilities to the basic operations of NEMO (NEtworks in Motion), and discussed its potential security problems, especially, related to IPsec and other tunneling functions. Through our experiments (as well as our discussions with IPsec implementers from major router venders), we validated that the problems we raised here are practically possible. S. Jung et. al. Expires August, 2004 [Page 3] Internet-Draft Threat Analysis on NEMO basic operations February 2004 2 Potential threats to network in motion The major threats to the basic operations of mobile network are from the tunneling operations. Tunneled packet can disguise itself using fake source and destination addresses. The MR or HA should be responsible to verify the validity of those packets. Since the basic operation of mobile network is based on the IPsec tunnel and IP-in-IP tunnel between MR and HA, the threats to those tunneling operations will be investigated in this section. 2.1 Threats to the MR-HA IPsec Transport SA Three different potential attack scenarios are presented in this section. 2.1.1 BU spoofing: no ingress filtering at MR The first case assumes that there is no ingress filtering activated at MR. Figure 1 shows the attack scenario. MNN MR HA |--------| |----------------| |-----------| | | | |-------|| ESP | |-------| | |Attacker|---------->|-------| IPSec ||====================| | IPSec | | | | | | ^ |-------|| Transport | |-------| | |--------| | |-|--------------| | |-----------| | At this point, MR | checks the packet | cannot tell the fake | using ESP and |-----------| BU from a BU from |-----------| updates Binding |Src=HoA | itself, and applies |Src=CoA | Cache (corrupts |Dst=HA | IPSec ESP. |Dst=HA | binding cache) |... | |ESP | |BU(MNP,CoA)| |... | |-----------| |BU(MNP,CoA)| Attacker |-----------| generates Packet is a fake BU encapsulated with ESP Figure 1. MNN spoofs the BU of the MR without ingress filtering In the Figure 1, a malicious MNN generates a spoofed packet by setting source address to the HoA of the MR and destination address to the address of HA, and also includes the BU of MR as a payload. The format and contents of the BU message look exactly like a BU from the MR. When the MR received the packet from the attacker, it first saves the packet to the buffer, and checks the security policy database (SPD) of the packet. Since the MR cannot tell the fake packet from the packet from itself at this point, it finds that the packet requires the IPsec processing, and forwards it to the security interface for IPsec processing. Then the IPsec module encapsulates the packet using the ESP transport mode and the associated SA. When the HA received the packet, it verifies the packet by checking the IPsec ESP SA that will be valid because it is encapsulated by a valid MR. Finally, the HA is fooled to believe that the BU is from the MR, and updates the binding cache of itself. S. Jung et. al. Expires August, 2004 [Page 4] Internet-Draft Threat Analysis on NEMO basic operations February 2004 This attack is possible due to two reasons. The first one is that the MR is not using ingress filtering to check the topological correctness of the source address. If the MR checks the source address of the packet, and finds that the source address is set to itself, then it will drop the packet. Another reason is that the MR forgets where the packet came from, once it gets the packets and saves to a buffer. If the MR can distinct the packet stream generated by other nodes (Layer2) from those by itself (Layer4), then the fake packet will not be processed by IPsec, and will be forwarded to HA encapsulated in an IP-in-IP tunnel. Then the attack will fail to modify the binding cache of the HA. 2.1.2 BU spoofing: with ingress filtering at MR This attack scenario is similar to the first scenario, but assumes the ingress filtering at the MR. Figure 2 shows the attack scenario. MNN IP_in_IP MR HA |--------| packet is |----------------------------| |-----------| | | generated ||-------| |------| |-----|| ESP | |-------| | |Attacker|---------->||Ingress|-|tunnel|---|IPSec||===============| | IPSec | | | | | ||filter | |decap | ^ | || Transport | | | | | | | ||-------| |------| | |-----|| | | |-------| | |--------| | |-------------------|--------| | |-----------| | | | checks the |-------------| |-----------| |-----------| packet |Outer Src=MNN| |Src=HoA | |Src=CoA | using ESP |Outer Dst=MR | |Dst=HA | |Dst=HA | and updates |Src=HoA | |... | |ESP | binding |Dst=HA | |BU(MNP,CoA)| |... | cache |... | |-----------| |BU(MNP,CoA)| |BU(MNP,CoA) | At this point, MR cannot |-----------| |-------------| tell the fake BU from a BU Packet is Attacker generates from itself, and applies encapsulated a fake BU using IPSec ESP. with ESP IP-in-IP tunnel Figure 2. MNN spoofs a BU of MR with ingress filtering In this scenario, the attacker generates a spoofed BU message using IP-in-IP encapsulation as shown in the figure. Now, the outer source address is set to the address MNN and the destination address is set to the address of the MR. The inner source address is set to the HoA of MR and the inner destination address is set to the address of HA. This attack is possible due to the order of packet processing at the MR as shown in the figure. If the MR performs the ingress filtering at first, and then do the tunnel decapsulation, then the fake packet can get through the ingress filtering of the MR. The rest of the story is the same as the first scenario. If the MR do perform the ingress filtering after the tunnel decapsulation, the fake packet can be dropped at the MR in this scenario. Therefore, it is very important to implement multiple functions of the MR in the right order. In real world, the ingress filtering function of the routers are not activated in many cases, and then those routers are exposed to this type of attacks. S. Jung et. al. Expires August, 2004 [Page 5] Internet-Draft Threat Analysis on NEMO basic operations February 2004 2.2 Threats to IP-in-IP tunnel between MR and HA Processing IP-in-IP packets in a mobile router requires encapsulation and decapsulation module with a dedicated protocol number. Securing IP-in-IP tunneled packets requires a specific security mechanism like IPsec tunnel mode encapsulation. The attacks to the IP-in-IP tunnel can initiate from inside of the mobile network to MR or from outside directly to HA. We will investigate two attack scenarios using MR and HA as stepping stones. 2.2.1 Attack from inside Figure 3 shows an attack scenario from inside nodes. |--------| |--------| IP-in-IP |--------| |--------| | | | | tunnel | | | | | MNN |---------->| MR |==============| HA |-------->| Victim | | | | | | | | | | | | |--------| | |--------| | |--------| | |--------| inside | | | attacker | | |--------------| |--------------| |--------------| |Src=spoofed IP| |Ext. Src=MNN | |Ext. Src=CoA | |Dst=victim | |Ext. Dst=MR | |Ext. Dst=HA | |payload | |Src=spoofed IP| |Src=spoofed IP| |--------------| |Dst=victim | |Dst=victim | |payload | |payload | |--------------| |--------------| generates a spoofed IP packet Figure 3. Inside attack using MR and HA as stepping stone In the scenario, an attacker generates a fake IP-in-IP packet setting the external source address to the address of another MNN inside the mobile network and the external destination address to the address of MR. Inside the encapsulation, the internal source address is set to a spoofed IP address and the internal destination address is set to the address of victim machine. Once the MR receives the packets, the MR decapsulates the packets, and recognizes to process the packets using IP-in-IP encapsulation and forward to the HA. Therefore, the MR encapsulates the inside payload in IP-in-IP format (external source address = CoA of MR, external destination address = address of HA), and sends it to HA. HA forwards the packet to the victim machine. The possible attacks from this scenario are IP spoofing or DoS attack to the victim machine. Similar attacks have been known to mobile network communities for a while, but the main point here is that MR can prevent this attack by checking ingress filtering after the GRE decapsulation. S. Jung et. al. Expires August, 2004 [Page 6] Internet-Draft Threat Analysis on NEMO basic operations February 2004 2.2.2 Attack from outside In this scenario, similar attacks can be initiated from outside of a mobile network. Figure 4 shows the attack scenario. |--------| IP-in-IP |--------| |--------| | | tunnel | | | | | MR |==============| HA |--------------->| Victim | | | | | | | | |--------| |--------| | |--------| ^ | | |---------------| | |Src=spoofed IP | |---------------| | |Dst=victim | |Ext. Src=CoA | | |payload | |Ext. Dst=HA | | |---------------| |Src=spoofed IP |-------| |Dst=victim | | |payload | |---|outside |---------------| | |attacker generates a spoofed |---| IP-in-IP packet Figure 4. Outside attack using HA as a stepping stone In the Figure 4, an attacker from outside can generate a spoofed IP-in-IP packet with setting the external source address to the CoA of MR and the external destination address to the address of HA, which includes a spoofed IP address as the internal source address, and the address of the victim machine as the internal destination address. If the access router of the outside attacker activates ingress filtering, this packet can be dropped at the access router. But many routers without ingress filtering will pass through this packet, and then HA may forward the packet to the victim machine. Due to this security problem, most routers do not process the IP-in-IP packets, but MR and HA in mobile networks should process IP-in-IP packets for forwarding the packets from MNN or CN. S. Jung et. al. Expires August, 2004 [Page 7] Internet-Draft Threat Analysis on NEMO basic operations February 2004 3. Threats to error processing operations 3.1 DoS attack due to error processing of BU Section 5.4 of basic support draft[3], Error Processing of Binding Update, says that if the status is set to '142', the Mobile Router should send a similar Binding Update to another Home Agent on the same home link. If no Home Agent replies positively then Mobile Router SHOULD refrain from sending this Binding Updates to any Home Agent on the home link. Additionally, the Home Agent MUST stop advertising the respective prefix(es) in the mobile network with associated Router Advertisements, and modify its own forwarding information accordingly. Following this, the Mobile Router MAY send Binding Updates in another mode (e.g. implicit) to a Home Agent on the same home link.? If a malicious MR sends a BU on the explicit mode to its HA claiming a MNP belonging to another MR, the HA will notice the MNP is not valid, and send a BA with 142 code will be generated. According to the statement above, HA stops advertising this MNP, which will be a DoS attack to the MR that is already using the MNP. If the malicious MR keep sending other invalid MNPs to the HA, then those MNPs will be blocked for service. 4. Threats to interactions between MRs In case that two or more MR exists on a mobile subnet for multihoming, there may be multiple bi-directional paths to forward packet to a HA or multiple HAs respectively. If one of the tunnel paths is broken for any reason, the MR(MR1) associated with the faulty path loses Internet connection, and should find an alternative bi-directional tunnel path through another MR2. In this case, MR1 becomes a nested MR of MR2. NEMO basic draft[3] describes that MR SHOULD not respond to the unsolicited RA messages to its egress interface, but according to the MR operations by multihoming draft[6], the MR1 SHOULD listen the RA from alternative MR2 on its ingress interface. At this point, a malicious MR may advertise a RA with a fake CoA to MR1. Then the MR1 will get a wrong CoA information. This threat is not directly related to the NEMO basic operation, but to the inter-MR operations. There is no explicit security mechanism for inter-MR operations for multihoming cases, threats related to inter-MR operations should be considered. S. Jung et. al. Expires August, 2004 [Page 8] Internet-Draft Threat Analysis on NEMO basic operations February 2004 References [1] Ernst, T., et al, "Network Mobility Support Goals and Requirements", Internet Draft: draft-ietf-nemo-requirements-01.txt, Work In Progress, May 2003. [2] Ernst, T. and H. Lach, "Network Mobility Support Terminology", Internet Draft: draft-ietf-nemo-terminology-00.txt, Work In Progress, May 2003. [3] Devarapalli V., et al, "NEMO Basic Support Protocol", Internet Draft: draft-wakikawa-nemo-basic-02.txt, Work In Progress, December 2003. [4] Johnson, D. B., Perkins, C. E. and Arkko, J., "Mobility Support in IPv6", Internet Draft: draft-ietf-mobileip-ipv6-24.txt, Work In Progress, June 2003. [5] Petrescu, A., et al, "Issues in Designing Mobile IPv6 Network Mobility with the MR-HA Bidirectional Tunnel (MRHA)", Internet Draft: draft-petrescu-nemo-mrha-03.txt, Work In Progress, October 2003. [6] Ng, C. W. and Tanaka, T., "Multihoming Issues in Network Mobility Support", Internet Draft: draft-ng-nemo-multihoming-issues-02.txt, Work In Progress, October 2003. [7] Arkko, J. et. al. ,"Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents," Internet Draft: draft-ietf-mobileip-mipv6-ha-ipsec-06.txt, Work In Progress, June 2003. [8] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [9] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [10] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. Changes from the previous version 1. Removed the threat model and generic threat stuff. 2. Described threats specific to basic support protocol. 3. Described details of specific threats to MR-HA tunneling. 4. Added thretas due to error processing. 5. Added threats to multihoming S. Jung et. al. Expires August, 2004 [Page 9] Internet-Draft Threat Analysis on NEMO basic operations February 2004 Authors' Addresses Souhwan Jung Soongsil University 1-1, Sangdo-dong, Dongjak-ku Seoul 156-743 KOREA Phone: +82-2-820-0714 EMail: souhwanj@ssu.ac.kr Fan Zhao Department of Computer Science University of California, Davis One Shield Avenue Davis, CA 95616 USA Phone: +1-530-752-3128 EMail: fanzhao@ucdavis.edu Felix Wu Department of Computer Science University of California, Davis One Shield Avenue Davis, CA 95616 USA Phone: +1-530-754-7070 EMail: wu@cs.ucdavis.edu HyunGon Kim Network Security Department ETRI 161 Kajong-Dong, Yusong-Gu Taejon 305-600 KOREA Phone: +82-42-860-5428 Email: hyungon@etri.re.kr SungWon Sohn Network Security Department ETRI 161 Kajong-Dong, Yusong-Gu Taejon 305-600 KOREA Phone: +82-42-860-5072 Email: swsohn@etri.re.kr S. Jung et. al. Expires August, 2004 [Page 10] Internet-Draft Threat Analysis on NEMO basic operations February 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. S. Jung et. al. Expires August, 2004 [Page 11] Internet-Draft Threat Analysis on NEMO basic operations February 2004 --------------050109070406020809090808-- From nemo-admin@ietf.org Sun Feb 29 08:50:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22361 for ; Sun, 29 Feb 2004 08:50:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRKU-0004fT-Hx; Sun, 29 Feb 2004 08:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRJg-0004cH-U5 for nemo@optimus.ietf.org; Sun, 29 Feb 2004 08:49:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22246 for ; Sun, 29 Feb 2004 08:49:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxRJf-0004Vw-00 for nemo@ietf.org; Sun, 29 Feb 2004 08:49:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxRHu-0004Bk-00 for nemo@ietf.org; Sun, 29 Feb 2004 08:47:22 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AxRGk-0003fq-00 for nemo@ietf.org; Sun, 29 Feb 2004 08:46:10 -0500 Received: from [172.16.37.241] ([210.93.162.110]) by multihop.net (8.12.10/8.12.10) with ESMTP id i1TDkCr4012541 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 29 Feb 2004 05:46:15 -0800 (PST) (envelope-from tj@kniveton.com) In-Reply-To: <404190B7.50302@cs.ucdavis.edu> References: <1077784218.790.15.camel@acorde> <1077850151.5540.30.camel@localhost> <404190B7.50302@cs.ucdavis.edu> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-970749739; protocol="application/pkcs7-signature" Message-Id: <3AC88F2F-6ABD-11D8-AE19-000A95DA08F2@kniveton.com> Cc: "Fan Zhao" , IETF NEMO WG , Souhwan Jung From: "T.J. Kniveton" Subject: Re: [nemo] can an HA itself be an MNN under NEMO? Date: Sun, 29 Feb 2004 22:43:17 +0900 To: "S. Felix Wu" X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , --Apple-Mail-2-970749739 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I don't get why you would have a Parent HA advertising prefix X, and then a Mobile HA and MNN inside the top MR's prefix X... doesn't seem like a topologically correct arrangement of routers. The Mobile HA is under MR with prefix Y, so why is it advertising prefix X. Think about the fixed case, would you have this arrangement? Router | prefix X | | Router | prefix Y | | Router | prefix X | | Fixed node with prefix X it wouldn't make sense, right? It seems the scenario in the slide is just taking this case, and nesting it inside MRs. On Feb 29, 2004, at 4:11 PM, S. Felix Wu wrote: > > Hi, > > During our analysis of multi-homing and nested NEMO cases, we > have encountered a question, hopefully get some clarifications > from the NEMO working group: > > -- Can an HA itself be an MNN under the NEMO context? > > Please see our attached PDF file for our preliminary analysis on > this issue. It seems to us that this can be allowed for MIPv6, but > should NOT be allowed for NEMO (otherwise, we might have a loop, > and the multi-homing issue might be more complex). > > -Felix > -- > ---------------------------------------------------------------------- > Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu > Associate Professor http://www.cs.ucdavis.edu/~wu > Computer Science Department office: 1-530-754-7070 > University of California at Davis fax: 1-530-752-4767 > ---------------------------------------------------------------------- > --Apple-Mail-2-970749739 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDIyOTEzNDMx N1owIwYJKoZIhvcNAQkEMRYEFNDsTpKUZwUQUSyGJUf+LHORvd9jMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgG8YxLAp89g4Q7/E5F2937bvMhXpiD4ac5Y9MxFzY2m1 4l5rA1+V2vl9SbSMsBSx3u334CiOOC/WIvFeOVCtOqKnTPmz3GU8x4ECGWrGFbytN78T0+91+4Fy EpaGnWSssOjnmifnotnNe6CAqxYvavK64bDuP0+5Ae+0oryHMmdaAAAAAAAA --Apple-Mail-2-970749739-- From exim@www1.ietf.org Sun Feb 29 08:54:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22812 for ; Sun, 29 Feb 2004 08:53:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRNq-000543-NS for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 08:53:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TDrUtU019461 for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 08:53:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRNq-00053o-I2 for nemo-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 08:53:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22767 for ; Sun, 29 Feb 2004 08:53:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxRNp-0005L8-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 08:53:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxRMg-00055c-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 08:52:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxRKa-0004h9-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 08:50:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRKU-0004fT-Hx; Sun, 29 Feb 2004 08:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRJg-0004cH-U5 for nemo@optimus.ietf.org; Sun, 29 Feb 2004 08:49:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22246 for ; Sun, 29 Feb 2004 08:49:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxRJf-0004Vw-00 for nemo@ietf.org; Sun, 29 Feb 2004 08:49:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxRHu-0004Bk-00 for nemo@ietf.org; Sun, 29 Feb 2004 08:47:22 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AxRGk-0003fq-00 for nemo@ietf.org; Sun, 29 Feb 2004 08:46:10 -0500 Received: from [172.16.37.241] ([210.93.162.110]) by multihop.net (8.12.10/8.12.10) with ESMTP id i1TDkCr4012541 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 29 Feb 2004 05:46:15 -0800 (PST) (envelope-from tj@kniveton.com) In-Reply-To: <404190B7.50302@cs.ucdavis.edu> References: <1077784218.790.15.camel@acorde> <1077850151.5540.30.camel@localhost> <404190B7.50302@cs.ucdavis.edu> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-970749739; protocol="application/pkcs7-signature" Message-Id: <3AC88F2F-6ABD-11D8-AE19-000A95DA08F2@kniveton.com> Cc: "Fan Zhao" , IETF NEMO WG , Souhwan Jung From: "T.J. Kniveton" Subject: Re: [nemo] can an HA itself be an MNN under NEMO? Date: Sun, 29 Feb 2004 22:43:17 +0900 To: "S. Felix Wu" X-Mailer: Apple Mail (2.612) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --Apple-Mail-2-970749739 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I don't get why you would have a Parent HA advertising prefix X, and then a Mobile HA and MNN inside the top MR's prefix X... doesn't seem like a topologically correct arrangement of routers. The Mobile HA is under MR with prefix Y, so why is it advertising prefix X. Think about the fixed case, would you have this arrangement? Router | prefix X | | Router | prefix Y | | Router | prefix X | | Fixed node with prefix X it wouldn't make sense, right? It seems the scenario in the slide is just taking this case, and nesting it inside MRs. On Feb 29, 2004, at 4:11 PM, S. Felix Wu wrote: > > Hi, > > During our analysis of multi-homing and nested NEMO cases, we > have encountered a question, hopefully get some clarifications > from the NEMO working group: > > -- Can an HA itself be an MNN under the NEMO context? > > Please see our attached PDF file for our preliminary analysis on > this issue. It seems to us that this can be allowed for MIPv6, but > should NOT be allowed for NEMO (otherwise, we might have a loop, > and the multi-homing issue might be more complex). > > -Felix > -- > ---------------------------------------------------------------------- > Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu > Associate Professor http://www.cs.ucdavis.edu/~wu > Computer Science Department office: 1-530-754-7070 > University of California at Davis fax: 1-530-752-4767 > ---------------------------------------------------------------------- > --Apple-Mail-2-970749739 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDIyOTEzNDMx N1owIwYJKoZIhvcNAQkEMRYEFNDsTpKUZwUQUSyGJUf+LHORvd9jMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgG8YxLAp89g4Q7/E5F2937bvMhXpiD4ac5Y9MxFzY2m1 4l5rA1+V2vl9SbSMsBSx3u334CiOOC/WIvFeOVCtOqKnTPmz3GU8x4ECGWrGFbytN78T0+91+4Fy EpaGnWSssOjnmifnotnNe6CAqxYvavK64bDuP0+5Ae+0oryHMmdaAAAAAAAA --Apple-Mail-2-970749739-- From nemo-admin@ietf.org Sun Feb 29 08:56:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23040 for ; Sun, 29 Feb 2004 08:56:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRQJ-0005K3-Cy; Sun, 29 Feb 2004 08:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRPZ-0005HJ-Ps for nemo@optimus.ietf.org; Sun, 29 Feb 2004 08:55:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22979 for ; Sun, 29 Feb 2004 08:55:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxRPY-0005eL-00 for nemo@ietf.org; Sun, 29 Feb 2004 08:55:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxROg-0005Wa-00 for nemo@ietf.org; Sun, 29 Feb 2004 08:54:23 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1AxRNt-0005L9-00 for nemo@ietf.org; Sun, 29 Feb 2004 08:53:33 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i1TDrQha020924; Sun, 29 Feb 2004 05:53:27 -0800 (PST) Message-ID: <4041EED0.3050708@cs.ucdavis.edu> Date: Sun, 29 Feb 2004 05:53:20 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T.J. Kniveton" CC: Fan Zhao , IETF NEMO WG , Souhwan Jung Subject: Re: [nemo] can an HA itself be an MNN under NEMO? References: <1077784218.790.15.camel@acorde> <1077850151.5540.30.camel@localhost> <404190B7.50302@cs.ucdavis.edu> <3AC88F2F-6ABD-11D8-AE19-000A95DA08F2@kniveton.com> In-Reply-To: <3AC88F2F-6ABD-11D8-AE19-000A95DA08F2@kniveton.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 was really thinking about the MR for prefix Y moving into another network (prefix X) without knowing that one of its own MNN is actually the HA for that network. I agree that, for fixed topology/configuration, this doesn't make sense. But, I am not sure about the "moving" case (plus nested). -Felix T.J. Kniveton wrote: > I don't get why you would have a Parent HA advertising prefix X, and > then a Mobile HA and MNN inside the top MR's prefix X... doesn't seem > like a topologically correct arrangement of routers. The Mobile HA is > under MR with prefix Y, so why is it advertising prefix X. > > Think about the fixed case, would you have this arrangement? > > Router > | prefix X > | > | > Router > | prefix Y > | > | > Router > | prefix X > | > | > Fixed node with prefix X > > > it wouldn't make sense, right? It seems the scenario in the slide is > just taking this case, and nesting it inside MRs. > > > On Feb 29, 2004, at 4:11 PM, S. Felix Wu wrote: > >> >> Hi, >> >> During our analysis of multi-homing and nested NEMO cases, we >> have encountered a question, hopefully get some clarifications >> from the NEMO working group: >> >> -- Can an HA itself be an MNN under the NEMO context? >> >> Please see our attached PDF file for our preliminary analysis on >> this issue. It seems to us that this can be allowed for MIPv6, but >> should NOT be allowed for NEMO (otherwise, we might have a loop, >> and the multi-homing issue might be more complex). >> >> -Felix >> -- >> ---------------------------------------------------------------------- >> Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu >> Associate Professor http://www.cs.ucdavis.edu/~wu >> Computer Science Department office: 1-530-754-7070 >> University of California at Davis fax: 1-530-752-4767 >> ---------------------------------------------------------------------- >> -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From exim@www1.ietf.org Sun Feb 29 08:58:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23096 for ; Sun, 29 Feb 2004 08:58:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRSB-0005SQ-Eg for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 08:57:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TDvxT1020972 for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 08:57:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRSB-0005SB-A6 for nemo-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 08:57:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23093 for ; Sun, 29 Feb 2004 08:57:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxRS9-0005v0-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 08:57:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxRRB-0005qZ-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 08:56:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxRQJ-0005lJ-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 08:56:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRQJ-0005K3-Cy; Sun, 29 Feb 2004 08:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRPZ-0005HJ-Ps for nemo@optimus.ietf.org; Sun, 29 Feb 2004 08:55:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22979 for ; Sun, 29 Feb 2004 08:55:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxRPY-0005eL-00 for nemo@ietf.org; Sun, 29 Feb 2004 08:55:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxROg-0005Wa-00 for nemo@ietf.org; Sun, 29 Feb 2004 08:54:23 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1AxRNt-0005L9-00 for nemo@ietf.org; Sun, 29 Feb 2004 08:53:33 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i1TDrQha020924; Sun, 29 Feb 2004 05:53:27 -0800 (PST) Message-ID: <4041EED0.3050708@cs.ucdavis.edu> Date: Sun, 29 Feb 2004 05:53:20 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T.J. Kniveton" CC: Fan Zhao , IETF NEMO WG , Souhwan Jung Subject: Re: [nemo] can an HA itself be an MNN under NEMO? References: <1077784218.790.15.camel@acorde> <1077850151.5540.30.camel@localhost> <404190B7.50302@cs.ucdavis.edu> <3AC88F2F-6ABD-11D8-AE19-000A95DA08F2@kniveton.com> In-Reply-To: <3AC88F2F-6ABD-11D8-AE19-000A95DA08F2@kniveton.com> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I was really thinking about the MR for prefix Y moving into another network (prefix X) without knowing that one of its own MNN is actually the HA for that network. I agree that, for fixed topology/configuration, this doesn't make sense. But, I am not sure about the "moving" case (plus nested). -Felix T.J. Kniveton wrote: > I don't get why you would have a Parent HA advertising prefix X, and > then a Mobile HA and MNN inside the top MR's prefix X... doesn't seem > like a topologically correct arrangement of routers. The Mobile HA is > under MR with prefix Y, so why is it advertising prefix X. > > Think about the fixed case, would you have this arrangement? > > Router > | prefix X > | > | > Router > | prefix Y > | > | > Router > | prefix X > | > | > Fixed node with prefix X > > > it wouldn't make sense, right? It seems the scenario in the slide is > just taking this case, and nesting it inside MRs. > > > On Feb 29, 2004, at 4:11 PM, S. Felix Wu wrote: > >> >> Hi, >> >> During our analysis of multi-homing and nested NEMO cases, we >> have encountered a question, hopefully get some clarifications >> from the NEMO working group: >> >> -- Can an HA itself be an MNN under the NEMO context? >> >> Please see our attached PDF file for our preliminary analysis on >> this issue. It seems to us that this can be allowed for MIPv6, but >> should NOT be allowed for NEMO (otherwise, we might have a loop, >> and the multi-homing issue might be more complex). >> >> -Felix >> -- >> ---------------------------------------------------------------------- >> Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu >> Associate Professor http://www.cs.ucdavis.edu/~wu >> Computer Science Department office: 1-530-754-7070 >> University of California at Davis fax: 1-530-752-4767 >> ---------------------------------------------------------------------- >> -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From nemo-admin@ietf.org Sun Feb 29 09:05:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23376 for ; Sun, 29 Feb 2004 09:05:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRZ1-0005vG-BC; Sun, 29 Feb 2004 09:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRY5-0005tk-TJ for nemo@optimus.ietf.org; Sun, 29 Feb 2004 09:04:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23325 for ; Sun, 29 Feb 2004 09:04:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxRY4-0006Tz-00 for nemo@ietf.org; Sun, 29 Feb 2004 09:04:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxRX6-0006Os-00 for nemo@ietf.org; Sun, 29 Feb 2004 09:03:04 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AxRWD-00066T-00 for nemo@ietf.org; Sun, 29 Feb 2004 09:02:09 -0500 Received: from [172.16.37.241] ([210.93.162.110]) by multihop.net (8.12.10/8.12.10) with ESMTP id i1TE2Tr4012609 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 29 Feb 2004 06:02:33 -0800 (PST) (envelope-from tj@kniveton.com) In-Reply-To: <4041EED0.3050708@cs.ucdavis.edu> References: <1077784218.790.15.camel@acorde> <1077850151.5540.30.camel@localhost> <404190B7.50302@cs.ucdavis.edu> <3AC88F2F-6ABD-11D8-AE19-000A95DA08F2@kniveton.com> <4041EED0.3050708@cs.ucdavis.edu> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-971726831; protocol="application/pkcs7-signature" Message-Id: <812CE771-6ABF-11D8-AE19-000A95DA08F2@kniveton.com> Cc: IETF NEMO WG From: "T.J. Kniveton" Subject: Re: [nemo] can an HA itself be an MNN under NEMO? Date: Sun, 29 Feb 2004 22:59:34 +0900 To: "S. Felix Wu" X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , --Apple-Mail-3-971726831 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit I still don't get it.. Why would there be HAs on two different links supporting the same prefix?? In the fixed case, it's analogous to two routers on different links, advertising the same global prefix. On Feb 29, 2004, at 10:53 PM, S. Felix Wu wrote: > > I was really thinking about the MR for prefix Y moving into > another network (prefix X) without knowing that one of its own > MNN is actually the HA for that network. > > I agree that, for fixed topology/configuration, this doesn't > make sense. But, I am not sure about the "moving" case (plus > nested). > -Felix > > > T.J. Kniveton wrote: > >> I don't get why you would have a Parent HA advertising prefix X, and >> then a Mobile HA and MNN inside the top MR's prefix X... doesn't seem >> like a topologically correct arrangement of routers. The Mobile HA is >> under MR with prefix Y, so why is it advertising prefix X. >> Think about the fixed case, would you have this arrangement? >> Router >> | prefix X >> | >> | >> Router >> | prefix Y >> | >> | >> Router >> | prefix X >> | >> | >> Fixed node with prefix X >> it wouldn't make sense, right? It seems the scenario in the slide is >> just taking this case, and nesting it inside MRs. >> On Feb 29, 2004, at 4:11 PM, S. Felix Wu wrote: >>> >>> Hi, >>> >>> During our analysis of multi-homing and nested NEMO cases, we >>> have encountered a question, hopefully get some clarifications >>> from the NEMO working group: >>> >>> -- Can an HA itself be an MNN under the NEMO context? >>> >>> Please see our attached PDF file for our preliminary analysis on >>> this issue. It seems to us that this can be allowed for MIPv6, but >>> should NOT be allowed for NEMO (otherwise, we might have a loop, >>> and the multi-homing issue might be more complex). >>> >>> -Felix >>> -- >>> --------------------------------------------------------------------- >>> - >>> Dr. S. (Shyhtsun) Felix Wu >>> wu@cs.ucdavis.edu >>> Associate Professor >>> http://www.cs.ucdavis.edu/~wu >>> Computer Science Department office: >>> 1-530-754-7070 >>> University of California at Davis fax: >>> 1-530-752-4767 >>> --------------------------------------------------------------------- >>> - >>> > > -- > ---------------------------------------------------------------------- > Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu > Associate Professor http://www.cs.ucdavis.edu/~wu > Computer Science Department office: 1-530-754-7070 > University of California at Davis fax: 1-530-752-4767 > ---------------------------------------------------------------------- > --Apple-Mail-3-971726831 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDIyOTEzNTkz NVowIwYJKoZIhvcNAQkEMRYEFOs+g63de4rr9Zsfp0ghnF9txUbMMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgBURACj8Q16nAfhu/g1v4E30swSFXKT5TRkRchF4S30K ILeRhtPDeJApm/XIYqq+msC79Z+rx10zfN7f6QU8iIrKyGvcBnnWSydBt2Bxph6FFT9iMaxb44Vv 9kYGdEyrTVEdFF4nTtfU+biA24a7NRx5n8Mk+S3T8sKrBIjIMQv1AAAAAAAA --Apple-Mail-3-971726831-- From exim@www1.ietf.org Sun Feb 29 09:07:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23426 for ; Sun, 29 Feb 2004 09:07:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRaq-000634-HC for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 09:06:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TE6uiO023244 for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 09:06:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRaq-00062p-D2 for nemo-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 09:06:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23414 for ; Sun, 29 Feb 2004 09:06:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxRao-0006jT-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 09:06:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxRZt-0006eZ-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 09:05:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxRZ1-0006a2-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 09:05:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRZ1-0005vG-BC; Sun, 29 Feb 2004 09:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxRY5-0005tk-TJ for nemo@optimus.ietf.org; Sun, 29 Feb 2004 09:04:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23325 for ; Sun, 29 Feb 2004 09:04:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxRY4-0006Tz-00 for nemo@ietf.org; Sun, 29 Feb 2004 09:04:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxRX6-0006Os-00 for nemo@ietf.org; Sun, 29 Feb 2004 09:03:04 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AxRWD-00066T-00 for nemo@ietf.org; Sun, 29 Feb 2004 09:02:09 -0500 Received: from [172.16.37.241] ([210.93.162.110]) by multihop.net (8.12.10/8.12.10) with ESMTP id i1TE2Tr4012609 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 29 Feb 2004 06:02:33 -0800 (PST) (envelope-from tj@kniveton.com) In-Reply-To: <4041EED0.3050708@cs.ucdavis.edu> References: <1077784218.790.15.camel@acorde> <1077850151.5540.30.camel@localhost> <404190B7.50302@cs.ucdavis.edu> <3AC88F2F-6ABD-11D8-AE19-000A95DA08F2@kniveton.com> <4041EED0.3050708@cs.ucdavis.edu> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-971726831; protocol="application/pkcs7-signature" Message-Id: <812CE771-6ABF-11D8-AE19-000A95DA08F2@kniveton.com> Cc: IETF NEMO WG From: "T.J. Kniveton" Subject: Re: [nemo] can an HA itself be an MNN under NEMO? Date: Sun, 29 Feb 2004 22:59:34 +0900 To: "S. Felix Wu" X-Mailer: Apple Mail (2.612) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --Apple-Mail-3-971726831 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit I still don't get it.. Why would there be HAs on two different links supporting the same prefix?? In the fixed case, it's analogous to two routers on different links, advertising the same global prefix. On Feb 29, 2004, at 10:53 PM, S. Felix Wu wrote: > > I was really thinking about the MR for prefix Y moving into > another network (prefix X) without knowing that one of its own > MNN is actually the HA for that network. > > I agree that, for fixed topology/configuration, this doesn't > make sense. But, I am not sure about the "moving" case (plus > nested). > -Felix > > > T.J. Kniveton wrote: > >> I don't get why you would have a Parent HA advertising prefix X, and >> then a Mobile HA and MNN inside the top MR's prefix X... doesn't seem >> like a topologically correct arrangement of routers. The Mobile HA is >> under MR with prefix Y, so why is it advertising prefix X. >> Think about the fixed case, would you have this arrangement? >> Router >> | prefix X >> | >> | >> Router >> | prefix Y >> | >> | >> Router >> | prefix X >> | >> | >> Fixed node with prefix X >> it wouldn't make sense, right? It seems the scenario in the slide is >> just taking this case, and nesting it inside MRs. >> On Feb 29, 2004, at 4:11 PM, S. Felix Wu wrote: >>> >>> Hi, >>> >>> During our analysis of multi-homing and nested NEMO cases, we >>> have encountered a question, hopefully get some clarifications >>> from the NEMO working group: >>> >>> -- Can an HA itself be an MNN under the NEMO context? >>> >>> Please see our attached PDF file for our preliminary analysis on >>> this issue. It seems to us that this can be allowed for MIPv6, but >>> should NOT be allowed for NEMO (otherwise, we might have a loop, >>> and the multi-homing issue might be more complex). >>> >>> -Felix >>> -- >>> --------------------------------------------------------------------- >>> - >>> Dr. S. (Shyhtsun) Felix Wu >>> wu@cs.ucdavis.edu >>> Associate Professor >>> http://www.cs.ucdavis.edu/~wu >>> Computer Science Department office: >>> 1-530-754-7070 >>> University of California at Davis fax: >>> 1-530-752-4767 >>> --------------------------------------------------------------------- >>> - >>> > > -- > ---------------------------------------------------------------------- > Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu > Associate Professor http://www.cs.ucdavis.edu/~wu > Computer Science Department office: 1-530-754-7070 > University of California at Davis fax: 1-530-752-4767 > ---------------------------------------------------------------------- > --Apple-Mail-3-971726831 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDIyOTEzNTkz NVowIwYJKoZIhvcNAQkEMRYEFOs+g63de4rr9Zsfp0ghnF9txUbMMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgBURACj8Q16nAfhu/g1v4E30swSFXKT5TRkRchF4S30K ILeRhtPDeJApm/XIYqq+msC79Z+rx10zfN7f6QU8iIrKyGvcBnnWSydBt2Bxph6FFT9iMaxb44Vv 9kYGdEyrTVEdFF4nTtfU+biA24a7NRx5n8Mk+S3T8sKrBIjIMQv1AAAAAAAA --Apple-Mail-3-971726831-- From nemo-admin@ietf.org Sun Feb 29 18:13:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15325 for ; Sun, 29 Feb 2004 18:13:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axa7J-00032C-7e; Sun, 29 Feb 2004 18:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axa6Z-0002rT-8s for nemo@optimus.ietf.org; Sun, 29 Feb 2004 18:12:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15199 for ; Sun, 29 Feb 2004 18:12:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axa6W-00048x-00 for nemo@ietf.org; Sun, 29 Feb 2004 18:12:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axa5Z-00044a-00 for nemo@ietf.org; Sun, 29 Feb 2004 18:11:14 -0500 Received: from nictamailserv.unsw.edu.au ([129.94.183.70] helo=nicta-atp-imss.nicta.com) by ietf-mx with esmtp (Exim 4.12) id 1Axa4r-0003vX-00 for nemo@ietf.org; Sun, 29 Feb 2004 18:10:29 -0500 Received: from nicta-atp-imss.nicta.com (localhost [127.0.0.1]) by localhost.nicta.com (Postfix) with ESMTP id F24691341C0; Mon, 1 Mar 2004 09:10:14 +1100 (EST) Received: from ERA (unknown [129.94.151.135]) by nicta-atp-imss.nicta.com (Postfix) with ESMTP id DE52813419D; Mon, 1 Mar 2004 09:10:14 +1100 (EST) From: "Eranga Perera" To: "'Alexandru Petrescu'" Cc: Subject: RE: [nemo] Visiting Nodes Date: Mon, 1 Mar 2004 10:09:56 +1100 Message-ID: <003701c3ff19$254ca0b0$87975e81@ERA> 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.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <403DBC40.3090907@motorola.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Alex, Thanks for the reply. I wish I had a solution for the security issues but I don't. I was only trying to verify why we assume that all Visiting Nodes are mobility aware. I guess gnerally everyone seems to go by the assumption that a node with a "permanent IP address" that belongs to another network (not the prefix of the mobile network)is MIP or MIPv6 enabled. If visiting nodes are all MIP or MIPv6 enabled then I guess it is more or less a route optimization issue as you have suggested. Best Regards, Eranga -----Original Message----- From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] Sent: Thursday, February 26, 2004 8:29 PM To: Eranga Perera Cc: nemo@ietf.org Subject: Re: [nemo] Visiting Nodes Eranga Perera wrote: > Hi All, > Would someone be able to clarify why is it that all visiting nodes to > a mobile network are assumed to be mobile nodes? More precisely how > about the nodes that belong to another network (not mobile network) > but has no mobility capabilities? (scenario - commuter with a PDA with > no mobility capabilities obtain connectivity via a MR deployed on a > bus) If the node entering the train has no mobility capabilities (i.e. no Mobile IPv6 MN code) then it will loose all ongoing connections once it obtains a new address inside the train. This is not necessarily meaning that its new connections will not work, it is just that ongoing applications will have to be restarted; for some applications this is probably not even noticeable, for others it is bad enough. However, since in NEMO the Mobile IPv6 protocol is used, it is natural to assume that the VMN's do use Mobile IPv6, and it is also natural to look at the Mobile IPv6 problems that might (or might not occur) when that node enters a train. If a node not using Mobile IPv6 enters a train moving network, then problems related to DHCPv6, or other means of acquiring a new address (without caring about continuing ongoing applications), or routing, maybe could be treated in other places; this is to say that the moving network looks to the respective node as any other fixed network, no difference... Otherwise, what do you think are the problems of a non-Mobile IPv6 node jumping from a bus to a train? My oppinion, Alex From exim@www1.ietf.org Sun Feb 29 18:14:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15453 for ; Sun, 29 Feb 2004 18:14:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axa8U-0003PR-Rv for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 18:14:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TNEEou013099 for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 18:14:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axa8U-0003P8-Jz for nemo-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 18:14:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15410 for ; Sun, 29 Feb 2004 18:14:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axa8R-0004Ho-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 18:14:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axa7Y-0004Dy-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 18:13:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axa7K-00049f-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 18:13:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axa7J-00032C-7e; Sun, 29 Feb 2004 18:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axa6Z-0002rT-8s for nemo@optimus.ietf.org; Sun, 29 Feb 2004 18:12:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15199 for ; Sun, 29 Feb 2004 18:12:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axa6W-00048x-00 for nemo@ietf.org; Sun, 29 Feb 2004 18:12:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axa5Z-00044a-00 for nemo@ietf.org; Sun, 29 Feb 2004 18:11:14 -0500 Received: from nictamailserv.unsw.edu.au ([129.94.183.70] helo=nicta-atp-imss.nicta.com) by ietf-mx with esmtp (Exim 4.12) id 1Axa4r-0003vX-00 for nemo@ietf.org; Sun, 29 Feb 2004 18:10:29 -0500 Received: from nicta-atp-imss.nicta.com (localhost [127.0.0.1]) by localhost.nicta.com (Postfix) with ESMTP id F24691341C0; Mon, 1 Mar 2004 09:10:14 +1100 (EST) Received: from ERA (unknown [129.94.151.135]) by nicta-atp-imss.nicta.com (Postfix) with ESMTP id DE52813419D; Mon, 1 Mar 2004 09:10:14 +1100 (EST) From: "Eranga Perera" To: "'Alexandru Petrescu'" Cc: Subject: RE: [nemo] Visiting Nodes Date: Mon, 1 Mar 2004 10:09:56 +1100 Message-ID: <003701c3ff19$254ca0b0$87975e81@ERA> 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.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <403DBC40.3090907@motorola.com> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Alex, Thanks for the reply. I wish I had a solution for the security issues but I don't. I was only trying to verify why we assume that all Visiting Nodes are mobility aware. I guess gnerally everyone seems to go by the assumption that a node with a "permanent IP address" that belongs to another network (not the prefix of the mobile network)is MIP or MIPv6 enabled. If visiting nodes are all MIP or MIPv6 enabled then I guess it is more or less a route optimization issue as you have suggested. Best Regards, Eranga -----Original Message----- From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com] Sent: Thursday, February 26, 2004 8:29 PM To: Eranga Perera Cc: nemo@ietf.org Subject: Re: [nemo] Visiting Nodes Eranga Perera wrote: > Hi All, > Would someone be able to clarify why is it that all visiting nodes to > a mobile network are assumed to be mobile nodes? More precisely how > about the nodes that belong to another network (not mobile network) > but has no mobility capabilities? (scenario - commuter with a PDA with > no mobility capabilities obtain connectivity via a MR deployed on a > bus) If the node entering the train has no mobility capabilities (i.e. no Mobile IPv6 MN code) then it will loose all ongoing connections once it obtains a new address inside the train. This is not necessarily meaning that its new connections will not work, it is just that ongoing applications will have to be restarted; for some applications this is probably not even noticeable, for others it is bad enough. However, since in NEMO the Mobile IPv6 protocol is used, it is natural to assume that the VMN's do use Mobile IPv6, and it is also natural to look at the Mobile IPv6 problems that might (or might not occur) when that node enters a train. If a node not using Mobile IPv6 enters a train moving network, then problems related to DHCPv6, or other means of acquiring a new address (without caring about continuing ongoing applications), or routing, maybe could be treated in other places; this is to say that the moving network looks to the respective node as any other fixed network, no difference... Otherwise, what do you think are the problems of a non-Mobile IPv6 node jumping from a bus to a train? My oppinion, Alex From nemo-admin@ietf.org Sun Feb 29 18:18:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15821 for ; Sun, 29 Feb 2004 18:18:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxaC8-0004V8-Re; Sun, 29 Feb 2004 18:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxaBY-0004LH-AO for nemo@optimus.ietf.org; Sun, 29 Feb 2004 18:17:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15679 for ; Sun, 29 Feb 2004 18:17:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxaBV-0004Vx-00 for nemo@ietf.org; Sun, 29 Feb 2004 18:17:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxaAX-0004RO-00 for nemo@ietf.org; Sun, 29 Feb 2004 18:16:21 -0500 Received: from nictamailserv.unsw.edu.au ([129.94.183.70] helo=nicta-atp-imss.nicta.com) by ietf-mx with esmtp (Exim 4.12) id 1Axa9l-0004IY-00 for nemo@ietf.org; Sun, 29 Feb 2004 18:15:33 -0500 Received: from nicta-atp-imss.nicta.com (localhost [127.0.0.1]) by localhost.nicta.com (Postfix) with ESMTP id 762671341BB; Mon, 1 Mar 2004 09:15:20 +1100 (EST) Received: from ERA (unknown [129.94.151.135]) by nicta-atp-imss.nicta.com (Postfix) with ESMTP id 63D9A13419D; Mon, 1 Mar 2004 09:15:20 +1100 (EST) From: "Eranga Perera" To: "'Chan-Wah NG'" Cc: Subject: RE: [nemo] Visiting Nodes Date: Mon, 1 Mar 2004 10:15:01 +1100 Message-ID: <003801c3ff19$db659a00$87975e81@ERA> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <1077850151.5540.30.camel@localhost> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Chan-Wah, Basically you are saying that there won't be any node in a mobile network with a permanent IP address which belongs to another network and has no MIP or MIPv6 capabilities. Have I understood you correctly? Best Regrds, Eranga -----Original Message----- From: Chan-Wah NG [mailto:cwng@psl.com.sg]=20 Sent: Friday, February 27, 2004 1:49 PM To: Carlos Jes=FAs Bernardos Cano Cc: Eranga Perera; IETF NEMO WG Subject: Re: [nemo] Visiting Nodes Hello all, One way to look at it is to restrict our interpretation of the terms used in the layer we are working on (i.e. IP: layer 3). With that, then "visiting" would implies the concept of 'Home network" and "foreign network". Thus it implicitly carry the concept of mobility protocols (MIPv4, MIPv6). The term "Local" would then refer to a node that is in its home domain, which may or may not use/know mobility protocols. Also, the term "Mobile node" implies a node that uses mobility protocols (MIPv4, MIPv6). The term "fixed node" would then refer to a node that does not use mobility protocols (though it may accept BU, send BA, implements BCE, etc). So, we say a node is "visiting" when its in a foreign domain, and a node is "local" when its in the home domain. Thus there can be no such thing as a Visiting fixed node. =20 In the eyes of IP, the PDA example would be a LFN, though in the eyes of the user it is definitely mobile, and in the eyes of the mobile router owner, it is a visitor. Does this makes sense? /rgds /cwng On Thu, 2004-02-26 at 16:30, Carlos Jes=FAs Bernardos Cano wrote: > Hi Eranga, >=20 > All MNNs (Mobile Network Nodes) move with the mobile network, but not=20 > all of them are "mobile nodes" (i.e. have MIPv6 support and can move=20 > topologically with respect to the MR). Local Fixed Nodes (LFNs) are=20 > nodes that belong to the mobile network and which do not move with=20 > respect to the MR (like the node you pointed in your example). In the=20 > other hand, there are nodes with mobility capabilities: Visiting=20 > Mobile Nodes (VMNs) and Local Mobile Nodes (LMNs). Perhaps the term=20 > "visiting" is not very clear and could lead to confusion, but IMHO it=20 > does not mean that other nodes-with no mobility capabilities-could not > visit a mobile network (i.e. a node with portability-DHCPv6 support). >=20 > Best regards, >=20 > Carlos J. >=20 From exim@www1.ietf.org Sun Feb 29 18:19:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15870 for ; Sun, 29 Feb 2004 18:19:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxaDI-000586-Po for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 18:19:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TNJCJt019709 for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 18:19:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxaDI-00057i-K1 for nemo-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 18:19:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15858 for ; Sun, 29 Feb 2004 18:19:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxaDF-0004fm-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 18:19:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxaCP-0004bs-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 18:18:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxaC6-0004Xe-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 18:17:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxaC8-0004V8-Re; Sun, 29 Feb 2004 18:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxaBY-0004LH-AO for nemo@optimus.ietf.org; Sun, 29 Feb 2004 18:17:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15679 for ; Sun, 29 Feb 2004 18:17:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxaBV-0004Vx-00 for nemo@ietf.org; Sun, 29 Feb 2004 18:17:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxaAX-0004RO-00 for nemo@ietf.org; Sun, 29 Feb 2004 18:16:21 -0500 Received: from nictamailserv.unsw.edu.au ([129.94.183.70] helo=nicta-atp-imss.nicta.com) by ietf-mx with esmtp (Exim 4.12) id 1Axa9l-0004IY-00 for nemo@ietf.org; Sun, 29 Feb 2004 18:15:33 -0500 Received: from nicta-atp-imss.nicta.com (localhost [127.0.0.1]) by localhost.nicta.com (Postfix) with ESMTP id 762671341BB; Mon, 1 Mar 2004 09:15:20 +1100 (EST) Received: from ERA (unknown [129.94.151.135]) by nicta-atp-imss.nicta.com (Postfix) with ESMTP id 63D9A13419D; Mon, 1 Mar 2004 09:15:20 +1100 (EST) From: "Eranga Perera" To: "'Chan-Wah NG'" Cc: Subject: RE: [nemo] Visiting Nodes Date: Mon, 1 Mar 2004 10:15:01 +1100 Message-ID: <003801c3ff19$db659a00$87975e81@ERA> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <1077850151.5540.30.camel@localhost> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Chan-Wah, Basically you are saying that there won't be any node in a mobile network with a permanent IP address which belongs to another network and has no MIP or MIPv6 capabilities. Have I understood you correctly? Best Regrds, Eranga -----Original Message----- From: Chan-Wah NG [mailto:cwng@psl.com.sg]=20 Sent: Friday, February 27, 2004 1:49 PM To: Carlos Jes=FAs Bernardos Cano Cc: Eranga Perera; IETF NEMO WG Subject: Re: [nemo] Visiting Nodes Hello all, One way to look at it is to restrict our interpretation of the terms used in the layer we are working on (i.e. IP: layer 3). With that, then "visiting" would implies the concept of 'Home network" and "foreign network". Thus it implicitly carry the concept of mobility protocols (MIPv4, MIPv6). The term "Local" would then refer to a node that is in its home domain, which may or may not use/know mobility protocols. Also, the term "Mobile node" implies a node that uses mobility protocols (MIPv4, MIPv6). The term "fixed node" would then refer to a node that does not use mobility protocols (though it may accept BU, send BA, implements BCE, etc). So, we say a node is "visiting" when its in a foreign domain, and a node is "local" when its in the home domain. Thus there can be no such thing as a Visiting fixed node. =20 In the eyes of IP, the PDA example would be a LFN, though in the eyes of the user it is definitely mobile, and in the eyes of the mobile router owner, it is a visitor. Does this makes sense? /rgds /cwng On Thu, 2004-02-26 at 16:30, Carlos Jes=FAs Bernardos Cano wrote: > Hi Eranga, >=20 > All MNNs (Mobile Network Nodes) move with the mobile network, but not=20 > all of them are "mobile nodes" (i.e. have MIPv6 support and can move=20 > topologically with respect to the MR). Local Fixed Nodes (LFNs) are=20 > nodes that belong to the mobile network and which do not move with=20 > respect to the MR (like the node you pointed in your example). In the=20 > other hand, there are nodes with mobility capabilities: Visiting=20 > Mobile Nodes (VMNs) and Local Mobile Nodes (LMNs). Perhaps the term=20 > "visiting" is not very clear and could lead to confusion, but IMHO it=20 > does not mean that other nodes-with no mobility capabilities-could not > visit a mobile network (i.e. a node with portability-DHCPv6 support). >=20 > Best regards, >=20 > Carlos J. >=20 From nemo-admin@ietf.org Sun Feb 29 19:06:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17558 for ; Sun, 29 Feb 2004 19:06:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axawb-00081a-CF; Sun, 29 Feb 2004 19:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axavs-0007wI-Rf for nemo@optimus.ietf.org; Sun, 29 Feb 2004 19:05:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17513 for ; Sun, 29 Feb 2004 19:05:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axavp-0000ZN-00 for nemo@ietf.org; Sun, 29 Feb 2004 19:05:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axauw-0000Ux-00 for nemo@ietf.org; Sun, 29 Feb 2004 19:04:19 -0500 Received: from mac-0-5-4e-44-f-4d.dhcp.ietf59.or.kr ([218.37.230.142] helo=mozart.psl.com.sg) by ietf-mx with esmtp (Exim 4.12) id 1AxauH-0000Qd-00 for nemo@ietf.org; Sun, 29 Feb 2004 19:03:37 -0500 Received: from localhost.ietf59.or.kr (localhost [127.0.0.1]) by mozart.psl.com.sg (Postfix) with ESMTP id E286F7DD57; Mon, 1 Mar 2004 08:05:31 +0800 (SGT) Subject: RE: [nemo] Visiting Nodes From: Chan-Wah NG To: Eranga Perera Cc: IETF NEMO WG In-Reply-To: <003801c3ff19$db659a00$87975e81@ERA> References: <003801c3ff19$db659a00$87975e81@ERA> Content-Type: text/plain; charset=iso-8859-1 Organization: Panasonic Singapore Labs Message-Id: <1078099531.5652.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 01 Mar 2004 08:05:31 +0800 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 I would think so, else your permenant IP won't be topologically compatible with the foriegn network, and it disrupt the routing fabric.=20 You could of-course not use your permenant IP, but grab a temporrary IP address via DHCP or autoconfiguration. /rgds /cwng On Mon, 2004-03-01 at 07:15, Eranga Perera wrote: > Hi Chan-Wah, > Basically you are saying that there won't be any node in a mobile > network with a permanent IP address which belongs to another network an= d > has no MIP or MIPv6 capabilities. > Have I understood you correctly? >=20 > Best Regrds, > Eranga >=20 > -----Original Message----- > From: Chan-Wah NG [mailto:cwng@psl.com.sg]=20 > Sent: Friday, February 27, 2004 1:49 PM > To: Carlos Jes=FAs Bernardos Cano > Cc: Eranga Perera; IETF NEMO WG > Subject: Re: [nemo] Visiting Nodes >=20 >=20 > Hello all, >=20 > One way to look at it is to restrict our interpretation of the terms > used in the layer we are working on (i.e. IP: layer 3). >=20 > With that, then "visiting" would implies the concept of 'Home network" > and "foreign network". Thus it implicitly carry the concept of mobilit= y > protocols (MIPv4, MIPv6). The term "Local" would then refer to a node > that is in its home domain, which may or may not use/know mobility > protocols. >=20 > Also, the term "Mobile node" implies a node that uses mobility protocol= s > (MIPv4, MIPv6). The term "fixed node" would then refer to a node that > does not use mobility protocols (though it may accept BU, send BA, > implements BCE, etc). >=20 > So, we say a node is "visiting" when its in a foreign domain, and a nod= e > is "local" when its in the home domain. Thus there can be no such thin= g > as a Visiting fixed node. =20 >=20 > In the eyes of IP, the PDA example would be a LFN, though in the eyes o= f > the user it is definitely mobile, and in the eyes of the mobile router > owner, it is a visitor. >=20 > Does this makes sense? >=20 > /rgds > /cwng >=20 >=20 > On Thu, 2004-02-26 at 16:30, Carlos Jes=FAs Bernardos Cano wrote: > > Hi Eranga, > >=20 > > All MNNs (Mobile Network Nodes) move with the mobile network, > but not=20 > > all of them are "mobile nodes" (i.e. have MIPv6 support and can move=20 > > topologically with respect to the MR). Local Fixed Nodes (LFNs) are=20 > > nodes that belong to the mobile network and which do not move with=20 > > respect to the MR (like the node you pointed in your example). In the= =20 > > other hand, there are nodes with mobility capabilities: Visiting=20 > > Mobile Nodes (VMNs) and Local Mobile Nodes (LMNs). Perhaps the term=20 > > "visiting" is not very clear and could lead to confusion, but IMHO it= =20 > > does not mean that other nodes-with no mobility capabilities-could no= t >=20 > > visit a mobile network (i.e. a node with portability-DHCPv6 support). > >=20 > > Best regards, > >=20 > > Carlos J. > >=20 >=20 >=20 >=20 >=20 From exim@www1.ietf.org Sun Feb 29 19:07:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17640 for ; Sun, 29 Feb 2004 19:07:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axaxy-0008Ft-6s for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 19:07:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2107QmH031725 for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 19:07:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axaxx-0008FU-LD for nemo-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 19:07:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17637 for ; Sun, 29 Feb 2004 19:07:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axaxu-0000nQ-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 19:07:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axax2-0000iK-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 19:06:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axawa-0000cQ-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 19:06:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axawb-00081a-CF; Sun, 29 Feb 2004 19:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axavs-0007wI-Rf for nemo@optimus.ietf.org; Sun, 29 Feb 2004 19:05:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17513 for ; Sun, 29 Feb 2004 19:05:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axavp-0000ZN-00 for nemo@ietf.org; Sun, 29 Feb 2004 19:05:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axauw-0000Ux-00 for nemo@ietf.org; Sun, 29 Feb 2004 19:04:19 -0500 Received: from mac-0-5-4e-44-f-4d.dhcp.ietf59.or.kr ([218.37.230.142] helo=mozart.psl.com.sg) by ietf-mx with esmtp (Exim 4.12) id 1AxauH-0000Qd-00 for nemo@ietf.org; Sun, 29 Feb 2004 19:03:37 -0500 Received: from localhost.ietf59.or.kr (localhost [127.0.0.1]) by mozart.psl.com.sg (Postfix) with ESMTP id E286F7DD57; Mon, 1 Mar 2004 08:05:31 +0800 (SGT) Subject: RE: [nemo] Visiting Nodes From: Chan-Wah NG To: Eranga Perera Cc: IETF NEMO WG In-Reply-To: <003801c3ff19$db659a00$87975e81@ERA> References: <003801c3ff19$db659a00$87975e81@ERA> Content-Type: text/plain; charset=iso-8859-1 Organization: Panasonic Singapore Labs Message-Id: <1078099531.5652.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 01 Mar 2004 08:05:31 +0800 Content-Transfer-Encoding: quoted-printable 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I would think so, else your permenant IP won't be topologically compatible with the foriegn network, and it disrupt the routing fabric.=20 You could of-course not use your permenant IP, but grab a temporrary IP address via DHCP or autoconfiguration. /rgds /cwng On Mon, 2004-03-01 at 07:15, Eranga Perera wrote: > Hi Chan-Wah, > Basically you are saying that there won't be any node in a mobile > network with a permanent IP address which belongs to another network an= d > has no MIP or MIPv6 capabilities. > Have I understood you correctly? >=20 > Best Regrds, > Eranga >=20 > -----Original Message----- > From: Chan-Wah NG [mailto:cwng@psl.com.sg]=20 > Sent: Friday, February 27, 2004 1:49 PM > To: Carlos Jes=FAs Bernardos Cano > Cc: Eranga Perera; IETF NEMO WG > Subject: Re: [nemo] Visiting Nodes >=20 >=20 > Hello all, >=20 > One way to look at it is to restrict our interpretation of the terms > used in the layer we are working on (i.e. IP: layer 3). >=20 > With that, then "visiting" would implies the concept of 'Home network" > and "foreign network". Thus it implicitly carry the concept of mobilit= y > protocols (MIPv4, MIPv6). The term "Local" would then refer to a node > that is in its home domain, which may or may not use/know mobility > protocols. >=20 > Also, the term "Mobile node" implies a node that uses mobility protocol= s > (MIPv4, MIPv6). The term "fixed node" would then refer to a node that > does not use mobility protocols (though it may accept BU, send BA, > implements BCE, etc). >=20 > So, we say a node is "visiting" when its in a foreign domain, and a nod= e > is "local" when its in the home domain. Thus there can be no such thin= g > as a Visiting fixed node. =20 >=20 > In the eyes of IP, the PDA example would be a LFN, though in the eyes o= f > the user it is definitely mobile, and in the eyes of the mobile router > owner, it is a visitor. >=20 > Does this makes sense? >=20 > /rgds > /cwng >=20 >=20 > On Thu, 2004-02-26 at 16:30, Carlos Jes=FAs Bernardos Cano wrote: > > Hi Eranga, > >=20 > > All MNNs (Mobile Network Nodes) move with the mobile network, > but not=20 > > all of them are "mobile nodes" (i.e. have MIPv6 support and can move=20 > > topologically with respect to the MR). Local Fixed Nodes (LFNs) are=20 > > nodes that belong to the mobile network and which do not move with=20 > > respect to the MR (like the node you pointed in your example). In the= =20 > > other hand, there are nodes with mobility capabilities: Visiting=20 > > Mobile Nodes (VMNs) and Local Mobile Nodes (LMNs). Perhaps the term=20 > > "visiting" is not very clear and could lead to confusion, but IMHO it= =20 > > does not mean that other nodes-with no mobility capabilities-could no= t >=20 > > visit a mobile network (i.e. a node with portability-DHCPv6 support). > >=20 > > Best regards, > >=20 > > Carlos J. > >=20 >=20 >=20 >=20 >=20 From nemo-admin@ietf.org Sun Feb 29 19:46:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19198 for ; Sun, 29 Feb 2004 19:46:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbZK-0003JD-16; Sun, 29 Feb 2004 19:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbYj-0003HI-00 for nemo@optimus.ietf.org; Sun, 29 Feb 2004 19:45:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19180 for ; Sun, 29 Feb 2004 19:45:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxbYh-0004MC-00 for nemo@ietf.org; Sun, 29 Feb 2004 19:45:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxbXe-0004HE-00 for nemo@ietf.org; Sun, 29 Feb 2004 19:44:19 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AxbX4-0004BX-00 for nemo@ietf.org; Sun, 29 Feb 2004 19:43:42 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 29 Feb 2004 16:55:05 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i210hAuA018155; Sun, 29 Feb 2004 16:43:10 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-197.cisco.com [10.86.240.197]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGK26195; Sun, 29 Feb 2004 19:43:06 -0500 (EST) Message-Id: <4.3.2.7.2.20040229193606.021caa28@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 29 Feb 2004 19:43:01 -0500 To: Laurent Toutain From: Ralph Droms Subject: Re: [nemo] autoconfiguration with DHCPv6 Cc: pthubert@cisco.com, nemo@ietf.org In-Reply-To: <403A25C2.8060307@irisa.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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: , Laurent - thanks for the comments on draft-droms-nemo-dhcpv6-pd-01.txt and to the pointer to your draft. I just got a pointer to your e-mail earlier and haven't had time to review your draft before the nemo WG meeting today. draft-droms-nemo-dhcpv6-pd-01.txt addresses two problems: 1. delegate NEMO-prefix from home network to MR 2. delegate NEMO-prefix from visited network to MR If I understand your comment about multiple MRs on a visited link, I don't think there will be a problem. Each MR assigns the delegated NEMO-prefixes to its downstream links. The prefix on the visited link is assigned by the NEMO AR. - Ralph At 05:09 PM 2/23/2004 +0100, Laurent Toutain wrote: >I'm not familiar with the network mobility vocabulary, I'm little >confused but all NEMO acronyms (but I will learn >them I promise), but I was very interested by the >draft-droms-nemo-dhcpv6-pd-01.txt since it covers some >concerns we got in the late ZEROUTER BOF.It could be important to have >solution that works either when >the MN is in its home network and away and with any kind of >architecture, not only a single homed network. > >I will compare this draft to the proposal we published sevral month away >and that can be found at >http://internet.motlabs.com/zerouter/drafts/draft-chelius-router-autoconf-00.txt > >If I understand the draft is for asking the HA to assign a prefix to the >Mobile Network either when the MR is >at home or in a visiting network. I think this solution works well for a >Mobile Network with only one MR, but it >will be very difficult to generalize it to Home Networking >autoconfiguration (like DSLAC) for several reasons : > >- in a home network, you may have several routers on a same link. In >that case, all the routers will asks for a >prefix using DHCPv6 and you may have several prefixes for each link. > >- in a home network, at least during the boot phase, it is not >guaranteed that you have access to a DHCPv6 >server since prefixes allocation and routing are not establish (it is >not the case in NEMO, you assume a certain >stability in visited networks). > > >Laurent From exim@www1.ietf.org Sun Feb 29 19:47:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19254 for ; Sun, 29 Feb 2004 19:47:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axbad-0003Tn-1G for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 19:47:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i210lMw3013369 for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 19:47:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axbac-0003TY-Pe for nemo-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 19:47:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19251 for ; Sun, 29 Feb 2004 19:47:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axbab-0004Wa-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 19:47:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxbZb-0004Rf-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 19:46:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxbZL-0004Mp-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 19:46:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbZK-0003JD-16; Sun, 29 Feb 2004 19:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxbYj-0003HI-00 for nemo@optimus.ietf.org; Sun, 29 Feb 2004 19:45:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19180 for ; Sun, 29 Feb 2004 19:45:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxbYh-0004MC-00 for nemo@ietf.org; Sun, 29 Feb 2004 19:45:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxbXe-0004HE-00 for nemo@ietf.org; Sun, 29 Feb 2004 19:44:19 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AxbX4-0004BX-00 for nemo@ietf.org; Sun, 29 Feb 2004 19:43:42 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 29 Feb 2004 16:55:05 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i210hAuA018155; Sun, 29 Feb 2004 16:43:10 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-197.cisco.com [10.86.240.197]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGK26195; Sun, 29 Feb 2004 19:43:06 -0500 (EST) Message-Id: <4.3.2.7.2.20040229193606.021caa28@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 29 Feb 2004 19:43:01 -0500 To: Laurent Toutain From: Ralph Droms Subject: Re: [nemo] autoconfiguration with DHCPv6 Cc: pthubert@cisco.com, nemo@ietf.org In-Reply-To: <403A25C2.8060307@irisa.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Laurent - thanks for the comments on draft-droms-nemo-dhcpv6-pd-01.txt and to the pointer to your draft. I just got a pointer to your e-mail earlier and haven't had time to review your draft before the nemo WG meeting today. draft-droms-nemo-dhcpv6-pd-01.txt addresses two problems: 1. delegate NEMO-prefix from home network to MR 2. delegate NEMO-prefix from visited network to MR If I understand your comment about multiple MRs on a visited link, I don't think there will be a problem. Each MR assigns the delegated NEMO-prefixes to its downstream links. The prefix on the visited link is assigned by the NEMO AR. - Ralph At 05:09 PM 2/23/2004 +0100, Laurent Toutain wrote: >I'm not familiar with the network mobility vocabulary, I'm little >confused but all NEMO acronyms (but I will learn >them I promise), but I was very interested by the >draft-droms-nemo-dhcpv6-pd-01.txt since it covers some >concerns we got in the late ZEROUTER BOF.It could be important to have >solution that works either when >the MN is in its home network and away and with any kind of >architecture, not only a single homed network. > >I will compare this draft to the proposal we published sevral month away >and that can be found at >http://internet.motlabs.com/zerouter/drafts/draft-chelius-router-autoconf-00.txt > >If I understand the draft is for asking the HA to assign a prefix to the >Mobile Network either when the MR is >at home or in a visiting network. I think this solution works well for a >Mobile Network with only one MR, but it >will be very difficult to generalize it to Home Networking >autoconfiguration (like DSLAC) for several reasons : > >- in a home network, you may have several routers on a same link. In >that case, all the routers will asks for a >prefix using DHCPv6 and you may have several prefixes for each link. > >- in a home network, at least during the boot phase, it is not >guaranteed that you have access to a DHCPv6 >server since prefixes allocation and routing are not establish (it is >not the case in NEMO, you assume a certain >stability in visited networks). > > >Laurent From nemo-admin@ietf.org Sun Feb 29 20:30:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20760 for ; Sun, 29 Feb 2004 20:30:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcFt-00079E-19; Sun, 29 Feb 2004 20:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcF9-00077B-OW for nemo@optimus.ietf.org; Sun, 29 Feb 2004 20:29:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20636 for ; Sun, 29 Feb 2004 20:29:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxcF7-0000Hk-00 for nemo@ietf.org; Sun, 29 Feb 2004 20:29:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxcEC-0000Ce-00 for nemo@ietf.org; Sun, 29 Feb 2004 20:28:17 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AxcDI-0007li-00 for nemo@ietf.org; Sun, 29 Feb 2004 20:27:20 -0500 Received: from [218.37.231.188] (wideload.dhcp.ietf59.or.kr [218.37.231.188]) by multihop.net (8.12.10/8.12.10) with ESMTP id i211SUr4014679 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sun, 29 Feb 2004 17:28:47 -0800 (PST) (envelope-from tj@kniveton.com) Mime-Version: 1.0 (Apple Message framework v612) To: IETF NEMO WG Message-Id: <52CEF8BE-6B1F-11D8-985D-000A95DA08F2@kniveton.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-1012880726; protocol="application/pkcs7-signature" From: "T.J. Kniveton" Date: Mon, 1 Mar 2004 10:25:28 +0900 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [nemo] Link for slides 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: , --Apple-Mail-1-1012880726 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit For anyone following along on your laptop, the link for slides is: http://www.mobilenetworks.org/nemo/ietf59/slides Keep in mind the files there could change until the final versions are announced on this list. TJ --Apple-Mail-1-1012880726 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMwMTAxMjUy OFowIwYJKoZIhvcNAQkEMRYEFNtygaum+SirwMyO5Y1e7abShxtXMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgJ7b9BjVl9FkbHStq7SQBtFE/9h+xUISarmiTlWuMG29 n9UdLDLTfpzJ2VuSuzBEewf2FhMU3XAuEep7D0ldBwxBqA00cuu5UXm4Qhjp8veUanHwLBwf9ROW ch4mMITCog6CjK++Gjhhxr2TO0+Qek1f1PS+onKVPOiA52C5jNR+AAAAAAAA --Apple-Mail-1-1012880726-- From exim@www1.ietf.org Sun Feb 29 20:32:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20861 for ; Sun, 29 Feb 2004 20:32:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcHY-0007KS-Ox for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 20:31:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i211ViGP028166 for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 20:31:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcHY-0007KD-Jb for nemo-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 20:31:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20834 for ; Sun, 29 Feb 2004 20:31:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxcHW-0000Ye-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 20:31:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxcGR-0000Rv-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 20:30:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxcFu-0000Kv-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 20:30:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcFt-00079E-19; Sun, 29 Feb 2004 20:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcF9-00077B-OW for nemo@optimus.ietf.org; Sun, 29 Feb 2004 20:29:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20636 for ; Sun, 29 Feb 2004 20:29:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxcF7-0000Hk-00 for nemo@ietf.org; Sun, 29 Feb 2004 20:29:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxcEC-0000Ce-00 for nemo@ietf.org; Sun, 29 Feb 2004 20:28:17 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AxcDI-0007li-00 for nemo@ietf.org; Sun, 29 Feb 2004 20:27:20 -0500 Received: from [218.37.231.188] (wideload.dhcp.ietf59.or.kr [218.37.231.188]) by multihop.net (8.12.10/8.12.10) with ESMTP id i211SUr4014679 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sun, 29 Feb 2004 17:28:47 -0800 (PST) (envelope-from tj@kniveton.com) Mime-Version: 1.0 (Apple Message framework v612) To: IETF NEMO WG Message-Id: <52CEF8BE-6B1F-11D8-985D-000A95DA08F2@kniveton.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-1012880726; protocol="application/pkcs7-signature" From: "T.J. Kniveton" Date: Mon, 1 Mar 2004 10:25:28 +0900 X-Mailer: Apple Mail (2.612) Subject: [nemo] Link for slides 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --Apple-Mail-1-1012880726 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit For anyone following along on your laptop, the link for slides is: http://www.mobilenetworks.org/nemo/ietf59/slides Keep in mind the files there could change until the final versions are announced on this list. TJ --Apple-Mail-1-1012880726 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMwMTAxMjUy OFowIwYJKoZIhvcNAQkEMRYEFNtygaum+SirwMyO5Y1e7abShxtXMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgJ7b9BjVl9FkbHStq7SQBtFE/9h+xUISarmiTlWuMG29 n9UdLDLTfpzJ2VuSuzBEewf2FhMU3XAuEep7D0ldBwxBqA00cuu5UXm4Qhjp8veUanHwLBwf9ROW ch4mMITCog6CjK++Gjhhxr2TO0+Qek1f1PS+onKVPOiA52C5jNR+AAAAAAAA --Apple-Mail-1-1012880726-- From nemo-admin@ietf.org Sun Feb 29 20:38:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21396 for ; Sun, 29 Feb 2004 20:38:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcNd-00080p-RX; Sun, 29 Feb 2004 20:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcN1-0007s7-Or for nemo@optimus.ietf.org; Sun, 29 Feb 2004 20:37:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21282 for ; Sun, 29 Feb 2004 20:37:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxcMz-0001Gf-00 for nemo@ietf.org; Sun, 29 Feb 2004 20:37:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxcMA-00019m-00 for nemo@ietf.org; Sun, 29 Feb 2004 20:36:30 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AxcLF-0000i9-00 for nemo@ietf.org; Sun, 29 Feb 2004 20:35:33 -0500 Received: from [218.37.231.188] (wideload.dhcp.ietf59.or.kr [218.37.231.188]) by multihop.net (8.12.10/8.12.10) with ESMTP id i211ZZr4014710 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sun, 29 Feb 2004 17:35:45 -0800 (PST) (envelope-from tj@kniveton.com) Mime-Version: 1.0 (Apple Message framework v612) To: IETF NEMO WG Message-Id: <53168FEB-6B20-11D8-985D-000A95DA08F2@kniveton.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-1013310692; protocol="application/pkcs7-signature" From: "T.J. Kniveton" Date: Mon, 1 Mar 2004 10:32:38 +0900 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [nemo] Fwd: NEMO charter update 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: , --Apple-Mail-2-1013310692 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Here is the updated Charter and Milestone list. It has been approved but not yet posted on the web site. Per the discussion today, submitting a multihoming problem statement draft is on the milstones list. TJ Begin forwarded message: > From: Thierry Ernst > Date: February 20, 2004 12:23:46 PM GMT+09:00 > Subject: NEMO charter update > > Changes are: > - new deadlines and re-ordering > - cosmetic changes in the description of some milestones (so that it > becomes more precice). > - new milestones > > Numbers are used to match the changes to a particular milestone: > - 1-6: existing milestones > - 7- : new milestones > > Here are the former milestones as currently shown on the web: > 1. Mar 03 Submit terminology and requirements documents (for Basic > support). > 2. May 03 Submit Threat analysis and security requirements for > NEMO. > 3. Aug 03 Submit solution for basic support to IESG. > 4. Nov 03 Submit MIB for Basic support to the IESG. > 5. Mar 04 Submit the analysis of the solution space for route > optimization. > 6. Jun 04 Shut down or recharter the WG to solve the route > optimization. > > > Please update the milestones as shown below: > 1. DONE Submit WG draft -00 on Terminology and Requirements (for > Basic Support) > 3. DONE Submit NEMO Basic Support to IESG > 2. Mar 04 Submit WG draft -00 on Threat Analysis and Security > Requirements for NEMO. > 7. Mar 04 Submit WG draft -00 on Multihoming Problem Statement > 8. Mar 04 Submit WG draft -00 on NEMO Basic Support Usages > 9. Apr 04 Submit Terminology as Informational to IETG > 10 Apr 04 Submit Goals and Requirements as Informational to IESG > 11 Apr 04 Submit WG draft -00 on Prefix Delegation for NEMO > 4. May 04 Submit WG draft -00 on MIB for NEMO Basic Support > 5. Jun 04 Submit WG draft -00 on Analysis of the Solution Space for > Route Optimization > 6. Aug 04 Shut down or recharter the WG to solve route optimization --Apple-Mail-2-1013310692 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMwMTAxMzIz OFowIwYJKoZIhvcNAQkEMRYEFFJVu2bPbJ/xAF1Qlia+PcFcQDVUMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgGQgH+7VgwjqHuiFY889CTZROK6luBSX2PmlRzNH99Ex 9pDFNWxf73dCac6f19Q/qk1GJcH6xNLHWir4xn5/K8EfdI+cctsJCBUYIlWHe3BW/pnOs7Xjja1j BRiMwNHhoNsn2ccX25YjPD0y0rVzjK6v8UCyElzFB0L8nLRw7VJyAAAAAAAA --Apple-Mail-2-1013310692-- From exim@www1.ietf.org Sun Feb 29 20:39:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21494 for ; Sun, 29 Feb 2004 20:39:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcP2-0008Nq-3Y for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 20:39:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i211dS7T032220 for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 20:39:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcP1-0008Na-Vn for nemo-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 20:39:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21463 for ; Sun, 29 Feb 2004 20:39:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxcOz-0001WG-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 20:39:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxcOD-0001QK-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 20:38:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxcNd-0001Jb-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 20:38:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcNd-00080p-RX; Sun, 29 Feb 2004 20:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcN1-0007s7-Or for nemo@optimus.ietf.org; Sun, 29 Feb 2004 20:37:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21282 for ; Sun, 29 Feb 2004 20:37:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxcMz-0001Gf-00 for nemo@ietf.org; Sun, 29 Feb 2004 20:37:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxcMA-00019m-00 for nemo@ietf.org; Sun, 29 Feb 2004 20:36:30 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AxcLF-0000i9-00 for nemo@ietf.org; Sun, 29 Feb 2004 20:35:33 -0500 Received: from [218.37.231.188] (wideload.dhcp.ietf59.or.kr [218.37.231.188]) by multihop.net (8.12.10/8.12.10) with ESMTP id i211ZZr4014710 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sun, 29 Feb 2004 17:35:45 -0800 (PST) (envelope-from tj@kniveton.com) Mime-Version: 1.0 (Apple Message framework v612) To: IETF NEMO WG Message-Id: <53168FEB-6B20-11D8-985D-000A95DA08F2@kniveton.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-1013310692; protocol="application/pkcs7-signature" From: "T.J. Kniveton" Date: Mon, 1 Mar 2004 10:32:38 +0900 X-Mailer: Apple Mail (2.612) Subject: [nemo] Fwd: NEMO charter update 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --Apple-Mail-2-1013310692 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Here is the updated Charter and Milestone list. It has been approved but not yet posted on the web site. Per the discussion today, submitting a multihoming problem statement draft is on the milstones list. TJ Begin forwarded message: > From: Thierry Ernst > Date: February 20, 2004 12:23:46 PM GMT+09:00 > Subject: NEMO charter update > > Changes are: > - new deadlines and re-ordering > - cosmetic changes in the description of some milestones (so that it > becomes more precice). > - new milestones > > Numbers are used to match the changes to a particular milestone: > - 1-6: existing milestones > - 7- : new milestones > > Here are the former milestones as currently shown on the web: > 1. Mar 03 Submit terminology and requirements documents (for Basic > support). > 2. May 03 Submit Threat analysis and security requirements for > NEMO. > 3. Aug 03 Submit solution for basic support to IESG. > 4. Nov 03 Submit MIB for Basic support to the IESG. > 5. Mar 04 Submit the analysis of the solution space for route > optimization. > 6. Jun 04 Shut down or recharter the WG to solve the route > optimization. > > > Please update the milestones as shown below: > 1. DONE Submit WG draft -00 on Terminology and Requirements (for > Basic Support) > 3. DONE Submit NEMO Basic Support to IESG > 2. Mar 04 Submit WG draft -00 on Threat Analysis and Security > Requirements for NEMO. > 7. Mar 04 Submit WG draft -00 on Multihoming Problem Statement > 8. Mar 04 Submit WG draft -00 on NEMO Basic Support Usages > 9. Apr 04 Submit Terminology as Informational to IETG > 10 Apr 04 Submit Goals and Requirements as Informational to IESG > 11 Apr 04 Submit WG draft -00 on Prefix Delegation for NEMO > 4. May 04 Submit WG draft -00 on MIB for NEMO Basic Support > 5. Jun 04 Submit WG draft -00 on Analysis of the Solution Space for > Route Optimization > 6. Aug 04 Shut down or recharter the WG to solve route optimization --Apple-Mail-2-1013310692 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMwMTAxMzIz OFowIwYJKoZIhvcNAQkEMRYEFFJVu2bPbJ/xAF1Qlia+PcFcQDVUMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgGQgH+7VgwjqHuiFY889CTZROK6luBSX2PmlRzNH99Ex 9pDFNWxf73dCac6f19Q/qk1GJcH6xNLHWir4xn5/K8EfdI+cctsJCBUYIlWHe3BW/pnOs7Xjja1j BRiMwNHhoNsn2ccX25YjPD0y0rVzjK6v8UCyElzFB0L8nLRw7VJyAAAAAAAA --Apple-Mail-2-1013310692-- From nemo-admin@ietf.org Sun Feb 29 22:14:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27844 for ; Sun, 29 Feb 2004 22:14:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxdsX-0000mo-Ch; Sun, 29 Feb 2004 22:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxdNl-00073g-Fq for nemo@optimus.ietf.org; Sun, 29 Feb 2004 21:42:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25923 for ; Sun, 29 Feb 2004 21:42:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxdNi-0001fj-00 for nemo@ietf.org; Sun, 29 Feb 2004 21:42:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxdMd-0001U1-00 for nemo@ietf.org; Sun, 29 Feb 2004 21:41:03 -0500 Received: from yue.hongo.wide.ad.jp ([203.178.135.30]) by ietf-mx with esmtp (Exim 4.12) id 1AxdLo-0001JS-00 for nemo@ietf.org; Sun, 29 Feb 2004 21:40:12 -0500 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 0BD0133CA5 for ; Mon, 1 Mar 2004 11:41:31 +0900 (JST) Date: Mon, 01 Mar 2004 11:41:30 +0900 (JST) Message-Id: <20040301.114130.90421801.yoshfuji@wide.ad.jp> To: nemo@ietf.org From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [nemo] draft-cho-nemo-hmra-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 Hello. About draft-cho-nemo-hmra-00.txt: Cited from secion 4.1 Router Advertisement Message Format ---- Figure 2 shows the RA message format with age field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O| Age |Rsvd | Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- ---- The "age" is conflicts with the the Home Agent (H) flag (in ) and with the Default Router Preference (prf) flag (in ). The flags is extremely expensive resource and it is actually running out. Allocating another "RA option" is better. Thanks. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From exim@www1.ietf.org Sun Feb 29 22:15:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27952 for ; Sun, 29 Feb 2004 22:15:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axdts-0000xB-Va for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 22:15:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i213FOiC003661 for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 22:15:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axdts-0000wy-RY for nemo-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 22:15:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27949 for ; Sun, 29 Feb 2004 22:15:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axdtp-0005Ft-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 22:15:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxdtC-0005BV-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 22:14:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxdsW-00054E-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 22:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxdsX-0000mo-Ch; Sun, 29 Feb 2004 22:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxdNl-00073g-Fq for nemo@optimus.ietf.org; Sun, 29 Feb 2004 21:42:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25923 for ; Sun, 29 Feb 2004 21:42:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxdNi-0001fj-00 for nemo@ietf.org; Sun, 29 Feb 2004 21:42:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxdMd-0001U1-00 for nemo@ietf.org; Sun, 29 Feb 2004 21:41:03 -0500 Received: from yue.hongo.wide.ad.jp ([203.178.135.30]) by ietf-mx with esmtp (Exim 4.12) id 1AxdLo-0001JS-00 for nemo@ietf.org; Sun, 29 Feb 2004 21:40:12 -0500 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 0BD0133CA5 for ; Mon, 1 Mar 2004 11:41:31 +0900 (JST) Date: Mon, 01 Mar 2004 11:41:30 +0900 (JST) Message-Id: <20040301.114130.90421801.yoshfuji@wide.ad.jp> To: nemo@ietf.org From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] draft-cho-nemo-hmra-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello. About draft-cho-nemo-hmra-00.txt: Cited from secion 4.1 Router Advertisement Message Format ---- Figure 2 shows the RA message format with age field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O| Age |Rsvd | Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- ---- The "age" is conflicts with the the Home Agent (H) flag (in ) and with the Default Router Preference (prf) flag (in ). The flags is extremely expensive resource and it is actually running out. Allocating another "RA option" is better. Thanks. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From nemo-admin@ietf.org Sun Feb 29 23:02:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29395 for ; Sun, 29 Feb 2004 23:02:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxedA-0004BP-9b; Sun, 29 Feb 2004 23:02:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxecO-00048z-Uu for nemo@optimus.ietf.org; Sun, 29 Feb 2004 23:01:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29371 for ; Sun, 29 Feb 2004 23:01:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxecL-0001MN-00 for nemo@ietf.org; Sun, 29 Feb 2004 23:01:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxebQ-0001HO-00 for nemo@ietf.org; Sun, 29 Feb 2004 23:00:25 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1Axeaq-0001CR-00 for nemo@ietf.org; Sun, 29 Feb 2004 22:59:48 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i213xcha024459 for ; Sun, 29 Feb 2004 19:59:39 -0800 (PST) Message-ID: <4042B535.5010003@cs.ucdavis.edu> Date: Sun, 29 Feb 2004 19:59:49 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF NEMO WG Subject: [nemo] a special discussion session for threat analysis and security requirements X-Priority: 2 (high) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 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, It seems to me that we have many folks are interested in working on security/threat related issues under NEMO, while, as TJ concluded today, we still need a good external review for security issues. In order for us to work together more effectively as a team and to consolidate different efforts, I proposed to TJ that maybe we should have a special meeting this week in Seoul to discuss about security issue. This special discussion will be open to any one who is interested in the security issue under NEMO. I propose two options for the meeting time: (1). 11-12 on Wed morning (2). 11-12 on Thu morning For those of you who are indeed interested in joining us, please let me know in emails whether any one of the propsed time is good for you. And, then, after I collect all the inputs, I will announce tomorrow around 4:00 p.m. to the NEMO mailing list. Draft Agenda: (1). Introduce ourselves (2). status of all current drafts (3). what should we really achieve regarding the security issue in NEMO? (4). "how to achieve that goal" and hopefully some action items before the next IETF. Thanks. Any comments will be welcome. -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From nemo-admin@ietf.org Sun Feb 29 23:44:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01651 for ; Sun, 29 Feb 2004 23:44:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfGf-0000NG-BT; Sun, 29 Feb 2004 23:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfG2-0000Hk-7n for nemo@optimus.ietf.org; Sun, 29 Feb 2004 23:42:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01513 for ; Sun, 29 Feb 2004 23:42:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxfG0-0005La-00 for nemo@ietf.org; Sun, 29 Feb 2004 23:42:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxfF2-0005EY-00 for nemo@ietf.org; Sun, 29 Feb 2004 23:41:20 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AxfE4-0004sq-00 for nemo@ietf.org; Sun, 29 Feb 2004 23:40:20 -0500 Received: from [218.37.231.188] (wideload.dhcp.ietf59.or.kr [218.37.231.188]) by multihop.net (8.12.10/8.12.10) with ESMTP id i214ekr4015398 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sun, 29 Feb 2004 20:40:48 -0800 (PST) (envelope-from tj@kniveton.com) Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <4042B535.5010003@cs.ucdavis.edu> References: <4042B535.5010003@cs.ucdavis.edu> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-12-1024422654; protocol="application/pkcs7-signature" Message-Id: <32555209-6B3A-11D8-985D-000A95DA08F2@kniveton.com> From: "T.J. Kniveton" Subject: Re: [nemo] a special discussion session for threat analysis and security requirements Date: Mon, 1 Mar 2004 13:37:50 +0900 To: IETF NEMO WG X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , --Apple-Mail-12-1024422654 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Mar 1, 2004, at 12:59 PM, S. Felix Wu wrote: > > It seems to me that we have many folks are interested in working on > security/threat related issues under NEMO, while, as TJ concluded > today, we still need a good external review for security issues. Maybe I didn't state it understandably at the meeting. The draft has definitely undergone an extensive security analysis and review during and after creation. I was saying that I would like to see some experts from the security Area make commentary and analysis about the draft. We have requested this a while back, but it didn't happen. I'm not trying to imply that the NEMO basic solution is deficient; as I said in the meeting, I would like a positive affirmation of the security analysis by those whose primary interest is security. TJ --Apple-Mail-12-1024422654 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMwMTA0Mzc1 MFowIwYJKoZIhvcNAQkEMRYEFEAe4+1sDmlIDOM+7yJhihB9uezcMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgDCNhN5IjCrxBOaUWE4MnjsoOqif2miZI7V9ZyO6BQCS FYAI0QWtHZEUyNPQvTymc2hxHiZo0XDMmMIkBhI8/k3Ckf1N9hYnc+vJT37sV4XUajHwgd1grY86 0qwObNZYkIeAahHsNLVEEjzu9fBYNuosmj4/lid6CvxShDe2gRhQAAAAAAAA --Apple-Mail-12-1024422654-- From exim@www1.ietf.org Sun Feb 29 23:45:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01861 for ; Sun, 29 Feb 2004 23:45:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfIy-0000iA-Ej for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 23:45:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i214jOYb002734 for nemo-archive@odin.ietf.org; Sun, 29 Feb 2004 23:45:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfIy-0000i1-AZ for nemo-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 23:45:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01810 for ; Sun, 29 Feb 2004 23:45:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxfIw-0005hb-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 23:45:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxfI2-0005ac-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 23:44:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxfH9-0005U0-00 for nemo-web-archive@ietf.org; Sun, 29 Feb 2004 23:43:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfGf-0000NG-BT; Sun, 29 Feb 2004 23:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfG2-0000Hk-7n for nemo@optimus.ietf.org; Sun, 29 Feb 2004 23:42:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01513 for ; Sun, 29 Feb 2004 23:42:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxfG0-0005La-00 for nemo@ietf.org; Sun, 29 Feb 2004 23:42:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxfF2-0005EY-00 for nemo@ietf.org; Sun, 29 Feb 2004 23:41:20 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AxfE4-0004sq-00 for nemo@ietf.org; Sun, 29 Feb 2004 23:40:20 -0500 Received: from [218.37.231.188] (wideload.dhcp.ietf59.or.kr [218.37.231.188]) by multihop.net (8.12.10/8.12.10) with ESMTP id i214ekr4015398 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sun, 29 Feb 2004 20:40:48 -0800 (PST) (envelope-from tj@kniveton.com) Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <4042B535.5010003@cs.ucdavis.edu> References: <4042B535.5010003@cs.ucdavis.edu> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-12-1024422654; protocol="application/pkcs7-signature" Message-Id: <32555209-6B3A-11D8-985D-000A95DA08F2@kniveton.com> From: "T.J. Kniveton" Subject: Re: [nemo] a special discussion session for threat analysis and security requirements Date: Mon, 1 Mar 2004 13:37:50 +0900 To: IETF NEMO WG X-Mailer: Apple Mail (2.612) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --Apple-Mail-12-1024422654 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Mar 1, 2004, at 12:59 PM, S. Felix Wu wrote: > > It seems to me that we have many folks are interested in working on > security/threat related issues under NEMO, while, as TJ concluded > today, we still need a good external review for security issues. Maybe I didn't state it understandably at the meeting. The draft has definitely undergone an extensive security analysis and review during and after creation. I was saying that I would like to see some experts from the security Area make commentary and analysis about the draft. We have requested this a while back, but it didn't happen. I'm not trying to imply that the NEMO basic solution is deficient; as I said in the meeting, I would like a positive affirmation of the security analysis by those whose primary interest is security. TJ --Apple-Mail-12-1024422654 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEEjCCBA4w ggN3oAMCAQICAQgwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3Jr czEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5t dWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9wLm5ldDAeFw0wMzExMjIwMDMw MjZaFw0wODExMjAwMDMwMjZaMIGqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxGjAYBgNV BAsTEU1haWwgU2VuZGluZyBVbml0MRYwFAYDVQQDEw1ULkouIEtuaXZldG9uMR4wHAYJKoZIhvcN AQkBFg90akBrbml2ZXRvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMOyGVi3ZeqI A+thWuShiTnHWEBAOCPlbsX6nSssNdB4QNZWRmZfBr5I2Okj/E5flongKGToDI17j1aIakZ/FIkA +2gvTBxonCFvtySFn7sQ9JYVkw8QCFopEEvug3TTxGqsc3UfvFUgpEQ0berx4juC6bCRZoFey5Ss A68nqs9hAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMBgGCWCGSAGG+EIBDQQLFglUcnVzdCBtZS4w HQYDVR0OBBYEFJ9elKRQr9QN4AlUWPuDDDd+30e7MIHmBgNVHSMEgd4wgduAFOQDibOvWu1mlL3o 8nqpjMsx+Q5GoYG/pIG8MIG5MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEaMBgGA1UEChMRTXVsdGlob3AgTmV0d29ya3MxJjAkBgNVBAsT HVNlY3VyaXR5IEluZnJhc3RydWN0dXJlIEdyb3VwMRkwFwYDVQQDExBpaW8ubXVsdGlob3AubmV0 MR4wHAYJKoZIhvcNAQkBFg9jYUBtdWx0aWhvcC5uZXSCAQAwDQYJKoZIhvcNAQEEBQADgYEAThZg UzZQwvrd6ysmFdzYC8mnfrKBiM80IOzh9o3/ZywlfduKhl70Z92WEFt8/KA3Tehu16YHm/FN0RCj DqA8agRMj0b/bjIPGxhX4QfJU/ADdhuGw+ZCPBaK3d+rbS/4+j7hCavSwqtnvXOCN7KYj+KkPm21 e8OBM6rS/wFtxYgxggNvMIIDawIBATCBvzCBuTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlm b3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xGjAYBgNVBAoTEU11bHRpaG9wIE5ldHdvcmtz MSYwJAYDVQQLEx1TZWN1cml0eSBJbmZyYXN0cnVjdHVyZSBHcm91cDEZMBcGA1UEAxMQaWlvLm11 bHRpaG9wLm5ldDEeMBwGCSqGSIb3DQEJARYPY2FAbXVsdGlob3AubmV0AgEIMAkGBSsOAwIaBQCg ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMwMTA0Mzc1 MFowIwYJKoZIhvcNAQkEMRYEFEAe4+1sDmlIDOM+7yJhihB9uezcMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgDCNhN5IjCrxBOaUWE4MnjsoOqif2miZI7V9ZyO6BQCS FYAI0QWtHZEUyNPQvTymc2hxHiZo0XDMmMIkBhI8/k3Ckf1N9hYnc+vJT37sV4XUajHwgd1grY86 0qwObNZYkIeAahHsNLVEEjzu9fBYNuosmj4/lid6CvxShDe2gRhQAAAAAAAA --Apple-Mail-12-1024422654--