From nemo-admin@ietf.org Mon Dec 1 03:22:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01458 for ; Mon, 1 Dec 2003 03:22: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 1AQjJm-0008Cw-OO; Mon, 01 Dec 2003 03:22:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQjIj-0008B4-UH for nemo@optimus.ietf.org; Mon, 01 Dec 2003 03:21: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 DAA01366 for ; Mon, 1 Dec 2003 03:20:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQj70-00052z-00 for nemo@ietf.org; Mon, 01 Dec 2003 03:08:54 -0500 Received: from web21505.mail.yahoo.com ([66.163.169.16]) by ietf-mx with smtp (Exim 4.12) id 1AQj70-00052w-00 for nemo@ietf.org; Mon, 01 Dec 2003 03:08:54 -0500 Message-ID: <20031201080855.9744.qmail@web21505.mail.yahoo.com> Received: from [156.26.34.216] by web21505.mail.yahoo.com via HTTP; Mon, 01 Dec 2003 00:08:55 PST Date: Mon, 1 Dec 2003 00:08:55 -0800 (PST) From: Sachin Gorde Reply-To: gords_sachin@yahoo.com To: nemo@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [nemo] wanted some guideline Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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, I am a new member working on internet connectivity in ad-hoc nodes. I am looking forward if there is any group regarding this topic working under IETF. If anyone knows about it please let me know. Thanking you in anticipation. Sachin Gorde M.S.E.E. (student) Wichita state univ. wichita, kansas. __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ From exim@www1.ietf.org Mon Dec 1 03:22:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01488 for ; Mon, 1 Dec 2003 03:22: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 1AQjJu-0008FI-8s for nemo-archive@odin.ietf.org; Mon, 01 Dec 2003 03:22:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB18MEq1031690 for nemo-archive@odin.ietf.org; Mon, 1 Dec 2003 03:22:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQjJt-0008F3-NQ for nemo-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 03:22: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 DAA01448 for ; Mon, 1 Dec 2003 03:22:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQjJr-0005Qq-00 for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 03:22:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQjJr-0005Qm-00 for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 03:22:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQjJm-0008Cw-OO; Mon, 01 Dec 2003 03:22:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQjIj-0008B4-UH for nemo@optimus.ietf.org; Mon, 01 Dec 2003 03:21: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 DAA01366 for ; Mon, 1 Dec 2003 03:20:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQj70-00052z-00 for nemo@ietf.org; Mon, 01 Dec 2003 03:08:54 -0500 Received: from web21505.mail.yahoo.com ([66.163.169.16]) by ietf-mx with smtp (Exim 4.12) id 1AQj70-00052w-00 for nemo@ietf.org; Mon, 01 Dec 2003 03:08:54 -0500 Message-ID: <20031201080855.9744.qmail@web21505.mail.yahoo.com> Received: from [156.26.34.216] by web21505.mail.yahoo.com via HTTP; Mon, 01 Dec 2003 00:08:55 PST Date: Mon, 1 Dec 2003 00:08:55 -0800 (PST) From: Sachin Gorde Reply-To: gords_sachin@yahoo.com To: nemo@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [nemo] wanted some guideline Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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, I am a new member working on internet connectivity in ad-hoc nodes. I am looking forward if there is any group regarding this topic working under IETF. If anyone knows about it please let me know. Thanking you in anticipation. Sachin Gorde M.S.E.E. (student) Wichita state univ. wichita, kansas. __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ From nemo-admin@ietf.org Mon Dec 1 04:08:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02440 for ; Mon, 1 Dec 2003 04:08:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQk2D-0003FD-Qo; Mon, 01 Dec 2003 04:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQk1U-00034F-AG for nemo@optimus.ietf.org; Mon, 01 Dec 2003 04:07: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 EAA02418 for ; Mon, 1 Dec 2003 04:07:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQk1R-0005uh-00 for nemo@ietf.org; Mon, 01 Dec 2003 04:07:13 -0500 Received: from xenon2.um.es ([155.54.212.101] helo=smtp.um.es) by ietf-mx with esmtp (Exim 4.12) id 1AQk1R-0005ue-00 for nemo@ietf.org; Mon, 01 Dec 2003 04:07:13 -0500 Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 59DF234794; Mon, 1 Dec 2003 10:06:43 +0100 (CET) Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with ESMTP id 41412346DB; Mon, 1 Dec 2003 10:06:43 +0100 (CET) Received: from anakin (teo.dif.um.es [155.54.210.26]) by aries.dif.um.es (Postfix) with SMTP id 2B5C214426; Mon, 1 Dec 2003 09:53:58 +0100 (MET) From: "Pedro M. Ruiz" To: , Subject: RE: [nemo] wanted some guideline Date: Mon, 1 Dec 2003 10:00:33 +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.4927.1200 Importance: Normal In-Reply-To: <20031201080855.9744.qmail@web21505.mail.yahoo.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: , Content-Transfer-Encoding: 7bit Dear Sachin, In the MANET working group, there has been some proposals regarding the topic you mention. I think that whether to consider the topic or not in the next IETF meeting is still a hot topic in the WG. Furthermore, for multicast connectivity between MANETs and fixed networks, we designed a new protocol, and associated architecture, based on the concept of MIGs (Multicast Internet Gateways). Should you need further information on that, please do not hesitate to contact me. Some papers describing this approach can be found here: http://ants.dif.um.es/staff/pedrom/publications.html Best wishes, Pedro > -----Mensaje original----- > De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]En nombre de Sachin > Gorde > Enviado el: 01 December 2003 09:09 > Para: nemo@ietf.org > Asunto: [nemo] wanted some guideline > > > Hi all, > I am a new member working on internet connectivity in > ad-hoc nodes. I am looking forward if there is any > group regarding this topic working under IETF. If > anyone knows about it please let me know. > Thanking you in anticipation. > > Sachin Gorde > M.S.E.E. (student) > Wichita state univ. > wichita, kansas. > > > __________________________________ > Do you Yahoo!? > Free Pop-Up Blocker - Get it now > http://companion.yahoo.com/ > From exim@www1.ietf.org Mon Dec 1 04:08:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02455 for ; Mon, 1 Dec 2003 04:08: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 1AQk2Q-0003J9-6K for nemo-archive@odin.ietf.org; Mon, 01 Dec 2003 04:08:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB198CXi012608 for nemo-archive@odin.ietf.org; Mon, 1 Dec 2003 04:08:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQk2K-0003HB-Gq for nemo-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 04:08:08 -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 EAA02429 for ; Mon, 1 Dec 2003 04:07:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQk2H-0005v0-00 for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 04:08:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQk2H-0005ux-00 for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 04:08:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQk2D-0003FD-Qo; Mon, 01 Dec 2003 04:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQk1U-00034F-AG for nemo@optimus.ietf.org; Mon, 01 Dec 2003 04:07: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 EAA02418 for ; Mon, 1 Dec 2003 04:07:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQk1R-0005uh-00 for nemo@ietf.org; Mon, 01 Dec 2003 04:07:13 -0500 Received: from xenon2.um.es ([155.54.212.101] helo=smtp.um.es) by ietf-mx with esmtp (Exim 4.12) id 1AQk1R-0005ue-00 for nemo@ietf.org; Mon, 01 Dec 2003 04:07:13 -0500 Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 59DF234794; Mon, 1 Dec 2003 10:06:43 +0100 (CET) Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with ESMTP id 41412346DB; Mon, 1 Dec 2003 10:06:43 +0100 (CET) Received: from anakin (teo.dif.um.es [155.54.210.26]) by aries.dif.um.es (Postfix) with SMTP id 2B5C214426; Mon, 1 Dec 2003 09:53:58 +0100 (MET) From: "Pedro M. Ruiz" To: , Subject: RE: [nemo] wanted some guideline Date: Mon, 1 Dec 2003 10:00:33 +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.4927.1200 Importance: Normal In-Reply-To: <20031201080855.9744.qmail@web21505.mail.yahoo.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear Sachin, In the MANET working group, there has been some proposals regarding the topic you mention. I think that whether to consider the topic or not in the next IETF meeting is still a hot topic in the WG. Furthermore, for multicast connectivity between MANETs and fixed networks, we designed a new protocol, and associated architecture, based on the concept of MIGs (Multicast Internet Gateways). Should you need further information on that, please do not hesitate to contact me. Some papers describing this approach can be found here: http://ants.dif.um.es/staff/pedrom/publications.html Best wishes, Pedro > -----Mensaje original----- > De: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org]En nombre de Sachin > Gorde > Enviado el: 01 December 2003 09:09 > Para: nemo@ietf.org > Asunto: [nemo] wanted some guideline > > > Hi all, > I am a new member working on internet connectivity in > ad-hoc nodes. I am looking forward if there is any > group regarding this topic working under IETF. If > anyone knows about it please let me know. > Thanking you in anticipation. > > Sachin Gorde > M.S.E.E. (student) > Wichita state univ. > wichita, kansas. > > > __________________________________ > Do you Yahoo!? > Free Pop-Up Blocker - Get it now > http://companion.yahoo.com/ > From nemo-admin@ietf.org Mon Dec 1 12:32:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19053 for ; Mon, 1 Dec 2003 12:32: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 1AQrtw-0003np-Mp; Mon, 01 Dec 2003 12:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQrtM-0003kO-Cj for nemo@optimus.ietf.org; Mon, 01 Dec 2003 12:31: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 MAA18993 for ; Mon, 1 Dec 2003 12:31:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQrtK-0005dn-00 for nemo@ietf.org; Mon, 01 Dec 2003 12:31:22 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AQrtK-0005dd-00 for nemo@ietf.org; Mon, 01 Dec 2003 12:31:22 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 289326A902 for ; Mon, 1 Dec 2003 19:31:15 +0200 (EET) Message-ID: <3FCB79D5.3080009@kolumbus.fi> Date: Mon, 01 Dec 2003 19:26:45 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] review of the nemo basic spec Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 recently read the Nemo spec and have some questions and comments, embedded in the document itself: http://www.arkko.com/publications/mipv6/nemo/nemo_basic_review.txt For your convenience, I have copied the main questions and comments below: Technical: This is pretty solid work (especially for an -02) but I still had the a number of issues with it. Here are the main ones: o Why is there support for so many alternative ways to deliver route information? Note that due to the current security mechanisms, static config of routes would probably be sufficient. Or stick with just the prefix option, and don't support the static and routing protocol variants. I understand that these alternatives can be useful in some specific contexts. But reducing them would contribute to a shorter and easier-to-implement spec. o Probably makes sense to have just one moboption. o It is unclear to me why the MR needs to behave as a (limited form of a) router on the home link, and whether there are any implications of this. o A related issue is in which order do the various things take place? When do you decide you are in the home network and can act as a router, and when do you join various router-related multicast addresses, for instance? o Some error cases are missing. o It probably makes sense to be more explicit about the relationship of this document to MIPv6. Does a MR have to support everything in MIPV6, or just some parts? Or say at least that you MUST support everything... o I'd like understand loop detection better. Or at least why its not required. o I don't like the fact that MIPv6 HAs can accept and R=1 registration and no one notices anything. An approach that uses moboptions, even in the response, would probably work smoother. o Something unclear with regards to Status value treatment in Sections 5.3 and 5.4, perhaps related to the above issue. Management: My main concern are the IPRs. A lot of people I have talked with have worried about the NEMO IPRs, particularly the ones that Cisco claims to have. If I remember correctly, the Nokia IPRs are also free only for public domain implementations which isn't good. We need to decide whether this work should go forward given this situation, unless some better license conditions can be provided. If I had a choice I would rather change the design, if that would help to avoid the existing IPRs. Editorial: The document is well written, but in some cases you could have formulated it in a simpler way. A number of suggestions below. The structure of the document is good. --Jari From exim@www1.ietf.org Mon Dec 1 12:32:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19068 for ; Mon, 1 Dec 2003 12:32: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 1AQru6-0003q3-VZ for nemo-archive@odin.ietf.org; Mon, 01 Dec 2003 12:32:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1HWAqq014749 for nemo-archive@odin.ietf.org; Mon, 1 Dec 2003 12:32:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQru6-0003po-QI for nemo-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 12:32: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 MAA19027 for ; Mon, 1 Dec 2003 12:31:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQru5-0005eX-00 for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 12:32:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQru4-0005eT-00 for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 12:32:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQrtw-0003np-Mp; Mon, 01 Dec 2003 12:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQrtM-0003kO-Cj for nemo@optimus.ietf.org; Mon, 01 Dec 2003 12:31: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 MAA18993 for ; Mon, 1 Dec 2003 12:31:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQrtK-0005dn-00 for nemo@ietf.org; Mon, 01 Dec 2003 12:31:22 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AQrtK-0005dd-00 for nemo@ietf.org; Mon, 01 Dec 2003 12:31:22 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 289326A902 for ; Mon, 1 Dec 2003 19:31:15 +0200 (EET) Message-ID: <3FCB79D5.3080009@kolumbus.fi> Date: Mon, 01 Dec 2003 19:26:45 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] review of the nemo basic spec Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I recently read the Nemo spec and have some questions and comments, embedded in the document itself: http://www.arkko.com/publications/mipv6/nemo/nemo_basic_review.txt For your convenience, I have copied the main questions and comments below: Technical: This is pretty solid work (especially for an -02) but I still had the a number of issues with it. Here are the main ones: o Why is there support for so many alternative ways to deliver route information? Note that due to the current security mechanisms, static config of routes would probably be sufficient. Or stick with just the prefix option, and don't support the static and routing protocol variants. I understand that these alternatives can be useful in some specific contexts. But reducing them would contribute to a shorter and easier-to-implement spec. o Probably makes sense to have just one moboption. o It is unclear to me why the MR needs to behave as a (limited form of a) router on the home link, and whether there are any implications of this. o A related issue is in which order do the various things take place? When do you decide you are in the home network and can act as a router, and when do you join various router-related multicast addresses, for instance? o Some error cases are missing. o It probably makes sense to be more explicit about the relationship of this document to MIPv6. Does a MR have to support everything in MIPV6, or just some parts? Or say at least that you MUST support everything... o I'd like understand loop detection better. Or at least why its not required. o I don't like the fact that MIPv6 HAs can accept and R=1 registration and no one notices anything. An approach that uses moboptions, even in the response, would probably work smoother. o Something unclear with regards to Status value treatment in Sections 5.3 and 5.4, perhaps related to the above issue. Management: My main concern are the IPRs. A lot of people I have talked with have worried about the NEMO IPRs, particularly the ones that Cisco claims to have. If I remember correctly, the Nokia IPRs are also free only for public domain implementations which isn't good. We need to decide whether this work should go forward given this situation, unless some better license conditions can be provided. If I had a choice I would rather change the design, if that would help to avoid the existing IPRs. Editorial: The document is well written, but in some cases you could have formulated it in a simpler way. A number of suggestions below. The structure of the document is good. --Jari From nemo-admin@ietf.org Mon Dec 1 13:17:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20807 for ; Mon, 1 Dec 2003 13:17: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 1AQsbV-0007I0-4J; Mon, 01 Dec 2003 13:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsag-0007Bo-9B for nemo@optimus.ietf.org; Mon, 01 Dec 2003 13:16: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 NAA20649 for ; Mon, 1 Dec 2003 13:15:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQsae-0006Bk-00 for nemo@ietf.org; Mon, 01 Dec 2003 13:16:08 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AQsad-0006BM-00 for nemo@ietf.org; Mon, 01 Dec 2003 13:16:08 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 01 Dec 2003 19:12:51 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB1IFMJs005562; Mon, 1 Dec 2003 19:15:23 +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); Mon, 1 Dec 2003 18:15:35 +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 Subject: RE: [nemo] review of the nemo basic spec Date: Mon, 1 Dec 2003 18:15:34 -0000 Message-ID: Thread-Topic: [nemo] review of the nemo basic spec Thread-Index: AcO4MR5wgcXkgAZrTzOcnaI5fEfv2gAACs1w From: "Pascal Thubert (pthubert)" To: "Jari Arkko" , X-OriginalArrivalTime: 01 Dec 2003 18:15:35.0531 (UTC) FILETIME=[1D91C3B0:01C3B837] 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 Jari: Thanks for the review :) We need to dig into your work but here is a beginning of answer (and IMHO we'll have to open issues and propose text for most of your points) >=20 > o Why is there support for so many alternative ways to > deliver route information? Note that due to the current > security mechanisms, static config of routes would > probably be sufficient. Or stick with just the prefix > option, and don't support the static and routing protocol > variants. >=20 Actually there's nothing much about static but it's a configuration that has many advantages. One is the implicit authorization, another is the minimum control traffic linked to movements. So I strongly push to keep that option.=20 We can not easily prevent the configuration of a routing protocol between the MR and Home if that's what the customer wants, but how that is done is mostly out of scope.=20 As of the variants of the prefix options, I tried to defend them and at this point it's a matter of consensus. It's a small piece of code for a small value anyway. What we want to keep for sure is the ability to use a Home Address from the mobile network. >=20 > o Probably makes sense to have just one moboption. >=20 > o It is unclear to me why the MR needs to behave as a > (limited form of a) router on the home link, and whether there are > any implications of this. If Home is not using static routes and a MR deregisters, then the routes to its prefixes are removed. When at home, the MR has to inject those routes in the local IGP by itself or they just do not exist. At least one implication is the routing protocol activity (and the temporary disruptions) of the Home IGP, associated with MRs registrations and deregistrations.=20 >=20 > o A related issue is in which order do the various > things take place? When do you decide you are > in the home network and can act as a router, > and when do you join various router-related > multicast addresses, for instance? >=20 Yes, that would be the assumption. I understand that you suggest adding more text about that phase, correct? > o Some error cases are missing. >=20 > o It probably makes sense to be more explicit about > the relationship of this document to MIPv6. Does > a MR have to support everything in MIPV6, or just > some parts? Or say at least that you MUST support > everything... Right. In basic mode, the MR does not need to support to be a CN, and RO with a CN, since it is not expected to be the end point of most conversations. But IMHO, a Nemo HA should fully support MIPv6. Comments anyone? >=20 > o I'd like understand loop detection better. Or > at least why its not required. >=20 You mean packets flying back and forth over MRHA? I believe we should have text to prevent a HA from putting a packet back on a same MRHA tunnel, which is a classical behavior. > o I don't like the fact that MIPv6 HAs can accept > and R=3D1 registration and no one notices anything. > An approach that uses moboptions, even in the > response, would probably work smoother. >=20 Could you please elaborate? > o Something unclear with regards to Status value > treatment in Sections 5.3 and 5.4, perhaps > related to the above issue. >=20 > Management: My main concern are the IPRs. A lot of people I have > talked with have worried about the NEMO IPRs, particularly the > ones that Cisco claims to have. If I remember correctly, the > Nokia IPRs are also free only for public domain implementations > which isn't good. We need to decide whether this work should go > forward given this situation, unless some better license > conditions can be provided. If I had a choice I would rather > change the design, if that would help to avoid the existing > IPRs. >=20 > Editorial: The document is well written, but in some cases you > could have formulated it in a simpler way. A number of > suggestions below. The structure of the document is good. >=20 > --Jari >=20 >=20 From exim@www1.ietf.org Mon Dec 1 13:17:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20834 for ; Mon, 1 Dec 2003 13:17: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 1AQsbY-0007NJ-4r for nemo-archive@odin.ietf.org; Mon, 01 Dec 2003 13:17:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1IH4Yd028343 for nemo-archive@odin.ietf.org; Mon, 1 Dec 2003 13:17:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsbY-0007N4-0I for nemo-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 13:17: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 NAA20773 for ; Mon, 1 Dec 2003 13:16:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQsbV-0006CF-00 for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 13:17:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQsbV-0006CC-00 for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 13:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsbV-0007I0-4J; Mon, 01 Dec 2003 13:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsag-0007Bo-9B for nemo@optimus.ietf.org; Mon, 01 Dec 2003 13:16: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 NAA20649 for ; Mon, 1 Dec 2003 13:15:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQsae-0006Bk-00 for nemo@ietf.org; Mon, 01 Dec 2003 13:16:08 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AQsad-0006BM-00 for nemo@ietf.org; Mon, 01 Dec 2003 13:16:08 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 01 Dec 2003 19:12:51 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB1IFMJs005562; Mon, 1 Dec 2003 19:15:23 +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); Mon, 1 Dec 2003 18:15:35 +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 Subject: RE: [nemo] review of the nemo basic spec Date: Mon, 1 Dec 2003 18:15:34 -0000 Message-ID: Thread-Topic: [nemo] review of the nemo basic spec Thread-Index: AcO4MR5wgcXkgAZrTzOcnaI5fEfv2gAACs1w From: "Pascal Thubert (pthubert)" To: "Jari Arkko" , X-OriginalArrivalTime: 01 Dec 2003 18:15:35.0531 (UTC) FILETIME=[1D91C3B0:01C3B837] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jari: Thanks for the review :) We need to dig into your work but here is a beginning of answer (and IMHO we'll have to open issues and propose text for most of your points) >=20 > o Why is there support for so many alternative ways to > deliver route information? Note that due to the current > security mechanisms, static config of routes would > probably be sufficient. Or stick with just the prefix > option, and don't support the static and routing protocol > variants. >=20 Actually there's nothing much about static but it's a configuration that has many advantages. One is the implicit authorization, another is the minimum control traffic linked to movements. So I strongly push to keep that option.=20 We can not easily prevent the configuration of a routing protocol between the MR and Home if that's what the customer wants, but how that is done is mostly out of scope.=20 As of the variants of the prefix options, I tried to defend them and at this point it's a matter of consensus. It's a small piece of code for a small value anyway. What we want to keep for sure is the ability to use a Home Address from the mobile network. >=20 > o Probably makes sense to have just one moboption. >=20 > o It is unclear to me why the MR needs to behave as a > (limited form of a) router on the home link, and whether there are > any implications of this. If Home is not using static routes and a MR deregisters, then the routes to its prefixes are removed. When at home, the MR has to inject those routes in the local IGP by itself or they just do not exist. At least one implication is the routing protocol activity (and the temporary disruptions) of the Home IGP, associated with MRs registrations and deregistrations.=20 >=20 > o A related issue is in which order do the various > things take place? When do you decide you are > in the home network and can act as a router, > and when do you join various router-related > multicast addresses, for instance? >=20 Yes, that would be the assumption. I understand that you suggest adding more text about that phase, correct? > o Some error cases are missing. >=20 > o It probably makes sense to be more explicit about > the relationship of this document to MIPv6. Does > a MR have to support everything in MIPV6, or just > some parts? Or say at least that you MUST support > everything... Right. In basic mode, the MR does not need to support to be a CN, and RO with a CN, since it is not expected to be the end point of most conversations. But IMHO, a Nemo HA should fully support MIPv6. Comments anyone? >=20 > o I'd like understand loop detection better. Or > at least why its not required. >=20 You mean packets flying back and forth over MRHA? I believe we should have text to prevent a HA from putting a packet back on a same MRHA tunnel, which is a classical behavior. > o I don't like the fact that MIPv6 HAs can accept > and R=3D1 registration and no one notices anything. > An approach that uses moboptions, even in the > response, would probably work smoother. >=20 Could you please elaborate? > o Something unclear with regards to Status value > treatment in Sections 5.3 and 5.4, perhaps > related to the above issue. >=20 > Management: My main concern are the IPRs. A lot of people I have > talked with have worried about the NEMO IPRs, particularly the > ones that Cisco claims to have. If I remember correctly, the > Nokia IPRs are also free only for public domain implementations > which isn't good. We need to decide whether this work should go > forward given this situation, unless some better license > conditions can be provided. If I had a choice I would rather > change the design, if that would help to avoid the existing > IPRs. >=20 > Editorial: The document is well written, but in some cases you > could have formulated it in a simpler way. A number of > suggestions below. The structure of the document is good. >=20 > --Jari >=20 >=20 From nemo-admin@ietf.org Mon Dec 1 14:20:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23323 for ; Mon, 1 Dec 2003 14:20: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 1AQtaV-0002tk-NU; Mon, 01 Dec 2003 14:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtaF-0002ss-Dl for nemo@optimus.ietf.org; Mon, 01 Dec 2003 14:19: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 OAA23306 for ; Mon, 1 Dec 2003 14:19:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtaC-00074S-00 for nemo@ietf.org; Mon, 01 Dec 2003 14:19:44 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AQta8-00074L-00 for nemo@ietf.org; Mon, 01 Dec 2003 14:19:40 -0500 Received: from [192.103.17.160] ([192.103.17.160]) by multihop.net (8.12.10/8.12.10) with ESMTP id hB1JKMA8026636 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 1 Dec 2003 11:20:23 -0800 (PST) (envelope-from tj@kniveton.com) Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: <3FCB79D5.3080009@kolumbus.fi> References: <3FCB79D5.3080009@kolumbus.fi> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7--342631156; protocol="application/pkcs7-signature" Message-Id: <46C4686A-2433-11D8-81BF-000A95DA08F2@kniveton.com> From: "T.J. Kniveton" Subject: IPR (Re: [nemo] review of the nemo basic spec) Date: Mon, 1 Dec 2003 11:19:25 -0800 To: nemo@ietf.org X-Mailer: Apple Mail (2.606) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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-7--342631156 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Dec 1, 2003, at 9:26 AM, Jari Arkko wrote: > Management: My main concern are the IPRs. A lot of people I have > talked with have worried about the NEMO IPRs, particularly the > ones that Cisco claims to have. If I remember correctly, the > Nokia IPRs are also free only for public domain implementations > which isn't good. We need to decide whether this work should go > forward given this situation, unless some better license > conditions can be provided. If I had a choice I would rather > change the design, if that would help to avoid the existing > IPRs. We have had several discussions about this, the latest one being at the IETF58 meeting. The group consensus so far is to move forward with the current technical solution, and monitor the IPR situation and further patents that are issued. Right now, there are many unknowns, including (but not limited to) what claims are in the pending patent applications from cisco, whether cisco will be willing to change their licensing on this technology (so far the answer is an unresounding no), and whether Nokia would change their licensing terms, if there were a consensus to ask for this (so far, there isn't). So, to answer your question whether the work should go forward, the answer so far from the WG is yes. TJ --Apple-Mail-7--342631156 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 ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTIwMTE5MTky NlowIwYJKoZIhvcNAQkEMRYEFGMbxmwXcUfGLsXVSjc9flvUwT9eMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgFkqUr0xIiCiqZmrwiYXq7gMDM7nj/Y6yfgMeNr5tQcX b17bv0bk7bC0GwFenFWaAs9qqEBtWO7JaPaPwWO22YDosM1u9WXChpcUDQcmQ5axGRqGCuu9yKfN ASjzqQfjDqOtM0X4YZb2P/mkurv9PfYIVy6fXExLYh6gHDlo6Ed4AAAAAAAA --Apple-Mail-7--342631156-- From exim@www1.ietf.org Mon Dec 1 14:20:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23342 for ; Mon, 1 Dec 2003 14:20:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtaw-0002yM-3g for nemo-archive@odin.ietf.org; Mon, 01 Dec 2003 14:20:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1JKUu5011425 for nemo-archive@odin.ietf.org; Mon, 1 Dec 2003 14:20:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtav-0002yC-W4 for nemo-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 14:20: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 OAA23314 for ; Mon, 1 Dec 2003 14:20:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtat-00074i-00 for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 14:20:27 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQtat-00074d-00 for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 14:20:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtaV-0002tk-NU; Mon, 01 Dec 2003 14:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtaF-0002ss-Dl for nemo@optimus.ietf.org; Mon, 01 Dec 2003 14:19: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 OAA23306 for ; Mon, 1 Dec 2003 14:19:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtaC-00074S-00 for nemo@ietf.org; Mon, 01 Dec 2003 14:19:44 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AQta8-00074L-00 for nemo@ietf.org; Mon, 01 Dec 2003 14:19:40 -0500 Received: from [192.103.17.160] ([192.103.17.160]) by multihop.net (8.12.10/8.12.10) with ESMTP id hB1JKMA8026636 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 1 Dec 2003 11:20:23 -0800 (PST) (envelope-from tj@kniveton.com) Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: <3FCB79D5.3080009@kolumbus.fi> References: <3FCB79D5.3080009@kolumbus.fi> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7--342631156; protocol="application/pkcs7-signature" Message-Id: <46C4686A-2433-11D8-81BF-000A95DA08F2@kniveton.com> From: "T.J. Kniveton" Subject: IPR (Re: [nemo] review of the nemo basic spec) Date: Mon, 1 Dec 2003 11:19:25 -0800 To: nemo@ietf.org X-Mailer: Apple Mail (2.606) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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-7--342631156 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Dec 1, 2003, at 9:26 AM, Jari Arkko wrote: > Management: My main concern are the IPRs. A lot of people I have > talked with have worried about the NEMO IPRs, particularly the > ones that Cisco claims to have. If I remember correctly, the > Nokia IPRs are also free only for public domain implementations > which isn't good. We need to decide whether this work should go > forward given this situation, unless some better license > conditions can be provided. If I had a choice I would rather > change the design, if that would help to avoid the existing > IPRs. We have had several discussions about this, the latest one being at the IETF58 meeting. The group consensus so far is to move forward with the current technical solution, and monitor the IPR situation and further patents that are issued. Right now, there are many unknowns, including (but not limited to) what claims are in the pending patent applications from cisco, whether cisco will be willing to change their licensing on this technology (so far the answer is an unresounding no), and whether Nokia would change their licensing terms, if there were a consensus to ask for this (so far, there isn't). So, to answer your question whether the work should go forward, the answer so far from the WG is yes. TJ --Apple-Mail-7--342631156 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 ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTIwMTE5MTky NlowIwYJKoZIhvcNAQkEMRYEFGMbxmwXcUfGLsXVSjc9flvUwT9eMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgFkqUr0xIiCiqZmrwiYXq7gMDM7nj/Y6yfgMeNr5tQcX b17bv0bk7bC0GwFenFWaAs9qqEBtWO7JaPaPwWO22YDosM1u9WXChpcUDQcmQ5axGRqGCuu9yKfN ASjzqQfjDqOtM0X4YZb2P/mkurv9PfYIVy6fXExLYh6gHDlo6Ed4AAAAAAAA --Apple-Mail-7--342631156-- From nemo-admin@ietf.org Mon Dec 1 14:21:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23375 for ; Mon, 1 Dec 2003 14:21: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 1AQtbR-00031w-5c; Mon, 01 Dec 2003 14:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtaw-0002yV-IL for nemo@optimus.ietf.org; Mon, 01 Dec 2003 14:20: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 OAA23321 for ; Mon, 1 Dec 2003 14:20:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtat-00074s-00 for nemo@ietf.org; Mon, 01 Dec 2003 14:20:27 -0500 Received: from sunlight.wichita.edu ([156.26.1.5]) by ietf-mx with esmtp (Exim 4.12) id 1AQtat-00074c-00 for nemo@ietf.org; Mon, 01 Dec 2003 14:20:27 -0500 Received: from CONVERSION-DAEMON.sunlight.wichita.edu by sunlight.wichita.edu (PMDF V6.2-X17 #30772) id <0HP800B01DP6F6@sunlight.wichita.edu> for nemo@ietf.org; Mon, 01 Dec 2003 13:19:54 -0600 (CST) Received: from webmail.wichita.edu (BIERSTADT.WICHITA.EDU [156.26.1.165]) by sunlight.wichita.edu (PMDF V6.2-X17 #30772) with ESMTP id <0HP800BA2DP66Z@sunlight.wichita.edu> for nemo@ietf.org; Mon, 01 Dec 2003 13:19:54 -0600 (CST) Date: Mon, 01 Dec 2003 13:19:54 -0600 From: sggorde To: nemo@ietf.org Message-id: <3FCB5AD9@webmail.wichita.edu> MIME-version: 1.0 X-Mailer: WebMail (Hydra) SMTP v3.62 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-WebMail-UserID: sggorde@wichita.edu X-EXP32-SerialNo: 00003023, 00003770 Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit unsubscribe shilpa91277 sggorde@wichita.edu Sachin G. Gorde Electrical and Computer Engineering Dept. Wichita State University, Wichita, Kansas, USA. From exim@www1.ietf.org Mon Dec 1 14:21:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23390 for ; Mon, 1 Dec 2003 14:21: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 1AQtbT-00036t-KN for nemo-archive@odin.ietf.org; Mon, 01 Dec 2003 14:21:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1JL37T011946 for nemo-archive@odin.ietf.org; Mon, 1 Dec 2003 14:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtbT-00036Y-84 for nemo-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 14:21: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 OAA23359 for ; Mon, 1 Dec 2003 14:20:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtbQ-00074z-00 for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 14:21:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQtbQ-00074w-00 for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 14:21:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtbR-00031w-5c; Mon, 01 Dec 2003 14:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtaw-0002yV-IL for nemo@optimus.ietf.org; Mon, 01 Dec 2003 14:20: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 OAA23321 for ; Mon, 1 Dec 2003 14:20:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtat-00074s-00 for nemo@ietf.org; Mon, 01 Dec 2003 14:20:27 -0500 Received: from sunlight.wichita.edu ([156.26.1.5]) by ietf-mx with esmtp (Exim 4.12) id 1AQtat-00074c-00 for nemo@ietf.org; Mon, 01 Dec 2003 14:20:27 -0500 Received: from CONVERSION-DAEMON.sunlight.wichita.edu by sunlight.wichita.edu (PMDF V6.2-X17 #30772) id <0HP800B01DP6F6@sunlight.wichita.edu> for nemo@ietf.org; Mon, 01 Dec 2003 13:19:54 -0600 (CST) Received: from webmail.wichita.edu (BIERSTADT.WICHITA.EDU [156.26.1.165]) by sunlight.wichita.edu (PMDF V6.2-X17 #30772) with ESMTP id <0HP800BA2DP66Z@sunlight.wichita.edu> for nemo@ietf.org; Mon, 01 Dec 2003 13:19:54 -0600 (CST) Date: Mon, 01 Dec 2003 13:19:54 -0600 From: sggorde To: nemo@ietf.org Message-id: <3FCB5AD9@webmail.wichita.edu> MIME-version: 1.0 X-Mailer: WebMail (Hydra) SMTP v3.62 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-WebMail-UserID: sggorde@wichita.edu X-EXP32-SerialNo: 00003023, 00003770 Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit unsubscribe shilpa91277 sggorde@wichita.edu Sachin G. Gorde Electrical and Computer Engineering Dept. Wichita State University, Wichita, Kansas, USA. From nemo-admin@ietf.org Mon Dec 1 16:38:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01767 for ; Mon, 1 Dec 2003 16:38:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvk2-0004F1-8u; Mon, 01 Dec 2003 16: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 1AQvjd-00047X-VI for nemo@optimus.ietf.org; Mon, 01 Dec 2003 16:37: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 QAA01744 for ; Mon, 1 Dec 2003 16:37:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvjb-00021y-00 for nemo@ietf.org; Mon, 01 Dec 2003 16:37:35 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AQvjb-00021v-00 for nemo@ietf.org; Mon, 01 Dec 2003 16:37:35 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 29ECA6A901; Mon, 1 Dec 2003 23:37:34 +0200 (EET) Message-ID: <3FCBB391.6060909@kolumbus.fi> Date: Mon, 01 Dec 2003 23:33:05 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: nemo@ietf.org Subject: Re: [nemo] review of the nemo basic spec 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: , Content-Transfer-Encoding: 7bit Thanks for your prompt answer, Pascal. Inline: >> o Why is there support for so many alternative ways to >> deliver route information? Note that due to the current >> security mechanisms, static config of routes would >> probably be sufficient. Or stick with just the prefix >> option, and don't support the static and routing protocol >> variants. >> > > > Actually there's nothing much about static but it's a configuration that > has many advantages. One is the implicit authorization, another is the > minimum control traffic linked to movements. > So I strongly push to keep that option. > > We can not easily prevent the configuration of a routing protocol > between the MR and Home if that's what the customer wants, but how that > is done is mostly out of scope. You may be right, but then again describing the routing protocol behaviour in the basic spec will lead to a number of MUSTs or SHOULDs, or at least MAYs. We could avoid that, even if someone does that on their own, or if you develop a NEMO Dynamic Routing Extension later. > As of the variants of the prefix options, I tried to defend them and at > this point it's a matter of consensus. It's a small piece of code for a > small value anyway. What we want to keep for sure is the ability to use > a Home Address from the mobile network. That I agree with. >> o Probably makes sense to have just one moboption. >> >> o It is unclear to me why the MR needs to behave as a >> (limited form of a) router on the home link, and whether > > there are > >> any implications of this. > > > If Home is not using static routes and a MR deregisters, then the routes > to its prefixes are removed. When at home, the MR has to inject those > routes in the local IGP by itself or they just do not exist. At least > one implication is the routing protocol activity (and the temporary > disruptions) of the Home IGP, associated with MRs registrations and > deregistrations. Ok. The IGP route argument is compelling. The implications I was afraid of were related to a host becoming a router depending on movement detection results. I don't have any specific case where this would fail, I just worried about it. >> o A related issue is in which order do the various >> things take place? When do you decide you are >> in the home network and can act as a router, >> and when do you join various router-related >> multicast addresses, for instance? >> > > > Yes, that would be the assumption. I understand that you suggest adding > more text about that phase, correct? Yes. >> o Some error cases are missing. >> >> o It probably makes sense to be more explicit about >> the relationship of this document to MIPv6. Does >> a MR have to support everything in MIPV6, or just >> some parts? Or say at least that you MUST support >> everything... > > > Right. In basic mode, the MR does not need to support to be a CN, and RO > with a CN, since it is not expected to be the end point of most > conversations. But IMHO, a Nemo HA should fully support MIPv6. Comments > anyone? Specification-wise it would be easiest to just require full support. Functionality-wise RO might not be necessary, if the MR is not sending any packets itself. OTOH RO support is not a very big burden. >> o I'd like understand loop detection better. Or >> at least why its not required. >> > > > You mean packets flying back and forth over MRHA? I believe we should > have text to prevent a HA from putting a packet back on a same MRHA > tunnel, which is a classical behavior. Here's what I'm thinking: Step 1. MR1 -> MR2 -> MR3 ---> Fixed Network ---> HA Step 2. _---> Fixed Network ---> HA / +---> MR1 -> MR2 -> MR3 ---+ | | +--------------------------+ Step 3. +---> MR1 -> MR2 -> MR3 ---+ | | +--------------------------+ That is, an MR3 is attached to a fixed network and communicates with its HA. There are nested MRs, MR1 and MR2. Now, MR3 sees MR1 advertising access with a better signal strenght, and thinks incorrectly that it would be a good idea to attach to it. So it decides to attach to MR1 instead. However, MR3 keeps its old attachment running until it has completed the attachment to MR1; this implies the BU it sends via MR1 gets routed back to itself in a tunnel, and actually gets to the home agent via the still operational fixed attachment. But after the BA comes back, MR3 detaches itself from the fixed network. As a result, we have a loop and no connectivity. Now try to send a data packet. I would like to understand why this is not a problem. I'm sure I'm missing something obvious. >> o I don't like the fact that MIPv6 HAs can accept >> and R=1 registration and no one notices anything. >> An approach that uses moboptions, even in the >> response, would probably work smoother. >> > > > Could you please elaborate? I'm referring to the first paragraph of Section 7. Remember that according to MIPv6 base spec, unknown flags are ignored, as are unknown moboptions. One good way past this is to send one moboption and expect another one back as an ack that the receiver understood what you requested; then you know the HA supports NEMO. Alternatively, you can track a flag value on the Binding Ack. If it comes back as zero, HA did not support NEMO. In nemo, you do neither. Instead you have added a new flag in DHAAD. That is useful, but I would also handle the BU/BA in a way that the mobile router becomes certain the home agent understood what it was being asked to do. Does this help explain my issue about the current nemo R=1 usage? --Jari From exim@www1.ietf.org Mon Dec 1 16:38:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01784 for ; Mon, 1 Dec 2003 16:38: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 1AQvk9-0004Ga-Pl for nemo-archive@odin.ietf.org; Mon, 01 Dec 2003 16:38:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1Lc9VW016385 for nemo-archive@odin.ietf.org; Mon, 1 Dec 2003 16:38:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvk9-0004GB-0E for nemo-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 16:38: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 QAA01758 for ; Mon, 1 Dec 2003 16:37:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvk7-00022j-00 for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 16:38:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQvk6-00022g-00 for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 16:38:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvk2-0004F1-8u; Mon, 01 Dec 2003 16: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 1AQvjd-00047X-VI for nemo@optimus.ietf.org; Mon, 01 Dec 2003 16:37: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 QAA01744 for ; Mon, 1 Dec 2003 16:37:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvjb-00021y-00 for nemo@ietf.org; Mon, 01 Dec 2003 16:37:35 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AQvjb-00021v-00 for nemo@ietf.org; Mon, 01 Dec 2003 16:37:35 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 29ECA6A901; Mon, 1 Dec 2003 23:37:34 +0200 (EET) Message-ID: <3FCBB391.6060909@kolumbus.fi> Date: Mon, 01 Dec 2003 23:33:05 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: nemo@ietf.org Subject: Re: [nemo] review of the nemo basic spec 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for your prompt answer, Pascal. Inline: >> o Why is there support for so many alternative ways to >> deliver route information? Note that due to the current >> security mechanisms, static config of routes would >> probably be sufficient. Or stick with just the prefix >> option, and don't support the static and routing protocol >> variants. >> > > > Actually there's nothing much about static but it's a configuration that > has many advantages. One is the implicit authorization, another is the > minimum control traffic linked to movements. > So I strongly push to keep that option. > > We can not easily prevent the configuration of a routing protocol > between the MR and Home if that's what the customer wants, but how that > is done is mostly out of scope. You may be right, but then again describing the routing protocol behaviour in the basic spec will lead to a number of MUSTs or SHOULDs, or at least MAYs. We could avoid that, even if someone does that on their own, or if you develop a NEMO Dynamic Routing Extension later. > As of the variants of the prefix options, I tried to defend them and at > this point it's a matter of consensus. It's a small piece of code for a > small value anyway. What we want to keep for sure is the ability to use > a Home Address from the mobile network. That I agree with. >> o Probably makes sense to have just one moboption. >> >> o It is unclear to me why the MR needs to behave as a >> (limited form of a) router on the home link, and whether > > there are > >> any implications of this. > > > If Home is not using static routes and a MR deregisters, then the routes > to its prefixes are removed. When at home, the MR has to inject those > routes in the local IGP by itself or they just do not exist. At least > one implication is the routing protocol activity (and the temporary > disruptions) of the Home IGP, associated with MRs registrations and > deregistrations. Ok. The IGP route argument is compelling. The implications I was afraid of were related to a host becoming a router depending on movement detection results. I don't have any specific case where this would fail, I just worried about it. >> o A related issue is in which order do the various >> things take place? When do you decide you are >> in the home network and can act as a router, >> and when do you join various router-related >> multicast addresses, for instance? >> > > > Yes, that would be the assumption. I understand that you suggest adding > more text about that phase, correct? Yes. >> o Some error cases are missing. >> >> o It probably makes sense to be more explicit about >> the relationship of this document to MIPv6. Does >> a MR have to support everything in MIPV6, or just >> some parts? Or say at least that you MUST support >> everything... > > > Right. In basic mode, the MR does not need to support to be a CN, and RO > with a CN, since it is not expected to be the end point of most > conversations. But IMHO, a Nemo HA should fully support MIPv6. Comments > anyone? Specification-wise it would be easiest to just require full support. Functionality-wise RO might not be necessary, if the MR is not sending any packets itself. OTOH RO support is not a very big burden. >> o I'd like understand loop detection better. Or >> at least why its not required. >> > > > You mean packets flying back and forth over MRHA? I believe we should > have text to prevent a HA from putting a packet back on a same MRHA > tunnel, which is a classical behavior. Here's what I'm thinking: Step 1. MR1 -> MR2 -> MR3 ---> Fixed Network ---> HA Step 2. _---> Fixed Network ---> HA / +---> MR1 -> MR2 -> MR3 ---+ | | +--------------------------+ Step 3. +---> MR1 -> MR2 -> MR3 ---+ | | +--------------------------+ That is, an MR3 is attached to a fixed network and communicates with its HA. There are nested MRs, MR1 and MR2. Now, MR3 sees MR1 advertising access with a better signal strenght, and thinks incorrectly that it would be a good idea to attach to it. So it decides to attach to MR1 instead. However, MR3 keeps its old attachment running until it has completed the attachment to MR1; this implies the BU it sends via MR1 gets routed back to itself in a tunnel, and actually gets to the home agent via the still operational fixed attachment. But after the BA comes back, MR3 detaches itself from the fixed network. As a result, we have a loop and no connectivity. Now try to send a data packet. I would like to understand why this is not a problem. I'm sure I'm missing something obvious. >> o I don't like the fact that MIPv6 HAs can accept >> and R=1 registration and no one notices anything. >> An approach that uses moboptions, even in the >> response, would probably work smoother. >> > > > Could you please elaborate? I'm referring to the first paragraph of Section 7. Remember that according to MIPv6 base spec, unknown flags are ignored, as are unknown moboptions. One good way past this is to send one moboption and expect another one back as an ack that the receiver understood what you requested; then you know the HA supports NEMO. Alternatively, you can track a flag value on the Binding Ack. If it comes back as zero, HA did not support NEMO. In nemo, you do neither. Instead you have added a new flag in DHAAD. That is useful, but I would also handle the BU/BA in a way that the mobile router becomes certain the home agent understood what it was being asked to do. Does this help explain my issue about the current nemo R=1 usage? --Jari From nemo-admin@ietf.org Mon Dec 1 17:59:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08365 for ; Mon, 1 Dec 2003 17:59: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 1AQx0P-0000rr-8S; Mon, 01 Dec 2003 17:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQx0C-0000rE-6B for nemo@optimus.ietf.org; Mon, 01 Dec 2003 17:58: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 RAA08217 for ; Mon, 1 Dec 2003 17:58:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQx09-0004Zo-00 for nemo@ietf.org; Mon, 01 Dec 2003 17:58:45 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AQx08-0004Zd-00 for nemo@ietf.org; Mon, 01 Dec 2003 17:58:44 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB1Mvwq32007; Mon, 1 Dec 2003 14:57:58 -0800 X-mProtect: <200312012257> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2BvEXs; Mon, 01 Dec 2003 14:57:57 PST Message-ID: <3FCBC8B5.6030206@iprg.nokia.com> Date: Mon, 01 Dec 2003 15:03:17 -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: Jari Arkko CC: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] review of the nemo basic spec References: <3FCBB391.6060909@kolumbus.fi> In-Reply-To: <3FCBB391.6060909@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Thanks for your prompt answer, Pascal. Inline: > >>> o Why is there support for so many alternative ways to >>> deliver route information? Note that due to the current >>> security mechanisms, static config of routes would >>> probably be sufficient. Or stick with just the prefix >>> option, and don't support the static and routing protocol >>> variants. >>> >> >> >> Actually there's nothing much about static but it's a configuration that >> has many advantages. One is the implicit authorization, another is the >> minimum control traffic linked to movements. >> So I strongly push to keep that option. >> We can not easily prevent the configuration of a routing protocol >> between the MR and Home if that's what the customer wants, but how that >> is done is mostly out of scope. > > > You may be right, but then again describing the routing protocol > behaviour in the basic spec will lead to a number of MUSTs or SHOULDs, > or at least MAYs. We could avoid that, even if someone does that > on their own, or if you develop a NEMO Dynamic Routing Extension > later. > >> As of the variants of the prefix options, I tried to defend them and at >> this point it's a matter of consensus. It's a small piece of code for a >> small value anyway. What we want to keep for sure is the ability to use >> a Home Address from the mobile network. > > > That I agree with. there is an ongoing discussion on removing the explicit prefix length mode. it is issue 20 at http://people.nokia.net/vijayd/nemo/issues.html. IMO, we can remove this mode, since the explicit network mode can used to do whatever you want to do with the explicit prefix length mode. > >>> o Probably makes sense to have just one moboption >>> >>> o It is unclear to me why the MR needs to behave as a >>> (limited form of a) router on the home link, and whether >> >> >> there are >> >>> any implications of this. >> >> >> >> If Home is not using static routes and a MR deregisters, then the routes >> to its prefixes are removed. When at home, the MR has to inject those >> routes in the local IGP by itself or they just do not exist. At least >> one implication is the routing protocol activity (and the temporary >> disruptions) of the Home IGP, associated with MRs registrations and >> deregistrations. > > > Ok. The IGP route argument is compelling. > > The implications I was afraid of were related to a host > becoming a router depending on movement detection results. > I don't have any specific case where this would fail, I > just worried about it. the idea is let the mobile router on its home link behave as it would if it were a fixed router. turning on/off this behavior very much depends on movement detection. I dont see any issue currently though. > >>> o A related issue is in which order do the various >>> things take place? When do you decide you are >>> in the home network and can act as a router, >>> and when do you join various router-related >>> multicast addresses, for instance? >>> >> >> >> Yes, that would be the assumption. I understand that you suggest adding >> more text about that phase, correct? > > > Yes. I will add some text. > >>> o Some error cases are missing. ?? >>> >>> o It probably makes sense to be more explicit about >>> the relationship of this document to MIPv6. Does >>> a MR have to support everything in MIPV6, or just >>> some parts? Or say at least that you MUST support >>> everything... >> >> >> >> Right. In basic mode, the MR does not need to support to be a CN, and RO >> with a CN, since it is not expected to be the end point of most >> conversations. But IMHO, a Nemo HA should fully support MIPv6. Comments >> anyone? > > > Specification-wise it would be easiest to just require full > support. Functionality-wise RO might not be necessary, if the > MR is not sending any packets itself. OTOH RO support is not > a very big burden. it depends on the specific scenario. if a cell phone is a mobile router (which provides connectivity to a laptop and an MP3 device), then it is likely to be a mobile node most of the time. maybe we should should all of MIPv6 (?) > >>> o I'd like understand loop detection better. Or >>> at least why its not required. >>> >> >> >> You mean packets flying back and forth over MRHA? I believe we should >> have text to prevent a HA from putting a packet back on a same MRHA >> tunnel, which is a classical behavior. > > > Here's what I'm thinking: filed this as issue 24 at http://people.nokia.net/vijayd/nemo/issues.html >>> o I don't like the fact that MIPv6 HAs can accept >>> and R=1 registration and no one notices anything. >>> An approach that uses moboptions, even in the >>> response, would probably work smoother. >>> >> >> >> Could you please elaborate? > > > I'm referring to the first paragraph of Section 7. > Remember that according to MIPv6 base spec, unknown > flags are ignored, as are unknown moboptions. One good > way past this is to send one moboption and expect another > one back as an ack that the receiver understood what you > requested; then you know the HA supports NEMO. Alternatively, > you can track a flag value on the Binding Ack. If it comes > back as zero, HA did not support NEMO. > > In nemo, you do neither. Instead you have added a new flag > in DHAAD. That is useful, but I would also handle the BU/BA > in a way that the mobile router becomes certain the home > agent understood what it was being asked to do. > > Does this help explain my issue about the current nemo R=1 > usage? this was discussed earlier. Issues 15 and 16 capture the discussion. the first solution to support inter-working with MIPv6 Home Agents was to add a new binding ack status which says forwarding was setup. MIPv6 Home Agents would return just 0. the second suggestion was to add a flag in the binding ack which would be set to 1 if the Home Agents sets up forwarding for the mobile network. MIPv6 Home Agent would not set this flag. neither of this will work because, the Mobile Router now has to repeatedly try other Home Agents until it gets an indication from a Home Agent that it has set up forwarding. the mobile router also has to deregister with the MIPv6 Home Agent before trying another Home Agent. so modifying DHAAD was the right solution. the mobile router should not have attempted registration with a Home Agent that does not support mobile routers. IMO, a flag in the binding ack is just extra specification and extra code for something that shouldnt have happened. what do you think? Vijay From exim@www1.ietf.org Mon Dec 1 17:59:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08380 for ; Mon, 1 Dec 2003 17:59: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 1AQx0Z-0000ux-DA for nemo-archive@odin.ietf.org; Mon, 01 Dec 2003 17:59:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1MxBkg003521 for nemo-archive@odin.ietf.org; Mon, 1 Dec 2003 17:59:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQx0Z-0000ui-8j for nemo-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 17:59:11 -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 RAA08255 for ; Mon, 1 Dec 2003 17:58:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQx0W-0004as-00 for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 17:59:08 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AQx0V-0004ai-00 for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 17:59:07 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AQx0W-0007VD-LR for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 17:59:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQx0P-0000rr-8S; Mon, 01 Dec 2003 17:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQx0C-0000rE-6B for nemo@optimus.ietf.org; Mon, 01 Dec 2003 17:58: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 RAA08217 for ; Mon, 1 Dec 2003 17:58:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQx09-0004Zo-00 for nemo@ietf.org; Mon, 01 Dec 2003 17:58:45 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AQx08-0004Zd-00 for nemo@ietf.org; Mon, 01 Dec 2003 17:58:44 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB1Mvwq32007; Mon, 1 Dec 2003 14:57:58 -0800 X-mProtect: <200312012257> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2BvEXs; Mon, 01 Dec 2003 14:57:57 PST Message-ID: <3FCBC8B5.6030206@iprg.nokia.com> Date: Mon, 01 Dec 2003 15:03:17 -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: Jari Arkko CC: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] review of the nemo basic spec References: <3FCBB391.6060909@kolumbus.fi> In-Reply-To: <3FCBB391.6060909@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Thanks for your prompt answer, Pascal. Inline: > >>> o Why is there support for so many alternative ways to >>> deliver route information? Note that due to the current >>> security mechanisms, static config of routes would >>> probably be sufficient. Or stick with just the prefix >>> option, and don't support the static and routing protocol >>> variants. >>> >> >> >> Actually there's nothing much about static but it's a configuration that >> has many advantages. One is the implicit authorization, another is the >> minimum control traffic linked to movements. >> So I strongly push to keep that option. >> We can not easily prevent the configuration of a routing protocol >> between the MR and Home if that's what the customer wants, but how that >> is done is mostly out of scope. > > > You may be right, but then again describing the routing protocol > behaviour in the basic spec will lead to a number of MUSTs or SHOULDs, > or at least MAYs. We could avoid that, even if someone does that > on their own, or if you develop a NEMO Dynamic Routing Extension > later. > >> As of the variants of the prefix options, I tried to defend them and at >> this point it's a matter of consensus. It's a small piece of code for a >> small value anyway. What we want to keep for sure is the ability to use >> a Home Address from the mobile network. > > > That I agree with. there is an ongoing discussion on removing the explicit prefix length mode. it is issue 20 at http://people.nokia.net/vijayd/nemo/issues.html. IMO, we can remove this mode, since the explicit network mode can used to do whatever you want to do with the explicit prefix length mode. > >>> o Probably makes sense to have just one moboption >>> >>> o It is unclear to me why the MR needs to behave as a >>> (limited form of a) router on the home link, and whether >> >> >> there are >> >>> any implications of this. >> >> >> >> If Home is not using static routes and a MR deregisters, then the routes >> to its prefixes are removed. When at home, the MR has to inject those >> routes in the local IGP by itself or they just do not exist. At least >> one implication is the routing protocol activity (and the temporary >> disruptions) of the Home IGP, associated with MRs registrations and >> deregistrations. > > > Ok. The IGP route argument is compelling. > > The implications I was afraid of were related to a host > becoming a router depending on movement detection results. > I don't have any specific case where this would fail, I > just worried about it. the idea is let the mobile router on its home link behave as it would if it were a fixed router. turning on/off this behavior very much depends on movement detection. I dont see any issue currently though. > >>> o A related issue is in which order do the various >>> things take place? When do you decide you are >>> in the home network and can act as a router, >>> and when do you join various router-related >>> multicast addresses, for instance? >>> >> >> >> Yes, that would be the assumption. I understand that you suggest adding >> more text about that phase, correct? > > > Yes. I will add some text. > >>> o Some error cases are missing. ?? >>> >>> o It probably makes sense to be more explicit about >>> the relationship of this document to MIPv6. Does >>> a MR have to support everything in MIPV6, or just >>> some parts? Or say at least that you MUST support >>> everything... >> >> >> >> Right. In basic mode, the MR does not need to support to be a CN, and RO >> with a CN, since it is not expected to be the end point of most >> conversations. But IMHO, a Nemo HA should fully support MIPv6. Comments >> anyone? > > > Specification-wise it would be easiest to just require full > support. Functionality-wise RO might not be necessary, if the > MR is not sending any packets itself. OTOH RO support is not > a very big burden. it depends on the specific scenario. if a cell phone is a mobile router (which provides connectivity to a laptop and an MP3 device), then it is likely to be a mobile node most of the time. maybe we should should all of MIPv6 (?) > >>> o I'd like understand loop detection better. Or >>> at least why its not required. >>> >> >> >> You mean packets flying back and forth over MRHA? I believe we should >> have text to prevent a HA from putting a packet back on a same MRHA >> tunnel, which is a classical behavior. > > > Here's what I'm thinking: filed this as issue 24 at http://people.nokia.net/vijayd/nemo/issues.html >>> o I don't like the fact that MIPv6 HAs can accept >>> and R=1 registration and no one notices anything. >>> An approach that uses moboptions, even in the >>> response, would probably work smoother. >>> >> >> >> Could you please elaborate? > > > I'm referring to the first paragraph of Section 7. > Remember that according to MIPv6 base spec, unknown > flags are ignored, as are unknown moboptions. One good > way past this is to send one moboption and expect another > one back as an ack that the receiver understood what you > requested; then you know the HA supports NEMO. Alternatively, > you can track a flag value on the Binding Ack. If it comes > back as zero, HA did not support NEMO. > > In nemo, you do neither. Instead you have added a new flag > in DHAAD. That is useful, but I would also handle the BU/BA > in a way that the mobile router becomes certain the home > agent understood what it was being asked to do. > > Does this help explain my issue about the current nemo R=1 > usage? this was discussed earlier. Issues 15 and 16 capture the discussion. the first solution to support inter-working with MIPv6 Home Agents was to add a new binding ack status which says forwarding was setup. MIPv6 Home Agents would return just 0. the second suggestion was to add a flag in the binding ack which would be set to 1 if the Home Agents sets up forwarding for the mobile network. MIPv6 Home Agent would not set this flag. neither of this will work because, the Mobile Router now has to repeatedly try other Home Agents until it gets an indication from a Home Agent that it has set up forwarding. the mobile router also has to deregister with the MIPv6 Home Agent before trying another Home Agent. so modifying DHAAD was the right solution. the mobile router should not have attempted registration with a Home Agent that does not support mobile routers. IMO, a flag in the binding ack is just extra specification and extra code for something that shouldnt have happened. what do you think? Vijay From nemo-admin@ietf.org Mon Dec 1 18:14:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10102 for ; Mon, 1 Dec 2003 18:14: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 1AQxEw-0002jX-Af; Mon, 01 Dec 2003 18: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 1AQxEg-0002is-C4 for nemo@optimus.ietf.org; Mon, 01 Dec 2003 18:13: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 SAA10022 for ; Mon, 1 Dec 2003 18:13:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQxEd-0004zs-00 for nemo@ietf.org; Mon, 01 Dec 2003 18:13:43 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AQxEc-0004zp-00 for nemo@ietf.org; Mon, 01 Dec 2003 18:13:43 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id F0DE66A902; Tue, 2 Dec 2003 01:13:41 +0200 (EET) Message-ID: <3FCBCA18.6010604@kolumbus.fi> Date: Tue, 02 Dec 2003 01:09:12 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] review of the nemo basic spec References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> In-Reply-To: <3FCBC8B5.6030206@iprg.nokia.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: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> I'm referring to the first paragraph of Section 7. >> Remember that according to MIPv6 base spec, unknown >> flags are ignored, as are unknown moboptions. One good >> way past this is to send one moboption and expect another >> one back as an ack that the receiver understood what you >> requested; then you know the HA supports NEMO. Alternatively, >> you can track a flag value on the Binding Ack. If it comes >> back as zero, HA did not support NEMO. >> >> In nemo, you do neither. Instead you have added a new flag >> in DHAAD. That is useful, but I would also handle the BU/BA >> in a way that the mobile router becomes certain the home >> agent understood what it was being asked to do. >> >> Does this help explain my issue about the current nemo R=1 >> usage? > > > this was discussed earlier. Issues 15 and 16 capture the I need to take a look at that, right now its too late (1 am) here for that ;-) > discussion. the first solution to support inter-working with > MIPv6 Home Agents was to add a new binding ack status which > says forwarding was setup. MIPv6 Home Agents would return > just 0. the second suggestion was to add a flag in the binding > ack which would be set to 1 if the Home Agents sets up > forwarding for the mobile network. MIPv6 Home Agent would not > set this flag. neither of this will work because, the Mobile > Router now has to repeatedly try other Home Agents until it > gets an indication from a Home Agent that it has set up > forwarding. the mobile router also has to deregister with the > MIPv6 Home Agent before trying another Home Agent. > > so modifying DHAAD was the right solution. the mobile router > should not have attempted registration with a Home Agent that > does not support mobile routers. > > IMO, a flag in the binding ack is just extra specification and > extra code for something that shouldnt have happened. what do > you think? I think I agree that modifying DHAAD was a good thing to do. WHat I am less sure about is whether that is sufficient. One thing is that I'd rather not do DHAAD at all, if I can avoid it. The second thing is making the decision of what you support local. The HA that responds to a BU certainly knows what it supports; another home agent might not know, for sure, what the other home agents support. Or at least there could be config errors in it. In conclusion, while I agree that DHAAD support is good, it may be necessary to make the BU/BA protocol itself robust enough to survive even mistakes or old information in DHAAD. Does that make sense? --Jari From exim@www1.ietf.org Mon Dec 1 18:14:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10119 for ; Mon, 1 Dec 2003 18:14: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 1AQxEy-0002kd-DI for nemo-archive@odin.ietf.org; Mon, 01 Dec 2003 18:14:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1NE4WN010569 for nemo-archive@odin.ietf.org; Mon, 1 Dec 2003 18:14:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQxEy-0002kO-8U for nemo-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 18:14: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 SAA10059 for ; Mon, 1 Dec 2003 18:13:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQxEv-00050O-00 for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 18:14:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQxEv-00050K-00 for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 18:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQxEw-0002jX-Af; Mon, 01 Dec 2003 18: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 1AQxEg-0002is-C4 for nemo@optimus.ietf.org; Mon, 01 Dec 2003 18:13: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 SAA10022 for ; Mon, 1 Dec 2003 18:13:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQxEd-0004zs-00 for nemo@ietf.org; Mon, 01 Dec 2003 18:13:43 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AQxEc-0004zp-00 for nemo@ietf.org; Mon, 01 Dec 2003 18:13:43 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id F0DE66A902; Tue, 2 Dec 2003 01:13:41 +0200 (EET) Message-ID: <3FCBCA18.6010604@kolumbus.fi> Date: Tue, 02 Dec 2003 01:09:12 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] review of the nemo basic spec References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> In-Reply-To: <3FCBC8B5.6030206@iprg.nokia.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> I'm referring to the first paragraph of Section 7. >> Remember that according to MIPv6 base spec, unknown >> flags are ignored, as are unknown moboptions. One good >> way past this is to send one moboption and expect another >> one back as an ack that the receiver understood what you >> requested; then you know the HA supports NEMO. Alternatively, >> you can track a flag value on the Binding Ack. If it comes >> back as zero, HA did not support NEMO. >> >> In nemo, you do neither. Instead you have added a new flag >> in DHAAD. That is useful, but I would also handle the BU/BA >> in a way that the mobile router becomes certain the home >> agent understood what it was being asked to do. >> >> Does this help explain my issue about the current nemo R=1 >> usage? > > > this was discussed earlier. Issues 15 and 16 capture the I need to take a look at that, right now its too late (1 am) here for that ;-) > discussion. the first solution to support inter-working with > MIPv6 Home Agents was to add a new binding ack status which > says forwarding was setup. MIPv6 Home Agents would return > just 0. the second suggestion was to add a flag in the binding > ack which would be set to 1 if the Home Agents sets up > forwarding for the mobile network. MIPv6 Home Agent would not > set this flag. neither of this will work because, the Mobile > Router now has to repeatedly try other Home Agents until it > gets an indication from a Home Agent that it has set up > forwarding. the mobile router also has to deregister with the > MIPv6 Home Agent before trying another Home Agent. > > so modifying DHAAD was the right solution. the mobile router > should not have attempted registration with a Home Agent that > does not support mobile routers. > > IMO, a flag in the binding ack is just extra specification and > extra code for something that shouldnt have happened. what do > you think? I think I agree that modifying DHAAD was a good thing to do. WHat I am less sure about is whether that is sufficient. One thing is that I'd rather not do DHAAD at all, if I can avoid it. The second thing is making the decision of what you support local. The HA that responds to a BU certainly knows what it supports; another home agent might not know, for sure, what the other home agents support. Or at least there could be config errors in it. In conclusion, while I agree that DHAAD support is good, it may be necessary to make the BU/BA protocol itself robust enough to survive even mistakes or old information in DHAAD. Does that make sense? --Jari From nemo-admin@ietf.org Mon Dec 1 21:03:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16197 for ; Mon, 1 Dec 2003 21:03:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQzsT-0003oX-JY; Mon, 01 Dec 2003 21:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQzsC-0003oG-IW for nemo@optimus.ietf.org; Mon, 01 Dec 2003 21:02: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 VAA16180 for ; Mon, 1 Dec 2003 21:02:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQzsA-0007JM-00 for nemo@ietf.org; Mon, 01 Dec 2003 21:02:42 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AQzs9-0007IX-00 for nemo@ietf.org; Mon, 01 Dec 2003 21:02:41 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB2226000411; Mon, 1 Dec 2003 18:02:06 -0800 X-mProtect: <200312020202> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdjBhXrM; Mon, 01 Dec 2003 18:02:05 PST Message-ID: <3FCBF3DE.7050202@iprg.nokia.com> Date: Mon, 01 Dec 2003 18:07:26 -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: Jari Arkko , nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Editorial comments from Jari Arkko Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 Jari, thanks for the detailed review. > Network Mobility (NEMO) Basic Support Protocol > > JARI: Why "Basic Support"? Wouldn't Network Mobility Base > Protocol be a sufficient name for this? > well, the term was in use before this draft was written. infact it is used in the charter. "Extended Support" talks about route optimization for the nodes in the mobile network. the WG has a charter item to look into Extended Support and define requirements. > JARI: I think LFNs can be complete mobility-unaware, I think you > should mention this upfront as one of the benefits. LFNs by definition are nodes which are not mobility aware. they are fixed nodes. we already mention this once in the abstract itself. The protocol is designed in such a way that network mobility is transparent to the nodes inside the mobile network. > JARI: Hmm... there might be value in defining the terms in a self-contained > manner here. I'm pretty sure you only use a subset of [8] terms, > so it wouldn't be that long. I also believe in a document being self contained when it comes to terminology. but there is a separate WG document on NEMO terminology that is being advanced as an informational RFC. so I am not sure. > Prefix Table > > It is a list of a Mobile Network Prefixes indexed > by the Home Address of a Mobile Router. The prefix table > is managed by the Home Agent and is used by the Home Agent > to determine which Mobile Network Prefixes are owned > a particular Mobile Router. This is an optional data > structure. > > JARI: Really? Why is it optional? Sounds mandatory to me... well, there could be scenarios where the mobile routers are not expected to misbehave. and there could be other ways for verifying this. so we left it optional. I dont mind making it mandatory. > A Mobile Network is a network segment or subnet which can move > and attach to arbitrary points in the Internet. A Mobile Network > does not allow any transit traffic and can only be accessed via > specific gateways called Mobile Routers that manage its movement. > > JARI: The above is a bit unclear. I think you mean that the > nodes behind the MR can't access the internet directly, they > have to go through the MR and the HA. actually no. it means traffic to the Mobile Network can reach the Mobile Network only through mobile routers. it also says mobile networks are not transit networks. always stub networks. > JARI: Question: is the prefix for a MR always unique? This seems unclear. > Can other MRs have the same prefix, can the HA have the same > prefix as the MR? > more than one MR can be assigned a prefix. one can imagine having two routers for the same mobile network. the HA will probably not have the same prefix as the MR. > JARI: Come to think of it, both the MR and the HA must know the > assigned prefixes beforehand in any case, so I wonder if we > need to communicate the prefixes at all?!? Can you cite an > example where the HA would give a prefix to the MR without > knowing it belongs to it? Or is the idea to prepare for the > eventual bootstrapping support in MIPv6? well, we still havent figured out how to do prefix delegation to a mobile router. there is a draft by Ralph Droms on extending DHCPv6 prefix delegation for NEMO. not a WG draft yet. and there is this scenario, where the mobile router is delegated more than prefix, but it could decide to setup forwarding for just one prefix instead of all prefixes. this cant be dont without carrying prefix information in the Binding Update. > JARI: So, presumably this includes forwarding of packets to > the MR's own home address under all these prefixes, no? > If so, I think we have the S=0 bit functionality when you > set R=1 ;-) :) only if the mobile router has configured all its home addresses from its MNPs. > JARI: Is there something that you would perhaps like to > reference from MIPv6 regarding this tunneling, or is [3] enough? > why? are we missing something. > Finally, the Home Agent may be configured with static routes to the > Mobile Network Prefix via the Mobile Router's Home Address. In that > case, the routes are set independently of the binding flows and the > returning Home of a Mobile Router. The benefit is that such movement > does not induce any additional signalling in the form of routing > updates in the Home Network. The drawback of that model is that the > routes are present even if the related Mobile Routers that are not > reachable (at Home or bound) at a given point of time. > > > JARI: This is only a drawback if the routes would be reachable somewhere > else. Given the desire to keep the Internet routing pretty > stable, I would argue that we shouldn't be moving routes all > over the place. Hence it would be sufficient if the routes > were on one place only. well, its a drawback in the sense, the Home Agent has routing table entries even though the mobile router is currently dormant or just disconnected. > JARI: What happens in the statically configured route case if R=0? > Reading on... there are two static cases. 1. implicit mode 2. dynamic routing protocol updates which one are you referring to? > This document introduces a new Prefix Information field in the > Binding Update list structure. This field is used to store any > prefix information that the Mobile Router includes in the Binding > Update. If the Mobile Router sets the Mobile Router flag 'R' in the > Binding Update, but does not include any prefix information in it > (implicit mode), this field is set to null. > > JARI: So, if you run a routing protocol over the tunnel, will this > information be updated in the BUL as well? I think its not needed when a routing protocol is being run. > If the Binding Acknowlegement status is set to '0' (Binding Update > > JARI: I don't understand this vs. what you are saying above in Section > 5.3. What is the issue? Is it perhaps that due to your rules, > you can do an R registration without a single moboption and > hence the HA does not recognize that it doesn't support R? If > so, you should require your moboptions to be always present... > > accepted), the Mobile Router concludes that the Home Agent which > processed the Binding Update is a MIPv6 Home Agent that has not > implemented support for Mobile Routers. It should send a similar > Binding Update to another Home Agent on the link. If no Home Agent > replies positively then the Mobile Router MUST refrain from sending > any Binding Update with the Mobile Router flag set to any home agent > on the home link and log the information. > > JARI: Hmm... forever? actually this whole paragraph needs to be removed. it is left over text from previous edits. my mistake. > A Mobile Router MAY limit the number of mobile routers that attach to > its mobile network (the number of levels in the nested aggregation) > by means of setting the Tunnel Encapsulation Limit field of the > Tunnel Encapsulation option. > > JARI: So what happens if there is a loop? A packet that you send > travels through the loop until the encapsulation limit > is reached? Or is there some other defense? > I guess this is related to your issue on loop detection. I will add this to issue 24. > 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. > > JARI: I wonder if the above paragraph could be replaced with > some reference to ND specs. As far as I can see, an MR should > follow ND rules on its egress interface when on a visited > network. > if you go by ND specs, routers ignore router advertisements. we are infact saying router advertisements MUST NOT be ignored. > In some deployment scenarios it may be necessary for the Home Agent > to prevent a misbehaving Mobile Router from claiming mobile network > prefixes belonging to another Mobile Router. The Home Agent can > prevent such attacks if it maintains a Prefix Table and verifies the > Prefix Information provided by the Mobile Router against the entries > in the Prefix Table. However, this verification is done only if the > Binding Update contained explicit prefix information in the form of > either the Mobile Network Prefix Option or the Mobile Network Prefix > Length Option. > > JARI: I think that verification could also be done at the routing > protocol case, assuming the HA can link the virtual interface > and the corresponding MR together. > we assume routing protocols have their own mechanism for verifying the routing information sent by a router. so we did not recommend anything in the routing protocol case. > - The Home Registration (H) flag MUST be set. If not, the > > JARI: Use 'H' instead of (H) MIPv6 spec uses (H). :) > JARI: Is it possible to go from a "R=1" BCE to an "R=0" BCE in > some manner? Or only deleting the BCE and registering > again? the mobile router has to de-register and then register again. > The establishment and operation of the bi-directional tunnel is > implementation specific. However, all implementations MUST be > capable of the following operations. > > JARI: What does it mean that its implementation specific? What > specifically would you have to do to establish the tunnel > in the first place? Why can't this be specified? setting up and using tunnels is implementation specific. some people like to set them up as virtual interfaces. sometimes it is just code in the IP stack. > The Home Agent either uses only the routing > table, only the Binding Cache or a combination of routing table > and Binding Cache to route packets to the mobile network. This is > implementation specific. Two examples are shown below. > > JARI: You are presenting the rules in a too implementation-near > form. Perhaps you could formulate something general > that has a MUST. > there is a problem with it. the binding cache is a conceptual data structure. sometimes it is just implemented as a routing table entry. one implementation (of mobile routers), I know, uses the binding cache for both routing and CoA lookup. so we left it implementation specific. and we present two ways of doing it. we had a long discussion on using the binding cache or routing table for the HA to forward packets to the mobile network. this discussion happened before this draft was written up. > In the solution described so far, forwarding to the Mobile Network > at the Home Agent is set up when the Home Agent receives a Binding > Update from the Mobile Router. An alternative to this is for the > Home Agent and the Mobile Router to run an intra-domain routing > protocol like RIPng [10] and OSPF [11] through the bi-directional > tunnel. The Mobile Router can continue running the same routing > protocol that it was running when it was attached to the home link. > > This feature is very useful when the Mobile Network is large with > multiple subnets containing different IPv6 prefixes. Routing changes > > JARI: Can you give a practical example of where this could be the > case? I can't think of any, but maybe its just me... it could happen when there are multiple mobile networks attached to the mobile router, each one having different prefix, but want routing enabled for all these prefixes through the Home Agent. using a routing protocol makes sense here. > Since the routing protocol messages from the Home Agent to the Mobile > Router could potentically contain information about the internal > routing structure of the home network, these messages require > authentications and confidentiality protection. Confidentialy > protection using IPsec ESP [4] in tunnel mode MUST be supported and > SHOULD be used. > > > JARI: It might be necessary to have some more detail about this. > What kind of SPD entries are needed etc. should be straight forward. OSPFv3 and RIPng use specific transport protocols and ports. for example the SPD entry on the mobile router would say "if routing protocol message with destination=HA, use a particular SA which would do tunnel mode ESP". your other suggestions were accepted. Vijay From exim@www1.ietf.org Mon Dec 1 21:03:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16212 for ; Mon, 1 Dec 2003 21:03: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 1AQzsc-0003pY-Fq for nemo-archive@odin.ietf.org; Mon, 01 Dec 2003 21:03:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB223A2p014718 for nemo-archive@odin.ietf.org; Mon, 1 Dec 2003 21:03:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQzsc-0003pJ-B0 for nemo-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 21:03: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 VAA16186 for ; Mon, 1 Dec 2003 21:02:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQzsZ-0007JS-00 for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 21:03:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQzsZ-0007JP-00 for nemo-web-archive@ietf.org; Mon, 01 Dec 2003 21:03:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQzsT-0003oX-JY; Mon, 01 Dec 2003 21:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQzsC-0003oG-IW for nemo@optimus.ietf.org; Mon, 01 Dec 2003 21:02: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 VAA16180 for ; Mon, 1 Dec 2003 21:02:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQzsA-0007JM-00 for nemo@ietf.org; Mon, 01 Dec 2003 21:02:42 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AQzs9-0007IX-00 for nemo@ietf.org; Mon, 01 Dec 2003 21:02:41 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB2226000411; Mon, 1 Dec 2003 18:02:06 -0800 X-mProtect: <200312020202> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdjBhXrM; Mon, 01 Dec 2003 18:02:05 PST Message-ID: <3FCBF3DE.7050202@iprg.nokia.com> Date: Mon, 01 Dec 2003 18:07:26 -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: Jari Arkko , nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Editorial comments from Jari Arkko Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Jari, thanks for the detailed review. > Network Mobility (NEMO) Basic Support Protocol > > JARI: Why "Basic Support"? Wouldn't Network Mobility Base > Protocol be a sufficient name for this? > well, the term was in use before this draft was written. infact it is used in the charter. "Extended Support" talks about route optimization for the nodes in the mobile network. the WG has a charter item to look into Extended Support and define requirements. > JARI: I think LFNs can be complete mobility-unaware, I think you > should mention this upfront as one of the benefits. LFNs by definition are nodes which are not mobility aware. they are fixed nodes. we already mention this once in the abstract itself. The protocol is designed in such a way that network mobility is transparent to the nodes inside the mobile network. > JARI: Hmm... there might be value in defining the terms in a self-contained > manner here. I'm pretty sure you only use a subset of [8] terms, > so it wouldn't be that long. I also believe in a document being self contained when it comes to terminology. but there is a separate WG document on NEMO terminology that is being advanced as an informational RFC. so I am not sure. > Prefix Table > > It is a list of a Mobile Network Prefixes indexed > by the Home Address of a Mobile Router. The prefix table > is managed by the Home Agent and is used by the Home Agent > to determine which Mobile Network Prefixes are owned > a particular Mobile Router. This is an optional data > structure. > > JARI: Really? Why is it optional? Sounds mandatory to me... well, there could be scenarios where the mobile routers are not expected to misbehave. and there could be other ways for verifying this. so we left it optional. I dont mind making it mandatory. > A Mobile Network is a network segment or subnet which can move > and attach to arbitrary points in the Internet. A Mobile Network > does not allow any transit traffic and can only be accessed via > specific gateways called Mobile Routers that manage its movement. > > JARI: The above is a bit unclear. I think you mean that the > nodes behind the MR can't access the internet directly, they > have to go through the MR and the HA. actually no. it means traffic to the Mobile Network can reach the Mobile Network only through mobile routers. it also says mobile networks are not transit networks. always stub networks. > JARI: Question: is the prefix for a MR always unique? This seems unclear. > Can other MRs have the same prefix, can the HA have the same > prefix as the MR? > more than one MR can be assigned a prefix. one can imagine having two routers for the same mobile network. the HA will probably not have the same prefix as the MR. > JARI: Come to think of it, both the MR and the HA must know the > assigned prefixes beforehand in any case, so I wonder if we > need to communicate the prefixes at all?!? Can you cite an > example where the HA would give a prefix to the MR without > knowing it belongs to it? Or is the idea to prepare for the > eventual bootstrapping support in MIPv6? well, we still havent figured out how to do prefix delegation to a mobile router. there is a draft by Ralph Droms on extending DHCPv6 prefix delegation for NEMO. not a WG draft yet. and there is this scenario, where the mobile router is delegated more than prefix, but it could decide to setup forwarding for just one prefix instead of all prefixes. this cant be dont without carrying prefix information in the Binding Update. > JARI: So, presumably this includes forwarding of packets to > the MR's own home address under all these prefixes, no? > If so, I think we have the S=0 bit functionality when you > set R=1 ;-) :) only if the mobile router has configured all its home addresses from its MNPs. > JARI: Is there something that you would perhaps like to > reference from MIPv6 regarding this tunneling, or is [3] enough? > why? are we missing something. > Finally, the Home Agent may be configured with static routes to the > Mobile Network Prefix via the Mobile Router's Home Address. In that > case, the routes are set independently of the binding flows and the > returning Home of a Mobile Router. The benefit is that such movement > does not induce any additional signalling in the form of routing > updates in the Home Network. The drawback of that model is that the > routes are present even if the related Mobile Routers that are not > reachable (at Home or bound) at a given point of time. > > > JARI: This is only a drawback if the routes would be reachable somewhere > else. Given the desire to keep the Internet routing pretty > stable, I would argue that we shouldn't be moving routes all > over the place. Hence it would be sufficient if the routes > were on one place only. well, its a drawback in the sense, the Home Agent has routing table entries even though the mobile router is currently dormant or just disconnected. > JARI: What happens in the statically configured route case if R=0? > Reading on... there are two static cases. 1. implicit mode 2. dynamic routing protocol updates which one are you referring to? > This document introduces a new Prefix Information field in the > Binding Update list structure. This field is used to store any > prefix information that the Mobile Router includes in the Binding > Update. If the Mobile Router sets the Mobile Router flag 'R' in the > Binding Update, but does not include any prefix information in it > (implicit mode), this field is set to null. > > JARI: So, if you run a routing protocol over the tunnel, will this > information be updated in the BUL as well? I think its not needed when a routing protocol is being run. > If the Binding Acknowlegement status is set to '0' (Binding Update > > JARI: I don't understand this vs. what you are saying above in Section > 5.3. What is the issue? Is it perhaps that due to your rules, > you can do an R registration without a single moboption and > hence the HA does not recognize that it doesn't support R? If > so, you should require your moboptions to be always present... > > accepted), the Mobile Router concludes that the Home Agent which > processed the Binding Update is a MIPv6 Home Agent that has not > implemented support for Mobile Routers. It should send a similar > Binding Update to another Home Agent on the link. If no Home Agent > replies positively then the Mobile Router MUST refrain from sending > any Binding Update with the Mobile Router flag set to any home agent > on the home link and log the information. > > JARI: Hmm... forever? actually this whole paragraph needs to be removed. it is left over text from previous edits. my mistake. > A Mobile Router MAY limit the number of mobile routers that attach to > its mobile network (the number of levels in the nested aggregation) > by means of setting the Tunnel Encapsulation Limit field of the > Tunnel Encapsulation option. > > JARI: So what happens if there is a loop? A packet that you send > travels through the loop until the encapsulation limit > is reached? Or is there some other defense? > I guess this is related to your issue on loop detection. I will add this to issue 24. > 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. > > JARI: I wonder if the above paragraph could be replaced with > some reference to ND specs. As far as I can see, an MR should > follow ND rules on its egress interface when on a visited > network. > if you go by ND specs, routers ignore router advertisements. we are infact saying router advertisements MUST NOT be ignored. > In some deployment scenarios it may be necessary for the Home Agent > to prevent a misbehaving Mobile Router from claiming mobile network > prefixes belonging to another Mobile Router. The Home Agent can > prevent such attacks if it maintains a Prefix Table and verifies the > Prefix Information provided by the Mobile Router against the entries > in the Prefix Table. However, this verification is done only if the > Binding Update contained explicit prefix information in the form of > either the Mobile Network Prefix Option or the Mobile Network Prefix > Length Option. > > JARI: I think that verification could also be done at the routing > protocol case, assuming the HA can link the virtual interface > and the corresponding MR together. > we assume routing protocols have their own mechanism for verifying the routing information sent by a router. so we did not recommend anything in the routing protocol case. > - The Home Registration (H) flag MUST be set. If not, the > > JARI: Use 'H' instead of (H) MIPv6 spec uses (H). :) > JARI: Is it possible to go from a "R=1" BCE to an "R=0" BCE in > some manner? Or only deleting the BCE and registering > again? the mobile router has to de-register and then register again. > The establishment and operation of the bi-directional tunnel is > implementation specific. However, all implementations MUST be > capable of the following operations. > > JARI: What does it mean that its implementation specific? What > specifically would you have to do to establish the tunnel > in the first place? Why can't this be specified? setting up and using tunnels is implementation specific. some people like to set them up as virtual interfaces. sometimes it is just code in the IP stack. > The Home Agent either uses only the routing > table, only the Binding Cache or a combination of routing table > and Binding Cache to route packets to the mobile network. This is > implementation specific. Two examples are shown below. > > JARI: You are presenting the rules in a too implementation-near > form. Perhaps you could formulate something general > that has a MUST. > there is a problem with it. the binding cache is a conceptual data structure. sometimes it is just implemented as a routing table entry. one implementation (of mobile routers), I know, uses the binding cache for both routing and CoA lookup. so we left it implementation specific. and we present two ways of doing it. we had a long discussion on using the binding cache or routing table for the HA to forward packets to the mobile network. this discussion happened before this draft was written up. > In the solution described so far, forwarding to the Mobile Network > at the Home Agent is set up when the Home Agent receives a Binding > Update from the Mobile Router. An alternative to this is for the > Home Agent and the Mobile Router to run an intra-domain routing > protocol like RIPng [10] and OSPF [11] through the bi-directional > tunnel. The Mobile Router can continue running the same routing > protocol that it was running when it was attached to the home link. > > This feature is very useful when the Mobile Network is large with > multiple subnets containing different IPv6 prefixes. Routing changes > > JARI: Can you give a practical example of where this could be the > case? I can't think of any, but maybe its just me... it could happen when there are multiple mobile networks attached to the mobile router, each one having different prefix, but want routing enabled for all these prefixes through the Home Agent. using a routing protocol makes sense here. > Since the routing protocol messages from the Home Agent to the Mobile > Router could potentically contain information about the internal > routing structure of the home network, these messages require > authentications and confidentiality protection. Confidentialy > protection using IPsec ESP [4] in tunnel mode MUST be supported and > SHOULD be used. > > > JARI: It might be necessary to have some more detail about this. > What kind of SPD entries are needed etc. should be straight forward. OSPFv3 and RIPng use specific transport protocols and ports. for example the SPD entry on the mobile router would say "if routing protocol message with destination=HA, use a particular SA which would do tunnel mode ESP". your other suggestions were accepted. Vijay From nemo-admin@ietf.org Tue Dec 2 03:06:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07718 for ; Tue, 2 Dec 2003 03:06: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 1AR5Xl-0001B2-Sb; Tue, 02 Dec 2003 03: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 1AR5Ww-00019x-5F for nemo@optimus.ietf.org; Tue, 02 Dec 2003 03:05: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 DAA07672 for ; Tue, 2 Dec 2003 03:04:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR5Ws-0003F5-00 for nemo@ietf.org; Tue, 02 Dec 2003 03:05:06 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AR5Wr-0003ED-00 for nemo@ietf.org; Tue, 02 Dec 2003 03:05:05 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB284O905302; Tue, 2 Dec 2003 00:04:24 -0800 X-mProtect: <200312020804> Nokia Silicon Valley Messaging Protection Received: from danira-pool055125.americas.nokia.com (10.241.55.125, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQE3kmb; Tue, 02 Dec 2003 00:04:23 PST Message-ID: <3FCC477B.8030507@iprg.nokia.com> Date: Tue, 02 Dec 2003 00:04:11 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] review of the nemo basic spec References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCBCA18.6010604@kolumbus.fi> In-Reply-To: <3FCBCA18.6010604@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I think I agree that modifying DHAAD was a good thing to > do. WHat I am less sure about is whether that is sufficient. > One thing is that I'd rather not do DHAAD at all, if I can avoid > it. okay. apart from DHAAD and manual configuration, how else is the mobile router assigned a Home Agent? > The second thing is making the decision of what you support > local. The HA that responds to a BU certainly knows what > it supports; another home agent might not know, for sure, > what the other home agents support. Or at least there could > be config errors in it. In conclusion, while I agree that > DHAAD support is good, it may be necessary to make the > BU/BA protocol itself robust enough to survive even > mistakes or old information in DHAAD. Does that make > sense? I am not disagreeing with this. a flag in the binding ack which says the Home Agent has setup forwarding for the mobile network will do what you want. the question I have, is this extra specification worth it for what I consider a corner case (a configuration error)? Vijay From exim@www1.ietf.org Tue Dec 2 03:06:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07733 for ; Tue, 2 Dec 2003 03:06: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 1AR5Xu-0001CW-Ae for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 03:06:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB28692F004612 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 03:06:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR5Xt-0001CJ-PG for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 03:06: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 DAA07707 for ; Tue, 2 Dec 2003 03:05:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR5Xp-0003Fy-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 03:06:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR5Xp-0003Fv-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 03:06:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR5Xl-0001B2-Sb; Tue, 02 Dec 2003 03: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 1AR5Ww-00019x-5F for nemo@optimus.ietf.org; Tue, 02 Dec 2003 03:05: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 DAA07672 for ; Tue, 2 Dec 2003 03:04:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR5Ws-0003F5-00 for nemo@ietf.org; Tue, 02 Dec 2003 03:05:06 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AR5Wr-0003ED-00 for nemo@ietf.org; Tue, 02 Dec 2003 03:05:05 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB284O905302; Tue, 2 Dec 2003 00:04:24 -0800 X-mProtect: <200312020804> Nokia Silicon Valley Messaging Protection Received: from danira-pool055125.americas.nokia.com (10.241.55.125, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQE3kmb; Tue, 02 Dec 2003 00:04:23 PST Message-ID: <3FCC477B.8030507@iprg.nokia.com> Date: Tue, 02 Dec 2003 00:04:11 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] review of the nemo basic spec References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCBCA18.6010604@kolumbus.fi> In-Reply-To: <3FCBCA18.6010604@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I think I agree that modifying DHAAD was a good thing to > do. WHat I am less sure about is whether that is sufficient. > One thing is that I'd rather not do DHAAD at all, if I can avoid > it. okay. apart from DHAAD and manual configuration, how else is the mobile router assigned a Home Agent? > The second thing is making the decision of what you support > local. The HA that responds to a BU certainly knows what > it supports; another home agent might not know, for sure, > what the other home agents support. Or at least there could > be config errors in it. In conclusion, while I agree that > DHAAD support is good, it may be necessary to make the > BU/BA protocol itself robust enough to survive even > mistakes or old information in DHAAD. Does that make > sense? I am not disagreeing with this. a flag in the binding ack which says the Home Agent has setup forwarding for the mobile network will do what you want. the question I have, is this extra specification worth it for what I consider a corner case (a configuration error)? Vijay From nemo-admin@ietf.org Tue Dec 2 03:45:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08462 for ; Tue, 2 Dec 2003 03: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 1AR69V-0003G3-6k; Tue, 02 Dec 2003 03:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR692-0003FM-DO for nemo@optimus.ietf.org; Tue, 02 Dec 2003 03:44: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 DAA08414 for ; Tue, 2 Dec 2003 03:44:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR68z-0003al-00 for nemo@ietf.org; Tue, 02 Dec 2003 03:44:29 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AR68z-0003a7-00 for nemo@ietf.org; Tue, 02 Dec 2003 03:44:29 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Dec 2003 09:41:13 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB28hkc4019489; Tue, 2 Dec 2003 09:43:46 +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); Tue, 2 Dec 2003 08:43:59 +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 Subject: Issue 24 (was RE: [nemo] review of the nemo basic spec) Date: Tue, 2 Dec 2003 08:43:58 -0000 Message-ID: Thread-Topic: Issue 24 (was RE: [nemo] review of the nemo basic spec) Thread-Index: AcO4U2H813278szRQxGzRePKGgSbygAU9auA From: "Pascal Thubert (pthubert)" To: "Jari Arkko" Cc: X-OriginalArrivalTime: 02 Dec 2003 08:43:59.0055 (UTC) FILETIME=[6DB095F0:01C3B8B0] 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 > Here's what I'm thinking: >=20 > Step 1. > MR1 -> MR2 -> MR3 ---> Fixed Network ---> HA >=20 >=20 >=20 > Step 2. > _---> Fixed Network ---> HA > / > +---> MR1 -> MR2 -> MR3 ---+ > | | > +--------------------------+ >=20 >=20 > Step 3. >=20 > +---> MR1 -> MR2 -> MR3 ---+ > | | > +--------------------------+ >=20 > That is, an MR3 is attached to a fixed network and communicates > with its HA. There are nested MRs, MR1 and MR2. Now, MR3 sees MR1 > advertising access with a better signal strenght, and thinks > incorrectly that it would be a good idea to attach to it. So > it decides to attach to MR1 instead. However, MR3 keeps its old > attachment running until it has completed the attachment to MR1; > this implies the BU it sends via MR1 gets routed back to itself > in a tunnel, and actually gets to the home agent via the > still operational fixed attachment. But after the BA comes back, > MR3 detaches itself from the fixed network. As a result, we > have a loop and no connectivity. Now try to send a data packet. >=20 > I would like to understand why this is not a problem. > I'm sure I'm missing something obvious. >=20 You're not :) Short answer is that it's heavily linked to Nemo Route Optimization (more in 2.1 Nested Tunnels Optimization in http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-01.tx t) and that we ruled that out of scope for basic (thus its name :). With basic, we address a MR connected to an AR, but do not detail AR selection, and do not enable automatic navigation within a cloud of mobile routers.=20 Long answer: Actually it's a question Steve Deering raised at the time Nemo was still a BOF, and that we spent quite some time discussing together before that, when I described to him our Reverse Routing Header technology, that we published (IPR free :) at that time (now http://www.ietf.org/internet-drafts/draft-thubert-nemo-reverse-routing-h eader-03.txt). The Nested Tunnel RO somehow manages the path between a MR and a fixed AR via other MRs. An example of that is nested MRs forming a MANET. At this time, the Nemo WG is chartered to study that problem but not to write up a normative document on its solution. On the side, note that as long as MRs form a single CareOf each, when MRs attach to MRs in a loopless fashion, they form a tree, ideal for bridging and multicasting. In RRH, we propose an extension to ND RA (called Tree Information Option, RATIO) that enables loop prevention, and provides metrics for AR selection.=20 The minimum information we need from that TIO to prevent loops is the ID of the root (top level) mobile router and a metric, like the tree depth. Rules for loopless AR selection: - A MR that is not attached to a tree is root (either attached to a fixed AR or floating). A root MR may attach to any tree for which it is not root. - A MR that is attached to a tree may jump to a different tree (root id is different) or to the same tree at a better metric. - A MR will jump proactively in order to improve its metric. A MR will jump reactively when its current attachment is not reachable anymore. One consequence of these rules is that if movement detection finds that the current attachment is not reachable anymore, and that only MRs in the same tree with a worse metric are visible, then, following the second rule, the MR can not reattach. So it becomes root and reinitiates a RATIO. That RATIO is propagated down our MR subtree so that 2 trees are now in existence. Our MR may now reattach to the previous tree, following the first rule. There's a bit more to it, but that's the idea. A DV technique to form a virtual L2 tree. Once you've formed trees that are optimized for your metrics, you may want to populate that tree with prefixes, and set up local routing. As you see, this discussion may lead quite far. IMHO, it's fair that basic cuts short and does not open the Pandora box. Pascal From exim@www1.ietf.org Tue Dec 2 03:45:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08477 for ; Tue, 2 Dec 2003 03:45: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 1AR69f-0003HF-I9 for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 03:45:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB28jBnE012598 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 03:45:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR69f-0003H7-3n for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 03:45:11 -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 DAA08430 for ; Tue, 2 Dec 2003 03:44:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR69c-0003bB-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 03:45:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR69c-0003b8-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 03:45:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR69V-0003G3-6k; Tue, 02 Dec 2003 03:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR692-0003FM-DO for nemo@optimus.ietf.org; Tue, 02 Dec 2003 03:44: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 DAA08414 for ; Tue, 2 Dec 2003 03:44:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR68z-0003al-00 for nemo@ietf.org; Tue, 02 Dec 2003 03:44:29 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AR68z-0003a7-00 for nemo@ietf.org; Tue, 02 Dec 2003 03:44:29 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Dec 2003 09:41:13 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB28hkc4019489; Tue, 2 Dec 2003 09:43:46 +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); Tue, 2 Dec 2003 08:43:59 +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 Subject: Issue 24 (was RE: [nemo] review of the nemo basic spec) Date: Tue, 2 Dec 2003 08:43:58 -0000 Message-ID: Thread-Topic: Issue 24 (was RE: [nemo] review of the nemo basic spec) Thread-Index: AcO4U2H813278szRQxGzRePKGgSbygAU9auA From: "Pascal Thubert (pthubert)" To: "Jari Arkko" Cc: X-OriginalArrivalTime: 02 Dec 2003 08:43:59.0055 (UTC) FILETIME=[6DB095F0:01C3B8B0] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > Here's what I'm thinking: >=20 > Step 1. > MR1 -> MR2 -> MR3 ---> Fixed Network ---> HA >=20 >=20 >=20 > Step 2. > _---> Fixed Network ---> HA > / > +---> MR1 -> MR2 -> MR3 ---+ > | | > +--------------------------+ >=20 >=20 > Step 3. >=20 > +---> MR1 -> MR2 -> MR3 ---+ > | | > +--------------------------+ >=20 > That is, an MR3 is attached to a fixed network and communicates > with its HA. There are nested MRs, MR1 and MR2. Now, MR3 sees MR1 > advertising access with a better signal strenght, and thinks > incorrectly that it would be a good idea to attach to it. So > it decides to attach to MR1 instead. However, MR3 keeps its old > attachment running until it has completed the attachment to MR1; > this implies the BU it sends via MR1 gets routed back to itself > in a tunnel, and actually gets to the home agent via the > still operational fixed attachment. But after the BA comes back, > MR3 detaches itself from the fixed network. As a result, we > have a loop and no connectivity. Now try to send a data packet. >=20 > I would like to understand why this is not a problem. > I'm sure I'm missing something obvious. >=20 You're not :) Short answer is that it's heavily linked to Nemo Route Optimization (more in 2.1 Nested Tunnels Optimization in http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-01.tx t) and that we ruled that out of scope for basic (thus its name :). With basic, we address a MR connected to an AR, but do not detail AR selection, and do not enable automatic navigation within a cloud of mobile routers.=20 Long answer: Actually it's a question Steve Deering raised at the time Nemo was still a BOF, and that we spent quite some time discussing together before that, when I described to him our Reverse Routing Header technology, that we published (IPR free :) at that time (now http://www.ietf.org/internet-drafts/draft-thubert-nemo-reverse-routing-h eader-03.txt). The Nested Tunnel RO somehow manages the path between a MR and a fixed AR via other MRs. An example of that is nested MRs forming a MANET. At this time, the Nemo WG is chartered to study that problem but not to write up a normative document on its solution. On the side, note that as long as MRs form a single CareOf each, when MRs attach to MRs in a loopless fashion, they form a tree, ideal for bridging and multicasting. In RRH, we propose an extension to ND RA (called Tree Information Option, RATIO) that enables loop prevention, and provides metrics for AR selection.=20 The minimum information we need from that TIO to prevent loops is the ID of the root (top level) mobile router and a metric, like the tree depth. Rules for loopless AR selection: - A MR that is not attached to a tree is root (either attached to a fixed AR or floating). A root MR may attach to any tree for which it is not root. - A MR that is attached to a tree may jump to a different tree (root id is different) or to the same tree at a better metric. - A MR will jump proactively in order to improve its metric. A MR will jump reactively when its current attachment is not reachable anymore. One consequence of these rules is that if movement detection finds that the current attachment is not reachable anymore, and that only MRs in the same tree with a worse metric are visible, then, following the second rule, the MR can not reattach. So it becomes root and reinitiates a RATIO. That RATIO is propagated down our MR subtree so that 2 trees are now in existence. Our MR may now reattach to the previous tree, following the first rule. There's a bit more to it, but that's the idea. A DV technique to form a virtual L2 tree. Once you've formed trees that are optimized for your metrics, you may want to populate that tree with prefixes, and set up local routing. As you see, this discussion may lead quite far. IMHO, it's fair that basic cuts short and does not open the Pandora box. Pascal From nemo-admin@ietf.org Tue Dec 2 04:27:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09514 for ; Tue, 2 Dec 2003 04:27:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6o9-0005Fi-34; Tue, 02 Dec 2003 04:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6nB-0005EU-Lu for nemo@optimus.ietf.org; Tue, 02 Dec 2003 04:26: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 EAA09490 for ; Tue, 2 Dec 2003 04:25:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6n8-00041X-00 for nemo@ietf.org; Tue, 02 Dec 2003 04:25:58 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AR6n8-00041L-00 for nemo@ietf.org; Tue, 02 Dec 2003 04:25:58 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Dec 2003 10:22:41 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB29PFAA000436; Tue, 2 Dec 2003 10:25:15 +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); Tue, 2 Dec 2003 09:25:27 +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 Subject: RE: [nemo] review of the nemo basic spec Date: Tue, 2 Dec 2003 09:25:27 -0000 Message-ID: Thread-Topic: [nemo] review of the nemo basic spec Thread-Index: AcO4U2H813278szRQxGzRePKGgSbygAXIoHg From: "Pascal Thubert (pthubert)" To: "Jari Arkko" Cc: X-OriginalArrivalTime: 02 Dec 2003 09:25:27.0953 (UTC) FILETIME=[39304810:01C3B8B6] 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 > You may be right, but then again describing the routing protocol > behaviour in the basic spec will lead to a number of MUSTs or SHOULDs, > or at least MAYs. We could avoid that, even if someone does that > on their own, or if you develop a NEMO Dynamic Routing Extension > later. >=20 Are you suggesting to remove chapter 7 and say nothing? >=20 > The implications I was afraid of were related to a host > becoming a router depending on movement detection results. > I don't have any specific case where this would fail, I > just worried about it. This relates to the "ND model for routers" and the "ROUTERS" vs. "routers" discussions in the v6WG list. A MR is always and definitely a router, but we are talking here about the model that its applies when it presents itself at ND level. Maybe the ND model is a bit limited. When a MR comes home in aggregated mode, it presents itself as a Node (NA), but it would be beneficial to advertise directly the prefixes for its MNPs, as not onlink. When a MR comes home in extended mode, it may present itself in either way (NA or RA), both unsatisfying.=20 The model I'm missing in ND is the "Network in a Node". For a Node with a prefix inside it or behind it, or more generally a proxy. A Network in Node Option (Nino) would help. Maybe it's just a prefix option in a NA, but I suspect there'd be more information such as MTU, bandwidth, and other metrics. > >> o It probably makes sense to be more explicit about > >> the relationship of this document to MIPv6. Does > >> a MR have to support everything in MIPV6, or just > >> some parts? Or say at least that you MUST support > >> everything... > > > > > > Right. In basic mode, the MR does not need to support to be a CN, and RO > > with a CN, since it is not expected to be the end point of most > > conversations. But IMHO, a Nemo HA should fully support MIPv6. Comments > > anyone? >=20 > Specification-wise it would be easiest to just require full > support. Functionality-wise RO might not be necessary, if the > MR is not sending any packets itself. OTOH RO support is not > a very big burden. Being a CN is a piece of work that may be useless and costly for a MR to implement. If we go through the requirements, it seems fair to say that MR MUST comply with MIPv6 as for the reqs on 8.1, 8.3 and MAY comply with 8.2. But I'm afraid that we need to extend 8.4 (for route setup) and to revisit 8.5 (to limit to MRHA tunnel, which is the requirement for basic). Pascal From exim@www1.ietf.org Tue Dec 2 04:27:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09529 for ; Tue, 2 Dec 2003 04:27: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 1AR6oG-0005Gg-9K for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 04:27:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB29R8Mq020250 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 04:27:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6oF-0005GX-Dx for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 04:27:07 -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 EAA09505 for ; Tue, 2 Dec 2003 04:26:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6oC-00042F-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 04:27:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR6oC-00042C-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 04:27:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6o9-0005Fi-34; Tue, 02 Dec 2003 04:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6nB-0005EU-Lu for nemo@optimus.ietf.org; Tue, 02 Dec 2003 04:26: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 EAA09490 for ; Tue, 2 Dec 2003 04:25:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6n8-00041X-00 for nemo@ietf.org; Tue, 02 Dec 2003 04:25:58 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AR6n8-00041L-00 for nemo@ietf.org; Tue, 02 Dec 2003 04:25:58 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Dec 2003 10:22:41 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB29PFAA000436; Tue, 2 Dec 2003 10:25:15 +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); Tue, 2 Dec 2003 09:25:27 +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 Subject: RE: [nemo] review of the nemo basic spec Date: Tue, 2 Dec 2003 09:25:27 -0000 Message-ID: Thread-Topic: [nemo] review of the nemo basic spec Thread-Index: AcO4U2H813278szRQxGzRePKGgSbygAXIoHg From: "Pascal Thubert (pthubert)" To: "Jari Arkko" Cc: X-OriginalArrivalTime: 02 Dec 2003 09:25:27.0953 (UTC) FILETIME=[39304810:01C3B8B6] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > You may be right, but then again describing the routing protocol > behaviour in the basic spec will lead to a number of MUSTs or SHOULDs, > or at least MAYs. We could avoid that, even if someone does that > on their own, or if you develop a NEMO Dynamic Routing Extension > later. >=20 Are you suggesting to remove chapter 7 and say nothing? >=20 > The implications I was afraid of were related to a host > becoming a router depending on movement detection results. > I don't have any specific case where this would fail, I > just worried about it. This relates to the "ND model for routers" and the "ROUTERS" vs. "routers" discussions in the v6WG list. A MR is always and definitely a router, but we are talking here about the model that its applies when it presents itself at ND level. Maybe the ND model is a bit limited. When a MR comes home in aggregated mode, it presents itself as a Node (NA), but it would be beneficial to advertise directly the prefixes for its MNPs, as not onlink. When a MR comes home in extended mode, it may present itself in either way (NA or RA), both unsatisfying.=20 The model I'm missing in ND is the "Network in a Node". For a Node with a prefix inside it or behind it, or more generally a proxy. A Network in Node Option (Nino) would help. Maybe it's just a prefix option in a NA, but I suspect there'd be more information such as MTU, bandwidth, and other metrics. > >> o It probably makes sense to be more explicit about > >> the relationship of this document to MIPv6. Does > >> a MR have to support everything in MIPV6, or just > >> some parts? Or say at least that you MUST support > >> everything... > > > > > > Right. In basic mode, the MR does not need to support to be a CN, and RO > > with a CN, since it is not expected to be the end point of most > > conversations. But IMHO, a Nemo HA should fully support MIPv6. Comments > > anyone? >=20 > Specification-wise it would be easiest to just require full > support. Functionality-wise RO might not be necessary, if the > MR is not sending any packets itself. OTOH RO support is not > a very big burden. Being a CN is a piece of work that may be useless and costly for a MR to implement. If we go through the requirements, it seems fair to say that MR MUST comply with MIPv6 as for the reqs on 8.1, 8.3 and MAY comply with 8.2. But I'm afraid that we need to extend 8.4 (for route setup) and to revisit 8.5 (to limit to MRHA tunnel, which is the requirement for basic). Pascal From nemo-admin@ietf.org Tue Dec 2 04:30:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09619 for ; Tue, 2 Dec 2003 04:30: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 1AR6r5-0005O9-Aj; Tue, 02 Dec 2003 04: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 1AR6qb-0005Mu-R7 for nemo@optimus.ietf.org; Tue, 02 Dec 2003 04:29: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 EAA09575 for ; Tue, 2 Dec 2003 04:29:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6qX-000434-00 for nemo@ietf.org; Tue, 02 Dec 2003 04:29:29 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AR6qW-000431-00 for nemo@ietf.org; Tue, 02 Dec 2003 04:29:29 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Dec 2003 10:26:12 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB29SjO0001457; Tue, 2 Dec 2003 10:28:46 +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); Tue, 2 Dec 2003 09:28:58 +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] review of the nemo basic spec Date: Tue, 2 Dec 2003 09:28:57 -0000 Message-ID: Thread-Topic: [nemo] review of the nemo basic spec Thread-Index: AcO4YNU1Kg0fnIbeTUaGFXRCdCL8OQAVM/Aw From: "Pascal Thubert (pthubert)" To: "Jari Arkko" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 02 Dec 2003 09:28:58.0606 (UTC) FILETIME=[B6BF60E0:01C3B8B6] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: mardi 2 d=E9cembre 2003 00:09 > To: Vijay Devarapalli > Cc: Pascal Thubert (pthubert); nemo@ietf.org > Subject: Re: [nemo] review of the nemo basic spec >=20 > Vijay Devarapalli wrote: >=20 > >> I'm referring to the first paragraph of Section 7. > >> Remember that according to MIPv6 base spec, unknown > >> flags are ignored, as are unknown moboptions. One good > >> way past this is to send one moboption and expect another > >> one back as an ack that the receiver understood what you > >> requested; then you know the HA supports NEMO. Alternatively, > >> you can track a flag value on the Binding Ack. If it comes > >> back as zero, HA did not support NEMO. > >> > >> In nemo, you do neither. Instead you have added a new flag > >> in DHAAD. That is useful, but I would also handle the BU/BA > >> in a way that the mobile router becomes certain the home > >> agent understood what it was being asked to do. > >> > >> Does this help explain my issue about the current nemo R=3D1 > >> usage? > > > > > > this was discussed earlier. Issues 15 and 16 capture the >=20 > I need to take a look at that, right now its too late (1 am) > here for that ;-) >=20 > > discussion. the first solution to support inter-working with > > MIPv6 Home Agents was to add a new binding ack status which > > says forwarding was setup. MIPv6 Home Agents would return > > just 0. the second suggestion was to add a flag in the binding > > ack which would be set to 1 if the Home Agents sets up > > forwarding for the mobile network. MIPv6 Home Agent would not > > set this flag. neither of this will work because, the Mobile > > Router now has to repeatedly try other Home Agents until it > > gets an indication from a Home Agent that it has set up > > forwarding. the mobile router also has to deregister with the > > MIPv6 Home Agent before trying another Home Agent. > > > > so modifying DHAAD was the right solution. the mobile router > > should not have attempted registration with a Home Agent that > > does not support mobile routers. > > > > IMO, a flag in the binding ack is just extra specification and > > extra code for something that shouldnt have happened. what do > > you think? >=20 > I think I agree that modifying DHAAD was a good thing to > do. WHat I am less sure about is whether that is sufficient. > One thing is that I'd rather not do DHAAD at all, if I can avoid > it. The second thing is making the decision of what you support > local. The HA that responds to a BU certainly knows what > it supports; another home agent might not know, for sure, > what the other home agents support. Or at least there could > be config errors in it. In conclusion, while I agree that > DHAAD support is good, it may be necessary to make the > BU/BA protocol itself robust enough to survive even > mistakes or old information in DHAAD. Does that make > sense? >=20 My point exactly. I agree we need both, since DHAAD is not always = wanted.=20 Note that for DHAAD, we need also to modify the Router Advertisement = Message to add a Nemo bit... Pascal From nemo-admin@ietf.org Tue Dec 2 04:30:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09621 for ; Tue, 2 Dec 2003 04:30: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 1AR6r6-0005P2-S3; Tue, 02 Dec 2003 04:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6qr-0005N2-MY for nemo@optimus.ietf.org; Tue, 02 Dec 2003 04:29: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 EAA09579 for ; Tue, 2 Dec 2003 04:29:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6qo-00043C-00 for nemo@ietf.org; Tue, 02 Dec 2003 04:29:46 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AR6qn-000439-00 for nemo@ietf.org; Tue, 02 Dec 2003 04:29:45 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id F303D6A902; Tue, 2 Dec 2003 11:29:44 +0200 (EET) Message-ID: <3FCC5A7B.4080509@kolumbus.fi> Date: Tue, 02 Dec 2003 11:25:15 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko References: <3FCBF3DE.7050202@iprg.nokia.com> In-Reply-To: <3FCBF3DE.7050202@iprg.nokia.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: , Content-Transfer-Encoding: 7bit Thanks Vijay for your prompt answer. I'm happy with most of your answers, some further discussion inline: >> JARI: I think LFNs can be complete mobility-unaware, I think you >> should mention this upfront as one of the benefits. > > > LFNs by definition are nodes which are not mobility aware. they > are fixed nodes. we already mention this once in the abstract > itself. > > The protocol is designed > in such a way that network mobility is transparent to the nodes > inside the mobile network. Ok. >> JARI: Hmm... there might be value in defining the terms in a >> self-contained >> manner here. I'm pretty sure you only use a subset of [8] terms, >> so it wouldn't be that long. > > > I also believe in a document being self contained when it comes > to terminology. but there is a separate WG document on NEMO > terminology that is being advanced as an informational RFC. so > I am not sure. I think that other document would have value even if you copied some of the terms (used ones) to the basic nemo document. Anyway, I don't think it is crucial. Just a practical issue that I noticed when reading. >> Prefix Table >> >> It is a list of a Mobile Network Prefixes indexed >> by the Home Address of a Mobile Router. The prefix table >> is managed by the Home Agent and is used by the Home Agent >> to determine which Mobile Network Prefixes are owned >> a particular Mobile Router. This is an optional data >> structure. >> >> JARI: Really? Why is it optional? Sounds mandatory to me... > > > well, there could be scenarios where the mobile routers are not > expected to misbehave. and there could be other ways for verifying > this. so we left it optional. I dont mind making it mandatory. That would make sense. Imho all nemo-based products should support this function. >> A Mobile Network is a network segment or subnet which can move >> and attach to arbitrary points in the Internet. A Mobile Network >> does not allow any transit traffic and can only be accessed via >> specific gateways called Mobile Routers that manage its movement. >> >> JARI: The above is a bit unclear. I think you mean that the >> nodes behind the MR can't access the internet directly, they >> have to go through the MR and the HA. > > > actually no. it means traffic to the Mobile Network can reach > the Mobile Network only through mobile routers. it also says > mobile networks are not transit networks. always stub networks. I'm still having some difficulty with the transit network part. I looked up one definition of a transit network from RFC 1584, which talks about the number of attached routers. However, in the nested nemo case you could actually have several attached routers, hidden inside tunnels. And would you allow multiple MRs per Mobile Network or not? I think not, because then you would appear like a transit network, according to the RFC 1584 definition. OTOH, I'm not sure why such a limitation would be necessary in the technical sense. Is it allowed for an MR to have two home agents, home addresses, and network prefixes? Is there any case where the Mobile Network would become a transit network in such a situation? How about this: A Mobile Network is a network segment or subnet which can move and attach to arbitrary points in the Internet. A Mobile Network can only be accessed via specific gateways called Mobile Routers that manage its movement. Mobile Networks have (always exactly)| (at least) one Mobile Router serving them. >> JARI: Question: is the prefix for a MR always unique? This seems unclear. >> Can other MRs have the same prefix, can the HA have the same >> prefix as the MR? >> > > more than one MR can be assigned a prefix. one can imagine having > two routers for the same mobile network. the HA will probably not > have the same prefix as the MR. Ok. >> JARI: Come to think of it, both the MR and the HA must know the >> assigned prefixes beforehand in any case, so I wonder if we >> need to communicate the prefixes at all?!? Can you cite an >> example where the HA would give a prefix to the MR without >> knowing it belongs to it? Or is the idea to prepare for the >> eventual bootstrapping support in MIPv6? > > > well, we still havent figured out how to do prefix delegation > to a mobile router. there is a draft by Ralph Droms on extending > DHCPv6 prefix delegation for NEMO. not a WG draft yet. > > and there is this scenario, where the mobile router is delegated > more than prefix, but it could decide to setup forwarding for just > one prefix instead of all prefixes. this cant be dont without > carrying prefix information in the Binding Update. If this is the case, perhaps you could remove the static alternative then? My concern is mainly the number of alternatives. I'd rather have less alternatives, even if the BUs would carry a few more bytes in some cases... >> JARI: So, presumably this includes forwarding of packets to >> the MR's own home address under all these prefixes, no? >> If so, I think we have the S=0 bit functionality when you >> set R=1 ;-) > > > :) only if the mobile router has configured all its home addresses > from its MNPs. Yeah. But to support S=0 all I have to do is to agree about suitable prefixes with my home agent, and set R=1... I'm not really suggesting you change anything, just making an observation. But doesn't this point to an additional reason for making the Prefix Table functionality mandatory? How else would the HA know which prefixes to give to the MR, if no prefixes were mentioned in the BU? >> JARI: Is there something that you would perhaps like to >> reference from MIPv6 regarding this tunneling, or is [3] enough? >> > > why? are we missing something. Would it be useful to follow MIPv6 base Section 5.5 guidelines on the use of source addresses? >> Finally, the Home Agent may be configured with static routes to the >> Mobile Network Prefix via the Mobile Router's Home Address. In that >> case, the routes are set independently of the binding flows and the >> returning Home of a Mobile Router. The benefit is that such movement >> does not induce any additional signalling in the form of routing >> updates in the Home Network. The drawback of that model is that the >> routes are present even if the related Mobile Routers that are not >> reachable (at Home or bound) at a given point of time. >> >> >> JARI: This is only a drawback if the routes would be reachable somewhere >> else. Given the desire to keep the Internet routing pretty >> stable, I would argue that we shouldn't be moving routes all >> over the place. Hence it would be sufficient if the routes >> were on one place only. > > > well, its a drawback in the sense, the Home Agent has routing table > entries even though the mobile router is currently dormant or just > disconnected. Its additional state yes, but packets destined to the prefix will be dropped on the floor in any case. >> JARI: What happens in the statically configured route case if R=0? >> Reading on... > > > there are two static cases. > > 1. implicit mode > 2. dynamic routing protocol updates > > which one are you referring to? Either one. >> This document introduces a new Prefix Information field in the >> Binding Update list structure. This field is used to store any >> prefix information that the Mobile Router includes in the Binding >> Update. If the Mobile Router sets the Mobile Router flag 'R' in the >> Binding Update, but does not include any prefix information in it >> (implicit mode), this field is set to null. >> >> JARI: So, if you run a routing protocol over the tunnel, will this >> information be updated in the BUL as well? > > > I think its not needed when a routing protocol is being run. Ok. Perhaps you could explicitly say this. >> If the Binding Acknowlegement status is set to '0' (Binding Update >> >> JARI: I don't understand this vs. what you are saying above in Section >> 5.3. What is the issue? Is it perhaps that due to your rules, >> you can do an R registration without a single moboption and >> hence the HA does not recognize that it doesn't support R? If >> so, you should require your moboptions to be always present... >> >> accepted), the Mobile Router concludes that the Home Agent which >> processed the Binding Update is a MIPv6 Home Agent that has not >> implemented support for Mobile Routers. It should send a similar >> Binding Update to another Home Agent on the link. If no Home Agent >> replies positively then the Mobile Router MUST refrain from sending >> any Binding Update with the Mobile Router flag set to any home agent >> on the home link and log the information. >> >> JARI: Hmm... forever? > > > actually this whole paragraph needs to be removed. it is left over > text from previous edits. my mistake. Ok. >> A Mobile Router MAY limit the number of mobile routers that attach to >> its mobile network (the number of levels in the nested aggregation) >> by means of setting the Tunnel Encapsulation Limit field of the >> Tunnel Encapsulation option. >> >> JARI: So what happens if there is a loop? A packet that you send >> travels through the loop until the encapsulation limit >> is reached? Or is there some other defense? >> > > I guess this is related to your issue on loop detection. I will add > this to issue 24. Ok. >> 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. >> >> JARI: I wonder if the above paragraph could be replaced with >> some reference to ND specs. As far as I can see, an MR should >> follow ND rules on its egress interface when on a visited >> network. > > > if you go by ND specs, routers ignore router advertisements. we are > infact saying router advertisements MUST NOT be ignored. I guess this is related to the MR turning to a host, as far as any external observer can determine, when it attaches to a foreign network. >> In some deployment scenarios it may be necessary for the Home Agent >> to prevent a misbehaving Mobile Router from claiming mobile network >> prefixes belonging to another Mobile Router. The Home Agent can >> prevent such attacks if it maintains a Prefix Table and verifies the >> Prefix Information provided by the Mobile Router against the entries >> in the Prefix Table. However, this verification is done only if the >> Binding Update contained explicit prefix information in the form of >> either the Mobile Network Prefix Option or the Mobile Network Prefix >> Length Option. >> >> JARI: I think that verification could also be done at the routing >> protocol case, assuming the HA can link the virtual interface >> and the corresponding MR together. >> > > we assume routing protocols have their own mechanism for verifying > the routing information sent by a router. so we did not recommend > anything in the routing protocol case. Ok. Maybe an explicit note about this too is needed. >> - The Home Registration (H) flag MUST be set. If not, the >> >> JARI: Use 'H' instead of (H) > > > MIPv6 spec uses (H). :) Well, what I really meant was to use one form all over the place ;-) >> JARI: Is it possible to go from a "R=1" BCE to an "R=0" BCE in >> some manner? Or only deleting the BCE and registering >> again? > > > the mobile router has to de-register and then register again. Ok. >> The establishment and operation of the bi-directional tunnel is >> implementation specific. However, all implementations MUST be >> capable of the following operations. >> >> JARI: What does it mean that its implementation specific? What >> specifically would you have to do to establish the tunnel >> in the first place? Why can't this be specified? > > > setting up and using tunnels is implementation specific. some > people like to set them up as virtual interfaces. sometimes it > is just code in the IP stack. Perhaps you could change the text to avoid a perception that the protocols are not fully defined. How about this: The implementation of the bi-directional tunnels and the mechanism of attaching them to the IP stack are outside the scope of this specification. However, all implementations MUST be capable of the following operations. >> The Home Agent either uses only the routing >> table, only the Binding Cache or a combination of routing table >> and Binding Cache to route packets to the mobile network. This is >> implementation specific. Two examples are shown below. >> >> JARI: You are presenting the rules in a too implementation-near >> form. Perhaps you could formulate something general >> that has a MUST. >> > > there is a problem with it. the binding cache is a conceptual > data structure. sometimes it is just implemented as a routing > table entry. one implementation (of mobile routers), I know, > uses the binding cache for both routing and CoA lookup. so > we left it implementation specific. and we present two ways > of doing it. > > we had a long discussion on using the binding cache or routing > table for the HA to forward packets to the mobile network. this > discussion happened before this draft was written up. Ok. (Perhaps you could change the first paragraph of 6.5 to have a keyword. This would be the normative part, the rest is implementation guidance.) >> In the solution described so far, forwarding to the Mobile Network >> at the Home Agent is set up when the Home Agent receives a Binding >> Update from the Mobile Router. An alternative to this is for the >> Home Agent and the Mobile Router to run an intra-domain routing >> protocol like RIPng [10] and OSPF [11] through the bi-directional >> tunnel. The Mobile Router can continue running the same routing >> protocol that it was running when it was attached to the home link. >> >> This feature is very useful when the Mobile Network is large with >> multiple subnets containing different IPv6 prefixes. Routing changes >> >> JARI: Can you give a practical example of where this could be the >> case? I can't think of any, but maybe its just me... > > > it could happen when there are multiple mobile networks attached > to the mobile router, each one having different prefix, but want > routing enabled for all these prefixes through the Home Agent. > using a routing protocol makes sense here. I think the key question here is whether running the routing protocol makes a difference in the end. Is it used to avoid sending useless packets to the MR? Most likely such traffic would be minimal, given that there would be no response from the networks that are currently disconnected. Or is it used to make some real routing changes, such as switching the traffic from one HA site to another one? If yes, this needs to be supported. Like I said above, I'm primarily concerned about the number of alternatives and that's why I'm trying to see if we really have a true need for all three, i.e. static, BU, and routing protocol alternatives. >> Since the routing protocol messages from the Home Agent to the Mobile >> Router could potentically contain information about the internal >> routing structure of the home network, these messages require >> authentications and confidentiality protection. Confidentialy >> protection using IPsec ESP [4] in tunnel mode MUST be supported and >> SHOULD be used. >> >> >> JARI: It might be necessary to have some more detail about this. >> What kind of SPD entries are needed etc. > > > should be straight forward. OSPFv3 and RIPng use specific transport > protocols and ports. for example the SPD entry on the mobile router > would say "if routing protocol message with destination=HA, use a > particular SA which would do tunnel mode ESP". How about writing this down somewhere in the document? As you know, "should be straight forward" is not always a guarantee that things will actually be like that ;-) > your other suggestions were accepted. Thanks. --Jari From exim@www1.ietf.org Tue Dec 2 04:30:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09649 for ; Tue, 2 Dec 2003 04:30: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 1AR6r9-0005QP-Pg for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 04:30:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB29U7r2020827 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 04:30:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6r7-0005Pd-M0 for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 04:30: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 EAA09596 for ; Tue, 2 Dec 2003 04:29:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6r4-00043W-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 04:30:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR6r4-00043T-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 04: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 1AR6r5-0005O9-Aj; Tue, 02 Dec 2003 04: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 1AR6qb-0005Mu-R7 for nemo@optimus.ietf.org; Tue, 02 Dec 2003 04:29: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 EAA09575 for ; Tue, 2 Dec 2003 04:29:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6qX-000434-00 for nemo@ietf.org; Tue, 02 Dec 2003 04:29:29 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AR6qW-000431-00 for nemo@ietf.org; Tue, 02 Dec 2003 04:29:29 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Dec 2003 10:26:12 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB29SjO0001457; Tue, 2 Dec 2003 10:28:46 +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); Tue, 2 Dec 2003 09:28:58 +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] review of the nemo basic spec Date: Tue, 2 Dec 2003 09:28:57 -0000 Message-ID: Thread-Topic: [nemo] review of the nemo basic spec Thread-Index: AcO4YNU1Kg0fnIbeTUaGFXRCdCL8OQAVM/Aw From: "Pascal Thubert (pthubert)" To: "Jari Arkko" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 02 Dec 2003 09:28:58.0606 (UTC) FILETIME=[B6BF60E0:01C3B8B6] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: mardi 2 d=E9cembre 2003 00:09 > To: Vijay Devarapalli > Cc: Pascal Thubert (pthubert); nemo@ietf.org > Subject: Re: [nemo] review of the nemo basic spec >=20 > Vijay Devarapalli wrote: >=20 > >> I'm referring to the first paragraph of Section 7. > >> Remember that according to MIPv6 base spec, unknown > >> flags are ignored, as are unknown moboptions. One good > >> way past this is to send one moboption and expect another > >> one back as an ack that the receiver understood what you > >> requested; then you know the HA supports NEMO. Alternatively, > >> you can track a flag value on the Binding Ack. If it comes > >> back as zero, HA did not support NEMO. > >> > >> In nemo, you do neither. Instead you have added a new flag > >> in DHAAD. That is useful, but I would also handle the BU/BA > >> in a way that the mobile router becomes certain the home > >> agent understood what it was being asked to do. > >> > >> Does this help explain my issue about the current nemo R=3D1 > >> usage? > > > > > > this was discussed earlier. Issues 15 and 16 capture the >=20 > I need to take a look at that, right now its too late (1 am) > here for that ;-) >=20 > > discussion. the first solution to support inter-working with > > MIPv6 Home Agents was to add a new binding ack status which > > says forwarding was setup. MIPv6 Home Agents would return > > just 0. the second suggestion was to add a flag in the binding > > ack which would be set to 1 if the Home Agents sets up > > forwarding for the mobile network. MIPv6 Home Agent would not > > set this flag. neither of this will work because, the Mobile > > Router now has to repeatedly try other Home Agents until it > > gets an indication from a Home Agent that it has set up > > forwarding. the mobile router also has to deregister with the > > MIPv6 Home Agent before trying another Home Agent. > > > > so modifying DHAAD was the right solution. the mobile router > > should not have attempted registration with a Home Agent that > > does not support mobile routers. > > > > IMO, a flag in the binding ack is just extra specification and > > extra code for something that shouldnt have happened. what do > > you think? >=20 > I think I agree that modifying DHAAD was a good thing to > do. WHat I am less sure about is whether that is sufficient. > One thing is that I'd rather not do DHAAD at all, if I can avoid > it. The second thing is making the decision of what you support > local. The HA that responds to a BU certainly knows what > it supports; another home agent might not know, for sure, > what the other home agents support. Or at least there could > be config errors in it. In conclusion, while I agree that > DHAAD support is good, it may be necessary to make the > BU/BA protocol itself robust enough to survive even > mistakes or old information in DHAAD. Does that make > sense? >=20 My point exactly. I agree we need both, since DHAAD is not always = wanted.=20 Note that for DHAAD, we need also to modify the Router Advertisement = Message to add a Nemo bit... Pascal From nemo-admin@ietf.org Tue Dec 2 04:34:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09743 for ; Tue, 2 Dec 2003 04:34: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 1AR6uv-0005ec-G8; Tue, 02 Dec 2003 04:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6u5-0005dn-LC for nemo@optimus.ietf.org; Tue, 02 Dec 2003 04:33: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 EAA09732 for ; Tue, 2 Dec 2003 04:32:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6u2-00046I-00 for nemo@ietf.org; Tue, 02 Dec 2003 04:33:06 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AR6u2-00046F-00 for nemo@ietf.org; Tue, 02 Dec 2003 04:33:06 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3A6A96A901; Tue, 2 Dec 2003 11:33:07 +0200 (EET) Message-ID: <3FCC5B45.8020109@kolumbus.fi> Date: Tue, 02 Dec 2003 11:28:37 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: Vijay Devarapalli , nemo@ietf.org Subject: Re: [nemo] review of the nemo basic spec 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: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Note that for DHAAD, we need also to modify the Router Advertisement Message to add a Nemo bit... Or a vector of capabilities bits for every HA... ok, maybe that's an overkill. --Jari From exim@www1.ietf.org Tue Dec 2 04:34:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09758 for ; Tue, 2 Dec 2003 04:34:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6ux-0005ff-C3 for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 04:34:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB29Y3B0021791 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 04:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6uw-0005fO-QX for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 04:34: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 EAA09736 for ; Tue, 2 Dec 2003 04:33:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6ut-00046R-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 04:33:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR6ut-00046O-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 04:33:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6uv-0005ec-G8; Tue, 02 Dec 2003 04:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6u5-0005dn-LC for nemo@optimus.ietf.org; Tue, 02 Dec 2003 04:33: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 EAA09732 for ; Tue, 2 Dec 2003 04:32:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6u2-00046I-00 for nemo@ietf.org; Tue, 02 Dec 2003 04:33:06 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AR6u2-00046F-00 for nemo@ietf.org; Tue, 02 Dec 2003 04:33:06 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3A6A96A901; Tue, 2 Dec 2003 11:33:07 +0200 (EET) Message-ID: <3FCC5B45.8020109@kolumbus.fi> Date: Tue, 02 Dec 2003 11:28:37 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: Vijay Devarapalli , nemo@ietf.org Subject: Re: [nemo] review of the nemo basic spec 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Note that for DHAAD, we need also to modify the Router Advertisement Message to add a Nemo bit... Or a vector of capabilities bits for every HA... ok, maybe that's an overkill. --Jari From exim@www1.ietf.org Tue Dec 2 05:19:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09650 for ; Tue, 2 Dec 2003 04:30: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 1AR6r9-0005QQ-St for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 04:30:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB29U7gS020834 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 04:30:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6r8-0005Pu-59 for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 04:30: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 EAA09599 for ; Tue, 2 Dec 2003 04:29:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6r5-00043a-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 04:30:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR6r4-00043X-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 04: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 1AR6r6-0005P2-S3; Tue, 02 Dec 2003 04:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6qr-0005N2-MY for nemo@optimus.ietf.org; Tue, 02 Dec 2003 04:29: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 EAA09579 for ; Tue, 2 Dec 2003 04:29:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6qo-00043C-00 for nemo@ietf.org; Tue, 02 Dec 2003 04:29:46 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AR6qn-000439-00 for nemo@ietf.org; Tue, 02 Dec 2003 04:29:45 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id F303D6A902; Tue, 2 Dec 2003 11:29:44 +0200 (EET) Message-ID: <3FCC5A7B.4080509@kolumbus.fi> Date: Tue, 02 Dec 2003 11:25:15 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko References: <3FCBF3DE.7050202@iprg.nokia.com> In-Reply-To: <3FCBF3DE.7050202@iprg.nokia.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks Vijay for your prompt answer. I'm happy with most of your answers, some further discussion inline: >> JARI: I think LFNs can be complete mobility-unaware, I think you >> should mention this upfront as one of the benefits. > > > LFNs by definition are nodes which are not mobility aware. they > are fixed nodes. we already mention this once in the abstract > itself. > > The protocol is designed > in such a way that network mobility is transparent to the nodes > inside the mobile network. Ok. >> JARI: Hmm... there might be value in defining the terms in a >> self-contained >> manner here. I'm pretty sure you only use a subset of [8] terms, >> so it wouldn't be that long. > > > I also believe in a document being self contained when it comes > to terminology. but there is a separate WG document on NEMO > terminology that is being advanced as an informational RFC. so > I am not sure. I think that other document would have value even if you copied some of the terms (used ones) to the basic nemo document. Anyway, I don't think it is crucial. Just a practical issue that I noticed when reading. >> Prefix Table >> >> It is a list of a Mobile Network Prefixes indexed >> by the Home Address of a Mobile Router. The prefix table >> is managed by the Home Agent and is used by the Home Agent >> to determine which Mobile Network Prefixes are owned >> a particular Mobile Router. This is an optional data >> structure. >> >> JARI: Really? Why is it optional? Sounds mandatory to me... > > > well, there could be scenarios where the mobile routers are not > expected to misbehave. and there could be other ways for verifying > this. so we left it optional. I dont mind making it mandatory. That would make sense. Imho all nemo-based products should support this function. >> A Mobile Network is a network segment or subnet which can move >> and attach to arbitrary points in the Internet. A Mobile Network >> does not allow any transit traffic and can only be accessed via >> specific gateways called Mobile Routers that manage its movement. >> >> JARI: The above is a bit unclear. I think you mean that the >> nodes behind the MR can't access the internet directly, they >> have to go through the MR and the HA. > > > actually no. it means traffic to the Mobile Network can reach > the Mobile Network only through mobile routers. it also says > mobile networks are not transit networks. always stub networks. I'm still having some difficulty with the transit network part. I looked up one definition of a transit network from RFC 1584, which talks about the number of attached routers. However, in the nested nemo case you could actually have several attached routers, hidden inside tunnels. And would you allow multiple MRs per Mobile Network or not? I think not, because then you would appear like a transit network, according to the RFC 1584 definition. OTOH, I'm not sure why such a limitation would be necessary in the technical sense. Is it allowed for an MR to have two home agents, home addresses, and network prefixes? Is there any case where the Mobile Network would become a transit network in such a situation? How about this: A Mobile Network is a network segment or subnet which can move and attach to arbitrary points in the Internet. A Mobile Network can only be accessed via specific gateways called Mobile Routers that manage its movement. Mobile Networks have (always exactly)| (at least) one Mobile Router serving them. >> JARI: Question: is the prefix for a MR always unique? This seems unclear. >> Can other MRs have the same prefix, can the HA have the same >> prefix as the MR? >> > > more than one MR can be assigned a prefix. one can imagine having > two routers for the same mobile network. the HA will probably not > have the same prefix as the MR. Ok. >> JARI: Come to think of it, both the MR and the HA must know the >> assigned prefixes beforehand in any case, so I wonder if we >> need to communicate the prefixes at all?!? Can you cite an >> example where the HA would give a prefix to the MR without >> knowing it belongs to it? Or is the idea to prepare for the >> eventual bootstrapping support in MIPv6? > > > well, we still havent figured out how to do prefix delegation > to a mobile router. there is a draft by Ralph Droms on extending > DHCPv6 prefix delegation for NEMO. not a WG draft yet. > > and there is this scenario, where the mobile router is delegated > more than prefix, but it could decide to setup forwarding for just > one prefix instead of all prefixes. this cant be dont without > carrying prefix information in the Binding Update. If this is the case, perhaps you could remove the static alternative then? My concern is mainly the number of alternatives. I'd rather have less alternatives, even if the BUs would carry a few more bytes in some cases... >> JARI: So, presumably this includes forwarding of packets to >> the MR's own home address under all these prefixes, no? >> If so, I think we have the S=0 bit functionality when you >> set R=1 ;-) > > > :) only if the mobile router has configured all its home addresses > from its MNPs. Yeah. But to support S=0 all I have to do is to agree about suitable prefixes with my home agent, and set R=1... I'm not really suggesting you change anything, just making an observation. But doesn't this point to an additional reason for making the Prefix Table functionality mandatory? How else would the HA know which prefixes to give to the MR, if no prefixes were mentioned in the BU? >> JARI: Is there something that you would perhaps like to >> reference from MIPv6 regarding this tunneling, or is [3] enough? >> > > why? are we missing something. Would it be useful to follow MIPv6 base Section 5.5 guidelines on the use of source addresses? >> Finally, the Home Agent may be configured with static routes to the >> Mobile Network Prefix via the Mobile Router's Home Address. In that >> case, the routes are set independently of the binding flows and the >> returning Home of a Mobile Router. The benefit is that such movement >> does not induce any additional signalling in the form of routing >> updates in the Home Network. The drawback of that model is that the >> routes are present even if the related Mobile Routers that are not >> reachable (at Home or bound) at a given point of time. >> >> >> JARI: This is only a drawback if the routes would be reachable somewhere >> else. Given the desire to keep the Internet routing pretty >> stable, I would argue that we shouldn't be moving routes all >> over the place. Hence it would be sufficient if the routes >> were on one place only. > > > well, its a drawback in the sense, the Home Agent has routing table > entries even though the mobile router is currently dormant or just > disconnected. Its additional state yes, but packets destined to the prefix will be dropped on the floor in any case. >> JARI: What happens in the statically configured route case if R=0? >> Reading on... > > > there are two static cases. > > 1. implicit mode > 2. dynamic routing protocol updates > > which one are you referring to? Either one. >> This document introduces a new Prefix Information field in the >> Binding Update list structure. This field is used to store any >> prefix information that the Mobile Router includes in the Binding >> Update. If the Mobile Router sets the Mobile Router flag 'R' in the >> Binding Update, but does not include any prefix information in it >> (implicit mode), this field is set to null. >> >> JARI: So, if you run a routing protocol over the tunnel, will this >> information be updated in the BUL as well? > > > I think its not needed when a routing protocol is being run. Ok. Perhaps you could explicitly say this. >> If the Binding Acknowlegement status is set to '0' (Binding Update >> >> JARI: I don't understand this vs. what you are saying above in Section >> 5.3. What is the issue? Is it perhaps that due to your rules, >> you can do an R registration without a single moboption and >> hence the HA does not recognize that it doesn't support R? If >> so, you should require your moboptions to be always present... >> >> accepted), the Mobile Router concludes that the Home Agent which >> processed the Binding Update is a MIPv6 Home Agent that has not >> implemented support for Mobile Routers. It should send a similar >> Binding Update to another Home Agent on the link. If no Home Agent >> replies positively then the Mobile Router MUST refrain from sending >> any Binding Update with the Mobile Router flag set to any home agent >> on the home link and log the information. >> >> JARI: Hmm... forever? > > > actually this whole paragraph needs to be removed. it is left over > text from previous edits. my mistake. Ok. >> A Mobile Router MAY limit the number of mobile routers that attach to >> its mobile network (the number of levels in the nested aggregation) >> by means of setting the Tunnel Encapsulation Limit field of the >> Tunnel Encapsulation option. >> >> JARI: So what happens if there is a loop? A packet that you send >> travels through the loop until the encapsulation limit >> is reached? Or is there some other defense? >> > > I guess this is related to your issue on loop detection. I will add > this to issue 24. Ok. >> 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. >> >> JARI: I wonder if the above paragraph could be replaced with >> some reference to ND specs. As far as I can see, an MR should >> follow ND rules on its egress interface when on a visited >> network. > > > if you go by ND specs, routers ignore router advertisements. we are > infact saying router advertisements MUST NOT be ignored. I guess this is related to the MR turning to a host, as far as any external observer can determine, when it attaches to a foreign network. >> In some deployment scenarios it may be necessary for the Home Agent >> to prevent a misbehaving Mobile Router from claiming mobile network >> prefixes belonging to another Mobile Router. The Home Agent can >> prevent such attacks if it maintains a Prefix Table and verifies the >> Prefix Information provided by the Mobile Router against the entries >> in the Prefix Table. However, this verification is done only if the >> Binding Update contained explicit prefix information in the form of >> either the Mobile Network Prefix Option or the Mobile Network Prefix >> Length Option. >> >> JARI: I think that verification could also be done at the routing >> protocol case, assuming the HA can link the virtual interface >> and the corresponding MR together. >> > > we assume routing protocols have their own mechanism for verifying > the routing information sent by a router. so we did not recommend > anything in the routing protocol case. Ok. Maybe an explicit note about this too is needed. >> - The Home Registration (H) flag MUST be set. If not, the >> >> JARI: Use 'H' instead of (H) > > > MIPv6 spec uses (H). :) Well, what I really meant was to use one form all over the place ;-) >> JARI: Is it possible to go from a "R=1" BCE to an "R=0" BCE in >> some manner? Or only deleting the BCE and registering >> again? > > > the mobile router has to de-register and then register again. Ok. >> The establishment and operation of the bi-directional tunnel is >> implementation specific. However, all implementations MUST be >> capable of the following operations. >> >> JARI: What does it mean that its implementation specific? What >> specifically would you have to do to establish the tunnel >> in the first place? Why can't this be specified? > > > setting up and using tunnels is implementation specific. some > people like to set them up as virtual interfaces. sometimes it > is just code in the IP stack. Perhaps you could change the text to avoid a perception that the protocols are not fully defined. How about this: The implementation of the bi-directional tunnels and the mechanism of attaching them to the IP stack are outside the scope of this specification. However, all implementations MUST be capable of the following operations. >> The Home Agent either uses only the routing >> table, only the Binding Cache or a combination of routing table >> and Binding Cache to route packets to the mobile network. This is >> implementation specific. Two examples are shown below. >> >> JARI: You are presenting the rules in a too implementation-near >> form. Perhaps you could formulate something general >> that has a MUST. >> > > there is a problem with it. the binding cache is a conceptual > data structure. sometimes it is just implemented as a routing > table entry. one implementation (of mobile routers), I know, > uses the binding cache for both routing and CoA lookup. so > we left it implementation specific. and we present two ways > of doing it. > > we had a long discussion on using the binding cache or routing > table for the HA to forward packets to the mobile network. this > discussion happened before this draft was written up. Ok. (Perhaps you could change the first paragraph of 6.5 to have a keyword. This would be the normative part, the rest is implementation guidance.) >> In the solution described so far, forwarding to the Mobile Network >> at the Home Agent is set up when the Home Agent receives a Binding >> Update from the Mobile Router. An alternative to this is for the >> Home Agent and the Mobile Router to run an intra-domain routing >> protocol like RIPng [10] and OSPF [11] through the bi-directional >> tunnel. The Mobile Router can continue running the same routing >> protocol that it was running when it was attached to the home link. >> >> This feature is very useful when the Mobile Network is large with >> multiple subnets containing different IPv6 prefixes. Routing changes >> >> JARI: Can you give a practical example of where this could be the >> case? I can't think of any, but maybe its just me... > > > it could happen when there are multiple mobile networks attached > to the mobile router, each one having different prefix, but want > routing enabled for all these prefixes through the Home Agent. > using a routing protocol makes sense here. I think the key question here is whether running the routing protocol makes a difference in the end. Is it used to avoid sending useless packets to the MR? Most likely such traffic would be minimal, given that there would be no response from the networks that are currently disconnected. Or is it used to make some real routing changes, such as switching the traffic from one HA site to another one? If yes, this needs to be supported. Like I said above, I'm primarily concerned about the number of alternatives and that's why I'm trying to see if we really have a true need for all three, i.e. static, BU, and routing protocol alternatives. >> Since the routing protocol messages from the Home Agent to the Mobile >> Router could potentically contain information about the internal >> routing structure of the home network, these messages require >> authentications and confidentiality protection. Confidentialy >> protection using IPsec ESP [4] in tunnel mode MUST be supported and >> SHOULD be used. >> >> >> JARI: It might be necessary to have some more detail about this. >> What kind of SPD entries are needed etc. > > > should be straight forward. OSPFv3 and RIPng use specific transport > protocols and ports. for example the SPD entry on the mobile router > would say "if routing protocol message with destination=HA, use a > particular SA which would do tunnel mode ESP". How about writing this down somewhere in the document? As you know, "should be straight forward" is not always a guarantee that things will actually be like that ;-) > your other suggestions were accepted. Thanks. --Jari From nemo-admin@ietf.org Tue Dec 2 05:38:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11165 for ; Tue, 2 Dec 2003 05:38: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 1AR7ur-0008FI-UT; Tue, 02 Dec 2003 05: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 1AR7uf-0008CS-3y for nemo@optimus.ietf.org; Tue, 02 Dec 2003 05:37: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 FAA11150 for ; Tue, 2 Dec 2003 05:37:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR7ub-0004hm-00 for nemo@ietf.org; Tue, 02 Dec 2003 05:37:45 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AR7ua-0004gv-00 for nemo@ietf.org; Tue, 02 Dec 2003 05:37:44 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Dec 2003 11:33:59 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB2AaWQc022479; Tue, 2 Dec 2003 11:36:32 +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); Tue, 2 Dec 2003 10:36:44 +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 Subject: RE: [nemo] Editorial comments from Jari Arkko Date: Tue, 2 Dec 2003 10:36:43 -0000 Message-ID: Thread-Topic: [nemo] Editorial comments from Jari Arkko Thread-Index: AcO4twaFBqGe5zGuR7ODzyVcIqpqnQAAuOQQ From: "Pascal Thubert (pthubert)" To: "Jari Arkko" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 02 Dec 2003 10:36:44.0976 (UTC) FILETIME=[2E7E3300:01C3B8C0] 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 > >> Prefix Table > >> > >> It is a list of a Mobile Network Prefixes indexed > >> by the Home Address of a Mobile Router. The prefix table > >> is managed by the Home Agent and is used by the Home Agent > >> to determine which Mobile Network Prefixes are owned > >> a particular Mobile Router. This is an optional data > >> structure. > >> > >> JARI: Really? Why is it optional? Sounds mandatory to me... > > > > > > well, there could be scenarios where the mobile routers are not > > expected to misbehave. and there could be other ways for verifying > > this. so we left it optional. I dont mind making it mandatory. >=20 > That would make sense. Imho all nemo-based products > should support this function. Yes, and it's very abstract. It can be implemented as a set of static routes. >=20 > >> A Mobile Network is a network segment or subnet which can move > >> and attach to arbitrary points in the Internet. A Mobile Network > >> does not allow any transit traffic and can only be accessed via > >> specific gateways called Mobile Routers that manage its movement. > >> > >> JARI: The above is a bit unclear. I think you mean that the > >> nodes behind the MR can't access the internet directly, they > >> have to go through the MR and the HA. > > > > > > actually no. it means traffic to the Mobile Network can reach > > the Mobile Network only through mobile routers. it also says > > mobile networks are not transit networks. always stub networks. >=20 > I'm still having some difficulty with the transit network > part. I looked up one definition of a transit network from RFC > 1584, which talks about the number of attached routers. However, > in the nested nemo case you could actually have several attached > routers, hidden inside tunnels. And would you allow multiple > MRs per Mobile Network or not? I think not, because then you > would appear like a transit network, according to the > RFC 1584 definition. OTOH, I'm not sure why such a limitation > would be necessary in the technical sense. >=20 > Is it allowed for an MR to have two home agents, home addresses, > and network prefixes? Is there any case where the Mobile Network > would become a transit network in such a situation? Jari: This is entering the multihoming discussion, again out of scope. We tried to define formats that would allow for it. But we do not detail how that works. Like RO, multihoming in Nemo has multiple faces (see http://www.ietf.org/internet-drafts/draft-charbon-nemo-multihoming-evalu ation-00.txt) >=20 > How about this: >=20 > A Mobile Network is a network segment or subnet which can move > and attach to arbitrary points in the Internet. A Mobile Network > can only be accessed via specific gateways called Mobile Routers > that manage its movement. Mobile Networks have (always exactly)| > (at least) one Mobile Router serving them. >=20 > >> JARI: Question: is the prefix for a MR always unique? This seems unclear. > >> Can other MRs have the same prefix, can the HA have the same > >> prefix as the MR? > >> > > > > more than one MR can be assigned a prefix. one can imagine having > > two routers for the same mobile network. the HA will probably not > > have the same prefix as the MR. >=20 > Ok. >=20 > >> JARI: Come to think of it, both the MR and the HA must know the > >> assigned prefixes beforehand in any case, so I wonder if we > >> need to communicate the prefixes at all?!? Can you cite an > >> example where the HA would give a prefix to the MR without > >> knowing it belongs to it? Or is the idea to prepare for the > >> eventual bootstrapping support in MIPv6? > > > > > > well, we still havent figured out how to do prefix delegation > > to a mobile router. there is a draft by Ralph Droms on extending > > DHCPv6 prefix delegation for NEMO. not a WG draft yet. > > > > and there is this scenario, where the mobile router is delegated > > more than prefix, but it could decide to setup forwarding for just > > one prefix instead of all prefixes. this cant be dont without > > carrying prefix information in the Binding Update. >=20 > If this is the case, perhaps you could remove the static alternative > then? My concern is mainly the number of alternatives. I'd rather > have less alternatives, even if the BUs would carry a few more bytes > in some cases... >=20 Halt! If there's only one thing left, in my mind it's static. The way I see the original question is more like: why do we need explicit if the HA has the prefix table anyway for authorization purposes? For the lack of a better one, my answer is that the authorization may be more global or turned off by policy. Having more then one mode opens for different deployments. MRs do not have to support them all, only the HAs do (we definitely should write our own version of the MIPv6 8.4 and 8.5 chapters). And static comes free with the HA. So why remove it? > >> > >> JARI: This is only a drawback if the routes would be reachable somewhere > >> else. Given the desire to keep the Internet routing pretty > >> stable, I would argue that we shouldn't be moving routes all > >> over the place. Hence it would be sufficient if the routes > >> were on one place only. > > > > > > well, its a drawback in the sense, the Home Agent has routing table > > entries even though the mobile router is currently dormant or just > > disconnected. >=20 > Its additional state yes, but packets destined to the prefix will > be dropped on the floor in any case. This is why I like static :) >=20 > >> JARI: What happens in the statically configured route case if = R=3D0? > >> Reading on... > > > > > > there are two static cases. > > > > 1. implicit mode > > 2. dynamic routing protocol updates > > > > which one are you referring to? >=20 > Either one. >=20 I have trouble to call 2. static... For 1., the spec says not to install forwarding, but on the other hand it's already installed and can hardly be removed (should we send an alert and ask the operator to reconfigure?). So I'm not sure of the value of r=3D0 in implicit mode. = We discussed that already and I'm still not convinced.=20 >=20 > I think the key question here is whether running the routing > protocol makes a difference in the end. Is it used to avoid > sending useless packets to the MR? Most likely such traffic > would be minimal, given that there would be no response from > the networks that are currently disconnected. Or is it used > to make some real routing changes, such as switching the > traffic from one HA site to another one? If yes, this needs > to be supported. >=20 > Like I said above, I'm primarily concerned about the number > of alternatives and that's why I'm trying to see if we really > have a true need for all three, i.e. static, BU, and routing > protocol alternatives. >=20 The routing protocol thing could be considered out of scope. Once the MRHA tunnel is established, any manual tunnel can be used to carry IPv4, multicast, or an IGP back home. Do we have to explicitly say all this? Maybe we could move it to "usages"? Pascal From exim@www1.ietf.org Tue Dec 2 05:38:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11184 for ; Tue, 2 Dec 2003 05:38: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 1AR7v0-0008HR-Jw for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 05:38:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2AcAj6031821 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 05:38:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7v0-0008H2-69 for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 05:38: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 FAA11157 for ; Tue, 2 Dec 2003 05:37:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR7uw-0004iD-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 05:38:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR7uw-0004iA-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 05:38:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7ur-0008FI-UT; Tue, 02 Dec 2003 05: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 1AR7uf-0008CS-3y for nemo@optimus.ietf.org; Tue, 02 Dec 2003 05:37: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 FAA11150 for ; Tue, 2 Dec 2003 05:37:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR7ub-0004hm-00 for nemo@ietf.org; Tue, 02 Dec 2003 05:37:45 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AR7ua-0004gv-00 for nemo@ietf.org; Tue, 02 Dec 2003 05:37:44 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Dec 2003 11:33:59 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB2AaWQc022479; Tue, 2 Dec 2003 11:36:32 +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); Tue, 2 Dec 2003 10:36:44 +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 Subject: RE: [nemo] Editorial comments from Jari Arkko Date: Tue, 2 Dec 2003 10:36:43 -0000 Message-ID: Thread-Topic: [nemo] Editorial comments from Jari Arkko Thread-Index: AcO4twaFBqGe5zGuR7ODzyVcIqpqnQAAuOQQ From: "Pascal Thubert (pthubert)" To: "Jari Arkko" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 02 Dec 2003 10:36:44.0976 (UTC) FILETIME=[2E7E3300:01C3B8C0] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > >> Prefix Table > >> > >> It is a list of a Mobile Network Prefixes indexed > >> by the Home Address of a Mobile Router. The prefix table > >> is managed by the Home Agent and is used by the Home Agent > >> to determine which Mobile Network Prefixes are owned > >> a particular Mobile Router. This is an optional data > >> structure. > >> > >> JARI: Really? Why is it optional? Sounds mandatory to me... > > > > > > well, there could be scenarios where the mobile routers are not > > expected to misbehave. and there could be other ways for verifying > > this. so we left it optional. I dont mind making it mandatory. >=20 > That would make sense. Imho all nemo-based products > should support this function. Yes, and it's very abstract. It can be implemented as a set of static routes. >=20 > >> A Mobile Network is a network segment or subnet which can move > >> and attach to arbitrary points in the Internet. A Mobile Network > >> does not allow any transit traffic and can only be accessed via > >> specific gateways called Mobile Routers that manage its movement. > >> > >> JARI: The above is a bit unclear. I think you mean that the > >> nodes behind the MR can't access the internet directly, they > >> have to go through the MR and the HA. > > > > > > actually no. it means traffic to the Mobile Network can reach > > the Mobile Network only through mobile routers. it also says > > mobile networks are not transit networks. always stub networks. >=20 > I'm still having some difficulty with the transit network > part. I looked up one definition of a transit network from RFC > 1584, which talks about the number of attached routers. However, > in the nested nemo case you could actually have several attached > routers, hidden inside tunnels. And would you allow multiple > MRs per Mobile Network or not? I think not, because then you > would appear like a transit network, according to the > RFC 1584 definition. OTOH, I'm not sure why such a limitation > would be necessary in the technical sense. >=20 > Is it allowed for an MR to have two home agents, home addresses, > and network prefixes? Is there any case where the Mobile Network > would become a transit network in such a situation? Jari: This is entering the multihoming discussion, again out of scope. We tried to define formats that would allow for it. But we do not detail how that works. Like RO, multihoming in Nemo has multiple faces (see http://www.ietf.org/internet-drafts/draft-charbon-nemo-multihoming-evalu ation-00.txt) >=20 > How about this: >=20 > A Mobile Network is a network segment or subnet which can move > and attach to arbitrary points in the Internet. A Mobile Network > can only be accessed via specific gateways called Mobile Routers > that manage its movement. Mobile Networks have (always exactly)| > (at least) one Mobile Router serving them. >=20 > >> JARI: Question: is the prefix for a MR always unique? This seems unclear. > >> Can other MRs have the same prefix, can the HA have the same > >> prefix as the MR? > >> > > > > more than one MR can be assigned a prefix. one can imagine having > > two routers for the same mobile network. the HA will probably not > > have the same prefix as the MR. >=20 > Ok. >=20 > >> JARI: Come to think of it, both the MR and the HA must know the > >> assigned prefixes beforehand in any case, so I wonder if we > >> need to communicate the prefixes at all?!? Can you cite an > >> example where the HA would give a prefix to the MR without > >> knowing it belongs to it? Or is the idea to prepare for the > >> eventual bootstrapping support in MIPv6? > > > > > > well, we still havent figured out how to do prefix delegation > > to a mobile router. there is a draft by Ralph Droms on extending > > DHCPv6 prefix delegation for NEMO. not a WG draft yet. > > > > and there is this scenario, where the mobile router is delegated > > more than prefix, but it could decide to setup forwarding for just > > one prefix instead of all prefixes. this cant be dont without > > carrying prefix information in the Binding Update. >=20 > If this is the case, perhaps you could remove the static alternative > then? My concern is mainly the number of alternatives. I'd rather > have less alternatives, even if the BUs would carry a few more bytes > in some cases... >=20 Halt! If there's only one thing left, in my mind it's static. The way I see the original question is more like: why do we need explicit if the HA has the prefix table anyway for authorization purposes? For the lack of a better one, my answer is that the authorization may be more global or turned off by policy. Having more then one mode opens for different deployments. MRs do not have to support them all, only the HAs do (we definitely should write our own version of the MIPv6 8.4 and 8.5 chapters). And static comes free with the HA. So why remove it? > >> > >> JARI: This is only a drawback if the routes would be reachable somewhere > >> else. Given the desire to keep the Internet routing pretty > >> stable, I would argue that we shouldn't be moving routes all > >> over the place. Hence it would be sufficient if the routes > >> were on one place only. > > > > > > well, its a drawback in the sense, the Home Agent has routing table > > entries even though the mobile router is currently dormant or just > > disconnected. >=20 > Its additional state yes, but packets destined to the prefix will > be dropped on the floor in any case. This is why I like static :) >=20 > >> JARI: What happens in the statically configured route case if = R=3D0? > >> Reading on... > > > > > > there are two static cases. > > > > 1. implicit mode > > 2. dynamic routing protocol updates > > > > which one are you referring to? >=20 > Either one. >=20 I have trouble to call 2. static... For 1., the spec says not to install forwarding, but on the other hand it's already installed and can hardly be removed (should we send an alert and ask the operator to reconfigure?). So I'm not sure of the value of r=3D0 in implicit mode. = We discussed that already and I'm still not convinced.=20 >=20 > I think the key question here is whether running the routing > protocol makes a difference in the end. Is it used to avoid > sending useless packets to the MR? Most likely such traffic > would be minimal, given that there would be no response from > the networks that are currently disconnected. Or is it used > to make some real routing changes, such as switching the > traffic from one HA site to another one? If yes, this needs > to be supported. >=20 > Like I said above, I'm primarily concerned about the number > of alternatives and that's why I'm trying to see if we really > have a true need for all three, i.e. static, BU, and routing > protocol alternatives. >=20 The routing protocol thing could be considered out of scope. Once the MRHA tunnel is established, any manual tunnel can be used to carry IPv4, multicast, or an IGP back home. Do we have to explicitly say all this? Maybe we could move it to "usages"? Pascal From nemo-admin@ietf.org Tue Dec 2 05:44:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11431 for ; Tue, 2 Dec 2003 05:44: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 1AR80g-0000Po-46; Tue, 02 Dec 2003 05:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR80Y-0000PP-3x for nemo@optimus.ietf.org; Tue, 02 Dec 2003 05:43: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 FAA11401 for ; Tue, 2 Dec 2003 05:43:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR80U-0004nI-00 for nemo@ietf.org; Tue, 02 Dec 2003 05:43:50 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AR80T-0004mi-00 for nemo@ietf.org; Tue, 02 Dec 2003 05:43:49 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Dec 2003 11:40:28 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB2Ah1DW024313; Tue, 2 Dec 2003 11:43:02 +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); Tue, 2 Dec 2003 10:43:14 +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] review of the nemo basic spec Date: Tue, 2 Dec 2003 10:43:13 -0000 Message-ID: Thread-Topic: [nemo] review of the nemo basic spec Thread-Index: AcO4t1twzhaT5Oz/R2iehUUDNxIw4AACSDQQ From: "Pascal Thubert (pthubert)" To: "Jari Arkko" Cc: "Vijay Devarapalli" , X-OriginalArrivalTime: 02 Dec 2003 10:43:14.0764 (UTC) FILETIME=[16D320C0:01C3B8C1] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: mardi 2 d=E9cembre 2003 10:29 > To: Pascal Thubert (pthubert) > Cc: Vijay Devarapalli; nemo@ietf.org > Subject: Re: [nemo] review of the nemo basic spec >=20 > Pascal Thubert (pthubert) wrote: >=20 > > Note that for DHAAD, we need also to modify the Router Advertisement = Message to add a Nemo > bit... >=20 > Or a vector of capabilities bits for every HA... ok, maybe > that's an overkill. >=20 Well I think it's not in the end. This is why we started HAHA. But for = Nemo, maybe yes :) Pascal From exim@www1.ietf.org Tue Dec 2 05:44:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11446 for ; Tue, 2 Dec 2003 05:44: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 1AR80m-0000Ua-Kj for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 05:44:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Ai8BC001886 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 05:44:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR80m-0000UL-9o for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 05:44:08 -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 FAA11410 for ; Tue, 2 Dec 2003 05:43:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR80i-0004nc-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 05:44:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR80i-0004nX-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 05:44:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR80g-0000Po-46; Tue, 02 Dec 2003 05:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR80Y-0000PP-3x for nemo@optimus.ietf.org; Tue, 02 Dec 2003 05:43: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 FAA11401 for ; Tue, 2 Dec 2003 05:43:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR80U-0004nI-00 for nemo@ietf.org; Tue, 02 Dec 2003 05:43:50 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AR80T-0004mi-00 for nemo@ietf.org; Tue, 02 Dec 2003 05:43:49 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Dec 2003 11:40:28 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB2Ah1DW024313; Tue, 2 Dec 2003 11:43:02 +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); Tue, 2 Dec 2003 10:43:14 +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] review of the nemo basic spec Date: Tue, 2 Dec 2003 10:43:13 -0000 Message-ID: Thread-Topic: [nemo] review of the nemo basic spec Thread-Index: AcO4t1twzhaT5Oz/R2iehUUDNxIw4AACSDQQ From: "Pascal Thubert (pthubert)" To: "Jari Arkko" Cc: "Vijay Devarapalli" , X-OriginalArrivalTime: 02 Dec 2003 10:43:14.0764 (UTC) FILETIME=[16D320C0:01C3B8C1] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: mardi 2 d=E9cembre 2003 10:29 > To: Pascal Thubert (pthubert) > Cc: Vijay Devarapalli; nemo@ietf.org > Subject: Re: [nemo] review of the nemo basic spec >=20 > Pascal Thubert (pthubert) wrote: >=20 > > Note that for DHAAD, we need also to modify the Router Advertisement = Message to add a Nemo > bit... >=20 > Or a vector of capabilities bits for every HA... ok, maybe > that's an overkill. >=20 Well I think it's not in the end. This is why we started HAHA. But for = Nemo, maybe yes :) Pascal From nemo-admin@ietf.org Tue Dec 2 06:17:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12213 for ; Tue, 2 Dec 2003 06:17: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 1AR8Wb-0001rQ-5o; Tue, 02 Dec 2003 06:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR8Vi-0001ql-UL for nemo@optimus.ietf.org; Tue, 02 Dec 2003 06:16: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 GAA12167 for ; Tue, 2 Dec 2003 06:15:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR8Ve-000576-00 for nemo@ietf.org; Tue, 02 Dec 2003 06:16:02 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AR8Ve-000573-00 for nemo@ietf.org; Tue, 02 Dec 2003 06:16:02 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D1A3F6A901; Tue, 2 Dec 2003 13:16:02 +0200 (EET) Message-ID: <3FCC7364.90108@kolumbus.fi> Date: Tue, 02 Dec 2003 13:11:32 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: nemo@ietf.org Subject: Re: [nemo] review of the nemo basic spec 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: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >>You may be right, but then again describing the routing protocol >>behaviour in the basic spec will lead to a number of MUSTs or SHOULDs, >>or at least MAYs. We could avoid that, even if someone does that >>on their own, or if you develop a NEMO Dynamic Routing Extension >>later. >> > > > Are you suggesting to remove chapter 7 and say nothing? That would be one alternative yes. I think the draft has too many options at the moment. (Another alternative would be not have the static config option, that would also reduce the number of options. But I see there is some discussion about this already ...) >>The implications I was afraid of were related to a host >>becoming a router depending on movement detection results. >>I don't have any specific case where this would fail, I >>just worried about it. > > > This relates to the "ND model for routers" and the "ROUTERS" vs. > "routers" discussions in the v6WG list. A MR is always and definitely a > router, but we are talking here about the model that its applies when it > presents itself at ND level. An MR is a router between its ingress and tunnel interfaces, and a host on its attachment interface. When home, MR is a complete router. When it is still figuring out whether its at home or not, it is a router only on its ingress interface and a host on the egress interface. > Maybe the ND model is a bit limited. When a MR comes home in aggregated > mode, it presents itself as a Node (NA), but it would be beneficial to > advertise directly the prefixes for its MNPs, as not onlink. When a MR > comes home in extended mode, it may present itself in either way (NA or > RA), both unsatisfying. Well, you could arrange for the MR to always use NEMO, even when at home. Or forbid it to ever come home ;-) > The model I'm missing in ND is the "Network in a Node". For a Node with > a prefix inside it or behind it, or more generally a proxy. A Network in > Node Option (Nino) would help. Maybe it's just a prefix option in a NA, > but I suspect there'd be more information such as MTU, bandwidth, and > other metrics. If the answer to "is this node a router" is something else than YES/NO, we are now finding out that all the rules in the RFCs based on this question are starting to look funny... But what to do about that? I don't know yet... > If we go through the requirements, it seems fair to say that MR MUST > comply with MIPv6 as for the reqs on 8.1, 8.3 and MAY comply with 8.2. Sounds ok. > But I'm afraid that we need to extend 8.4 (for route setup) and to Extensions are fine too. > revisit 8.5 (to limit to MRHA tunnel, which is the requirement for > basic). Probably ok too. --Jari From nemo-admin@ietf.org Tue Dec 2 06:17:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12214 for ; Tue, 2 Dec 2003 06:17: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 1AR8Wb-0001rn-Kf; Tue, 02 Dec 2003 06:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR8Vp-0001qw-6G for nemo@optimus.ietf.org; Tue, 02 Dec 2003 06:16: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 GAA12170 for ; Tue, 2 Dec 2003 06:15:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR8Vl-00057C-00 for nemo@ietf.org; Tue, 02 Dec 2003 06:16:09 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AR8Vk-000579-00 for nemo@ietf.org; Tue, 02 Dec 2003 06:16:08 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id EF0586A901; Tue, 2 Dec 2003 13:16:09 +0200 (EET) Message-ID: <3FCC736C.6000005@kolumbus.fi> Date: Tue, 02 Dec 2003 13:11:40 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: Vijay Devarapalli , nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko 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: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > The routing protocol thing could be considered out of scope. Once the > MRHA tunnel is established, any manual tunnel can be used to carry IPv4, > multicast, or an IGP back home. Do we have to explicitly say all this? > Maybe we could move it to "usages"? That would work for me. I like modular specifications ;-) --Jari From exim@www1.ietf.org Tue Dec 2 06:17:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12230 for ; Tue, 2 Dec 2003 06:17:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR8Wf-0001tG-6m for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 06:17:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2BH554007259 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 06:17:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR8Wf-0001t0-2F for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 06:17: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 GAA12187 for ; Tue, 2 Dec 2003 06:16:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR8Wa-000581-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 06:17:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR8Wa-00057x-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 06:17:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR8Wb-0001rQ-5o; Tue, 02 Dec 2003 06:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR8Vi-0001ql-UL for nemo@optimus.ietf.org; Tue, 02 Dec 2003 06:16: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 GAA12167 for ; Tue, 2 Dec 2003 06:15:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR8Ve-000576-00 for nemo@ietf.org; Tue, 02 Dec 2003 06:16:02 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AR8Ve-000573-00 for nemo@ietf.org; Tue, 02 Dec 2003 06:16:02 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D1A3F6A901; Tue, 2 Dec 2003 13:16:02 +0200 (EET) Message-ID: <3FCC7364.90108@kolumbus.fi> Date: Tue, 02 Dec 2003 13:11:32 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: nemo@ietf.org Subject: Re: [nemo] review of the nemo basic spec 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >>You may be right, but then again describing the routing protocol >>behaviour in the basic spec will lead to a number of MUSTs or SHOULDs, >>or at least MAYs. We could avoid that, even if someone does that >>on their own, or if you develop a NEMO Dynamic Routing Extension >>later. >> > > > Are you suggesting to remove chapter 7 and say nothing? That would be one alternative yes. I think the draft has too many options at the moment. (Another alternative would be not have the static config option, that would also reduce the number of options. But I see there is some discussion about this already ...) >>The implications I was afraid of were related to a host >>becoming a router depending on movement detection results. >>I don't have any specific case where this would fail, I >>just worried about it. > > > This relates to the "ND model for routers" and the "ROUTERS" vs. > "routers" discussions in the v6WG list. A MR is always and definitely a > router, but we are talking here about the model that its applies when it > presents itself at ND level. An MR is a router between its ingress and tunnel interfaces, and a host on its attachment interface. When home, MR is a complete router. When it is still figuring out whether its at home or not, it is a router only on its ingress interface and a host on the egress interface. > Maybe the ND model is a bit limited. When a MR comes home in aggregated > mode, it presents itself as a Node (NA), but it would be beneficial to > advertise directly the prefixes for its MNPs, as not onlink. When a MR > comes home in extended mode, it may present itself in either way (NA or > RA), both unsatisfying. Well, you could arrange for the MR to always use NEMO, even when at home. Or forbid it to ever come home ;-) > The model I'm missing in ND is the "Network in a Node". For a Node with > a prefix inside it or behind it, or more generally a proxy. A Network in > Node Option (Nino) would help. Maybe it's just a prefix option in a NA, > but I suspect there'd be more information such as MTU, bandwidth, and > other metrics. If the answer to "is this node a router" is something else than YES/NO, we are now finding out that all the rules in the RFCs based on this question are starting to look funny... But what to do about that? I don't know yet... > If we go through the requirements, it seems fair to say that MR MUST > comply with MIPv6 as for the reqs on 8.1, 8.3 and MAY comply with 8.2. Sounds ok. > But I'm afraid that we need to extend 8.4 (for route setup) and to Extensions are fine too. > revisit 8.5 (to limit to MRHA tunnel, which is the requirement for > basic). Probably ok too. --Jari From exim@www1.ietf.org Tue Dec 2 06:17:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12235 for ; Tue, 2 Dec 2003 06:17: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 1AR8Wf-0001tV-D7 for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 06:17:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2BH5h8007275 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 06:17:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR8Wf-0001t7-6h for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 06:17: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 GAA12188 for ; Tue, 2 Dec 2003 06:16:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR8Wa-000584-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 06:17:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR8Wa-00057y-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 06:17:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR8Wb-0001rn-Kf; Tue, 02 Dec 2003 06:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR8Vp-0001qw-6G for nemo@optimus.ietf.org; Tue, 02 Dec 2003 06:16: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 GAA12170 for ; Tue, 2 Dec 2003 06:15:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR8Vl-00057C-00 for nemo@ietf.org; Tue, 02 Dec 2003 06:16:09 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AR8Vk-000579-00 for nemo@ietf.org; Tue, 02 Dec 2003 06:16:08 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id EF0586A901; Tue, 2 Dec 2003 13:16:09 +0200 (EET) Message-ID: <3FCC736C.6000005@kolumbus.fi> Date: Tue, 02 Dec 2003 13:11:40 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: Vijay Devarapalli , nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > The routing protocol thing could be considered out of scope. Once the > MRHA tunnel is established, any manual tunnel can be used to carry IPv4, > multicast, or an IGP back home. Do we have to explicitly say all this? > Maybe we could move it to "usages"? That would work for me. I like modular specifications ;-) --Jari From nemo-admin@ietf.org Tue Dec 2 06:20:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12343 for ; Tue, 2 Dec 2003 06:20:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR8ZY-00027q-Aj; Tue, 02 Dec 2003 06: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 1AR8ZM-00026q-9z for nemo@optimus.ietf.org; Tue, 02 Dec 2003 06:19: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 GAA12311 for ; Tue, 2 Dec 2003 06:19:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR8ZI-00059y-00 for nemo@ietf.org; Tue, 02 Dec 2003 06:19:48 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AR8ZH-00059v-00 for nemo@ietf.org; Tue, 02 Dec 2003 06:19:47 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id EA9B46A901; Tue, 2 Dec 2003 13:19:48 +0200 (EET) Message-ID: <3FCC7447.4000504@kolumbus.fi> Date: Tue, 02 Dec 2003 13:15:19 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: Vijay Devarapalli , nemo@ietf.org Subject: Re: [nemo] review of the nemo basic spec 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: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Well I think it's not in the end. This is why we started HAHA. But for Nemo, maybe yes :) If there are multiple features (and there will be, nemo, haha, security extensions, and so on), response flags would probably work better than request flags. The problem with request flags is that if you don't get exactly what you asked for, you are stuck with trying a bunch of other combinations. With response flags you can see what the nodes support, and go from there. That being said, I'm not sure if the DHAAD response has a suitable place for response flags per home agent. --Jari From exim@www1.ietf.org Tue Dec 2 06:20:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12373 for ; Tue, 2 Dec 2003 06:20: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 1AR8Zi-0002FU-2q for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 06:20:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2BKDQ4008627 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 06:20:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR8Zg-0002Es-9h for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 06:20: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 GAA12329 for ; Tue, 2 Dec 2003 06:19:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR8Zc-0005AL-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 06:20:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR8Zb-0005AC-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 06:20:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR8ZY-00027q-Aj; Tue, 02 Dec 2003 06: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 1AR8ZM-00026q-9z for nemo@optimus.ietf.org; Tue, 02 Dec 2003 06:19: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 GAA12311 for ; Tue, 2 Dec 2003 06:19:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR8ZI-00059y-00 for nemo@ietf.org; Tue, 02 Dec 2003 06:19:48 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AR8ZH-00059v-00 for nemo@ietf.org; Tue, 02 Dec 2003 06:19:47 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id EA9B46A901; Tue, 2 Dec 2003 13:19:48 +0200 (EET) Message-ID: <3FCC7447.4000504@kolumbus.fi> Date: Tue, 02 Dec 2003 13:15:19 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: Vijay Devarapalli , nemo@ietf.org Subject: Re: [nemo] review of the nemo basic spec 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Well I think it's not in the end. This is why we started HAHA. But for Nemo, maybe yes :) If there are multiple features (and there will be, nemo, haha, security extensions, and so on), response flags would probably work better than request flags. The problem with request flags is that if you don't get exactly what you asked for, you are stuck with trying a bunch of other combinations. With response flags you can see what the nodes support, and go from there. That being said, I'm not sure if the DHAAD response has a suitable place for response flags per home agent. --Jari From nemo-admin@ietf.org Tue Dec 2 07:58:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15014 for ; Tue, 2 Dec 2003 07:58: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 1ARA6L-00069n-3U; Tue, 02 Dec 2003 07:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARA68-00069b-DR for nemo@optimus.ietf.org; Tue, 02 Dec 2003 07:57: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 HAA15004 for ; Tue, 2 Dec 2003 07:57:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARA67-0006tA-00 for nemo@ietf.org; Tue, 02 Dec 2003 07:57:47 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARA67-0006sX-00 for nemo@ietf.org; Tue, 02 Dec 2003 07:57:47 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Dec 2003 13:54:29 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB2Cv2IS001916; Tue, 2 Dec 2003 13:57:02 +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); Tue, 2 Dec 2003 12:57:14 +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 Subject: RE: [nemo] review of the nemo basic spec Date: Tue, 2 Dec 2003 12:57:13 -0000 Message-ID: Thread-Topic: [nemo] review of the nemo basic spec Thread-Index: AcO4xbTNQJS+4ndSRfO8ENYjdkrD8QADAHrA From: "Pascal Thubert (pthubert)" To: "Jari Arkko" Cc: X-OriginalArrivalTime: 02 Dec 2003 12:57:14.0989 (UTC) FILETIME=[CF2C19D0:01C3B8D3] 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 > > > > This relates to the "ND model for routers" and the "ROUTERS" vs. > > "routers" discussions in the v6WG list. A MR is always and definitely a > > router, but we are talking here about the model that its applies when it > > presents itself at ND level. >=20 > An MR is a router between its ingress and tunnel interfaces, > and a host on its attachment interface. When home, MR is a complete > router. When it is still figuring out whether its at home or not, > it is a router only on its ingress interface and a host on the > egress interface. Technically, since the MR forwards packets across interfaces (including the egress) it is still a router... We are talking about the ND model that it uses to present itself at the egress, right? ND was not designed to represent a node with a subnet in or behind it, a node that does not wish to be used as a router by other nodes but can receive packets or bridge them for that particular subnet. We're missing NA for a subnet, we're missing proxy NA... =20 >=20 > > Maybe the ND model is a bit limited. When a MR comes home in aggregated > > mode, it presents itself as a Node (NA), but it would be beneficial to > > advertise directly the prefixes for its MNPs, as not onlink. When a MR > > comes home in extended mode, it may present itself in either way (NA or > > RA), both unsatisfying. >=20 > Well, you could arrange for the MR to always use NEMO, even > when at home. Or forbid it to ever come home ;-) >=20 The work on proxy ND has already started. ND is being reworked. I think it's possible to express what we would really like to have for MRs in a problem statement and see with v6WG whether someone is willing to help. What do you think? > > The model I'm missing in ND is the "Network in a Node". For a Node with > > a prefix inside it or behind it, or more generally a proxy. A Network in > > Node Option (Nino) would help. Maybe it's just a prefix option in a NA, > > but I suspect there'd be more information such as MTU, bandwidth, and > > other metrics. >=20 > If the answer to "is this node a router" is something else than YES/NO, > we are now finding out that all the rules in the RFCs based on this > question are starting to look funny... >=20 > But what to do about that? I don't know yet... >=20 :) Pascal From exim@www1.ietf.org Tue Dec 2 07:58:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15029 for ; Tue, 2 Dec 2003 07:58: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 1ARA6O-0006An-Mr for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 07:58:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Cw4RV023723 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 07:58:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARA6O-0006AY-II for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 07: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 HAA15008 for ; Tue, 2 Dec 2003 07:57:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARA6N-0006tW-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 07:58:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARA6N-0006tT-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 07:58:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARA6L-00069n-3U; Tue, 02 Dec 2003 07:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARA68-00069b-DR for nemo@optimus.ietf.org; Tue, 02 Dec 2003 07:57: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 HAA15004 for ; Tue, 2 Dec 2003 07:57:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARA67-0006tA-00 for nemo@ietf.org; Tue, 02 Dec 2003 07:57:47 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARA67-0006sX-00 for nemo@ietf.org; Tue, 02 Dec 2003 07:57:47 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Dec 2003 13:54:29 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB2Cv2IS001916; Tue, 2 Dec 2003 13:57:02 +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); Tue, 2 Dec 2003 12:57:14 +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 Subject: RE: [nemo] review of the nemo basic spec Date: Tue, 2 Dec 2003 12:57:13 -0000 Message-ID: Thread-Topic: [nemo] review of the nemo basic spec Thread-Index: AcO4xbTNQJS+4ndSRfO8ENYjdkrD8QADAHrA From: "Pascal Thubert (pthubert)" To: "Jari Arkko" Cc: X-OriginalArrivalTime: 02 Dec 2003 12:57:14.0989 (UTC) FILETIME=[CF2C19D0:01C3B8D3] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > > > This relates to the "ND model for routers" and the "ROUTERS" vs. > > "routers" discussions in the v6WG list. A MR is always and definitely a > > router, but we are talking here about the model that its applies when it > > presents itself at ND level. >=20 > An MR is a router between its ingress and tunnel interfaces, > and a host on its attachment interface. When home, MR is a complete > router. When it is still figuring out whether its at home or not, > it is a router only on its ingress interface and a host on the > egress interface. Technically, since the MR forwards packets across interfaces (including the egress) it is still a router... We are talking about the ND model that it uses to present itself at the egress, right? ND was not designed to represent a node with a subnet in or behind it, a node that does not wish to be used as a router by other nodes but can receive packets or bridge them for that particular subnet. We're missing NA for a subnet, we're missing proxy NA... =20 >=20 > > Maybe the ND model is a bit limited. When a MR comes home in aggregated > > mode, it presents itself as a Node (NA), but it would be beneficial to > > advertise directly the prefixes for its MNPs, as not onlink. When a MR > > comes home in extended mode, it may present itself in either way (NA or > > RA), both unsatisfying. >=20 > Well, you could arrange for the MR to always use NEMO, even > when at home. Or forbid it to ever come home ;-) >=20 The work on proxy ND has already started. ND is being reworked. I think it's possible to express what we would really like to have for MRs in a problem statement and see with v6WG whether someone is willing to help. What do you think? > > The model I'm missing in ND is the "Network in a Node". For a Node with > > a prefix inside it or behind it, or more generally a proxy. A Network in > > Node Option (Nino) would help. Maybe it's just a prefix option in a NA, > > but I suspect there'd be more information such as MTU, bandwidth, and > > other metrics. >=20 > If the answer to "is this node a router" is something else than YES/NO, > we are now finding out that all the rules in the RFCs based on this > question are starting to look funny... >=20 > But what to do about that? I don't know yet... >=20 :) Pascal From nemo-admin@ietf.org Tue Dec 2 10:00:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19637 for ; Tue, 2 Dec 2003 10:00: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 1ARC0Q-0002fF-TV; Tue, 02 Dec 2003 10:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARBzR-0002eN-Iw for nemo@optimus.ietf.org; Tue, 02 Dec 2003 09:59: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 JAA19585 for ; Tue, 2 Dec 2003 09:58:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARBzP-0001tZ-00 for nemo@ietf.org; Tue, 02 Dec 2003 09:58:59 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARBzP-0001tR-00 for nemo@ietf.org; Tue, 02 Dec 2003 09:58:59 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Dec 2003 15:55:41 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB2EwEIn010687; Tue, 2 Dec 2003 15:58:14 +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); Tue, 2 Dec 2003 14:58:27 +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] review of the nemo basic spec Date: Tue, 2 Dec 2003 14:58:26 -0000 Message-ID: Thread-Topic: [nemo] review of the nemo basic spec Thread-Index: AcO4qvRAOLwVj1fAQH2TY41lWOxyiQAOMhOw From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Jari Arkko" Cc: X-OriginalArrivalTime: 02 Dec 2003 14:58:27.0362 (UTC) FILETIME=[BDD82820:01C3B8E4] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mardi 2 d=E9cembre 2003 09:04 > To: Jari Arkko > Cc: Pascal Thubert (pthubert); nemo@ietf.org > Subject: Re: [nemo] review of the nemo basic spec >=20 >=20 > > I think I agree that modifying DHAAD was a good thing to > > do. WHat I am less sure about is whether that is sufficient. > > One thing is that I'd rather not do DHAAD at all, if I can avoid > > it. >=20 > okay. apart from DHAAD and manual configuration, how else is > the mobile router assigned a Home Agent? >=20 > > The second thing is making the decision of what you support > > local. The HA that responds to a BU certainly knows what > > it supports; another home agent might not know, for sure, > > what the other home agents support. Or at least there could > > be config errors in it. In conclusion, while I agree that > > DHAAD support is good, it may be necessary to make the > > BU/BA protocol itself robust enough to survive even > > mistakes or old information in DHAAD. Does that make > > sense? >=20 > I am not disagreeing with this. a flag in the binding ack which > says the Home Agent has setup forwarding for the mobile network > will do what you want. the question I have, is this extra > specification worth it for what I consider a corner case (a > configuration error)? >=20 If you consider the lifetime of a MR, it may happen that a configuration = that is right for some time becomes wrong. For instance if HAs are = reassigned for some reasons overtime. I agree with you it's not a = critical thing, but my inclination is to add the check. =20 Pascal From exim@www1.ietf.org Tue Dec 2 10:00:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19652 for ; Tue, 2 Dec 2003 10:00: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 1ARC0f-0002gZ-Hr for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 10:00:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2F0HFn010317 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 10:00:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARC0f-0002gK-Ce for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 10:00: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 KAA19624 for ; Tue, 2 Dec 2003 10:00:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARC0d-0001u2-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 10:00:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARC0c-0001tz-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 10:00:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARC0Q-0002fF-TV; Tue, 02 Dec 2003 10:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARBzR-0002eN-Iw for nemo@optimus.ietf.org; Tue, 02 Dec 2003 09:59: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 JAA19585 for ; Tue, 2 Dec 2003 09:58:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARBzP-0001tZ-00 for nemo@ietf.org; Tue, 02 Dec 2003 09:58:59 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARBzP-0001tR-00 for nemo@ietf.org; Tue, 02 Dec 2003 09:58:59 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Dec 2003 15:55:41 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB2EwEIn010687; Tue, 2 Dec 2003 15:58:14 +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); Tue, 2 Dec 2003 14:58:27 +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] review of the nemo basic spec Date: Tue, 2 Dec 2003 14:58:26 -0000 Message-ID: Thread-Topic: [nemo] review of the nemo basic spec Thread-Index: AcO4qvRAOLwVj1fAQH2TY41lWOxyiQAOMhOw From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Jari Arkko" Cc: X-OriginalArrivalTime: 02 Dec 2003 14:58:27.0362 (UTC) FILETIME=[BDD82820:01C3B8E4] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mardi 2 d=E9cembre 2003 09:04 > To: Jari Arkko > Cc: Pascal Thubert (pthubert); nemo@ietf.org > Subject: Re: [nemo] review of the nemo basic spec >=20 >=20 > > I think I agree that modifying DHAAD was a good thing to > > do. WHat I am less sure about is whether that is sufficient. > > One thing is that I'd rather not do DHAAD at all, if I can avoid > > it. >=20 > okay. apart from DHAAD and manual configuration, how else is > the mobile router assigned a Home Agent? >=20 > > The second thing is making the decision of what you support > > local. The HA that responds to a BU certainly knows what > > it supports; another home agent might not know, for sure, > > what the other home agents support. Or at least there could > > be config errors in it. In conclusion, while I agree that > > DHAAD support is good, it may be necessary to make the > > BU/BA protocol itself robust enough to survive even > > mistakes or old information in DHAAD. Does that make > > sense? >=20 > I am not disagreeing with this. a flag in the binding ack which > says the Home Agent has setup forwarding for the mobile network > will do what you want. the question I have, is this extra > specification worth it for what I consider a corner case (a > configuration error)? >=20 If you consider the lifetime of a MR, it may happen that a configuration = that is right for some time becomes wrong. For instance if HAs are = reassigned for some reasons overtime. I agree with you it's not a = critical thing, but my inclination is to add the check. =20 Pascal From nemo-admin@ietf.org Tue Dec 2 11:15:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24499 for ; Tue, 2 Dec 2003 11:15:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDB0-0006Lv-CO; Tue, 02 Dec 2003 11:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDA5-0006KE-KG for nemo@optimus.ietf.org; Tue, 02 Dec 2003 11:14: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 LAA24316 for ; Tue, 2 Dec 2003 11:13:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDA4-0003Bk-00 for nemo@ietf.org; Tue, 02 Dec 2003 11:14:04 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARDA3-0003BO-00 for nemo@ietf.org; Tue, 02 Dec 2003 11:14:03 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Dec 2003 17:10:45 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB2GDInF008577; Tue, 2 Dec 2003 17:13:18 +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); Tue, 2 Dec 2003 16:13:31 +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: Tue, 2 Dec 2003 16:13:30 -0000 Message-ID: Thread-Topic: issue xxx: requirements chapter for Nemo. Thread-Index: AcO47ttTb1Kcj6+cQN+IsI7W07JrrA== From: "Pascal Thubert (pthubert)" To: , "Jari Arkko" Cc: X-OriginalArrivalTime: 02 Dec 2003 16:13:31.0204 (UTC) FILETIME=[3A57E840:01C3B8EF] Content-Transfer-Encoding: quoted-printable Subject: [nemo] issue xxx: requirements chapter for 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: quoted-printable Hi:=20 I understand from the discussion with Jari that we could (should) open an issue regarding the equivalent of [MIPv6] chapter 8, that appears to be missing from basic nemo. Here's my view of what that text could be (largely inheriting from [MIPv6]). What do you think? 8. Requirements for Types of IPv6 Nodes Basic Nemo extends the requirements placed by Mobile IPv6 on the=20 functions provided by different types of IPv6 nodes. This section summarizes those requirements, identifying the functionality each=20 requirement is intended to support. Note that the category 'mobile node' that is used in [MIPv6] really applies to mobile hosts and excludes=20 mobile routers which are placed in a separate category. The requirements are set for the following groups of nodes: o All IPv6 nodes. o All IPv6 nodes with support for route optimization. o All IPv6 routers. o All Mobile IPv6 home agents. o All Mobile IPv6 mobile nodes. o All Mobile IPv6 mobile routers. It is outside the scope of this specification to specify which of these groups are mandatory in IPv6. We only describe what is mandatory for a router that supports network mobility. Other specifications are expected to define the extent of IPv6. 8.1 All IPv6 Nodes There are no Basic Nemo specific MUST requirements for such nodes,=20 and basic IPv6 techniques are sufficient. 8.2 IPv6 Nodes with Support for [MIPv6] Route Optimization Basic Nemo does not introduce a specific route optimization for Mobile Networks. If a Mobile Router acts as a [MIPv6] Mobile Node, the Route Optimization follows the [MIPv6] rules with the same requirements no the Correspondents. The Mobility of a Network is transparent to the Visiting Mobile Nodes and does not create any additional requirement on the=20 Correspondent. 8.3 All IPv6 Routers Basic Nemo uses the movement detection mechanisms as described in [MIPv6],=20 and places the same requirements on all routers as [MIPv6] does. 8.4 IPv6 Home Agents A Nemo Home Agent extends the feature set of a Mobile IPv6 HA. As such,=20 It MUST support all the features described in [MIPv6] chapter 8.4. and=20 process [MIPv6] messages per the [MIPv6] specification for all Mobile Nodes. On top of that, the following additional requirements apply to all [MIPv6]=20 Home Agents in order to serve as a Nemo Home Agent: o Every home agent MUST recognize the mobility messages associated to=20 mobile routers and support both the implicit and explicit prefix modes. A home agent MAY optionally support an other routing protocol over the MRHA tunnel. o Every home agent MUST support establishing and tearing down a bidirectional=20 tunnel to a mobile router careOF address.=20 o Every home agent MUST support setting the forwarding states proactively (static routes) or reactively (upon registration) in order to route packets to the registered prefixes, via the mobile router home address or over the tunnel. o Every home agent MUST be able to authorize the registrations in explicit prefix mode prior to installing the associated forwarding states. o Every home agent MUST fully support IPv6 tunneling [RFC2473] for MRHA tunnel.=20 For packets sent received from a mobile router's careOf address, every home agent MUST check that the inner packet is topologically correct. o Every home agent MUST be able to return a Binding Acknowledgement in response to a Binding Update (Section 10.3.1). o Every home agent MUST maintain a separate Home Agents List for each link on which it is serving as a home agent, as described in [MIPv6] Section 10.1 and 10.5.1, and in Section 7. o Every home agent SHOULD be able to intercept packets (using proxy Neighbor Discovery [RFC2461]) addressed to a node on a mobile network Associated with a mobile router for which it has an active binding on that mobile router's home Link.=20 (note: This is used in the aggregated physical Home Net only, thus the SHOULD) o Every home agent performing that interception MUST be able=20 to encapsulate [RFC2473] such intercepted packets in order to tunnel=20 them to the primary care-of address for the mobile router for which=20 the forwarding states are established. 8.5 IPv6 Mobile Nodes Basic Nemo is transparent to the activity of MIPv6 Mobile Nodes and does not require any specific support from those. =20 8.6 IPv6 Mobile Routers Finally, the following requirements apply to all IPv6 routers capable of functioning as mobile routers: o The router MUST comply with the MIPv6 requirements on all nodes and=20 on all routers ([MIPv6] Sections 8.1 and 8.3). It MAY comply with=20 section 8.2 as well.=20 o The router MUST support establishing and tearing down a bidirectional=20 tunnel to its Home Agent and a default route over that tunnel.=20 It MUST support forwarding packets between that tunnel and the Mobile Networks.=20 o The router MUST support at least one of the 2 modes, implicit or explicit prefix, for its Home registration as a mobile router. It SHOULD support both. It MAY support additional routing protocols over the MRHA tunnel. =20 o The router MUST support sending packets containing a Home Address option ([MIPv6] Section 11.3.1), and follow the required IPsec interaction ([MIPv6] Section 11.3.2). o The router MUST fully support [RFC2473]. As such, it MUST be able to=20 perform IPv6 encapsulation and decapsulation, ICMP forwarding and PMTU discovery. o The router MUST be able to process type 2 routing header as defined in [MIPv6] Section 6.4 and Section 11.3.3. o The router MUST support receiving a Binding Error message ([MIPv6] Section 11.3.6). o The router MUST support receiving ICMP errors ([MIPv6] Section 11.3.5). o The router MUST support movement detection, care-of address formation. It MAY also support returning home. o The router MUST be able to process Mobility Headers as described in [MIPv6] and Section 5. o The router MUST be able to send Binding Updates, as specified in=20 Section 5.2. o The router MUST be able to receive and process Binding Acknowledgements, as specified in Section 5.3. o The router MUST support receiving a Binding Refresh Request ([MIPv6]=20 Section 6.1.2), by responding with a Binding Update (section 5.2). o The router SHOULD support use of the dynamic home agent address discovery mechanism, as described in Section 7. ? The router MAY support receiving Mobile Prefix Advertisements (Section 11.4.3) and reconfiguring its home address based on the prefix information contained therein. o The router MAY support stateful address autoconfiguration mechanisms such as DHCPv6 [29] on the interface represented by the tunnel to the home agent. From exim@www1.ietf.org Tue Dec 2 11:15:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24514 for ; Tue, 2 Dec 2003 11: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 1ARDB5-0006OW-Jj for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 11:15:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2GF7vI024574 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 11:15:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDB5-0006OH-F7 for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 11:15:07 -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 LAA24423 for ; Tue, 2 Dec 2003 11:14:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDB4-0003F3-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 11:15:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARDB4-0003F0-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 11:15:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDB0-0006Lv-CO; Tue, 02 Dec 2003 11:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDA5-0006KE-KG for nemo@optimus.ietf.org; Tue, 02 Dec 2003 11:14: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 LAA24316 for ; Tue, 2 Dec 2003 11:13:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDA4-0003Bk-00 for nemo@ietf.org; Tue, 02 Dec 2003 11:14:04 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARDA3-0003BO-00 for nemo@ietf.org; Tue, 02 Dec 2003 11:14:03 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Dec 2003 17:10:45 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB2GDInF008577; Tue, 2 Dec 2003 17:13:18 +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); Tue, 2 Dec 2003 16:13:31 +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: Tue, 2 Dec 2003 16:13:30 -0000 Message-ID: Thread-Topic: issue xxx: requirements chapter for Nemo. Thread-Index: AcO47ttTb1Kcj6+cQN+IsI7W07JrrA== From: "Pascal Thubert (pthubert)" To: , "Jari Arkko" Cc: X-OriginalArrivalTime: 02 Dec 2003 16:13:31.0204 (UTC) FILETIME=[3A57E840:01C3B8EF] Content-Transfer-Encoding: quoted-printable Subject: [nemo] issue xxx: requirements chapter for 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: quoted-printable Content-Transfer-Encoding: quoted-printable Hi:=20 I understand from the discussion with Jari that we could (should) open an issue regarding the equivalent of [MIPv6] chapter 8, that appears to be missing from basic nemo. Here's my view of what that text could be (largely inheriting from [MIPv6]). What do you think? 8. Requirements for Types of IPv6 Nodes Basic Nemo extends the requirements placed by Mobile IPv6 on the=20 functions provided by different types of IPv6 nodes. This section summarizes those requirements, identifying the functionality each=20 requirement is intended to support. Note that the category 'mobile node' that is used in [MIPv6] really applies to mobile hosts and excludes=20 mobile routers which are placed in a separate category. The requirements are set for the following groups of nodes: o All IPv6 nodes. o All IPv6 nodes with support for route optimization. o All IPv6 routers. o All Mobile IPv6 home agents. o All Mobile IPv6 mobile nodes. o All Mobile IPv6 mobile routers. It is outside the scope of this specification to specify which of these groups are mandatory in IPv6. We only describe what is mandatory for a router that supports network mobility. Other specifications are expected to define the extent of IPv6. 8.1 All IPv6 Nodes There are no Basic Nemo specific MUST requirements for such nodes,=20 and basic IPv6 techniques are sufficient. 8.2 IPv6 Nodes with Support for [MIPv6] Route Optimization Basic Nemo does not introduce a specific route optimization for Mobile Networks. If a Mobile Router acts as a [MIPv6] Mobile Node, the Route Optimization follows the [MIPv6] rules with the same requirements no the Correspondents. The Mobility of a Network is transparent to the Visiting Mobile Nodes and does not create any additional requirement on the=20 Correspondent. 8.3 All IPv6 Routers Basic Nemo uses the movement detection mechanisms as described in [MIPv6],=20 and places the same requirements on all routers as [MIPv6] does. 8.4 IPv6 Home Agents A Nemo Home Agent extends the feature set of a Mobile IPv6 HA. As such,=20 It MUST support all the features described in [MIPv6] chapter 8.4. and=20 process [MIPv6] messages per the [MIPv6] specification for all Mobile Nodes. On top of that, the following additional requirements apply to all [MIPv6]=20 Home Agents in order to serve as a Nemo Home Agent: o Every home agent MUST recognize the mobility messages associated to=20 mobile routers and support both the implicit and explicit prefix modes. A home agent MAY optionally support an other routing protocol over the MRHA tunnel. o Every home agent MUST support establishing and tearing down a bidirectional=20 tunnel to a mobile router careOF address.=20 o Every home agent MUST support setting the forwarding states proactively (static routes) or reactively (upon registration) in order to route packets to the registered prefixes, via the mobile router home address or over the tunnel. o Every home agent MUST be able to authorize the registrations in explicit prefix mode prior to installing the associated forwarding states. o Every home agent MUST fully support IPv6 tunneling [RFC2473] for MRHA tunnel.=20 For packets sent received from a mobile router's careOf address, every home agent MUST check that the inner packet is topologically correct. o Every home agent MUST be able to return a Binding Acknowledgement in response to a Binding Update (Section 10.3.1). o Every home agent MUST maintain a separate Home Agents List for each link on which it is serving as a home agent, as described in [MIPv6] Section 10.1 and 10.5.1, and in Section 7. o Every home agent SHOULD be able to intercept packets (using proxy Neighbor Discovery [RFC2461]) addressed to a node on a mobile network Associated with a mobile router for which it has an active binding on that mobile router's home Link.=20 (note: This is used in the aggregated physical Home Net only, thus the SHOULD) o Every home agent performing that interception MUST be able=20 to encapsulate [RFC2473] such intercepted packets in order to tunnel=20 them to the primary care-of address for the mobile router for which=20 the forwarding states are established. 8.5 IPv6 Mobile Nodes Basic Nemo is transparent to the activity of MIPv6 Mobile Nodes and does not require any specific support from those. =20 8.6 IPv6 Mobile Routers Finally, the following requirements apply to all IPv6 routers capable of functioning as mobile routers: o The router MUST comply with the MIPv6 requirements on all nodes and=20 on all routers ([MIPv6] Sections 8.1 and 8.3). It MAY comply with=20 section 8.2 as well.=20 o The router MUST support establishing and tearing down a bidirectional=20 tunnel to its Home Agent and a default route over that tunnel.=20 It MUST support forwarding packets between that tunnel and the Mobile Networks.=20 o The router MUST support at least one of the 2 modes, implicit or explicit prefix, for its Home registration as a mobile router. It SHOULD support both. It MAY support additional routing protocols over the MRHA tunnel. =20 o The router MUST support sending packets containing a Home Address option ([MIPv6] Section 11.3.1), and follow the required IPsec interaction ([MIPv6] Section 11.3.2). o The router MUST fully support [RFC2473]. As such, it MUST be able to=20 perform IPv6 encapsulation and decapsulation, ICMP forwarding and PMTU discovery. o The router MUST be able to process type 2 routing header as defined in [MIPv6] Section 6.4 and Section 11.3.3. o The router MUST support receiving a Binding Error message ([MIPv6] Section 11.3.6). o The router MUST support receiving ICMP errors ([MIPv6] Section 11.3.5). o The router MUST support movement detection, care-of address formation. It MAY also support returning home. o The router MUST be able to process Mobility Headers as described in [MIPv6] and Section 5. o The router MUST be able to send Binding Updates, as specified in=20 Section 5.2. o The router MUST be able to receive and process Binding Acknowledgements, as specified in Section 5.3. o The router MUST support receiving a Binding Refresh Request ([MIPv6]=20 Section 6.1.2), by responding with a Binding Update (section 5.2). o The router SHOULD support use of the dynamic home agent address discovery mechanism, as described in Section 7. ? The router MAY support receiving Mobile Prefix Advertisements (Section 11.4.3) and reconfiguring its home address based on the prefix information contained therein. o The router MAY support stateful address autoconfiguration mechanisms such as DHCPv6 [29] on the interface represented by the tunnel to the home agent. From nemo-admin@ietf.org Tue Dec 2 14:59:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05277 for ; Tue, 2 Dec 2003 14:59: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 1ARGfk-0004sh-PQ; Tue, 02 Dec 2003 14:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGex-0004rv-21 for nemo@optimus.ietf.org; Tue, 02 Dec 2003 14:58:11 -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 OAA05219 for ; Tue, 2 Dec 2003 14:57:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGeu-0007Ja-00 for nemo@ietf.org; Tue, 02 Dec 2003 14:58:08 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARGet-0007Il-00 for nemo@ietf.org; Tue, 02 Dec 2003 14:58:07 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB2JvX313823; Tue, 2 Dec 2003 11:57:33 -0800 X-mProtect: <200312021957> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9tReAU; Tue, 02 Dec 2003 11:57:32 PST Message-ID: <3FCCEFF1.7090009@iprg.nokia.com> Date: Tue, 02 Dec 2003 12:02:57 -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: Jari Arkko CC: nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko References: <3FCBF3DE.7050202@iprg.nokia.com> <3FCC5A7B.4080509@kolumbus.fi> In-Reply-To: <3FCC5A7B.4080509@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jari Arkko wrote: >>> JARI: Hmm... there might be value in defining the terms in a >>> self-contained >>> manner here. I'm pretty sure you only use a subset of [8] terms, >>> so it wouldn't be that long. >> >> >> >> I also believe in a document being self contained when it comes >> to terminology. but there is a separate WG document on NEMO >> terminology that is being advanced as an informational RFC. so >> I am not sure. > > > I think that other document would have value even if you > copied some of the terms (used ones) to the basic nemo > document. > > Anyway, I don't think it is crucial. Just a practical issue > that I noticed when reading. I am okay with copying some of the terms from the terminology document so that the basic support spec is self contained. if nobody has any objection I will go ahead and do this. > >>> Prefix Table >>> >>> It is a list of a Mobile Network Prefixes indexed >>> by the Home Address of a Mobile Router. The prefix table >>> is managed by the Home Agent and is used by the Home Agent >>> to determine which Mobile Network Prefixes are owned >>> a particular Mobile Router. This is an optional data >>> structure. >>> >>> JARI: Really? Why is it optional? Sounds mandatory to me... >> >> >> >> well, there could be scenarios where the mobile routers are not >> expected to misbehave. and there could be other ways for verifying >> this. so we left it optional. I dont mind making it mandatory. > > > That would make sense. you mean making it mandatory makes sense? maybe a SHOULD, not a MUST. > Imho all nemo-based products > should support this function. I agree too. > >>> A Mobile Network is a network segment or subnet which can move >>> and attach to arbitrary points in the Internet. A Mobile Network >>> does not allow any transit traffic and can only be accessed via >>> specific gateways called Mobile Routers that manage its movement. >>> >>> JARI: The above is a bit unclear. I think you mean that the >>> nodes behind the MR can't access the internet directly, they >>> have to go through the MR and the HA. >> >> >> >> actually no. it means traffic to the Mobile Network can reach >> the Mobile Network only through mobile routers. it also says >> mobile networks are not transit networks. always stub networks. > > > I'm still having some difficulty with the transit network > part. I looked up one definition of a transit network from RFC > 1584, which talks about the number of attached routers. However, > in the nested nemo case you could actually have several attached > routers, hidden inside tunnels. And would you allow multiple > MRs per Mobile Network or not? I think not, because then you > would appear like a transit network, according to the > RFC 1584 definition. OTOH, I'm not sure why such a limitation > would be necessary in the technical sense. > > Is it allowed for an MR to have two home agents, home addresses, > and network prefixes? Is there any case where the Mobile Network > would become a transit network in such a situation? > > How about this: > > A Mobile Network is a network segment or subnet which can move > and attach to arbitrary points in the Internet. A Mobile Network > can only be accessed via specific gateways called Mobile Routers > that manage its movement. Mobile Networks have (always exactly)| > (at least) one Mobile Router serving them. fine with me. > >>> JARI: Come to think of it, both the MR and the HA must know the >>> assigned prefixes beforehand in any case, so I wonder if we >>> need to communicate the prefixes at all?!? Can you cite an >>> example where the HA would give a prefix to the MR without >>> knowing it belongs to it? Or is the idea to prepare for the >>> eventual bootstrapping support in MIPv6? >> >> >> >> well, we still havent figured out how to do prefix delegation >> to a mobile router. there is a draft by Ralph Droms on extending >> DHCPv6 prefix delegation for NEMO. not a WG draft yet. >> >> and there is this scenario, where the mobile router is delegated >> more than prefix, but it could decide to setup forwarding for just >> one prefix instead of all prefixes. this cant be dont without >> carrying prefix information in the Binding Update. > > > If this is the case, perhaps you could remove the static alternative > then? My concern is mainly the number of alternatives. I'd rather > have less alternatives, even if the BUs would carry a few more bytes > in some cases... I would rather remove the explicit prefix length mode. the implicit mode I think is needed for minimal implementations of mobile routers. they are also needed when routes are managed by manual configuartion at the Home Agent, i.e. the routes are always there on the Home Agent and are just modified to reflect the current point of attachment of the mobile router. > >>> JARI: So, presumably this includes forwarding of packets to >>> the MR's own home address under all these prefixes, no? >>> If so, I think we have the S=0 bit functionality when you >>> set R=1 ;-) >> >> >> >> :) only if the mobile router has configured all its home addresses >> from its MNPs. > > > Yeah. But to support S=0 all I have to do is to agree about > suitable prefixes with my home agent, and set R=1... > > I'm not really suggesting you change anything, just making > an observation. > > But doesn't this point to an additional reason for making > the Prefix Table functionality mandatory? How else would > the HA know which prefixes to give to the MR, if no prefixes > were mentioned in the BU? how about manually configured routes which always exist on the Home Agent. we should keep it open. it is internal to the Home Agent. > >>> JARI: Is there something that you would perhaps like to >>> reference from MIPv6 regarding this tunneling, or is [3] enough? >>> >> >> why? are we missing something. > > > Would it be useful to follow MIPv6 base Section 5.5 guidelines > on the use of source addresses? we already say in the spec (section 5.5), what the source and destination addresses should be for the inner and outer IPv6 headers when sending packets through the bi-directional tunnel. >>> This document introduces a new Prefix Information field in the >>> Binding Update list structure. This field is used to store any >>> prefix information that the Mobile Router includes in the Binding >>> Update. If the Mobile Router sets the Mobile Router flag 'R' in the >>> Binding Update, but does not include any prefix information in it >>> (implicit mode), this field is set to null. >>> >>> JARI: So, if you run a routing protocol over the tunnel, will this >>> information be updated in the BUL as well? >> >> >> >> I think its not needed when a routing protocol is being run. > > > Ok. Perhaps you could explicitly say this. okay. >>> 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. >>> >>> JARI: I wonder if the above paragraph could be replaced with >>> some reference to ND specs. As far as I can see, an MR should >>> follow ND rules on its egress interface when on a visited >>> network. >> >> >> >> if you go by ND specs, routers ignore router advertisements. we are >> infact saying router advertisements MUST NOT be ignored. > > > I guess this is related to the MR turning to a host, as far > as any external observer can determine, when it attaches to > a foreign network. right. implementors need to explicitly enable the mobile routers to process router advertisements received on its egress interface. > >>> The establishment and operation of the bi-directional tunnel is >>> implementation specific. However, all implementations MUST be >>> capable of the following operations. >>> >>> JARI: What does it mean that its implementation specific? What >>> specifically would you have to do to establish the tunnel >>> in the first place? Why can't this be specified? >> >> >> >> setting up and using tunnels is implementation specific. some >> people like to set them up as virtual interfaces. sometimes it >> is just code in the IP stack. > > > Perhaps you could change the text to avoid a perception > that the protocols are not fully defined. How about this: > > The implementation of the bi-directional tunnels and the mechanism > of attaching them to the IP stack are outside the scope of this > specification. However, all implementations MUST be capable of > the following operations. okay. > >>> The Home Agent either uses only the routing >>> table, only the Binding Cache or a combination of routing table >>> and Binding Cache to route packets to the mobile network. This is >>> implementation specific. Two examples are shown below. >>> >>> JARI: You are presenting the rules in a too implementation-near >>> form. Perhaps you could formulate something general >>> that has a MUST. >>> >> >> there is a problem with it. the binding cache is a conceptual >> data structure. sometimes it is just implemented as a routing >> table entry. one implementation (of mobile routers), I know, >> uses the binding cache for both routing and CoA lookup. so >> we left it implementation specific. and we present two ways >> of doing it. >> >> we had a long discussion on using the binding cache or routing >> table for the HA to forward packets to the mobile network. this >> discussion happened before this draft was written up. > > > Ok. > > (Perhaps you could change the first paragraph of 6.5 to > have a keyword. This would be the normative part, the rest > is implementation guidance.) I am not sure I got. is this what you are getting at? When the Home Agent receives a data packet destined for the mobile network, it MUST forward the packet to the Mobile Router through the bi-directional tunnel. The Home Agent either uses only the routing table, only the Binding Cache or a combination of routing table and Binding Cache to route packets to the mobile network. This is implementation specific. Two examples are shown below. > >>> In the solution described so far, forwarding to the Mobile Network >>> at the Home Agent is set up when the Home Agent receives a Binding >>> Update from the Mobile Router. An alternative to this is for the >>> Home Agent and the Mobile Router to run an intra-domain routing >>> protocol like RIPng [10] and OSPF [11] through the bi-directional >>> tunnel. The Mobile Router can continue running the same routing >>> protocol that it was running when it was attached to the home link. >>> >>> This feature is very useful when the Mobile Network is large with >>> multiple subnets containing different IPv6 prefixes. Routing changes >>> >>> JARI: Can you give a practical example of where this could be the >>> case? I can't think of any, but maybe its just me... >> >> it could happen when there are multiple mobile networks attached >> to the mobile router, each one having different prefix, but want >> routing enabled for all these prefixes through the Home Agent. >> using a routing protocol makes sense here. > > I think the key question here is whether running the routing > protocol makes a difference in the end. Is it used to avoid > sending useless packets to the MR? Most likely such traffic > would be minimal, given that there would be no response from > the networks that are currently disconnected. Or is it used > to make some real routing changes, such as switching the > traffic from one HA site to another one? If yes, this needs > to be supported. what I would like to see is something we called a fully enabled case in another draft. the mobile router runs a routing protocol with its Home Agent to manage all routes. the mobile router also gets to know about the routes on the home domain through its Home Agent. the use of binding updates to do this is a poor substitute, IMO. > > Like I said above, I'm primarily concerned about the number > of alternatives and that's why I'm trying to see if we really > have a true need for all three, i.e. static, BU, and routing > protocol alternatives. I would like to enable the basic NEMO spec to be able to use a dynamic routing protocol. > >>> Since the routing protocol messages from the Home Agent to the Mobile >>> Router could potentically contain information about the internal >>> routing structure of the home network, these messages require >>> authentications and confidentiality protection. Confidentialy >>> protection using IPsec ESP [4] in tunnel mode MUST be supported and >>> SHOULD be used. >>> >>> >>> JARI: It might be necessary to have some more detail about this. >>> What kind of SPD entries are needed etc. >> >> should be straight forward. OSPFv3 and RIPng use specific transport >> protocols and ports. for example the SPD entry on the mobile router >> would say "if routing protocol message with destination=HA, use a >> particular SA which would do tunnel mode ESP". > > > How about writing this down somewhere in the document? As you > know, "should be straight forward" is not always a guarantee > that things will actually be like that ;-) hmm.. I will try to come up with some text in the Security Considerations section. Vijay From exim@www1.ietf.org Tue Dec 2 14:59:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05292 for ; Tue, 2 Dec 2003 14:59: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 1ARGfv-0004tr-5u for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 14:59:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2JxBCT018829 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 14:59:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGfv-0004tc-1D for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 14:59:11 -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 OAA05270 for ; Tue, 2 Dec 2003 14:58:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGfs-0007Ke-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 14:59:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARGfr-0007KX-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 14:59:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGfk-0004sh-PQ; Tue, 02 Dec 2003 14:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGex-0004rv-21 for nemo@optimus.ietf.org; Tue, 02 Dec 2003 14:58:11 -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 OAA05219 for ; Tue, 2 Dec 2003 14:57:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGeu-0007Ja-00 for nemo@ietf.org; Tue, 02 Dec 2003 14:58:08 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARGet-0007Il-00 for nemo@ietf.org; Tue, 02 Dec 2003 14:58:07 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB2JvX313823; Tue, 2 Dec 2003 11:57:33 -0800 X-mProtect: <200312021957> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9tReAU; Tue, 02 Dec 2003 11:57:32 PST Message-ID: <3FCCEFF1.7090009@iprg.nokia.com> Date: Tue, 02 Dec 2003 12:02:57 -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: Jari Arkko CC: nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko References: <3FCBF3DE.7050202@iprg.nokia.com> <3FCC5A7B.4080509@kolumbus.fi> In-Reply-To: <3FCC5A7B.4080509@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jari Arkko wrote: >>> JARI: Hmm... there might be value in defining the terms in a >>> self-contained >>> manner here. I'm pretty sure you only use a subset of [8] terms, >>> so it wouldn't be that long. >> >> >> >> I also believe in a document being self contained when it comes >> to terminology. but there is a separate WG document on NEMO >> terminology that is being advanced as an informational RFC. so >> I am not sure. > > > I think that other document would have value even if you > copied some of the terms (used ones) to the basic nemo > document. > > Anyway, I don't think it is crucial. Just a practical issue > that I noticed when reading. I am okay with copying some of the terms from the terminology document so that the basic support spec is self contained. if nobody has any objection I will go ahead and do this. > >>> Prefix Table >>> >>> It is a list of a Mobile Network Prefixes indexed >>> by the Home Address of a Mobile Router. The prefix table >>> is managed by the Home Agent and is used by the Home Agent >>> to determine which Mobile Network Prefixes are owned >>> a particular Mobile Router. This is an optional data >>> structure. >>> >>> JARI: Really? Why is it optional? Sounds mandatory to me... >> >> >> >> well, there could be scenarios where the mobile routers are not >> expected to misbehave. and there could be other ways for verifying >> this. so we left it optional. I dont mind making it mandatory. > > > That would make sense. you mean making it mandatory makes sense? maybe a SHOULD, not a MUST. > Imho all nemo-based products > should support this function. I agree too. > >>> A Mobile Network is a network segment or subnet which can move >>> and attach to arbitrary points in the Internet. A Mobile Network >>> does not allow any transit traffic and can only be accessed via >>> specific gateways called Mobile Routers that manage its movement. >>> >>> JARI: The above is a bit unclear. I think you mean that the >>> nodes behind the MR can't access the internet directly, they >>> have to go through the MR and the HA. >> >> >> >> actually no. it means traffic to the Mobile Network can reach >> the Mobile Network only through mobile routers. it also says >> mobile networks are not transit networks. always stub networks. > > > I'm still having some difficulty with the transit network > part. I looked up one definition of a transit network from RFC > 1584, which talks about the number of attached routers. However, > in the nested nemo case you could actually have several attached > routers, hidden inside tunnels. And would you allow multiple > MRs per Mobile Network or not? I think not, because then you > would appear like a transit network, according to the > RFC 1584 definition. OTOH, I'm not sure why such a limitation > would be necessary in the technical sense. > > Is it allowed for an MR to have two home agents, home addresses, > and network prefixes? Is there any case where the Mobile Network > would become a transit network in such a situation? > > How about this: > > A Mobile Network is a network segment or subnet which can move > and attach to arbitrary points in the Internet. A Mobile Network > can only be accessed via specific gateways called Mobile Routers > that manage its movement. Mobile Networks have (always exactly)| > (at least) one Mobile Router serving them. fine with me. > >>> JARI: Come to think of it, both the MR and the HA must know the >>> assigned prefixes beforehand in any case, so I wonder if we >>> need to communicate the prefixes at all?!? Can you cite an >>> example where the HA would give a prefix to the MR without >>> knowing it belongs to it? Or is the idea to prepare for the >>> eventual bootstrapping support in MIPv6? >> >> >> >> well, we still havent figured out how to do prefix delegation >> to a mobile router. there is a draft by Ralph Droms on extending >> DHCPv6 prefix delegation for NEMO. not a WG draft yet. >> >> and there is this scenario, where the mobile router is delegated >> more than prefix, but it could decide to setup forwarding for just >> one prefix instead of all prefixes. this cant be dont without >> carrying prefix information in the Binding Update. > > > If this is the case, perhaps you could remove the static alternative > then? My concern is mainly the number of alternatives. I'd rather > have less alternatives, even if the BUs would carry a few more bytes > in some cases... I would rather remove the explicit prefix length mode. the implicit mode I think is needed for minimal implementations of mobile routers. they are also needed when routes are managed by manual configuartion at the Home Agent, i.e. the routes are always there on the Home Agent and are just modified to reflect the current point of attachment of the mobile router. > >>> JARI: So, presumably this includes forwarding of packets to >>> the MR's own home address under all these prefixes, no? >>> If so, I think we have the S=0 bit functionality when you >>> set R=1 ;-) >> >> >> >> :) only if the mobile router has configured all its home addresses >> from its MNPs. > > > Yeah. But to support S=0 all I have to do is to agree about > suitable prefixes with my home agent, and set R=1... > > I'm not really suggesting you change anything, just making > an observation. > > But doesn't this point to an additional reason for making > the Prefix Table functionality mandatory? How else would > the HA know which prefixes to give to the MR, if no prefixes > were mentioned in the BU? how about manually configured routes which always exist on the Home Agent. we should keep it open. it is internal to the Home Agent. > >>> JARI: Is there something that you would perhaps like to >>> reference from MIPv6 regarding this tunneling, or is [3] enough? >>> >> >> why? are we missing something. > > > Would it be useful to follow MIPv6 base Section 5.5 guidelines > on the use of source addresses? we already say in the spec (section 5.5), what the source and destination addresses should be for the inner and outer IPv6 headers when sending packets through the bi-directional tunnel. >>> This document introduces a new Prefix Information field in the >>> Binding Update list structure. This field is used to store any >>> prefix information that the Mobile Router includes in the Binding >>> Update. If the Mobile Router sets the Mobile Router flag 'R' in the >>> Binding Update, but does not include any prefix information in it >>> (implicit mode), this field is set to null. >>> >>> JARI: So, if you run a routing protocol over the tunnel, will this >>> information be updated in the BUL as well? >> >> >> >> I think its not needed when a routing protocol is being run. > > > Ok. Perhaps you could explicitly say this. okay. >>> 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. >>> >>> JARI: I wonder if the above paragraph could be replaced with >>> some reference to ND specs. As far as I can see, an MR should >>> follow ND rules on its egress interface when on a visited >>> network. >> >> >> >> if you go by ND specs, routers ignore router advertisements. we are >> infact saying router advertisements MUST NOT be ignored. > > > I guess this is related to the MR turning to a host, as far > as any external observer can determine, when it attaches to > a foreign network. right. implementors need to explicitly enable the mobile routers to process router advertisements received on its egress interface. > >>> The establishment and operation of the bi-directional tunnel is >>> implementation specific. However, all implementations MUST be >>> capable of the following operations. >>> >>> JARI: What does it mean that its implementation specific? What >>> specifically would you have to do to establish the tunnel >>> in the first place? Why can't this be specified? >> >> >> >> setting up and using tunnels is implementation specific. some >> people like to set them up as virtual interfaces. sometimes it >> is just code in the IP stack. > > > Perhaps you could change the text to avoid a perception > that the protocols are not fully defined. How about this: > > The implementation of the bi-directional tunnels and the mechanism > of attaching them to the IP stack are outside the scope of this > specification. However, all implementations MUST be capable of > the following operations. okay. > >>> The Home Agent either uses only the routing >>> table, only the Binding Cache or a combination of routing table >>> and Binding Cache to route packets to the mobile network. This is >>> implementation specific. Two examples are shown below. >>> >>> JARI: You are presenting the rules in a too implementation-near >>> form. Perhaps you could formulate something general >>> that has a MUST. >>> >> >> there is a problem with it. the binding cache is a conceptual >> data structure. sometimes it is just implemented as a routing >> table entry. one implementation (of mobile routers), I know, >> uses the binding cache for both routing and CoA lookup. so >> we left it implementation specific. and we present two ways >> of doing it. >> >> we had a long discussion on using the binding cache or routing >> table for the HA to forward packets to the mobile network. this >> discussion happened before this draft was written up. > > > Ok. > > (Perhaps you could change the first paragraph of 6.5 to > have a keyword. This would be the normative part, the rest > is implementation guidance.) I am not sure I got. is this what you are getting at? When the Home Agent receives a data packet destined for the mobile network, it MUST forward the packet to the Mobile Router through the bi-directional tunnel. The Home Agent either uses only the routing table, only the Binding Cache or a combination of routing table and Binding Cache to route packets to the mobile network. This is implementation specific. Two examples are shown below. > >>> In the solution described so far, forwarding to the Mobile Network >>> at the Home Agent is set up when the Home Agent receives a Binding >>> Update from the Mobile Router. An alternative to this is for the >>> Home Agent and the Mobile Router to run an intra-domain routing >>> protocol like RIPng [10] and OSPF [11] through the bi-directional >>> tunnel. The Mobile Router can continue running the same routing >>> protocol that it was running when it was attached to the home link. >>> >>> This feature is very useful when the Mobile Network is large with >>> multiple subnets containing different IPv6 prefixes. Routing changes >>> >>> JARI: Can you give a practical example of where this could be the >>> case? I can't think of any, but maybe its just me... >> >> it could happen when there are multiple mobile networks attached >> to the mobile router, each one having different prefix, but want >> routing enabled for all these prefixes through the Home Agent. >> using a routing protocol makes sense here. > > I think the key question here is whether running the routing > protocol makes a difference in the end. Is it used to avoid > sending useless packets to the MR? Most likely such traffic > would be minimal, given that there would be no response from > the networks that are currently disconnected. Or is it used > to make some real routing changes, such as switching the > traffic from one HA site to another one? If yes, this needs > to be supported. what I would like to see is something we called a fully enabled case in another draft. the mobile router runs a routing protocol with its Home Agent to manage all routes. the mobile router also gets to know about the routes on the home domain through its Home Agent. the use of binding updates to do this is a poor substitute, IMO. > > Like I said above, I'm primarily concerned about the number > of alternatives and that's why I'm trying to see if we really > have a true need for all three, i.e. static, BU, and routing > protocol alternatives. I would like to enable the basic NEMO spec to be able to use a dynamic routing protocol. > >>> Since the routing protocol messages from the Home Agent to the Mobile >>> Router could potentically contain information about the internal >>> routing structure of the home network, these messages require >>> authentications and confidentiality protection. Confidentialy >>> protection using IPsec ESP [4] in tunnel mode MUST be supported and >>> SHOULD be used. >>> >>> >>> JARI: It might be necessary to have some more detail about this. >>> What kind of SPD entries are needed etc. >> >> should be straight forward. OSPFv3 and RIPng use specific transport >> protocols and ports. for example the SPD entry on the mobile router >> would say "if routing protocol message with destination=HA, use a >> particular SA which would do tunnel mode ESP". > > > How about writing this down somewhere in the document? As you > know, "should be straight forward" is not always a guarantee > that things will actually be like that ;-) hmm.. I will try to come up with some text in the Security Considerations section. Vijay From nemo-admin@ietf.org Tue Dec 2 15:51:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10032 for ; Tue, 2 Dec 2003 15:51: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 1ARHU4-00089r-Pp; Tue, 02 Dec 2003 15:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHTq-000899-Pr for nemo@optimus.ietf.org; Tue, 02 Dec 2003 15: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 PAA09939 for ; Tue, 2 Dec 2003 15:50:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHTp-0000XW-00 for nemo@ietf.org; Tue, 02 Dec 2003 15:50:45 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1ARHTo-0000XO-00 for nemo@ietf.org; Tue, 02 Dec 2003 15:50:44 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 2C6146A902; Tue, 2 Dec 2003 22:50:43 +0200 (EET) Message-ID: <3FCCFA14.5090806@kolumbus.fi> Date: Tue, 02 Dec 2003 22:46:12 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko References: <3FCBF3DE.7050202@iprg.nokia.com> <3FCC5A7B.4080509@kolumbus.fi> <3FCCEFF1.7090009@iprg.nokia.com> In-Reply-To: <3FCCEFF1.7090009@iprg.nokia.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: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > I am okay with copying some of the terms from the terminology > document so that the basic support spec is self contained. if > nobody has any objection I will go ahead and do this. Great! > you mean making it mandatory makes sense? maybe a SHOULD, not a > MUST. SHOULD is ok. >> A Mobile Network is a network segment or subnet which can move >> and attach to arbitrary points in the Internet. A Mobile Network >> can only be accessed via specific gateways called Mobile Routers >> that manage its movement. Mobile Networks have (always exactly)| >> (at least) one Mobile Router serving them. > > > fine with me. Ok, but you still need to pick either "always exactly" or "at least". >> Would it be useful to follow MIPv6 base Section 5.5 guidelines >> on the use of source addresses? > > > we already say in the spec (section 5.5), what the source and > destination addresses should be for the inner and outer IPv6 > headers when sending packets through the bi-directional tunnel. Yes, but you are not requiring that the source addresses be checked. This opens a reflection attack via home agents that don't get this. I think you need to add that, either as your own text or via reference. >> Ok. >> >> (Perhaps you could change the first paragraph of 6.5 to >> have a keyword. This would be the normative part, the rest >> is implementation guidance.) > > > I am not sure I got. is this what you are getting at? > > When the Home Agent receives a data packet destined for the mobile > network, it MUST forward the packet to the Mobile Router through the > bi-directional tunnel. The Home Agent either uses only the routing > table, only the Binding Cache or a combination of routing table > and Binding Cache to route packets to the mobile network. This is > implementation specific. Two examples are shown below. Exactly like that, thanks. >>>> In the solution described so far, forwarding to the Mobile Network >>>> at the Home Agent is set up when the Home Agent receives a Binding >>>> Update from the Mobile Router. An alternative to this is for the >>>> Home Agent and the Mobile Router to run an intra-domain routing >>>> protocol like RIPng [10] and OSPF [11] through the bi-directional >>>> tunnel. The Mobile Router can continue running the same routing >>>> protocol that it was running when it was attached to the home link. >>>> >>>> This feature is very useful when the Mobile Network is large with >>>> multiple subnets containing different IPv6 prefixes. Routing >>>> changes >>>> >>>> JARI: Can you give a practical example of where this could be the >>>> case? I can't think of any, but maybe its just me... >>> >>> >>> it could happen when there are multiple mobile networks attached >>> to the mobile router, each one having different prefix, but want >>> routing enabled for all these prefixes through the Home Agent. >>> using a routing protocol makes sense here. >> >> >> I think the key question here is whether running the routing >> protocol makes a difference in the end. Is it used to avoid >> sending useless packets to the MR? Most likely such traffic >> would be minimal, given that there would be no response from >> the networks that are currently disconnected. Or is it used >> to make some real routing changes, such as switching the >> traffic from one HA site to another one? If yes, this needs >> to be supported. > > > what I would like to see is something we called a fully enabled > case in another draft. the mobile router runs a routing protocol > with its Home Agent to manage all routes. the mobile router also > gets to know about the routes on the home domain through its > Home Agent. the use of binding updates to do this is a poor > substitute, IMO. Ok. >> How about writing this down somewhere in the document? As you >> know, "should be straight forward" is not always a guarantee >> that things will actually be like that ;-) > > > hmm.. I will try to come up with some text in the Security > Considerations section. Good. --Jari From exim@www1.ietf.org Tue Dec 2 15:51:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10047 for ; Tue, 2 Dec 2003 15:51: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 1ARHU8-0008B4-4J for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 15:51:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Kp4xJ031430 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 15:51:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHU7-0008Ap-Tj for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 15:51: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 PAA10001 for ; Tue, 2 Dec 2003 15:50:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHU6-0000Ye-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 15:51:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARHU6-0000Yb-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 15:51:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHU4-00089r-Pp; Tue, 02 Dec 2003 15:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHTq-000899-Pr for nemo@optimus.ietf.org; Tue, 02 Dec 2003 15: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 PAA09939 for ; Tue, 2 Dec 2003 15:50:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHTp-0000XW-00 for nemo@ietf.org; Tue, 02 Dec 2003 15:50:45 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1ARHTo-0000XO-00 for nemo@ietf.org; Tue, 02 Dec 2003 15:50:44 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 2C6146A902; Tue, 2 Dec 2003 22:50:43 +0200 (EET) Message-ID: <3FCCFA14.5090806@kolumbus.fi> Date: Tue, 02 Dec 2003 22:46:12 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko References: <3FCBF3DE.7050202@iprg.nokia.com> <3FCC5A7B.4080509@kolumbus.fi> <3FCCEFF1.7090009@iprg.nokia.com> In-Reply-To: <3FCCEFF1.7090009@iprg.nokia.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > I am okay with copying some of the terms from the terminology > document so that the basic support spec is self contained. if > nobody has any objection I will go ahead and do this. Great! > you mean making it mandatory makes sense? maybe a SHOULD, not a > MUST. SHOULD is ok. >> A Mobile Network is a network segment or subnet which can move >> and attach to arbitrary points in the Internet. A Mobile Network >> can only be accessed via specific gateways called Mobile Routers >> that manage its movement. Mobile Networks have (always exactly)| >> (at least) one Mobile Router serving them. > > > fine with me. Ok, but you still need to pick either "always exactly" or "at least". >> Would it be useful to follow MIPv6 base Section 5.5 guidelines >> on the use of source addresses? > > > we already say in the spec (section 5.5), what the source and > destination addresses should be for the inner and outer IPv6 > headers when sending packets through the bi-directional tunnel. Yes, but you are not requiring that the source addresses be checked. This opens a reflection attack via home agents that don't get this. I think you need to add that, either as your own text or via reference. >> Ok. >> >> (Perhaps you could change the first paragraph of 6.5 to >> have a keyword. This would be the normative part, the rest >> is implementation guidance.) > > > I am not sure I got. is this what you are getting at? > > When the Home Agent receives a data packet destined for the mobile > network, it MUST forward the packet to the Mobile Router through the > bi-directional tunnel. The Home Agent either uses only the routing > table, only the Binding Cache or a combination of routing table > and Binding Cache to route packets to the mobile network. This is > implementation specific. Two examples are shown below. Exactly like that, thanks. >>>> In the solution described so far, forwarding to the Mobile Network >>>> at the Home Agent is set up when the Home Agent receives a Binding >>>> Update from the Mobile Router. An alternative to this is for the >>>> Home Agent and the Mobile Router to run an intra-domain routing >>>> protocol like RIPng [10] and OSPF [11] through the bi-directional >>>> tunnel. The Mobile Router can continue running the same routing >>>> protocol that it was running when it was attached to the home link. >>>> >>>> This feature is very useful when the Mobile Network is large with >>>> multiple subnets containing different IPv6 prefixes. Routing >>>> changes >>>> >>>> JARI: Can you give a practical example of where this could be the >>>> case? I can't think of any, but maybe its just me... >>> >>> >>> it could happen when there are multiple mobile networks attached >>> to the mobile router, each one having different prefix, but want >>> routing enabled for all these prefixes through the Home Agent. >>> using a routing protocol makes sense here. >> >> >> I think the key question here is whether running the routing >> protocol makes a difference in the end. Is it used to avoid >> sending useless packets to the MR? Most likely such traffic >> would be minimal, given that there would be no response from >> the networks that are currently disconnected. Or is it used >> to make some real routing changes, such as switching the >> traffic from one HA site to another one? If yes, this needs >> to be supported. > > > what I would like to see is something we called a fully enabled > case in another draft. the mobile router runs a routing protocol > with its Home Agent to manage all routes. the mobile router also > gets to know about the routes on the home domain through its > Home Agent. the use of binding updates to do this is a poor > substitute, IMO. Ok. >> How about writing this down somewhere in the document? As you >> know, "should be straight forward" is not always a guarantee >> that things will actually be like that ;-) > > > hmm.. I will try to come up with some text in the Security > Considerations section. Good. --Jari From nemo-admin@ietf.org Tue Dec 2 16:03:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10755 for ; Tue, 2 Dec 2003 16:03: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 1ARHfh-00005n-HA; Tue, 02 Dec 2003 16:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHfA-000051-Qc for nemo@optimus.ietf.org; Tue, 02 Dec 2003 16:02: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 QAA10685 for ; Tue, 2 Dec 2003 16:02:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHf9-0000p2-00 for nemo@ietf.org; Tue, 02 Dec 2003 16:02:27 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARHf8-0000lQ-00 for nemo@ietf.org; Tue, 02 Dec 2003 16:02:26 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB2L0uj09997; Tue, 2 Dec 2003 13:00:56 -0800 X-mProtect: <200312022100> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXvxvpb; Tue, 02 Dec 2003 13:00:55 PST Message-ID: <3FCCFECC.2050703@iprg.nokia.com> Date: Tue, 02 Dec 2003 13:06:20 -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: Jari Arkko CC: nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko References: <3FCBF3DE.7050202@iprg.nokia.com> <3FCC5A7B.4080509@kolumbus.fi> <3FCCEFF1.7090009@iprg.nokia.com> <3FCCFA14.5090806@kolumbus.fi> In-Reply-To: <3FCCFA14.5090806@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jari Arkko wrote: >>> A Mobile Network is a network segment or subnet which can move >>> and attach to arbitrary points in the Internet. A Mobile Network >>> can only be accessed via specific gateways called Mobile Routers >>> that manage its movement. Mobile Networks have (always exactly)| >>> (at least) one Mobile Router serving them. >> >> >> >> fine with me. > > > Ok, but you still need to pick either "always exactly" or > "at least". we cannot restrict to one mobile router. so its "at least". > >>> Would it be useful to follow MIPv6 base Section 5.5 guidelines >>> on the use of source addresses? >> >> >> >> we already say in the spec (section 5.5), what the source and >> destination addresses should be for the inner and outer IPv6 >> headers when sending packets through the bi-directional tunnel. > > > Yes, but you are not requiring that the source addresses be > checked. This opens a reflection attack via home agents that > don't get this. there is some text in the Security Considerations section. 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 belong to the Mobile Network Prefix owned by the Mobile Router. Vijay From exim@www1.ietf.org Tue Dec 2 16:03:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10774 for ; Tue, 2 Dec 2003 16:03:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHfm-00007R-LN for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 16:03:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2L36Le000454 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 16:03:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHfm-00007F-HX for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 16:03: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 QAA10732 for ; Tue, 2 Dec 2003 16:02:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHfk-0000qK-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 16:03:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARHfk-0000qH-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 16:03:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHfh-00005n-HA; Tue, 02 Dec 2003 16:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHfA-000051-Qc for nemo@optimus.ietf.org; Tue, 02 Dec 2003 16:02: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 QAA10685 for ; Tue, 2 Dec 2003 16:02:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHf9-0000p2-00 for nemo@ietf.org; Tue, 02 Dec 2003 16:02:27 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARHf8-0000lQ-00 for nemo@ietf.org; Tue, 02 Dec 2003 16:02:26 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB2L0uj09997; Tue, 2 Dec 2003 13:00:56 -0800 X-mProtect: <200312022100> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXvxvpb; Tue, 02 Dec 2003 13:00:55 PST Message-ID: <3FCCFECC.2050703@iprg.nokia.com> Date: Tue, 02 Dec 2003 13:06:20 -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: Jari Arkko CC: nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko References: <3FCBF3DE.7050202@iprg.nokia.com> <3FCC5A7B.4080509@kolumbus.fi> <3FCCEFF1.7090009@iprg.nokia.com> <3FCCFA14.5090806@kolumbus.fi> In-Reply-To: <3FCCFA14.5090806@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jari Arkko wrote: >>> A Mobile Network is a network segment or subnet which can move >>> and attach to arbitrary points in the Internet. A Mobile Network >>> can only be accessed via specific gateways called Mobile Routers >>> that manage its movement. Mobile Networks have (always exactly)| >>> (at least) one Mobile Router serving them. >> >> >> >> fine with me. > > > Ok, but you still need to pick either "always exactly" or > "at least". we cannot restrict to one mobile router. so its "at least". > >>> Would it be useful to follow MIPv6 base Section 5.5 guidelines >>> on the use of source addresses? >> >> >> >> we already say in the spec (section 5.5), what the source and >> destination addresses should be for the inner and outer IPv6 >> headers when sending packets through the bi-directional tunnel. > > > Yes, but you are not requiring that the source addresses be > checked. This opens a reflection attack via home agents that > don't get this. there is some text in the Security Considerations section. 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 belong to the Mobile Network Prefix owned by the Mobile Router. Vijay From nemo-admin@ietf.org Tue Dec 2 16:16:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11619 for ; Tue, 2 Dec 2003 16:16: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 1ARHsH-0000wf-0y; Tue, 02 Dec 2003 16:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHra-0000vU-3W for nemo@optimus.ietf.org; Tue, 02 Dec 2003 16:15: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 QAA11559 for ; Tue, 2 Dec 2003 16:15:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHrY-000190-00 for nemo@ietf.org; Tue, 02 Dec 2003 16:15:16 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARHrX-00018k-00 for nemo@ietf.org; Tue, 02 Dec 2003 16:15:15 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB2LEhX19669; Tue, 2 Dec 2003 13:14:43 -0800 X-mProtect: <200312022114> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3PEOog; Tue, 02 Dec 2003 13:14:42 PST Message-ID: <3FCD0207.6010101@iprg.nokia.com> Date: Tue, 02 Dec 2003 13:20:07 -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: nemo@ietf.org CC: kempf@docomolabs-usa.com, jari.arkko@kolumbus.fi, pthubert@cisco.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Closing Issue 20 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi all, I think there is concensus now to remove the explicit prefix length mode. whatever one wanted to do with the explicit prefix length mode should be possible with the explicit network mode. this will address (to an extent) the concern that there are now too many differnt ways of doing the same thing, i.e. the mobile router asking the Home Agent to setup forwarding for the mobile network. Vijay From exim@www1.ietf.org Tue Dec 2 16:16:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11634 for ; Tue, 2 Dec 2003 16:16: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 1ARHsN-0000xq-4y for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 16:16:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2LG7YP003700 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 16:16:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHsM-0000xb-Un for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 16:16:07 -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 QAA11586 for ; Tue, 2 Dec 2003 16:15:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHsJ-00019Y-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 16:16:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARHsJ-00019V-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 16:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHsH-0000wf-0y; Tue, 02 Dec 2003 16:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHra-0000vU-3W for nemo@optimus.ietf.org; Tue, 02 Dec 2003 16:15: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 QAA11559 for ; Tue, 2 Dec 2003 16:15:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHrY-000190-00 for nemo@ietf.org; Tue, 02 Dec 2003 16:15:16 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARHrX-00018k-00 for nemo@ietf.org; Tue, 02 Dec 2003 16:15:15 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB2LEhX19669; Tue, 2 Dec 2003 13:14:43 -0800 X-mProtect: <200312022114> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3PEOog; Tue, 02 Dec 2003 13:14:42 PST Message-ID: <3FCD0207.6010101@iprg.nokia.com> Date: Tue, 02 Dec 2003 13:20:07 -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: nemo@ietf.org CC: kempf@docomolabs-usa.com, jari.arkko@kolumbus.fi, pthubert@cisco.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Closing Issue 20 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi all, I think there is concensus now to remove the explicit prefix length mode. whatever one wanted to do with the explicit prefix length mode should be possible with the explicit network mode. this will address (to an extent) the concern that there are now too many differnt ways of doing the same thing, i.e. the mobile router asking the Home Agent to setup forwarding for the mobile network. Vijay From nemo-admin@ietf.org Tue Dec 2 17:14:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16951 for ; Tue, 2 Dec 2003 17: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 1ARImQ-0004iG-JW; Tue, 02 Dec 2003 17: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 1ARIly-0004bJ-WA for nemo@optimus.ietf.org; Tue, 02 Dec 2003 17:13: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 RAA16798 for ; Tue, 2 Dec 2003 17:13:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARIlw-0003GQ-00 for nemo@ietf.org; Tue, 02 Dec 2003 17:13:32 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1ARIlv-0003G7-00 for nemo@ietf.org; Tue, 02 Dec 2003 17:13:31 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 83F486A902; Wed, 3 Dec 2003 00:13:23 +0200 (EET) Message-ID: <3FCD0D75.2080605@kolumbus.fi> Date: Wed, 03 Dec 2003 00:08:53 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko References: <3FCBF3DE.7050202@iprg.nokia.com> <3FCC5A7B.4080509@kolumbus.fi> <3FCCEFF1.7090009@iprg.nokia.com> <3FCCFA14.5090806@kolumbus.fi> <3FCCFECC.2050703@iprg.nokia.com> In-Reply-To: <3FCCFECC.2050703@iprg.nokia.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: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> Yes, but you are not requiring that the source addresses be >> checked. This opens a reflection attack via home agents that >> don't get this. > > > there is some text in the Security Considerations section. > > 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 belong to the Mobile Network Prefix > owned by the Mobile Router. Ok, thanks -- I missed it initially. --Jari From exim@www1.ietf.org Tue Dec 2 17:14:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16970 for ; Tue, 2 Dec 2003 17:14: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 1ARImg-0004kM-Ge for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 17:14:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2MEIVA018240 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 17:14:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARIme-0004k2-RF for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 17:14: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 RAA16898 for ; Tue, 2 Dec 2003 17:14:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARIma-0003KS-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 17:14:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARIma-0003KP-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 17:14:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARImQ-0004iG-JW; Tue, 02 Dec 2003 17: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 1ARIly-0004bJ-WA for nemo@optimus.ietf.org; Tue, 02 Dec 2003 17:13: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 RAA16798 for ; Tue, 2 Dec 2003 17:13:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARIlw-0003GQ-00 for nemo@ietf.org; Tue, 02 Dec 2003 17:13:32 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1ARIlv-0003G7-00 for nemo@ietf.org; Tue, 02 Dec 2003 17:13:31 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 83F486A902; Wed, 3 Dec 2003 00:13:23 +0200 (EET) Message-ID: <3FCD0D75.2080605@kolumbus.fi> Date: Wed, 03 Dec 2003 00:08:53 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko References: <3FCBF3DE.7050202@iprg.nokia.com> <3FCC5A7B.4080509@kolumbus.fi> <3FCCEFF1.7090009@iprg.nokia.com> <3FCCFA14.5090806@kolumbus.fi> <3FCCFECC.2050703@iprg.nokia.com> In-Reply-To: <3FCCFECC.2050703@iprg.nokia.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> Yes, but you are not requiring that the source addresses be >> checked. This opens a reflection attack via home agents that >> don't get this. > > > there is some text in the Security Considerations section. > > 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 belong to the Mobile Network Prefix > owned by the Mobile Router. Ok, thanks -- I missed it initially. --Jari From nemo-admin@ietf.org Tue Dec 2 17:50:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19968 for ; Tue, 2 Dec 2003 17:50:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARJLF-0006aE-VG; Tue, 02 Dec 2003 17:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARJKg-0006Zi-Cd for nemo@optimus.ietf.org; Tue, 02 Dec 2003 17:49: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 RAA19861 for ; Tue, 2 Dec 2003 17:49:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARJKd-0004Xr-00 for nemo@ietf.org; Tue, 02 Dec 2003 17:49:23 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARJKc-0004VN-00 for nemo@ietf.org; Tue, 02 Dec 2003 17:49:23 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB2Mldj20513; Tue, 2 Dec 2003 14:47:39 -0800 X-mProtect: <200312022247> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLM47BX; Tue, 02 Dec 2003 14:47:37 PST Message-ID: <3FCD17CF.1060707@iprg.nokia.com> Date: Tue, 02 Dec 2003 14:53:03 -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: Jari Arkko , nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko 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: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > The routing protocol thing could be considered out of scope. Once the > MRHA tunnel is established, any manual tunnel can be used to carry IPv4, > multicast, or an IGP back home. Do we have to explicitly say all this? > Maybe we could move it to "usages"? Pascal, the usages document is not the answer to everything. you are suggesting using the usages document for everything that is thrown out of the basic spec. :) you have to keep in midn that it is targeted at informational. infact as you say, running a routing protocol over the bi-directional tunnel is not very different from say running DHCP prefix delegation over the tunnel. it is just some traffic. but in this case, traffic which affects routing tables on the Home Agent and the mobile router. we need to say how it interacts with sending routing information through the binding updates. so, I think it should stay in the basic spec. Vijay From exim@www1.ietf.org Tue Dec 2 17:51:08 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20075 for ; Tue, 2 Dec 2003 17:51: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 1ARJM4-0006gO-NO for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 17:50:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2MoqjE025680 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 17:50:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARJM4-0006g7-BY for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 17:50: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 RAA19998 for ; Tue, 2 Dec 2003 17:50:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARJM1-0004b7-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 17:50:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARJM0-0004aM-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 17:50:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARJLF-0006aE-VG; Tue, 02 Dec 2003 17:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARJKg-0006Zi-Cd for nemo@optimus.ietf.org; Tue, 02 Dec 2003 17:49: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 RAA19861 for ; Tue, 2 Dec 2003 17:49:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARJKd-0004Xr-00 for nemo@ietf.org; Tue, 02 Dec 2003 17:49:23 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARJKc-0004VN-00 for nemo@ietf.org; Tue, 02 Dec 2003 17:49:23 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB2Mldj20513; Tue, 2 Dec 2003 14:47:39 -0800 X-mProtect: <200312022247> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLM47BX; Tue, 02 Dec 2003 14:47:37 PST Message-ID: <3FCD17CF.1060707@iprg.nokia.com> Date: Tue, 02 Dec 2003 14:53:03 -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: Jari Arkko , nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > The routing protocol thing could be considered out of scope. Once the > MRHA tunnel is established, any manual tunnel can be used to carry IPv4, > multicast, or an IGP back home. Do we have to explicitly say all this? > Maybe we could move it to "usages"? Pascal, the usages document is not the answer to everything. you are suggesting using the usages document for everything that is thrown out of the basic spec. :) you have to keep in midn that it is targeted at informational. infact as you say, running a routing protocol over the bi-directional tunnel is not very different from say running DHCP prefix delegation over the tunnel. it is just some traffic. but in this case, traffic which affects routing tables on the Home Agent and the mobile router. we need to say how it interacts with sending routing information through the binding updates. so, I think it should stay in the basic spec. Vijay From nemo-admin@ietf.org Tue Dec 2 18:53:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24711 for ; Tue, 2 Dec 2003 18:53: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 1ARKKC-0000xh-Kd; Tue, 02 Dec 2003 18:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKJg-0000xD-C3 for nemo@optimus.ietf.org; Tue, 02 Dec 2003 18:52: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 SAA24640 for ; Tue, 2 Dec 2003 18:52:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARKJd-0005yN-00 for nemo@ietf.org; Tue, 02 Dec 2003 18:52:25 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARKJc-0005wD-00 for nemo@ietf.org; Tue, 02 Dec 2003 18:52:24 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB2NpRP16889; Tue, 2 Dec 2003 15:51:27 -0800 X-mProtect: <200312022351> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3T7Ssi; Tue, 02 Dec 2003 15:51:25 PST Message-ID: <3FCD26C3.2030305@iprg.nokia.com> Date: Tue, 02 Dec 2003 15:56:51 -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: nemo@ietf.org, Jari Arkko , "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Closing Issue 16 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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, this issue was about support MIPv6 Home Agents that do not support mobile routers. we initially modified DHAAD to return only the list of home agents that support mobile routers. but Pascal and Jari argued that the protocol is more robust if the Home Agent echos a bit in the binding acknowledgement to indicate to the mobile router that it has setup forwarding for the mobile network. so I changed the format of the binding ack to include a new flag. this flag is set when the Home Agent which processed the binding update supports mobile routers and the mobile router flag in the corresponding binding update was set to 1. change the binding ack format 4.2. Binding Acknowledgement A new flag (R) is included in the Binding Acknowledgement to indicate that the Home Agent which processed the corresponding Binding Update supports Mobile Routers. The flag is set only if the corresponding Binding Update had the Mobile Router flag (R) set to 1. The rest of the Binding Acknowledgement format remains the same as defined in [1]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mobile Router Flag (R) The Mobile Router Flag is set to indicate that the Home Agent which processed the Binding Update supports Mobile Routers. It is set to 1 only if the corresponding Binding Update had the Mobile Router flag set to 1. For a description of the other fields in the message, see [1]. This document also introduces the following new Binding Acknowledgement status values. 140 Mobile Router Operation not permitted 141 Invalid Prefix 142 Not Authorized for Prefix 143 Forwarding Setup failed Status values less than 128 indicate that the Binding Update was processed successfully by the receiving nodes. Values greater than 128 indicate that the Binding Update was rejected by the Home Agent. change section 5.3 5.3. Receiving Binding Acknowledgements The Mobile Router receives Binding Acknowledgements from the Home Agent, corresponding to the Binding Updates it sent. If the Binding Acknowledgement status is set to '0' (Binding Update accepted) and the Mobile Router flag (R) is set to 1, the Mobile Router assumes that the Home Agent has successfully processed the Binding Update and has set up forwarding for the Mobile Network. The Mobile Router can then start using the bi-directional tunnel for reverse tunneling traffic from the mobile network. If the Mobile Router flag (R) is not set, then the Mobile Router concludes that its current Home Agent does not support Mobile Routers and performs Dynamic Home Agent Discovery again to discover Home Agents which support Mobile Routers. modify section 6.6 to say The Home Agent sets the status code in the Binding Acknowledgement to '0' (Binding Update accepted) in order to indicate to the Mobile Router that it successfully processed the Binding Update. It also sets the Mobile Router flag (R) to indicate to the Mobile Router that it has setup forwarding for the Mobile Network. a MIPv6 Home Agent will not set this flag. let me know if this looks good. Vijay From exim@www1.ietf.org Tue Dec 2 18:53:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24729 for ; Tue, 2 Dec 2003 18:53: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 1ARKKc-000101-D3 for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 18:53:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2NrQ1F003837 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 18:53:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKKc-0000zo-8c for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 18:53: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 SAA24693 for ; Tue, 2 Dec 2003 18:53:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARKKZ-0005zE-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 18:53:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARKKY-0005z1-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 18:53:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKKC-0000xh-Kd; Tue, 02 Dec 2003 18:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKJg-0000xD-C3 for nemo@optimus.ietf.org; Tue, 02 Dec 2003 18:52: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 SAA24640 for ; Tue, 2 Dec 2003 18:52:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARKJd-0005yN-00 for nemo@ietf.org; Tue, 02 Dec 2003 18:52:25 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARKJc-0005wD-00 for nemo@ietf.org; Tue, 02 Dec 2003 18:52:24 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB2NpRP16889; Tue, 2 Dec 2003 15:51:27 -0800 X-mProtect: <200312022351> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3T7Ssi; Tue, 02 Dec 2003 15:51:25 PST Message-ID: <3FCD26C3.2030305@iprg.nokia.com> Date: Tue, 02 Dec 2003 15:56:51 -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: nemo@ietf.org, Jari Arkko , "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Closing Issue 16 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi all, this issue was about support MIPv6 Home Agents that do not support mobile routers. we initially modified DHAAD to return only the list of home agents that support mobile routers. but Pascal and Jari argued that the protocol is more robust if the Home Agent echos a bit in the binding acknowledgement to indicate to the mobile router that it has setup forwarding for the mobile network. so I changed the format of the binding ack to include a new flag. this flag is set when the Home Agent which processed the binding update supports mobile routers and the mobile router flag in the corresponding binding update was set to 1. change the binding ack format 4.2. Binding Acknowledgement A new flag (R) is included in the Binding Acknowledgement to indicate that the Home Agent which processed the corresponding Binding Update supports Mobile Routers. The flag is set only if the corresponding Binding Update had the Mobile Router flag (R) set to 1. The rest of the Binding Acknowledgement format remains the same as defined in [1]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mobile Router Flag (R) The Mobile Router Flag is set to indicate that the Home Agent which processed the Binding Update supports Mobile Routers. It is set to 1 only if the corresponding Binding Update had the Mobile Router flag set to 1. For a description of the other fields in the message, see [1]. This document also introduces the following new Binding Acknowledgement status values. 140 Mobile Router Operation not permitted 141 Invalid Prefix 142 Not Authorized for Prefix 143 Forwarding Setup failed Status values less than 128 indicate that the Binding Update was processed successfully by the receiving nodes. Values greater than 128 indicate that the Binding Update was rejected by the Home Agent. change section 5.3 5.3. Receiving Binding Acknowledgements The Mobile Router receives Binding Acknowledgements from the Home Agent, corresponding to the Binding Updates it sent. If the Binding Acknowledgement status is set to '0' (Binding Update accepted) and the Mobile Router flag (R) is set to 1, the Mobile Router assumes that the Home Agent has successfully processed the Binding Update and has set up forwarding for the Mobile Network. The Mobile Router can then start using the bi-directional tunnel for reverse tunneling traffic from the mobile network. If the Mobile Router flag (R) is not set, then the Mobile Router concludes that its current Home Agent does not support Mobile Routers and performs Dynamic Home Agent Discovery again to discover Home Agents which support Mobile Routers. modify section 6.6 to say The Home Agent sets the status code in the Binding Acknowledgement to '0' (Binding Update accepted) in order to indicate to the Mobile Router that it successfully processed the Binding Update. It also sets the Mobile Router flag (R) to indicate to the Mobile Router that it has setup forwarding for the Mobile Network. a MIPv6 Home Agent will not set this flag. let me know if this looks good. Vijay From nemo-admin@ietf.org Tue Dec 2 19:36:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25929 for ; Tue, 2 Dec 2003 19:36: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 1ARKzq-0002oM-OB; Tue, 02 Dec 2003 19:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKza-0002nC-6Z for nemo@optimus.ietf.org; Tue, 02 Dec 2003 19:35: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 TAA25880 for ; Tue, 2 Dec 2003 19:35:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARKzY-0006VB-00 for nemo@ietf.org; Tue, 02 Dec 2003 19:35:44 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARKzX-0006UQ-00 for nemo@ietf.org; Tue, 02 Dec 2003 19:35:43 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB30YEK07394; Tue, 2 Dec 2003 16:34:14 -0800 X-mProtect: <200312030034> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdci9TAk; Tue, 02 Dec 2003 16:34:12 PST Message-ID: <3FCD30CA.7020106@iprg.nokia.com> Date: Tue, 02 Dec 2003 16:39:38 -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: Jari Arkko , 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: issue xxx: requirements chapter for 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 Pascal, this is ugly. I never liked the particular section in the base MIPv6 spec. that section was a source of contention/confusion for a long time. I have no desire to bloat the current NEMO basic spec by adding this section your propose. even from your text, it is obvious that NEMO basic support does not bring in new requirements for ordinary IPv6 hosts, IPv6 hosts which support route optimization, IPv6 routers, MIPv6 mobile nodes or MIPv6 Home Agents that support only mobile nodes. it only introduces new requirements for a mobile router and a Home Agent that supports mobile routers. we already specify what it means for a Home Agent to support mobile routers. we also say if the Mobile Router wants to behave as a mobile node, it should follow what is said in the MIPv6 specification. infact I would say the entire basic support spec *is* requirements for mobile routers and Home Agents that support mobile routers. I dont think anything more is required. Vijay Pascal Thubert (pthubert) wrote: > Hi: > > I understand from the discussion with Jari that we could (should) open > an issue regarding the equivalent of [MIPv6] chapter 8, that appears to > be missing from basic nemo. > > Here's my view of what that text could be (largely inheriting from > [MIPv6]). What do you think? > > > > > > > > 8. Requirements for Types of IPv6 Nodes > > Basic Nemo extends the requirements placed by Mobile IPv6 on the > functions provided by different types of IPv6 nodes. This section > summarizes those requirements, identifying the functionality each > requirement is intended to support. Note that the category 'mobile > node' > that is used in [MIPv6] really applies to mobile hosts and excludes > mobile routers which are placed in a separate category. > > The requirements are set for the following groups of nodes: > > o All IPv6 nodes. > > o All IPv6 nodes with support for route optimization. > > o All IPv6 routers. > > o All Mobile IPv6 home agents. > > o All Mobile IPv6 mobile nodes. > > o All Mobile IPv6 mobile routers. > > It is outside the scope of this specification to specify which of > these groups are mandatory in IPv6. We only describe what is > mandatory for a router that supports network mobility. > Other specifications are expected to define the extent of IPv6. > > 8.1 All IPv6 Nodes > > There are no Basic Nemo specific MUST requirements for such nodes, > and basic IPv6 techniques are sufficient. > > 8.2 IPv6 Nodes with Support for [MIPv6] Route Optimization > > Basic Nemo does not introduce a specific route optimization for > Mobile > Networks. If a Mobile Router acts as a [MIPv6] Mobile Node, the Route > > Optimization follows the [MIPv6] rules with the same requirements no > the > Correspondents. The Mobility of a Network is transparent to the > Visiting > Mobile Nodes and does not create any additional requirement on the > Correspondent. > > 8.3 All IPv6 Routers > > Basic Nemo uses the movement detection mechanisms as described in > [MIPv6], > and places the same requirements on all routers as [MIPv6] does. > > > 8.4 IPv6 Home Agents > > A Nemo Home Agent extends the feature set of a Mobile IPv6 HA. As > such, > It MUST support all the features described in [MIPv6] chapter 8.4. > and > process [MIPv6] messages per the [MIPv6] specification for all Mobile > Nodes. > > On top of that, the following additional requirements apply to all > [MIPv6] > Home Agents in order to serve as a Nemo Home Agent: > > o Every home agent MUST recognize the mobility messages associated > to > mobile routers and support both the implicit and explicit prefix > modes. > A home agent MAY optionally support an other routing protocol over > the > MRHA tunnel. > > > o Every home agent MUST support establishing and tearing down a > bidirectional > tunnel to a mobile router careOF address. > > o Every home agent MUST support setting the forwarding states > proactively (static routes) or reactively (upon registration) in > order to route packets to the registered prefixes, via the mobile > router home address or over the tunnel. > > o Every home agent MUST be able to authorize the registrations in > explicit prefix mode prior to installing the > associated forwarding states. > > o Every home agent MUST fully support IPv6 tunneling [RFC2473] for > MRHA tunnel. > For packets sent received from a mobile router's careOf address, > every home > agent MUST check that the inner packet is topologically correct. > > o Every home agent MUST be able to return a Binding Acknowledgement > in response to a Binding Update (Section 10.3.1). > > o Every home agent MUST maintain a separate Home Agents List for > each link on which it is serving as a home agent, as described in > [MIPv6] Section 10.1 and 10.5.1, and in Section 7. > > o Every home agent SHOULD be able to intercept packets (using proxy > Neighbor Discovery [RFC2461]) addressed to a node on a mobile > network > Associated with a mobile router for which it has an active binding > on that mobile router's home Link. > (note: This is used in the aggregated physical Home Net only, thus > > the SHOULD) > > o Every home agent performing that interception MUST be able > to encapsulate [RFC2473] such intercepted packets in order to > tunnel > them to the primary care-of address for the mobile router for > which > the forwarding states are established. > > 8.5 IPv6 Mobile Nodes > > Basic Nemo is transparent to the activity of MIPv6 Mobile Nodes > and > does not require any specific support from those. > > 8.6 IPv6 Mobile Routers > > Finally, the following requirements apply to all IPv6 routers capable > of functioning as mobile routers: > > > o The router MUST comply with the MIPv6 requirements on all nodes > and > on all routers ([MIPv6] Sections 8.1 and 8.3). It MAY comply with > section 8.2 as well. > > o The router MUST support establishing and tearing down a > bidirectional > tunnel to its Home Agent and a default route over that tunnel. > It MUST support forwarding packets between that tunnel and the > Mobile Networks. > > o The router MUST support at least one of the 2 modes, implicit or > explicit prefix, > for its Home registration as a mobile router. It SHOULD support > both. It MAY support > additional routing protocols over the MRHA tunnel. > > o The router MUST support sending packets containing a Home Address > option ([MIPv6] Section 11.3.1), and follow the required IPsec > interaction > ([MIPv6] Section 11.3.2). > > o The router MUST fully support [RFC2473]. As such, it MUST be able > to > perform IPv6 encapsulation and decapsulation, ICMP forwarding and > PMTU > discovery. > > o The router MUST be able to process type 2 routing header as > defined > in [MIPv6] Section 6.4 and Section 11.3.3. > > o The router MUST support receiving a Binding Error message ([MIPv6] > Section > 11.3.6). > > o The router MUST support receiving ICMP errors ([MIPv6] Section > 11.3.5). > > o The router MUST support movement detection, care-of address > formation. It MAY also support returning home. > > o The router MUST be able to process Mobility Headers as described > in > [MIPv6] and Section 5. > > o The router MUST be able to send Binding Updates, as specified in > Section 5.2. > > o The router MUST be able to receive and process Binding > Acknowledgements, as specified in Section 5.3. > > o The router MUST support receiving a Binding Refresh Request > ([MIPv6] > Section 6.1.2), by responding with a Binding Update (section > 5.2). > > o The router SHOULD support use of the dynamic home agent address > discovery mechanism, as described in Section 7. > > ? The router MAY support receiving Mobile Prefix Advertisements > (Section 11.4.3) and reconfiguring its home address based on the > prefix information contained therein. > > o The router MAY support stateful address autoconfiguration > mechanisms > such as DHCPv6 [29] on the interface represented by the tunnel to > the home agent. > > From exim@www1.ietf.org Tue Dec 2 19:36:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25954 for ; Tue, 2 Dec 2003 19:36: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 1ARKzv-0002rV-Li for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 19:36:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB30a7Wl010995 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 19:36:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKzv-0002rG-G0 for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 19:36:07 -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 TAA25894 for ; Tue, 2 Dec 2003 19:35:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARKzt-0006Vd-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 19:36:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARKzt-0006VX-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 19:36:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKzq-0002oM-OB; Tue, 02 Dec 2003 19:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKza-0002nC-6Z for nemo@optimus.ietf.org; Tue, 02 Dec 2003 19:35: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 TAA25880 for ; Tue, 2 Dec 2003 19:35:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARKzY-0006VB-00 for nemo@ietf.org; Tue, 02 Dec 2003 19:35:44 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARKzX-0006UQ-00 for nemo@ietf.org; Tue, 02 Dec 2003 19:35:43 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB30YEK07394; Tue, 2 Dec 2003 16:34:14 -0800 X-mProtect: <200312030034> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdci9TAk; Tue, 02 Dec 2003 16:34:12 PST Message-ID: <3FCD30CA.7020106@iprg.nokia.com> Date: Tue, 02 Dec 2003 16:39:38 -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: Jari Arkko , 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: issue xxx: requirements chapter for 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 Content-Transfer-Encoding: 7bit hi Pascal, this is ugly. I never liked the particular section in the base MIPv6 spec. that section was a source of contention/confusion for a long time. I have no desire to bloat the current NEMO basic spec by adding this section your propose. even from your text, it is obvious that NEMO basic support does not bring in new requirements for ordinary IPv6 hosts, IPv6 hosts which support route optimization, IPv6 routers, MIPv6 mobile nodes or MIPv6 Home Agents that support only mobile nodes. it only introduces new requirements for a mobile router and a Home Agent that supports mobile routers. we already specify what it means for a Home Agent to support mobile routers. we also say if the Mobile Router wants to behave as a mobile node, it should follow what is said in the MIPv6 specification. infact I would say the entire basic support spec *is* requirements for mobile routers and Home Agents that support mobile routers. I dont think anything more is required. Vijay Pascal Thubert (pthubert) wrote: > Hi: > > I understand from the discussion with Jari that we could (should) open > an issue regarding the equivalent of [MIPv6] chapter 8, that appears to > be missing from basic nemo. > > Here's my view of what that text could be (largely inheriting from > [MIPv6]). What do you think? > > > > > > > > 8. Requirements for Types of IPv6 Nodes > > Basic Nemo extends the requirements placed by Mobile IPv6 on the > functions provided by different types of IPv6 nodes. This section > summarizes those requirements, identifying the functionality each > requirement is intended to support. Note that the category 'mobile > node' > that is used in [MIPv6] really applies to mobile hosts and excludes > mobile routers which are placed in a separate category. > > The requirements are set for the following groups of nodes: > > o All IPv6 nodes. > > o All IPv6 nodes with support for route optimization. > > o All IPv6 routers. > > o All Mobile IPv6 home agents. > > o All Mobile IPv6 mobile nodes. > > o All Mobile IPv6 mobile routers. > > It is outside the scope of this specification to specify which of > these groups are mandatory in IPv6. We only describe what is > mandatory for a router that supports network mobility. > Other specifications are expected to define the extent of IPv6. > > 8.1 All IPv6 Nodes > > There are no Basic Nemo specific MUST requirements for such nodes, > and basic IPv6 techniques are sufficient. > > 8.2 IPv6 Nodes with Support for [MIPv6] Route Optimization > > Basic Nemo does not introduce a specific route optimization for > Mobile > Networks. If a Mobile Router acts as a [MIPv6] Mobile Node, the Route > > Optimization follows the [MIPv6] rules with the same requirements no > the > Correspondents. The Mobility of a Network is transparent to the > Visiting > Mobile Nodes and does not create any additional requirement on the > Correspondent. > > 8.3 All IPv6 Routers > > Basic Nemo uses the movement detection mechanisms as described in > [MIPv6], > and places the same requirements on all routers as [MIPv6] does. > > > 8.4 IPv6 Home Agents > > A Nemo Home Agent extends the feature set of a Mobile IPv6 HA. As > such, > It MUST support all the features described in [MIPv6] chapter 8.4. > and > process [MIPv6] messages per the [MIPv6] specification for all Mobile > Nodes. > > On top of that, the following additional requirements apply to all > [MIPv6] > Home Agents in order to serve as a Nemo Home Agent: > > o Every home agent MUST recognize the mobility messages associated > to > mobile routers and support both the implicit and explicit prefix > modes. > A home agent MAY optionally support an other routing protocol over > the > MRHA tunnel. > > > o Every home agent MUST support establishing and tearing down a > bidirectional > tunnel to a mobile router careOF address. > > o Every home agent MUST support setting the forwarding states > proactively (static routes) or reactively (upon registration) in > order to route packets to the registered prefixes, via the mobile > router home address or over the tunnel. > > o Every home agent MUST be able to authorize the registrations in > explicit prefix mode prior to installing the > associated forwarding states. > > o Every home agent MUST fully support IPv6 tunneling [RFC2473] for > MRHA tunnel. > For packets sent received from a mobile router's careOf address, > every home > agent MUST check that the inner packet is topologically correct. > > o Every home agent MUST be able to return a Binding Acknowledgement > in response to a Binding Update (Section 10.3.1). > > o Every home agent MUST maintain a separate Home Agents List for > each link on which it is serving as a home agent, as described in > [MIPv6] Section 10.1 and 10.5.1, and in Section 7. > > o Every home agent SHOULD be able to intercept packets (using proxy > Neighbor Discovery [RFC2461]) addressed to a node on a mobile > network > Associated with a mobile router for which it has an active binding > on that mobile router's home Link. > (note: This is used in the aggregated physical Home Net only, thus > > the SHOULD) > > o Every home agent performing that interception MUST be able > to encapsulate [RFC2473] such intercepted packets in order to > tunnel > them to the primary care-of address for the mobile router for > which > the forwarding states are established. > > 8.5 IPv6 Mobile Nodes > > Basic Nemo is transparent to the activity of MIPv6 Mobile Nodes > and > does not require any specific support from those. > > 8.6 IPv6 Mobile Routers > > Finally, the following requirements apply to all IPv6 routers capable > of functioning as mobile routers: > > > o The router MUST comply with the MIPv6 requirements on all nodes > and > on all routers ([MIPv6] Sections 8.1 and 8.3). It MAY comply with > section 8.2 as well. > > o The router MUST support establishing and tearing down a > bidirectional > tunnel to its Home Agent and a default route over that tunnel. > It MUST support forwarding packets between that tunnel and the > Mobile Networks. > > o The router MUST support at least one of the 2 modes, implicit or > explicit prefix, > for its Home registration as a mobile router. It SHOULD support > both. It MAY support > additional routing protocols over the MRHA tunnel. > > o The router MUST support sending packets containing a Home Address > option ([MIPv6] Section 11.3.1), and follow the required IPsec > interaction > ([MIPv6] Section 11.3.2). > > o The router MUST fully support [RFC2473]. As such, it MUST be able > to > perform IPv6 encapsulation and decapsulation, ICMP forwarding and > PMTU > discovery. > > o The router MUST be able to process type 2 routing header as > defined > in [MIPv6] Section 6.4 and Section 11.3.3. > > o The router MUST support receiving a Binding Error message ([MIPv6] > Section > 11.3.6). > > o The router MUST support receiving ICMP errors ([MIPv6] Section > 11.3.5). > > o The router MUST support movement detection, care-of address > formation. It MAY also support returning home. > > o The router MUST be able to process Mobility Headers as described > in > [MIPv6] and Section 5. > > o The router MUST be able to send Binding Updates, as specified in > Section 5.2. > > o The router MUST be able to receive and process Binding > Acknowledgements, as specified in Section 5.3. > > o The router MUST support receiving a Binding Refresh Request > ([MIPv6] > Section 6.1.2), by responding with a Binding Update (section > 5.2). > > o The router SHOULD support use of the dynamic home agent address > discovery mechanism, as described in Section 7. > > ? The router MAY support receiving Mobile Prefix Advertisements > (Section 11.4.3) and reconfiguring its home address based on the > prefix information contained therein. > > o The router MAY support stateful address autoconfiguration > mechanisms > such as DHCPv6 [29] on the interface represented by the tunnel to > the home agent. > > From nemo-admin@ietf.org Tue Dec 2 20:06:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26939 for ; Tue, 2 Dec 2003 20:06:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLSs-0004P9-AC; Tue, 02 Dec 2003 20:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLRy-0004Nx-Rm for nemo@optimus.ietf.org; Tue, 02 Dec 2003 20:05: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 UAA26874 for ; Tue, 2 Dec 2003 20:04:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARLRw-0006vu-00 for nemo@ietf.org; Tue, 02 Dec 2003 20:05:04 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1ARLRv-0006vk-00 for nemo@ietf.org; Tue, 02 Dec 2003 20:05:04 -0500 Received: from kniveton.com (wideload.kniveton.com [64.36.73.246]) by multihop.net (8.12.10/8.12.10) with ESMTP id hB3151r3006602 for ; Tue, 2 Dec 2003 17:05:02 -0800 (PST) (envelope-from tj@kniveton.com) Message-ID: <3FCD36BF.2070708@kniveton.com> Date: Tue, 02 Dec 2003 17:05:03 -0800 From: "T.J. Kniveton" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko References: <3FCBF3DE.7050202@iprg.nokia.com> <3FCC5A7B.4080509@kolumbus.fi> <3FCCEFF1.7090009@iprg.nokia.com> In-Reply-To: <3FCCEFF1.7090009@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > Jari Arkko wrote: > >>>> JARI: Hmm... there might be value in defining the terms in a >>>> self-contained >>>> manner here. I'm pretty sure you only use a subset of [8] >>>> terms, >>>> so it wouldn't be that long. >>> >>> I also believe in a document being self contained when it comes >>> to terminology. but there is a separate WG document on NEMO >>> terminology that is being advanced as an informational RFC. so >>> I am not sure. >> >> I think that other document would have value even if you >> copied some of the terms (used ones) to the basic nemo >> document. > Can you explain what the point is of having a separate NEMO terminology document if the basic support spec is self-defining? It seems that we followed the general trend in IETF WGs to have a more general terminology document, and then use those terms in the protocol specification. Can you point to a reference or suggestion by the IESG or ADs have suggested that everything be self-referential? I would personally like to know what the BCP on this is at the moment, since it seems like pushing the terms back in to make a larger document is like swimming upstream. >> Anyway, I don't think it is crucial. Just a practical issue >> that I noticed when reading. > Not crucial, but we would like to make sure that things end up in a best useable form. > I am okay with copying some of the terms from the terminology > document so that the basic support spec is self contained. if > nobody has any objection I will go ahead and do this. > >> >>>> Prefix Table >>>> >>>> It is a list of a Mobile Network Prefixes indexed >>>> by the Home Address of a Mobile Router. The prefix >>>> table >>>> is managed by the Home Agent and is used by the Home >>>> Agent >>>> to determine which Mobile Network Prefixes are owned >>>> a particular Mobile Router. This is an optional data >>>> structure. >>>> >>>> JARI: Really? Why is it optional? Sounds mandatory to me... >>> >>> >>> >>> >>> well, there could be scenarios where the mobile routers are not >>> expected to misbehave. and there could be other ways for verifying >>> this. so we left it optional. I dont mind making it mandatory. >> A table of owned prefixes is only one possible way for the Home Agent to determine which prefixes an authenticated MR is authorized to use NEMO with. That's why it's optional. >> >> >> That would make sense. > > > you mean making it mandatory makes sense? maybe a SHOULD, not a > MUST. > >> Imho all nemo-based products >> should support this function. > > > I agree too. Of a prefix table? Yes, in statically configured cases, which is probably the most useable in the near term, we would highly recommend using this static mapping. But someone could always hook up a database and do lookups, when the list is managed by another piece of software. >>>> A Mobile Network is a network segment or subnet which can move >>>> and attach to arbitrary points in the Internet. A Mobile Network >>>> does not allow any transit traffic and can only be accessed via >>>> specific gateways called Mobile Routers that manage its movement. >>>> >>>> JARI: The above is a bit unclear. I think you mean that the >>>> nodes behind the MR can't access the internet directly, they >>>> have to go through the MR and the HA. >>> >>> >>> >>> >>> actually no. it means traffic to the Mobile Network can reach >>> the Mobile Network only through mobile routers. it also says >>> mobile networks are not transit networks. always stub networks. >> >> >> >> I'm still having some difficulty with the transit network >> part. I looked up one definition of a transit network from RFC >> 1584, which talks about the number of attached routers. However, >> in the nested nemo case you could actually have several attached >> routers, hidden inside tunnels. And would you allow multiple >> MRs per Mobile Network or not? I think not, because then you >> would appear like a transit network, according to the >> RFC 1584 definition. OTOH, I'm not sure why such a limitation >> would be necessary in the technical sense. > True, traffic inside a mobile network can transit from one sub-network to another sub-network. However, consider this rule, which might help clarify: (a) For all mobile networks, there is a defined boundary in which all nodes are considered part of the mobile network, and then we say that all packets entering the mobile network (through one or more top-level mobile routers) MUST be destined for addresses within the mobile network, that means it is NOT a transit network, since no packets will enter the mobile network at one point, be forwarded, and leave the mobile network at another (or the same) point. (b) When you have nested MRs inside mobile network (a), then we just apply the above definition in a recursive manner: the mobile network served by one of the nested mobile routers becomes the mobile network in definition (a), then you just apply the same definition and it still holds true. >> >> Is it allowed for an MR to have two home agents, > Inasmuch as a MN can have two home agents. >> home addresses, > ditto. >> and network prefixes? > In the mobile network? definitely. >> Is there any case where the Mobile Network >> would become a transit network in such a situation? >> >> How about this: >> >> A Mobile Network is a network segment or subnet which can move >> and attach to arbitrary points in the Internet. A Mobile Network >> can only be accessed via specific gateways called Mobile Routers >> that manage its movement. Mobile Networks have (always exactly)| >> (at least) one Mobile Router serving them. > > > fine with me. > > >> >>>> JARI: Come to think of it, both the MR and the HA must know the >>>> assigned prefixes beforehand in any case, so I wonder if we >>>> need to communicate the prefixes at all?!? Can you cite an >>>> example where the HA would give a prefix to the MR without >>>> knowing it belongs to it? Or is the idea to prepare for the >>>> eventual bootstrapping support in MIPv6? >>> Yes, here are a couple examples: How about the case where an MR is authorized to use the set of prefixes P1, and it only wants to use a subset of those prefixes, set P2 (c P1). It does not want the subtraction P1 \ P2 prefixes forwarded. Next, consider a case where a bunch of MRs share a pool of prefixes. A prefix is dynamically assigned to the mobile network as soon as the MR authenticates to the HA. At that time, the HA picks a prefix and uses the option to explicitly tell the MR its prefix. >>> >>> >>> >>> well, we still havent figured out how to do prefix delegation >>> to a mobile router. there is a draft by Ralph Droms on extending >>> DHCPv6 prefix delegation for NEMO. not a WG draft yet. >>> >>> and there is this scenario, where the mobile router is delegated >>> more than prefix, but it could decide to setup forwarding for just >>> one prefix instead of all prefixes. this cant be dont without >>> carrying prefix information in the Binding Update. >> >> >> >> If this is the case, perhaps you could remove the static alternative >> then? My concern is mainly the number of alternatives. I'd rather >> have less alternatives, even if the BUs would carry a few more bytes >> in some cases... > > > I would rather remove the explicit prefix length mode. the implicit > mode I think is needed for minimal implementations of mobile routers. > they are also needed when routes are managed by manual configuartion > at the Home Agent, i.e. the routes are always there on the Home Agent > and are just modified to reflect the current point of attachment of > the mobile router. > >> >>>> JARI: So, presumably this includes forwarding of packets to >>>> the MR's own home address under all these prefixes, no? >>>> If so, I think we have the S=0 bit functionality when you >>>> set R=1 ;-) >>> >>> >>> >>> >>> :) only if the mobile router has configured all its home addresses >>> from its MNPs. >> >> >> >> Yeah. But to support S=0 all I have to do is to agree about >> suitable prefixes with my home agent, and set R=1... >> >> I'm not really suggesting you change anything, just making >> an observation. >> >> But doesn't this point to an additional reason for making >> the Prefix Table functionality mandatory? How else would >> the HA know which prefixes to give to the MR, if no prefixes >> were mentioned in the BU? > > > how about manually configured routes which always exist on > the Home Agent. we should keep it open. it is internal to > the Home Agent. Yes, I can see both of your points, since this is a "basic" support draft. Let's hear what others in the WG think about this, since it may be better to sacrifice flexibility for simplicity. > > >> >>>> JARI: Is there something that you would perhaps like to >>>> reference from MIPv6 regarding this tunneling, or is [3] enough? >>>> >>> >>> why? are we missing something. >> >> >> >> Would it be useful to follow MIPv6 base Section 5.5 guidelines >> on the use of source addresses? > > > we already say in the spec (section 5.5), what the source and > destination addresses should be for the inner and outer IPv6 > headers when sending packets through the bi-directional tunnel. > > >>>> This document introduces a new Prefix Information field in the >>>> Binding Update list structure. This field is used to store any >>>> prefix information that the Mobile Router includes in the Binding >>>> Update. If the Mobile Router sets the Mobile Router flag 'R' in >>>> the >>>> Binding Update, but does not include any prefix information in it >>>> (implicit mode), this field is set to null. >>>> >>>> JARI: So, if you run a routing protocol over the tunnel, will this >>>> information be updated in the BUL as well? >>> >>> >>> >>> >>> I think its not needed when a routing protocol is being run. >> >> >> >> Ok. Perhaps you could explicitly say this. > > > okay. > >>>> 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. >>>> >>>> JARI: I wonder if the above paragraph could be replaced with >>>> some reference to ND specs. As far as I can see, an MR should >>>> follow ND rules on its egress interface when on a visited >>>> network. >>> >>> >>> >>> >>> if you go by ND specs, routers ignore router advertisements. we are >>> infact saying router advertisements MUST NOT be ignored. >> >> >> >> I guess this is related to the MR turning to a host, as far >> as any external observer can determine, when it attaches to >> a foreign network. > > > right. implementors need to explicitly enable the mobile routers > to process router advertisements received on its egress interface. Yes, this is a good point which we have mentioned many times, but perhaps can be clarified more in the spec. To the entire Internet except the HA, the MR looks like a MN (host). To the entire mobile network, the MR looks like a fixed router. To the HA, the MR looks like an MN with some added bells and whistles. No other comments, but thanks for yours. TJ From exim@www1.ietf.org Tue Dec 2 20:06:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26954 for ; Tue, 2 Dec 2003 20:06: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 1ARLSx-0004Qg-BW for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 20:06:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3167BG017020 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 20:06:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLSx-0004QR-6A for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 20:06:07 -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 UAA26914 for ; Tue, 2 Dec 2003 20:05:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARLSv-0006x2-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 20:06:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARLSu-0006wz-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 20:06:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLSs-0004P9-AC; Tue, 02 Dec 2003 20:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLRy-0004Nx-Rm for nemo@optimus.ietf.org; Tue, 02 Dec 2003 20:05: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 UAA26874 for ; Tue, 2 Dec 2003 20:04:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARLRw-0006vu-00 for nemo@ietf.org; Tue, 02 Dec 2003 20:05:04 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1ARLRv-0006vk-00 for nemo@ietf.org; Tue, 02 Dec 2003 20:05:04 -0500 Received: from kniveton.com (wideload.kniveton.com [64.36.73.246]) by multihop.net (8.12.10/8.12.10) with ESMTP id hB3151r3006602 for ; Tue, 2 Dec 2003 17:05:02 -0800 (PST) (envelope-from tj@kniveton.com) Message-ID: <3FCD36BF.2070708@kniveton.com> Date: Tue, 02 Dec 2003 17:05:03 -0800 From: "T.J. Kniveton" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko References: <3FCBF3DE.7050202@iprg.nokia.com> <3FCC5A7B.4080509@kolumbus.fi> <3FCCEFF1.7090009@iprg.nokia.com> In-Reply-To: <3FCCEFF1.7090009@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > Jari Arkko wrote: > >>>> JARI: Hmm... there might be value in defining the terms in a >>>> self-contained >>>> manner here. I'm pretty sure you only use a subset of [8] >>>> terms, >>>> so it wouldn't be that long. >>> >>> I also believe in a document being self contained when it comes >>> to terminology. but there is a separate WG document on NEMO >>> terminology that is being advanced as an informational RFC. so >>> I am not sure. >> >> I think that other document would have value even if you >> copied some of the terms (used ones) to the basic nemo >> document. > Can you explain what the point is of having a separate NEMO terminology document if the basic support spec is self-defining? It seems that we followed the general trend in IETF WGs to have a more general terminology document, and then use those terms in the protocol specification. Can you point to a reference or suggestion by the IESG or ADs have suggested that everything be self-referential? I would personally like to know what the BCP on this is at the moment, since it seems like pushing the terms back in to make a larger document is like swimming upstream. >> Anyway, I don't think it is crucial. Just a practical issue >> that I noticed when reading. > Not crucial, but we would like to make sure that things end up in a best useable form. > I am okay with copying some of the terms from the terminology > document so that the basic support spec is self contained. if > nobody has any objection I will go ahead and do this. > >> >>>> Prefix Table >>>> >>>> It is a list of a Mobile Network Prefixes indexed >>>> by the Home Address of a Mobile Router. The prefix >>>> table >>>> is managed by the Home Agent and is used by the Home >>>> Agent >>>> to determine which Mobile Network Prefixes are owned >>>> a particular Mobile Router. This is an optional data >>>> structure. >>>> >>>> JARI: Really? Why is it optional? Sounds mandatory to me... >>> >>> >>> >>> >>> well, there could be scenarios where the mobile routers are not >>> expected to misbehave. and there could be other ways for verifying >>> this. so we left it optional. I dont mind making it mandatory. >> A table of owned prefixes is only one possible way for the Home Agent to determine which prefixes an authenticated MR is authorized to use NEMO with. That's why it's optional. >> >> >> That would make sense. > > > you mean making it mandatory makes sense? maybe a SHOULD, not a > MUST. > >> Imho all nemo-based products >> should support this function. > > > I agree too. Of a prefix table? Yes, in statically configured cases, which is probably the most useable in the near term, we would highly recommend using this static mapping. But someone could always hook up a database and do lookups, when the list is managed by another piece of software. >>>> A Mobile Network is a network segment or subnet which can move >>>> and attach to arbitrary points in the Internet. A Mobile Network >>>> does not allow any transit traffic and can only be accessed via >>>> specific gateways called Mobile Routers that manage its movement. >>>> >>>> JARI: The above is a bit unclear. I think you mean that the >>>> nodes behind the MR can't access the internet directly, they >>>> have to go through the MR and the HA. >>> >>> >>> >>> >>> actually no. it means traffic to the Mobile Network can reach >>> the Mobile Network only through mobile routers. it also says >>> mobile networks are not transit networks. always stub networks. >> >> >> >> I'm still having some difficulty with the transit network >> part. I looked up one definition of a transit network from RFC >> 1584, which talks about the number of attached routers. However, >> in the nested nemo case you could actually have several attached >> routers, hidden inside tunnels. And would you allow multiple >> MRs per Mobile Network or not? I think not, because then you >> would appear like a transit network, according to the >> RFC 1584 definition. OTOH, I'm not sure why such a limitation >> would be necessary in the technical sense. > True, traffic inside a mobile network can transit from one sub-network to another sub-network. However, consider this rule, which might help clarify: (a) For all mobile networks, there is a defined boundary in which all nodes are considered part of the mobile network, and then we say that all packets entering the mobile network (through one or more top-level mobile routers) MUST be destined for addresses within the mobile network, that means it is NOT a transit network, since no packets will enter the mobile network at one point, be forwarded, and leave the mobile network at another (or the same) point. (b) When you have nested MRs inside mobile network (a), then we just apply the above definition in a recursive manner: the mobile network served by one of the nested mobile routers becomes the mobile network in definition (a), then you just apply the same definition and it still holds true. >> >> Is it allowed for an MR to have two home agents, > Inasmuch as a MN can have two home agents. >> home addresses, > ditto. >> and network prefixes? > In the mobile network? definitely. >> Is there any case where the Mobile Network >> would become a transit network in such a situation? >> >> How about this: >> >> A Mobile Network is a network segment or subnet which can move >> and attach to arbitrary points in the Internet. A Mobile Network >> can only be accessed via specific gateways called Mobile Routers >> that manage its movement. Mobile Networks have (always exactly)| >> (at least) one Mobile Router serving them. > > > fine with me. > > >> >>>> JARI: Come to think of it, both the MR and the HA must know the >>>> assigned prefixes beforehand in any case, so I wonder if we >>>> need to communicate the prefixes at all?!? Can you cite an >>>> example where the HA would give a prefix to the MR without >>>> knowing it belongs to it? Or is the idea to prepare for the >>>> eventual bootstrapping support in MIPv6? >>> Yes, here are a couple examples: How about the case where an MR is authorized to use the set of prefixes P1, and it only wants to use a subset of those prefixes, set P2 (c P1). It does not want the subtraction P1 \ P2 prefixes forwarded. Next, consider a case where a bunch of MRs share a pool of prefixes. A prefix is dynamically assigned to the mobile network as soon as the MR authenticates to the HA. At that time, the HA picks a prefix and uses the option to explicitly tell the MR its prefix. >>> >>> >>> >>> well, we still havent figured out how to do prefix delegation >>> to a mobile router. there is a draft by Ralph Droms on extending >>> DHCPv6 prefix delegation for NEMO. not a WG draft yet. >>> >>> and there is this scenario, where the mobile router is delegated >>> more than prefix, but it could decide to setup forwarding for just >>> one prefix instead of all prefixes. this cant be dont without >>> carrying prefix information in the Binding Update. >> >> >> >> If this is the case, perhaps you could remove the static alternative >> then? My concern is mainly the number of alternatives. I'd rather >> have less alternatives, even if the BUs would carry a few more bytes >> in some cases... > > > I would rather remove the explicit prefix length mode. the implicit > mode I think is needed for minimal implementations of mobile routers. > they are also needed when routes are managed by manual configuartion > at the Home Agent, i.e. the routes are always there on the Home Agent > and are just modified to reflect the current point of attachment of > the mobile router. > >> >>>> JARI: So, presumably this includes forwarding of packets to >>>> the MR's own home address under all these prefixes, no? >>>> If so, I think we have the S=0 bit functionality when you >>>> set R=1 ;-) >>> >>> >>> >>> >>> :) only if the mobile router has configured all its home addresses >>> from its MNPs. >> >> >> >> Yeah. But to support S=0 all I have to do is to agree about >> suitable prefixes with my home agent, and set R=1... >> >> I'm not really suggesting you change anything, just making >> an observation. >> >> But doesn't this point to an additional reason for making >> the Prefix Table functionality mandatory? How else would >> the HA know which prefixes to give to the MR, if no prefixes >> were mentioned in the BU? > > > how about manually configured routes which always exist on > the Home Agent. we should keep it open. it is internal to > the Home Agent. Yes, I can see both of your points, since this is a "basic" support draft. Let's hear what others in the WG think about this, since it may be better to sacrifice flexibility for simplicity. > > >> >>>> JARI: Is there something that you would perhaps like to >>>> reference from MIPv6 regarding this tunneling, or is [3] enough? >>>> >>> >>> why? are we missing something. >> >> >> >> Would it be useful to follow MIPv6 base Section 5.5 guidelines >> on the use of source addresses? > > > we already say in the spec (section 5.5), what the source and > destination addresses should be for the inner and outer IPv6 > headers when sending packets through the bi-directional tunnel. > > >>>> This document introduces a new Prefix Information field in the >>>> Binding Update list structure. This field is used to store any >>>> prefix information that the Mobile Router includes in the Binding >>>> Update. If the Mobile Router sets the Mobile Router flag 'R' in >>>> the >>>> Binding Update, but does not include any prefix information in it >>>> (implicit mode), this field is set to null. >>>> >>>> JARI: So, if you run a routing protocol over the tunnel, will this >>>> information be updated in the BUL as well? >>> >>> >>> >>> >>> I think its not needed when a routing protocol is being run. >> >> >> >> Ok. Perhaps you could explicitly say this. > > > okay. > >>>> 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. >>>> >>>> JARI: I wonder if the above paragraph could be replaced with >>>> some reference to ND specs. As far as I can see, an MR should >>>> follow ND rules on its egress interface when on a visited >>>> network. >>> >>> >>> >>> >>> if you go by ND specs, routers ignore router advertisements. we are >>> infact saying router advertisements MUST NOT be ignored. >> >> >> >> I guess this is related to the MR turning to a host, as far >> as any external observer can determine, when it attaches to >> a foreign network. > > > right. implementors need to explicitly enable the mobile routers > to process router advertisements received on its egress interface. Yes, this is a good point which we have mentioned many times, but perhaps can be clarified more in the spec. To the entire Internet except the HA, the MR looks like a MN (host). To the entire mobile network, the MR looks like a fixed router. To the HA, the MR looks like an MN with some added bells and whistles. No other comments, but thanks for yours. TJ From nemo-admin@ietf.org Tue Dec 2 20:12:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27167 for ; Tue, 2 Dec 2003 20:12: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 1ARLYf-0005Ab-JM; Tue, 02 Dec 2003 20:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLY9-00059u-3b for nemo@optimus.ietf.org; Tue, 02 Dec 2003 20:11: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 UAA27126 for ; Tue, 2 Dec 2003 20:11:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARLY7-0006zs-00 for nemo@ietf.org; Tue, 02 Dec 2003 20:11:27 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1ARLY6-0006zd-00 for nemo@ietf.org; Tue, 02 Dec 2003 20:11:26 -0500 Received: from kniveton.com (wideload.kniveton.com [64.36.73.246]) by multihop.net (8.12.10/8.12.10) with ESMTP id hB31A4r3006622; Tue, 2 Dec 2003 17:10:04 -0800 (PST) (envelope-from tj@kniveton.com) Message-ID: <3FCD37EE.7080008@kniveton.com> Date: Tue, 02 Dec 2003 17:10:06 -0800 From: "T.J. Kniveton" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: nemo@ietf.org Subject: Re: [nemo] Re: issue xxx: requirements chapter for Nemo. References: <3FCD30CA.7020106@iprg.nokia.com> In-Reply-To: <3FCD30CA.7020106@iprg.nokia.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: , Content-Transfer-Encoding: 7bit Question: Is there a specific complaint, or reason why the current spec does not adequately spell out the requirements of nodes to operate with NEMO? It seems like it's not too hard to see or figure out. I'd like to avoid making the draft longer than necessary.. best to keep it simpler if adequate. tj From exim@www1.ietf.org Tue Dec 2 20:12:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27182 for ; Tue, 2 Dec 2003 20:12:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLYh-0005Co-0S for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 20:12:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB31C2Fg019993 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 20:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLYg-0005CL-R4 for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 20:12: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 UAA27145 for ; Tue, 2 Dec 2003 20:11:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARLYe-00070M-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 20:12:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARLYe-00070J-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 20:12:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLYf-0005Ab-JM; Tue, 02 Dec 2003 20:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLY9-00059u-3b for nemo@optimus.ietf.org; Tue, 02 Dec 2003 20:11: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 UAA27126 for ; Tue, 2 Dec 2003 20:11:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARLY7-0006zs-00 for nemo@ietf.org; Tue, 02 Dec 2003 20:11:27 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1ARLY6-0006zd-00 for nemo@ietf.org; Tue, 02 Dec 2003 20:11:26 -0500 Received: from kniveton.com (wideload.kniveton.com [64.36.73.246]) by multihop.net (8.12.10/8.12.10) with ESMTP id hB31A4r3006622; Tue, 2 Dec 2003 17:10:04 -0800 (PST) (envelope-from tj@kniveton.com) Message-ID: <3FCD37EE.7080008@kniveton.com> Date: Tue, 02 Dec 2003 17:10:06 -0800 From: "T.J. Kniveton" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: nemo@ietf.org Subject: Re: [nemo] Re: issue xxx: requirements chapter for Nemo. References: <3FCD30CA.7020106@iprg.nokia.com> In-Reply-To: <3FCD30CA.7020106@iprg.nokia.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Question: Is there a specific complaint, or reason why the current spec does not adequately spell out the requirements of nodes to operate with NEMO? It seems like it's not too hard to see or figure out. I'd like to avoid making the draft longer than necessary.. best to keep it simpler if adequate. tj From nemo-admin@ietf.org Tue Dec 2 20:28:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27589 for ; Tue, 2 Dec 2003 20:28:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLo8-0005fz-Ti; Tue, 02 Dec 2003 20:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLnz-0005ff-DT for nemo@optimus.ietf.org; Tue, 02 Dec 2003 20:27: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 UAA27564 for ; Tue, 2 Dec 2003 20:27:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARLnx-0007A0-00 for nemo@ietf.org; Tue, 02 Dec 2003 20:27:49 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARLnw-00079Y-00 for nemo@ietf.org; Tue, 02 Dec 2003 20:27:48 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB31RHC27554; Tue, 2 Dec 2003 17:27:17 -0800 X-mProtect: <200312030127> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdI6C4dH; Tue, 02 Dec 2003 17:27:15 PST Message-ID: <3FCD3D39.3010409@iprg.nokia.com> Date: Tue, 02 Dec 2003 17:32:41 -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: "T.J. Kniveton" CC: nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko References: <3FCBF3DE.7050202@iprg.nokia.com> <3FCC5A7B.4080509@kolumbus.fi> <3FCCEFF1.7090009@iprg.nokia.com> <3FCD36BF.2070708@kniveton.com> In-Reply-To: <3FCD36BF.2070708@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: , Content-Transfer-Encoding: 7bit T.J. Kniveton wrote: > Vijay Devarapalli wrote: > >> Jari Arkko wrote: >> >>>>> JARI: Hmm... there might be value in defining the terms in a >>>>> self-contained >>>>> manner here. I'm pretty sure you only use a subset of [8] >>>>> terms, >>>>> so it wouldn't be that long. >>>> >>>> >>>> I also believe in a document being self contained when it comes >>>> to terminology. but there is a separate WG document on NEMO >>>> terminology that is being advanced as an informational RFC. so >>>> I am not sure. >>> >>> >>> I think that other document would have value even if you >>> copied some of the terms (used ones) to the basic nemo >>> document. >> >> > Can you explain what the point is of having a separate NEMO terminology > document if the basic support spec is self-defining? well, I see the terminology document being absolutely essential for any meaningful discussion on the mailing list. before the terminology document was written, most of the time everybody was trying to figure what the other person was referring to. I agree with Jari that the basic support draft should be self-contained when it comes to terminology. Vijay From exim@www1.ietf.org Tue Dec 2 20:28:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27604 for ; Tue, 2 Dec 2003 20:28: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 1ARLoC-0005h7-7A for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 20:28:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB31S4PB021883 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 20:28:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLoC-0005gs-2d for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 20:28: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 UAA27571 for ; Tue, 2 Dec 2003 20:27:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARLo9-0007AH-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 20:28:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARLo9-0007AE-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 20:28:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLo8-0005fz-Ti; Tue, 02 Dec 2003 20:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLnz-0005ff-DT for nemo@optimus.ietf.org; Tue, 02 Dec 2003 20:27: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 UAA27564 for ; Tue, 2 Dec 2003 20:27:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARLnx-0007A0-00 for nemo@ietf.org; Tue, 02 Dec 2003 20:27:49 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARLnw-00079Y-00 for nemo@ietf.org; Tue, 02 Dec 2003 20:27:48 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB31RHC27554; Tue, 2 Dec 2003 17:27:17 -0800 X-mProtect: <200312030127> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdI6C4dH; Tue, 02 Dec 2003 17:27:15 PST Message-ID: <3FCD3D39.3010409@iprg.nokia.com> Date: Tue, 02 Dec 2003 17:32:41 -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: "T.J. Kniveton" CC: nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko References: <3FCBF3DE.7050202@iprg.nokia.com> <3FCC5A7B.4080509@kolumbus.fi> <3FCCEFF1.7090009@iprg.nokia.com> <3FCD36BF.2070708@kniveton.com> In-Reply-To: <3FCD36BF.2070708@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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit T.J. Kniveton wrote: > Vijay Devarapalli wrote: > >> Jari Arkko wrote: >> >>>>> JARI: Hmm... there might be value in defining the terms in a >>>>> self-contained >>>>> manner here. I'm pretty sure you only use a subset of [8] >>>>> terms, >>>>> so it wouldn't be that long. >>>> >>>> >>>> I also believe in a document being self contained when it comes >>>> to terminology. but there is a separate WG document on NEMO >>>> terminology that is being advanced as an informational RFC. so >>>> I am not sure. >>> >>> >>> I think that other document would have value even if you >>> copied some of the terms (used ones) to the basic nemo >>> document. >> >> > Can you explain what the point is of having a separate NEMO terminology > document if the basic support spec is self-defining? well, I see the terminology document being absolutely essential for any meaningful discussion on the mailing list. before the terminology document was written, most of the time everybody was trying to figure what the other person was referring to. I agree with Jari that the basic support draft should be self-contained when it comes to terminology. Vijay From nemo-admin@ietf.org Tue Dec 2 21:03:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28648 for ; Tue, 2 Dec 2003 21:03:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARMM1-0007Bu-8c; Tue, 02 Dec 2003 21:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARMLL-0007Bb-I9 for nemo@optimus.ietf.org; Tue, 02 Dec 2003 21:02: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 VAA28639 for ; Tue, 2 Dec 2003 21:02:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARMLI-0007aq-00 for nemo@ietf.org; Tue, 02 Dec 2003 21:02:16 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARMLI-0007af-00 for nemo@ietf.org; Tue, 02 Dec 2003 21:02:16 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB321A607352; Tue, 2 Dec 2003 18:01:10 -0800 X-mProtect: <200312030201> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd1wdHJW; Tue, 02 Dec 2003 18:01:09 PST Message-ID: <3FCD452B.7000704@iprg.nokia.com> Date: Tue, 02 Dec 2003 18:06:35 -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: "Souhwan Jung" , nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Closing Issue 23 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 Souhwan, heres some text to be added to the Security Considerations section to prevent tunneling threats you identified in your draft. The Mobile Router has to perform ingress filtering on packets received from the Mobile Network to ensure that nodes in the Mobile Network do not use the bi-directional tunnel to launch IP spoofing attacks. In particular the Mobile Router SHOULD check that the IP source address in the packets received from the nodes in the Mobile Network belongs to the Mobile Network Prefix and is not the same as one of the addresses used by the Mobile Router. In case the Mobile Router receives a IP-in-IP tunneled packet from a node in the Mobile Network and the Mobile Router has to forward the decapsulated packet, it SHOULD perform the above mentioned checks on the source address of the inner packet. what do you think about this? Vijay From exim@www1.ietf.org Tue Dec 2 21:03:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28663 for ; Tue, 2 Dec 2003 21:03: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 1ARMM5-0007Cu-65 for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 21:03:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3235ed027698 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 21:03:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARMM4-0007Cf-UR for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 21:03: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 VAA28645 for ; Tue, 2 Dec 2003 21:02:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARMM2-0007az-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 21:03:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARMM2-0007aw-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 21:03:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARMM1-0007Bu-8c; Tue, 02 Dec 2003 21:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARMLL-0007Bb-I9 for nemo@optimus.ietf.org; Tue, 02 Dec 2003 21:02: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 VAA28639 for ; Tue, 2 Dec 2003 21:02:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARMLI-0007aq-00 for nemo@ietf.org; Tue, 02 Dec 2003 21:02:16 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARMLI-0007af-00 for nemo@ietf.org; Tue, 02 Dec 2003 21:02:16 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB321A607352; Tue, 2 Dec 2003 18:01:10 -0800 X-mProtect: <200312030201> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd1wdHJW; Tue, 02 Dec 2003 18:01:09 PST Message-ID: <3FCD452B.7000704@iprg.nokia.com> Date: Tue, 02 Dec 2003 18:06:35 -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: "Souhwan Jung" , nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Closing Issue 23 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Souhwan, heres some text to be added to the Security Considerations section to prevent tunneling threats you identified in your draft. The Mobile Router has to perform ingress filtering on packets received from the Mobile Network to ensure that nodes in the Mobile Network do not use the bi-directional tunnel to launch IP spoofing attacks. In particular the Mobile Router SHOULD check that the IP source address in the packets received from the nodes in the Mobile Network belongs to the Mobile Network Prefix and is not the same as one of the addresses used by the Mobile Router. In case the Mobile Router receives a IP-in-IP tunneled packet from a node in the Mobile Network and the Mobile Router has to forward the decapsulated packet, it SHOULD perform the above mentioned checks on the source address of the inner packet. what do you think about this? Vijay From nemo-admin@ietf.org Tue Dec 2 22:23:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00621 for ; Tue, 2 Dec 2003 22:23:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNbS-00031C-4x; Tue, 02 Dec 2003 22:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNbB-00030M-21 for nemo@optimus.ietf.org; Tue, 02 Dec 2003 22:22: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 WAA00571 for ; Tue, 2 Dec 2003 22:22:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARNb7-0000c1-00 for nemo@ietf.org; Tue, 02 Dec 2003 22:22:41 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARNb7-0000bW-00 for nemo@ietf.org; Tue, 02 Dec 2003 22:22:41 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB33M0g31187; Tue, 2 Dec 2003 19:22:00 -0800 X-mProtect: <200312030322> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdB7Nr8Y; Tue, 02 Dec 2003 19:21:59 PST Message-ID: <3FCD581E.3030606@iprg.nokia.com> Date: Tue, 02 Dec 2003 19:27:26 -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: Jari Arkko CC: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: MR returning home (was Re: [nemo] review of the nemo basic spec) References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> In-Reply-To: <3FCBC8B5.6030206@iprg.nokia.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: , Content-Transfer-Encoding: 7bit hi Jari, Vijay Devarapalli wrote: > >> >>>> o A related issue is in which order do the various >>>> things take place? When do you decide you are >>>> in the home network and can act as a router, >>>> and when do you join various router-related >>>> multicast addresses, for instance? >>>> >>> >>> >>> Yes, that would be the assumption. I understand that you suggest adding >>> more text about that phase, correct? >> >> >> >> Yes. > > > I will add some text. here is some text for this. I added a new section. 5.8. Returning Home When the Mobile Router realizes it has returned to its home link through movement detection mechanisms, it MUST de-register with its Home Agent. The Mobile Router MUST implement and follow the returning home procedure defined for a mobile node in [1]. In addition, the Mobile Router MAY start behaving as a router on its egress interface. In particular, - The Mobile Router MAY send router advertisements on its egress interfaces. But the router lifetime SHOULD be set to 0, so that hosts on the home link do not pick the Mobile Router as the default router. - The Mobile Router MAY join the All Routers multicast group on the home link. - The Mobile Router MAY send routing protocol messages on its egress interface if it is configured to run a dynamic routing protocol. comments? Vijay From exim@www1.ietf.org Tue Dec 2 22:23:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00636 for ; Tue, 2 Dec 2003 22:23: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 1ARNbV-00032b-GC for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 22:23:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB33N52n011683 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 22:23:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNbV-00032M-Bb for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 22:23: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 WAA00584 for ; Tue, 2 Dec 2003 22:22:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARNbS-0000cT-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 22:23:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARNbR-0000cQ-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 22:23:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNbS-00031C-4x; Tue, 02 Dec 2003 22:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNbB-00030M-21 for nemo@optimus.ietf.org; Tue, 02 Dec 2003 22:22: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 WAA00571 for ; Tue, 2 Dec 2003 22:22:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARNb7-0000c1-00 for nemo@ietf.org; Tue, 02 Dec 2003 22:22:41 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARNb7-0000bW-00 for nemo@ietf.org; Tue, 02 Dec 2003 22:22:41 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB33M0g31187; Tue, 2 Dec 2003 19:22:00 -0800 X-mProtect: <200312030322> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdB7Nr8Y; Tue, 02 Dec 2003 19:21:59 PST Message-ID: <3FCD581E.3030606@iprg.nokia.com> Date: Tue, 02 Dec 2003 19:27:26 -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: Jari Arkko CC: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: MR returning home (was Re: [nemo] review of the nemo basic spec) References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> In-Reply-To: <3FCBC8B5.6030206@iprg.nokia.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Jari, Vijay Devarapalli wrote: > >> >>>> o A related issue is in which order do the various >>>> things take place? When do you decide you are >>>> in the home network and can act as a router, >>>> and when do you join various router-related >>>> multicast addresses, for instance? >>>> >>> >>> >>> Yes, that would be the assumption. I understand that you suggest adding >>> more text about that phase, correct? >> >> >> >> Yes. > > > I will add some text. here is some text for this. I added a new section. 5.8. Returning Home When the Mobile Router realizes it has returned to its home link through movement detection mechanisms, it MUST de-register with its Home Agent. The Mobile Router MUST implement and follow the returning home procedure defined for a mobile node in [1]. In addition, the Mobile Router MAY start behaving as a router on its egress interface. In particular, - The Mobile Router MAY send router advertisements on its egress interfaces. But the router lifetime SHOULD be set to 0, so that hosts on the home link do not pick the Mobile Router as the default router. - The Mobile Router MAY join the All Routers multicast group on the home link. - The Mobile Router MAY send routing protocol messages on its egress interface if it is configured to run a dynamic routing protocol. comments? Vijay From nemo-admin@ietf.org Tue Dec 2 22:29:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01008 for ; Tue, 2 Dec 2003 22:29: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 1ARNhE-0003JN-PZ; Tue, 02 Dec 2003 22:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNh0-0003J8-Pc for nemo@optimus.ietf.org; Tue, 02 Dec 2003 22:28: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 WAA00951 for ; Tue, 2 Dec 2003 22:28:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARNgx-0000kn-00 for nemo@ietf.org; Tue, 02 Dec 2003 22:28:43 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1ARNgw-0000kR-00 for nemo@ietf.org; Tue, 02 Dec 2003 22:28:42 -0500 Received: from kniveton.com (wideload.kniveton.com [64.36.73.246]) by multihop.net (8.12.10/8.12.10) with ESMTP id hB33S6r3007883; Tue, 2 Dec 2003 19:28:06 -0800 (PST) (envelope-from tj@kniveton.com) Message-ID: <3FCD5847.1010809@kniveton.com> Date: Tue, 02 Dec 2003 19:28:07 -0800 From: "T.J. Kniveton" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: nemo@ietf.org Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic spec) References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> In-Reply-To: <3FCD581E.3030606@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > > - The Mobile Router MAY send router advertisements on its egress > interfaces. But the router lifetime SHOULD be set to 0, so that > hosts on the home link do not pick the Mobile Router as the > default router. I'm missing something.. Why would the MR put out RAs on the egress interface? I can see why it would put them out on the ingress interface, and use a routing protocol on the egress interface to advertise the mobile network.. but what would the RA contain? tj From exim@www1.ietf.org Tue Dec 2 22:29:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01023 for ; Tue, 2 Dec 2003 22:29: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 1ARNhH-0003Ls-1V for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 22:29:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB33T39w012878 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 22:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNhG-0003KN-Ry for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 22:29: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 WAA01000 for ; Tue, 2 Dec 2003 22:28:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARNhD-0000lz-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 22:28:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARNhD-0000lw-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 22:28:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNhE-0003JN-PZ; Tue, 02 Dec 2003 22:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNh0-0003J8-Pc for nemo@optimus.ietf.org; Tue, 02 Dec 2003 22:28: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 WAA00951 for ; Tue, 2 Dec 2003 22:28:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARNgx-0000kn-00 for nemo@ietf.org; Tue, 02 Dec 2003 22:28:43 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1ARNgw-0000kR-00 for nemo@ietf.org; Tue, 02 Dec 2003 22:28:42 -0500 Received: from kniveton.com (wideload.kniveton.com [64.36.73.246]) by multihop.net (8.12.10/8.12.10) with ESMTP id hB33S6r3007883; Tue, 2 Dec 2003 19:28:06 -0800 (PST) (envelope-from tj@kniveton.com) Message-ID: <3FCD5847.1010809@kniveton.com> Date: Tue, 02 Dec 2003 19:28:07 -0800 From: "T.J. Kniveton" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: nemo@ietf.org Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic spec) References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> In-Reply-To: <3FCD581E.3030606@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > > - The Mobile Router MAY send router advertisements on its egress > interfaces. But the router lifetime SHOULD be set to 0, so that > hosts on the home link do not pick the Mobile Router as the > default router. I'm missing something.. Why would the MR put out RAs on the egress interface? I can see why it would put them out on the ingress interface, and use a routing protocol on the egress interface to advertise the mobile network.. but what would the RA contain? tj From nemo-admin@ietf.org Tue Dec 2 22:34:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01180 for ; Tue, 2 Dec 2003 22:34: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 1ARNm6-0003XC-Bj; Tue, 02 Dec 2003 22: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 1ARNlv-0003Wy-MJ for nemo@optimus.ietf.org; Tue, 02 Dec 2003 22:33: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 WAA01131 for ; Tue, 2 Dec 2003 22:33:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARNls-0000p9-00 for nemo@ietf.org; Tue, 02 Dec 2003 22:33:48 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARNlr-0000oq-00 for nemo@ietf.org; Tue, 02 Dec 2003 22:33:47 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB33XHI05020; Tue, 2 Dec 2003 19:33:17 -0800 X-mProtect: <200312030333> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkcYJiE; Tue, 02 Dec 2003 19:33:16 PST Message-ID: <3FCD5AC2.3060503@iprg.nokia.com> Date: Tue, 02 Dec 2003 19:38:42 -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: "T.J. Kniveton" CC: nemo@ietf.org Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic spec) References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> <3FCD5847.1010809@kniveton.com> In-Reply-To: <3FCD5847.1010809@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: , Content-Transfer-Encoding: 7bit T.J. Kniveton wrote: > > > Vijay Devarapalli wrote: > >> >> - The Mobile Router MAY send router advertisements on its egress >> interfaces. But the router lifetime SHOULD be set to 0, so that >> hosts on the home link do not pick the Mobile Router as the >> default router. > > > I'm missing something.. Why would the MR put out RAs on the egress > interface? I can see why it would put them out on the ingress interface, > and use a routing protocol on the egress interface to advertise the > mobile network.. but what would the RA contain? > a router by its nature sends out router advertisements. there is no spec prohibiting it from sending out router advertisements on any of its interfaces. the NEMO basic spec restricts the mobile router to not send router advertisements on its egress interface when it is attached to a visited link. when it returns to a home link, we are saying it MAY start sending again. but we have to prevent hosts on the home link from configuring the mobile router as a default router. so we say the router lifetime SHOULD be set to 0. Vijay From exim@www1.ietf.org Tue Dec 2 22:34:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01195 for ; Tue, 2 Dec 2003 22:34:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNm9-0003Y8-An for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 22:34:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB33Y5Wj013643 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 22:34:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNm8-0003Xy-2f for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 22:34: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 WAA01135 for ; Tue, 2 Dec 2003 22:33:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARNm4-0000pG-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 22:34:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARNm4-0000pD-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 22:34:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNm6-0003XC-Bj; Tue, 02 Dec 2003 22: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 1ARNlv-0003Wy-MJ for nemo@optimus.ietf.org; Tue, 02 Dec 2003 22:33: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 WAA01131 for ; Tue, 2 Dec 2003 22:33:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARNls-0000p9-00 for nemo@ietf.org; Tue, 02 Dec 2003 22:33:48 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARNlr-0000oq-00 for nemo@ietf.org; Tue, 02 Dec 2003 22:33:47 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB33XHI05020; Tue, 2 Dec 2003 19:33:17 -0800 X-mProtect: <200312030333> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkcYJiE; Tue, 02 Dec 2003 19:33:16 PST Message-ID: <3FCD5AC2.3060503@iprg.nokia.com> Date: Tue, 02 Dec 2003 19:38:42 -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: "T.J. Kniveton" CC: nemo@ietf.org Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic spec) References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> <3FCD5847.1010809@kniveton.com> In-Reply-To: <3FCD5847.1010809@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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit T.J. Kniveton wrote: > > > Vijay Devarapalli wrote: > >> >> - The Mobile Router MAY send router advertisements on its egress >> interfaces. But the router lifetime SHOULD be set to 0, so that >> hosts on the home link do not pick the Mobile Router as the >> default router. > > > I'm missing something.. Why would the MR put out RAs on the egress > interface? I can see why it would put them out on the ingress interface, > and use a routing protocol on the egress interface to advertise the > mobile network.. but what would the RA contain? > a router by its nature sends out router advertisements. there is no spec prohibiting it from sending out router advertisements on any of its interfaces. the NEMO basic spec restricts the mobile router to not send router advertisements on its egress interface when it is attached to a visited link. when it returns to a home link, we are saying it MAY start sending again. but we have to prevent hosts on the home link from configuring the mobile router as a default router. so we say the router lifetime SHOULD be set to 0. Vijay From nemo-admin@ietf.org Tue Dec 2 22:38:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01436 for ; Tue, 2 Dec 2003 22:38: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 1ARNpx-0003tA-3Q; Tue, 02 Dec 2003 22: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 1ARNp4-0003iD-35 for nemo@optimus.ietf.org; Tue, 02 Dec 2003 22:37: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 WAA01367 for ; Tue, 2 Dec 2003 22:36:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARNp0-0000uy-00 for nemo@ietf.org; Tue, 02 Dec 2003 22:37:02 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1ARNoz-0000ts-00 for nemo@ietf.org; Tue, 02 Dec 2003 22:37:02 -0500 Received: from kniveton.com (wideload.kniveton.com [64.36.73.246]) by multihop.net (8.12.10/8.12.10) with ESMTP id hB33a8r3008035; Tue, 2 Dec 2003 19:36:08 -0800 (PST) (envelope-from tj@kniveton.com) Message-ID: <3FCD5A29.8070302@kniveton.com> Date: Tue, 02 Dec 2003 19:36:09 -0800 From: "T.J. Kniveton" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: nemo@ietf.org Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic spec) References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> <3FCD5847.1010809@kniveton.com> <3FCD5AC2.3060503@iprg.nokia.com> In-Reply-To: <3FCD5AC2.3060503@iprg.nokia.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: , Content-Transfer-Encoding: 7bit OK.. can you give me an example of when any MR, ever, would get any benefit by sending RAs on its egress interface? If not, the text there should probably point out this fact, or just say..don't send them. From exim@www1.ietf.org Tue Dec 2 22:38:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01451 for ; Tue, 2 Dec 2003 22:38:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNq3-0003yX-Gm for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 22:38:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB33c72B015044 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 22: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 1ARNq0-0003uM-Fq for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 22:38: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 WAA01423 for ; Tue, 2 Dec 2003 22:37:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARNpx-0000wR-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 22:38:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARNpw-0000wO-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 22:38:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNpx-0003tA-3Q; Tue, 02 Dec 2003 22: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 1ARNp4-0003iD-35 for nemo@optimus.ietf.org; Tue, 02 Dec 2003 22:37: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 WAA01367 for ; Tue, 2 Dec 2003 22:36:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARNp0-0000uy-00 for nemo@ietf.org; Tue, 02 Dec 2003 22:37:02 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1ARNoz-0000ts-00 for nemo@ietf.org; Tue, 02 Dec 2003 22:37:02 -0500 Received: from kniveton.com (wideload.kniveton.com [64.36.73.246]) by multihop.net (8.12.10/8.12.10) with ESMTP id hB33a8r3008035; Tue, 2 Dec 2003 19:36:08 -0800 (PST) (envelope-from tj@kniveton.com) Message-ID: <3FCD5A29.8070302@kniveton.com> Date: Tue, 02 Dec 2003 19:36:09 -0800 From: "T.J. Kniveton" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: nemo@ietf.org Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic spec) References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> <3FCD5847.1010809@kniveton.com> <3FCD5AC2.3060503@iprg.nokia.com> In-Reply-To: <3FCD5AC2.3060503@iprg.nokia.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit OK.. can you give me an example of when any MR, ever, would get any benefit by sending RAs on its egress interface? If not, the text there should probably point out this fact, or just say..don't send them. From nemo-admin@ietf.org Tue Dec 2 22:48:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01649 for ; Tue, 2 Dec 2003 22:48: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 1ARNzd-0004Ep-Em; Tue, 02 Dec 2003 22: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 1ARNz3-0004EL-Cs for nemo@optimus.ietf.org; Tue, 02 Dec 2003 22:47: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 WAA01618 for ; Tue, 2 Dec 2003 22:47:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARNyz-00011u-00 for nemo@ietf.org; Tue, 02 Dec 2003 22:47:21 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARNyz-00011a-00 for nemo@ietf.org; Tue, 02 Dec 2003 22:47:21 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB33kpa12224; Tue, 2 Dec 2003 19:46:51 -0800 X-mProtect: <200312030346> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhHsmFf; Tue, 02 Dec 2003 19:46:49 PST Message-ID: <3FCD5DF0.7090309@iprg.nokia.com> Date: Tue, 02 Dec 2003 19:52:16 -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: "T.J. Kniveton" CC: nemo@ietf.org, "James Kempf" Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic spec) References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> <3FCD5847.1010809@kniveton.com> <3FCD5AC2.3060503@iprg.nokia.com> <3FCD5A29.807 In-Reply-To: <3FCD5A29.8070302@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: , Content-Transfer-Encoding: 7bit T.J. Kniveton wrote: > OK.. can you give me an example of when any MR, ever, would get any > benefit by sending RAs on its egress interface? If not, the text there > should probably point out this fact, or just say..don't send them. not for us to prohibit this, TJ. neighbor discovery specs dont prohibit it. Jim and I had a discussion on this. the discussion is at http://people.nokia.net/vijayd/nemo/issue21.txt. maybe you should pose this question on the IPv6 mailing list. Jim has sent a mail to Hesham to clarify this when RFC 2461 is being revised. it hasnt been discussed on the IPv6 mailing list, though. Vijay From exim@www1.ietf.org Tue Dec 2 22:48:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01664 for ; Tue, 2 Dec 2003 22:48:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNzg-0004Fp-Oy for nemo-archive@odin.ietf.org; Tue, 02 Dec 2003 22:48:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB33m48S016347 for nemo-archive@odin.ietf.org; Tue, 2 Dec 2003 22:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNzg-0004Fa-Hx for nemo-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 22:48: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 WAA01636 for ; Tue, 2 Dec 2003 22:47:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARNzd-00012I-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 22:48:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARNzc-00012F-00 for nemo-web-archive@ietf.org; Tue, 02 Dec 2003 22:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNzd-0004Ep-Em; Tue, 02 Dec 2003 22: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 1ARNz3-0004EL-Cs for nemo@optimus.ietf.org; Tue, 02 Dec 2003 22:47: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 WAA01618 for ; Tue, 2 Dec 2003 22:47:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARNyz-00011u-00 for nemo@ietf.org; Tue, 02 Dec 2003 22:47:21 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARNyz-00011a-00 for nemo@ietf.org; Tue, 02 Dec 2003 22:47:21 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB33kpa12224; Tue, 2 Dec 2003 19:46:51 -0800 X-mProtect: <200312030346> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhHsmFf; Tue, 02 Dec 2003 19:46:49 PST Message-ID: <3FCD5DF0.7090309@iprg.nokia.com> Date: Tue, 02 Dec 2003 19:52:16 -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: "T.J. Kniveton" CC: nemo@ietf.org, "James Kempf" Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic spec) References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> <3FCD5847.1010809@kniveton.com> <3FCD5AC2.3060503@iprg.nokia.com> <3FCD5A29.807 In-Reply-To: <3FCD5A29.8070302@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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit T.J. Kniveton wrote: > OK.. can you give me an example of when any MR, ever, would get any > benefit by sending RAs on its egress interface? If not, the text there > should probably point out this fact, or just say..don't send them. not for us to prohibit this, TJ. neighbor discovery specs dont prohibit it. Jim and I had a discussion on this. the discussion is at http://people.nokia.net/vijayd/nemo/issue21.txt. maybe you should pose this question on the IPv6 mailing list. Jim has sent a mail to Hesham to clarify this when RFC 2461 is being revised. it hasnt been discussed on the IPv6 mailing list, though. Vijay From nemo-admin@ietf.org Wed Dec 3 01:28:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05904 for ; Wed, 3 Dec 2003 01:28:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARQUT-0001yl-S3; Wed, 03 Dec 2003 01:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARQTo-0001yR-IU for nemo@optimus.ietf.org; Wed, 03 Dec 2003 01:27: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 BAA05861 for ; Wed, 3 Dec 2003 01:27:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARQTl-0002vH-00 for nemo@ietf.org; Wed, 03 Dec 2003 01:27:17 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1ARQTk-0002ue-00 for nemo@ietf.org; Wed, 03 Dec 2003 01:27:16 -0500 Received: from kniveton.com (wideload.kniveton.com [64.36.73.246]) by multihop.net (8.12.10/8.12.10) with ESMTP id hB36R5r3010697; Tue, 2 Dec 2003 22:27:05 -0800 (PST) (envelope-from tj@kniveton.com) Message-ID: <3FCD823A.7060009@kniveton.com> Date: Tue, 02 Dec 2003 22:27:06 -0800 From: "T.J. Kniveton" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: nemo@ietf.org Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic spec) References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> <3FCD5847.1010809@kniveton.com> <3FCD5AC2.3060503@iprg.nokia.com> In-Reply-To: <3FCD5AC2.3060503@iprg.nokia.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: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > a router by its nature sends out router advertisements. there is > no spec prohibiting it from sending out router advertisements on > any of its interfaces. the NEMO basic spec restricts the mobile > router to not send router advertisements on its egress interface > when it is attached to a visited link. when it returns to a home > link, we are saying it MAY start sending again. My understand about router advertisements is that they are used for routers to advertise their existence on links they serve, and give information about the prefixes they will serve. The MR does not serve any nodes on the egress interface. Therefore it is just like a HOST on that link. The MR should ever, only, advertise itself as a router on a link where it acts as a router -- the mobile network. > > but we have to prevent hosts on the home link from configuring > the mobile router as a default router. so we say the router > lifetime SHOULD be set to 0. Which is equivalent to not sending router advertisements. After all, it's not going to include any prefix options in the RA, is it?? > > > Vijay > From exim@www1.ietf.org Wed Dec 3 01:28:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05922 for ; Wed, 3 Dec 2003 01:28: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 1ARQUY-0001zl-OR for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 01:28:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB36S602007663 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 01:28:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARQUY-0001zW-J8 for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 01:28: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 BAA05889 for ; Wed, 3 Dec 2003 01:27:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARQUV-0002vy-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 01:28:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARQUV-0002vv-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 01:28:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARQUT-0001yl-S3; Wed, 03 Dec 2003 01:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARQTo-0001yR-IU for nemo@optimus.ietf.org; Wed, 03 Dec 2003 01:27: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 BAA05861 for ; Wed, 3 Dec 2003 01:27:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARQTl-0002vH-00 for nemo@ietf.org; Wed, 03 Dec 2003 01:27:17 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1ARQTk-0002ue-00 for nemo@ietf.org; Wed, 03 Dec 2003 01:27:16 -0500 Received: from kniveton.com (wideload.kniveton.com [64.36.73.246]) by multihop.net (8.12.10/8.12.10) with ESMTP id hB36R5r3010697; Tue, 2 Dec 2003 22:27:05 -0800 (PST) (envelope-from tj@kniveton.com) Message-ID: <3FCD823A.7060009@kniveton.com> Date: Tue, 02 Dec 2003 22:27:06 -0800 From: "T.J. Kniveton" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: nemo@ietf.org Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic spec) References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> <3FCD5847.1010809@kniveton.com> <3FCD5AC2.3060503@iprg.nokia.com> In-Reply-To: <3FCD5AC2.3060503@iprg.nokia.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > a router by its nature sends out router advertisements. there is > no spec prohibiting it from sending out router advertisements on > any of its interfaces. the NEMO basic spec restricts the mobile > router to not send router advertisements on its egress interface > when it is attached to a visited link. when it returns to a home > link, we are saying it MAY start sending again. My understand about router advertisements is that they are used for routers to advertise their existence on links they serve, and give information about the prefixes they will serve. The MR does not serve any nodes on the egress interface. Therefore it is just like a HOST on that link. The MR should ever, only, advertise itself as a router on a link where it acts as a router -- the mobile network. > > but we have to prevent hosts on the home link from configuring > the mobile router as a default router. so we say the router > lifetime SHOULD be set to 0. Which is equivalent to not sending router advertisements. After all, it's not going to include any prefix options in the RA, is it?? > > > Vijay > From nemo-admin@ietf.org Wed Dec 3 01:36:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06043 for ; Wed, 3 Dec 2003 01:36: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 1ARQcE-00029v-FU; Wed, 03 Dec 2003 01:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARQbL-000289-Qh for nemo@optimus.ietf.org; Wed, 03 Dec 2003 01:35:08 -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 BAA06015 for ; Wed, 3 Dec 2003 01:34:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARQbI-0002zj-00 for nemo@ietf.org; Wed, 03 Dec 2003 01:35:04 -0500 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1ARQbH-0002zg-00 for nemo@ietf.org; Wed, 03 Dec 2003 01:35:04 -0500 Received: from [82.145.164.5] ([82.145.164.5]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id hB36Yk4v009073; Wed, 3 Dec 2003 15:34:49 +0900 Date: Wed, 03 Dec 2003 15:34:54 +0900 From: Ryuji Wakikawa To: Vijay Devarapalli Subject: Re: [nemo] Closing Issue 16 Cc: nemo@ietf.org, Jari Arkko , "Pascal Thubert (pthubert)" In-Reply-To: <3FCD26C3.2030305@iprg.nokia.com> References: <3FCD26C3.2030305@iprg.nokia.com> Message-Id: <20031203150053.6C8B.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.06.02 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Vijay one comment > hi all, > > this issue was about support MIPv6 Home Agents that do not support > mobile routers. we initially modified DHAAD to return only the list > of home agents that support mobile routers. but Pascal and Jari > argued that the protocol is more robust if the Home Agent echos a > bit in the binding acknowledgement to indicate to the mobile router > that it has setup forwarding for the mobile network. > > so I changed the format of the binding ack to include a new flag. > this flag is set when the Home Agent which processed the binding > update supports mobile routers and the mobile router flag in the > corresponding binding update was set to 1. > > change the binding ack format > > 4.2. Binding Acknowledgement > > A new flag (R) is included in the Binding Acknowledgement to indicate > that the Home Agent which processed the corresponding Binding Update > supports Mobile Routers. The flag is set only if the corresponding > Binding Update had the Mobile Router flag (R) set to 1. The rest of > the Binding Acknowledgement format remains the same as defined in > [1]. > > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status |K|R| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Mobility options . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Mobile Router Flag (R) > > The Mobile Router Flag is set to indicate that the Home Agent > which processed the Binding Update supports Mobile Routers. It > is set to 1 only if the corresponding Binding Update had the > Mobile Router flag set to 1. > > For a description of the other fields in the message, see [1]. > > This document also introduces the following new Binding > Acknowledgement status values. > > 140 Mobile Router Operation not permitted > > 141 Invalid Prefix > > 142 Not Authorized for Prefix > > 143 Forwarding Setup failed > > Status values less than 128 indicate that the Binding Update was > processed successfully by the receiving nodes. Values greater than > 128 indicate that the Binding Update was rejected by the Home Agent. > > > change section 5.3 > > 5.3. Receiving Binding Acknowledgements > > The Mobile Router receives Binding Acknowledgements from the Home > Agent, corresponding to the Binding Updates it sent. If the Binding > Acknowledgement status is set to '0' (Binding Update accepted) and > the Mobile Router flag (R) is set to 1, the Mobile Router assumes > that the Home Agent has successfully processed the Binding Update > and has set up forwarding for the Mobile Network. The Mobile Router > can then start using the bi-directional tunnel for reverse tunneling > traffic from the mobile network. If the Mobile Router flag (R) is > not set, then the Mobile Router concludes that its current Home Agent > does not support Mobile Routers and performs Dynamic Home Agent > Discovery again to discover Home Agents which support Mobile Routers. If lecacy HA replied with successful status code without Rbit, MR should de-register its host binding from the HA. no? Otherwise, it HoA is generated from the home link (MIP mode), DAD will be occured at the home link. regards ryuji > modify section 6.6 to say > > The Home Agent sets the status code in the Binding Acknowledgement > to '0' (Binding Update accepted) in order to indicate to the Mobile > Router that it successfully processed the Binding Update. It also > sets the Mobile Router flag (R) to indicate to the Mobile Router that > it has setup forwarding for the Mobile Network. > > a MIPv6 Home Agent will not set this flag. > > let me know if this looks good. > > Vijay regards, ryuji From nemo-admin@ietf.org Wed Dec 3 01:36:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06058 for ; Wed, 3 Dec 2003 01:36: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 1ARQcF-0002B6-Pk; Wed, 03 Dec 2003 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 1ARQbX-00028O-Na for nemo@optimus.ietf.org; Wed, 03 Dec 2003 01:35: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 BAA06024 for ; Wed, 3 Dec 2003 01:35:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARQbU-000301-00 for nemo@ietf.org; Wed, 03 Dec 2003 01:35:16 -0500 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1ARQbT-0002zt-00 for nemo@ietf.org; Wed, 03 Dec 2003 01:35:15 -0500 Received: from [82.145.164.5] ([82.145.164.5]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id hB36Yk51009073; Wed, 3 Dec 2003 15:35:04 +0900 Date: Wed, 03 Dec 2003 15:35:09 +0900 From: Ryuji Wakikawa To: Vijay Devarapalli Subject: Re: [nemo] Closing Issue 20 Cc: nemo@ietf.org, kempf@docomolabs-usa.com, jari.arkko@kolumbus.fi, pthubert@cisco.com In-Reply-To: <3FCD0207.6010101@iprg.nokia.com> References: <3FCD0207.6010101@iprg.nokia.com> Message-Id: <20031203153412.6C92.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.06.02 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Vijay. Final argument for this topic:-p The difference between prefix opt and prefixlen opt is whether it has field for "prefix" and how to retrieve "prefix" from moboption. We can combine two options into one option and say both prefix and prefixlen is explicit mode. My idea is using flag in reserved field. If t=he flag is on, prefix field is not presented and use both len and HoA to retrieve HoA. Otherwise, HA gets mobile network prefix just from prefix field. +-------+-------+--------+---------+ | type | len |x| | len | +-------+-------+--------+---------+ | prefix (optional) | +-------+-------+--------+---------+ this does not cause so much additional codes. If this is not right way, just drop prefix length. I am OK if MR can retrieve its HoA from its mobile network prefix at least. ryuji > hi all, > > I think there is concensus now to remove the explicit prefix length > mode. whatever one wanted to do with the explicit prefix length mode > should be possible with the explicit network mode. > > this will address (to an extent) the concern that there are now too > many differnt ways of doing the same thing, i.e. the mobile router > asking the Home Agent to setup forwarding for the mobile network. > > Vijay regards, ryuji From exim@www1.ietf.org Wed Dec 3 01:36:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06073 for ; Wed, 3 Dec 2003 01:36:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARQcG-0002CA-5v for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 01:36:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB36a4Z2008432 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 01:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARQcF-0002BN-UV for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 01:36: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 BAA06028 for ; Wed, 3 Dec 2003 01:35:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARQcC-000308-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 01:36:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARQcC-000305-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 01:36:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARQcE-00029v-FU; Wed, 03 Dec 2003 01:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARQbL-000289-Qh for nemo@optimus.ietf.org; Wed, 03 Dec 2003 01:35:08 -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 BAA06015 for ; Wed, 3 Dec 2003 01:34:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARQbI-0002zj-00 for nemo@ietf.org; Wed, 03 Dec 2003 01:35:04 -0500 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1ARQbH-0002zg-00 for nemo@ietf.org; Wed, 03 Dec 2003 01:35:04 -0500 Received: from [82.145.164.5] ([82.145.164.5]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id hB36Yk4v009073; Wed, 3 Dec 2003 15:34:49 +0900 Date: Wed, 03 Dec 2003 15:34:54 +0900 From: Ryuji Wakikawa To: Vijay Devarapalli Subject: Re: [nemo] Closing Issue 16 Cc: nemo@ietf.org, Jari Arkko , "Pascal Thubert (pthubert)" In-Reply-To: <3FCD26C3.2030305@iprg.nokia.com> References: <3FCD26C3.2030305@iprg.nokia.com> Message-Id: <20031203150053.6C8B.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.06.02 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Vijay one comment > hi all, > > this issue was about support MIPv6 Home Agents that do not support > mobile routers. we initially modified DHAAD to return only the list > of home agents that support mobile routers. but Pascal and Jari > argued that the protocol is more robust if the Home Agent echos a > bit in the binding acknowledgement to indicate to the mobile router > that it has setup forwarding for the mobile network. > > so I changed the format of the binding ack to include a new flag. > this flag is set when the Home Agent which processed the binding > update supports mobile routers and the mobile router flag in the > corresponding binding update was set to 1. > > change the binding ack format > > 4.2. Binding Acknowledgement > > A new flag (R) is included in the Binding Acknowledgement to indicate > that the Home Agent which processed the corresponding Binding Update > supports Mobile Routers. The flag is set only if the corresponding > Binding Update had the Mobile Router flag (R) set to 1. The rest of > the Binding Acknowledgement format remains the same as defined in > [1]. > > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status |K|R| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Mobility options . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Mobile Router Flag (R) > > The Mobile Router Flag is set to indicate that the Home Agent > which processed the Binding Update supports Mobile Routers. It > is set to 1 only if the corresponding Binding Update had the > Mobile Router flag set to 1. > > For a description of the other fields in the message, see [1]. > > This document also introduces the following new Binding > Acknowledgement status values. > > 140 Mobile Router Operation not permitted > > 141 Invalid Prefix > > 142 Not Authorized for Prefix > > 143 Forwarding Setup failed > > Status values less than 128 indicate that the Binding Update was > processed successfully by the receiving nodes. Values greater than > 128 indicate that the Binding Update was rejected by the Home Agent. > > > change section 5.3 > > 5.3. Receiving Binding Acknowledgements > > The Mobile Router receives Binding Acknowledgements from the Home > Agent, corresponding to the Binding Updates it sent. If the Binding > Acknowledgement status is set to '0' (Binding Update accepted) and > the Mobile Router flag (R) is set to 1, the Mobile Router assumes > that the Home Agent has successfully processed the Binding Update > and has set up forwarding for the Mobile Network. The Mobile Router > can then start using the bi-directional tunnel for reverse tunneling > traffic from the mobile network. If the Mobile Router flag (R) is > not set, then the Mobile Router concludes that its current Home Agent > does not support Mobile Routers and performs Dynamic Home Agent > Discovery again to discover Home Agents which support Mobile Routers. If lecacy HA replied with successful status code without Rbit, MR should de-register its host binding from the HA. no? Otherwise, it HoA is generated from the home link (MIP mode), DAD will be occured at the home link. regards ryuji > modify section 6.6 to say > > The Home Agent sets the status code in the Binding Acknowledgement > to '0' (Binding Update accepted) in order to indicate to the Mobile > Router that it successfully processed the Binding Update. It also > sets the Mobile Router flag (R) to indicate to the Mobile Router that > it has setup forwarding for the Mobile Network. > > a MIPv6 Home Agent will not set this flag. > > let me know if this looks good. > > Vijay regards, ryuji From exim@www1.ietf.org Wed Dec 3 02:29:46 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06075 for ; Wed, 3 Dec 2003 01:36:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARQcH-0002DA-Dk for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 01:36:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB36a54W008493 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 01:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARQcH-0002Ck-6s for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 01:36: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 BAA06037 for ; Wed, 3 Dec 2003 01:35:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARQcD-00030K-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 01:36:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARQcD-00030F-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 01:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARQcF-0002B6-Pk; Wed, 03 Dec 2003 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 1ARQbX-00028O-Na for nemo@optimus.ietf.org; Wed, 03 Dec 2003 01:35: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 BAA06024 for ; Wed, 3 Dec 2003 01:35:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARQbU-000301-00 for nemo@ietf.org; Wed, 03 Dec 2003 01:35:16 -0500 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1ARQbT-0002zt-00 for nemo@ietf.org; Wed, 03 Dec 2003 01:35:15 -0500 Received: from [82.145.164.5] ([82.145.164.5]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id hB36Yk51009073; Wed, 3 Dec 2003 15:35:04 +0900 Date: Wed, 03 Dec 2003 15:35:09 +0900 From: Ryuji Wakikawa To: Vijay Devarapalli Subject: Re: [nemo] Closing Issue 20 Cc: nemo@ietf.org, kempf@docomolabs-usa.com, jari.arkko@kolumbus.fi, pthubert@cisco.com In-Reply-To: <3FCD0207.6010101@iprg.nokia.com> References: <3FCD0207.6010101@iprg.nokia.com> Message-Id: <20031203153412.6C92.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.06.02 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Vijay. Final argument for this topic:-p The difference between prefix opt and prefixlen opt is whether it has field for "prefix" and how to retrieve "prefix" from moboption. We can combine two options into one option and say both prefix and prefixlen is explicit mode. My idea is using flag in reserved field. If t=he flag is on, prefix field is not presented and use both len and HoA to retrieve HoA. Otherwise, HA gets mobile network prefix just from prefix field. +-------+-------+--------+---------+ | type | len |x| | len | +-------+-------+--------+---------+ | prefix (optional) | +-------+-------+--------+---------+ this does not cause so much additional codes. If this is not right way, just drop prefix length. I am OK if MR can retrieve its HoA from its mobile network prefix at least. ryuji > hi all, > > I think there is concensus now to remove the explicit prefix length > mode. whatever one wanted to do with the explicit prefix length mode > should be possible with the explicit network mode. > > this will address (to an extent) the concern that there are now too > many differnt ways of doing the same thing, i.e. the mobile router > asking the Home Agent to setup forwarding for the mobile network. > > Vijay regards, ryuji From nemo-admin@ietf.org Wed Dec 3 02:55:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04575 for ; Wed, 3 Dec 2003 02:55:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARRqh-0006s6-GA; Wed, 03 Dec 2003 02:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARRqQ-0006re-S5 for nemo@optimus.ietf.org; Wed, 03 Dec 2003 02:54: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 CAA04564 for ; Wed, 3 Dec 2003 02:54:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARRqM-0003n0-00 for nemo@ietf.org; Wed, 03 Dec 2003 02:54:42 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1ARRqM-0003mw-00 for nemo@ietf.org; Wed, 03 Dec 2003 02:54:42 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 9A6076A904; Wed, 3 Dec 2003 09:54:37 +0200 (EET) Message-ID: <3FCD95AE.1070702@kolumbus.fi> Date: Wed, 03 Dec 2003 09:50:06 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: nemo@ietf.org, "Pascal Thubert (pthubert)" Subject: Re: [nemo] Closing Issue 16 References: <3FCD26C3.2030305@iprg.nokia.com> In-Reply-To: <3FCD26C3.2030305@iprg.nokia.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: , Content-Transfer-Encoding: 7bit > let me know if this looks good. It does. Thanks! I agree with Ryuji that you should require a de-register if the home agent turned out to be plain MIPv6 only. --Jari From exim@www1.ietf.org Wed Dec 3 02:55:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04590 for ; Wed, 3 Dec 2003 02:55: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 1ARRqo-0006tN-AY for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 02:55:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB37tAR4026489 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 02:55:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARRqn-0006tA-UN for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 02:55: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 CAA04572 for ; Wed, 3 Dec 2003 02:54:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARRqk-0003nU-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 02:55:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARRqj-0003nR-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 02:55:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARRqh-0006s6-GA; Wed, 03 Dec 2003 02:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARRqQ-0006re-S5 for nemo@optimus.ietf.org; Wed, 03 Dec 2003 02:54: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 CAA04564 for ; Wed, 3 Dec 2003 02:54:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARRqM-0003n0-00 for nemo@ietf.org; Wed, 03 Dec 2003 02:54:42 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1ARRqM-0003mw-00 for nemo@ietf.org; Wed, 03 Dec 2003 02:54:42 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 9A6076A904; Wed, 3 Dec 2003 09:54:37 +0200 (EET) Message-ID: <3FCD95AE.1070702@kolumbus.fi> Date: Wed, 03 Dec 2003 09:50:06 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: nemo@ietf.org, "Pascal Thubert (pthubert)" Subject: Re: [nemo] Closing Issue 16 References: <3FCD26C3.2030305@iprg.nokia.com> In-Reply-To: <3FCD26C3.2030305@iprg.nokia.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > let me know if this looks good. It does. Thanks! I agree with Ryuji that you should require a de-register if the home agent turned out to be plain MIPv6 only. --Jari From nemo-admin@ietf.org Wed Dec 3 03:27:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05772 for ; Wed, 3 Dec 2003 03:27: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 1ARSLd-0008MH-Io; Wed, 03 Dec 2003 03:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSLK-0008Lw-IU for nemo@optimus.ietf.org; Wed, 03 Dec 2003 03:26: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 DAA05749 for ; Wed, 3 Dec 2003 03:26:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARSLI-0004HH-00 for nemo@ietf.org; Wed, 03 Dec 2003 03:26:40 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1ARSLH-0004HE-00 for nemo@ietf.org; Wed, 03 Dec 2003 03:26:39 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id BC4C16A905; Wed, 3 Dec 2003 10:26:40 +0200 (EET) Message-ID: <3FCD9D31.4030802@kolumbus.fi> Date: Wed, 03 Dec 2003 10:22:09 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T.J. Kniveton" Cc: nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko References: <3FCBF3DE.7050202@iprg.nokia.com> <3FCC5A7B.4080509@kolumbus.fi> <3FCCEFF1.7090009@iprg.nokia.com> <3FCD36BF.2070708@kniveton.com> In-Reply-To: <3FCD36BF.2070708@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: , Content-Transfer-Encoding: 7bit T.J. Kniveton wrote: > A table of owned prefixes is only one possible way for the Home Agent to > determine which prefixes an authenticated MR is authorized to use NEMO > with. That's why it's optional. Ah, I see. I don't think that you should require a table. You should require an ability to tell which prefixes are legal for a given MR. Folks can then implement this as a table, an AAA lookup, a database, or whatever they want. > How about the case where an MR is authorized to use the set of prefixes > P1, and it only wants to use a subset of those prefixes, set P2 (c P1). > It does not want the subtraction P1 \ P2 prefixes forwarded. Ok. > Next, consider a case where a bunch of MRs share a pool of prefixes. A > prefix is dynamically assigned to the mobile network as soon as the MR > authenticates to the HA. At that time, the HA picks a prefix and uses > the option to explicitly tell the MR its prefix. Right. And this would be a useful function. But I guess it would have to be written down somewhere? Currently you say your options are only used in the BU. What you suggest above belongs to a new "dynamic MR prefix assignment" spec, probably... --Jari From exim@www1.ietf.org Wed Dec 3 03:27:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05787 for ; Wed, 3 Dec 2003 03:27:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSLj-0008NO-QW for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 03:27:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB38R74p032192 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 03:27:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSLj-0008N9-FH for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 03:27:07 -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 DAA05754 for ; Wed, 3 Dec 2003 03:26:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARSLh-0004HP-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 03:27:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARSLg-0004HM-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 03:27:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSLd-0008MH-Io; Wed, 03 Dec 2003 03:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSLK-0008Lw-IU for nemo@optimus.ietf.org; Wed, 03 Dec 2003 03:26: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 DAA05749 for ; Wed, 3 Dec 2003 03:26:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARSLI-0004HH-00 for nemo@ietf.org; Wed, 03 Dec 2003 03:26:40 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1ARSLH-0004HE-00 for nemo@ietf.org; Wed, 03 Dec 2003 03:26:39 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id BC4C16A905; Wed, 3 Dec 2003 10:26:40 +0200 (EET) Message-ID: <3FCD9D31.4030802@kolumbus.fi> Date: Wed, 03 Dec 2003 10:22:09 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T.J. Kniveton" Cc: nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko References: <3FCBF3DE.7050202@iprg.nokia.com> <3FCC5A7B.4080509@kolumbus.fi> <3FCCEFF1.7090009@iprg.nokia.com> <3FCD36BF.2070708@kniveton.com> In-Reply-To: <3FCD36BF.2070708@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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit T.J. Kniveton wrote: > A table of owned prefixes is only one possible way for the Home Agent to > determine which prefixes an authenticated MR is authorized to use NEMO > with. That's why it's optional. Ah, I see. I don't think that you should require a table. You should require an ability to tell which prefixes are legal for a given MR. Folks can then implement this as a table, an AAA lookup, a database, or whatever they want. > How about the case where an MR is authorized to use the set of prefixes > P1, and it only wants to use a subset of those prefixes, set P2 (c P1). > It does not want the subtraction P1 \ P2 prefixes forwarded. Ok. > Next, consider a case where a bunch of MRs share a pool of prefixes. A > prefix is dynamically assigned to the mobile network as soon as the MR > authenticates to the HA. At that time, the HA picks a prefix and uses > the option to explicitly tell the MR its prefix. Right. And this would be a useful function. But I guess it would have to be written down somewhere? Currently you say your options are only used in the BU. What you suggest above belongs to a new "dynamic MR prefix assignment" spec, probably... --Jari From nemo-admin@ietf.org Wed Dec 3 03:49:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06323 for ; Wed, 3 Dec 2003 03: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 1ARSgv-0000rd-69; Wed, 03 Dec 2003 03: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 1ARSgP-0000qs-Qb for nemo@optimus.ietf.org; Wed, 03 Dec 2003 03:48: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 DAA06311 for ; Wed, 3 Dec 2003 03:48:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARSgN-0004Y6-00 for nemo@ietf.org; Wed, 03 Dec 2003 03:48:27 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARSgM-0004Xp-00 for nemo@ietf.org; Wed, 03 Dec 2003 03:48:26 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Dec 2003 09:45:08 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB38lgM2013026; Wed, 3 Dec 2003 09:47:42 +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); Wed, 3 Dec 2003 08:47:55 +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] Editorial comments from Jari Arkko Date: Wed, 3 Dec 2003 08:47:54 -0000 Message-ID: Thread-Topic: [nemo] Editorial comments from Jari Arkko Thread-Index: AcO5GA9CsAC3DcHWQXOaC0IeTLPY8QAYXrNA From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Jari Arkko" Cc: X-OriginalArrivalTime: 03 Dec 2003 08:47:55.0232 (UTC) FILETIME=[24E01600:01C3B97A] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of = Vijay Devarapalli > Sent: mardi 2 d=E9cembre 2003 22:06 > To: Jari Arkko > Cc: nemo@ietf.org > Subject: Re: [nemo] Editorial comments from Jari Arkko >=20 > Jari Arkko wrote: >=20 > >>> A Mobile Network is a network segment or subnet which can move > >>> and attach to arbitrary points in the Internet. A Mobile = Network > >>> can only be accessed via specific gateways called Mobile = Routers > >>> that manage its movement. Mobile Networks have (always = exactly)| > >>> (at least) one Mobile Router serving them. > >> > >> > >> > >> fine with me. > > > > > > Ok, but you still need to pick either "always exactly" or > > "at least". >=20 > we cannot restrict to one mobile router. so its "at least". >=20 > > > >>> Would it be useful to follow MIPv6 base Section 5.5 guidelines > >>> on the use of source addresses? > >> > >> > >> > >> we already say in the spec (section 5.5), what the source and > >> destination addresses should be for the inner and outer IPv6 > >> headers when sending packets through the bi-directional tunnel. > > > > > > Yes, but you are not requiring that the source addresses be > > checked. This opens a reflection attack via home agents that > > don't get this. >=20 > there is some text in the Security Considerations section. >=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 belong to the Mobile Network Prefix > owned by the Mobile Router. >=20 Note that in the reqs I proposed yesterday, I first thought I would copy = that text and then I realized it was a bit restrictive and I replaced by = topological correctness for the inner packet. What do you think? I = believe this should be changed in the security section as well. Pascal From exim@www1.ietf.org Wed Dec 3 03:49:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06341 for ; Wed, 3 Dec 2003 03:49: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 1ARSh4-0000sd-KZ for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 03:49:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB38nAGj003379 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 03:49:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSh2-0000sQ-6W for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 03:49:08 -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 DAA06315 for ; Wed, 3 Dec 2003 03:48:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARSgz-0004YC-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 03:49:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARSgz-0004Y9-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 03:49:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSgv-0000rd-69; Wed, 03 Dec 2003 03: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 1ARSgP-0000qs-Qb for nemo@optimus.ietf.org; Wed, 03 Dec 2003 03:48: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 DAA06311 for ; Wed, 3 Dec 2003 03:48:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARSgN-0004Y6-00 for nemo@ietf.org; Wed, 03 Dec 2003 03:48:27 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARSgM-0004Xp-00 for nemo@ietf.org; Wed, 03 Dec 2003 03:48:26 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Dec 2003 09:45:08 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB38lgM2013026; Wed, 3 Dec 2003 09:47:42 +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); Wed, 3 Dec 2003 08:47:55 +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] Editorial comments from Jari Arkko Date: Wed, 3 Dec 2003 08:47:54 -0000 Message-ID: Thread-Topic: [nemo] Editorial comments from Jari Arkko Thread-Index: AcO5GA9CsAC3DcHWQXOaC0IeTLPY8QAYXrNA From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Jari Arkko" Cc: X-OriginalArrivalTime: 03 Dec 2003 08:47:55.0232 (UTC) FILETIME=[24E01600:01C3B97A] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of = Vijay Devarapalli > Sent: mardi 2 d=E9cembre 2003 22:06 > To: Jari Arkko > Cc: nemo@ietf.org > Subject: Re: [nemo] Editorial comments from Jari Arkko >=20 > Jari Arkko wrote: >=20 > >>> A Mobile Network is a network segment or subnet which can move > >>> and attach to arbitrary points in the Internet. A Mobile = Network > >>> can only be accessed via specific gateways called Mobile = Routers > >>> that manage its movement. Mobile Networks have (always = exactly)| > >>> (at least) one Mobile Router serving them. > >> > >> > >> > >> fine with me. > > > > > > Ok, but you still need to pick either "always exactly" or > > "at least". >=20 > we cannot restrict to one mobile router. so its "at least". >=20 > > > >>> Would it be useful to follow MIPv6 base Section 5.5 guidelines > >>> on the use of source addresses? > >> > >> > >> > >> we already say in the spec (section 5.5), what the source and > >> destination addresses should be for the inner and outer IPv6 > >> headers when sending packets through the bi-directional tunnel. > > > > > > Yes, but you are not requiring that the source addresses be > > checked. This opens a reflection attack via home agents that > > don't get this. >=20 > there is some text in the Security Considerations section. >=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 belong to the Mobile Network Prefix > owned by the Mobile Router. >=20 Note that in the reqs I proposed yesterday, I first thought I would copy = that text and then I realized it was a bit restrictive and I replaced by = topological correctness for the inner packet. What do you think? I = believe this should be changed in the security section as well. Pascal From nemo-admin@ietf.org Wed Dec 3 03:58:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06704 for ; Wed, 3 Dec 2003 03:58:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSpf-0001Z6-3p; Wed, 03 Dec 2003 03:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSpV-0001XU-EH for nemo@optimus.ietf.org; Wed, 03 Dec 2003 03:57: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 DAA06655 for ; Wed, 3 Dec 2003 03:57:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARSpS-0004gP-00 for nemo@ietf.org; Wed, 03 Dec 2003 03:57:50 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1ARSpR-0004g6-00 for nemo@ietf.org; Wed, 03 Dec 2003 03:57:49 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3DAF46A904; Wed, 3 Dec 2003 10:57:31 +0200 (EET) Message-ID: <3FCDA46C.90404@kolumbus.fi> Date: Wed, 03 Dec 2003 10:53:00 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T.J. Kniveton" Cc: Vijay Devarapalli , nemo@ietf.org Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic spec) References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> <3FCD5847.1010809@kniveton.com> <3FCD5AC2.3060503@iprg.nokia.com> <3FCD823A.7060009@kniveton.com> In-Reply-To: <3FCD823A.7060009@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: , Content-Transfer-Encoding: 7bit I also feel a bit uneasy about sending RAs on the home link. If the dynamic routing protocol case is included in basic support draft, then we do have to allow routing protocols to be run on the home link. But what else? Unfortunately, the ipv6 routers vs. ROUTERs discussion did not go in to too much depth on these issues. Start a new discussion with the specific case of Nemo in mind? Or did you already discuss the RFC 2461 unclarities wrt this in some other thread on the ipv6 list, as someone promised to do in the issue 21 file? --Jari From exim@www1.ietf.org Wed Dec 3 03:58:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06719 for ; Wed, 3 Dec 2003 03:58: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 1ARSpm-0001bK-9q for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 03:58:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB38wAdD006148 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 03:58:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSpl-0001b5-MC for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 03:58: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 DAA06694 for ; Wed, 3 Dec 2003 03:57:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARSpj-0004hY-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 03:58:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARSpi-0004hV-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 03:58:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSpf-0001Z6-3p; Wed, 03 Dec 2003 03:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSpV-0001XU-EH for nemo@optimus.ietf.org; Wed, 03 Dec 2003 03:57: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 DAA06655 for ; Wed, 3 Dec 2003 03:57:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARSpS-0004gP-00 for nemo@ietf.org; Wed, 03 Dec 2003 03:57:50 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1ARSpR-0004g6-00 for nemo@ietf.org; Wed, 03 Dec 2003 03:57:49 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3DAF46A904; Wed, 3 Dec 2003 10:57:31 +0200 (EET) Message-ID: <3FCDA46C.90404@kolumbus.fi> Date: Wed, 03 Dec 2003 10:53:00 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T.J. Kniveton" Cc: Vijay Devarapalli , nemo@ietf.org Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic spec) References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> <3FCD5847.1010809@kniveton.com> <3FCD5AC2.3060503@iprg.nokia.com> <3FCD823A.7060009@kniveton.com> In-Reply-To: <3FCD823A.7060009@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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I also feel a bit uneasy about sending RAs on the home link. If the dynamic routing protocol case is included in basic support draft, then we do have to allow routing protocols to be run on the home link. But what else? Unfortunately, the ipv6 routers vs. ROUTERs discussion did not go in to too much depth on these issues. Start a new discussion with the specific case of Nemo in mind? Or did you already discuss the RFC 2461 unclarities wrt this in some other thread on the ipv6 list, as someone promised to do in the issue 21 file? --Jari From nemo-admin@ietf.org Wed Dec 3 04:54:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07894 for ; Wed, 3 Dec 2003 04:54: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 1ARThp-0003si-IX; Wed, 03 Dec 2003 04: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 1ARThE-0003sC-6t for nemo@optimus.ietf.org; Wed, 03 Dec 2003 04:53: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 EAA07877 for ; Wed, 3 Dec 2003 04:53:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARTh9-0005G5-00 for nemo@ietf.org; Wed, 03 Dec 2003 04:53:19 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARTh9-0005G1-00 for nemo@ietf.org; Wed, 03 Dec 2003 04:53:19 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Dec 2003 10:50:01 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB39qWd4001381; Wed, 3 Dec 2003 10:52:35 +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); Wed, 3 Dec 2003 09:52: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] Re: issue xxx: requirements chapter for Nemo. Date: Wed, 3 Dec 2003 09:52:46 -0000 Message-ID: Thread-Topic: [nemo] Re: issue xxx: requirements chapter for Nemo. Thread-Index: AcO5Ok5BpCcs1Ci8Q1WesHummXsL4AARlKpg From: "Pascal Thubert (pthubert)" To: "T.J. Kniveton" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 03 Dec 2003 09:52:47.0023 (UTC) FILETIME=[349043F0:01C3B983] 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 My text looks ugly, I must agree on that. It's more like an initial dump = to be filtered out. =20 The key is that basic nemo has dependencies, and at the moment they are = implicit, thus Jari's comment on the deps on MIPv6. On top of MIPv6, we = have dependencies on several RFCs like IPv6 spec, nd, autoconf, dhcpv6, = tunnels. Most MUST be fully implemented, but it's not the case of MIPv6. = I agree with Jari that there's a need to say so. Maybe it takes much = less text then I actually used. Something like: Dependencies: ------------- Basic Nemo MRs MUST implement this specification, [MIPv6] chapter 8.1 = and 8.3, and RFCs 2460, 2461, 2462, 2463 and 2473. Basic Nemo MRs MAY implement [MIPv6] chapter 8.2 and 8.5, and RFC 3041. Basic Nemo HAs MUST fully implement this specification, [MIPv6] chapter = 8.1, 8.3 and 8.4, and RFCs 2460, 2461, 2462, 2463 and 2473. > -----Original Message----- > From: T.J. Kniveton [mailto:tj@kniveton.com] > Sent: mercredi 3 d=E9cembre 2003 02:10 > To: Pascal Thubert (pthubert) > Cc: nemo@ietf.org > Subject: Re: [nemo] Re: issue xxx: requirements chapter for Nemo. >=20 > Question: Is there a specific complaint, or reason why the current = spec > does not adequately spell out the requirements of nodes to operate = with > NEMO? It seems like it's not too hard to see or figure out. I'd like = to > avoid making the draft longer than necessary.. best to keep it simpler > if adequate. >=20 > tj From exim@www1.ietf.org Wed Dec 3 04:54:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07909 for ; Wed, 3 Dec 2003 04:54: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 1ARThz-0003tj-LD for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 04:54:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB39sBAe014981 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 04:54:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARThx-0003tY-Mp for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 04:54: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 EAA07886 for ; Wed, 3 Dec 2003 04:53:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARThu-0005GR-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 04:54:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARThu-0005GO-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 04:54:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARThp-0003si-IX; Wed, 03 Dec 2003 04: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 1ARThE-0003sC-6t for nemo@optimus.ietf.org; Wed, 03 Dec 2003 04:53: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 EAA07877 for ; Wed, 3 Dec 2003 04:53:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARTh9-0005G5-00 for nemo@ietf.org; Wed, 03 Dec 2003 04:53:19 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARTh9-0005G1-00 for nemo@ietf.org; Wed, 03 Dec 2003 04:53:19 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Dec 2003 10:50:01 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB39qWd4001381; Wed, 3 Dec 2003 10:52:35 +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); Wed, 3 Dec 2003 09:52: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] Re: issue xxx: requirements chapter for Nemo. Date: Wed, 3 Dec 2003 09:52:46 -0000 Message-ID: Thread-Topic: [nemo] Re: issue xxx: requirements chapter for Nemo. Thread-Index: AcO5Ok5BpCcs1Ci8Q1WesHummXsL4AARlKpg From: "Pascal Thubert (pthubert)" To: "T.J. Kniveton" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 03 Dec 2003 09:52:47.0023 (UTC) FILETIME=[349043F0:01C3B983] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable My text looks ugly, I must agree on that. It's more like an initial dump = to be filtered out. =20 The key is that basic nemo has dependencies, and at the moment they are = implicit, thus Jari's comment on the deps on MIPv6. On top of MIPv6, we = have dependencies on several RFCs like IPv6 spec, nd, autoconf, dhcpv6, = tunnels. Most MUST be fully implemented, but it's not the case of MIPv6. = I agree with Jari that there's a need to say so. Maybe it takes much = less text then I actually used. Something like: Dependencies: ------------- Basic Nemo MRs MUST implement this specification, [MIPv6] chapter 8.1 = and 8.3, and RFCs 2460, 2461, 2462, 2463 and 2473. Basic Nemo MRs MAY implement [MIPv6] chapter 8.2 and 8.5, and RFC 3041. Basic Nemo HAs MUST fully implement this specification, [MIPv6] chapter = 8.1, 8.3 and 8.4, and RFCs 2460, 2461, 2462, 2463 and 2473. > -----Original Message----- > From: T.J. Kniveton [mailto:tj@kniveton.com] > Sent: mercredi 3 d=E9cembre 2003 02:10 > To: Pascal Thubert (pthubert) > Cc: nemo@ietf.org > Subject: Re: [nemo] Re: issue xxx: requirements chapter for Nemo. >=20 > Question: Is there a specific complaint, or reason why the current = spec > does not adequately spell out the requirements of nodes to operate = with > NEMO? It seems like it's not too hard to see or figure out. I'd like = to > avoid making the draft longer than necessary.. best to keep it simpler > if adequate. >=20 > tj From nemo-admin@ietf.org Wed Dec 3 05:20:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08423 for ; Wed, 3 Dec 2003 05:20:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARU71-0004jZ-P5; Wed, 03 Dec 2003 05:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARU6K-0004id-TX for nemo@optimus.ietf.org; Wed, 03 Dec 2003 05:19:21 -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 FAA08393 for ; Wed, 3 Dec 2003 05:19:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARU6H-0005XP-00 for nemo@ietf.org; Wed, 03 Dec 2003 05:19:17 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARU6G-0005Wx-00 for nemo@ietf.org; Wed, 03 Dec 2003 05:19:17 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Dec 2003 11:16:00 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB3AIXM6009449; Wed, 3 Dec 2003 11:18:34 +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); Wed, 3 Dec 2003 10:18:46 +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] Editorial comments from Jari Arkko Date: Wed, 3 Dec 2003 10:18:46 -0000 Message-ID: Thread-Topic: [nemo] Editorial comments from Jari Arkko Thread-Index: AcO5JnmJe5Vckzb2QKe8jGpaDRV8/wAXFVBQ From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: "Jari Arkko" , X-OriginalArrivalTime: 03 Dec 2003 10:18:46.0830 (UTC) FILETIME=[D647ECE0:01C3B986] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mardi 2 d=E9cembre 2003 23:53 > To: Pascal Thubert (pthubert) > Cc: Jari Arkko; nemo@ietf.org > Subject: Re: [nemo] Editorial comments from Jari Arkko >=20 > Pascal Thubert (pthubert) wrote: >=20 > > The routing protocol thing could be considered out of scope. Once = the > > MRHA tunnel is established, any manual tunnel can be used to carry = IPv4, > > multicast, or an IGP back home. Do we have to explicitly say all = this? > > Maybe we could move it to "usages"? >=20 > Pascal, >=20 > the usages document is not the answer to everything. you are > suggesting using the usages document for everything that is > thrown out of the basic spec. :) >=20 > you have to keep in midn that it is targeted at informational. >=20 Yes, actually that's the whole point ... > infact as you say, running a routing protocol over the > bi-directional tunnel is not very different from say running > DHCP prefix delegation over the tunnel. it is just some > traffic. but in this case, traffic which affects routing > tables on the Home Agent and the mobile router. we need to > say how it interacts with sending routing information through > the binding updates. so, I think it should stay in the basic > spec. >=20 My point is that there not a line of code or a bit in the protocol that = is affected by IGPs over the MRHA tunnel. Thus that much is = informational. It may contain deployment recommendation and caution and = I'm happy that the text exists. But the people interested are not the = implementers, it's aimed at the deployers. This is why I proposed the = usage draft as a repository. As of the part of the text that discusses the MR running and IGP only if = at home, yes I agree this much is important in basic. Maybe the right = place for that text would be close to 5.6, since that's the place where = we say that when not at home, the MR acts as a host on the egress link.=20 Note that the MR MAY run an IGP when at home. It does not do so in the = case of aggregated Home network or in the case of static routes. So the = text COULD be revisited a little bit ;) Pascal From exim@www1.ietf.org Wed Dec 3 05:20:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08442 for ; Wed, 3 Dec 2003 05:20: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 1ARU7G-0004la-C9 for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 05:20:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3AKGFT018321 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 05:20:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARU7D-0004lJ-P6 for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 05:20: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 FAA08402 for ; Wed, 3 Dec 2003 05:19:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARU7A-0005Xc-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 05:20:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARU79-0005XY-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 05:20:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARU71-0004jZ-P5; Wed, 03 Dec 2003 05:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARU6K-0004id-TX for nemo@optimus.ietf.org; Wed, 03 Dec 2003 05:19:21 -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 FAA08393 for ; Wed, 3 Dec 2003 05:19:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARU6H-0005XP-00 for nemo@ietf.org; Wed, 03 Dec 2003 05:19:17 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARU6G-0005Wx-00 for nemo@ietf.org; Wed, 03 Dec 2003 05:19:17 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Dec 2003 11:16:00 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB3AIXM6009449; Wed, 3 Dec 2003 11:18:34 +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); Wed, 3 Dec 2003 10:18:46 +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] Editorial comments from Jari Arkko Date: Wed, 3 Dec 2003 10:18:46 -0000 Message-ID: Thread-Topic: [nemo] Editorial comments from Jari Arkko Thread-Index: AcO5JnmJe5Vckzb2QKe8jGpaDRV8/wAXFVBQ From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: "Jari Arkko" , X-OriginalArrivalTime: 03 Dec 2003 10:18:46.0830 (UTC) FILETIME=[D647ECE0:01C3B986] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mardi 2 d=E9cembre 2003 23:53 > To: Pascal Thubert (pthubert) > Cc: Jari Arkko; nemo@ietf.org > Subject: Re: [nemo] Editorial comments from Jari Arkko >=20 > Pascal Thubert (pthubert) wrote: >=20 > > The routing protocol thing could be considered out of scope. Once = the > > MRHA tunnel is established, any manual tunnel can be used to carry = IPv4, > > multicast, or an IGP back home. Do we have to explicitly say all = this? > > Maybe we could move it to "usages"? >=20 > Pascal, >=20 > the usages document is not the answer to everything. you are > suggesting using the usages document for everything that is > thrown out of the basic spec. :) >=20 > you have to keep in midn that it is targeted at informational. >=20 Yes, actually that's the whole point ... > infact as you say, running a routing protocol over the > bi-directional tunnel is not very different from say running > DHCP prefix delegation over the tunnel. it is just some > traffic. but in this case, traffic which affects routing > tables on the Home Agent and the mobile router. we need to > say how it interacts with sending routing information through > the binding updates. so, I think it should stay in the basic > spec. >=20 My point is that there not a line of code or a bit in the protocol that = is affected by IGPs over the MRHA tunnel. Thus that much is = informational. It may contain deployment recommendation and caution and = I'm happy that the text exists. But the people interested are not the = implementers, it's aimed at the deployers. This is why I proposed the = usage draft as a repository. As of the part of the text that discusses the MR running and IGP only if = at home, yes I agree this much is important in basic. Maybe the right = place for that text would be close to 5.6, since that's the place where = we say that when not at home, the MR acts as a host on the egress link.=20 Note that the MR MAY run an IGP when at home. It does not do so in the = case of aggregated Home network or in the case of static routes. So the = text COULD be revisited a little bit ;) Pascal From nemo-admin@ietf.org Wed Dec 3 06:01:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09271 for ; Wed, 3 Dec 2003 06:01: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 1ARUkf-0005qz-K0; Wed, 03 Dec 2003 06:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARUji-0005pO-Ph for nemo@optimus.ietf.org; Wed, 03 Dec 2003 06:00: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 FAA09226 for ; Wed, 3 Dec 2003 05:59:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARUje-0005tH-00 for nemo@ietf.org; Wed, 03 Dec 2003 05:59:59 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARUje-0005sb-00 for nemo@ietf.org; Wed, 03 Dec 2003 05:59:58 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Dec 2003 11:56:41 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB3AxFgi021739; Wed, 3 Dec 2003 11:59:15 +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); Wed, 3 Dec 2003 10:59:28 +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] Closing Issue 16 Date: Wed, 3 Dec 2003 10:59:27 -0000 Message-ID: Thread-Topic: [nemo] Closing Issue 16 Thread-Index: AcO5crqjieqD6JJ/TlyWeHZBV7XXTQAF2KRw From: "Pascal Thubert (pthubert)" To: "Jari Arkko" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 03 Dec 2003 10:59:28.0298 (UTC) FILETIME=[858260A0:01C3B98C] 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 Vijay: Fine with me too :) It's a pain that the bit in the ack is not the same = as the bit in the req but it's already true for the K bit, so... I've also reviewed your text in pre_02 for the change in DHAAD, in the = light of Jari's comment that the capabilities should be a response thing = and not a req thing, which I do agree on. Say we add more and more features like basic nemo and now HAs support a = number of those features. The request may end up like an SQL query = depending on what the requester wants or is willing to accept if the = most wanted is not available. Wouldn't it be better to list everything = and let the requester sort it out based on its own preference? On the other hand, there are formatting issues and the list of HAs as = presented here is very practical. But if you look at prefix options in = RAs, they already have additional info associated with them. Pascal > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: mercredi 3 d=E9cembre 2003 08:50 > To: Vijay Devarapalli > Cc: nemo@ietf.org; Pascal Thubert (pthubert) > Subject: Re: [nemo] Closing Issue 16 >=20 >=20 > > let me know if this looks good. >=20 > It does. Thanks! I agree with Ryuji that you should > require a de-register if the home agent turned out to > be plain MIPv6 only. >=20 > --Jari From exim@www1.ietf.org Wed Dec 3 06:01:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09286 for ; Wed, 3 Dec 2003 06:01: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 1ARUkr-0005tV-0n for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 06:01:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3B1CQf022654 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 06:01:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARUkq-0005tJ-Q8 for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 06:01: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 GAA09258 for ; Wed, 3 Dec 2003 06:00:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARUkn-0005tf-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 06:01:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARUkm-0005tc-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 06:01:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARUkf-0005qz-K0; Wed, 03 Dec 2003 06:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARUji-0005pO-Ph for nemo@optimus.ietf.org; Wed, 03 Dec 2003 06:00: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 FAA09226 for ; Wed, 3 Dec 2003 05:59:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARUje-0005tH-00 for nemo@ietf.org; Wed, 03 Dec 2003 05:59:59 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARUje-0005sb-00 for nemo@ietf.org; Wed, 03 Dec 2003 05:59:58 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Dec 2003 11:56:41 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB3AxFgi021739; Wed, 3 Dec 2003 11:59:15 +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); Wed, 3 Dec 2003 10:59:28 +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] Closing Issue 16 Date: Wed, 3 Dec 2003 10:59:27 -0000 Message-ID: Thread-Topic: [nemo] Closing Issue 16 Thread-Index: AcO5crqjieqD6JJ/TlyWeHZBV7XXTQAF2KRw From: "Pascal Thubert (pthubert)" To: "Jari Arkko" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 03 Dec 2003 10:59:28.0298 (UTC) FILETIME=[858260A0:01C3B98C] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Vijay: Fine with me too :) It's a pain that the bit in the ack is not the same = as the bit in the req but it's already true for the K bit, so... I've also reviewed your text in pre_02 for the change in DHAAD, in the = light of Jari's comment that the capabilities should be a response thing = and not a req thing, which I do agree on. Say we add more and more features like basic nemo and now HAs support a = number of those features. The request may end up like an SQL query = depending on what the requester wants or is willing to accept if the = most wanted is not available. Wouldn't it be better to list everything = and let the requester sort it out based on its own preference? On the other hand, there are formatting issues and the list of HAs as = presented here is very practical. But if you look at prefix options in = RAs, they already have additional info associated with them. Pascal > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: mercredi 3 d=E9cembre 2003 08:50 > To: Vijay Devarapalli > Cc: nemo@ietf.org; Pascal Thubert (pthubert) > Subject: Re: [nemo] Closing Issue 16 >=20 >=20 > > let me know if this looks good. >=20 > It does. Thanks! I agree with Ryuji that you should > require a de-register if the home agent turned out to > be plain MIPv6 only. >=20 > --Jari From nemo-admin@ietf.org Wed Dec 3 06:31:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09785 for ; Wed, 3 Dec 2003 06:31: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 1ARVDg-0006bd-R3; Wed, 03 Dec 2003 06:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVDQ-0006b6-8V for nemo@optimus.ietf.org; Wed, 03 Dec 2003 06:30: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 GAA09758 for ; Wed, 3 Dec 2003 06:30:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVDM-00068m-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:30:40 -0500 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1ARVDL-00068j-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:30:39 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate.mot.com (Motorola/Motgate) with ESMTP id hB3BUegd009863; Wed, 3 Dec 2003 04:30:40 -0700 (MST) Received: from motorola.com ([163.14.20.28]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id hB3BUUQU012571; Wed, 3 Dec 2003 05:30:31 -0600 Message-ID: <3FCDC957.5010703@motorola.com> Date: Wed, 03 Dec 2003 12:30:31 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: "T.J. Kniveton" , Vijay Devarapalli , nemo@ietf.org Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic spec) References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> <3FCD5847.1010809@kniveton.com> <3FCD5AC2.3060503@iprg.nokia.com> <3FCD823A.7060009@kniveton.com> <3FCDA46C.90404@kolumbus.fi> In-Reply-To: <3FCDA46C.90404@kolumbus.fi> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jari Arkko wrote: > I also feel a bit uneasy about sending RAs on the home link. I feel at ease with MR's sending RA's on the home link, it's just like a router like others. Its neighbour routers will be able to lots of additional things if they know MR is there like a normal fixed router. I think TJ didn't feel at ease about MR sending RA's on the egress interface, while on the visited link (not on the home link). > If the dynamic routing protocol case is included in basic support > draft, then we do have to allow routing protocols to be run on the > home link. Routing protocols interactions between routers on the home link don't involve RA's. > But what else? On the home link, neighbour routers might use the MR's RA's to log presence purposes; additionally, if on the home link FR is shutdown for whatever reason then MR sending RA's helps an FH on the home link to be able to talk to an LFN inside the moving network. If MR on the home link does not send RA's, then this communication is impossible. (FR - fixed router, FH - fixed host). MTU also, if the FR is down, then MR might provide that MTU. And all the other parameters also, except the one saying MR is a default router. I think this is reason enough to have MR MAY send RA's on the home link. Similarly, on the visited link, if MR is not allowed to send RA's on the egress interface, then, if AR is down, an an MH on that wireless link (between MR and AR) will not be able to form a CoA and talk to an LFN inside the moving network (by using source address selection). It is of course of much concern to allow MR to send RA's on the egress interface on the wireless interface, because the avertised prefix is a prefix valid in the home link (not in the visited domain). But normally RA's are not propagated by routers, so it should be less of a concern. So I strongly believe MR MAY send RA's on the visited link too (maybe a little bit less MAY than the MAY for the home link). > Unfortunately, the ipv6 routers vs. ROUTERs discussion did not go in > to too much depth on these issues. I doubt the relevance here, but it's a good discussion. Alex From exim@www1.ietf.org Wed Dec 3 06:31:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09800 for ; Wed, 3 Dec 2003 06:31:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVDm-0006dH-Te for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 06:31:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3BV6lj025489 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 06:31:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVDm-0006d2-Nw for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 06:31: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 GAA09767 for ; Wed, 3 Dec 2003 06:30:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVDi-00068y-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 06:31:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARVDi-00068v-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 06:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVDg-0006bd-R3; Wed, 03 Dec 2003 06:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVDQ-0006b6-8V for nemo@optimus.ietf.org; Wed, 03 Dec 2003 06:30: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 GAA09758 for ; Wed, 3 Dec 2003 06:30:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVDM-00068m-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:30:40 -0500 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1ARVDL-00068j-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:30:39 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate.mot.com (Motorola/Motgate) with ESMTP id hB3BUegd009863; Wed, 3 Dec 2003 04:30:40 -0700 (MST) Received: from motorola.com ([163.14.20.28]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id hB3BUUQU012571; Wed, 3 Dec 2003 05:30:31 -0600 Message-ID: <3FCDC957.5010703@motorola.com> Date: Wed, 03 Dec 2003 12:30:31 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: "T.J. Kniveton" , Vijay Devarapalli , nemo@ietf.org Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic spec) References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> <3FCD5847.1010809@kniveton.com> <3FCD5AC2.3060503@iprg.nokia.com> <3FCD823A.7060009@kniveton.com> <3FCDA46C.90404@kolumbus.fi> In-Reply-To: <3FCDA46C.90404@kolumbus.fi> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jari Arkko wrote: > I also feel a bit uneasy about sending RAs on the home link. I feel at ease with MR's sending RA's on the home link, it's just like a router like others. Its neighbour routers will be able to lots of additional things if they know MR is there like a normal fixed router. I think TJ didn't feel at ease about MR sending RA's on the egress interface, while on the visited link (not on the home link). > If the dynamic routing protocol case is included in basic support > draft, then we do have to allow routing protocols to be run on the > home link. Routing protocols interactions between routers on the home link don't involve RA's. > But what else? On the home link, neighbour routers might use the MR's RA's to log presence purposes; additionally, if on the home link FR is shutdown for whatever reason then MR sending RA's helps an FH on the home link to be able to talk to an LFN inside the moving network. If MR on the home link does not send RA's, then this communication is impossible. (FR - fixed router, FH - fixed host). MTU also, if the FR is down, then MR might provide that MTU. And all the other parameters also, except the one saying MR is a default router. I think this is reason enough to have MR MAY send RA's on the home link. Similarly, on the visited link, if MR is not allowed to send RA's on the egress interface, then, if AR is down, an an MH on that wireless link (between MR and AR) will not be able to form a CoA and talk to an LFN inside the moving network (by using source address selection). It is of course of much concern to allow MR to send RA's on the egress interface on the wireless interface, because the avertised prefix is a prefix valid in the home link (not in the visited domain). But normally RA's are not propagated by routers, so it should be less of a concern. So I strongly believe MR MAY send RA's on the visited link too (maybe a little bit less MAY than the MAY for the home link). > Unfortunately, the ipv6 routers vs. ROUTERs discussion did not go in > to too much depth on these issues. I doubt the relevance here, but it's a good discussion. Alex From nemo-admin@ietf.org Wed Dec 3 06:46:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10168 for ; Wed, 3 Dec 2003 06:46: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 1ARVSE-0007A1-Ei; Wed, 03 Dec 2003 06: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 1ARVRd-00078z-Nr for nemo@optimus.ietf.org; Wed, 03 Dec 2003 06:45: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 GAA10116 for ; Wed, 3 Dec 2003 06:45:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVRZ-0006GN-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:45:21 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1ARVRZ-0006GK-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:45:21 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by manatick with esmtp (Exim 4.24) id 1ARVRc-0003XT-BW for nemo@ietf.org; Wed, 03 Dec 2003 06:45:24 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id hB3BeJZC014511; Wed, 3 Dec 2003 04:40:19 -0700 (MST) Received: from motorola.com ([163.14.20.28]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id hB3BdvQU019930; Wed, 3 Dec 2003 05:40:05 -0600 Message-ID: <3FCDCB89.3020608@motorola.com> Date: Wed, 03 Dec 2003 12:39:53 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T.J. Kniveton" CC: Vijay Devarapalli , nemo@ietf.org References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> <3FCD5847.1010809@kniveton.com> <3FCD5AC2.3060503@iprg.nokia.com> <3FCD823A.7060009@kniveton.com> In-Reply-To: <3FCD823A.7060009@kniveton.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: MR MAY send RA's on egress? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 T.J. Kniveton wrote: > The MR does not serve any nodes on the egress interface. Therefore it > is just like a HOST on that link. The MR should ever, only, > advertise itself as a router on a link where it acts as a router -- > the mobile network. Could MR act as a router on the visited link too? For example, MR goes visit an AR over a wireless link. An MH goes visit that wireless link too. Now AR is shutdown for whatever reason. At this point, if MR does _not_ send RA's on its egress interface, then MH is not at all capable of talking to LFN inside MR. If MR _does_ send RA on its egress interface, then MH receives it and forms an address, and uses source address selection, and can talk to LFN (MH does not go through its HA). The RA used by MR sent on the visited link has a prefix topologically correct on the home link (not under the AR). Only the AR advertises itself as a default router, but the MR not. So, if MR could act as a router on the visited link too, then MR might send some RA's. Alex From exim@www1.ietf.org Wed Dec 3 06:46:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10183 for ; Wed, 3 Dec 2003 06:46: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 1ARVSI-0007CL-6P for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 06:46:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Bk6kO027666 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 06:46:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVSH-0007C9-Vo for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 06:46: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 GAA10151 for ; Wed, 3 Dec 2003 06:45:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVSD-0006Hd-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 06:46:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARVSD-0006HX-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 06:46:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVSE-0007A1-Ei; Wed, 03 Dec 2003 06: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 1ARVRd-00078z-Nr for nemo@optimus.ietf.org; Wed, 03 Dec 2003 06:45: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 GAA10116 for ; Wed, 3 Dec 2003 06:45:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVRZ-0006GN-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:45:21 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1ARVRZ-0006GK-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:45:21 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by manatick with esmtp (Exim 4.24) id 1ARVRc-0003XT-BW for nemo@ietf.org; Wed, 03 Dec 2003 06:45:24 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id hB3BeJZC014511; Wed, 3 Dec 2003 04:40:19 -0700 (MST) Received: from motorola.com ([163.14.20.28]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id hB3BdvQU019930; Wed, 3 Dec 2003 05:40:05 -0600 Message-ID: <3FCDCB89.3020608@motorola.com> Date: Wed, 03 Dec 2003 12:39:53 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T.J. Kniveton" CC: Vijay Devarapalli , nemo@ietf.org References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> <3FCD5847.1010809@kniveton.com> <3FCD5AC2.3060503@iprg.nokia.com> <3FCD823A.7060009@kniveton.com> In-Reply-To: <3FCD823A.7060009@kniveton.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: MR MAY send RA's on egress? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit T.J. Kniveton wrote: > The MR does not serve any nodes on the egress interface. Therefore it > is just like a HOST on that link. The MR should ever, only, > advertise itself as a router on a link where it acts as a router -- > the mobile network. Could MR act as a router on the visited link too? For example, MR goes visit an AR over a wireless link. An MH goes visit that wireless link too. Now AR is shutdown for whatever reason. At this point, if MR does _not_ send RA's on its egress interface, then MH is not at all capable of talking to LFN inside MR. If MR _does_ send RA on its egress interface, then MH receives it and forms an address, and uses source address selection, and can talk to LFN (MH does not go through its HA). The RA used by MR sent on the visited link has a prefix topologically correct on the home link (not under the AR). Only the AR advertises itself as a default router, but the MR not. So, if MR could act as a router on the visited link too, then MR might send some RA's. Alex From nemo-admin@ietf.org Wed Dec 3 06:47:14 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10288 for ; Wed, 3 Dec 2003 06:47: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 1ARVTB-0007Mn-JG; Wed, 03 Dec 2003 06:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVSt-0007Ie-E8 for nemo@optimus.ietf.org; Wed, 03 Dec 2003 06:46: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 GAA10207 for ; Wed, 3 Dec 2003 06:46:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVSp-0006Jh-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:46:39 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARVSo-0006Hn-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:46:38 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Dec 2003 12:43:21 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB3Bjco3005649; Wed, 3 Dec 2003 12:45:49 +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, 3 Dec 2003 11:45:59 +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: MR returning home (was Re: [nemo] review of the nemo basic spec) Date: Wed, 3 Dec 2003 11:45:58 -0000 Message-ID: Thread-Topic: MR returning home (was Re: [nemo] review of the nemo basic spec) Thread-Index: AcO5TbS0/318+uZuTuOZ75FTXFsp6AAPyT0A From: "Pascal Thubert (pthubert)" To: "T.J. Kniveton" , "Vijay Devarapalli" , "Soliman Hesham" Cc: X-OriginalArrivalTime: 03 Dec 2003 11:45:59.0786 (UTC) FILETIME=[055DA4A0:01C3B993] 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 TJ:=20 With current ND, in order to advertise a prefix, you have to send an RA. = Why would we want to do that? If you consider the aggregated mode, the prefix on the Home link is the = aggregation of all MNPs (say that it is a /48 while MNPs are /64, for = the sake of the discussion). When a MR comes Home using the egress = interface, it has to setup some bridging between the egress and the = ingress.=20 Alternatively, it could act as a proxy, and as opposed to answering = every NS one by one for all MNNs, it would be nice to advertise that = this MR LL2 matches the full MNP on the home link. Which can be done by = sending an RA with the MNPs as not onlink, no auto. I'm not sure how = nodes on the home link would react to that but if it's unclear we can = raise an issue since RFCs 2461/2 are being updated. I'd expect nodes to = create a route to the prefix that depends on the REACHability of the MR = on the home link, or something. There's one thing we do not have today (like I said I already mentioned = this in the v6 WG), which is the capability to advertise a Network in or = behind a Node. I call the option NINO for Network In Node Option, and I = call NINA a NA with such an option.=20 This would allow addressing devices inside a (virtual) PC, this would = allow addressing devices inside a car or whatever such for of stub, this = would allow a MR to present itself on the egress interface, whether at = home or not. And this would help proxying subnets in general. Nino could benefit from Dave Thaler's draft = http://www.ietf.org/internet-drafts/draft-thaler-ipv6-ndproxy-01.txt and = in particular it should have a minimum set of metrics and info like MTU. I believe there's value for Nemo and if someone agrees support would be = appreciated. Pascal > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of = T.J. Kniveton > Sent: mercredi 3 d=E9cembre 2003 04:28 > To: Vijay Devarapalli > Cc: nemo@ietf.org > Subject: Re: MR returning home (was Re: [nemo] review of the nemo = basic spec) >=20 >=20 >=20 > Vijay Devarapalli wrote: >=20 > > > > - The Mobile Router MAY send router advertisements on its = egress > > interfaces. But the router lifetime SHOULD be set to 0, so = that > > hosts on the home link do not pick the Mobile Router as the > > default router. >=20 > I'm missing something.. Why would the MR put out RAs on the egress > interface? I can see why it would put them out on the ingress = interface, > and use a routing protocol on the egress interface to advertise the > mobile network.. but what would the RA contain? >=20 > tj >=20 From exim@www1.ietf.org Wed Dec 3 06:47:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10306 for ; Wed, 3 Dec 2003 06:47: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 1ARVTD-0007PW-Pr for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 06:47:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Bl3PX028476 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 06:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVTC-0007P8-SR for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 06:47: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 GAA10233 for ; Wed, 3 Dec 2003 06:46:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVT8-0006K4-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 06:46:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARVT8-0006K1-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 06:46:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVTB-0007Mn-JG; Wed, 03 Dec 2003 06:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVSt-0007Ie-E8 for nemo@optimus.ietf.org; Wed, 03 Dec 2003 06:46: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 GAA10207 for ; Wed, 3 Dec 2003 06:46:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVSp-0006Jh-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:46:39 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARVSo-0006Hn-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:46:38 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Dec 2003 12:43:21 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB3Bjco3005649; Wed, 3 Dec 2003 12:45:49 +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, 3 Dec 2003 11:45:59 +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: MR returning home (was Re: [nemo] review of the nemo basic spec) Date: Wed, 3 Dec 2003 11:45:58 -0000 Message-ID: Thread-Topic: MR returning home (was Re: [nemo] review of the nemo basic spec) Thread-Index: AcO5TbS0/318+uZuTuOZ75FTXFsp6AAPyT0A From: "Pascal Thubert (pthubert)" To: "T.J. Kniveton" , "Vijay Devarapalli" , "Soliman Hesham" Cc: X-OriginalArrivalTime: 03 Dec 2003 11:45:59.0786 (UTC) FILETIME=[055DA4A0:01C3B993] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable TJ:=20 With current ND, in order to advertise a prefix, you have to send an RA. = Why would we want to do that? If you consider the aggregated mode, the prefix on the Home link is the = aggregation of all MNPs (say that it is a /48 while MNPs are /64, for = the sake of the discussion). When a MR comes Home using the egress = interface, it has to setup some bridging between the egress and the = ingress.=20 Alternatively, it could act as a proxy, and as opposed to answering = every NS one by one for all MNNs, it would be nice to advertise that = this MR LL2 matches the full MNP on the home link. Which can be done by = sending an RA with the MNPs as not onlink, no auto. I'm not sure how = nodes on the home link would react to that but if it's unclear we can = raise an issue since RFCs 2461/2 are being updated. I'd expect nodes to = create a route to the prefix that depends on the REACHability of the MR = on the home link, or something. There's one thing we do not have today (like I said I already mentioned = this in the v6 WG), which is the capability to advertise a Network in or = behind a Node. I call the option NINO for Network In Node Option, and I = call NINA a NA with such an option.=20 This would allow addressing devices inside a (virtual) PC, this would = allow addressing devices inside a car or whatever such for of stub, this = would allow a MR to present itself on the egress interface, whether at = home or not. And this would help proxying subnets in general. Nino could benefit from Dave Thaler's draft = http://www.ietf.org/internet-drafts/draft-thaler-ipv6-ndproxy-01.txt and = in particular it should have a minimum set of metrics and info like MTU. I believe there's value for Nemo and if someone agrees support would be = appreciated. Pascal > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of = T.J. Kniveton > Sent: mercredi 3 d=E9cembre 2003 04:28 > To: Vijay Devarapalli > Cc: nemo@ietf.org > Subject: Re: MR returning home (was Re: [nemo] review of the nemo = basic spec) >=20 >=20 >=20 > Vijay Devarapalli wrote: >=20 > > > > - The Mobile Router MAY send router advertisements on its = egress > > interfaces. But the router lifetime SHOULD be set to 0, so = that > > hosts on the home link do not pick the Mobile Router as the > > default router. >=20 > I'm missing something.. Why would the MR put out RAs on the egress > interface? I can see why it would put them out on the ingress = interface, > and use a routing protocol on the egress interface to advertise the > mobile network.. but what would the RA contain? >=20 > tj >=20 From nemo-admin@ietf.org Wed Dec 3 06:51:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10668 for ; Wed, 3 Dec 2003 06:51: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 1ARVX4-0007v2-85; Wed, 03 Dec 2003 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 1ARVWZ-0007ts-RU for nemo@optimus.ietf.org; Wed, 03 Dec 2003 06:50: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 GAA10638 for ; Wed, 3 Dec 2003 06:50:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVWV-0006TP-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:50:27 -0500 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 1ARVWK-0006TI-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:50:16 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id hB3Bo46A021715; Wed, 3 Dec 2003 04:50:04 -0700 (MST) Received: from motorola.com ([163.14.20.28]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id hB3Bo5QU027539; Wed, 3 Dec 2003 05:50:07 -0600 Message-ID: <3FCDCDEF.8040704@motorola.com> Date: Wed, 03 Dec 2003 12:50:07 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: Jari Arkko , nemo@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: NINO in a MIMO (was: review of the nemo basic spec) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > This relates to the "ND model for routers" and the "ROUTERS" vs. > "routers" discussions in the v6WG list. I would suggest keep that thread where it started. > The model I'm missing in ND is the "Network in a Node". For a Node > with a prefix inside it or behind it, or more generally a proxy. A > Network in Node Option (Nino) would help. I think there could be some confusion when using NINO in a MIMO device. Alex From exim@www1.ietf.org Wed Dec 3 06:51:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10683 for ; Wed, 3 Dec 2003 06:51: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 1ARVX6-0007yj-0Z for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 06:51:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Bp3OY030610 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 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 1ARVX5-0007xN-EV for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 06:51: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 GAA10656 for ; Wed, 3 Dec 2003 06:50:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVX1-0006Ty-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 06:50:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARVX0-0006Tv-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 06:50:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVX4-0007v2-85; Wed, 03 Dec 2003 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 1ARVWZ-0007ts-RU for nemo@optimus.ietf.org; Wed, 03 Dec 2003 06:50: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 GAA10638 for ; Wed, 3 Dec 2003 06:50:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVWV-0006TP-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:50:27 -0500 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 1ARVWK-0006TI-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:50:16 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id hB3Bo46A021715; Wed, 3 Dec 2003 04:50:04 -0700 (MST) Received: from motorola.com ([163.14.20.28]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id hB3Bo5QU027539; Wed, 3 Dec 2003 05:50:07 -0600 Message-ID: <3FCDCDEF.8040704@motorola.com> Date: Wed, 03 Dec 2003 12:50:07 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: Jari Arkko , nemo@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: NINO in a MIMO (was: review of the nemo basic spec) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > This relates to the "ND model for routers" and the "ROUTERS" vs. > "routers" discussions in the v6WG list. I would suggest keep that thread where it started. > The model I'm missing in ND is the "Network in a Node". For a Node > with a prefix inside it or behind it, or more generally a proxy. A > Network in Node Option (Nino) would help. I think there could be some confusion when using NINO in a MIMO device. Alex From nemo-admin@ietf.org Wed Dec 3 06:54:14 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10815 for ; Wed, 3 Dec 2003 06:54: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 1ARVZx-00083u-HW; Wed, 03 Dec 2003 06: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 1ARVZ6-00082u-Q5 for nemo@optimus.ietf.org; Wed, 03 Dec 2003 06:53:08 -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 GAA10737 for ; Wed, 3 Dec 2003 06:52:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVZ2-0006Ve-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:53:04 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1ARVZ1-0006VX-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:53:04 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id hB3Br1E9021399; Wed, 3 Dec 2003 04:53:01 -0700 (MST) Received: from motorola.com ([163.14.20.28]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id hB3BqqQU029772; Wed, 3 Dec 2003 05:52:53 -0600 Message-ID: <3FCDCE95.10603@motorola.com> Date: Wed, 03 Dec 2003 12:52:53 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] review of the nemo basic spec References: <3FCC7364.90108@kolumbus.fi> In-Reply-To: <3FCC7364.90108@kolumbus.fi> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jari Arkko wrote: >> Are you suggesting to remove chapter 7 and say nothing? > > That would be one alternative yes. I think the draft has too many > options at the moment. (Another alternative would be not have the > static config option, that would also reduce the number of options. > But I see there is some discussion about this already ...) The first alternative sounds reasonable to me. Keep both the implicit and explicit network modes, and enhance the routing protocol section over MRHA in an additional document. Alex From exim@www1.ietf.org Wed Dec 3 06:54:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10830 for ; Wed, 3 Dec 2003 06:54: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 1ARVZz-00085q-31 for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 06:54:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Bs2Zo031099 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 06:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVZy-00085N-Oz for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 06:54: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 GAA10770 for ; Wed, 3 Dec 2003 06:53:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVZu-0006WT-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 06:53:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARVZu-0006WQ-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 06:53:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVZx-00083u-HW; Wed, 03 Dec 2003 06: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 1ARVZ6-00082u-Q5 for nemo@optimus.ietf.org; Wed, 03 Dec 2003 06:53:08 -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 GAA10737 for ; Wed, 3 Dec 2003 06:52:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVZ2-0006Ve-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:53:04 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1ARVZ1-0006VX-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:53:04 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id hB3Br1E9021399; Wed, 3 Dec 2003 04:53:01 -0700 (MST) Received: from motorola.com ([163.14.20.28]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id hB3BqqQU029772; Wed, 3 Dec 2003 05:52:53 -0600 Message-ID: <3FCDCE95.10603@motorola.com> Date: Wed, 03 Dec 2003 12:52:53 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] review of the nemo basic spec References: <3FCC7364.90108@kolumbus.fi> In-Reply-To: <3FCC7364.90108@kolumbus.fi> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jari Arkko wrote: >> Are you suggesting to remove chapter 7 and say nothing? > > That would be one alternative yes. I think the draft has too many > options at the moment. (Another alternative would be not have the > static config option, that would also reduce the number of options. > But I see there is some discussion about this already ...) The first alternative sounds reasonable to me. Keep both the implicit and explicit network modes, and enhance the routing protocol section over MRHA in an additional document. Alex From nemo-admin@ietf.org Wed Dec 3 06:58:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11061 for ; Wed, 3 Dec 2003 06:58: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 1ARVdq-0008Qs-Qp; Wed, 03 Dec 2003 06:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVdZ-0008PH-9T for nemo@optimus.ietf.org; Wed, 03 Dec 2003 06:57: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 GAA11014 for ; Wed, 3 Dec 2003 06:57:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVdU-0006bz-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:57:41 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1ARVdU-0006bw-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:57:40 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id hB3BvG74004086; Wed, 3 Dec 2003 04:57:16 -0700 (MST) Received: from motorola.com ([163.14.20.28]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id hB3BvTQU000782; Wed, 3 Dec 2003 05:57:30 -0600 Message-ID: <3FCDCFAB.3040507@motorola.com> Date: Wed, 03 Dec 2003 12:57:31 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] review of the nemo basic spec References: <3FCC7364.90108@kolumbus.fi> In-Reply-To: <3FCC7364.90108@kolumbus.fi> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jari Arkko wrote: >> But I'm afraid that we need to extend 8.4 (for route setup) and to > > > Extensions are fine too. Extensions in new documents are even better, such as the base document stays short and digestible by the IESG. Alex From exim@www1.ietf.org Wed Dec 3 06:58:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11077 for ; Wed, 3 Dec 2003 06:58: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 1ARVdt-0008Sa-EB for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 06:58:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Bw5MA032514 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 06: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 1ARVdt-0008SI-6v for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 06:58: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 GAA11039 for ; Wed, 3 Dec 2003 06:57:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVdo-0006ck-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 06:58:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARVdo-0006cf-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 06:58:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVdq-0008Qs-Qp; Wed, 03 Dec 2003 06:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVdZ-0008PH-9T for nemo@optimus.ietf.org; Wed, 03 Dec 2003 06:57: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 GAA11014 for ; Wed, 3 Dec 2003 06:57:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVdU-0006bz-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:57:41 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1ARVdU-0006bw-00 for nemo@ietf.org; Wed, 03 Dec 2003 06:57:40 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id hB3BvG74004086; Wed, 3 Dec 2003 04:57:16 -0700 (MST) Received: from motorola.com ([163.14.20.28]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id hB3BvTQU000782; Wed, 3 Dec 2003 05:57:30 -0600 Message-ID: <3FCDCFAB.3040507@motorola.com> Date: Wed, 03 Dec 2003 12:57:31 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] review of the nemo basic spec References: <3FCC7364.90108@kolumbus.fi> In-Reply-To: <3FCC7364.90108@kolumbus.fi> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jari Arkko wrote: >> But I'm afraid that we need to extend 8.4 (for route setup) and to > > > Extensions are fine too. Extensions in new documents are even better, such as the base document stays short and digestible by the IESG. Alex From nemo-admin@ietf.org Wed Dec 3 07:07:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11453 for ; Wed, 3 Dec 2003 07:07: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 1ARVmY-0000Oy-4l; Wed, 03 Dec 2003 07:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVlr-0000NB-Tt for nemo@optimus.ietf.org; Wed, 03 Dec 2003 07:06: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 HAA11391 for ; Wed, 3 Dec 2003 07:06:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVln-0006n7-00 for nemo@ietf.org; Wed, 03 Dec 2003 07:06:15 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARVln-0006mZ-00 for nemo@ietf.org; Wed, 03 Dec 2003 07:06:15 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Dec 2003 13:02:58 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB3C5BZT011624; Wed, 3 Dec 2003 13:05:32 +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, 3 Dec 2003 12:05:31 +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 Date: Wed, 3 Dec 2003 12:05:30 -0000 Message-ID: Thread-Topic: NINO in a MIMO (was: review of the nemo basic spec) Thread-Index: AcO5k6UwCrQvky/1Rq6CV4VtAWAmhQAAXjiw From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" Cc: "Jari Arkko" , X-OriginalArrivalTime: 03 Dec 2003 12:05:31.0629 (UTC) FILETIME=[BFD6B1D0:01C3B995] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: NINO in a MIMO (was: review of the nemo basic spec) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: mercredi 3 d=E9cembre 2003 12:50 > To: Pascal Thubert (pthubert) > Cc: Jari Arkko; nemo@ietf.org > Subject: Re: NINO in a MIMO (was: review of the nemo basic spec) >=20 > Pascal Thubert (pthubert) wrote: > > This relates to the "ND model for routers" and the "ROUTERS" vs. > > "routers" discussions in the v6WG list. >=20 > I would suggest keep that thread where it started. >=20 > > The model I'm missing in ND is the "Network in a Node". For a Node > > with a prefix inside it or behind it, or more generally a proxy. A > > Network in Node Option (Nino) would help. >=20 > I think there could be some confusion when using NINO in a MIMO = device. >=20 > Note that MIMO is pronounced MY-MO while NINO is pronounced NEE-GNO :) Pascal From exim@www1.ietf.org Wed Dec 3 07:07:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11468 for ; Wed, 3 Dec 2003 07:07: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 1ARVma-0000R1-ET for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 07:07:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3C73xx001645 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 07:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVmZ-0000QP-MD for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 07:07: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 HAA11413 for ; Wed, 3 Dec 2003 07:06:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVmV-0006ng-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 07:06:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARVmU-0006nd-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 07:06:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVmY-0000Oy-4l; Wed, 03 Dec 2003 07:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARVlr-0000NB-Tt for nemo@optimus.ietf.org; Wed, 03 Dec 2003 07:06: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 HAA11391 for ; Wed, 3 Dec 2003 07:06:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARVln-0006n7-00 for nemo@ietf.org; Wed, 03 Dec 2003 07:06:15 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARVln-0006mZ-00 for nemo@ietf.org; Wed, 03 Dec 2003 07:06:15 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Dec 2003 13:02:58 +0100 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB3C5BZT011624; Wed, 3 Dec 2003 13:05:32 +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, 3 Dec 2003 12:05:31 +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 Date: Wed, 3 Dec 2003 12:05:30 -0000 Message-ID: Thread-Topic: NINO in a MIMO (was: review of the nemo basic spec) Thread-Index: AcO5k6UwCrQvky/1Rq6CV4VtAWAmhQAAXjiw From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" Cc: "Jari Arkko" , X-OriginalArrivalTime: 03 Dec 2003 12:05:31.0629 (UTC) FILETIME=[BFD6B1D0:01C3B995] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: NINO in a MIMO (was: review of the nemo basic spec) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: mercredi 3 d=E9cembre 2003 12:50 > To: Pascal Thubert (pthubert) > Cc: Jari Arkko; nemo@ietf.org > Subject: Re: NINO in a MIMO (was: review of the nemo basic spec) >=20 > Pascal Thubert (pthubert) wrote: > > This relates to the "ND model for routers" and the "ROUTERS" vs. > > "routers" discussions in the v6WG list. >=20 > I would suggest keep that thread where it started. >=20 > > The model I'm missing in ND is the "Network in a Node". For a Node > > with a prefix inside it or behind it, or more generally a proxy. A > > Network in Node Option (Nino) would help. >=20 > I think there could be some confusion when using NINO in a MIMO = device. >=20 > Note that MIMO is pronounced MY-MO while NINO is pronounced NEE-GNO :) Pascal From nemo-admin@ietf.org Wed Dec 3 12:43:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25440 for ; Wed, 3 Dec 2003 12:43:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARb1h-0003F0-Tm; Wed, 03 Dec 2003 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 1ARb1d-0003EP-BA for nemo@optimus.ietf.org; Wed, 03 Dec 2003 12: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 MAA25392 for ; Wed, 3 Dec 2003 12:42:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARb1b-00057L-00 for nemo@ietf.org; Wed, 03 Dec 2003 12:42:55 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARb1a-00056F-00 for nemo@ietf.org; Wed, 03 Dec 2003 12:42:55 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB3HgMB29521; Wed, 3 Dec 2003 09:42:22 -0800 X-mProtect: <200312031742> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdcJrx90; Wed, 03 Dec 2003 09:42:20 PST Message-ID: <3FCE21AD.1000501@iprg.nokia.com> Date: Wed, 03 Dec 2003 09:47:25 -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: "T.J. Kniveton" CC: nemo@ietf.org Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic spec) References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> <3FCD5847.1010809@kniveton.com> <3FCD5AC2.3060503@iprg.nokia.com> <3FCD823A.706 In-Reply-To: <3FCD823A.7060009@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: , Content-Transfer-Encoding: 7bit I see one use for it. a router can attach to a new link and announce itself through a router advertisement. we dont have any other message which can do this. not all routers run a routing protocol. but we dont have a use for this yet, currently. but then again, I dont see a reason to prohibit this when the MR is on the home link. Vijay T.J. Kniveton wrote: > > > Vijay Devarapalli wrote: > >> a router by its nature sends out router advertisements. there is >> no spec prohibiting it from sending out router advertisements on >> any of its interfaces. the NEMO basic spec restricts the mobile >> router to not send router advertisements on its egress interface >> when it is attached to a visited link. when it returns to a home >> link, we are saying it MAY start sending again. > > > My understand about router advertisements is that they are used for > routers to advertise their existence on links they serve, and give > information about the prefixes they will serve. > > The MR does not serve any nodes on the egress interface. Therefore it is > just like a HOST on that link. The MR should ever, only, advertise > itself as a router on a link where it acts as a router -- the mobile > network. > >> >> but we have to prevent hosts on the home link from configuring >> the mobile router as a default router. so we say the router >> lifetime SHOULD be set to 0. > > > Which is equivalent to not sending router advertisements. After all, > it's not going to include any prefix options in the RA, is it?? > >> >> >> Vijay >> > From exim@www1.ietf.org Wed Dec 3 12:43:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25456 for ; Wed, 3 Dec 2003 12:43: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 1ARb1o-0003GK-Ew for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 12:43:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Hh8HN012536 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 12:43:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARb1o-0003G7-Am for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 12:43:08 -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 MAA25420 for ; Wed, 3 Dec 2003 12:42:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARb1m-000584-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 12:43:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARb1m-000581-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 12:43:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARb1h-0003F0-Tm; Wed, 03 Dec 2003 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 1ARb1d-0003EP-BA for nemo@optimus.ietf.org; Wed, 03 Dec 2003 12: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 MAA25392 for ; Wed, 3 Dec 2003 12:42:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARb1b-00057L-00 for nemo@ietf.org; Wed, 03 Dec 2003 12:42:55 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARb1a-00056F-00 for nemo@ietf.org; Wed, 03 Dec 2003 12:42:55 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB3HgMB29521; Wed, 3 Dec 2003 09:42:22 -0800 X-mProtect: <200312031742> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdcJrx90; Wed, 03 Dec 2003 09:42:20 PST Message-ID: <3FCE21AD.1000501@iprg.nokia.com> Date: Wed, 03 Dec 2003 09:47:25 -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: "T.J. Kniveton" CC: nemo@ietf.org Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic spec) References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> <3FCD5847.1010809@kniveton.com> <3FCD5AC2.3060503@iprg.nokia.com> <3FCD823A.706 In-Reply-To: <3FCD823A.7060009@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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I see one use for it. a router can attach to a new link and announce itself through a router advertisement. we dont have any other message which can do this. not all routers run a routing protocol. but we dont have a use for this yet, currently. but then again, I dont see a reason to prohibit this when the MR is on the home link. Vijay T.J. Kniveton wrote: > > > Vijay Devarapalli wrote: > >> a router by its nature sends out router advertisements. there is >> no spec prohibiting it from sending out router advertisements on >> any of its interfaces. the NEMO basic spec restricts the mobile >> router to not send router advertisements on its egress interface >> when it is attached to a visited link. when it returns to a home >> link, we are saying it MAY start sending again. > > > My understand about router advertisements is that they are used for > routers to advertise their existence on links they serve, and give > information about the prefixes they will serve. > > The MR does not serve any nodes on the egress interface. Therefore it is > just like a HOST on that link. The MR should ever, only, advertise > itself as a router on a link where it acts as a router -- the mobile > network. > >> >> but we have to prevent hosts on the home link from configuring >> the mobile router as a default router. so we say the router >> lifetime SHOULD be set to 0. > > > Which is equivalent to not sending router advertisements. After all, > it's not going to include any prefix options in the RA, is it?? > >> >> >> Vijay >> > From nemo-admin@ietf.org Wed Dec 3 12:44:14 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25535 for ; Wed, 3 Dec 2003 12:44: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 1ARb2f-0003Kw-1O; Wed, 03 Dec 2003 12: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 1ARb25-0003KE-FP for nemo@optimus.ietf.org; Wed, 03 Dec 2003 12:43: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 MAA25428 for ; Wed, 3 Dec 2003 12:43:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARb23-00058P-00 for nemo@ietf.org; Wed, 03 Dec 2003 12:43:23 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARb22-00057F-00 for nemo@ietf.org; Wed, 03 Dec 2003 12:43:23 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB3Hgmx30634; Wed, 3 Dec 2003 09:42:48 -0800 X-mProtect: <200312031742> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAakbnn; Wed, 03 Dec 2003 09:42:46 PST Message-ID: <3FCE21DF.2040107@iprg.nokia.com> Date: Wed, 03 Dec 2003 09:48:15 -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: Ryuji Wakikawa CC: nemo@ietf.org, Jari Arkko , "Pascal Thubert (pthubert)" Subject: Re: [nemo] Closing Issue 16 References: <3FCD26C3.2030305@iprg.nokia.com> <20031203150053.6C8B.RYUJI@sfc.wide.ad.jp> In-Reply-To: <20031203150053.6C8B.RYUJI@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: >>5.3. Receiving Binding Acknowledgements >> >> The Mobile Router receives Binding Acknowledgements from the Home >> Agent, corresponding to the Binding Updates it sent. If the Binding >> Acknowledgement status is set to '0' (Binding Update accepted) and >> the Mobile Router flag (R) is set to 1, the Mobile Router assumes >> that the Home Agent has successfully processed the Binding Update >> and has set up forwarding for the Mobile Network. The Mobile Router >> can then start using the bi-directional tunnel for reverse tunneling >> traffic from the mobile network. If the Mobile Router flag (R) is >> not set, then the Mobile Router concludes that its current Home Agent >> does not support Mobile Routers and performs Dynamic Home Agent >> Discovery again to discover Home Agents which support Mobile Routers. > > > If lecacy HA replied with successful status code without Rbit, MR should > de-register its host binding from the HA. no? > Otherwise, it HoA is generated from the home link (MIP mode), DAD will > be occured at the home link. > regards > ryuji agree. I will add some text. Vijay From exim@www1.ietf.org Wed Dec 3 12:44:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25553 for ; Wed, 3 Dec 2003 12:44: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 1ARb2i-0003PY-CC for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 12:44:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Hi4xa013106 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 12:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARb2h-0003PC-4i for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 12:44: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 MAA25497 for ; Wed, 3 Dec 2003 12:43:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARb2e-000590-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 12:44:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARb2e-00058x-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 12:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARb2f-0003Kw-1O; Wed, 03 Dec 2003 12: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 1ARb25-0003KE-FP for nemo@optimus.ietf.org; Wed, 03 Dec 2003 12:43: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 MAA25428 for ; Wed, 3 Dec 2003 12:43:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARb23-00058P-00 for nemo@ietf.org; Wed, 03 Dec 2003 12:43:23 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARb22-00057F-00 for nemo@ietf.org; Wed, 03 Dec 2003 12:43:23 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB3Hgmx30634; Wed, 3 Dec 2003 09:42:48 -0800 X-mProtect: <200312031742> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAakbnn; Wed, 03 Dec 2003 09:42:46 PST Message-ID: <3FCE21DF.2040107@iprg.nokia.com> Date: Wed, 03 Dec 2003 09:48:15 -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: Ryuji Wakikawa CC: nemo@ietf.org, Jari Arkko , "Pascal Thubert (pthubert)" Subject: Re: [nemo] Closing Issue 16 References: <3FCD26C3.2030305@iprg.nokia.com> <20031203150053.6C8B.RYUJI@sfc.wide.ad.jp> In-Reply-To: <20031203150053.6C8B.RYUJI@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: >>5.3. Receiving Binding Acknowledgements >> >> The Mobile Router receives Binding Acknowledgements from the Home >> Agent, corresponding to the Binding Updates it sent. If the Binding >> Acknowledgement status is set to '0' (Binding Update accepted) and >> the Mobile Router flag (R) is set to 1, the Mobile Router assumes >> that the Home Agent has successfully processed the Binding Update >> and has set up forwarding for the Mobile Network. The Mobile Router >> can then start using the bi-directional tunnel for reverse tunneling >> traffic from the mobile network. If the Mobile Router flag (R) is >> not set, then the Mobile Router concludes that its current Home Agent >> does not support Mobile Routers and performs Dynamic Home Agent >> Discovery again to discover Home Agents which support Mobile Routers. > > > If lecacy HA replied with successful status code without Rbit, MR should > de-register its host binding from the HA. no? > Otherwise, it HoA is generated from the home link (MIP mode), DAD will > be occured at the home link. > regards > ryuji agree. I will add some text. Vijay From nemo-admin@ietf.org Wed Dec 3 12:48:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25769 for ; Wed, 3 Dec 2003 12:48: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 1ARb6X-0003Us-BJ; Wed, 03 Dec 2003 12: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 1ARb69-0003U3-8D for nemo@optimus.ietf.org; Wed, 03 Dec 2003 12:47: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 MAA25734 for ; Wed, 3 Dec 2003 12:47:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARb67-0005DK-00 for nemo@ietf.org; Wed, 03 Dec 2003 12:47:35 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARb66-0005Cl-00 for nemo@ietf.org; Wed, 03 Dec 2003 12:47:34 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB3Hl2003054; Wed, 3 Dec 2003 09:47:02 -0800 X-mProtect: <200312031747> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7ahfej; Wed, 03 Dec 2003 09:47:01 PST Message-ID: <3FCE22DE.5060304@iprg.nokia.com> Date: Wed, 03 Dec 2003 09:52:30 -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: Ryuji Wakikawa CC: nemo@ietf.org, kempf@docomolabs-usa.com, jari.arkko@kolumbus.fi, pthubert@cisco.com Subject: Re: [nemo] Closing Issue 20 References: <3FCD0207.6010101@iprg.nokia.com> <20031203153412.6C92.RYUJI@sfc.wide.ad.jp> In-Reply-To: <20031203153412.6C92.RYUJI@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ryuji, lets keep it simple. I think it is just not worth having a flag and extra code for this. just include the prefix in the Binding Update if explicit mode is being used. Vijay Ryuji Wakikawa wrote: > Hi Vijay. > > Final argument for this topic:-p > > The difference between prefix opt and prefixlen opt is whether it has > field for "prefix" and how to retrieve "prefix" from moboption. > > We can combine two options into one option and say both prefix and > prefixlen is explicit mode. > > My idea is using flag in reserved field. If t=he flag is on, prefix field is not presented and use both len > and HoA to retrieve HoA. Otherwise, HA gets mobile network prefix just from prefix field. > > +-------+-------+--------+---------+ > | type | len |x| | len | > +-------+-------+--------+---------+ > | prefix (optional) | > +-------+-------+--------+---------+ > > this does not cause so much additional codes. > If this is not right way, just drop prefix length. > I am OK if MR can retrieve its HoA from its mobile network prefix at least. > > ryuji > > >>hi all, >> >>I think there is concensus now to remove the explicit prefix length >>mode. whatever one wanted to do with the explicit prefix length mode >>should be possible with the explicit network mode. >> >>this will address (to an extent) the concern that there are now too >>many differnt ways of doing the same thing, i.e. the mobile router >>asking the Home Agent to setup forwarding for the mobile network. >> >>Vijay > > > regards, > ryuji > From exim@www1.ietf.org Wed Dec 3 12:48:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25784 for ; Wed, 3 Dec 2003 12:48:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARb6c-0003XF-I0 for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 12:48:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Hm6MW013583 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 12:48:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARb6Y-0003Vr-Uy for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 12:48: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 MAA25743 for ; Wed, 3 Dec 2003 12:47:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARb6W-0005DW-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 12:48:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARb6W-0005DT-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 12:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARb6X-0003Us-BJ; Wed, 03 Dec 2003 12: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 1ARb69-0003U3-8D for nemo@optimus.ietf.org; Wed, 03 Dec 2003 12:47: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 MAA25734 for ; Wed, 3 Dec 2003 12:47:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARb67-0005DK-00 for nemo@ietf.org; Wed, 03 Dec 2003 12:47:35 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARb66-0005Cl-00 for nemo@ietf.org; Wed, 03 Dec 2003 12:47:34 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB3Hl2003054; Wed, 3 Dec 2003 09:47:02 -0800 X-mProtect: <200312031747> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7ahfej; Wed, 03 Dec 2003 09:47:01 PST Message-ID: <3FCE22DE.5060304@iprg.nokia.com> Date: Wed, 03 Dec 2003 09:52:30 -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: Ryuji Wakikawa CC: nemo@ietf.org, kempf@docomolabs-usa.com, jari.arkko@kolumbus.fi, pthubert@cisco.com Subject: Re: [nemo] Closing Issue 20 References: <3FCD0207.6010101@iprg.nokia.com> <20031203153412.6C92.RYUJI@sfc.wide.ad.jp> In-Reply-To: <20031203153412.6C92.RYUJI@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ryuji, lets keep it simple. I think it is just not worth having a flag and extra code for this. just include the prefix in the Binding Update if explicit mode is being used. Vijay Ryuji Wakikawa wrote: > Hi Vijay. > > Final argument for this topic:-p > > The difference between prefix opt and prefixlen opt is whether it has > field for "prefix" and how to retrieve "prefix" from moboption. > > We can combine two options into one option and say both prefix and > prefixlen is explicit mode. > > My idea is using flag in reserved field. If t=he flag is on, prefix field is not presented and use both len > and HoA to retrieve HoA. Otherwise, HA gets mobile network prefix just from prefix field. > > +-------+-------+--------+---------+ > | type | len |x| | len | > +-------+-------+--------+---------+ > | prefix (optional) | > +-------+-------+--------+---------+ > > this does not cause so much additional codes. > If this is not right way, just drop prefix length. > I am OK if MR can retrieve its HoA from its mobile network prefix at least. > > ryuji > > >>hi all, >> >>I think there is concensus now to remove the explicit prefix length >>mode. whatever one wanted to do with the explicit prefix length mode >>should be possible with the explicit network mode. >> >>this will address (to an extent) the concern that there are now too >>many differnt ways of doing the same thing, i.e. the mobile router >>asking the Home Agent to setup forwarding for the mobile network. >> >>Vijay > > > regards, > ryuji > From nemo-admin@ietf.org Wed Dec 3 12:58:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26113 for ; Wed, 3 Dec 2003 12:58: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 1ARbGD-0003m7-I3; Wed, 03 Dec 2003 12:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARbFi-0003lY-5g for nemo@optimus.ietf.org; Wed, 03 Dec 2003 12:57: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 MAA26092 for ; Wed, 3 Dec 2003 12:57:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARbFg-0005Ls-00 for nemo@ietf.org; Wed, 03 Dec 2003 12:57:28 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARbFf-0005LU-00 for nemo@ietf.org; Wed, 03 Dec 2003 12:57:27 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB3Hu1A13218; Wed, 3 Dec 2003 09:56:01 -0800 X-mProtect: <200312031756> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpddugAd9; Wed, 03 Dec 2003 09:55:59 PST Message-ID: <3FCE24F9.5020104@iprg.nokia.com> Date: Wed, 03 Dec 2003 10:01:29 -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: Jari Arkko , nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko 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: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > >> >> 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 belong to the Mobile Network Prefix >> owned by the Mobile Router. >> > > > Note that in the reqs I proposed yesterday, I first thought I would copy > that text and then I realized it was a bit restrictive and I replaced by > topological correctness for the inner packet. What do you think? I believe > this should be changed in the security section as well. hmm.. either way is fine with me. but dont you think "topological correctness" is vague compared to what is there currently? Vijay From exim@www1.ietf.org Wed Dec 3 12:58:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26128 for ; Wed, 3 Dec 2003 12:58: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 1ARbGH-0003nO-1I for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 12:58:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Hw4cP014584 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 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 1ARbGG-0003n1-QH for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 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 MAA26102 for ; Wed, 3 Dec 2003 12:57:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARbGF-0005M6-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 12:58:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARbGE-0005M3-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 12:58:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARbGD-0003m7-I3; Wed, 03 Dec 2003 12:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARbFi-0003lY-5g for nemo@optimus.ietf.org; Wed, 03 Dec 2003 12:57: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 MAA26092 for ; Wed, 3 Dec 2003 12:57:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARbFg-0005Ls-00 for nemo@ietf.org; Wed, 03 Dec 2003 12:57:28 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARbFf-0005LU-00 for nemo@ietf.org; Wed, 03 Dec 2003 12:57:27 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB3Hu1A13218; Wed, 3 Dec 2003 09:56:01 -0800 X-mProtect: <200312031756> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpddugAd9; Wed, 03 Dec 2003 09:55:59 PST Message-ID: <3FCE24F9.5020104@iprg.nokia.com> Date: Wed, 03 Dec 2003 10:01:29 -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: Jari Arkko , nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > >> >> 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 belong to the Mobile Network Prefix >> owned by the Mobile Router. >> > > > Note that in the reqs I proposed yesterday, I first thought I would copy > that text and then I realized it was a bit restrictive and I replaced by > topological correctness for the inner packet. What do you think? I believe > this should be changed in the security section as well. hmm.. either way is fine with me. but dont you think "topological correctness" is vague compared to what is there currently? Vijay From nemo-admin@ietf.org Wed Dec 3 13:02:14 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26329 for ; Wed, 3 Dec 2003 13:02: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 1ARbK4-0003yb-L8; Wed, 03 Dec 2003 13:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARbJM-0003wT-Bc for nemo@optimus.ietf.org; Wed, 03 Dec 2003 13:01: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 NAA26260 for ; Wed, 3 Dec 2003 13:00:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARbJK-0005Pg-00 for nemo@ietf.org; Wed, 03 Dec 2003 13:01:14 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARbJJ-0005Oi-00 for nemo@ietf.org; Wed, 03 Dec 2003 13:01:13 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB3I0eB18225; Wed, 3 Dec 2003 10:00:40 -0800 X-mProtect: <200312031800> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmSgchi; Wed, 03 Dec 2003 10:00:39 PST Message-ID: <3FCE2611.5070706@iprg.nokia.com> Date: Wed, 03 Dec 2003 10:06:09 -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: Jari Arkko CC: "T.J. Kniveton" , nemo@ietf.org Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic spec) References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> <3FCD5847.1010809@kniveton.com> <3FCD5AC2.3060503@iprg.nokia.com> <3FCD823A.706 In-Reply-To: <3FCDA46C.90404@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I know James Kempf sent a mail to Hesham asking for this to be clarified when RFC 2461 is revised. IMO, there is no technical reason to prohibit it. infact I see it as a message which can be used by a router to announce itself on a link when it attaches to its home link. however there is no use for this currently. Vijay Jari Arkko wrote: > > I also feel a bit uneasy about sending RAs on the home > link. If the dynamic routing protocol case is included > in basic support draft, then we do have to allow routing > protocols to be run on the home link. But what else? > > Unfortunately, the ipv6 routers vs. ROUTERs discussion > did not go in to too much depth on these issues. Start a > new discussion with the specific case of Nemo in mind? > Or did you already discuss the RFC 2461 unclarities wrt > this in some other thread on the ipv6 list, as someone > promised to do in the issue 21 file? > > --Jari > > From exim@www1.ietf.org Wed Dec 3 13:02:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26344 for ; Wed, 3 Dec 2003 13:02: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 1ARbK6-0003zd-48 for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 13:02:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3I22bQ015343 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 13: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 1ARbK5-0003zO-Ut for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 13:02: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 NAA26319 for ; Wed, 3 Dec 2003 13:01:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARbK4-0005Rb-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 13:02:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARbK3-0005RY-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 13:01:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARbK4-0003yb-L8; Wed, 03 Dec 2003 13:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARbJM-0003wT-Bc for nemo@optimus.ietf.org; Wed, 03 Dec 2003 13:01: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 NAA26260 for ; Wed, 3 Dec 2003 13:00:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARbJK-0005Pg-00 for nemo@ietf.org; Wed, 03 Dec 2003 13:01:14 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARbJJ-0005Oi-00 for nemo@ietf.org; Wed, 03 Dec 2003 13:01:13 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB3I0eB18225; Wed, 3 Dec 2003 10:00:40 -0800 X-mProtect: <200312031800> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmSgchi; Wed, 03 Dec 2003 10:00:39 PST Message-ID: <3FCE2611.5070706@iprg.nokia.com> Date: Wed, 03 Dec 2003 10:06:09 -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: Jari Arkko CC: "T.J. Kniveton" , nemo@ietf.org Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic spec) References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> <3FCD5847.1010809@kniveton.com> <3FCD5AC2.3060503@iprg.nokia.com> <3FCD823A.706 In-Reply-To: <3FCDA46C.90404@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I know James Kempf sent a mail to Hesham asking for this to be clarified when RFC 2461 is revised. IMO, there is no technical reason to prohibit it. infact I see it as a message which can be used by a router to announce itself on a link when it attaches to its home link. however there is no use for this currently. Vijay Jari Arkko wrote: > > I also feel a bit uneasy about sending RAs on the home > link. If the dynamic routing protocol case is included > in basic support draft, then we do have to allow routing > protocols to be run on the home link. But what else? > > Unfortunately, the ipv6 routers vs. ROUTERs discussion > did not go in to too much depth on these issues. Start a > new discussion with the specific case of Nemo in mind? > Or did you already discuss the RFC 2461 unclarities wrt > this in some other thread on the ipv6 list, as someone > promised to do in the issue 21 file? > > --Jari > > From nemo-admin@ietf.org Wed Dec 3 13:08:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26520 for ; Wed, 3 Dec 2003 13:08: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 1ARbPs-0004Rd-UR; Wed, 03 Dec 2003 13:08:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARbPF-0004Fq-NI for nemo@optimus.ietf.org; Wed, 03 Dec 2003 13:07:21 -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 NAA26499 for ; Wed, 3 Dec 2003 13:07:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARbPD-0005Ud-00 for nemo@ietf.org; Wed, 03 Dec 2003 13:07:19 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARbPC-0005UH-00 for nemo@ietf.org; Wed, 03 Dec 2003 13:07:19 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB3I4YX21499; Wed, 3 Dec 2003 10:04:34 -0800 X-mProtect: <200312031804> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdvCIu8U; Wed, 03 Dec 2003 10:04:32 PST Message-ID: <3FCE26F9.2060606@iprg.nokia.com> Date: Wed, 03 Dec 2003 10:10:01 -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: Jari Arkko , nemo@ietf.org Subject: Re: [nemo] Closing Issue 16 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: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > > Say we add more and more features like basic nemo and now HAs support a number of those features. The request may end up like an SQL query depending on what the requester wants or is willing to accept if the most wanted is not available. Wouldn't it be better to list everything and let the requester sort it out based on its own preference? you maybe right. but NEMO basic support spec the place to do it? Vijay From exim@www1.ietf.org Wed Dec 3 13:08:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26535 for ; Wed, 3 Dec 2003 13:08: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 1ARbPv-0004TX-FH for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 13:08:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3I83bY017188 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 13: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 1ARbPu-0004T9-P1 for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 13:08: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 NAA26512 for ; Wed, 3 Dec 2003 13:07:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARbPs-0005VD-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 13:08:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARbPs-0005VA-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 13:08:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARbPs-0004Rd-UR; Wed, 03 Dec 2003 13:08:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARbPF-0004Fq-NI for nemo@optimus.ietf.org; Wed, 03 Dec 2003 13:07:21 -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 NAA26499 for ; Wed, 3 Dec 2003 13:07:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARbPD-0005Ud-00 for nemo@ietf.org; Wed, 03 Dec 2003 13:07:19 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARbPC-0005UH-00 for nemo@ietf.org; Wed, 03 Dec 2003 13:07:19 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB3I4YX21499; Wed, 3 Dec 2003 10:04:34 -0800 X-mProtect: <200312031804> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdvCIu8U; Wed, 03 Dec 2003 10:04:32 PST Message-ID: <3FCE26F9.2060606@iprg.nokia.com> Date: Wed, 03 Dec 2003 10:10:01 -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: Jari Arkko , nemo@ietf.org Subject: Re: [nemo] Closing Issue 16 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > > Say we add more and more features like basic nemo and now HAs support a number of those features. The request may end up like an SQL query depending on what the requester wants or is willing to accept if the most wanted is not available. Wouldn't it be better to list everything and let the requester sort it out based on its own preference? you maybe right. but NEMO basic support spec the place to do it? Vijay From nemo-admin@ietf.org Wed Dec 3 13:17:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26870 for ; Wed, 3 Dec 2003 13:17: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 1ARbYb-0004mC-EY; Wed, 03 Dec 2003 13:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARbXg-0004lw-SF for nemo@optimus.ietf.org; Wed, 03 Dec 2003 13:16: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 NAA26859 for ; Wed, 3 Dec 2003 13:15:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARbXe-0005du-00 for nemo@ietf.org; Wed, 03 Dec 2003 13:16:02 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARbXe-0005df-00 for nemo@ietf.org; Wed, 03 Dec 2003 13:16:02 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB3IDqg29072; Wed, 3 Dec 2003 10:13:52 -0800 X-mProtect: <200312031813> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdzHpae6; Wed, 03 Dec 2003 10:13:50 PST Message-ID: <3FCE2928.2070900@iprg.nokia.com> Date: Wed, 03 Dec 2003 10:19:20 -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: Jari Arkko , "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] review of the nemo basic spec References: <3FCC7364.90108@kolumbus.fi> <3FCDCE95.10603@motorola.com> In-Reply-To: <3FCDCE95.10603@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: , Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Jari Arkko wrote: > >>> Are you suggesting to remove chapter 7 and say nothing? >> >> >> That would be one alternative yes. I think the draft has too many >> options at the moment. (Another alternative would be not have the >> static config option, that would also reduce the number of options. >> But I see there is some discussion about this already ...) > > > The first alternative sounds reasonable to me. Keep both the implicit > and explicit network modes, and enhance the routing protocol section > over MRHA in an additional document. Alex, if there is a technical issue which needs a lot of text to resolve, then maybe, yes. otherwise, I disagree. Vijay From exim@www1.ietf.org Wed Dec 3 13:17:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26885 for ; Wed, 3 Dec 2003 13:17: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 1ARbYe-0004nD-AD for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 13:17:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3IH4PS018417 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 13:17:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARbYe-0004my-49 for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 13:17: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 NAA26867 for ; Wed, 3 Dec 2003 13:16:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARbYc-0005fb-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 13:17:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARbYb-0005fY-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 13:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARbYb-0004mC-EY; Wed, 03 Dec 2003 13:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARbXg-0004lw-SF for nemo@optimus.ietf.org; Wed, 03 Dec 2003 13:16: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 NAA26859 for ; Wed, 3 Dec 2003 13:15:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARbXe-0005du-00 for nemo@ietf.org; Wed, 03 Dec 2003 13:16:02 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARbXe-0005df-00 for nemo@ietf.org; Wed, 03 Dec 2003 13:16:02 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB3IDqg29072; Wed, 3 Dec 2003 10:13:52 -0800 X-mProtect: <200312031813> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdzHpae6; Wed, 03 Dec 2003 10:13:50 PST Message-ID: <3FCE2928.2070900@iprg.nokia.com> Date: Wed, 03 Dec 2003 10:19:20 -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: Jari Arkko , "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] review of the nemo basic spec References: <3FCC7364.90108@kolumbus.fi> <3FCDCE95.10603@motorola.com> In-Reply-To: <3FCDCE95.10603@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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Jari Arkko wrote: > >>> Are you suggesting to remove chapter 7 and say nothing? >> >> >> That would be one alternative yes. I think the draft has too many >> options at the moment. (Another alternative would be not have the >> static config option, that would also reduce the number of options. >> But I see there is some discussion about this already ...) > > > The first alternative sounds reasonable to me. Keep both the implicit > and explicit network modes, and enhance the routing protocol section > over MRHA in an additional document. Alex, if there is a technical issue which needs a lot of text to resolve, then maybe, yes. otherwise, I disagree. Vijay From nemo-admin@ietf.org Wed Dec 3 14:32:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00348 for ; Wed, 3 Dec 2003 14:32: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 1ARcjB-0007oX-TP; Wed, 03 Dec 2003 14:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARciJ-0007nX-0O for nemo@optimus.ietf.org; Wed, 03 Dec 2003 14:31:07 -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 OAA00227 for ; Wed, 3 Dec 2003 14:30:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARciG-0006xg-00 for nemo@ietf.org; Wed, 03 Dec 2003 14:31:04 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARciE-0006xJ-00 for nemo@ietf.org; Wed, 03 Dec 2003 14:31:03 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB3JU3t20255; Wed, 3 Dec 2003 11:30:03 -0800 X-mProtect: <200312031930> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEkdY5J; Wed, 03 Dec 2003 11:30:01 PST Message-ID: <3FCE3B03.6030803@iprg.nokia.com> Date: Wed, 03 Dec 2003 11:35:31 -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: "T.J. Kniveton" , nemo@ietf.org Subject: Re: [nemo] Re: issue xxx: requirements chapter for Nemo. 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: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > > Dependencies: > ------------- > Basic Nemo MRs MUST implement this specification, [MIPv6] chapter 8.1 and 8.3, and RFCs 2460, 2461, 2462, 2463 and 2473. > Basic Nemo MRs MAY implement [MIPv6] chapter 8.2 and 8.5, and RFC 3041. > Basic Nemo HAs MUST fully implement this specification, [MIPv6] chapter 8.1, 8.3 and 8.4, and RFCs 2460, 2461, 2462, 2463 and 2473. apart for saying NEMO Mobile Routers MAY implement return routability based Route Optimization (both CN and MN functionality), everything else seems to be mandatory. maybe that is all that needs to be said. (?) Vijay From exim@www1.ietf.org Wed Dec 3 14:32:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00381 for ; Wed, 3 Dec 2003 14:32: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 1ARcjY-0007tj-0c for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 14:32:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3JWNkw030353 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 14:32:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcjX-0007tU-Qn for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 14:32: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 OAA00296 for ; Wed, 3 Dec 2003 14:32:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARcjV-00070F-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 14:32:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARcjU-00070C-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 14:32:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcjB-0007oX-TP; Wed, 03 Dec 2003 14:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARciJ-0007nX-0O for nemo@optimus.ietf.org; Wed, 03 Dec 2003 14:31:07 -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 OAA00227 for ; Wed, 3 Dec 2003 14:30:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARciG-0006xg-00 for nemo@ietf.org; Wed, 03 Dec 2003 14:31:04 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARciE-0006xJ-00 for nemo@ietf.org; Wed, 03 Dec 2003 14:31:03 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB3JU3t20255; Wed, 3 Dec 2003 11:30:03 -0800 X-mProtect: <200312031930> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEkdY5J; Wed, 03 Dec 2003 11:30:01 PST Message-ID: <3FCE3B03.6030803@iprg.nokia.com> Date: Wed, 03 Dec 2003 11:35:31 -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: "T.J. Kniveton" , nemo@ietf.org Subject: Re: [nemo] Re: issue xxx: requirements chapter for Nemo. 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > > Dependencies: > ------------- > Basic Nemo MRs MUST implement this specification, [MIPv6] chapter 8.1 and 8.3, and RFCs 2460, 2461, 2462, 2463 and 2473. > Basic Nemo MRs MAY implement [MIPv6] chapter 8.2 and 8.5, and RFC 3041. > Basic Nemo HAs MUST fully implement this specification, [MIPv6] chapter 8.1, 8.3 and 8.4, and RFCs 2460, 2461, 2462, 2463 and 2473. apart for saying NEMO Mobile Routers MAY implement return routability based Route Optimization (both CN and MN functionality), everything else seems to be mandatory. maybe that is all that needs to be said. (?) Vijay From nemo-admin@ietf.org Wed Dec 3 14:59:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01379 for ; Wed, 3 Dec 2003 14:59: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 1ARd9J-0000eU-IZ; Wed, 03 Dec 2003 14:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARd8q-0000e5-3b for nemo@optimus.ietf.org; Wed, 03 Dec 2003 14:58: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 OAA01345 for ; Wed, 3 Dec 2003 14:58:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARd8n-0007MX-00 for nemo@ietf.org; Wed, 03 Dec 2003 14:58:29 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1ARd8m-0007MM-00 for nemo@ietf.org; Wed, 03 Dec 2003 14:58:28 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B3BAA6A903; Wed, 3 Dec 2003 21:58:17 +0200 (EET) Message-ID: <3FCE3F4A.3070205@kolumbus.fi> Date: Wed, 03 Dec 2003 21:53:46 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: "Pascal Thubert (pthubert)" , "T.J. Kniveton" , nemo@ietf.org Subject: Re: [nemo] Re: issue xxx: requirements chapter for Nemo. References: <3FCE3B03.6030803@iprg.nokia.com> In-Reply-To: <3FCE3B03.6030803@iprg.nokia.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: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > apart for saying NEMO Mobile Routers MAY implement return > routability based Route Optimization (both CN and MN > functionality), everything else seems to be mandatory. maybe > that is all that needs to be said. (?) Yes. --Jari From exim@www1.ietf.org Wed Dec 3 14:59:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01398 for ; Wed, 3 Dec 2003 14:59: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 1ARd9U-0000fl-DY for nemo-archive@odin.ietf.org; Wed, 03 Dec 2003 14:59:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3JxC1c002579 for nemo-archive@odin.ietf.org; Wed, 3 Dec 2003 14:59:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARd9U-0000fW-7J for nemo-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 14:59: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 OAA01370 for ; Wed, 3 Dec 2003 14:58:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARd9R-0007Mr-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 14:59:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARd9R-0007Mn-00 for nemo-web-archive@ietf.org; Wed, 03 Dec 2003 14:59:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARd9J-0000eU-IZ; Wed, 03 Dec 2003 14:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARd8q-0000e5-3b for nemo@optimus.ietf.org; Wed, 03 Dec 2003 14:58: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 OAA01345 for ; Wed, 3 Dec 2003 14:58:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARd8n-0007MX-00 for nemo@ietf.org; Wed, 03 Dec 2003 14:58:29 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1ARd8m-0007MM-00 for nemo@ietf.org; Wed, 03 Dec 2003 14:58:28 -0500 Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B3BAA6A903; Wed, 3 Dec 2003 21:58:17 +0200 (EET) Message-ID: <3FCE3F4A.3070205@kolumbus.fi> Date: Wed, 03 Dec 2003 21:53:46 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: "Pascal Thubert (pthubert)" , "T.J. Kniveton" , nemo@ietf.org Subject: Re: [nemo] Re: issue xxx: requirements chapter for Nemo. References: <3FCE3B03.6030803@iprg.nokia.com> In-Reply-To: <3FCE3B03.6030803@iprg.nokia.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > apart for saying NEMO Mobile Routers MAY implement return > routability based Route Optimization (both CN and MN > functionality), everything else seems to be mandatory. maybe > that is all that needs to be said. (?) Yes. --Jari From nemo-admin@ietf.org Thu Dec 4 02:29:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14093 for ; Thu, 4 Dec 2003 02:29: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 1ARnv5-0004On-4o; Thu, 04 Dec 2003 02:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARnuP-0004NR-3O for nemo@optimus.ietf.org; Thu, 04 Dec 2003 02:28: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 CAA14067 for ; Thu, 4 Dec 2003 02:28:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARnuL-0003Wa-00 for nemo@ietf.org; Thu, 04 Dec 2003 02:28:17 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARnuK-0003WL-00 for nemo@ietf.org; Thu, 04 Dec 2003 02:28:16 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 04 Dec 2003 08:24:28 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB47R4Os010136; Thu, 4 Dec 2003 08:27:04 +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, 4 Dec 2003 07:27:16 +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] Editorial comments from Jari Arkko Date: Thu, 4 Dec 2003 07:27:16 -0000 Message-ID: Thread-Topic: [nemo] Editorial comments from Jari Arkko Thread-Index: AcO5xujK8t2HTdJNRzmCEc6DRN+PBAAb6y+w From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: "Jari Arkko" , X-OriginalArrivalTime: 04 Dec 2003 07:27:16.0912 (UTC) FILETIME=[0B6CCB00:01C3BA38] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mercredi 3 d=E9cembre 2003 19:01 > To: Pascal Thubert (pthubert) > Cc: Jari Arkko; nemo@ietf.org > Subject: Re: [nemo] Editorial comments from Jari Arkko >=20 > Pascal Thubert (pthubert) wrote: > > >=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 belong to the Mobile Network = Prefix > >> owned by the Mobile Router. > >> > > > > > > Note that in the reqs I proposed yesterday, I first thought I would = copy > > that text and then I realized it was a bit restrictive and I = replaced by > > topological correctness for the inner packet. What do you think? I = believe > > this should be changed in the security section as well. >=20 > hmm.. either way is fine with me. but dont you think "topological > correctness" is vague compared to what is there currently? >=20 In the simple case it should end up being the same.=20 But take the case where you run a tier routing protocol over the tunnel = that has its own trust model. You can not refer to the prefixes obtained = that way as MNPs. The routing table can be seen as the repository for all prefixes that = are authorized from a direction, whoever installs the routes. Pascal From exim@www1.ietf.org Thu Dec 4 02:29:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14110 for ; Thu, 4 Dec 2003 02:29: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 1ARnvI-0004QH-Rm for nemo-archive@odin.ietf.org; Thu, 04 Dec 2003 02:29:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB47TGQr017000 for nemo-archive@odin.ietf.org; Thu, 4 Dec 2003 02:29:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARnvI-0004Q7-2R for nemo-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 02:29: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 CAA14090 for ; Thu, 4 Dec 2003 02:29:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARnvE-0003X5-00 for nemo-web-archive@ietf.org; Thu, 04 Dec 2003 02:29:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARnvE-0003X2-00 for nemo-web-archive@ietf.org; Thu, 04 Dec 2003 02:29:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARnv5-0004On-4o; Thu, 04 Dec 2003 02:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARnuP-0004NR-3O for nemo@optimus.ietf.org; Thu, 04 Dec 2003 02:28: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 CAA14067 for ; Thu, 4 Dec 2003 02:28:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARnuL-0003Wa-00 for nemo@ietf.org; Thu, 04 Dec 2003 02:28:17 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARnuK-0003WL-00 for nemo@ietf.org; Thu, 04 Dec 2003 02:28:16 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 04 Dec 2003 08:24:28 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB47R4Os010136; Thu, 4 Dec 2003 08:27:04 +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, 4 Dec 2003 07:27:16 +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] Editorial comments from Jari Arkko Date: Thu, 4 Dec 2003 07:27:16 -0000 Message-ID: Thread-Topic: [nemo] Editorial comments from Jari Arkko Thread-Index: AcO5xujK8t2HTdJNRzmCEc6DRN+PBAAb6y+w From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: "Jari Arkko" , X-OriginalArrivalTime: 04 Dec 2003 07:27:16.0912 (UTC) FILETIME=[0B6CCB00:01C3BA38] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mercredi 3 d=E9cembre 2003 19:01 > To: Pascal Thubert (pthubert) > Cc: Jari Arkko; nemo@ietf.org > Subject: Re: [nemo] Editorial comments from Jari Arkko >=20 > Pascal Thubert (pthubert) wrote: > > >=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 belong to the Mobile Network = Prefix > >> owned by the Mobile Router. > >> > > > > > > Note that in the reqs I proposed yesterday, I first thought I would = copy > > that text and then I realized it was a bit restrictive and I = replaced by > > topological correctness for the inner packet. What do you think? I = believe > > this should be changed in the security section as well. >=20 > hmm.. either way is fine with me. but dont you think "topological > correctness" is vague compared to what is there currently? >=20 In the simple case it should end up being the same.=20 But take the case where you run a tier routing protocol over the tunnel = that has its own trust model. You can not refer to the prefixes obtained = that way as MNPs. The routing table can be seen as the repository for all prefixes that = are authorized from a direction, whoever installs the routes. Pascal From nemo-admin@ietf.org Thu Dec 4 02:32:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14332 for ; Thu, 4 Dec 2003 02:32: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 1ARnxx-0004k1-CF; Thu, 04 Dec 2003 02:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARnxM-0004hi-Lm for nemo@optimus.ietf.org; Thu, 04 Dec 2003 02:31: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 CAA14301 for ; Thu, 4 Dec 2003 02:31:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARnxI-0003fP-00 for nemo@ietf.org; Thu, 04 Dec 2003 02:31:20 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARnxI-0003et-00 for nemo@ietf.org; Thu, 04 Dec 2003 02:31:20 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 04 Dec 2003 08:28:00 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB47Ua4v010775; Thu, 4 Dec 2003 08:30:36 +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, 4 Dec 2003 07:30:49 +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] Closing Issue 16 Date: Thu, 4 Dec 2003 07:30:48 -0000 Message-ID: Thread-Topic: [nemo] Closing Issue 16 Thread-Index: AcO5yD2zzrxsSIiuSs+JDIbUIrG+dQAbz1Jg From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: "Jari Arkko" , X-OriginalArrivalTime: 04 Dec 2003 07:30:49.0429 (UTC) FILETIME=[8A185050:01C3BA38] 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 MIPv6 did not set a direction for this. Because it does not need it for = itself. It appears it would if it is seen as a precursor. If it's not in = MIPv6, then the first RFC coming next sets the direction. But taking the = wrong direction will make the future painful. I'd sure appreciate Jari's = advice. Pascal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mercredi 3 d=E9cembre 2003 19:10 > To: Pascal Thubert (pthubert) > Cc: Jari Arkko; nemo@ietf.org > Subject: Re: [nemo] Closing Issue 16 >=20 > Pascal Thubert (pthubert) wrote: >=20 > > > > Say we add more and more features like basic nemo and now HAs = support a number of those > features. The request may end up like an SQL query depending on what = the requester wants or > is willing to accept if the most wanted is not available. Wouldn't it = be better to list > everything and let the requester sort it out based on its own = preference? >=20 > you maybe right. but NEMO basic support spec the place to do it? >=20 > Vijay From exim@www1.ietf.org Thu Dec 4 02:32:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14352 for ; Thu, 4 Dec 2003 02:32: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 1ARny0-0004mT-0a for nemo-archive@odin.ietf.org; Thu, 04 Dec 2003 02:32:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB47W3hs018371 for nemo-archive@odin.ietf.org; Thu, 4 Dec 2003 02:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARnxz-0004kw-CN for nemo-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 02:32: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 CAA14326 for ; Thu, 4 Dec 2003 02:31:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARnxv-0003hO-00 for nemo-web-archive@ietf.org; Thu, 04 Dec 2003 02:31:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARnxv-0003hL-00 for nemo-web-archive@ietf.org; Thu, 04 Dec 2003 02:31:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARnxx-0004k1-CF; Thu, 04 Dec 2003 02:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARnxM-0004hi-Lm for nemo@optimus.ietf.org; Thu, 04 Dec 2003 02:31: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 CAA14301 for ; Thu, 4 Dec 2003 02:31:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARnxI-0003fP-00 for nemo@ietf.org; Thu, 04 Dec 2003 02:31:20 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ARnxI-0003et-00 for nemo@ietf.org; Thu, 04 Dec 2003 02:31:20 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 04 Dec 2003 08:28:00 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB47Ua4v010775; Thu, 4 Dec 2003 08:30:36 +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, 4 Dec 2003 07:30:49 +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] Closing Issue 16 Date: Thu, 4 Dec 2003 07:30:48 -0000 Message-ID: Thread-Topic: [nemo] Closing Issue 16 Thread-Index: AcO5yD2zzrxsSIiuSs+JDIbUIrG+dQAbz1Jg From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: "Jari Arkko" , X-OriginalArrivalTime: 04 Dec 2003 07:30:49.0429 (UTC) FILETIME=[8A185050:01C3BA38] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable MIPv6 did not set a direction for this. Because it does not need it for = itself. It appears it would if it is seen as a precursor. If it's not in = MIPv6, then the first RFC coming next sets the direction. But taking the = wrong direction will make the future painful. I'd sure appreciate Jari's = advice. Pascal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mercredi 3 d=E9cembre 2003 19:10 > To: Pascal Thubert (pthubert) > Cc: Jari Arkko; nemo@ietf.org > Subject: Re: [nemo] Closing Issue 16 >=20 > Pascal Thubert (pthubert) wrote: >=20 > > > > Say we add more and more features like basic nemo and now HAs = support a number of those > features. The request may end up like an SQL query depending on what = the requester wants or > is willing to accept if the most wanted is not available. Wouldn't it = be better to list > everything and let the requester sort it out based on its own = preference? >=20 > you maybe right. but NEMO basic support spec the place to do it? >=20 > Vijay From nemo-admin@ietf.org Thu Dec 4 13:51:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08426 for ; Thu, 4 Dec 2003 13:51: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 1ARyZ4-00028H-Tg; Thu, 04 Dec 2003 13: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 1ARyJi-0000xx-5m for nemo@optimus.ietf.org; Thu, 04 Dec 2003 13:35: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 NAA07108 for ; Thu, 4 Dec 2003 13:24:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARy9K-0005t7-00 for nemo@ietf.org; Thu, 04 Dec 2003 13:24:26 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARy9I-0005t4-00 for nemo@ietf.org; Thu, 04 Dec 2003 13:24:25 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB4ILe921203; Thu, 4 Dec 2003 10:21:40 -0800 X-mProtect: <200312041821> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTUTjoP; Thu, 04 Dec 2003 10:21:39 PST Message-ID: <3FCF7C81.5070609@iprg.nokia.com> Date: Thu, 04 Dec 2003 10:27:13 -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: Jari Arkko , nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko 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: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >>>> 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 belong to the Mobile Network Prefix >>>> owned by the Mobile Router. >>>> >>> >>> >>>Note that in the reqs I proposed yesterday, I first thought I would copy >>>that text and then I realized it was a bit restrictive and I replaced by >>>topological correctness for the inner packet. What do you think? I believe >>>this should be changed in the security section as well. >> >>hmm.. either way is fine with me. but dont you think "topological >>correctness" is vague compared to what is there currently? >> > > In the simple case it should end up being the same. > > But take the case where you run a tier routing protocol over the tunnel that has its own trust model. You can not refer to the prefixes obtained that way as MNPs. > > The routing table can be seen as the repository for all prefixes that are authorized from a direction, whoever installs the routes. how about this? 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. Vijay From exim@www1.ietf.org Thu Dec 4 13:51:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08455 for ; Thu, 4 Dec 2003 13:51: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 1ARyZE-0002Bl-0b for nemo-archive@odin.ietf.org; Thu, 04 Dec 2003 13:51:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4IpB3E008409 for nemo-archive@odin.ietf.org; Thu, 4 Dec 2003 13:51:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyZD-0002BY-Sa for nemo-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 13:51:11 -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 NAA08360 for ; Thu, 4 Dec 2003 13:50:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARyZB-0006P1-00 for nemo-web-archive@ietf.org; Thu, 04 Dec 2003 13:51:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARyZB-0006Ov-00 for nemo-web-archive@ietf.org; Thu, 04 Dec 2003 13:51:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyZ4-00028H-Tg; Thu, 04 Dec 2003 13: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 1ARyJi-0000xx-5m for nemo@optimus.ietf.org; Thu, 04 Dec 2003 13:35: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 NAA07108 for ; Thu, 4 Dec 2003 13:24:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARy9K-0005t7-00 for nemo@ietf.org; Thu, 04 Dec 2003 13:24:26 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARy9I-0005t4-00 for nemo@ietf.org; Thu, 04 Dec 2003 13:24:25 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB4ILe921203; Thu, 4 Dec 2003 10:21:40 -0800 X-mProtect: <200312041821> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTUTjoP; Thu, 04 Dec 2003 10:21:39 PST Message-ID: <3FCF7C81.5070609@iprg.nokia.com> Date: Thu, 04 Dec 2003 10:27:13 -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: Jari Arkko , nemo@ietf.org Subject: Re: [nemo] Editorial comments from Jari Arkko 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >>>> 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 belong to the Mobile Network Prefix >>>> owned by the Mobile Router. >>>> >>> >>> >>>Note that in the reqs I proposed yesterday, I first thought I would copy >>>that text and then I realized it was a bit restrictive and I replaced by >>>topological correctness for the inner packet. What do you think? I believe >>>this should be changed in the security section as well. >> >>hmm.. either way is fine with me. but dont you think "topological >>correctness" is vague compared to what is there currently? >> > > In the simple case it should end up being the same. > > But take the case where you run a tier routing protocol over the tunnel that has its own trust model. You can not refer to the prefixes obtained that way as MNPs. > > The routing table can be seen as the repository for all prefixes that are authorized from a direction, whoever installs the routes. how about this? 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. Vijay From exim@www1.ietf.org Thu Dec 4 13:51:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08472 for ; Thu, 4 Dec 2003 13:51: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 1ARyZG-0002Ed-PL for nemo-archive@odin.ietf.org; Thu, 04 Dec 2003 13:51:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4IpEGg008585 for nemo-archive@odin.ietf.org; Thu, 4 Dec 2003 13:51:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyZG-0002EO-Ji for nemo-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 13:51: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 NAA08366 for ; Thu, 4 Dec 2003 13:50:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARyZB-0006Oy-00 for nemo-web-archive@ietf.org; Thu, 04 Dec 2003 13:51:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARyZB-0006Ou-00 for nemo-web-archive@ietf.org; Thu, 04 Dec 2003 13:51:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyZ6-000291-3j; Thu, 04 Dec 2003 13:51:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyJf-0000xx-JQ for nemo@optimus.ietf.org; Thu, 04 Dec 2003 13:35:08 -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 NAA07152 for ; Thu, 4 Dec 2003 13:24:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARy9z-0005tr-00 for nemo@ietf.org; Thu, 04 Dec 2003 13:25:07 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARy9y-0005tH-00 for nemo@ietf.org; Thu, 04 Dec 2003 13:25:06 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB4IMSl21625; Thu, 4 Dec 2003 10:22:28 -0800 X-mProtect: <200312041822> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdvBcB30; Thu, 04 Dec 2003 10:22:26 PST Message-ID: <3FCF7CB0.5010000@iprg.nokia.com> Date: Thu, 04 Dec 2003 10:28:00 -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: Jari Arkko , nemo@ietf.org Subject: Re: [nemo] Closing Issue 16 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit you should bring this up in the MIP6 mailing list. Pascal Thubert (pthubert) wrote: > MIPv6 did not set a direction for this. Because it does not need it for itself. It appears it would if it is seen as a precursor. If it's not in MIPv6, then the first RFC coming next sets the direction. But taking the wrong direction will make the future painful. I'd sure appreciate Jari's advice. > > Pascal > > >>-----Original Message----- >>From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] >>Sent: mercredi 3 dicembre 2003 19:10 >>To: Pascal Thubert (pthubert) >>Cc: Jari Arkko; nemo@ietf.org >>Subject: Re: [nemo] Closing Issue 16 >> >>Pascal Thubert (pthubert) wrote: >> >> >>>Say we add more and more features like basic nemo and now HAs support a number of those >> >>features. The request may end up like an SQL query depending on what the requester wants or >>is willing to accept if the most wanted is not available. Wouldn't it be better to list >>everything and let the requester sort it out based on its own preference? >> >>you maybe right. but NEMO basic support spec the place to do it? >> >>Vijay > > From nemo-admin@ietf.org Thu Dec 4 14:45:00 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08427 for ; Thu, 4 Dec 2003 13:51: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 1ARyZ6-000291-3j; Thu, 04 Dec 2003 13:51:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyJf-0000xx-JQ for nemo@optimus.ietf.org; Thu, 04 Dec 2003 13:35:08 -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 NAA07152 for ; Thu, 4 Dec 2003 13:24:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARy9z-0005tr-00 for nemo@ietf.org; Thu, 04 Dec 2003 13:25:07 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ARy9y-0005tH-00 for nemo@ietf.org; Thu, 04 Dec 2003 13:25:06 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB4IMSl21625; Thu, 4 Dec 2003 10:22:28 -0800 X-mProtect: <200312041822> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdvBcB30; Thu, 04 Dec 2003 10:22:26 PST Message-ID: <3FCF7CB0.5010000@iprg.nokia.com> Date: Thu, 04 Dec 2003 10:28:00 -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: Jari Arkko , nemo@ietf.org Subject: Re: [nemo] Closing Issue 16 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit you should bring this up in the MIP6 mailing list. Pascal Thubert (pthubert) wrote: > MIPv6 did not set a direction for this. Because it does not need it for itself. It appears it would if it is seen as a precursor. If it's not in MIPv6, then the first RFC coming next sets the direction. But taking the wrong direction will make the future painful. I'd sure appreciate Jari's advice. > > Pascal > > >>-----Original Message----- >>From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] >>Sent: mercredi 3 dicembre 2003 19:10 >>To: Pascal Thubert (pthubert) >>Cc: Jari Arkko; nemo@ietf.org >>Subject: Re: [nemo] Closing Issue 16 >> >>Pascal Thubert (pthubert) wrote: >> >> >>>Say we add more and more features like basic nemo and now HAs support a number of those >> >>features. The request may end up like an SQL query depending on what the requester wants or >>is willing to accept if the most wanted is not available. Wouldn't it be better to list >>everything and let the requester sort it out based on its own preference? >> >>you maybe right. but NEMO basic support spec the place to do it? >> >>Vijay > > From nemo-admin@ietf.org Thu Dec 4 16:32:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16861 for ; Thu, 4 Dec 2003 16:32:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS14q-0001v1-RP; Thu, 04 Dec 2003 16:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS144-0001tY-EP for nemo@optimus.ietf.org; Thu, 04 Dec 2003 16:31: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 QAA16407 for ; Thu, 4 Dec 2003 16:30:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS142-000125-00 for nemo@ietf.org; Thu, 04 Dec 2003 16:31:10 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AS141-00011Q-00 for nemo@ietf.org; Thu, 04 Dec 2003 16:31:09 -0500 Received: from [64.36.73.246] (wideload.kniveton.com [64.36.73.246]) by multihop.net (8.12.10/8.12.10) with ESMTP id hB4LVBr4040626 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 4 Dec 2003 13:31:11 -0800 (PST) (envelope-from tj@kniveton.com) In-Reply-To: <3FCE21AD.1000501@iprg.nokia.com> References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> <3FCD5847.1010809@kniveton.com> <3FCD5AC2.3060503@iprg.nokia.com> <3FCD823A.706 <3FCE21AD.1000501@iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--75534260; protocol="application/pkcs7-signature" Message-Id: <28EC7587-26A1-11D8-AAE8-000A95DA08F2@kniveton.com> Cc: nemo@ietf.org From: "T.J. Kniveton" Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic spec) Date: Thu, 4 Dec 2003 13:31:02 -0800 To: Vijay Devarapalli X-Mailer: Apple Mail (2.606) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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-4--75534260 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Dec 3, 2003, at 9:47 AM, Vijay Devarapalli wrote: > I see one use for it. a router can attach to a new link and > announce itself through a router advertisement. we dont have > any other message which can do this. not all routers run a > routing protocol. I expect packets coming to the home link would be routed to the MR by the HA. > > but we dont have a use for this yet, currently. > > but then again, I dont see a reason to prohibit this when the > MR is on the home link. OK.. it just seems like a weird thing to do. :) > > Vijay > > T.J. Kniveton wrote: >> Vijay Devarapalli wrote: >>> a router by its nature sends out router advertisements. there is >>> no spec prohibiting it from sending out router advertisements on >>> any of its interfaces. the NEMO basic spec restricts the mobile >>> router to not send router advertisements on its egress interface >>> when it is attached to a visited link. when it returns to a home >>> link, we are saying it MAY start sending again. >> My understand about router advertisements is that they are used for >> routers to advertise their existence on links they serve, and give >> information about the prefixes they will serve. >> The MR does not serve any nodes on the egress interface. Therefore it >> is just like a HOST on that link. The MR should ever, only, advertise >> itself as a router on a link where it acts as a router -- the mobile >> network. >>> >>> but we have to prevent hosts on the home link from configuring >>> the mobile router as a default router. so we say the router >>> lifetime SHOULD be set to 0. >> Which is equivalent to not sending router advertisements. After all, >> it's not going to include any prefix options in the RA, is it?? >>> >>> >>> Vijay >>> > > --Apple-Mail-4--75534260 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 ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTIwNDIxMzEw M1owIwYJKoZIhvcNAQkEMRYEFN60OgCvdld7HM8XoIgFokw12LigMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgBHrN/v29WTt9qgJybyiPA3NuXqU1NmeS+UinZ5lIjhq c8ZHDwOaMh0mgSyaEUuuYIUZGcD5Gq3yyrihkZHqEpKw1kMmhQCbURgqMzFdXy/womiaPPU8Iazt usdg4f4EPUNwnxd72hm8uCCj38ytGfUzP1uttlQxgKVRInNNq1DaAAAAAAAA --Apple-Mail-4--75534260-- From exim@www1.ietf.org Thu Dec 4 16:32:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16894 for ; Thu, 4 Dec 2003 16:32: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 1AS14x-0001w1-8Z for nemo-archive@odin.ietf.org; Thu, 04 Dec 2003 16:32:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4LW7sA007437 for nemo-archive@odin.ietf.org; Thu, 4 Dec 2003 16:32:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS14x-0001vs-3V for nemo-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 16:32:07 -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 QAA16622 for ; Thu, 4 Dec 2003 16:31:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS14v-00019Y-00 for nemo-web-archive@ietf.org; Thu, 04 Dec 2003 16:32:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AS14u-00019Q-00 for nemo-web-archive@ietf.org; Thu, 04 Dec 2003 16:32:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS14q-0001v1-RP; Thu, 04 Dec 2003 16:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS144-0001tY-EP for nemo@optimus.ietf.org; Thu, 04 Dec 2003 16:31: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 QAA16407 for ; Thu, 4 Dec 2003 16:30:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS142-000125-00 for nemo@ietf.org; Thu, 04 Dec 2003 16:31:10 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AS141-00011Q-00 for nemo@ietf.org; Thu, 04 Dec 2003 16:31:09 -0500 Received: from [64.36.73.246] (wideload.kniveton.com [64.36.73.246]) by multihop.net (8.12.10/8.12.10) with ESMTP id hB4LVBr4040626 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 4 Dec 2003 13:31:11 -0800 (PST) (envelope-from tj@kniveton.com) In-Reply-To: <3FCE21AD.1000501@iprg.nokia.com> References: <3FCBB391.6060909@kolumbus.fi> <3FCBC8B5.6030206@iprg.nokia.com> <3FCD581E.3030606@iprg.nokia.com> <3FCD5847.1010809@kniveton.com> <3FCD5AC2.3060503@iprg.nokia.com> <3FCD823A.706 <3FCE21AD.1000501@iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--75534260; protocol="application/pkcs7-signature" Message-Id: <28EC7587-26A1-11D8-AAE8-000A95DA08F2@kniveton.com> Cc: nemo@ietf.org From: "T.J. Kniveton" Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic spec) Date: Thu, 4 Dec 2003 13:31:02 -0800 To: Vijay Devarapalli X-Mailer: Apple Mail (2.606) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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-4--75534260 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Dec 3, 2003, at 9:47 AM, Vijay Devarapalli wrote: > I see one use for it. a router can attach to a new link and > announce itself through a router advertisement. we dont have > any other message which can do this. not all routers run a > routing protocol. I expect packets coming to the home link would be routed to the MR by the HA. > > but we dont have a use for this yet, currently. > > but then again, I dont see a reason to prohibit this when the > MR is on the home link. OK.. it just seems like a weird thing to do. :) > > Vijay > > T.J. Kniveton wrote: >> Vijay Devarapalli wrote: >>> a router by its nature sends out router advertisements. there is >>> no spec prohibiting it from sending out router advertisements on >>> any of its interfaces. the NEMO basic spec restricts the mobile >>> router to not send router advertisements on its egress interface >>> when it is attached to a visited link. when it returns to a home >>> link, we are saying it MAY start sending again. >> My understand about router advertisements is that they are used for >> routers to advertise their existence on links they serve, and give >> information about the prefixes they will serve. >> The MR does not serve any nodes on the egress interface. Therefore it >> is just like a HOST on that link. The MR should ever, only, advertise >> itself as a router on a link where it acts as a router -- the mobile >> network. >>> >>> but we have to prevent hosts on the home link from configuring >>> the mobile router as a default router. so we say the router >>> lifetime SHOULD be set to 0. >> Which is equivalent to not sending router advertisements. After all, >> it's not going to include any prefix options in the RA, is it?? >>> >>> >>> Vijay >>> > > --Apple-Mail-4--75534260 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 ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTIwNDIxMzEw M1owIwYJKoZIhvcNAQkEMRYEFN60OgCvdld7HM8XoIgFokw12LigMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgBHrN/v29WTt9qgJybyiPA3NuXqU1NmeS+UinZ5lIjhq c8ZHDwOaMh0mgSyaEUuuYIUZGcD5Gq3yyrihkZHqEpKw1kMmhQCbURgqMzFdXy/womiaPPU8Iazt usdg4f4EPUNwnxd72hm8uCCj38ytGfUzP1uttlQxgKVRInNNq1DaAAAAAAAA --Apple-Mail-4--75534260-- From nemo-admin@ietf.org Fri Dec 5 04:48:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28212 for ; Fri, 5 Dec 2003 04:48: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 1ASCZ8-0004k1-2w; Fri, 05 Dec 2003 04:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS4Xn-0002qy-Ev for nemo@optimus.ietf.org; Thu, 04 Dec 2003 20:14:07 -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 UAA29497 for ; Thu, 4 Dec 2003 20:13:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS4Xl-0006Ed-00 for nemo@ietf.org; Thu, 04 Dec 2003 20:14:05 -0500 Received: from letters.cs.ucsb.edu ([128.111.41.13]) by ietf-mx with esmtp (Exim 4.12) id 1AS4Xk-0006EU-00 for nemo@ietf.org; Thu, 04 Dec 2003 20:14:04 -0500 Received: from yosemite.cs.ucsb.edu (yosemite [128.111.40.103]) by letters.cs.ucsb.edu (8.11.7+Sun/8.11.7) with ESMTP id hB51E3214140 for ; Thu, 4 Dec 2003 17:14:03 -0800 (PST) From: Elizabeth Belding-Royer To: nemo@ietf.org Content-Type: text/plain Message-Id: <1070586843.13966.20.camel@yosemite.cs.ucsb.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 04 Dec 2003 17:14:04 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] MobiHoc CFP Deadline Reminder Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 Reminder: The paper submission deadline is December 11, 2003, only a week away!!! ====================================================================== CALL FOR PAPERS The Fifth ACM International Symposium on Mobile Ad Hoc Networking and Computing MobiHoc 2004 www.sigmobile.org/mobihoc/2004/ May 24-26, 2004 Tokyo, Japan MobiHoc 2004 is the fifth of a series of annual meetings sponsored by ACM SIGMOBILE, focusing on the latest research in the rapidly growing area of mobile ad hoc networking and computing. The first MobiHoc was held in 2000 in Boston, Massachusetts, as a workshop affiliated with the MobiCom conference also sponsored by SIGMOBILE. Since then, MobiHoc has become a separate symposium, held in 2001 at Long Beach, California, in 2002 at Lausanne, Switzerland, in 2003 at Annapolis, Maryland, and now in 2004 at Tokyo, Japan. PAPERS: Technical papers describing original, previously unpublished research, not currently under review by another conference or journal, are solicited. In general this symposium is interested in papers that address networking or computing problems in the context of mobile and wireless ad hoc networks, ad hoc computing systems, and sensor networks, with the focus being on issues above the physical layer. Specific topics of interest include the following: * Routing protocols (unicast, multicast, geocast, content-based, etc.) * Media access techniques * Transport-layer issues * Hardware and software platforms, systems, and testbeds * Applications for ad hoc networks * Power-aware, low-power, and energy-efficient designs * Quality-of-service issues * Security and fault tolerance issues * Self-configuration in ad hoc networks * Processing and fusion of data in sensor networks * Location discovery and management * Timing synchronization * Distributed algorithms for ad hoc networks * Biologically inspired mechanisms * Ad hoc networks of autonomous intelligent systems * Analytic methods and modeling for performance evaluation * Cross-layer interactions, including between higher and physical layers * Other ad hoc networking and computing topics above the physical layer Please consult the program co-chairs Charlie Perkins and Leandros Tassiulas if you are uncertain whether your paper falls within the scope of the symposium. SUBMISSION INSTRUCTIONS: All submissions will be handled electronically and must be in PDF or PostScript format. Papers must not exceed 15 pages (US "Letter" size, 8.5 x 11 inches) including text, figures and references. The font size must be at least 10 points. Accepted papers will be published in the symposium proceedings. We will adopt a double-blind process for paper review, where the identities of the authors are withheld from the reviewers. Authors' names and their affiliations must not be revealed or mentioned anywhere in the paper or in the PDF or PostScript file. Submitted papers should describe original research, not published and not currently under review for any other conference or journal. Papers not following these guidelines will be summarily rejected. To submit a paper, please refer to the paper submission link at the conference website, www.sigmobile.org/mobihoc/2004/. Questions about the submission process should be directed to the Program Co-Chairs. TUTORIALS: Proposals for tutorials are solicited. Evaluation of proposals will be based on the expertise and experience of the instructors, and on the relevance of the subject matter for the symposium. Potential instructors are requested to submit a tutorial proposal of at most 5 pages, including a biographical sketch, to the Tutorial Chair, Maria Papadopouli by the paper submission deadline below. IMPORTANT DATES: Paper Submission Deadline December 11, 2003 Notification of Acceptance March 10, 2004 Camera-ready version Due March 25, 2004 Please visit the MobiHoc 2004 Home Page at www.sigmobile.org/mobihoc/2004/, or send email to the General Chair, Jun Murai or to for any questions or for more information about the symposium. From exim@www1.ietf.org Fri Dec 5 04:48:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28227 for ; Fri, 5 Dec 2003 04:48: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 1ASCZG-0004lc-8l for nemo-archive@odin.ietf.org; Fri, 05 Dec 2003 04:48:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB59m9tO018318 for nemo-archive@odin.ietf.org; Fri, 5 Dec 2003 04:48:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASCZE-0004lN-RM for nemo-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 04:48: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 EAA28180 for ; Fri, 5 Dec 2003 04:47:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASCZB-00061D-00 for nemo-web-archive@ietf.org; Fri, 05 Dec 2003 04:48:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASCZB-00061A-00 for nemo-web-archive@ietf.org; Fri, 05 Dec 2003 04:48:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASCZ8-0004k1-2w; Fri, 05 Dec 2003 04:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS4Xn-0002qy-Ev for nemo@optimus.ietf.org; Thu, 04 Dec 2003 20:14:07 -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 UAA29497 for ; Thu, 4 Dec 2003 20:13:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS4Xl-0006Ed-00 for nemo@ietf.org; Thu, 04 Dec 2003 20:14:05 -0500 Received: from letters.cs.ucsb.edu ([128.111.41.13]) by ietf-mx with esmtp (Exim 4.12) id 1AS4Xk-0006EU-00 for nemo@ietf.org; Thu, 04 Dec 2003 20:14:04 -0500 Received: from yosemite.cs.ucsb.edu (yosemite [128.111.40.103]) by letters.cs.ucsb.edu (8.11.7+Sun/8.11.7) with ESMTP id hB51E3214140 for ; Thu, 4 Dec 2003 17:14:03 -0800 (PST) From: Elizabeth Belding-Royer To: nemo@ietf.org Content-Type: text/plain Message-Id: <1070586843.13966.20.camel@yosemite.cs.ucsb.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 04 Dec 2003 17:14:04 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] MobiHoc CFP Deadline Reminder Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Reminder: The paper submission deadline is December 11, 2003, only a week away!!! ====================================================================== CALL FOR PAPERS The Fifth ACM International Symposium on Mobile Ad Hoc Networking and Computing MobiHoc 2004 www.sigmobile.org/mobihoc/2004/ May 24-26, 2004 Tokyo, Japan MobiHoc 2004 is the fifth of a series of annual meetings sponsored by ACM SIGMOBILE, focusing on the latest research in the rapidly growing area of mobile ad hoc networking and computing. The first MobiHoc was held in 2000 in Boston, Massachusetts, as a workshop affiliated with the MobiCom conference also sponsored by SIGMOBILE. Since then, MobiHoc has become a separate symposium, held in 2001 at Long Beach, California, in 2002 at Lausanne, Switzerland, in 2003 at Annapolis, Maryland, and now in 2004 at Tokyo, Japan. PAPERS: Technical papers describing original, previously unpublished research, not currently under review by another conference or journal, are solicited. In general this symposium is interested in papers that address networking or computing problems in the context of mobile and wireless ad hoc networks, ad hoc computing systems, and sensor networks, with the focus being on issues above the physical layer. Specific topics of interest include the following: * Routing protocols (unicast, multicast, geocast, content-based, etc.) * Media access techniques * Transport-layer issues * Hardware and software platforms, systems, and testbeds * Applications for ad hoc networks * Power-aware, low-power, and energy-efficient designs * Quality-of-service issues * Security and fault tolerance issues * Self-configuration in ad hoc networks * Processing and fusion of data in sensor networks * Location discovery and management * Timing synchronization * Distributed algorithms for ad hoc networks * Biologically inspired mechanisms * Ad hoc networks of autonomous intelligent systems * Analytic methods and modeling for performance evaluation * Cross-layer interactions, including between higher and physical layers * Other ad hoc networking and computing topics above the physical layer Please consult the program co-chairs Charlie Perkins and Leandros Tassiulas if you are uncertain whether your paper falls within the scope of the symposium. SUBMISSION INSTRUCTIONS: All submissions will be handled electronically and must be in PDF or PostScript format. Papers must not exceed 15 pages (US "Letter" size, 8.5 x 11 inches) including text, figures and references. The font size must be at least 10 points. Accepted papers will be published in the symposium proceedings. We will adopt a double-blind process for paper review, where the identities of the authors are withheld from the reviewers. Authors' names and their affiliations must not be revealed or mentioned anywhere in the paper or in the PDF or PostScript file. Submitted papers should describe original research, not published and not currently under review for any other conference or journal. Papers not following these guidelines will be summarily rejected. To submit a paper, please refer to the paper submission link at the conference website, www.sigmobile.org/mobihoc/2004/. Questions about the submission process should be directed to the Program Co-Chairs. TUTORIALS: Proposals for tutorials are solicited. Evaluation of proposals will be based on the expertise and experience of the instructors, and on the relevance of the subject matter for the symposium. Potential instructors are requested to submit a tutorial proposal of at most 5 pages, including a biographical sketch, to the Tutorial Chair, Maria Papadopouli by the paper submission deadline below. IMPORTANT DATES: Paper Submission Deadline December 11, 2003 Notification of Acceptance March 10, 2004 Camera-ready version Due March 25, 2004 Please visit the MobiHoc 2004 Home Page at www.sigmobile.org/mobihoc/2004/, or send email to the General Chair, Jun Murai or to for any questions or for more information about the symposium. From nemo-admin@ietf.org Fri Dec 5 04:54:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28386 for ; Fri, 5 Dec 2003 04:54: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 1ASCev-0004y5-V0; Fri, 05 Dec 2003 04: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 1ASCe5-0004xL-KE for nemo@optimus.ietf.org; Fri, 05 Dec 2003 04:53: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 EAA28355 for ; Fri, 5 Dec 2003 04:52:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASCe2-00065f-00 for nemo@ietf.org; Fri, 05 Dec 2003 04:53:06 -0500 Received: from roura.ac.upc.es ([147.83.33.10]) by ietf-mx with esmtp (Exim 4.12) id 1ASCe1-00065N-00 for nemo@ietf.org; Fri, 05 Dec 2003 04:53:05 -0500 Received: from rogent.ac.upc.es (rogent.ac.upc.es [147.83.31.7]) by roura.ac.upc.es (8.12.8/8.12.8) with ESMTP id hB59qRJA016045 for ; Fri, 5 Dec 2003 10:52:27 +0100 (MET) Received: (from ew2004@localhost) by rogent.ac.upc.es (8.12.8/8.12.8) id hB59qR7p028225 for nemo@ietf.org; Fri, 5 Dec 2003 10:52:27 +0100 (MET) Date: Fri, 5 Dec 2003 10:52:27 +0100 From: Conferencia ew2004 To: nemo@ietf.org Message-ID: <20031205095227.GA28215@ac.upc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [nemo] EW2004 Call For Participation Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Dear Colleague, Please accept our apologies if you receive multiple copies of this e-mail. We would appreciate your assistance in distributing this call for participation to your colleagues. You are cordially invited to attend The 5th European Wireless Conference (EW2004) Mobile and Wireless Systems beyond 3G to be held in Barcelona, Spain in February 24-27, 2004. Registration for EW2004 is now open. Early registration is available until January 10th, 2004. All the details about the conference can be found at: http://www.ac.upc.es/EW2004 (look at links: "Conference Program", "Tutorials" and "Conference and tutorial Registration") Looking forward to see you in Barcelona, EW2004 organizing committee. From exim@www1.ietf.org Fri Dec 5 04:54:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28407 for ; Fri, 5 Dec 2003 04:54: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 1ASCf0-00050W-8G for nemo-archive@odin.ietf.org; Fri, 05 Dec 2003 04:54:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB59s61w019164 for nemo-archive@odin.ietf.org; Fri, 5 Dec 2003 04:54:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASCey-0004z0-BT for nemo-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 04:54: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 EAA28369 for ; Fri, 5 Dec 2003 04:53:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASCev-000666-00 for nemo-web-archive@ietf.org; Fri, 05 Dec 2003 04:54:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASCeu-000663-00 for nemo-web-archive@ietf.org; Fri, 05 Dec 2003 04:54:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASCev-0004y5-V0; Fri, 05 Dec 2003 04: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 1ASCe5-0004xL-KE for nemo@optimus.ietf.org; Fri, 05 Dec 2003 04:53: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 EAA28355 for ; Fri, 5 Dec 2003 04:52:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASCe2-00065f-00 for nemo@ietf.org; Fri, 05 Dec 2003 04:53:06 -0500 Received: from roura.ac.upc.es ([147.83.33.10]) by ietf-mx with esmtp (Exim 4.12) id 1ASCe1-00065N-00 for nemo@ietf.org; Fri, 05 Dec 2003 04:53:05 -0500 Received: from rogent.ac.upc.es (rogent.ac.upc.es [147.83.31.7]) by roura.ac.upc.es (8.12.8/8.12.8) with ESMTP id hB59qRJA016045 for ; Fri, 5 Dec 2003 10:52:27 +0100 (MET) Received: (from ew2004@localhost) by rogent.ac.upc.es (8.12.8/8.12.8) id hB59qR7p028225 for nemo@ietf.org; Fri, 5 Dec 2003 10:52:27 +0100 (MET) Date: Fri, 5 Dec 2003 10:52:27 +0100 From: Conferencia ew2004 To: nemo@ietf.org Message-ID: <20031205095227.GA28215@ac.upc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [nemo] EW2004 Call For Participation Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Dear Colleague, Please accept our apologies if you receive multiple copies of this e-mail. We would appreciate your assistance in distributing this call for participation to your colleagues. You are cordially invited to attend The 5th European Wireless Conference (EW2004) Mobile and Wireless Systems beyond 3G to be held in Barcelona, Spain in February 24-27, 2004. Registration for EW2004 is now open. Early registration is available until January 10th, 2004. All the details about the conference can be found at: http://www.ac.upc.es/EW2004 (look at links: "Conference Program", "Tutorials" and "Conference and tutorial Registration") Looking forward to see you in Barcelona, EW2004 organizing committee. From nemo-admin@ietf.org Fri Dec 5 12:42:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15322 for ; Fri, 5 Dec 2003 12:42: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 1ASJxp-0005DZ-4H; Fri, 05 Dec 2003 12:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASJxn-0005D4-Of for nemo@optimus.ietf.org; Fri, 05 Dec 2003 12:41: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 MAA15311 for ; Fri, 5 Dec 2003 12:41:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASJxm-0005sU-00 for nemo@ietf.org; Fri, 05 Dec 2003 12:41:58 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ASJxl-0005s5-00 for nemo@ietf.org; Fri, 05 Dec 2003 12:41:57 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB5HfQv24746 for ; Fri, 5 Dec 2003 09:41:26 -0800 X-mProtect: <200312051741> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTONDUD; Fri, 05 Dec 2003 09:41:24 PST Message-ID: <3FD0C496.4030502@iprg.nokia.com> Date: Fri, 05 Dec 2003 09:47:02 -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: nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Issue 28 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 need some more comments/opinions on Issue 28 before I can call concensus and close the issue. the list of issues are at http://people.nokia.net/vijayd/nemo/issues.html what does everybody think? Vijay From exim@www1.ietf.org Fri Dec 5 12:42:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15337 for ; Fri, 5 Dec 2003 12:42:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASJxw-0005EZ-W3 for nemo-archive@odin.ietf.org; Fri, 05 Dec 2003 12:42:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5Hg8aL020113 for nemo-archive@odin.ietf.org; Fri, 5 Dec 2003 12:42:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASJxw-0005EK-RP for nemo-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 12:42:08 -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 MAA15319 for ; Fri, 5 Dec 2003 12:41:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASJxv-0005sk-00 for nemo-web-archive@ietf.org; Fri, 05 Dec 2003 12:42:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASJxu-0005sh-00 for nemo-web-archive@ietf.org; Fri, 05 Dec 2003 12:42:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASJxp-0005DZ-4H; Fri, 05 Dec 2003 12:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASJxn-0005D4-Of for nemo@optimus.ietf.org; Fri, 05 Dec 2003 12:41: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 MAA15311 for ; Fri, 5 Dec 2003 12:41:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASJxm-0005sU-00 for nemo@ietf.org; Fri, 05 Dec 2003 12:41:58 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ASJxl-0005s5-00 for nemo@ietf.org; Fri, 05 Dec 2003 12:41:57 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB5HfQv24746 for ; Fri, 5 Dec 2003 09:41:26 -0800 X-mProtect: <200312051741> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTONDUD; Fri, 05 Dec 2003 09:41:24 PST Message-ID: <3FD0C496.4030502@iprg.nokia.com> Date: Fri, 05 Dec 2003 09:47:02 -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: nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Issue 28 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I need some more comments/opinions on Issue 28 before I can call concensus and close the issue. the list of issues are at http://people.nokia.net/vijayd/nemo/issues.html what does everybody think? Vijay From nemo-admin@ietf.org Fri Dec 5 13:02:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16493 for ; Fri, 5 Dec 2003 13:02: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 1ASKHB-000661-4t; Fri, 05 Dec 2003 13:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASKGU-00064M-5J for nemo@optimus.ietf.org; Fri, 05 Dec 2003 13:01: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 NAA16407 for ; Fri, 5 Dec 2003 13:01:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASKGR-0006Lq-00 for nemo@ietf.org; Fri, 05 Dec 2003 13:01:15 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ASKGQ-0006KE-00 for nemo@ietf.org; Fri, 05 Dec 2003 13:01:14 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB5HxXK10195; Fri, 5 Dec 2003 09:59:33 -0800 X-mProtect: <200312051759> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDyB532; Fri, 05 Dec 2003 09:59:31 PST Message-ID: <3FD0C8D7.1010004@iprg.nokia.com> Date: Fri, 05 Dec 2003 10:05:11 -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: Jari Arkko , "Pascal Thubert (pthubert)" CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Closing Issue 27 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 Jari, Pascal, issue 27 is about clarifying MR requirements with respect to MIPv6. add the following to section 5 A Mobile Router MUST implement all requirements for IPv6 Mobile Nodes, Section 8.5 in [1]. However if a Mobile Router is not expected to initiate sessions of its own and behaves purely as a router serving the Mobile Network most of the time, then the Route Optimization functionality MAY be implemented. comments, text suggestions welcome. Vijay From exim@www1.ietf.org Fri Dec 5 13:02:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16508 for ; Fri, 5 Dec 2003 13:02: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 1ASKHE-00066x-PG for nemo-archive@odin.ietf.org; Fri, 05 Dec 2003 13:02:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5I24KR023490 for nemo-archive@odin.ietf.org; Fri, 5 Dec 2003 13:02:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASKHE-00066n-Jn for nemo-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 13:02: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 NAA16479 for ; Fri, 5 Dec 2003 13:01:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASKHC-0006PM-00 for nemo-web-archive@ietf.org; Fri, 05 Dec 2003 13:02:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASKHC-0006PJ-00 for nemo-web-archive@ietf.org; Fri, 05 Dec 2003 13:02:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASKHB-000661-4t; Fri, 05 Dec 2003 13:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASKGU-00064M-5J for nemo@optimus.ietf.org; Fri, 05 Dec 2003 13:01: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 NAA16407 for ; Fri, 5 Dec 2003 13:01:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASKGR-0006Lq-00 for nemo@ietf.org; Fri, 05 Dec 2003 13:01:15 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ASKGQ-0006KE-00 for nemo@ietf.org; Fri, 05 Dec 2003 13:01:14 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB5HxXK10195; Fri, 5 Dec 2003 09:59:33 -0800 X-mProtect: <200312051759> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDyB532; Fri, 05 Dec 2003 09:59:31 PST Message-ID: <3FD0C8D7.1010004@iprg.nokia.com> Date: Fri, 05 Dec 2003 10:05:11 -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: Jari Arkko , "Pascal Thubert (pthubert)" CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Closing Issue 27 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jari, Pascal, issue 27 is about clarifying MR requirements with respect to MIPv6. add the following to section 5 A Mobile Router MUST implement all requirements for IPv6 Mobile Nodes, Section 8.5 in [1]. However if a Mobile Router is not expected to initiate sessions of its own and behaves purely as a router serving the Mobile Network most of the time, then the Route Optimization functionality MAY be implemented. comments, text suggestions welcome. Vijay From nemo-admin@ietf.org Sun Dec 7 13:28:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29030 for ; Sun, 7 Dec 2003 13:28: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 1AT3dQ-0004Ps-PD; Sun, 07 Dec 2003 13:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT3ch-0004Pg-Ht for nemo@optimus.ietf.org; Sun, 07 Dec 2003 13:27: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 NAA29013 for ; Sun, 7 Dec 2003 13:26:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AT3cf-0003hW-00 for nemo@ietf.org; Sun, 07 Dec 2003 13:27:13 -0500 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 1AT3ce-0003hT-00 for nemo@ietf.org; Sun, 07 Dec 2003 13:27:12 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id hB7IQd6Z015446; Sun, 7 Dec 2003 11:26:49 -0700 (MST) Received: from motorola.com ([163.14.20.50]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id hB7IOfRh009368; Sun, 7 Dec 2003 12:24:46 -0600 Message-ID: <3FD370C0.3010307@motorola.com> Date: Sun, 07 Dec 2003 19:26:08 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: nemo@ietf.org Subject: Re: [nemo] Issue 28 References: <3FD0C496.4030502@iprg.nokia.com> In-Reply-To: <3FD0C496.4030502@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > I need some more comments/opinions on Issue 28 before I can call > concensus and close the issue. the list of issues are at > http://people.nokia.net/vijayd/nemo/issues.html > > what does everybody think? I think it makes sense to have all terms of NEMO basic support draft defined in the Terminology section of same draft. And, because I wish that Terminology section not to be too long, and because many terms have been used in this mailing list to discuss wide-reaching aspects of network mobility, I also think that the separate terminology draft is useful. For example, MR would be good to be defined in the Terminology section but TLMR would be defined in the Terminology document, because the basic support draft does not talk about TLMR's at all. Also, MNN would be defined in the Terminology draft and not in the Terminology section. LFN and LFR would be defined in the Terminology section, since they're used directly by the basic support draft. VMN and VMR would be defined in the Terminology draft, because they are not used at all in the basic support draft. And, last but not least, there is that Seamoby Informational terminology draft that contains the definition of MR too. Finally, the clarification of MH, MR and MN should be re-stated somewhere, because currently there is much confusion about this. Most text I've read and speech I've heard refers to MN as being a Mobile Host; while in reality MN could be either a MH or a MR (by the definition in the Mobile IPv6 spec). That's what I think about issue 28 on terminology, thanks for asking, Alex From exim@www1.ietf.org Sun Dec 7 13:28:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29045 for ; Sun, 7 Dec 2003 13:28: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 1AT3dW-0004Qq-5R for nemo-archive@odin.ietf.org; Sun, 07 Dec 2003 13:28:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB7IS6On017031 for nemo-archive@odin.ietf.org; Sun, 7 Dec 2003 13:28:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT3dW-0004Qc-1K for nemo-web-archive@optimus.ietf.org; Sun, 07 Dec 2003 13:28: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 NAA29027 for ; Sun, 7 Dec 2003 13:27:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AT3dT-0003hl-00 for nemo-web-archive@ietf.org; Sun, 07 Dec 2003 13:28:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AT3dT-0003hh-00 for nemo-web-archive@ietf.org; Sun, 07 Dec 2003 13:28:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT3dQ-0004Ps-PD; Sun, 07 Dec 2003 13:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT3ch-0004Pg-Ht for nemo@optimus.ietf.org; Sun, 07 Dec 2003 13:27: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 NAA29013 for ; Sun, 7 Dec 2003 13:26:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AT3cf-0003hW-00 for nemo@ietf.org; Sun, 07 Dec 2003 13:27:13 -0500 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 1AT3ce-0003hT-00 for nemo@ietf.org; Sun, 07 Dec 2003 13:27:12 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id hB7IQd6Z015446; Sun, 7 Dec 2003 11:26:49 -0700 (MST) Received: from motorola.com ([163.14.20.50]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id hB7IOfRh009368; Sun, 7 Dec 2003 12:24:46 -0600 Message-ID: <3FD370C0.3010307@motorola.com> Date: Sun, 07 Dec 2003 19:26:08 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: nemo@ietf.org Subject: Re: [nemo] Issue 28 References: <3FD0C496.4030502@iprg.nokia.com> In-Reply-To: <3FD0C496.4030502@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > I need some more comments/opinions on Issue 28 before I can call > concensus and close the issue. the list of issues are at > http://people.nokia.net/vijayd/nemo/issues.html > > what does everybody think? I think it makes sense to have all terms of NEMO basic support draft defined in the Terminology section of same draft. And, because I wish that Terminology section not to be too long, and because many terms have been used in this mailing list to discuss wide-reaching aspects of network mobility, I also think that the separate terminology draft is useful. For example, MR would be good to be defined in the Terminology section but TLMR would be defined in the Terminology document, because the basic support draft does not talk about TLMR's at all. Also, MNN would be defined in the Terminology draft and not in the Terminology section. LFN and LFR would be defined in the Terminology section, since they're used directly by the basic support draft. VMN and VMR would be defined in the Terminology draft, because they are not used at all in the basic support draft. And, last but not least, there is that Seamoby Informational terminology draft that contains the definition of MR too. Finally, the clarification of MH, MR and MN should be re-stated somewhere, because currently there is much confusion about this. Most text I've read and speech I've heard refers to MN as being a Mobile Host; while in reality MN could be either a MH or a MR (by the definition in the Mobile IPv6 spec). That's what I think about issue 28 on terminology, thanks for asking, Alex From nemo-admin@ietf.org Sun Dec 7 15:49:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03284 for ; Sun, 7 Dec 2003 15:49: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 1AT5pt-00005V-I2; Sun, 07 Dec 2003 15: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 1AT5pi-00005I-Gk for nemo@optimus.ietf.org; Sun, 07 Dec 2003 15:48: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 PAA03277 for ; Sun, 7 Dec 2003 15:48:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AT5pg-0005Pq-00 for nemo@ietf.org; Sun, 07 Dec 2003 15:48:49 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AT5pg-0005PS-00 for nemo@ietf.org; Sun, 07 Dec 2003 15:48:48 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB7Km8g27039; Sun, 7 Dec 2003 12:48:08 -0800 X-mProtect: <200312072048> Nokia Silicon Valley Messaging Protection Received: from danira-pool055160.americas.nokia.com (10.241.55.160, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdF4c93P; Sun, 07 Dec 2003 12:48:06 PST Message-ID: <3FD391FB.7070003@iprg.nokia.com> Date: Sun, 07 Dec 2003 12:47:55 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@ietf.org Subject: Re: [nemo] Issue 28 References: <3FD0C496.4030502@iprg.nokia.com> <3FD370C0.3010307@motorola.com> In-Reply-To: <3FD370C0.3010307@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: , Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Vijay Devarapalli wrote: > >> I need some more comments/opinions on Issue 28 before I can call >> concensus and close the issue. the list of issues are at >> http://people.nokia.net/vijayd/nemo/issues.html >> >> what does everybody think? > > > I think it makes sense to have all terms of NEMO basic support draft > defined in the Terminology section of same draft. okay. > > And, because I wish that Terminology section not to be too long, and > because many terms have been used in this mailing list to discuss > wide-reaching aspects of network mobility, I also think that the > separate terminology draft is useful. right. the intention is that the terminology section in the Basic support draft will contain a very small subset of terms contained in the terminology draft. > Finally, the clarification of MH, MR and MN should be re-stated > somewhere, because currently there is much confusion about this. Most > text I've read and speech I've heard refers to MN as being a Mobile > Host; while in reality MN could be either a MH or a MR (by the > definition in the Mobile IPv6 spec). this should be clarified in the Terminology draft. Vijay From exim@www1.ietf.org Sun Dec 7 15:49:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03299 for ; Sun, 7 Dec 2003 15:49:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT5pw-00006V-RK for nemo-archive@odin.ietf.org; Sun, 07 Dec 2003 15:49:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB7Kn4R4000393 for nemo-archive@odin.ietf.org; Sun, 7 Dec 2003 15:49:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT5pw-00006G-NM for nemo-web-archive@optimus.ietf.org; Sun, 07 Dec 2003 15:49: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 PAA03281 for ; Sun, 7 Dec 2003 15:48:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AT5pv-0005QH-00 for nemo-web-archive@ietf.org; Sun, 07 Dec 2003 15:49:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AT5pu-0005QE-00 for nemo-web-archive@ietf.org; Sun, 07 Dec 2003 15:49:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT5pt-00005V-I2; Sun, 07 Dec 2003 15: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 1AT5pi-00005I-Gk for nemo@optimus.ietf.org; Sun, 07 Dec 2003 15:48: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 PAA03277 for ; Sun, 7 Dec 2003 15:48:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AT5pg-0005Pq-00 for nemo@ietf.org; Sun, 07 Dec 2003 15:48:49 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AT5pg-0005PS-00 for nemo@ietf.org; Sun, 07 Dec 2003 15:48:48 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB7Km8g27039; Sun, 7 Dec 2003 12:48:08 -0800 X-mProtect: <200312072048> Nokia Silicon Valley Messaging Protection Received: from danira-pool055160.americas.nokia.com (10.241.55.160, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdF4c93P; Sun, 07 Dec 2003 12:48:06 PST Message-ID: <3FD391FB.7070003@iprg.nokia.com> Date: Sun, 07 Dec 2003 12:47:55 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@ietf.org Subject: Re: [nemo] Issue 28 References: <3FD0C496.4030502@iprg.nokia.com> <3FD370C0.3010307@motorola.com> In-Reply-To: <3FD370C0.3010307@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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Vijay Devarapalli wrote: > >> I need some more comments/opinions on Issue 28 before I can call >> concensus and close the issue. the list of issues are at >> http://people.nokia.net/vijayd/nemo/issues.html >> >> what does everybody think? > > > I think it makes sense to have all terms of NEMO basic support draft > defined in the Terminology section of same draft. okay. > > And, because I wish that Terminology section not to be too long, and > because many terms have been used in this mailing list to discuss > wide-reaching aspects of network mobility, I also think that the > separate terminology draft is useful. right. the intention is that the terminology section in the Basic support draft will contain a very small subset of terms contained in the terminology draft. > Finally, the clarification of MH, MR and MN should be re-stated > somewhere, because currently there is much confusion about this. Most > text I've read and speech I've heard refers to MN as being a Mobile > Host; while in reality MN could be either a MH or a MR (by the > definition in the Mobile IPv6 spec). this should be clarified in the Terminology draft. Vijay From nemo-admin@ietf.org Mon Dec 8 04:12:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01823 for ; Mon, 8 Dec 2003 04:12: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 1ATHQv-00057j-84; Mon, 08 Dec 2003 04:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATHQs-00057X-VG for nemo@optimus.ietf.org; Mon, 08 Dec 2003 04:11: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 EAA01792 for ; Mon, 8 Dec 2003 04:11:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATHQq-0007Ij-00 for nemo@ietf.org; Mon, 08 Dec 2003 04:11:56 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ATHQp-0007IT-00 for nemo@ietf.org; Mon, 08 Dec 2003 04:11:55 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Dec 2003 10:08:33 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB89BAct020968; Mon, 8 Dec 2003 10:11:12 +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); Mon, 8 Dec 2003 09:11:24 +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 Date: Mon, 8 Dec 2003 09:11:22 -0000 Message-ID: Thread-Topic: Closing Issue 27 Thread-Index: AcO7WcjWlS55jhD3SN66CLW8w+kcxgCDJcbg From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Jari Arkko" Cc: X-OriginalArrivalTime: 08 Dec 2003 09:11:24.0031 (UTC) FILETIME=[40A680F0:01C3BD6B] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Closing Issue 27 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Vijay: If you come back to my 'ugly' list and see what I think may not be = covered by the proposed text: IPv6 Mobile Routers o The router MUST comply with the MIPv6 requirements on all nodes = and=20 on all routers ([MIPv6] Sections 8.1 and 8.3). It MAY comply with=20 section 8.2 as well.=20 -> this is not said elsewhere in the spec. Do you think your new text = covers it? o The router MUST support establishing and tearing down a = bidirectional=20 tunnel to its Home Agent and a default route over that tunnel.=20 It MUST support forwarding packets between that tunnel and the = Mobile Networks.=20 -> I believe that one is natural with the spec, and can be omitted=20 o The router MUST support at least one of the 2 modes, implicit or = explicit prefix, for its Home registration as a mobile router. It SHOULD support = both. It MAY support additional routing protocols over the MRHA tunnel. =20 -> Chapter 5.2 is not clear on whether supporting only one mode is = enough. At the WG, we said HAs MUST support both, but MRs need only = support one. o The router MUST fully support [RFC2473]. As such, it MUST be able = to=20 perform IPv6 encapsulation and decapsulation, ICMP forwarding and = PMTU discovery. -> This comes with the support of 2473. Can we assume all MRs MUST do = 2473 without a word about it? ? The router MAY support receiving Mobile Prefix Advertisements (Section 11.4.3) and reconfiguring its home address based on the prefix information contained therein. -> in MIPv6 it's a MUST. For MRs, what we really need if DHCP PD that's = not ready yet. Now let's look at 8.5. o The node MUST maintain a Binding Update List (Section 11.1). -> useless for MRs. I suppose it's clear for you that this is a RO = feature. Is it clear enough for all? o The node MUST support movement detection, care-of address formation, and returning home (Section 11.5). -> MRs support this only on egress interfaces, when they act as nodes = (:meaning hosts:). This is lissing frm the new text. Again, people with = a good understanding of the spec would agree it's implicit. Conclusion: I'm afraid that your text is over simplifying (or over = implicit) though I agree with the concept, and I agree that most people = with a good understanding of the spirit of the spec would do OK = implementing it. What I suggest:=20 A bit more about what's removed from the MUST MN. In particular list = what's related to RO from 8.5 and becomes a MAY. Also remove MPA from = the MUST, and let's push for the advancement of NAI and PD features for = IPv6.=20 We need some text somewhere to list RFCs that are implicitly supported. = We're still missing an RFC with the minimum reqs on IPv6 nodes. So we = need to do it ourselves, same problem as the terminology I think. Note (as an answer for 28), that if the terminology becomes an RFC, I do = not mind referencing it and there's no need to copy text from there = (like we do not copy RFC 2461 text either) into our draft. But we can = only ref RFCs I guess. Pascal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: vendredi 5 d=E9cembre 2003 19:05 > To: Jari Arkko; Pascal Thubert (pthubert) > Cc: nemo@ietf.org > Subject: Closing Issue 27 >=20 > Jari, Pascal, >=20 > issue 27 is about clarifying MR requirements with respect to MIPv6. >=20 > add the following to section 5 >=20 > A Mobile Router MUST implement all requirements for IPv6 Mobile > Nodes, Section 8.5 in [1]. However if a Mobile Router is not > expected to initiate sessions of its own and behaves purely as a > router serving the Mobile Network most of the time, then the Route > Optimization functionality MAY be implemented. >=20 > comments, text suggestions welcome. >=20 > Vijay From exim@www1.ietf.org Mon Dec 8 04:12:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01838 for ; Mon, 8 Dec 2003 04:12: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 1ATHR0-00058Q-12 for nemo-archive@odin.ietf.org; Mon, 08 Dec 2003 04:12:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB89C5HH019737 for nemo-archive@odin.ietf.org; Mon, 8 Dec 2003 04:12:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATHQy-00058F-No for nemo-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 04:12: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 EAA01799 for ; Mon, 8 Dec 2003 04:11:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATHQv-0007Ir-00 for nemo-web-archive@ietf.org; Mon, 08 Dec 2003 04:12:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATHQv-0007Io-00 for nemo-web-archive@ietf.org; Mon, 08 Dec 2003 04:12:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATHQv-00057j-84; Mon, 08 Dec 2003 04:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATHQs-00057X-VG for nemo@optimus.ietf.org; Mon, 08 Dec 2003 04:11: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 EAA01792 for ; Mon, 8 Dec 2003 04:11:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATHQq-0007Ij-00 for nemo@ietf.org; Mon, 08 Dec 2003 04:11:56 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ATHQp-0007IT-00 for nemo@ietf.org; Mon, 08 Dec 2003 04:11:55 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Dec 2003 10:08:33 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB89BAct020968; Mon, 8 Dec 2003 10:11:12 +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); Mon, 8 Dec 2003 09:11:24 +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 Date: Mon, 8 Dec 2003 09:11:22 -0000 Message-ID: Thread-Topic: Closing Issue 27 Thread-Index: AcO7WcjWlS55jhD3SN66CLW8w+kcxgCDJcbg From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Jari Arkko" Cc: X-OriginalArrivalTime: 08 Dec 2003 09:11:24.0031 (UTC) FILETIME=[40A680F0:01C3BD6B] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Closing Issue 27 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Vijay: If you come back to my 'ugly' list and see what I think may not be = covered by the proposed text: IPv6 Mobile Routers o The router MUST comply with the MIPv6 requirements on all nodes = and=20 on all routers ([MIPv6] Sections 8.1 and 8.3). It MAY comply with=20 section 8.2 as well.=20 -> this is not said elsewhere in the spec. Do you think your new text = covers it? o The router MUST support establishing and tearing down a = bidirectional=20 tunnel to its Home Agent and a default route over that tunnel.=20 It MUST support forwarding packets between that tunnel and the = Mobile Networks.=20 -> I believe that one is natural with the spec, and can be omitted=20 o The router MUST support at least one of the 2 modes, implicit or = explicit prefix, for its Home registration as a mobile router. It SHOULD support = both. It MAY support additional routing protocols over the MRHA tunnel. =20 -> Chapter 5.2 is not clear on whether supporting only one mode is = enough. At the WG, we said HAs MUST support both, but MRs need only = support one. o The router MUST fully support [RFC2473]. As such, it MUST be able = to=20 perform IPv6 encapsulation and decapsulation, ICMP forwarding and = PMTU discovery. -> This comes with the support of 2473. Can we assume all MRs MUST do = 2473 without a word about it? ? The router MAY support receiving Mobile Prefix Advertisements (Section 11.4.3) and reconfiguring its home address based on the prefix information contained therein. -> in MIPv6 it's a MUST. For MRs, what we really need if DHCP PD that's = not ready yet. Now let's look at 8.5. o The node MUST maintain a Binding Update List (Section 11.1). -> useless for MRs. I suppose it's clear for you that this is a RO = feature. Is it clear enough for all? o The node MUST support movement detection, care-of address formation, and returning home (Section 11.5). -> MRs support this only on egress interfaces, when they act as nodes = (:meaning hosts:). This is lissing frm the new text. Again, people with = a good understanding of the spec would agree it's implicit. Conclusion: I'm afraid that your text is over simplifying (or over = implicit) though I agree with the concept, and I agree that most people = with a good understanding of the spirit of the spec would do OK = implementing it. What I suggest:=20 A bit more about what's removed from the MUST MN. In particular list = what's related to RO from 8.5 and becomes a MAY. Also remove MPA from = the MUST, and let's push for the advancement of NAI and PD features for = IPv6.=20 We need some text somewhere to list RFCs that are implicitly supported. = We're still missing an RFC with the minimum reqs on IPv6 nodes. So we = need to do it ourselves, same problem as the terminology I think. Note (as an answer for 28), that if the terminology becomes an RFC, I do = not mind referencing it and there's no need to copy text from there = (like we do not copy RFC 2461 text either) into our draft. But we can = only ref RFCs I guess. Pascal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: vendredi 5 d=E9cembre 2003 19:05 > To: Jari Arkko; Pascal Thubert (pthubert) > Cc: nemo@ietf.org > Subject: Closing Issue 27 >=20 > Jari, Pascal, >=20 > issue 27 is about clarifying MR requirements with respect to MIPv6. >=20 > add the following to section 5 >=20 > A Mobile Router MUST implement all requirements for IPv6 Mobile > Nodes, Section 8.5 in [1]. However if a Mobile Router is not > expected to initiate sessions of its own and behaves purely as a > router serving the Mobile Network most of the time, then the Route > Optimization functionality MAY be implemented. >=20 > comments, text suggestions welcome. >=20 > Vijay From nemo-admin@ietf.org Mon Dec 8 09:01:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09697 for ; Mon, 8 Dec 2003 09:01: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 1ATLwb-0007ID-UC; Mon, 08 Dec 2003 09:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATLve-0007Gz-7B for nemo@optimus.ietf.org; Mon, 08 Dec 2003 09:00: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 IAA09621 for ; Mon, 8 Dec 2003 08:59:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATLvc-0004D0-00 for nemo@ietf.org; Mon, 08 Dec 2003 09:00:00 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1ATLvc-0004Cu-00 for nemo@ietf.org; Mon, 08 Dec 2003 09:00:00 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id hB8DxtP1019379; Mon, 8 Dec 2003 06:59:55 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id hB8Dx2Px002752; Mon, 8 Dec 2003 07:59:55 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 5EBE22EC95; Mon, 8 Dec 2003 14:59:00 +0100 (CET) Message-ID: <3FD483A4.20209@motorola.com> Date: Mon, 08 Dec 2003 14:59:00 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Cc: "Pascal Thubert (pthubert)" , nemo@ietf.org References: <3FCBB391.6060909@kolumbus.fi> In-Reply-To: <3FCBB391.6060909@kolumbus.fi> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: loop detection issue 24 (was: review of the nemo basic spec) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 Jari, I would like to better understand the potential loop problem and eventually the loop detection tool. Jari Arkko wrote: > Step 1. > MR1 -> MR2 -> MR3 ---> Fixed Network ---> HA > > > > Step 2. > _---> Fixed Network ---> HA > / > +---> MR1 -> MR2 -> MR3 ---+ > | | > +--------------------------+ > > > Step 3. > > +---> MR1 -> MR2 -> MR3 ---+ > | | > +--------------------------+ > > That is, an MR3 is attached to a fixed network and communicates > with its HA. Do you assume that HA only serves MR3? And that MR1 and MR2 have different HA's that are not pictured? > There are nested MRs, MR1 and MR2. Now, MR3 sees MR1 advertising > access with a better signal strenght, and thinks incorrectly that it > would be a good idea to attach to it. So it decides to attach to MR1 > instead. However, MR3 keeps its old attachment running until it has > completed the attachment to MR1; Claiming that MR3 keeps its old attachment involves something very difficult that touches on multi-homing. Would it be possible to describe the same loop detection problem but without the "keeps its old attachment" part? Also, is it necessary to have _three_ MR's to describe the problem? I think only two MR's would be sufficient to describe the problem. > this implies the BU it sends via MR1 gets routed back to itself in a > tunnel, and actually gets to the home agent via the still operational > fixed attachment. No. If MR3 sends a BU when attached to MR1 then it is not capable of talking to its HA via the "still operational" fixed attachment. In other words, it is impossible for MR3 to send the BU to MR1 and to still talk to its HA (unless it had two egress interfaces). According to which rule would MR3 (1) send a BU to MR1 but (2) forward packets coming from MR2 tunnelled towards HA, through AR? (1) and (2) are entirely different L2 links, MR3 can not be attached to both simultaneously, unless it has two egress interfaces. > But after the BA comes back, MR3 detaches itself from the fixed > network. As a result, we have a loop and no connectivity. Now try to > send a data packet.> I would like to understand why this is not a > problem. I'm sure I'm missing something obvious. I would like to understand better how "loops" could become a problem, but w/o involving a MR wireless interface being simultaneously connected to two L2 links. Is it possible? To me, the loop detection problem as described up to now relates to the "disconnected operation" problem described in sec B.5 of draft-petrescu-nemo-mrha-03.txt and raised very early in the BoF by members; this problem basically says that if the TLMR is not connected to the infrastructure then communication between LFN's of different MR's within the nested aggregation is not possible, even if they are physically linked. Alex From exim@www1.ietf.org Mon Dec 8 09:01:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09712 for ; Mon, 8 Dec 2003 09:01: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 1ATLwe-0007Jc-Hu for nemo-archive@odin.ietf.org; Mon, 08 Dec 2003 09:01:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8E14cr028119 for nemo-archive@odin.ietf.org; Mon, 8 Dec 2003 09:01:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATLwe-0007JS-DL for nemo-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 09:01: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 JAA09679 for ; Mon, 8 Dec 2003 09:00:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATLwd-0004F6-00 for nemo-web-archive@ietf.org; Mon, 08 Dec 2003 09:01:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATLwc-0004F1-00 for nemo-web-archive@ietf.org; Mon, 08 Dec 2003 09:01:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATLwb-0007ID-UC; Mon, 08 Dec 2003 09:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATLve-0007Gz-7B for nemo@optimus.ietf.org; Mon, 08 Dec 2003 09:00: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 IAA09621 for ; Mon, 8 Dec 2003 08:59:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATLvc-0004D0-00 for nemo@ietf.org; Mon, 08 Dec 2003 09:00:00 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1ATLvc-0004Cu-00 for nemo@ietf.org; Mon, 08 Dec 2003 09:00:00 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id hB8DxtP1019379; Mon, 8 Dec 2003 06:59:55 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id hB8Dx2Px002752; Mon, 8 Dec 2003 07:59:55 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 5EBE22EC95; Mon, 8 Dec 2003 14:59:00 +0100 (CET) Message-ID: <3FD483A4.20209@motorola.com> Date: Mon, 08 Dec 2003 14:59:00 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Cc: "Pascal Thubert (pthubert)" , nemo@ietf.org References: <3FCBB391.6060909@kolumbus.fi> In-Reply-To: <3FCBB391.6060909@kolumbus.fi> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: loop detection issue 24 (was: review of the nemo basic spec) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jari, I would like to better understand the potential loop problem and eventually the loop detection tool. Jari Arkko wrote: > Step 1. > MR1 -> MR2 -> MR3 ---> Fixed Network ---> HA > > > > Step 2. > _---> Fixed Network ---> HA > / > +---> MR1 -> MR2 -> MR3 ---+ > | | > +--------------------------+ > > > Step 3. > > +---> MR1 -> MR2 -> MR3 ---+ > | | > +--------------------------+ > > That is, an MR3 is attached to a fixed network and communicates > with its HA. Do you assume that HA only serves MR3? And that MR1 and MR2 have different HA's that are not pictured? > There are nested MRs, MR1 and MR2. Now, MR3 sees MR1 advertising > access with a better signal strenght, and thinks incorrectly that it > would be a good idea to attach to it. So it decides to attach to MR1 > instead. However, MR3 keeps its old attachment running until it has > completed the attachment to MR1; Claiming that MR3 keeps its old attachment involves something very difficult that touches on multi-homing. Would it be possible to describe the same loop detection problem but without the "keeps its old attachment" part? Also, is it necessary to have _three_ MR's to describe the problem? I think only two MR's would be sufficient to describe the problem. > this implies the BU it sends via MR1 gets routed back to itself in a > tunnel, and actually gets to the home agent via the still operational > fixed attachment. No. If MR3 sends a BU when attached to MR1 then it is not capable of talking to its HA via the "still operational" fixed attachment. In other words, it is impossible for MR3 to send the BU to MR1 and to still talk to its HA (unless it had two egress interfaces). According to which rule would MR3 (1) send a BU to MR1 but (2) forward packets coming from MR2 tunnelled towards HA, through AR? (1) and (2) are entirely different L2 links, MR3 can not be attached to both simultaneously, unless it has two egress interfaces. > But after the BA comes back, MR3 detaches itself from the fixed > network. As a result, we have a loop and no connectivity. Now try to > send a data packet.> I would like to understand why this is not a > problem. I'm sure I'm missing something obvious. I would like to understand better how "loops" could become a problem, but w/o involving a MR wireless interface being simultaneously connected to two L2 links. Is it possible? To me, the loop detection problem as described up to now relates to the "disconnected operation" problem described in sec B.5 of draft-petrescu-nemo-mrha-03.txt and raised very early in the BoF by members; this problem basically says that if the TLMR is not connected to the infrastructure then communication between LFN's of different MR's within the nested aggregation is not possible, even if they are physically linked. Alex From nemo-admin@ietf.org Mon Dec 8 09:36:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10690 for ; Mon, 8 Dec 2003 09:36: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 1ATMUT-00004t-A7; Mon, 08 Dec 2003 09:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATMTp-0008Vi-4D for nemo@optimus.ietf.org; Mon, 08 Dec 2003 09:35:21 -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 JAA10666 for ; Mon, 8 Dec 2003 09:35:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATMTm-0004td-00 for nemo@ietf.org; Mon, 08 Dec 2003 09:35:18 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ATMTm-0004sw-00 for nemo@ietf.org; Mon, 08 Dec 2003 09:35:18 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Mon, 8 Dec 2003 09:34:38 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042042@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Vijay Devarapalli'" , "T.J. Kniveton" Cc: nemo@ietf.org, James Kempf Subject: RE: MR returning home (was Re: [nemo] review of the nemo basic sp ec) Date: Mon, 8 Dec 2003 09:34:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > T.J. Kniveton wrote: > > OK.. can you give me an example of when any MR, ever, > would get any > > benefit by sending RAs on its egress interface? If not, > the text there > > should probably point out this fact, or just say..don't send them. > > not for us to prohibit this, TJ. neighbor discovery specs dont > prohibit it. Jim and I had a discussion on this. the discussion > is at http://people.nokia.net/vijayd/nemo/issue21.txt. > > maybe you should pose this question on the IPv6 mailing list. > Jim has sent a mail to Hesham to clarify this when RFC 2461 > is being revised. it hasnt been discussed on the IPv6 mailing > list, though. => I just realised that I haven't replied to this email, Sorry, I'm on holidays for a while. I think what Vijay is saying makes sense to me. Routers send RAs on _advertising_ interfaces (see 2461 for the use of that term). If the MR's router is configured as an advertising interface in it's home network then it could send an RA. Why it needs to send an RA on its egress interface is a different question and depends on the particular use case. Therefore, prohibiting this effectively makes us define a new type of "router" as far as ND is concerned. The fact that the router is mobile does not mean that it cannot advertise on its egress interface. Perhaps ND needs to add another parameter to the advertising interface to allow the MR to advertise only at home (e.g. Advertising_i/f_at_home_only for MRs Vs advertising_i/f for fixed routers). But I sure wouldn't like us to disable a router from advertising on an ingress interface while at home. It might simply act as a normal router at home, why not? Hesham > > Vijay > > From exim@www1.ietf.org Mon Dec 8 09:36:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10703 for ; Mon, 8 Dec 2003 09:36:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATMUX-00007P-Ag for nemo-archive@odin.ietf.org; Mon, 08 Dec 2003 09:36:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8Ea5tW000449 for nemo-archive@odin.ietf.org; Mon, 8 Dec 2003 09:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATMUX-00007A-1X for nemo-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 09:36: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 JAA10687 for ; Mon, 8 Dec 2003 09:35:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATMUV-0004u9-00 for nemo-web-archive@ietf.org; Mon, 08 Dec 2003 09:36:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATMUU-0004u6-00 for nemo-web-archive@ietf.org; Mon, 08 Dec 2003 09: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 1ATMUT-00004t-A7; Mon, 08 Dec 2003 09:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATMTp-0008Vi-4D for nemo@optimus.ietf.org; Mon, 08 Dec 2003 09:35:21 -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 JAA10666 for ; Mon, 8 Dec 2003 09:35:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATMTm-0004td-00 for nemo@ietf.org; Mon, 08 Dec 2003 09:35:18 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ATMTm-0004sw-00 for nemo@ietf.org; Mon, 08 Dec 2003 09:35:18 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Mon, 8 Dec 2003 09:34:38 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042042@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Vijay Devarapalli'" , "T.J. Kniveton" Cc: nemo@ietf.org, James Kempf Subject: RE: MR returning home (was Re: [nemo] review of the nemo basic sp ec) Date: Mon, 8 Dec 2003 09:34:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > T.J. Kniveton wrote: > > OK.. can you give me an example of when any MR, ever, > would get any > > benefit by sending RAs on its egress interface? If not, > the text there > > should probably point out this fact, or just say..don't send them. > > not for us to prohibit this, TJ. neighbor discovery specs dont > prohibit it. Jim and I had a discussion on this. the discussion > is at http://people.nokia.net/vijayd/nemo/issue21.txt. > > maybe you should pose this question on the IPv6 mailing list. > Jim has sent a mail to Hesham to clarify this when RFC 2461 > is being revised. it hasnt been discussed on the IPv6 mailing > list, though. => I just realised that I haven't replied to this email, Sorry, I'm on holidays for a while. I think what Vijay is saying makes sense to me. Routers send RAs on _advertising_ interfaces (see 2461 for the use of that term). If the MR's router is configured as an advertising interface in it's home network then it could send an RA. Why it needs to send an RA on its egress interface is a different question and depends on the particular use case. Therefore, prohibiting this effectively makes us define a new type of "router" as far as ND is concerned. The fact that the router is mobile does not mean that it cannot advertise on its egress interface. Perhaps ND needs to add another parameter to the advertising interface to allow the MR to advertise only at home (e.g. Advertising_i/f_at_home_only for MRs Vs advertising_i/f for fixed routers). But I sure wouldn't like us to disable a router from advertising on an ingress interface while at home. It might simply act as a normal router at home, why not? Hesham > > Vijay > > From nemo-admin@ietf.org Mon Dec 8 09:47:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10938 for ; Mon, 8 Dec 2003 09:47: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 1ATMf7-0000ah-HM; Mon, 08 Dec 2003 09:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATMee-0000Z8-Az for nemo@optimus.ietf.org; Mon, 08 Dec 2003 09:46: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 JAA10902 for ; Mon, 8 Dec 2003 09:46:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATMec-00056T-00 for nemo@ietf.org; Mon, 08 Dec 2003 09:46:30 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ATMec-00055n-00 for nemo@ietf.org; Mon, 08 Dec 2003 09:46:30 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Mon, 8 Dec 2003 09:45:57 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042043@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Vijay Devarapalli'" , "T.J. Kniveton" Cc: nemo@ietf.org, James Kempf Subject: RE: MR returning home (was Re: [nemo] review of the nemo basic sp ec) Date: Mon, 8 Dec 2003 09:45:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Typo > But I sure wouldn't like us to disable a router from advertising > on an ingress interface while at home. It might simply act as ^^^^^^^^ => Should be "egress". Hesham From exim@www1.ietf.org Mon Dec 8 09:47:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10953 for ; Mon, 8 Dec 2003 09:47: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 1ATMfA-0000bh-St for nemo-archive@odin.ietf.org; Mon, 08 Dec 2003 09:47:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8El4BA002327 for nemo-archive@odin.ietf.org; Mon, 8 Dec 2003 09:47:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATMfA-0000bS-Nt for nemo-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 09:47: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 JAA10923 for ; Mon, 8 Dec 2003 09:46:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATMf8-00058E-00 for nemo-web-archive@ietf.org; Mon, 08 Dec 2003 09:47:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATMf8-00058B-00 for nemo-web-archive@ietf.org; Mon, 08 Dec 2003 09: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 1ATMf7-0000ah-HM; Mon, 08 Dec 2003 09:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATMee-0000Z8-Az for nemo@optimus.ietf.org; Mon, 08 Dec 2003 09:46: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 JAA10902 for ; Mon, 8 Dec 2003 09:46:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATMec-00056T-00 for nemo@ietf.org; Mon, 08 Dec 2003 09:46:30 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1ATMec-00055n-00 for nemo@ietf.org; Mon, 08 Dec 2003 09:46:30 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id ; Mon, 8 Dec 2003 09:45:57 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F042043@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Vijay Devarapalli'" , "T.J. Kniveton" Cc: nemo@ietf.org, James Kempf Subject: RE: MR returning home (was Re: [nemo] review of the nemo basic sp ec) Date: Mon, 8 Dec 2003 09:45:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Typo > But I sure wouldn't like us to disable a router from advertising > on an ingress interface while at home. It might simply act as ^^^^^^^^ => Should be "egress". Hesham From nemo-admin@ietf.org Mon Dec 8 12:39:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20337 for ; Mon, 8 Dec 2003 12:39: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 1ATPLZ-00027O-VB; Mon, 08 Dec 2003 12:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATPKu-00025m-N6 for nemo@optimus.ietf.org; Mon, 08 Dec 2003 12:38: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 MAA20270 for ; Mon, 8 Dec 2003 12:38:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATPKt-00017H-00 for nemo@ietf.org; Mon, 08 Dec 2003 12:38:19 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ATPKs-00016B-00 for nemo@ietf.org; Mon, 08 Dec 2003 12:38:18 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB8Hba720822; Mon, 8 Dec 2003 09:37:36 -0800 X-mProtect: <200312081737> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdMU6zZi; Mon, 08 Dec 2003 09:37:35 PST Message-ID: <3FD4B840.90401@iprg.nokia.com> Date: Mon, 08 Dec 2003 09:43:28 -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: Soliman Hesham CC: "T.J. Kniveton" , nemo@ietf.org, James Kempf Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic sp ec) References: <9E3BA3946476AD4EB94672712B12A85F042042@ftmail.lab.flarion.com> In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F042042@ftmail.lab.flarion.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: , Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > Perhaps ND needs to add another parameter to the advertising > interface to allow the MR to advertise only at home (e.g. > Advertising_i/f_at_home_only for MRs Vs advertising_i/f > for fixed routers). IMO, Neighbor Discovery should recognize that routers can be mobile and they cant behave as they used to when they were on their topologically correct links. the NEMO basic spec currently prohibits Mobile Routers from sending router adverts on their egress interface when they are on the visited link. having this in the ND spec itself is fine with me. Vijay From exim@www1.ietf.org Mon Dec 8 12:39:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20355 for ; Mon, 8 Dec 2003 12:39: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 1ATPLg-00029X-SQ for nemo-archive@odin.ietf.org; Mon, 08 Dec 2003 12:39:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8Hd87M008269 for nemo-archive@odin.ietf.org; Mon, 8 Dec 2003 12:39:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATPLg-00029I-ME for nemo-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 12:39:08 -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 MAA20327 for ; Mon, 8 Dec 2003 12:38:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATPLf-00019J-00 for nemo-web-archive@ietf.org; Mon, 08 Dec 2003 12:39:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATPLe-00019G-00 for nemo-web-archive@ietf.org; Mon, 08 Dec 2003 12:39:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATPLZ-00027O-VB; Mon, 08 Dec 2003 12:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATPKu-00025m-N6 for nemo@optimus.ietf.org; Mon, 08 Dec 2003 12:38: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 MAA20270 for ; Mon, 8 Dec 2003 12:38:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATPKt-00017H-00 for nemo@ietf.org; Mon, 08 Dec 2003 12:38:19 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ATPKs-00016B-00 for nemo@ietf.org; Mon, 08 Dec 2003 12:38:18 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB8Hba720822; Mon, 8 Dec 2003 09:37:36 -0800 X-mProtect: <200312081737> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdMU6zZi; Mon, 08 Dec 2003 09:37:35 PST Message-ID: <3FD4B840.90401@iprg.nokia.com> Date: Mon, 08 Dec 2003 09:43:28 -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: Soliman Hesham CC: "T.J. Kniveton" , nemo@ietf.org, James Kempf Subject: Re: MR returning home (was Re: [nemo] review of the nemo basic sp ec) References: <9E3BA3946476AD4EB94672712B12A85F042042@ftmail.lab.flarion.com> In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F042042@ftmail.lab.flarion.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > Perhaps ND needs to add another parameter to the advertising > interface to allow the MR to advertise only at home (e.g. > Advertising_i/f_at_home_only for MRs Vs advertising_i/f > for fixed routers). IMO, Neighbor Discovery should recognize that routers can be mobile and they cant behave as they used to when they were on their topologically correct links. the NEMO basic spec currently prohibits Mobile Routers from sending router adverts on their egress interface when they are on the visited link. having this in the ND spec itself is fine with me. Vijay From nemo-admin@ietf.org Mon Dec 8 13:27:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22857 for ; Mon, 8 Dec 2003 13:27: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 1ATQ64-0005NQ-M7; Mon, 08 Dec 2003 13:27:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATQ5P-0005Ji-Oy for nemo@optimus.ietf.org; Mon, 08 Dec 2003 13:26: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 NAA22712 for ; Mon, 8 Dec 2003 13:26:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATQ5N-00024k-00 for nemo@ietf.org; Mon, 08 Dec 2003 13:26:21 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ATQ5M-00023I-00 for nemo@ietf.org; Mon, 08 Dec 2003 13:26:20 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB8IOMj27357; Mon, 8 Dec 2003 10:24:22 -0800 X-mProtect: <200312081824> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdHou3Fm; Mon, 08 Dec 2003 10:24:21 PST Message-ID: <3FD4C336.3050507@iprg.nokia.com> Date: Mon, 08 Dec 2003 10:30:14 -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: Jari Arkko , nemo@ietf.org Subject: Re: [nemo] RE: Closing Issue 27 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: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > IPv6 Mobile Routers > > > o The router MUST comply with the MIPv6 requirements on all nodes and > on all routers ([MIPv6] Sections 8.1 and 8.3). It MAY comply with > section 8.2 as well. > > -> this is not said elsewhere in the spec. Do you think your new text covers it? section 8.1 does not have any requirements. section 8.3 talks about requirements for all IPv6 routers. a mobile router is an IPv6 router. draft-ietf-ipv6-node-requirements-06.txt says Routers SHOULD support the generic mobility-related requirements for all IPv6 routers described in Section 8.3 of [MIPv6]. > > o The router MUST support at least one of the 2 modes, implicit or explicit prefix, > for its Home registration as a mobile router. It SHOULD support both. It MAY support > additional routing protocols over the MRHA tunnel. > > -> Chapter 5.2 is not clear on whether supporting only one mode is enough. At the WG, we said HAs MUST support both, but MRs need only support one. we already discussed this. section 5.2 says The Mobile Router uses one of the following modes to instruct the Home Agent to determine the prefixes owned by the Mobile Router. section 6 says The Home Agent MUST implement both modes described in Section 5.2 of this document. support for dynamic routing protocols is truly optional for both mobile router and Home Agent. > > o The router MUST fully support [RFC2473]. As such, it MUST be able to > perform IPv6 encapsulation and decapsulation, ICMP forwarding and PMTU > discovery. > > -> This comes with the support of 2473. Can we assume all MRs MUST do 2473 without a word about it? look for reference [3] all over the text. the text says the reverse tunneling must be done using RFC 2473. > > ? The router MAY support receiving Mobile Prefix Advertisements > (Section 11.4.3) and reconfiguring its home address based on the > prefix information contained therein. > > -> in MIPv6 it's a MUST. For MRs, what we really need if DHCP PD that's not ready yet. if the MR configures its home address from the home link (and not from MNP), prefix discovery is still needed. so it is a MUST so far. > > > Now let's look at 8.5. > > > o The node MUST maintain a Binding Update List (Section 11.1). > > -> useless for MRs. I suppose it's clear for you that this is a RO feature. Is it clear enough for all? thats not correct. BUL is not an RO feature. it is needed for a mobile router because it sends binding updates to its Home Agent. > Conclusion: I'm afraid that your text is over simplifying its exactly what is need without getting into a rut. > Also remove MPA from the MUST disagree. > and let's push for the advancement of NAI and PD features for IPv6. sure. > > We're still missing an RFC with the minimum reqs on IPv6 nodes. it might be ready before the NEMO spec. its with the IESG now. look up the mobility section in the node requirements draft. > > Note (as an answer for 28), that if the terminology becomes an RFC, > I do not mind referencing it and there's no need to copy text from > there (like we do not copy RFC 2461 text either) into our draft. But > we can only ref RFCs I guess. a couple of clarifications. you can add an internet draft as an informational reference. you shouldnt put an internet draft in the normative section, unless that internet draft is also being advanced at the same time. but that may not an issue here because I was told that the terminology document is also being advanced to the IESG (though I dont know why there hasnt been a WG last call on it yet). as for you comparison between RFC 2461 and terminology draft, there is a huge difference. :) Vijay From exim@www1.ietf.org Mon Dec 8 13:27:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22873 for ; Mon, 8 Dec 2003 13:27:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATQ68-0005PS-D5 for nemo-archive@odin.ietf.org; Mon, 08 Dec 2003 13:27:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8IR8LH020793 for nemo-archive@odin.ietf.org; Mon, 8 Dec 2003 13:27:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATQ68-0005PI-8o for nemo-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 13:27:08 -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 NAA22782 for ; Mon, 8 Dec 2003 13:26:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATQ66-00026u-00 for nemo-web-archive@ietf.org; Mon, 08 Dec 2003 13:27:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATQ65-00026r-00 for nemo-web-archive@ietf.org; Mon, 08 Dec 2003 13:27:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATQ64-0005NQ-M7; Mon, 08 Dec 2003 13:27:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATQ5P-0005Ji-Oy for nemo@optimus.ietf.org; Mon, 08 Dec 2003 13:26: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 NAA22712 for ; Mon, 8 Dec 2003 13:26:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATQ5N-00024k-00 for nemo@ietf.org; Mon, 08 Dec 2003 13:26:21 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ATQ5M-00023I-00 for nemo@ietf.org; Mon, 08 Dec 2003 13:26:20 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB8IOMj27357; Mon, 8 Dec 2003 10:24:22 -0800 X-mProtect: <200312081824> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdHou3Fm; Mon, 08 Dec 2003 10:24:21 PST Message-ID: <3FD4C336.3050507@iprg.nokia.com> Date: Mon, 08 Dec 2003 10:30:14 -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: Jari Arkko , nemo@ietf.org Subject: Re: [nemo] RE: Closing Issue 27 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > IPv6 Mobile Routers > > > o The router MUST comply with the MIPv6 requirements on all nodes and > on all routers ([MIPv6] Sections 8.1 and 8.3). It MAY comply with > section 8.2 as well. > > -> this is not said elsewhere in the spec. Do you think your new text covers it? section 8.1 does not have any requirements. section 8.3 talks about requirements for all IPv6 routers. a mobile router is an IPv6 router. draft-ietf-ipv6-node-requirements-06.txt says Routers SHOULD support the generic mobility-related requirements for all IPv6 routers described in Section 8.3 of [MIPv6]. > > o The router MUST support at least one of the 2 modes, implicit or explicit prefix, > for its Home registration as a mobile router. It SHOULD support both. It MAY support > additional routing protocols over the MRHA tunnel. > > -> Chapter 5.2 is not clear on whether supporting only one mode is enough. At the WG, we said HAs MUST support both, but MRs need only support one. we already discussed this. section 5.2 says The Mobile Router uses one of the following modes to instruct the Home Agent to determine the prefixes owned by the Mobile Router. section 6 says The Home Agent MUST implement both modes described in Section 5.2 of this document. support for dynamic routing protocols is truly optional for both mobile router and Home Agent. > > o The router MUST fully support [RFC2473]. As such, it MUST be able to > perform IPv6 encapsulation and decapsulation, ICMP forwarding and PMTU > discovery. > > -> This comes with the support of 2473. Can we assume all MRs MUST do 2473 without a word about it? look for reference [3] all over the text. the text says the reverse tunneling must be done using RFC 2473. > > ? The router MAY support receiving Mobile Prefix Advertisements > (Section 11.4.3) and reconfiguring its home address based on the > prefix information contained therein. > > -> in MIPv6 it's a MUST. For MRs, what we really need if DHCP PD that's not ready yet. if the MR configures its home address from the home link (and not from MNP), prefix discovery is still needed. so it is a MUST so far. > > > Now let's look at 8.5. > > > o The node MUST maintain a Binding Update List (Section 11.1). > > -> useless for MRs. I suppose it's clear for you that this is a RO feature. Is it clear enough for all? thats not correct. BUL is not an RO feature. it is needed for a mobile router because it sends binding updates to its Home Agent. > Conclusion: I'm afraid that your text is over simplifying its exactly what is need without getting into a rut. > Also remove MPA from the MUST disagree. > and let's push for the advancement of NAI and PD features for IPv6. sure. > > We're still missing an RFC with the minimum reqs on IPv6 nodes. it might be ready before the NEMO spec. its with the IESG now. look up the mobility section in the node requirements draft. > > Note (as an answer for 28), that if the terminology becomes an RFC, > I do not mind referencing it and there's no need to copy text from > there (like we do not copy RFC 2461 text either) into our draft. But > we can only ref RFCs I guess. a couple of clarifications. you can add an internet draft as an informational reference. you shouldnt put an internet draft in the normative section, unless that internet draft is also being advanced at the same time. but that may not an issue here because I was told that the terminology document is also being advanced to the IESG (though I dont know why there hasnt been a WG last call on it yet). as for you comparison between RFC 2461 and terminology draft, there is a huge difference. :) Vijay From nemo-admin@ietf.org Tue Dec 9 02:29:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14204 for ; Tue, 9 Dec 2003 02:29: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 1ATcIp-0005uw-4t; Tue, 09 Dec 2003 02:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATcHo-0005su-OH for nemo@optimus.ietf.org; Tue, 09 Dec 2003 02:28: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 CAA14173 for ; Tue, 9 Dec 2003 02:27:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATcHl-00024c-00 for nemo@ietf.org; Tue, 09 Dec 2003 02:27:57 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ATcHk-00024Q-00 for nemo@ietf.org; Tue, 09 Dec 2003 02:27:56 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 09 Dec 2003 08:24:31 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB97RBbH023383; Tue, 9 Dec 2003 08:27:12 +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); Tue, 9 Dec 2003 07:27:25 +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] RE: Closing Issue 27 Date: Tue, 9 Dec 2003 07:27:24 -0000 Message-ID: Thread-Topic: [nemo] RE: Closing Issue 27 Thread-Index: AcO9uML2X+3shuijTZWhvX0UzQbBAQAav86g From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: "Jari Arkko" , X-OriginalArrivalTime: 09 Dec 2003 07:27:25.0291 (UTC) FILETIME=[E47C13B0:01C3BE25] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: lundi 8 d=E9cembre 2003 19:30 > To: Pascal Thubert (pthubert) > Cc: Jari Arkko; nemo@ietf.org > Subject: Re: [nemo] RE: Closing Issue 27 >=20 > Pascal Thubert (pthubert) wrote: >=20 > > IPv6 Mobile Routers > > > > > > o The router MUST comply with the MIPv6 requirements on all = nodes and > > on all routers ([MIPv6] Sections 8.1 and 8.3). It MAY comply = with > > section 8.2 as well. > > > > -> this is not said elsewhere in the spec. Do you think your new = text covers it? >=20 > section 8.1 does not have any requirements. section 8.3 talks > about requirements for all IPv6 routers. a mobile router is an > IPv6 router. >=20 > draft-ietf-ipv6-node-requirements-06.txt says >=20 > Routers SHOULD support the generic mobility-related requirements = for > all IPv6 routers described in Section 8.3 of [MIPv6]. >=20 > > > > o The router MUST support at least one of the 2 modes, implicit = or explicit prefix, > > for its Home registration as a mobile router. It SHOULD = support both. It MAY support > > additional routing protocols over the MRHA tunnel. > > > > -> Chapter 5.2 is not clear on whether supporting only one mode is = enough. At the WG, we > said HAs MUST support both, but MRs need only support one. >=20 > we already discussed this. >=20 > section 5.2 says >=20 > The Mobile Router uses > one of the following modes to instruct the Home Agent to determine > the prefixes owned by the Mobile Router. >=20 My point exactly. Obviously MR uses one method since that's all what's = available, but this does not say whether a compliant MR MAY or SHOULD = support both. I'm asking for a very limited change here, which removes = the need for a list at the end (which is ugly :) > section 6 says >=20 > The > Home Agent MUST implement both modes described in Section 5.2 of = this > document. >=20 > support for dynamic routing protocols is truly optional for both > mobile router and Home Agent. >=20 >=20 > look for reference [3] all over the text. the text says the reverse > tunneling must be done using RFC 2473. Again, do you think that mean full support of 2473? I mean, ICMP = forwarding, PMTU etc... It does not take a lot of text to be very = explicit. The current draft is not wrong, but it is very implicit. >=20 > > > > ? The router MAY support receiving Mobile Prefix Advertisements > > (Section 11.4.3) and reconfiguring its home address based on = the > > prefix information contained therein. > > > > -> in MIPv6 it's a MUST. For MRs, what we really need if DHCP PD = that's not ready yet. >=20 > if the MR configures its home address from the home link (and not > from MNP), prefix discovery is still needed. so it is a MUST so > far. >=20 So either you say it MUST in a given case, which is more precise than my = MAY, or you leave it to a MAY? Anyway I believe it is at least as = important to have the prefix delegation (from which we can build a new = Home address for the MR) that to have MPA. And we let the draft out with = no PD support. So for me MPA falls into the same TBD in a following = module. Maybe we will discover that MPA is not globally the best thing = to do when you have PD and NAI, so MUSTing it now pains me. > > > > > > Now let's look at 8.5. > > > > > > o The node MUST maintain a Binding Update List (Section 11.1). > > > > -> useless for MRs. I suppose it's clear for you that this is a RO = feature. Is it clear > enough for all? >=20 > thats not correct. BUL is not an RO feature. it is needed for a > mobile router because it sends binding updates to its Home Agent. >=20 That's not a List. It becomes a list when you start RO. > > Conclusion: I'm afraid that your text is over simplifying >=20 > its exactly what is need without getting into a rut. >=20 it sure is an improvement anyway > > Also remove MPA from the MUST >=20 > disagree. Advice from the list, anybody? >=20 > > and let's push for the advancement of NAI and PD features for IPv6. >=20 > sure. >=20 :) > > > > We're still missing an RFC with the minimum reqs on IPv6 nodes. >=20 > it might be ready before the NEMO spec. its with the IESG now. > look up the mobility section in the node requirements draft. >=20 > > > > Note (as an answer for 28), that if the terminology becomes an RFC, > > I do not mind referencing it and there's no need to copy text from > > there (like we do not copy RFC 2461 text either) into our draft. But > > we can only ref RFCs I guess. >=20 > a couple of clarifications. you can add an internet draft as an > informational reference. you shouldnt put an internet draft in > the normative section, unless that internet draft is also being > advanced at the same time. but that may not an issue here because > I was told that the terminology document is also being advanced > to the IESG (though I dont know why there hasnt been a WG last > call on it yet). >=20 > as for you comparison between RFC 2461 and terminology draft, > there is a huge difference. :) >=20 :) Pascal From exim@www1.ietf.org Tue Dec 9 02:29:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14219 for ; Tue, 9 Dec 2003 02:29: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 1ATcJ3-0005xl-9Z for nemo-archive@odin.ietf.org; Tue, 09 Dec 2003 02:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB97TGKG022845 for nemo-archive@odin.ietf.org; Tue, 9 Dec 2003 02:29:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATcJ0-0005wO-57 for nemo-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 02:29: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 CAA14199 for ; Tue, 9 Dec 2003 02:28:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATcIw-00025F-00 for nemo-web-archive@ietf.org; Tue, 09 Dec 2003 02:29:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATcIw-00025B-00 for nemo-web-archive@ietf.org; Tue, 09 Dec 2003 02:29:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATcIp-0005uw-4t; Tue, 09 Dec 2003 02:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATcHo-0005su-OH for nemo@optimus.ietf.org; Tue, 09 Dec 2003 02:28: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 CAA14173 for ; Tue, 9 Dec 2003 02:27:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATcHl-00024c-00 for nemo@ietf.org; Tue, 09 Dec 2003 02:27:57 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ATcHk-00024Q-00 for nemo@ietf.org; Tue, 09 Dec 2003 02:27:56 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 09 Dec 2003 08:24:31 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB97RBbH023383; Tue, 9 Dec 2003 08:27:12 +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); Tue, 9 Dec 2003 07:27:25 +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] RE: Closing Issue 27 Date: Tue, 9 Dec 2003 07:27:24 -0000 Message-ID: Thread-Topic: [nemo] RE: Closing Issue 27 Thread-Index: AcO9uML2X+3shuijTZWhvX0UzQbBAQAav86g From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: "Jari Arkko" , X-OriginalArrivalTime: 09 Dec 2003 07:27:25.0291 (UTC) FILETIME=[E47C13B0:01C3BE25] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: lundi 8 d=E9cembre 2003 19:30 > To: Pascal Thubert (pthubert) > Cc: Jari Arkko; nemo@ietf.org > Subject: Re: [nemo] RE: Closing Issue 27 >=20 > Pascal Thubert (pthubert) wrote: >=20 > > IPv6 Mobile Routers > > > > > > o The router MUST comply with the MIPv6 requirements on all = nodes and > > on all routers ([MIPv6] Sections 8.1 and 8.3). It MAY comply = with > > section 8.2 as well. > > > > -> this is not said elsewhere in the spec. Do you think your new = text covers it? >=20 > section 8.1 does not have any requirements. section 8.3 talks > about requirements for all IPv6 routers. a mobile router is an > IPv6 router. >=20 > draft-ietf-ipv6-node-requirements-06.txt says >=20 > Routers SHOULD support the generic mobility-related requirements = for > all IPv6 routers described in Section 8.3 of [MIPv6]. >=20 > > > > o The router MUST support at least one of the 2 modes, implicit = or explicit prefix, > > for its Home registration as a mobile router. It SHOULD = support both. It MAY support > > additional routing protocols over the MRHA tunnel. > > > > -> Chapter 5.2 is not clear on whether supporting only one mode is = enough. At the WG, we > said HAs MUST support both, but MRs need only support one. >=20 > we already discussed this. >=20 > section 5.2 says >=20 > The Mobile Router uses > one of the following modes to instruct the Home Agent to determine > the prefixes owned by the Mobile Router. >=20 My point exactly. Obviously MR uses one method since that's all what's = available, but this does not say whether a compliant MR MAY or SHOULD = support both. I'm asking for a very limited change here, which removes = the need for a list at the end (which is ugly :) > section 6 says >=20 > The > Home Agent MUST implement both modes described in Section 5.2 of = this > document. >=20 > support for dynamic routing protocols is truly optional for both > mobile router and Home Agent. >=20 >=20 > look for reference [3] all over the text. the text says the reverse > tunneling must be done using RFC 2473. Again, do you think that mean full support of 2473? I mean, ICMP = forwarding, PMTU etc... It does not take a lot of text to be very = explicit. The current draft is not wrong, but it is very implicit. >=20 > > > > ? The router MAY support receiving Mobile Prefix Advertisements > > (Section 11.4.3) and reconfiguring its home address based on = the > > prefix information contained therein. > > > > -> in MIPv6 it's a MUST. For MRs, what we really need if DHCP PD = that's not ready yet. >=20 > if the MR configures its home address from the home link (and not > from MNP), prefix discovery is still needed. so it is a MUST so > far. >=20 So either you say it MUST in a given case, which is more precise than my = MAY, or you leave it to a MAY? Anyway I believe it is at least as = important to have the prefix delegation (from which we can build a new = Home address for the MR) that to have MPA. And we let the draft out with = no PD support. So for me MPA falls into the same TBD in a following = module. Maybe we will discover that MPA is not globally the best thing = to do when you have PD and NAI, so MUSTing it now pains me. > > > > > > Now let's look at 8.5. > > > > > > o The node MUST maintain a Binding Update List (Section 11.1). > > > > -> useless for MRs. I suppose it's clear for you that this is a RO = feature. Is it clear > enough for all? >=20 > thats not correct. BUL is not an RO feature. it is needed for a > mobile router because it sends binding updates to its Home Agent. >=20 That's not a List. It becomes a list when you start RO. > > Conclusion: I'm afraid that your text is over simplifying >=20 > its exactly what is need without getting into a rut. >=20 it sure is an improvement anyway > > Also remove MPA from the MUST >=20 > disagree. Advice from the list, anybody? >=20 > > and let's push for the advancement of NAI and PD features for IPv6. >=20 > sure. >=20 :) > > > > We're still missing an RFC with the minimum reqs on IPv6 nodes. >=20 > it might be ready before the NEMO spec. its with the IESG now. > look up the mobility section in the node requirements draft. >=20 > > > > Note (as an answer for 28), that if the terminology becomes an RFC, > > I do not mind referencing it and there's no need to copy text from > > there (like we do not copy RFC 2461 text either) into our draft. But > > we can only ref RFCs I guess. >=20 > a couple of clarifications. you can add an internet draft as an > informational reference. you shouldnt put an internet draft in > the normative section, unless that internet draft is also being > advanced at the same time. but that may not an issue here because > I was told that the terminology document is also being advanced > to the IESG (though I dont know why there hasnt been a WG last > call on it yet). >=20 > as for you comparison between RFC 2461 and terminology draft, > there is a huge difference. :) >=20 :) Pascal From nemo-admin@ietf.org Tue Dec 9 04:57:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20049 for ; Tue, 9 Dec 2003 04:57: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 1ATec2-0006EK-3O; Tue, 09 Dec 2003 04:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATeb6-0006Di-4c for nemo@optimus.ietf.org; Tue, 09 Dec 2003 04:56: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 EAA19981 for ; Tue, 9 Dec 2003 04:55:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATeb2-0004eE-00 for nemo@ietf.org; Tue, 09 Dec 2003 04:56:00 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1ATeb2-0004dy-00 for nemo@ietf.org; Tue, 09 Dec 2003 04:56:00 -0500 Received: from huez (dhcp03.ipv6.rennes.enst-bretagne.fr [192.108.119.203]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 3DE725D094; Tue, 9 Dec 2003 18:55:28 +0900 (JST) Date: Tue, 9 Dec 2003 18:54:50 +0900 From: Thierry Ernst To: Alexandru Petrescu Cc: vijayd@iprg.nokia.com, nemo@ietf.org Subject: Re: [nemo] Issue 28 Message-Id: <20031209185450.5c723105.ernst@sfc.wide.ad.jp> In-Reply-To: <3FD370C0.3010307@motorola.com> References: <3FD0C496.4030502@iprg.nokia.com> <3FD370C0.3010307@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Let me remind you that we have a separate terminology because the WG aggreed it; and that the terminology doc contains more terms that are needed in NEMO Basic Support. So, if you want to move some definitions in the NEMO Basic Support doc, we would still need a doc for the other terms ... > For example, MR would be good to be defined in the Terminology section > but TLMR would be defined in the Terminology document, because the basic > support draft does not talk about TLMR's at all. - generic terms are defined in draft-ietf-seamoby-terminology, included MR. - TMLR doesn't exist anymore, it's root-MR. > Finally, the clarification of MH, MR and MN should be re-stated > somewhere, because currently there is much confusion about this. Most > text I've read and speech I've heard refers to MN as being a Mobile > Host; while in reality MN could be either a MH or a MR (by the > definition in the Mobile IPv6 spec). Anyone is free to propose a rephrasing (that is shared by ML members). To me, a MN is either a host or a router, I think the definitions are clear about this. I think the NEMO Basic Support doc should only define specific terms, if needed. For instance, LFN is better defined in an other document, as it will be used in discussions not only turning around Basic Support. On the other hand, if we want to define a term R-BU (Router Binding Update, to distinguish with the MIPv6 BU), the NEMO Basic Support doc is a better place. So, what terms would you like to see in the NEMO Basic Support doc ? About the status of the terminology doc, I have not issued the WG last call because I think the terminology about multihoming is not clear enough and may be enhanced based on the discussion about the coming multihoming WG document. Thierry. From exim@www1.ietf.org Tue Dec 9 04:57:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20064 for ; Tue, 9 Dec 2003 04:57: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 1ATecA-0006Gb-Ha for nemo-archive@odin.ietf.org; Tue, 09 Dec 2003 04:57:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB99vAgo024083 for nemo-archive@odin.ietf.org; Tue, 9 Dec 2003 04:57:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATec8-0006GL-AO for nemo-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 04:57:08 -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 EAA20039 for ; Tue, 9 Dec 2003 04:56:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATec5-0004fT-00 for nemo-web-archive@ietf.org; Tue, 09 Dec 2003 04:57:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATec4-0004fQ-00 for nemo-web-archive@ietf.org; Tue, 09 Dec 2003 04:57:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATec2-0006EK-3O; Tue, 09 Dec 2003 04:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATeb6-0006Di-4c for nemo@optimus.ietf.org; Tue, 09 Dec 2003 04:56: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 EAA19981 for ; Tue, 9 Dec 2003 04:55:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATeb2-0004eE-00 for nemo@ietf.org; Tue, 09 Dec 2003 04:56:00 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1ATeb2-0004dy-00 for nemo@ietf.org; Tue, 09 Dec 2003 04:56:00 -0500 Received: from huez (dhcp03.ipv6.rennes.enst-bretagne.fr [192.108.119.203]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 3DE725D094; Tue, 9 Dec 2003 18:55:28 +0900 (JST) Date: Tue, 9 Dec 2003 18:54:50 +0900 From: Thierry Ernst To: Alexandru Petrescu Cc: vijayd@iprg.nokia.com, nemo@ietf.org Subject: Re: [nemo] Issue 28 Message-Id: <20031209185450.5c723105.ernst@sfc.wide.ad.jp> In-Reply-To: <3FD370C0.3010307@motorola.com> References: <3FD0C496.4030502@iprg.nokia.com> <3FD370C0.3010307@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Let me remind you that we have a separate terminology because the WG aggreed it; and that the terminology doc contains more terms that are needed in NEMO Basic Support. So, if you want to move some definitions in the NEMO Basic Support doc, we would still need a doc for the other terms ... > For example, MR would be good to be defined in the Terminology section > but TLMR would be defined in the Terminology document, because the basic > support draft does not talk about TLMR's at all. - generic terms are defined in draft-ietf-seamoby-terminology, included MR. - TMLR doesn't exist anymore, it's root-MR. > Finally, the clarification of MH, MR and MN should be re-stated > somewhere, because currently there is much confusion about this. Most > text I've read and speech I've heard refers to MN as being a Mobile > Host; while in reality MN could be either a MH or a MR (by the > definition in the Mobile IPv6 spec). Anyone is free to propose a rephrasing (that is shared by ML members). To me, a MN is either a host or a router, I think the definitions are clear about this. I think the NEMO Basic Support doc should only define specific terms, if needed. For instance, LFN is better defined in an other document, as it will be used in discussions not only turning around Basic Support. On the other hand, if we want to define a term R-BU (Router Binding Update, to distinguish with the MIPv6 BU), the NEMO Basic Support doc is a better place. So, what terms would you like to see in the NEMO Basic Support doc ? About the status of the terminology doc, I have not issued the WG last call because I think the terminology about multihoming is not clear enough and may be enhanced based on the discussion about the coming multihoming WG document. Thierry. From nemo-admin@ietf.org Tue Dec 9 05:05:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20250 for ; Tue, 9 Dec 2003 05:05: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 1ATejl-0006YX-BB; Tue, 09 Dec 2003 05: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 1ATejb-0006YI-El for nemo@optimus.ietf.org; Tue, 09 Dec 2003 05:04: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 FAA20221 for ; Tue, 9 Dec 2003 05:04:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATejY-0004k9-00 for nemo@ietf.org; Tue, 09 Dec 2003 05:04:48 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ATejX-0004jr-00 for nemo@ietf.org; Tue, 09 Dec 2003 05:04:47 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 09 Dec 2003 11:01:23 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB9A43Dn011104; Tue, 9 Dec 2003 11:04:04 +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); Tue, 9 Dec 2003 10:04:17 +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] Issue 28 Date: Tue, 9 Dec 2003 10:04:16 -0000 Message-ID: Thread-Topic: [nemo] Issue 28 Thread-Index: AcO+OuBfjl7+Y82MQbiTtwS0hpIIxQAABTWA From: "Pascal Thubert (pthubert)" To: "Thierry Ernst" , "Alexandru Petrescu" Cc: , X-OriginalArrivalTime: 09 Dec 2003 10:04:17.0468 (UTC) FILETIME=[CE944FC0:01C3BE3B] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of = Thierry Ernst > Sent: mardi 9 d=E9cembre 2003 10:55 > To: Alexandru Petrescu > Cc: vijayd@iprg.nokia.com; nemo@ietf.org > Subject: Re: [nemo] Issue 28 >=20 >=20 > Hi, >=20 > Let me remind you that we have a separate terminology because the WG > aggreed it; and that the terminology doc contains more terms that are > needed in NEMO Basic Support. So, if you want to move some definitions > in the NEMO Basic Support doc, we would still need a doc for the other > terms ... >=20 I support leaving the definitions in terminology if it goes RFC, as I = mentioned implicitly in the thread. Question: should we also move the = definitions from the usage draft into the terminology (I assume yes)? > > For example, MR would be good to be defined in the Terminology = section > > but TLMR would be defined in the Terminology document, because the = basic > > support draft does not talk about TLMR's at all. >=20 > - generic terms are defined in draft-ietf-seamoby-terminology, = included > MR. >=20 > - TMLR doesn't exist anymore, it's root-MR. I support leaving TLMR in the terminology as a deprecated synonym for = root-MR; reason is it's been used for awhile. >=20 > > Finally, the clarification of MH, MR and MN should be re-stated > > somewhere, because currently there is much confusion about this. = Most > > text I've read and speech I've heard refers to MN as being a Mobile > > Host; while in reality MN could be either a MH or a MR (by the > > definition in the Mobile IPv6 spec). >=20 > Anyone is free to propose a rephrasing (that is shared by ML members). > To me, a MN is either a host or a router, I think the definitions are > clear about this. >=20 >=20 > I think the NEMO Basic Support doc should only define specific terms, = if > needed. For instance, LFN is better defined in an other document, as = it > will be used in discussions not only turning around Basic Support. On > the other hand, if we want to define a term R-BU (Router Binding = Update, > to distinguish with the MIPv6 BU), the NEMO Basic Support doc is a > better place. >=20 > So, what terms would you like to see in the NEMO Basic Support doc ? >=20 >=20 > About the status of the terminology doc, I have not issued the WG last > call because I think the terminology about multihoming is not clear > enough and may be enhanced based on the discussion about the coming > multihoming WG document. >=20 Thierry: this doc will always evolve. So we have to cut RFCs when needed = and start a follow on. From exim@www1.ietf.org Tue Dec 9 05:05:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20265 for ; Tue, 9 Dec 2003 05:05: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 1ATejp-0006Zd-AG for nemo-archive@odin.ietf.org; Tue, 09 Dec 2003 05:05:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9A55hW025268 for nemo-archive@odin.ietf.org; Tue, 9 Dec 2003 05:05:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATejo-0006ZR-R9 for nemo-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 05:05: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 FAA20225 for ; Tue, 9 Dec 2003 05:04:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATejl-0004kF-00 for nemo-web-archive@ietf.org; Tue, 09 Dec 2003 05:05:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATejl-0004kC-00 for nemo-web-archive@ietf.org; Tue, 09 Dec 2003 05:05:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATejl-0006YX-BB; Tue, 09 Dec 2003 05: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 1ATejb-0006YI-El for nemo@optimus.ietf.org; Tue, 09 Dec 2003 05:04: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 FAA20221 for ; Tue, 9 Dec 2003 05:04:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATejY-0004k9-00 for nemo@ietf.org; Tue, 09 Dec 2003 05:04:48 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ATejX-0004jr-00 for nemo@ietf.org; Tue, 09 Dec 2003 05:04:47 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 09 Dec 2003 11:01:23 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB9A43Dn011104; Tue, 9 Dec 2003 11:04:04 +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); Tue, 9 Dec 2003 10:04:17 +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] Issue 28 Date: Tue, 9 Dec 2003 10:04:16 -0000 Message-ID: Thread-Topic: [nemo] Issue 28 Thread-Index: AcO+OuBfjl7+Y82MQbiTtwS0hpIIxQAABTWA From: "Pascal Thubert (pthubert)" To: "Thierry Ernst" , "Alexandru Petrescu" Cc: , X-OriginalArrivalTime: 09 Dec 2003 10:04:17.0468 (UTC) FILETIME=[CE944FC0:01C3BE3B] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of = Thierry Ernst > Sent: mardi 9 d=E9cembre 2003 10:55 > To: Alexandru Petrescu > Cc: vijayd@iprg.nokia.com; nemo@ietf.org > Subject: Re: [nemo] Issue 28 >=20 >=20 > Hi, >=20 > Let me remind you that we have a separate terminology because the WG > aggreed it; and that the terminology doc contains more terms that are > needed in NEMO Basic Support. So, if you want to move some definitions > in the NEMO Basic Support doc, we would still need a doc for the other > terms ... >=20 I support leaving the definitions in terminology if it goes RFC, as I = mentioned implicitly in the thread. Question: should we also move the = definitions from the usage draft into the terminology (I assume yes)? > > For example, MR would be good to be defined in the Terminology = section > > but TLMR would be defined in the Terminology document, because the = basic > > support draft does not talk about TLMR's at all. >=20 > - generic terms are defined in draft-ietf-seamoby-terminology, = included > MR. >=20 > - TMLR doesn't exist anymore, it's root-MR. I support leaving TLMR in the terminology as a deprecated synonym for = root-MR; reason is it's been used for awhile. >=20 > > Finally, the clarification of MH, MR and MN should be re-stated > > somewhere, because currently there is much confusion about this. = Most > > text I've read and speech I've heard refers to MN as being a Mobile > > Host; while in reality MN could be either a MH or a MR (by the > > definition in the Mobile IPv6 spec). >=20 > Anyone is free to propose a rephrasing (that is shared by ML members). > To me, a MN is either a host or a router, I think the definitions are > clear about this. >=20 >=20 > I think the NEMO Basic Support doc should only define specific terms, = if > needed. For instance, LFN is better defined in an other document, as = it > will be used in discussions not only turning around Basic Support. On > the other hand, if we want to define a term R-BU (Router Binding = Update, > to distinguish with the MIPv6 BU), the NEMO Basic Support doc is a > better place. >=20 > So, what terms would you like to see in the NEMO Basic Support doc ? >=20 >=20 > About the status of the terminology doc, I have not issued the WG last > call because I think the terminology about multihoming is not clear > enough and may be enhanced based on the discussion about the coming > multihoming WG document. >=20 Thierry: this doc will always evolve. So we have to cut RFCs when needed = and start a follow on. From nemo-admin@ietf.org Tue Dec 9 14:18:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08609 for ; Tue, 9 Dec 2003 14:18: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 1ATnMv-0003Ux-95; Tue, 09 Dec 2003 14: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 1ATnMs-0003Ua-LX for nemo@optimus.ietf.org; Tue, 09 Dec 2003 14:17:58 -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 OAA08584 for ; Tue, 9 Dec 2003 14:17:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATnMq-0005cP-00 for nemo@ietf.org; Tue, 09 Dec 2003 14:17:56 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ATnMp-0005cA-00 for nemo@ietf.org; Tue, 09 Dec 2003 14:17:55 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB9JGTn02320; Tue, 9 Dec 2003 11:16:29 -0800 X-mProtect: <200312091916> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdHgsf6V; Tue, 09 Dec 2003 11:16:27 PST Message-ID: <3FD620F1.7020604@iprg.nokia.com> Date: Tue, 09 Dec 2003 11:22:25 -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: Jari Arkko , nemo@ietf.org Subject: Re: [nemo] RE: Closing Issue 27 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: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >>section 5.2 says >> >> The Mobile Router uses >> one of the following modes to instruct the Home Agent to determine >> the prefixes owned by the Mobile Router. >> > My point exactly. Obviously MR uses one method since that's all what's available, but this does not say whether a compliant MR MAY or SHOULD support both. I'm asking for a very limited change here, which removes the need for a list at the end (which is ugly :) okay. made it more explicit. A Mobile Router MUST implement atleast one mode and MAY implement both modes. >>look for reference [3] all over the text. the text says the reverse >>tunneling must be done using RFC 2473. > > > Again, do you think that mean full support of 2473? I mean, ICMP forwarding, PMTU etc... It does not take a lot of text to be very explicit. The current draft is not wrong, but it is very implicit. this should be clarified in the IPv6 Node requirements doc. IMO, RFC 2473 does not seem to have any optional sections. you have to implement it entirely. (?) >>> ? The router MAY support receiving Mobile Prefix Advertisements >>> (Section 11.4.3) and reconfiguring its home address based on the >>> prefix information contained therein. >>> >>>-> in MIPv6 it's a MUST. For MRs, what we really need if DHCP PD that's not ready yet. >> >>if the MR configures its home address from the home link (and not >>from MNP), prefix discovery is still needed. so it is a MUST so >>far. >> > So either you say it MUST in a given case, which is more precise than > my MAY, or you leave it to a MAY? Anyway I believe it is at least as > important to have the prefix delegation (from which we can build a new > Home address for the MR) that to have MPA. And we let the draft out > with no PD support. So for me MPA falls into the same TBD in a > following module. Maybe we will discover that MPA is not globally the > best thing to do when you have PD and NAI, so MUSTing it now pains me. the way I see it, prefix discovery and prefix delegation for NEMO do two different things. prefix discovery is about discovering prefix information on the home link. prefix delegation is about delegating prefixes for the mobile network. both are needed, IMO. if it turns out that prefix discovery is not used, when DHCP prefix delegation is deployed, then we can strip it out when NEMO basic support moves from proposed standard to draft standard. (I am being very optimistic :) >>> o The node MUST maintain a Binding Update List (Section 11.1). >>> >>>-> useless for MRs. I suppose it's clear for you that this is a RO feature. Is it clear >> >>enough for all? >> >>thats not correct. BUL is not an RO feature. it is needed for a >>mobile router because it sends binding updates to its Home Agent. >> > That's not a List. It becomes a list when you start RO. what about when the MR has more than one HA? it becomes a list? Vijay From exim@www1.ietf.org Tue Dec 9 14:18:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08626 for ; Tue, 9 Dec 2003 14:18:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATnN2-0003WF-LS for nemo-archive@odin.ietf.org; Tue, 09 Dec 2003 14:18:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9JI8HY013523 for nemo-archive@odin.ietf.org; Tue, 9 Dec 2003 14:18:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATnN2-0003Vw-BL for nemo-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 14:18:08 -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 OAA08592 for ; Tue, 9 Dec 2003 14:17:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATnMz-0005ck-00 for nemo-web-archive@ietf.org; Tue, 09 Dec 2003 14:18:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATnMz-0005cg-00 for nemo-web-archive@ietf.org; Tue, 09 Dec 2003 14:18:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATnMv-0003Ux-95; Tue, 09 Dec 2003 14: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 1ATnMs-0003Ua-LX for nemo@optimus.ietf.org; Tue, 09 Dec 2003 14:17:58 -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 OAA08584 for ; Tue, 9 Dec 2003 14:17:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATnMq-0005cP-00 for nemo@ietf.org; Tue, 09 Dec 2003 14:17:56 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ATnMp-0005cA-00 for nemo@ietf.org; Tue, 09 Dec 2003 14:17:55 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hB9JGTn02320; Tue, 9 Dec 2003 11:16:29 -0800 X-mProtect: <200312091916> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdHgsf6V; Tue, 09 Dec 2003 11:16:27 PST Message-ID: <3FD620F1.7020604@iprg.nokia.com> Date: Tue, 09 Dec 2003 11:22:25 -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: Jari Arkko , nemo@ietf.org Subject: Re: [nemo] RE: Closing Issue 27 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >>section 5.2 says >> >> The Mobile Router uses >> one of the following modes to instruct the Home Agent to determine >> the prefixes owned by the Mobile Router. >> > My point exactly. Obviously MR uses one method since that's all what's available, but this does not say whether a compliant MR MAY or SHOULD support both. I'm asking for a very limited change here, which removes the need for a list at the end (which is ugly :) okay. made it more explicit. A Mobile Router MUST implement atleast one mode and MAY implement both modes. >>look for reference [3] all over the text. the text says the reverse >>tunneling must be done using RFC 2473. > > > Again, do you think that mean full support of 2473? I mean, ICMP forwarding, PMTU etc... It does not take a lot of text to be very explicit. The current draft is not wrong, but it is very implicit. this should be clarified in the IPv6 Node requirements doc. IMO, RFC 2473 does not seem to have any optional sections. you have to implement it entirely. (?) >>> ? The router MAY support receiving Mobile Prefix Advertisements >>> (Section 11.4.3) and reconfiguring its home address based on the >>> prefix information contained therein. >>> >>>-> in MIPv6 it's a MUST. For MRs, what we really need if DHCP PD that's not ready yet. >> >>if the MR configures its home address from the home link (and not >>from MNP), prefix discovery is still needed. so it is a MUST so >>far. >> > So either you say it MUST in a given case, which is more precise than > my MAY, or you leave it to a MAY? Anyway I believe it is at least as > important to have the prefix delegation (from which we can build a new > Home address for the MR) that to have MPA. And we let the draft out > with no PD support. So for me MPA falls into the same TBD in a > following module. Maybe we will discover that MPA is not globally the > best thing to do when you have PD and NAI, so MUSTing it now pains me. the way I see it, prefix discovery and prefix delegation for NEMO do two different things. prefix discovery is about discovering prefix information on the home link. prefix delegation is about delegating prefixes for the mobile network. both are needed, IMO. if it turns out that prefix discovery is not used, when DHCP prefix delegation is deployed, then we can strip it out when NEMO basic support moves from proposed standard to draft standard. (I am being very optimistic :) >>> o The node MUST maintain a Binding Update List (Section 11.1). >>> >>>-> useless for MRs. I suppose it's clear for you that this is a RO feature. Is it clear >> >>enough for all? >> >>thats not correct. BUL is not an RO feature. it is needed for a >>mobile router because it sends binding updates to its Home Agent. >> > That's not a List. It becomes a list when you start RO. what about when the MR has more than one HA? it becomes a list? Vijay From nemo-admin@ietf.org Wed Dec 10 03:39:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04356 for ; Wed, 10 Dec 2003 03:39: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 1ATzs5-00010Q-Mo; Wed, 10 Dec 2003 03:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATzro-0000zt-8q for nemo@optimus.ietf.org; Wed, 10 Dec 2003 03:38: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 DAA04343 for ; Wed, 10 Dec 2003 03:38:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATzrl-0005kG-00 for nemo@ietf.org; Wed, 10 Dec 2003 03:38:41 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ATzrl-0005kD-00 for nemo@ietf.org; Wed, 10 Dec 2003 03:38:41 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 10 Dec 2003 09:35:15 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hBA8buYX017015; Wed, 10 Dec 2003 09:37:57 +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); Wed, 10 Dec 2003 08:38:10 +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 Subject: RE: [nemo] RE: Closing Issue 27 Date: Wed, 10 Dec 2003 08:38:09 -0000 Message-ID: Thread-Topic: [nemo] RE: Closing Issue 27 Thread-Index: AcO+iRjpaI+nHMraRyuUtPcbjNZv7QAblYdw From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 10 Dec 2003 08:38:10.0160 (UTC) FILETIME=[F1096F00:01C3BEF8] 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 > okay. made it more explicit. >=20 > A Mobile Router MUST implement atleast one mode and MAY implement > both modes. >=20 >=20 :) > >>look for reference [3] all over the text. the text says the reverse > >>tunneling must be done using RFC 2473. > > > > > > Again, do you think that mean full support of 2473? I mean, ICMP forwarding, PMTU etc... It > does not take a lot of text to be very explicit. The current draft is not wrong, but it is > very implicit. >=20 > this should be clarified in the IPv6 Node requirements doc. IMO, > RFC 2473 does not seem to have any optional sections. you have > to implement it entirely. (?) >=20 >=20 I suppose so too. I agree it's better if we are able to dereference the node reqs. > >>>-> useless for MRs. I suppose it's clear for you that this is a RO feature. Is it clear > >> > >>enough for all? > >> > >>thats not correct. BUL is not an RO feature. it is needed for a > >>mobile router because it sends binding updates to its Home Agent. > >> > > That's not a List. It becomes a list when you start RO. >=20 > what about when the MR has more than one HA? it becomes a list? >=20 I thought my point was clear... I try otherwise. Minimum basic Nemo MR does not need a list. So you can not MUST it. A basic nemo MR SHOULD support DHAAD, so I guess that implicitly it SHOULD be able to store a list of HAs. But only one needs to be active at a given point of time. Only one active binding is needed. There no need to support a list. Note that in the spirit (unless I'm wrong) the list is about the various bindings for a given CareOf, and if a MR was to support multiple registrations, I guess it would naturally maintain multiple lists. But this is implementation... Pascal From exim@www1.ietf.org Wed Dec 10 03:39:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04371 for ; Wed, 10 Dec 2003 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 1ATzsB-00011T-1y for nemo-archive@odin.ietf.org; Wed, 10 Dec 2003 03:39:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBA8d6Em003924 for nemo-archive@odin.ietf.org; Wed, 10 Dec 2003 03:39:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATzsA-00011D-FO for nemo-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 03:39: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 DAA04351 for ; Wed, 10 Dec 2003 03:39:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATzs8-0005kY-00 for nemo-web-archive@ietf.org; Wed, 10 Dec 2003 03:39:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATzs7-0005kU-00 for nemo-web-archive@ietf.org; Wed, 10 Dec 2003 03:39:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATzs5-00010Q-Mo; Wed, 10 Dec 2003 03:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATzro-0000zt-8q for nemo@optimus.ietf.org; Wed, 10 Dec 2003 03:38: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 DAA04343 for ; Wed, 10 Dec 2003 03:38:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATzrl-0005kG-00 for nemo@ietf.org; Wed, 10 Dec 2003 03:38:41 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ATzrl-0005kD-00 for nemo@ietf.org; Wed, 10 Dec 2003 03:38:41 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 10 Dec 2003 09:35:15 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hBA8buYX017015; Wed, 10 Dec 2003 09:37:57 +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); Wed, 10 Dec 2003 08:38:10 +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 Subject: RE: [nemo] RE: Closing Issue 27 Date: Wed, 10 Dec 2003 08:38:09 -0000 Message-ID: Thread-Topic: [nemo] RE: Closing Issue 27 Thread-Index: AcO+iRjpaI+nHMraRyuUtPcbjNZv7QAblYdw From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 10 Dec 2003 08:38:10.0160 (UTC) FILETIME=[F1096F00:01C3BEF8] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > okay. made it more explicit. >=20 > A Mobile Router MUST implement atleast one mode and MAY implement > both modes. >=20 >=20 :) > >>look for reference [3] all over the text. the text says the reverse > >>tunneling must be done using RFC 2473. > > > > > > Again, do you think that mean full support of 2473? I mean, ICMP forwarding, PMTU etc... It > does not take a lot of text to be very explicit. The current draft is not wrong, but it is > very implicit. >=20 > this should be clarified in the IPv6 Node requirements doc. IMO, > RFC 2473 does not seem to have any optional sections. you have > to implement it entirely. (?) >=20 >=20 I suppose so too. I agree it's better if we are able to dereference the node reqs. > >>>-> useless for MRs. I suppose it's clear for you that this is a RO feature. Is it clear > >> > >>enough for all? > >> > >>thats not correct. BUL is not an RO feature. it is needed for a > >>mobile router because it sends binding updates to its Home Agent. > >> > > That's not a List. It becomes a list when you start RO. >=20 > what about when the MR has more than one HA? it becomes a list? >=20 I thought my point was clear... I try otherwise. Minimum basic Nemo MR does not need a list. So you can not MUST it. A basic nemo MR SHOULD support DHAAD, so I guess that implicitly it SHOULD be able to store a list of HAs. But only one needs to be active at a given point of time. Only one active binding is needed. There no need to support a list. Note that in the spirit (unless I'm wrong) the list is about the various bindings for a given CareOf, and if a MR was to support multiple registrations, I guess it would naturally maintain multiple lists. But this is implementation... Pascal From exim@www1.ietf.org Wed Dec 10 13:39:09 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08608 for ; Wed, 10 Dec 2003 13:39: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 1AU90Y-00063M-KJ for nemo-archive@odin.ietf.org; Wed, 10 Dec 2003 13:24:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAIOMnC023264 for nemo-archive@odin.ietf.org; Wed, 10 Dec 2003 13:24:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU90Y-000639-F4 for nemo-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 13:24: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 NAA08039 for ; Wed, 10 Dec 2003 13:24:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU90G-0005CF-00 for nemo-web-archive@ietf.org; Wed, 10 Dec 2003 13:24:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AU90F-0005CC-00 for nemo-web-archive@ietf.org; Wed, 10 Dec 2003 13:24:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU90E-0005t0-4P; Wed, 10 Dec 2003 13:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU8zO-0005qG-19 for nemo@optimus.ietf.org; Wed, 10 Dec 2003 13:23: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 NAA07892 for ; Wed, 10 Dec 2003 13:14:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU8rU-00052a-00 for nemo@ietf.org; Wed, 10 Dec 2003 13:15:00 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AU8rT-000509-00 for nemo@ietf.org; Wed, 10 Dec 2003 13:15:00 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hBAIDSQ26638; Wed, 10 Dec 2003 10:13:28 -0800 X-mProtect: <200312101813> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdcrmWnV; Wed, 10 Dec 2003 10:13:27 PST Message-ID: <3FD763B1.5070501@iprg.nokia.com> Date: Wed, 10 Dec 2003 10:19:29 -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: nemo@ietf.org Subject: Re: [nemo] RE: Closing Issue 27 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >>>>thats not correct. BUL is not an RO feature. it is needed for a >>>>mobile router because it sends binding updates to its Home Agent. >>>> >>> >>>That's not a List. It becomes a list when you start RO. >> >>what about when the MR has more than one HA? it becomes a list? >> > > I thought my point was clear... I try otherwise. Minimum basic Nemo MR > does not need a list. So you can not MUST it. A basic nemo MR SHOULD > support DHAAD, so I guess that implicitly it SHOULD be able to store a > list of HAs. But only one needs to be active at a given point of time. > Only one active binding is needed. There no need to support a list. sigh... a basic NEMO MR can have more than one Home Agent at any time. and when a MR sends a BU to more than one node, you need a BUL. therefore an MR MUST implement BUL. suppose an implementor leaves out implementing the BUL. the user of the mobile router (with no BUL) configures it with more than one home agent. what happens then? dont tell me the implementor also left out implementing the ability to configure the mobile router with more than one home agent. > Note that in the spirit (unless I'm wrong) the list is about the various > bindings for a given CareOf, not really. from MIPv6 spec. Binding Update List This list is maintained by each mobile node. The list has an item for every binding that the mobile node has or is trying to establish with a specific other node. Both correspondent and home registrations are included in this list. > and if a MR was to support multiple > registrations, I guess it would naturally maintain multiple lists. But > this is implementation... BUL is looked up by CN/HA address. there is no BUL per CoA. Vijay From nemo-admin@ietf.org Wed Dec 10 13:49:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09170 for ; Wed, 10 Dec 2003 13:49: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 1AU90E-0005t0-4P; Wed, 10 Dec 2003 13:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU8zO-0005qG-19 for nemo@optimus.ietf.org; Wed, 10 Dec 2003 13:23: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 NAA07892 for ; Wed, 10 Dec 2003 13:14:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU8rU-00052a-00 for nemo@ietf.org; Wed, 10 Dec 2003 13:15:00 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AU8rT-000509-00 for nemo@ietf.org; Wed, 10 Dec 2003 13:15:00 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hBAIDSQ26638; Wed, 10 Dec 2003 10:13:28 -0800 X-mProtect: <200312101813> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdcrmWnV; Wed, 10 Dec 2003 10:13:27 PST Message-ID: <3FD763B1.5070501@iprg.nokia.com> Date: Wed, 10 Dec 2003 10:19:29 -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: nemo@ietf.org Subject: Re: [nemo] RE: Closing Issue 27 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: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >>>>thats not correct. BUL is not an RO feature. it is needed for a >>>>mobile router because it sends binding updates to its Home Agent. >>>> >>> >>>That's not a List. It becomes a list when you start RO. >> >>what about when the MR has more than one HA? it becomes a list? >> > > I thought my point was clear... I try otherwise. Minimum basic Nemo MR > does not need a list. So you can not MUST it. A basic nemo MR SHOULD > support DHAAD, so I guess that implicitly it SHOULD be able to store a > list of HAs. But only one needs to be active at a given point of time. > Only one active binding is needed. There no need to support a list. sigh... a basic NEMO MR can have more than one Home Agent at any time. and when a MR sends a BU to more than one node, you need a BUL. therefore an MR MUST implement BUL. suppose an implementor leaves out implementing the BUL. the user of the mobile router (with no BUL) configures it with more than one home agent. what happens then? dont tell me the implementor also left out implementing the ability to configure the mobile router with more than one home agent. > Note that in the spirit (unless I'm wrong) the list is about the various > bindings for a given CareOf, not really. from MIPv6 spec. Binding Update List This list is maintained by each mobile node. The list has an item for every binding that the mobile node has or is trying to establish with a specific other node. Both correspondent and home registrations are included in this list. > and if a MR was to support multiple > registrations, I guess it would naturally maintain multiple lists. But > this is implementation... BUL is looked up by CN/HA address. there is no BUL per CoA. Vijay From nemo-admin@ietf.org Wed Dec 10 15:51:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16042 for ; Wed, 10 Dec 2003 15:51: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 1AUBIV-0006R8-Qu; Wed, 10 Dec 2003 15: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 1AUBHw-0006QF-4b for nemo@optimus.ietf.org; Wed, 10 Dec 2003 15:50: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 PAA15989 for ; Wed, 10 Dec 2003 15:50:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUBHt-00013t-00 for nemo@ietf.org; Wed, 10 Dec 2003 15:50:25 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AUBHt-00013q-00 for nemo@ietf.org; Wed, 10 Dec 2003 15:50:25 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 8EB246A904; Wed, 10 Dec 2003 22:50:24 +0200 (EET) Message-ID: <3FD786E7.6000800@kolumbus.fi> Date: Wed, 10 Dec 2003 22:49:43 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] RE: Closing Issue 27 References: <3FD763B1.5070501@iprg.nokia.com> In-Reply-To: <3FD763B1.5070501@iprg.nokia.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: , Content-Transfer-Encoding: 7bit A couple of comments: o I agree with Vijay that BUL needs to be a list, if not for multiple registrations per home address, at least for the possibility of multiple home addresses / home agents. o A specification should clearly give its dependencies to other specifications, even if IPv6 node requirements perhaps mandates those other specifications. o I think the RFC 2473 reference is already clear enough in the draft. However, I'm a little troubled by the lack of a keyword in around any of the referencing places. If we had that, say in 5.5, 6.4, or 6.5, then matter would even clearer. o I do not think you should spend too much effort on optimizing the parts of MIPv6 that you need or do not need. Remember that CN side RO is already a SHOULD in the IPv6 node requirements. --Jari From exim@www1.ietf.org Wed Dec 10 15:51:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16057 for ; Wed, 10 Dec 2003 15:51: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 1AUBIY-0006SH-0m for nemo-archive@odin.ietf.org; Wed, 10 Dec 2003 15:51:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAKp51I024807 for nemo-archive@odin.ietf.org; Wed, 10 Dec 2003 15:51:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUBIX-0006S2-RQ for nemo-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 15:51: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 PAA16033 for ; Wed, 10 Dec 2003 15:51:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUBIV-00014P-00 for nemo-web-archive@ietf.org; Wed, 10 Dec 2003 15:51:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUBIV-00014M-00 for nemo-web-archive@ietf.org; Wed, 10 Dec 2003 15: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 1AUBIV-0006R8-Qu; Wed, 10 Dec 2003 15: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 1AUBHw-0006QF-4b for nemo@optimus.ietf.org; Wed, 10 Dec 2003 15:50: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 PAA15989 for ; Wed, 10 Dec 2003 15:50:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUBHt-00013t-00 for nemo@ietf.org; Wed, 10 Dec 2003 15:50:25 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AUBHt-00013q-00 for nemo@ietf.org; Wed, 10 Dec 2003 15:50:25 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 8EB246A904; Wed, 10 Dec 2003 22:50:24 +0200 (EET) Message-ID: <3FD786E7.6000800@kolumbus.fi> Date: Wed, 10 Dec 2003 22:49:43 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] RE: Closing Issue 27 References: <3FD763B1.5070501@iprg.nokia.com> In-Reply-To: <3FD763B1.5070501@iprg.nokia.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A couple of comments: o I agree with Vijay that BUL needs to be a list, if not for multiple registrations per home address, at least for the possibility of multiple home addresses / home agents. o A specification should clearly give its dependencies to other specifications, even if IPv6 node requirements perhaps mandates those other specifications. o I think the RFC 2473 reference is already clear enough in the draft. However, I'm a little troubled by the lack of a keyword in around any of the referencing places. If we had that, say in 5.5, 6.4, or 6.5, then matter would even clearer. o I do not think you should spend too much effort on optimizing the parts of MIPv6 that you need or do not need. Remember that CN side RO is already a SHOULD in the IPv6 node requirements. --Jari From nemo-admin@ietf.org Wed Dec 10 16:04:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17895 for ; Wed, 10 Dec 2003 16:04: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 1AUBV2-0007BJ-QO; Wed, 10 Dec 2003 16:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUBUc-0007Aa-MN for nemo@optimus.ietf.org; Wed, 10 Dec 2003 16:03:36 -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 QAA17793 for ; Wed, 10 Dec 2003 16:03:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUBUa-0001o5-00 for nemo@ietf.org; Wed, 10 Dec 2003 16:03:32 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AUBUY-0001o1-00 for nemo@ietf.org; Wed, 10 Dec 2003 16:03:30 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id hBAL30P1022199; Wed, 10 Dec 2003 14:03:00 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id hBAL2th0024824; Wed, 10 Dec 2003 15:02:57 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 3F4672EC95; Wed, 10 Dec 2003 22:02:55 +0100 (CET) Message-ID: <3FD789FF.8090506@motorola.com> Date: Wed, 10 Dec 2003 22:02:55 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Cc: Vijay Devarapalli , "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] RE: Closing Issue 27 References: <3FD763B1.5070501@iprg.nokia.com> <3FD786E7.6000800@kolumbus.fi> In-Reply-To: <3FD786E7.6000800@kolumbus.fi> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jari Arkko wrote: [...] > o I think the RFC 2473 reference is already clear enough in the > draft. However, I'm a little troubled by the lack of a keyword in > around any of the referencing places. If we had that, say in 5.5, > 6.4, or 6.5, then matter would even clearer. For example, in section 5.5 of pre02, the next to last paragraph, one could refer to section 4.1.1 of RFC2473 (Tunnel Encapsulation Limit Option). > o I do not think you should spend too much effort on optimizing the > parts of MIPv6 that you need or do not need. Remember that CN side RO > is already a SHOULD in the IPv6 node requirements. I agree with this too. Alex From nemo-admin@ietf.org Wed Dec 10 16:09:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18512 for ; Wed, 10 Dec 2003 16:09: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 1AUBZt-0007b8-GH; Wed, 10 Dec 2003 16:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUBZa-0007ad-Re for nemo@optimus.ietf.org; Wed, 10 Dec 2003 16:08: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 QAA18494 for ; Wed, 10 Dec 2003 16:08:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUBZY-00025r-00 for nemo@ietf.org; Wed, 10 Dec 2003 16:08:40 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AUBZX-00025g-00 for nemo@ietf.org; Wed, 10 Dec 2003 16:08:40 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 08B2E6A904; Wed, 10 Dec 2003 23:08:40 +0200 (EET) Message-ID: <3FD78B2F.9080807@kolumbus.fi> Date: Wed, 10 Dec 2003 23:07:59 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Cc: Vijay Devarapalli , "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] RE: Closing Issue 27 References: <3FD763B1.5070501@iprg.nokia.com> <3FD786E7.6000800@kolumbus.fi> <3FD789FF.8090506@motorola.com> In-Reply-To: <3FD789FF.8090506@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: , Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Jari Arkko wrote: > [...] > >> o I think the RFC 2473 reference is already clear enough in the draft. >> However, I'm a little troubled by the lack of a keyword in around any >> of the referencing places. If we had that, say in 5.5, 6.4, or 6.5, >> then matter would even clearer. > > > For example, in section 5.5 of pre02, the next to last paragraph, one > could refer to section 4.1.1 of RFC2473 (Tunnel Encapsulation Limit > Option). Yes. It would be even better if the whole thing i.e. reference to RFC 2473 as a whole appeared in a sentence with a 'MUST'. --Jari From exim@www1.ietf.org Wed Dec 10 16:11:50 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18747 for ; Wed, 10 Dec 2003 16:11:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUBcB-0007iq-4E for nemo-archive@odin.ietf.org; Wed, 10 Dec 2003 16:11:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBALBNsH029678 for nemo-archive@odin.ietf.org; Wed, 10 Dec 2003 16:11:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUBcA-0007iZ-Sx for nemo-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 16:11: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 QAA18662 for ; Wed, 10 Dec 2003 16:11:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUBc8-0002A5-00 for nemo-web-archive@ietf.org; Wed, 10 Dec 2003 16:11:20 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AUBc8-00029j-00 for nemo-web-archive@ietf.org; Wed, 10 Dec 2003 16:11:20 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AUBZw-0007eX-3v for nemo-web-archive@ietf.org; Wed, 10 Dec 2003 16:09:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUBZt-0007b8-GH; Wed, 10 Dec 2003 16:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUBZa-0007ad-Re for nemo@optimus.ietf.org; Wed, 10 Dec 2003 16:08: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 QAA18494 for ; Wed, 10 Dec 2003 16:08:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUBZY-00025r-00 for nemo@ietf.org; Wed, 10 Dec 2003 16:08:40 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AUBZX-00025g-00 for nemo@ietf.org; Wed, 10 Dec 2003 16:08:40 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 08B2E6A904; Wed, 10 Dec 2003 23:08:40 +0200 (EET) Message-ID: <3FD78B2F.9080807@kolumbus.fi> Date: Wed, 10 Dec 2003 23:07:59 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Cc: Vijay Devarapalli , "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] RE: Closing Issue 27 References: <3FD763B1.5070501@iprg.nokia.com> <3FD786E7.6000800@kolumbus.fi> <3FD789FF.8090506@motorola.com> In-Reply-To: <3FD789FF.8090506@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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Jari Arkko wrote: > [...] > >> o I think the RFC 2473 reference is already clear enough in the draft. >> However, I'm a little troubled by the lack of a keyword in around any >> of the referencing places. If we had that, say in 5.5, 6.4, or 6.5, >> then matter would even clearer. > > > For example, in section 5.5 of pre02, the next to last paragraph, one > could refer to section 4.1.1 of RFC2473 (Tunnel Encapsulation Limit > Option). Yes. It would be even better if the whole thing i.e. reference to RFC 2473 as a whole appeared in a sentence with a 'MUST'. --Jari From exim@www1.ietf.org Wed Dec 10 16:21:44 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19085 for ; Wed, 10 Dec 2003 16:21:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUBlk-0007x1-Hs for nemo-archive@odin.ietf.org; Wed, 10 Dec 2003 16:21:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBALLGWa030557 for nemo-archive@odin.ietf.org; Wed, 10 Dec 2003 16:21:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUBlk-0007wl-As for nemo-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 16:21: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 QAA19033 for ; Wed, 10 Dec 2003 16:21:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUBlh-0002Nr-00 for nemo-web-archive@ietf.org; Wed, 10 Dec 2003 16:21:13 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AUBcD-00029j-02 for nemo-web-archive@ietf.org; Wed, 10 Dec 2003 16:11:25 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AUBVG-0007OY-4R for nemo-web-archive@ietf.org; Wed, 10 Dec 2003 16:04:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUBV2-0007BJ-QO; Wed, 10 Dec 2003 16:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUBUc-0007Aa-MN for nemo@optimus.ietf.org; Wed, 10 Dec 2003 16:03:36 -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 QAA17793 for ; Wed, 10 Dec 2003 16:03:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUBUa-0001o5-00 for nemo@ietf.org; Wed, 10 Dec 2003 16:03:32 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AUBUY-0001o1-00 for nemo@ietf.org; Wed, 10 Dec 2003 16:03:30 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id hBAL30P1022199; Wed, 10 Dec 2003 14:03:00 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id hBAL2th0024824; Wed, 10 Dec 2003 15:02:57 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 3F4672EC95; Wed, 10 Dec 2003 22:02:55 +0100 (CET) Message-ID: <3FD789FF.8090506@motorola.com> Date: Wed, 10 Dec 2003 22:02:55 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Cc: Vijay Devarapalli , "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: [nemo] RE: Closing Issue 27 References: <3FD763B1.5070501@iprg.nokia.com> <3FD786E7.6000800@kolumbus.fi> In-Reply-To: <3FD786E7.6000800@kolumbus.fi> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jari Arkko wrote: [...] > o I think the RFC 2473 reference is already clear enough in the > draft. However, I'm a little troubled by the lack of a keyword in > around any of the referencing places. If we had that, say in 5.5, > 6.4, or 6.5, then matter would even clearer. For example, in section 5.5 of pre02, the next to last paragraph, one could refer to section 4.1.1 of RFC2473 (Tunnel Encapsulation Limit Option). > o I do not think you should spend too much effort on optimizing the > parts of MIPv6 that you need or do not need. Remember that CN side RO > is already a SHOULD in the IPv6 node requirements. I agree with this too. Alex From nemo-admin@ietf.org Thu Dec 11 21:29:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08112 for ; Thu, 11 Dec 2003 21:29: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 1AUd36-0008Rg-Mi; Thu, 11 Dec 2003 21:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUd2g-0008RJ-6D for nemo@optimus.ietf.org; Thu, 11 Dec 2003 21:28: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 VAA08096 for ; Thu, 11 Dec 2003 21:28:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUd2d-0000vn-00 for nemo@ietf.org; Thu, 11 Dec 2003 21:28:31 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AUd2c-0000vi-00 for nemo@ietf.org; Thu, 11 Dec 2003 21:28:30 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hBC2Rv031346; Thu, 11 Dec 2003 18:27:57 -0800 X-mProtect: <200312120227> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDRPwdj; Thu, 11 Dec 2003 18:27:55 PST Message-ID: <3FD9291D.3010608@iprg.nokia.com> Date: Thu, 11 Dec 2003 18:34:05 -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: Jari Arkko , nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] SPD entries for routing protocol messages Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 Jari, check out draft-ietf-ospf-ospfv3-auth-04.txt. it is a WG document in the OSPF WG. it describes SPD entries needed to protect OSPF messages. however the draft says transport mode MUST be used because it assumes OSPF messages are exchanged only between routers acting as hosts. > OSPFv3 packets are exchanged between the routers > but as the packets are destined to the routers, the routers act like > hosts in this case. So transport mode SA MUST be used in order to > provide required security to OSPFv3. in NEMO, the routing protocol messages are not forwarded. the destination address on the routing protocol messages is either the mobile router's address or the Home Agent's address inside the tunnel interface between the Home Agent and Mobile Router. if we assume the bi-directional tunnel to be a virtual link, then RFC 2740 (OSPFv3) says On virtual links, global scope or site-local IP addresses must be used as the source for OSPF protocol packets. so, an OSPFv3 packet from HA to MR could look like the following. IPv6 hdr (src=HA, dst=MR_CoA) IPv6 hdr (src=HA, dst=MR_HoA) ESP hdr OSPFv3 payload maybe we have to just reference the above mentioned draft. what do you think? Vijay From exim@www1.ietf.org Thu Dec 11 21:29:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08127 for ; Thu, 11 Dec 2003 21:29: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 1AUd39-0008Sk-By for nemo-archive@odin.ietf.org; Thu, 11 Dec 2003 21:29:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC2T3MH032524 for nemo-archive@odin.ietf.org; Thu, 11 Dec 2003 21:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUd39-0008SV-6i for nemo-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 21:29: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 VAA08105 for ; Thu, 11 Dec 2003 21:29:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUd36-0000w5-00 for nemo-web-archive@ietf.org; Thu, 11 Dec 2003 21:29:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUd36-0000w0-00 for nemo-web-archive@ietf.org; Thu, 11 Dec 2003 21:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUd36-0008Rg-Mi; Thu, 11 Dec 2003 21:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUd2g-0008RJ-6D for nemo@optimus.ietf.org; Thu, 11 Dec 2003 21:28: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 VAA08096 for ; Thu, 11 Dec 2003 21:28:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUd2d-0000vn-00 for nemo@ietf.org; Thu, 11 Dec 2003 21:28:31 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AUd2c-0000vi-00 for nemo@ietf.org; Thu, 11 Dec 2003 21:28:30 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hBC2Rv031346; Thu, 11 Dec 2003 18:27:57 -0800 X-mProtect: <200312120227> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDRPwdj; Thu, 11 Dec 2003 18:27:55 PST Message-ID: <3FD9291D.3010608@iprg.nokia.com> Date: Thu, 11 Dec 2003 18:34:05 -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: Jari Arkko , nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] SPD entries for routing protocol messages Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Jari, check out draft-ietf-ospf-ospfv3-auth-04.txt. it is a WG document in the OSPF WG. it describes SPD entries needed to protect OSPF messages. however the draft says transport mode MUST be used because it assumes OSPF messages are exchanged only between routers acting as hosts. > OSPFv3 packets are exchanged between the routers > but as the packets are destined to the routers, the routers act like > hosts in this case. So transport mode SA MUST be used in order to > provide required security to OSPFv3. in NEMO, the routing protocol messages are not forwarded. the destination address on the routing protocol messages is either the mobile router's address or the Home Agent's address inside the tunnel interface between the Home Agent and Mobile Router. if we assume the bi-directional tunnel to be a virtual link, then RFC 2740 (OSPFv3) says On virtual links, global scope or site-local IP addresses must be used as the source for OSPF protocol packets. so, an OSPFv3 packet from HA to MR could look like the following. IPv6 hdr (src=HA, dst=MR_CoA) IPv6 hdr (src=HA, dst=MR_HoA) ESP hdr OSPFv3 payload maybe we have to just reference the above mentioned draft. what do you think? Vijay From nemo-admin@ietf.org Fri Dec 12 06:15:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04302 for ; Fri, 12 Dec 2003 06:15: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 1AUlG9-0005RR-PF; Fri, 12 Dec 2003 06:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUlFz-0005NI-WE for nemo@optimus.ietf.org; Fri, 12 Dec 2003 06:14: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 GAA04275 for ; Fri, 12 Dec 2003 06:14:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUlFw-00029o-00 for nemo@ietf.org; Fri, 12 Dec 2003 06:14:48 -0500 Received: from roura.ac.upc.es ([147.83.33.10]) by ietf-mx with esmtp (Exim 4.12) id 1AUlFv-00029Y-00 for nemo@ietf.org; Fri, 12 Dec 2003 06:14:47 -0500 Received: from rogent.ac.upc.es (rogent.ac.upc.es [147.83.31.7]) by roura.ac.upc.es (8.12.8/8.12.8) with ESMTP id hBCBEHJA026968 for ; Fri, 12 Dec 2003 12:14:17 +0100 (MET) Received: (from ew2004@localhost) by rogent.ac.upc.es (8.12.8/8.12.8) id hBCBEHmK011032 for nemo@ietf.org; Fri, 12 Dec 2003 12:14:17 +0100 (MET) Date: Fri, 12 Dec 2003 12:14:17 +0100 From: Conferencia ew2004 To: nemo@ietf.org Message-ID: <20031212111417.GA11023@ac.upc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [nemo] EW2004 Tutorial and Conference Program Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Dear Colleague, Accept our apologies if you receive multiple copies of this e-mail. Please, find the Tutorial and Conference program for the The 5th European Wireless Conference (EW2004) Mobile and Wireless Systems beyond 3G to be held in Barcelona, Spain in February 24-27, 2004. You can find them at "Conference Program" and "Tutorials" links in http://www.ac.upc.es/EW2004 Looking forward to see you in Barcelona, EW2004 organizing committee. From exim@www1.ietf.org Fri Dec 12 06:15:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04320 for ; Fri, 12 Dec 2003 06:15:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUlGb-0005aL-1U for nemo-archive@odin.ietf.org; Fri, 12 Dec 2003 06:15:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCBFTqx021463 for nemo-archive@odin.ietf.org; Fri, 12 Dec 2003 06:15:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUlGa-0005a6-Q8 for nemo-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 06:15: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 GAA04284 for ; Fri, 12 Dec 2003 06:15:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUlGW-0002AB-00 for nemo-web-archive@ietf.org; Fri, 12 Dec 2003 06:15:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUlGW-00029z-00 for nemo-web-archive@ietf.org; Fri, 12 Dec 2003 06:15:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUlG9-0005RR-PF; Fri, 12 Dec 2003 06:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUlFz-0005NI-WE for nemo@optimus.ietf.org; Fri, 12 Dec 2003 06:14: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 GAA04275 for ; Fri, 12 Dec 2003 06:14:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUlFw-00029o-00 for nemo@ietf.org; Fri, 12 Dec 2003 06:14:48 -0500 Received: from roura.ac.upc.es ([147.83.33.10]) by ietf-mx with esmtp (Exim 4.12) id 1AUlFv-00029Y-00 for nemo@ietf.org; Fri, 12 Dec 2003 06:14:47 -0500 Received: from rogent.ac.upc.es (rogent.ac.upc.es [147.83.31.7]) by roura.ac.upc.es (8.12.8/8.12.8) with ESMTP id hBCBEHJA026968 for ; Fri, 12 Dec 2003 12:14:17 +0100 (MET) Received: (from ew2004@localhost) by rogent.ac.upc.es (8.12.8/8.12.8) id hBCBEHmK011032 for nemo@ietf.org; Fri, 12 Dec 2003 12:14:17 +0100 (MET) Date: Fri, 12 Dec 2003 12:14:17 +0100 From: Conferencia ew2004 To: nemo@ietf.org Message-ID: <20031212111417.GA11023@ac.upc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [nemo] EW2004 Tutorial and Conference Program Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Dear Colleague, Accept our apologies if you receive multiple copies of this e-mail. Please, find the Tutorial and Conference program for the The 5th European Wireless Conference (EW2004) Mobile and Wireless Systems beyond 3G to be held in Barcelona, Spain in February 24-27, 2004. You can find them at "Conference Program" and "Tutorials" links in http://www.ac.upc.es/EW2004 Looking forward to see you in Barcelona, EW2004 organizing committee. From nemo-admin@ietf.org Fri Dec 12 10:10:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10744 for ; Fri, 12 Dec 2003 10:10: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 1AUovb-0006Fd-6e; Fri, 12 Dec 2003 10:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUoun-0006EE-9P for nemo@optimus.ietf.org; Fri, 12 Dec 2003 10:09: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 KAA10597 for ; Fri, 12 Dec 2003 10:09:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUoul-0006WI-00 for nemo@ietf.org; Fri, 12 Dec 2003 10:09:11 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AUouk-0006VH-00 for nemo@ietf.org; Fri, 12 Dec 2003 10:09:10 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 12 Dec 2003 16:05:40 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hBCF8NlR010689; Fri, 12 Dec 2003 16:08:23 +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, 12 Dec 2003 15:08:37 +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 Subject: RE: [nemo] RE: Closing Issue 27 Date: Fri, 12 Dec 2003 15:08:36 -0000 Message-ID: Thread-Topic: [nemo] RE: Closing Issue 27 Thread-Index: AcO/X1HRwcIKHZzpTTu6036XUH2gGQAVZEPg From: "Pascal Thubert (pthubert)" To: "Jari Arkko" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 12 Dec 2003 15:08:37.0578 (UTC) FILETIME=[D1B13AA0:01C3C0C1] 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 > o I agree with Vijay that BUL needs to be a list, if not > for multiple registrations per home address, at least for > the possibility of multiple home addresses / home agents. >=20 I see confusion between HAs and bindings. With basic Nemo, a MR needs to maintain one active binding. Nothing more is required. Even though a MR maintains a list of HA. Different objects.=20 More than one active binding is multihoming which is clearly out of scope. The spec does not prevent it but it must not MUST it... Anyway, we lost too much time on this. It's impossible to see from the outside if an implementation that supports only one active binding has a list or not. >=20 > o I do not think you should spend too much effort on > optimizing the parts of MIPv6 that you need or do not > need. Remember that CN side RO is already a SHOULD > in the IPv6 node requirements. >=20 Agreed. =20 Pascal From exim@www1.ietf.org Fri Dec 12 10:10:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10761 for ; Fri, 12 Dec 2003 10:10: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 1AUovi-0006H0-Di for nemo-archive@odin.ietf.org; Fri, 12 Dec 2003 10:10:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCFAAa4024108 for nemo-archive@odin.ietf.org; Fri, 12 Dec 2003 10:10:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUovi-0006Gl-7M for nemo-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 10:10: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 KAA10716 for ; Fri, 12 Dec 2003 10:10:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUovg-0006Yq-00 for nemo-web-archive@ietf.org; Fri, 12 Dec 2003 10:10:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUovf-0006Yn-00 for nemo-web-archive@ietf.org; Fri, 12 Dec 2003 10:10:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUovb-0006Fd-6e; Fri, 12 Dec 2003 10:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUoun-0006EE-9P for nemo@optimus.ietf.org; Fri, 12 Dec 2003 10:09: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 KAA10597 for ; Fri, 12 Dec 2003 10:09:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUoul-0006WI-00 for nemo@ietf.org; Fri, 12 Dec 2003 10:09:11 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AUouk-0006VH-00 for nemo@ietf.org; Fri, 12 Dec 2003 10:09:10 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 12 Dec 2003 16:05:40 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hBCF8NlR010689; Fri, 12 Dec 2003 16:08:23 +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, 12 Dec 2003 15:08:37 +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 Subject: RE: [nemo] RE: Closing Issue 27 Date: Fri, 12 Dec 2003 15:08:36 -0000 Message-ID: Thread-Topic: [nemo] RE: Closing Issue 27 Thread-Index: AcO/X1HRwcIKHZzpTTu6036XUH2gGQAVZEPg From: "Pascal Thubert (pthubert)" To: "Jari Arkko" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 12 Dec 2003 15:08:37.0578 (UTC) FILETIME=[D1B13AA0:01C3C0C1] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > o I agree with Vijay that BUL needs to be a list, if not > for multiple registrations per home address, at least for > the possibility of multiple home addresses / home agents. >=20 I see confusion between HAs and bindings. With basic Nemo, a MR needs to maintain one active binding. Nothing more is required. Even though a MR maintains a list of HA. Different objects.=20 More than one active binding is multihoming which is clearly out of scope. The spec does not prevent it but it must not MUST it... Anyway, we lost too much time on this. It's impossible to see from the outside if an implementation that supports only one active binding has a list or not. >=20 > o I do not think you should spend too much effort on > optimizing the parts of MIPv6 that you need or do not > need. Remember that CN side RO is already a SHOULD > in the IPv6 node requirements. >=20 Agreed. =20 Pascal From nemo-admin@ietf.org Fri Dec 12 13:45:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19641 for ; Fri, 12 Dec 2003 13:45: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 1AUsHd-00018u-IZ; Fri, 12 Dec 2003 13:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrwH-0008Kk-08 for nemo@optimus.ietf.org; Fri, 12 Dec 2003 13:22: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 NAA18843; Fri, 12 Dec 2003 13:22:52 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUrwE-0003Os-00; Fri, 12 Dec 2003 13:22:54 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AUrwE-0003Oi-00; Fri, 12 Dec 2003 13:22:54 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBCIMqH06680; Fri, 12 Dec 2003 20:22:52 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Dec 2003 20:22:51 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Dec 2003 10:22:05 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 12 Dec 2003 13:22:03 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B808E91E@ajebe001.americas.nokia.com> Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcPAj3+GI+jb/BV5TZKaev9kPOSWVAASdmZA To: , Cc: , X-OriginalArrivalTime: 12 Dec 2003 18:22:05.0078 (UTC) FILETIME=[D84D2B60:01C3C0DC] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: [rohc] IP Address Compression for Context Replication Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 Lars-Erik, One scenario is the mobile router case. I think Yousuf already mentioned this a few times. But for some reason, it seems it has been ignored. The scenario is quite simple: a subnet behind a router which connects=20 to the Internet via a bandwidth-limited link. For example, a PAN = (personal area network) or a subnet on a train, plane, etc. ROHC can reside in the router to compress headers that are sent over the link. There is already a related WG called nemo: http://www.ietf.org/html.charters/nemo-charter.html. You can find more=20 details there. But above few words should already give you a good = picture. Even for case of last-link header compression, IP address compression is also useful if the endpoint can refer to a context that contains at least IP address prefix. It is true that the ROHC channels are=20 different between different endpoints and the HC entity on the=20 network side. So this is a small technical issue on how to refer to a context from another channel. But, one simple solution could be to=20 use a common context that is independent of channels. BR, Zhigang > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of ext > Lars-Erik Jonsson (LU/EAB) > Sent: December 12, 2003 03:05 AM > To: Saifullah Yousuf (NRC/Dallas) > Cc: rohc@ietf.org > Subject: RE: [rohc] IP Address Compression for Context Replication >=20 >=20 > Yousuf, >=20 > Please explain in more detail the scenarios you are addressing, > so that we can better understand the reason you think this is > important. At the moment, people do not seem to think this is > really needed, but we should make sure we do not decide before > we have all understood the arguments (first then can we have an > opinion on how to proceed). >=20 > Thanks! > /L-E >=20 > > -----Original Message----- > > From: Yousuf.Saifullah@nokia.com [mailto:Yousuf.Saifullah@nokia.com] > > Sent: den 12 december 2003 01:40 > > To: Lars-Erik Jonsson (LU/EAB); kristofer.sandlund@effnet.com; > > zhigang.c.liu@nokia.com > > Cc: mark.a.west@roke.co.uk; rohc@ietf.org > > Subject: RE: [rohc] IP Address Compression for Context Replication > >=20 > >=20 > > Hi Lars-Erik, > > My point is that multiple host scenario is not uncommon to=20 > > ignore. We should not limit the HC in the way you mentioned=20 > > below. Moreover, the decision should be made based on cost=20 > > vs. gain analysis. Again over here also we should not limit=20 > > to HTTP 1.0 and IPv4. > >=20 > > Regards, > > Yousuf > >=20 > > > -----Original Message----- > > > From: ext Lars-Erik Jonsson (LU/EAB) > > > [mailto:lars-erik.jonsson@ericsson.com] > > > Sent: Thursday, December 11, 2003 3:21 AM > > > To: Saifullah Yousuf (NRC/Dallas);=20 > > kristofer.sandlund@effnet.com; Liu > > > Zhigang.C (NRC/Dallas) > > > Cc: mark.a.west@roke.co.uk; rohc@ietf.org > > > Subject: RE: [rohc] IP Address Compression for Context Replication > > >=20 > > >=20 > > > Yousuf, > > >=20 > > > > I have given this number before. I am repeating it here again. > > > > If we have m multiple hosts in the system with compressible IP > > > > addresses, then the saving is m*(gain per flow). The saving > > > > will be 55*m bits for HTTP 1.1./IPv6.=20 > > >=20 > > > Consider the most common scenario for HC, i.e. compression over > > > the last link to a single end host. There you usually only have > > > ONE single host on the link, which means one address is always > > > the same (replicable), while other addresses are totally random > > > (only replicable when we have multiple connections to the same > > > peer host). > > >=20 > > > /L-E > > >=20 > >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 From exim@www1.ietf.org Fri Dec 12 13:45:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19656 for ; Fri, 12 Dec 2003 13:45: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 1AUsHg-0001A7-Sh for nemo-archive@odin.ietf.org; Fri, 12 Dec 2003 13:45:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCIj4Lk004461 for nemo-archive@odin.ietf.org; Fri, 12 Dec 2003 13:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUsHg-00019s-O4 for nemo-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 13:45: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 NAA19627 for ; Fri, 12 Dec 2003 13:45:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUsHe-0003nJ-00 for nemo-web-archive@ietf.org; Fri, 12 Dec 2003 13:45:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUsHe-0003nG-00 for nemo-web-archive@ietf.org; Fri, 12 Dec 2003 13:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUsHd-00018u-IZ; Fri, 12 Dec 2003 13:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrwH-0008Kk-08 for nemo@optimus.ietf.org; Fri, 12 Dec 2003 13:22: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 NAA18843; Fri, 12 Dec 2003 13:22:52 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUrwE-0003Os-00; Fri, 12 Dec 2003 13:22:54 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AUrwE-0003Oi-00; Fri, 12 Dec 2003 13:22:54 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBCIMqH06680; Fri, 12 Dec 2003 20:22:52 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Dec 2003 20:22:51 +0200 Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Dec 2003 10:22:05 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 12 Dec 2003 13:22:03 -0500 Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B808E91E@ajebe001.americas.nokia.com> Thread-Topic: [rohc] IP Address Compression for Context Replication Thread-Index: AcPAj3+GI+jb/BV5TZKaev9kPOSWVAASdmZA To: , Cc: , X-OriginalArrivalTime: 12 Dec 2003 18:22:05.0078 (UTC) FILETIME=[D84D2B60:01C3C0DC] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: [rohc] IP Address Compression for Context Replication Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Lars-Erik, One scenario is the mobile router case. I think Yousuf already mentioned this a few times. But for some reason, it seems it has been ignored. The scenario is quite simple: a subnet behind a router which connects=20 to the Internet via a bandwidth-limited link. For example, a PAN = (personal area network) or a subnet on a train, plane, etc. ROHC can reside in the router to compress headers that are sent over the link. There is already a related WG called nemo: http://www.ietf.org/html.charters/nemo-charter.html. You can find more=20 details there. But above few words should already give you a good = picture. Even for case of last-link header compression, IP address compression is also useful if the endpoint can refer to a context that contains at least IP address prefix. It is true that the ROHC channels are=20 different between different endpoints and the HC entity on the=20 network side. So this is a small technical issue on how to refer to a context from another channel. But, one simple solution could be to=20 use a common context that is independent of channels. BR, Zhigang > -----Original Message----- > From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of ext > Lars-Erik Jonsson (LU/EAB) > Sent: December 12, 2003 03:05 AM > To: Saifullah Yousuf (NRC/Dallas) > Cc: rohc@ietf.org > Subject: RE: [rohc] IP Address Compression for Context Replication >=20 >=20 > Yousuf, >=20 > Please explain in more detail the scenarios you are addressing, > so that we can better understand the reason you think this is > important. At the moment, people do not seem to think this is > really needed, but we should make sure we do not decide before > we have all understood the arguments (first then can we have an > opinion on how to proceed). >=20 > Thanks! > /L-E >=20 > > -----Original Message----- > > From: Yousuf.Saifullah@nokia.com [mailto:Yousuf.Saifullah@nokia.com] > > Sent: den 12 december 2003 01:40 > > To: Lars-Erik Jonsson (LU/EAB); kristofer.sandlund@effnet.com; > > zhigang.c.liu@nokia.com > > Cc: mark.a.west@roke.co.uk; rohc@ietf.org > > Subject: RE: [rohc] IP Address Compression for Context Replication > >=20 > >=20 > > Hi Lars-Erik, > > My point is that multiple host scenario is not uncommon to=20 > > ignore. We should not limit the HC in the way you mentioned=20 > > below. Moreover, the decision should be made based on cost=20 > > vs. gain analysis. Again over here also we should not limit=20 > > to HTTP 1.0 and IPv4. > >=20 > > Regards, > > Yousuf > >=20 > > > -----Original Message----- > > > From: ext Lars-Erik Jonsson (LU/EAB) > > > [mailto:lars-erik.jonsson@ericsson.com] > > > Sent: Thursday, December 11, 2003 3:21 AM > > > To: Saifullah Yousuf (NRC/Dallas);=20 > > kristofer.sandlund@effnet.com; Liu > > > Zhigang.C (NRC/Dallas) > > > Cc: mark.a.west@roke.co.uk; rohc@ietf.org > > > Subject: RE: [rohc] IP Address Compression for Context Replication > > >=20 > > >=20 > > > Yousuf, > > >=20 > > > > I have given this number before. I am repeating it here again. > > > > If we have m multiple hosts in the system with compressible IP > > > > addresses, then the saving is m*(gain per flow). The saving > > > > will be 55*m bits for HTTP 1.1./IPv6.=20 > > >=20 > > > Consider the most common scenario for HC, i.e. compression over > > > the last link to a single end host. There you usually only have > > > ONE single host on the link, which means one address is always > > > the same (replicable), while other addresses are totally random > > > (only replicable when we have multiple connections to the same > > > peer host). > > >=20 > > > /L-E > > >=20 > >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 From nemo-admin@ietf.org Sun Dec 14 19:18:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03329 for ; Sun, 14 Dec 2003 19:18: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 1AVgQz-0000UB-MC; Sun, 14 Dec 2003 19: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 1AVgQo-0000T1-R7 for nemo@optimus.ietf.org; Sun, 14 Dec 2003 19:17: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 TAA03264; Sun, 14 Dec 2003 19:17:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVgQm-0006t5-00; Sun, 14 Dec 2003 19:17:48 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AVgQm-0006t0-00; Sun, 14 Dec 2003 19:17:48 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hBF0HjY9024113; Mon, 15 Dec 2003 09:17:46 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hBF0HjiE010065; Mon, 15 Dec 2003 09:17:45 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA10062 ; Mon, 15 Dec 2003 09:17:45 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA03597; Mon, 15 Dec 2003 09:17:45 +0900 (JST) Received: from isl.rdc.toshiba.co.jp by toshiba.co.jp id JAA03834; Mon, 15 Dec 2003 09:17:44 +0900 (JST) Received: from localhost (inoue@flowerpark [133.196.16.25]) by isl.rdc.toshiba.co.jp (8.11.7/8.11.6/1.4) with ESMTP id hBF0Hh125636; Mon, 15 Dec 2003 09:17:43 +0900 (JST) To: nemo@ietf.org, mip6@ietf.org, mipshop@ietf.org, mip4@ietf.org, pana@ietf.org In-Reply-To: Your message of "Sat, 13 Dec 2003 10:55:08 +0900" <20031213105508E.inoue@isl.rdc.toshiba.co.jp> References: <20031213105508E.inoue@isl.rdc.toshiba.co.jp> X-Mailer: Mew version 1.93 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20031215091743J.inoue@isl.rdc.toshiba.co.jp> Date: Mon, 15 Dec 2003 09:17:43 +0900 From: Atsushi Inoue X-Dispatcher: imput version 980905(IM100) Lines: 126 Content-Transfer-Encoding: 7bit Subject: [nemo] Call for participation: ICMU2004 Jan.8-9 at Yokosuka Japan Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 (Apologies if you receive multiple copies) CALL FOR Participation ====================== First International Conference on Mobile Computing and Ubiquitous Networking (ICMU 2004) January 8 and 9, 2004 NTT DoCoMo R&D Center, Yokosuka Research Park, Yokosuka, JAPAN Co-sponsored by IPSJ SIG-MBL (Informaiton Processing Society of Japan, Special Interest Group of Mobile Computing and Ubiquitous Networking) and IPSJ SG-BCC (Study Group of Broadcast Communicaiton and Computing) Advanced Program: ~~~~~~~~~~~~~~~~~ See http://www.ipsj.or.jp/sig/mbl/icmu2004/ Scope ~~~~~~ Mobile computing aims at ubiquitous user access to computer application. To make it possible, networking technology which enables Internet access anytime and everywhere, i.e. ubiquitous networking is necessary. It is obvious that with the accelerating trends towards mobile networks, ad-hoc networks, and wireless networks, mobile computing and ubiquitous networking will play an important role in future network. This conference is aimed at providing researchers and practitioners in this hot research area a forum for discussion and collaboration. Authors are invited to submit papers addressing, but not limited to, the following topics: - Applications and services for mobile computing - Network architectures, protocols, or service models for ubiquitous networking - Network management for ubiquitous networking - Data management for mobile computing - Security in mobile computing and ubiquitous networking - Wireless and mobile communications - Nomadic computing - Ad-hoc networks - Mobile Internetworking - Performance evaluation for mobile computing and ubiquitous networking systems - Location Based Service - Broadcast Communication Location and Date: ~~~~~~~~~~~~~~~~~~ The location of the NTT DoCoMo R&D Center is in the heart of Yokosuka Research Park(YRP) where a lot of wireless communication related research institutes are established. YRP is really the heart of wireless communications research in Japan. Japanese old city Kamakura, a famous historic city, is 30 minutes by train. Beginning of the year is one of the best seasons for visiting Japan. --- Susumu ISHIHARA Faculty of Engineering, Shizuoka University 3-5-1 Johoku, Hamamatsu 432-8561, JAPAN ishiahra@ishilab.net http://www.ishilab.net/ (Apologies if you receive multiple copies) CALL FOR Participation ====================== First International Conference on Mobile Computing and Ubiquitous Networking (ICMU 2004) January 8 and 9, 2004 NTT DoCoMo R&D Center, Yokosuka Research Park, Yokosuka, JAPAN Co-sponsored by IPSJ SIG-MBL (Informaiton Processing Society of Japan, Special Interest Group of Mobile Computing and Ubiquitous Networking) and IPSJ SG-BCC (Study Group of Broadcast Communicaiton and Computing) Advanced Program: ~~~~~~~~~~~~~~~~~ See http://www.ipsj.or.jp/sig/mbl/icmu2004/ Scope ~~~~~~ Mobile computing aims at ubiquitous user access to computer application. To make it possible, networking technology which enables Internet access anytime and everywhere, i.e. ubiquitous networking is necessary. It is obvious that with the accelerating trends towards mobile networks, ad-hoc networks, and wireless networks, mobile computing and ubiquitous networking will play an important role in future network. This conference is aimed at providing researchers and practitioners in this hot research area a forum for discussion and collaboration. Authors are invited to submit papers addressing, but not limited to, the following topics: - Applications and services for mobile computing - Network architectures, protocols, or service models for ubiquitous networking - Network management for ubiquitous networking - Data management for mobile computing - Security in mobile computing and ubiquitous networking - Wireless and mobile communications - Nomadic computing - Ad-hoc networks - Mobile Internetworking - Performance evaluation for mobile computing and ubiquitous networking systems - Location Based Service - Broadcast Communication Location and Date: ~~~~~~~~~~~~~~~~~~ The location of the NTT DoCoMo R&D Center is in the heart of Yokosuka Research Park(YRP) where a lot of wireless communication related research institutes are established. YRP is really the heart of wireless communications research in Japan. Japanese old city Kamakura, a famous historic city, is 30 minutes by train. Beginning of the year is one of the best seasons for visiting Japan. --- Susumu ISHIHARA Faculty of Engineering, Shizuoka University 3-5-1 Johoku, Hamamatsu 432-8561, JAPAN ishiahra@ishilab.net http://www.ishilab.net/ From exim@www1.ietf.org Sun Dec 14 19:18:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03361 for ; Sun, 14 Dec 2003 19:18: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 1AVgR3-0000Wb-W2 for nemo-archive@odin.ietf.org; Sun, 14 Dec 2003 19:18:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBF0I5J9002011 for nemo-archive@odin.ietf.org; Sun, 14 Dec 2003 19:18:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVgR3-0000WK-PD for nemo-web-archive@optimus.ietf.org; Sun, 14 Dec 2003 19:18: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 TAA03292 for ; Sun, 14 Dec 2003 19:18:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVgR2-0006tq-00 for nemo-web-archive@ietf.org; Sun, 14 Dec 2003 19:18:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVgR1-0006th-00 for nemo-web-archive@ietf.org; Sun, 14 Dec 2003 19:18:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVgQz-0000UB-MC; Sun, 14 Dec 2003 19: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 1AVgQo-0000T1-R7 for nemo@optimus.ietf.org; Sun, 14 Dec 2003 19:17: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 TAA03264; Sun, 14 Dec 2003 19:17:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVgQm-0006t5-00; Sun, 14 Dec 2003 19:17:48 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AVgQm-0006t0-00; Sun, 14 Dec 2003 19:17:48 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hBF0HjY9024113; Mon, 15 Dec 2003 09:17:46 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hBF0HjiE010065; Mon, 15 Dec 2003 09:17:45 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA10062 ; Mon, 15 Dec 2003 09:17:45 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA03597; Mon, 15 Dec 2003 09:17:45 +0900 (JST) Received: from isl.rdc.toshiba.co.jp by toshiba.co.jp id JAA03834; Mon, 15 Dec 2003 09:17:44 +0900 (JST) Received: from localhost (inoue@flowerpark [133.196.16.25]) by isl.rdc.toshiba.co.jp (8.11.7/8.11.6/1.4) with ESMTP id hBF0Hh125636; Mon, 15 Dec 2003 09:17:43 +0900 (JST) To: nemo@ietf.org, mip6@ietf.org, mipshop@ietf.org, mip4@ietf.org, pana@ietf.org In-Reply-To: Your message of "Sat, 13 Dec 2003 10:55:08 +0900" <20031213105508E.inoue@isl.rdc.toshiba.co.jp> References: <20031213105508E.inoue@isl.rdc.toshiba.co.jp> X-Mailer: Mew version 1.93 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20031215091743J.inoue@isl.rdc.toshiba.co.jp> Date: Mon, 15 Dec 2003 09:17:43 +0900 From: Atsushi Inoue X-Dispatcher: imput version 980905(IM100) Lines: 126 Content-Transfer-Encoding: 7bit Subject: [nemo] Call for participation: ICMU2004 Jan.8-9 at Yokosuka Japan Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (Apologies if you receive multiple copies) CALL FOR Participation ====================== First International Conference on Mobile Computing and Ubiquitous Networking (ICMU 2004) January 8 and 9, 2004 NTT DoCoMo R&D Center, Yokosuka Research Park, Yokosuka, JAPAN Co-sponsored by IPSJ SIG-MBL (Informaiton Processing Society of Japan, Special Interest Group of Mobile Computing and Ubiquitous Networking) and IPSJ SG-BCC (Study Group of Broadcast Communicaiton and Computing) Advanced Program: ~~~~~~~~~~~~~~~~~ See http://www.ipsj.or.jp/sig/mbl/icmu2004/ Scope ~~~~~~ Mobile computing aims at ubiquitous user access to computer application. To make it possible, networking technology which enables Internet access anytime and everywhere, i.e. ubiquitous networking is necessary. It is obvious that with the accelerating trends towards mobile networks, ad-hoc networks, and wireless networks, mobile computing and ubiquitous networking will play an important role in future network. This conference is aimed at providing researchers and practitioners in this hot research area a forum for discussion and collaboration. Authors are invited to submit papers addressing, but not limited to, the following topics: - Applications and services for mobile computing - Network architectures, protocols, or service models for ubiquitous networking - Network management for ubiquitous networking - Data management for mobile computing - Security in mobile computing and ubiquitous networking - Wireless and mobile communications - Nomadic computing - Ad-hoc networks - Mobile Internetworking - Performance evaluation for mobile computing and ubiquitous networking systems - Location Based Service - Broadcast Communication Location and Date: ~~~~~~~~~~~~~~~~~~ The location of the NTT DoCoMo R&D Center is in the heart of Yokosuka Research Park(YRP) where a lot of wireless communication related research institutes are established. YRP is really the heart of wireless communications research in Japan. Japanese old city Kamakura, a famous historic city, is 30 minutes by train. Beginning of the year is one of the best seasons for visiting Japan. --- Susumu ISHIHARA Faculty of Engineering, Shizuoka University 3-5-1 Johoku, Hamamatsu 432-8561, JAPAN ishiahra@ishilab.net http://www.ishilab.net/ (Apologies if you receive multiple copies) CALL FOR Participation ====================== First International Conference on Mobile Computing and Ubiquitous Networking (ICMU 2004) January 8 and 9, 2004 NTT DoCoMo R&D Center, Yokosuka Research Park, Yokosuka, JAPAN Co-sponsored by IPSJ SIG-MBL (Informaiton Processing Society of Japan, Special Interest Group of Mobile Computing and Ubiquitous Networking) and IPSJ SG-BCC (Study Group of Broadcast Communicaiton and Computing) Advanced Program: ~~~~~~~~~~~~~~~~~ See http://www.ipsj.or.jp/sig/mbl/icmu2004/ Scope ~~~~~~ Mobile computing aims at ubiquitous user access to computer application. To make it possible, networking technology which enables Internet access anytime and everywhere, i.e. ubiquitous networking is necessary. It is obvious that with the accelerating trends towards mobile networks, ad-hoc networks, and wireless networks, mobile computing and ubiquitous networking will play an important role in future network. This conference is aimed at providing researchers and practitioners in this hot research area a forum for discussion and collaboration. Authors are invited to submit papers addressing, but not limited to, the following topics: - Applications and services for mobile computing - Network architectures, protocols, or service models for ubiquitous networking - Network management for ubiquitous networking - Data management for mobile computing - Security in mobile computing and ubiquitous networking - Wireless and mobile communications - Nomadic computing - Ad-hoc networks - Mobile Internetworking - Performance evaluation for mobile computing and ubiquitous networking systems - Location Based Service - Broadcast Communication Location and Date: ~~~~~~~~~~~~~~~~~~ The location of the NTT DoCoMo R&D Center is in the heart of Yokosuka Research Park(YRP) where a lot of wireless communication related research institutes are established. YRP is really the heart of wireless communications research in Japan. Japanese old city Kamakura, a famous historic city, is 30 minutes by train. Beginning of the year is one of the best seasons for visiting Japan. --- Susumu ISHIHARA Faculty of Engineering, Shizuoka University 3-5-1 Johoku, Hamamatsu 432-8561, JAPAN ishiahra@ishilab.net http://www.ishilab.net/ From nemo-admin@ietf.org Mon Dec 15 07:01:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04399 for ; Mon, 15 Dec 2003 07:01: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 1AVrPJ-00082g-0V; Mon, 15 Dec 2003 07:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVrPF-000824-72 for nemo@optimus.ietf.org; Mon, 15 Dec 2003 07:00: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 HAA04382 for ; Mon, 15 Dec 2003 07:00:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVrPB-0002kV-00 for nemo@ietf.org; Mon, 15 Dec 2003 07:00:53 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AVrPA-0002kS-00 for nemo@ietf.org; Mon, 15 Dec 2003 07:00:52 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBFC0qI2001285; Mon, 15 Dec 2003 13:00:52 +0100 (MET) Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.75]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW7XLYVP; Mon, 15 Dec 2003 13:00:51 +0100 Message-ID: <3FDDA273.2090308@ericsson.com> Date: Mon, 15 Dec 2003 13:00:51 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 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: Vijay Devarapalli CC: Jari Arkko , nemo@ietf.org Subject: Re: [nemo] SPD entries for routing protocol messages References: <3FD9291D.3010608@iprg.nokia.com> In-Reply-To: <3FD9291D.3010608@iprg.nokia.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: , Content-Transfer-Encoding: 7bit Hi Vijay, Vijay Devarapalli wrote: > if we assume the bi-directional tunnel to be a virtual link, > then RFC 2740 (OSPFv3) says > > On virtual links, global scope or site-local IP addresses must be > used as the source for OSPF protocol packets. > Not that you are responsible for the wording of RFC 2740, but I'm curious why virtual links use the exception of global addresses. In IPv6, shouldn't all links be able to use link-local addresses? It is a more preferred approach, as you wouldn't have to assign a global prefix to that link, but instead just use link-local addresses. Point-to-point links between routers should not require global addresses. Now in this case maybe you can use the packet design as you speficy below, but are the inner packet addresses really the best choices? The addresses HA and MR_HoA actually belong to another link (the physical home link in case we don't have a virtual home link). Is this a problem? /Mattias > so, an OSPFv3 packet from HA to MR could look like the following. > > IPv6 hdr (src=HA, dst=MR_CoA) > IPv6 hdr (src=HA, dst=MR_HoA) > ESP hdr > OSPFv3 payload > > maybe we have to just reference the above mentioned draft. > > what do you think? > > Vijay > > From exim@www1.ietf.org Mon Dec 15 07:01:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04414 for ; Mon, 15 Dec 2003 07:01: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 1AVrPO-00083e-8f for nemo-archive@odin.ietf.org; Mon, 15 Dec 2003 07:01:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFC16QV030974 for nemo-archive@odin.ietf.org; Mon, 15 Dec 2003 07:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVrPO-00083V-40 for nemo-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 07:01: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 HAA04396 for ; Mon, 15 Dec 2003 07:01:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVrPJ-0002kb-00 for nemo-web-archive@ietf.org; Mon, 15 Dec 2003 07:01:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVrPJ-0002kY-00 for nemo-web-archive@ietf.org; Mon, 15 Dec 2003 07:01:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVrPJ-00082g-0V; Mon, 15 Dec 2003 07:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVrPF-000824-72 for nemo@optimus.ietf.org; Mon, 15 Dec 2003 07:00: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 HAA04382 for ; Mon, 15 Dec 2003 07:00:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVrPB-0002kV-00 for nemo@ietf.org; Mon, 15 Dec 2003 07:00:53 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AVrPA-0002kS-00 for nemo@ietf.org; Mon, 15 Dec 2003 07:00:52 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBFC0qI2001285; Mon, 15 Dec 2003 13:00:52 +0100 (MET) Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.75]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW7XLYVP; Mon, 15 Dec 2003 13:00:51 +0100 Message-ID: <3FDDA273.2090308@ericsson.com> Date: Mon, 15 Dec 2003 13:00:51 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 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: Vijay Devarapalli CC: Jari Arkko , nemo@ietf.org Subject: Re: [nemo] SPD entries for routing protocol messages References: <3FD9291D.3010608@iprg.nokia.com> In-Reply-To: <3FD9291D.3010608@iprg.nokia.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Vijay, Vijay Devarapalli wrote: > if we assume the bi-directional tunnel to be a virtual link, > then RFC 2740 (OSPFv3) says > > On virtual links, global scope or site-local IP addresses must be > used as the source for OSPF protocol packets. > Not that you are responsible for the wording of RFC 2740, but I'm curious why virtual links use the exception of global addresses. In IPv6, shouldn't all links be able to use link-local addresses? It is a more preferred approach, as you wouldn't have to assign a global prefix to that link, but instead just use link-local addresses. Point-to-point links between routers should not require global addresses. Now in this case maybe you can use the packet design as you speficy below, but are the inner packet addresses really the best choices? The addresses HA and MR_HoA actually belong to another link (the physical home link in case we don't have a virtual home link). Is this a problem? /Mattias > so, an OSPFv3 packet from HA to MR could look like the following. > > IPv6 hdr (src=HA, dst=MR_CoA) > IPv6 hdr (src=HA, dst=MR_HoA) > ESP hdr > OSPFv3 payload > > maybe we have to just reference the above mentioned draft. > > what do you think? > > Vijay > > From nemo-admin@ietf.org Mon Dec 15 12:08:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16915 for ; Mon, 15 Dec 2003 12: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 1AVwCQ-0004oe-5g; Mon, 15 Dec 2003 12:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVwBt-0004ja-MM for nemo@optimus.ietf.org; Mon, 15 Dec 2003 12:07: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 MAA16884 for ; Mon, 15 Dec 2003 12:07:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVwBs-0000q7-00 for nemo@ietf.org; Mon, 15 Dec 2003 12:07:28 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AVwBr-0000pv-00 for nemo@ietf.org; Mon, 15 Dec 2003 12:07:27 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hBFH6pF06413; Mon, 15 Dec 2003 09:06:51 -0800 X-mProtect: <200312151706> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQ5f5SJ; Mon, 15 Dec 2003 09:06:49 PST Message-ID: <3FDDEBAB.2010502@iprg.nokia.com> Date: Mon, 15 Dec 2003 09:13:15 -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: Mattias Pettersson CC: Jari Arkko , nemo@ietf.org Subject: Re: [nemo] SPD entries for routing protocol messages References: <3FD9291D.3010608@iprg.nokia.com> <3FDDA273.2090308@ericsson.com> In-Reply-To: <3FDDA273.2090308@ericsson.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: , Content-Transfer-Encoding: 7bit Mattias Pettersson wrote: >> if we assume the bi-directional tunnel to be a virtual link, >> then RFC 2740 (OSPFv3) says >> >> On virtual links, global scope or site-local IP addresses must be >> used as the source for OSPF protocol packets. >> > > Not that you are responsible for the wording of RFC 2740, but I'm > curious why virtual links use the exception of global addresses. In > IPv6, shouldn't all links be able to use link-local addresses? It is a > more preferred approach, as you wouldn't have to assign a global prefix > to that link, but instead just use link-local addresses. Point-to-point > links between routers should not require global addresses. > > Now in this case maybe you can use the packet design as you speficy > below, but are the inner packet addresses really the best choices? The > addresses HA and MR_HoA actually belong to another link (the physical > home link in case we don't have a virtual home link). I am fine with using link local addresses inside the tunnel. dont know why RFC 2740 says "global scope or site-local IP addresses must be used as the source for OSPF protocol packets". something that needs clarification in the OSPF WG. Vijay > > Is this a problem? > > /Mattias > >> so, an OSPFv3 packet from HA to MR could look like the following. >> >> IPv6 hdr (src=HA, dst=MR_CoA) >> IPv6 hdr (src=HA, dst=MR_HoA) >> ESP hdr >> OSPFv3 payload >> >> maybe we have to just reference the above mentioned draft. >> >> what do you think? >> >> Vijay >> >> > From exim@www1.ietf.org Mon Dec 15 12:08:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16930 for ; Mon, 15 Dec 2003 12:08: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 1AVwCW-0004pz-4a for nemo-archive@odin.ietf.org; Mon, 15 Dec 2003 12:08:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFH8706018581 for nemo-archive@odin.ietf.org; Mon, 15 Dec 2003 12:08:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVwCU-0004pT-Gx for nemo-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 12:08: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 MAA16907 for ; Mon, 15 Dec 2003 12:08:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVwCT-0000rk-00 for nemo-web-archive@ietf.org; Mon, 15 Dec 2003 12:08:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVwCS-0000rh-00 for nemo-web-archive@ietf.org; Mon, 15 Dec 2003 12:08:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVwCQ-0004oe-5g; Mon, 15 Dec 2003 12:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVwBt-0004ja-MM for nemo@optimus.ietf.org; Mon, 15 Dec 2003 12:07: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 MAA16884 for ; Mon, 15 Dec 2003 12:07:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVwBs-0000q7-00 for nemo@ietf.org; Mon, 15 Dec 2003 12:07:28 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AVwBr-0000pv-00 for nemo@ietf.org; Mon, 15 Dec 2003 12:07:27 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hBFH6pF06413; Mon, 15 Dec 2003 09:06:51 -0800 X-mProtect: <200312151706> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQ5f5SJ; Mon, 15 Dec 2003 09:06:49 PST Message-ID: <3FDDEBAB.2010502@iprg.nokia.com> Date: Mon, 15 Dec 2003 09:13:15 -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: Mattias Pettersson CC: Jari Arkko , nemo@ietf.org Subject: Re: [nemo] SPD entries for routing protocol messages References: <3FD9291D.3010608@iprg.nokia.com> <3FDDA273.2090308@ericsson.com> In-Reply-To: <3FDDA273.2090308@ericsson.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mattias Pettersson wrote: >> if we assume the bi-directional tunnel to be a virtual link, >> then RFC 2740 (OSPFv3) says >> >> On virtual links, global scope or site-local IP addresses must be >> used as the source for OSPF protocol packets. >> > > Not that you are responsible for the wording of RFC 2740, but I'm > curious why virtual links use the exception of global addresses. In > IPv6, shouldn't all links be able to use link-local addresses? It is a > more preferred approach, as you wouldn't have to assign a global prefix > to that link, but instead just use link-local addresses. Point-to-point > links between routers should not require global addresses. > > Now in this case maybe you can use the packet design as you speficy > below, but are the inner packet addresses really the best choices? The > addresses HA and MR_HoA actually belong to another link (the physical > home link in case we don't have a virtual home link). I am fine with using link local addresses inside the tunnel. dont know why RFC 2740 says "global scope or site-local IP addresses must be used as the source for OSPF protocol packets". something that needs clarification in the OSPF WG. Vijay > > Is this a problem? > > /Mattias > >> so, an OSPFv3 packet from HA to MR could look like the following. >> >> IPv6 hdr (src=HA, dst=MR_CoA) >> IPv6 hdr (src=HA, dst=MR_HoA) >> ESP hdr >> OSPFv3 payload >> >> maybe we have to just reference the above mentioned draft. >> >> what do you think? >> >> Vijay >> >> > From nemo-admin@ietf.org Tue Dec 16 07:20:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12823 for ; Tue, 16 Dec 2003 07:20: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 1AWEBM-000808-97; Tue, 16 Dec 2003 07:20:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWEAe-0007yi-QI for nemo@optimus.ietf.org; Tue, 16 Dec 2003 07:19: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 HAA12783 for ; Tue, 16 Dec 2003 07:19:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWEAe-00075M-00 for nemo@ietf.org; Tue, 16 Dec 2003 07:19:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWEAd-00075F-00 for nemo@ietf.org; Tue, 16 Dec 2003 07:19:23 -0500 Received: from melanieb.vtt.fi ([130.188.1.12]) by ietf-mx with esmtp (Exim 4.12) id 1AWEAc-00073H-00 for nemo@ietf.org; Tue, 16 Dec 2003 07:19:23 -0500 Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi (8.12.9/8.12.9) with ESMTP id hBGCI035019882 for ; Tue, 16 Dec 2003 14:18:00 +0200 (EET) Received: from oulkv10326.vtt.fi (ele4114.ele.vtt.fi [130.188.94.114]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with ESMTP id OAA29256 for ; Tue, 16 Dec 2003 14:18:50 +0200 (EET) Message-Id: <4.3.2.7.2.20031216135829.00bda3a0@elemail.ele.vtt.fi> X-Sender: eleppa@elemail.ele.vtt.fi X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Dec 2003 14:09:13 +0200 To: nemo@ietf.org From: Pekka =?iso-8859-1?Q?P=E4=E4kk=F6nen?= Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed 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 Subject: [nemo] draft submission Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 all, I have submitted an individual draft, which focuses on IPv6 addressing in a heterogeneous MANET-network. Any comments on the subject are welcome. Pekka P=E4=E4kk=F6nen draft URL: http://www.ietf.org/internet-drafts/draft-paakkonen-addressing-htr-manet-00.= txt From exim@www1.ietf.org Tue Dec 16 07:20:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12838 for ; Tue, 16 Dec 2003 07:20: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 1AWEBT-00081u-I2 for nemo-archive@odin.ietf.org; Tue, 16 Dec 2003 07:20:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGCKFqw030860 for nemo-archive@odin.ietf.org; Tue, 16 Dec 2003 07:20:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWEBT-00081f-Bp for nemo-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 07:20: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 HAA12796 for ; Tue, 16 Dec 2003 07:20:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWEBS-00076g-00 for nemo-web-archive@ietf.org; Tue, 16 Dec 2003 07:20:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWEBR-00076X-00 for nemo-web-archive@ietf.org; Tue, 16 Dec 2003 07:20:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWEBR-00076T-00 for nemo-web-archive@ietf.org; Tue, 16 Dec 2003 07:20:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWEBM-000808-97; Tue, 16 Dec 2003 07:20:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWEAe-0007yi-QI for nemo@optimus.ietf.org; Tue, 16 Dec 2003 07:19: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 HAA12783 for ; Tue, 16 Dec 2003 07:19:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWEAe-00075M-00 for nemo@ietf.org; Tue, 16 Dec 2003 07:19:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWEAd-00075F-00 for nemo@ietf.org; Tue, 16 Dec 2003 07:19:23 -0500 Received: from melanieb.vtt.fi ([130.188.1.12]) by ietf-mx with esmtp (Exim 4.12) id 1AWEAc-00073H-00 for nemo@ietf.org; Tue, 16 Dec 2003 07:19:23 -0500 Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi (8.12.9/8.12.9) with ESMTP id hBGCI035019882 for ; Tue, 16 Dec 2003 14:18:00 +0200 (EET) Received: from oulkv10326.vtt.fi (ele4114.ele.vtt.fi [130.188.94.114]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with ESMTP id OAA29256 for ; Tue, 16 Dec 2003 14:18:50 +0200 (EET) Message-Id: <4.3.2.7.2.20031216135829.00bda3a0@elemail.ele.vtt.fi> X-Sender: eleppa@elemail.ele.vtt.fi X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Dec 2003 14:09:13 +0200 To: nemo@ietf.org From: Pekka =?iso-8859-1?Q?P=E4=E4kk=F6nen?= Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [nemo] draft submission Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 all, I have submitted an individual draft, which focuses on IPv6 addressing in a heterogeneous MANET-network. Any comments on the subject are welcome. Pekka P=E4=E4kk=F6nen draft URL: http://www.ietf.org/internet-drafts/draft-paakkonen-addressing-htr-manet-00.= txt From nemo-admin@ietf.org Tue Dec 16 08:26:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14828 for ; Tue, 16 Dec 2003 08:26: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 1AWFD9-0001Pe-6h; Tue, 16 Dec 2003 08:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWFD3-0001P0-EG for nemo@optimus.ietf.org; Tue, 16 Dec 2003 08:25: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 IAA14629 for ; Tue, 16 Dec 2003 08:25:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWFD2-00024q-00 for nemo@ietf.org; Tue, 16 Dec 2003 08:25:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWF9X-00021G-00 for nemo@ietf.org; Tue, 16 Dec 2003 08:22:20 -0500 Received: from plant.sfc.wide.ad.jp ([203.178.143.91]) by ietf-mx with esmtp (Exim 4.12) id 1AWF9W-00021B-00 for nemo@ietf.org; Tue, 16 Dec 2003 08:22:18 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 24F3929F50; Tue, 16 Dec 2003 22:22:15 +0900 (JST) Date: Tue, 16 Dec 2003 22:22:14 +0900 (JST) Message-Id: <20031216.222214.69509365.yasu@sfc.wide.ad.jp> To: vijayd@iprg.nokia.com Cc: mattias.l.pettersson@ericsson.com, jari.arkko@kolumbus.fi, nemo@ietf.org Subject: Re: [nemo] SPD entries for routing protocol messages From: Yasuhiro Ohara In-Reply-To: <3FDDEBAB.2010502@iprg.nokia.com> References: <3FD9291D.3010608@iprg.nokia.com> <3FDDA273.2090308@ericsson.com> <3FDDEBAB.2010502@iprg.nokia.com> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) 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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 > >> if we assume the bi-directional tunnel to be a virtual link, > >> then RFC 2740 (OSPFv3) says > >> > >> On virtual links, global scope or site-local IP addresses must be > >> used as the source for OSPF protocol packets. > >> > > > > Not that you are responsible for the wording of RFC 2740, but I'm > > curious why virtual links use the exception of global addresses. In > > IPv6, shouldn't all links be able to use link-local addresses? It is a > > more preferred approach, as you wouldn't have to assign a global prefix > > to that link, but instead just use link-local addresses. Point-to-point > > links between routers should not require global addresses. > > > > Now in this case maybe you can use the packet design as you speficy > > below, but are the inner packet addresses really the best choices? The > > addresses HA and MR_HoA actually belong to another link (the physical > > home link in case we don't have a virtual home link). > > I am fine with using link local addresses inside the tunnel. > dont know why RFC 2740 says "global scope or site-local IP > addresses must be used as the source for OSPF protocol > packets". > > something that needs clarification in the OSPF WG. Hi, Don't know about MIP (HA/CoA) thing but ... Virtual link does not involve packet encapsulation. It is just an adjacency forming (routing information exchange) between routers of multi-hop far away. You can't use linklocal address as neither source nor destination address of the packet that traverse multi-hop. If linklocal addresses are used in those field, routers drops (rejects) the packet according to IPv6 spec, ... you know ;p) regards, yasu From exim@www1.ietf.org Tue Dec 16 08:26:50 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14880 for ; Tue, 16 Dec 2003 08:26:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWFDQ-0001Rk-Rn for nemo-archive@odin.ietf.org; Tue, 16 Dec 2003 08:26:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGDQKU7005554 for nemo-archive@odin.ietf.org; Tue, 16 Dec 2003 08:26:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWFDQ-0001RV-HV for nemo-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 08:26: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 IAA14792 for ; Tue, 16 Dec 2003 08:26:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWFDP-0002Ax-00 for nemo-web-archive@ietf.org; Tue, 16 Dec 2003 08:26:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWFDB-00027l-00 for nemo-web-archive@ietf.org; Tue, 16 Dec 2003 08:26:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWFDB-00027h-00 for nemo-web-archive@ietf.org; Tue, 16 Dec 2003 08:26:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWFD9-0001Pe-6h; Tue, 16 Dec 2003 08:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWFD3-0001P0-EG for nemo@optimus.ietf.org; Tue, 16 Dec 2003 08:25: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 IAA14629 for ; Tue, 16 Dec 2003 08:25:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWFD2-00024q-00 for nemo@ietf.org; Tue, 16 Dec 2003 08:25:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWF9X-00021G-00 for nemo@ietf.org; Tue, 16 Dec 2003 08:22:20 -0500 Received: from plant.sfc.wide.ad.jp ([203.178.143.91]) by ietf-mx with esmtp (Exim 4.12) id 1AWF9W-00021B-00 for nemo@ietf.org; Tue, 16 Dec 2003 08:22:18 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 24F3929F50; Tue, 16 Dec 2003 22:22:15 +0900 (JST) Date: Tue, 16 Dec 2003 22:22:14 +0900 (JST) Message-Id: <20031216.222214.69509365.yasu@sfc.wide.ad.jp> To: vijayd@iprg.nokia.com Cc: mattias.l.pettersson@ericsson.com, jari.arkko@kolumbus.fi, nemo@ietf.org Subject: Re: [nemo] SPD entries for routing protocol messages From: Yasuhiro Ohara In-Reply-To: <3FDDEBAB.2010502@iprg.nokia.com> References: <3FD9291D.3010608@iprg.nokia.com> <3FDDA273.2090308@ericsson.com> <3FDDEBAB.2010502@iprg.nokia.com> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > >> if we assume the bi-directional tunnel to be a virtual link, > >> then RFC 2740 (OSPFv3) says > >> > >> On virtual links, global scope or site-local IP addresses must be > >> used as the source for OSPF protocol packets. > >> > > > > Not that you are responsible for the wording of RFC 2740, but I'm > > curious why virtual links use the exception of global addresses. In > > IPv6, shouldn't all links be able to use link-local addresses? It is a > > more preferred approach, as you wouldn't have to assign a global prefix > > to that link, but instead just use link-local addresses. Point-to-point > > links between routers should not require global addresses. > > > > Now in this case maybe you can use the packet design as you speficy > > below, but are the inner packet addresses really the best choices? The > > addresses HA and MR_HoA actually belong to another link (the physical > > home link in case we don't have a virtual home link). > > I am fine with using link local addresses inside the tunnel. > dont know why RFC 2740 says "global scope or site-local IP > addresses must be used as the source for OSPF protocol > packets". > > something that needs clarification in the OSPF WG. Hi, Don't know about MIP (HA/CoA) thing but ... Virtual link does not involve packet encapsulation. It is just an adjacency forming (routing information exchange) between routers of multi-hop far away. You can't use linklocal address as neither source nor destination address of the packet that traverse multi-hop. If linklocal addresses are used in those field, routers drops (rejects) the packet according to IPv6 spec, ... you know ;p) regards, yasu From nemo-admin@ietf.org Tue Dec 16 10:24:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17159 for ; Tue, 16 Dec 2003 10:24: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 1AWH3J-0004Cs-6y; Tue, 16 Dec 2003 10: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 1AWH3A-0004Bu-Vi for nemo@optimus.ietf.org; Tue, 16 Dec 2003 10:23: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 KAA16963 for ; Tue, 16 Dec 2003 10:23:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWH38-0003gt-01 for nemo@ietf.org; Tue, 16 Dec 2003 10:23:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWGoD-0003Qm-00 for nemo@ietf.org; Tue, 16 Dec 2003 10:08:27 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AWFdS-0002nl-00 for nemo@ietf.org; Tue, 16 Dec 2003 08:53:14 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBGDrAI2015532; Tue, 16 Dec 2003 14:53:10 +0100 (MET) Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.75]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZAJZKNL5; Tue, 16 Dec 2003 14:53:09 +0100 Message-ID: <3FDF0E36.7060606@ericsson.com> Date: Tue, 16 Dec 2003 14:52:54 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 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: Yasuhiro Ohara CC: vijayd@iprg.nokia.com, nemo@ietf.org Subject: Re: [nemo] SPD entries for routing protocol messages References: <3FD9291D.3010608@iprg.nokia.com> <3FDDA273.2090308@ericsson.com> <3FDDEBAB.2010502@iprg.nokia.com> <20031216.222214.69509365.yasu@sfc.wide.ad.jp> In-Reply-To: <20031216.222214.69509365.yasu@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Yasuhiro Ohara wrote: >>>>if we assume the bi-directional tunnel to be a virtual link, >>>>then RFC 2740 (OSPFv3) says >>>> >>>> On virtual links, global scope or site-local IP addresses must be >>>> used as the source for OSPF protocol packets. >>>> >>> >>>Not that you are responsible for the wording of RFC 2740, but I'm >>>curious why virtual links use the exception of global addresses. In >>>IPv6, shouldn't all links be able to use link-local addresses? It is a >>>more preferred approach, as you wouldn't have to assign a global prefix >>>to that link, but instead just use link-local addresses. Point-to-point >>>links between routers should not require global addresses. >>> >>>Now in this case maybe you can use the packet design as you speficy >>>below, but are the inner packet addresses really the best choices? The >>>addresses HA and MR_HoA actually belong to another link (the physical >>>home link in case we don't have a virtual home link). >> >>I am fine with using link local addresses inside the tunnel. >>dont know why RFC 2740 says "global scope or site-local IP >>addresses must be used as the source for OSPF protocol >>packets". >> >>something that needs clarification in the OSPF WG. > > > Hi, > > Don't know about MIP (HA/CoA) thing but ... > > Virtual link does not involve packet encapsulation. > It is just an adjacency forming (routing information exchange) > between routers of multi-hop far away. OK, I see. Not quite what neither me nor Vijay envisioned. > > You can't use linklocal address as neither source nor > destination address of the packet that traverse multi-hop. > If linklocal addresses are used in those field, > routers drops (rejects) the packet according to IPv6 spec, > ... you know ;p) Seems true... So if I quote what Vijay said: >>>>if we assume the bi-directional tunnel to be a virtual link, >>>>then RFC 2740 (OSPFv3) says doesn't hold any longer, as OSPF doesn't deal with tunnels (not that I found anything about it while browsing through the spec). I don't think that a virtual link can be used just like a tunnel would. Within a tunnel I thought we could run OSPFv3 with link-local addresses and make OSPFv3 unaware of that the tunnel moves when the MR moves. But with virtual links the OSPFv3 implementation must now deal with that the MR end of the link changes its IP address. I'd prefer not to go this path; routing protocols should not have to be modified to run together with NEMO. /Mattias From nemo-admin@ietf.org Tue Dec 16 11:35:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22502 for ; Tue, 16 Dec 2003 11:35: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 1AWIA2-0001hX-Sf; Tue, 16 Dec 2003 11:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWI9L-0001gc-8M for nemo@optimus.ietf.org; Tue, 16 Dec 2003 11:34: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 LAA22439 for ; Tue, 16 Dec 2003 11:34:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWI9K-0001S2-00 for nemo@ietf.org; Tue, 16 Dec 2003 11:34:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWI9J-0001Rv-00 for nemo@ietf.org; Tue, 16 Dec 2003 11:34:17 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AWI9J-0001Qq-00 for nemo@ietf.org; Tue, 16 Dec 2003 11:34:17 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hBGGXdG03898; Tue, 16 Dec 2003 08:33:39 -0800 X-mProtect: <200312161633> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8Qu6Zp; Tue, 16 Dec 2003 08:33:38 PST Message-ID: <3FDF3569.1030705@iprg.nokia.com> Date: Tue, 16 Dec 2003 08:40:09 -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: Yasuhiro Ohara CC: mattias.l.pettersson@ericsson.com, jari.arkko@kolumbus.fi, nemo@ietf.org Subject: Re: [nemo] SPD entries for routing protocol messages References: <3FD9291D.3010608@iprg.nokia.com> <3FDDA273.2090308@ericsson.com> <3FDDEBAB.2010502@iprg.nokia.com> <20031216.222214.69509365.yasu@sfc.wide.ad.jp> In-Reply-To: <20031216.222214.69509365.yasu@sfc.wide.ad.jp> 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 Yasuhiro Ohara wrote: > Don't know about MIP (HA/CoA) thing but ... > > Virtual link does not involve packet encapsulation. > It is just an adjacency forming (routing information exchange) > between routers of multi-hop far away. my suggestion was to use the bi-directional tunnel between the MR and the HA as a single hop virtual link. and use transport mode protection for the routing protocol messages exchanged on this link. > You can't use linklocal address as neither source nor > destination address of the packet that traverse multi-hop. > If linklocal addresses are used in those field, > routers drops (rejects) the packet according to IPv6 spec, > ... you know ;p) agree. Vijay From exim@www1.ietf.org Tue Dec 16 11:35:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22517 for ; Tue, 16 Dec 2003 11:35: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 1AWIA9-0001iv-AS for nemo-archive@odin.ietf.org; Tue, 16 Dec 2003 11:35:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGGZ95g006619 for nemo-archive@odin.ietf.org; Tue, 16 Dec 2003 11:35:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIA9-0001ig-5p for nemo-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 11:35: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 LAA22467 for ; Tue, 16 Dec 2003 11:35:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWIA8-0001Uy-00 for nemo-web-archive@ietf.org; Tue, 16 Dec 2003 11:35:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWIA6-0001Uc-00 for nemo-web-archive@ietf.org; Tue, 16 Dec 2003 11:35:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWIA5-0001UZ-00 for nemo-web-archive@ietf.org; Tue, 16 Dec 2003 11: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 1AWIA2-0001hX-Sf; Tue, 16 Dec 2003 11:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWI9L-0001gc-8M for nemo@optimus.ietf.org; Tue, 16 Dec 2003 11:34: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 LAA22439 for ; Tue, 16 Dec 2003 11:34:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWI9K-0001S2-00 for nemo@ietf.org; Tue, 16 Dec 2003 11:34:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWI9J-0001Rv-00 for nemo@ietf.org; Tue, 16 Dec 2003 11:34:17 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AWI9J-0001Qq-00 for nemo@ietf.org; Tue, 16 Dec 2003 11:34:17 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hBGGXdG03898; Tue, 16 Dec 2003 08:33:39 -0800 X-mProtect: <200312161633> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8Qu6Zp; Tue, 16 Dec 2003 08:33:38 PST Message-ID: <3FDF3569.1030705@iprg.nokia.com> Date: Tue, 16 Dec 2003 08:40:09 -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: Yasuhiro Ohara CC: mattias.l.pettersson@ericsson.com, jari.arkko@kolumbus.fi, nemo@ietf.org Subject: Re: [nemo] SPD entries for routing protocol messages References: <3FD9291D.3010608@iprg.nokia.com> <3FDDA273.2090308@ericsson.com> <3FDDEBAB.2010502@iprg.nokia.com> <20031216.222214.69509365.yasu@sfc.wide.ad.jp> In-Reply-To: <20031216.222214.69509365.yasu@sfc.wide.ad.jp> 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 Yasuhiro Ohara wrote: > Don't know about MIP (HA/CoA) thing but ... > > Virtual link does not involve packet encapsulation. > It is just an adjacency forming (routing information exchange) > between routers of multi-hop far away. my suggestion was to use the bi-directional tunnel between the MR and the HA as a single hop virtual link. and use transport mode protection for the routing protocol messages exchanged on this link. > You can't use linklocal address as neither source nor > destination address of the packet that traverse multi-hop. > If linklocal addresses are used in those field, > routers drops (rejects) the packet according to IPv6 spec, > ... you know ;p) agree. Vijay From nemo-admin@ietf.org Tue Dec 16 11:38:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22736 for ; Tue, 16 Dec 2003 11:38: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 1AWICv-0002IQ-8G; Tue, 16 Dec 2003 11: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 1AWICW-000270-GH for nemo@optimus.ietf.org; Tue, 16 Dec 2003 11:37:36 -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 LAA22670 for ; Tue, 16 Dec 2003 11:37:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWICV-0001am-00 for nemo@ietf.org; Tue, 16 Dec 2003 11:37:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWICU-0001af-00 for nemo@ietf.org; Tue, 16 Dec 2003 11:37:35 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AWICT-0001a8-00 for nemo@ietf.org; Tue, 16 Dec 2003 11:37:33 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hBGGawY06345; Tue, 16 Dec 2003 08:36:58 -0800 X-mProtect: <200312161636> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBO9Gsw; Tue, 16 Dec 2003 08:36:57 PST Message-ID: <3FDF3630.9020101@iprg.nokia.com> Date: Tue, 16 Dec 2003 08:43:28 -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: Mattias Pettersson CC: Yasuhiro Ohara , nemo@ietf.org Subject: Re: [nemo] SPD entries for routing protocol messages References: <3FD9291D.3010608@iprg.nokia.com> <3FDDA273.2090308@ericsson.com> <3FDDEBAB.2010502@iprg.nokia.com> <20031216.222214.69509365.yasu@sfc.wide.ad.jp> <3FDF0E36.7060606@ericsson.com> In-Reply-To: <3FDF0E36.7060606@ericsson.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 Mattias Pettersson wrote: > > > Yasuhiro Ohara wrote: > >>>>> if we assume the bi-directional tunnel to be a virtual link, >>>>> then RFC 2740 (OSPFv3) says >>>>> >>>>> On virtual links, global scope or site-local IP addresses must be >>>>> used as the source for OSPF protocol packets. >>>>> >>>> >>>> Not that you are responsible for the wording of RFC 2740, but I'm >>>> curious why virtual links use the exception of global addresses. In >>>> IPv6, shouldn't all links be able to use link-local addresses? It is >>>> a more preferred approach, as you wouldn't have to assign a global >>>> prefix to that link, but instead just use link-local addresses. >>>> Point-to-point links between routers should not require global >>>> addresses. >>>> >>>> Now in this case maybe you can use the packet design as you speficy >>>> below, but are the inner packet addresses really the best choices? >>>> The addresses HA and MR_HoA actually belong to another link (the >>>> physical home link in case we don't have a virtual home link). >>> >>> >>> I am fine with using link local addresses inside the tunnel. >>> dont know why RFC 2740 says "global scope or site-local IP >>> addresses must be used as the source for OSPF protocol >>> packets". >>> >>> something that needs clarification in the OSPF WG. >> >> >> >> Hi, >> >> Don't know about MIP (HA/CoA) thing but ... >> >> Virtual link does not involve packet encapsulation. >> It is just an adjacency forming (routing information exchange) >> between routers of multi-hop far away. > > > OK, I see. Not quite what neither me nor Vijay envisioned. > >> >> You can't use linklocal address as neither source nor >> destination address of the packet that traverse multi-hop. >> If linklocal addresses are used in those field, >> routers drops (rejects) the packet according to IPv6 spec, >> ... you know ;p) > > > Seems true... > > So if I quote what Vijay said: > >>>>if we assume the bi-directional tunnel to be a virtual link, > >>>>then RFC 2740 (OSPFv3) says > > doesn't hold any longer, as OSPF doesn't deal with tunnels (not that I > found anything about it while browsing through the spec). > > I don't think that a virtual link can be used just like a tunnel would. > Within a tunnel I thought we could run OSPFv3 with link-local addresses > and make OSPFv3 unaware of that the tunnel moves when the MR moves. okay. forget my earlier suggestion. lets go with link local addresses inside with the tunnel. > But with virtual links the OSPFv3 implementation must now deal with that > the MR end of the link changes its IP address. I'd prefer not to go this > path; routing protocols should not have to be modified to run together > with NEMO. agree. Vijay From exim@www1.ietf.org Tue Dec 16 11:38:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22751 for ; Tue, 16 Dec 2003 11: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 1AWICx-0002Ja-SC for nemo-archive@odin.ietf.org; Tue, 16 Dec 2003 11:38:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGGc3O6008892 for nemo-archive@odin.ietf.org; Tue, 16 Dec 2003 11:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWICx-0002JD-5N for nemo-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 11:38: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 LAA22708 for ; Tue, 16 Dec 2003 11:38:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWICw-0001bs-00 for nemo-web-archive@ietf.org; Tue, 16 Dec 2003 11:38:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWICv-0001bl-00 for nemo-web-archive@ietf.org; Tue, 16 Dec 2003 11:38:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWICv-0001bi-00 for nemo-web-archive@ietf.org; Tue, 16 Dec 2003 11: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 1AWICv-0002IQ-8G; Tue, 16 Dec 2003 11: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 1AWICW-000270-GH for nemo@optimus.ietf.org; Tue, 16 Dec 2003 11:37:36 -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 LAA22670 for ; Tue, 16 Dec 2003 11:37:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWICV-0001am-00 for nemo@ietf.org; Tue, 16 Dec 2003 11:37:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWICU-0001af-00 for nemo@ietf.org; Tue, 16 Dec 2003 11:37:35 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AWICT-0001a8-00 for nemo@ietf.org; Tue, 16 Dec 2003 11:37:33 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hBGGawY06345; Tue, 16 Dec 2003 08:36:58 -0800 X-mProtect: <200312161636> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBO9Gsw; Tue, 16 Dec 2003 08:36:57 PST Message-ID: <3FDF3630.9020101@iprg.nokia.com> Date: Tue, 16 Dec 2003 08:43:28 -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: Mattias Pettersson CC: Yasuhiro Ohara , nemo@ietf.org Subject: Re: [nemo] SPD entries for routing protocol messages References: <3FD9291D.3010608@iprg.nokia.com> <3FDDA273.2090308@ericsson.com> <3FDDEBAB.2010502@iprg.nokia.com> <20031216.222214.69509365.yasu@sfc.wide.ad.jp> <3FDF0E36.7060606@ericsson.com> In-Reply-To: <3FDF0E36.7060606@ericsson.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 Mattias Pettersson wrote: > > > Yasuhiro Ohara wrote: > >>>>> if we assume the bi-directional tunnel to be a virtual link, >>>>> then RFC 2740 (OSPFv3) says >>>>> >>>>> On virtual links, global scope or site-local IP addresses must be >>>>> used as the source for OSPF protocol packets. >>>>> >>>> >>>> Not that you are responsible for the wording of RFC 2740, but I'm >>>> curious why virtual links use the exception of global addresses. In >>>> IPv6, shouldn't all links be able to use link-local addresses? It is >>>> a more preferred approach, as you wouldn't have to assign a global >>>> prefix to that link, but instead just use link-local addresses. >>>> Point-to-point links between routers should not require global >>>> addresses. >>>> >>>> Now in this case maybe you can use the packet design as you speficy >>>> below, but are the inner packet addresses really the best choices? >>>> The addresses HA and MR_HoA actually belong to another link (the >>>> physical home link in case we don't have a virtual home link). >>> >>> >>> I am fine with using link local addresses inside the tunnel. >>> dont know why RFC 2740 says "global scope or site-local IP >>> addresses must be used as the source for OSPF protocol >>> packets". >>> >>> something that needs clarification in the OSPF WG. >> >> >> >> Hi, >> >> Don't know about MIP (HA/CoA) thing but ... >> >> Virtual link does not involve packet encapsulation. >> It is just an adjacency forming (routing information exchange) >> between routers of multi-hop far away. > > > OK, I see. Not quite what neither me nor Vijay envisioned. > >> >> You can't use linklocal address as neither source nor >> destination address of the packet that traverse multi-hop. >> If linklocal addresses are used in those field, >> routers drops (rejects) the packet according to IPv6 spec, >> ... you know ;p) > > > Seems true... > > So if I quote what Vijay said: > >>>>if we assume the bi-directional tunnel to be a virtual link, > >>>>then RFC 2740 (OSPFv3) says > > doesn't hold any longer, as OSPF doesn't deal with tunnels (not that I > found anything about it while browsing through the spec). > > I don't think that a virtual link can be used just like a tunnel would. > Within a tunnel I thought we could run OSPFv3 with link-local addresses > and make OSPFv3 unaware of that the tunnel moves when the MR moves. okay. forget my earlier suggestion. lets go with link local addresses inside with the tunnel. > But with virtual links the OSPFv3 implementation must now deal with that > the MR end of the link changes its IP address. I'd prefer not to go this > path; routing protocols should not have to be modified to run together > with NEMO. agree. Vijay From nemo-admin@ietf.org Tue Dec 16 17:36:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11630 for ; Tue, 16 Dec 2003 17:36: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 1AWNnM-0001ME-RH; Tue, 16 Dec 2003 17:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW8rk-0001Jm-D7 for nemo@optimus.ietf.org; Tue, 16 Dec 2003 01: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 BAA19025 for ; Tue, 16 Dec 2003 01:39:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW8rh-0002gE-00 for nemo@ietf.org; Tue, 16 Dec 2003 01:39:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW8rg-0002g7-00 for nemo@ietf.org; Tue, 16 Dec 2003 01:39:28 -0500 Received: from melanieb.vtt.fi ([130.188.1.12]) by ietf-mx with esmtp (Exim 4.12) id 1AW8re-0002fT-00; Tue, 16 Dec 2003 01:39:27 -0500 Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi (8.12.9/8.12.9) with ESMTP id hBG6c635017434; Tue, 16 Dec 2003 08:38:06 +0200 (EET) Received: from oulkv10326.vtt.fi (ele4114.ele.vtt.fi [130.188.94.114]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with ESMTP id IAA11163; Tue, 16 Dec 2003 08:38:55 +0200 (EET) Message-Id: <4.3.2.7.2.20031216082217.00c37420@elemail.ele.vtt.fi> X-Sender: eleppa@elemail.ele.vtt.fi X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Dec 2003 08:38:52 +0200 To: manet@ietf.org;, nemo@ietf.org From: Pekka =?iso-8859-1?Q?Pääkkönen?= Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; 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=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [nemo] draft submission Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 all, I have submitted an individual draft, which focuses on IPv6 addressing in a heterogeneous MANET-network. Any comments on the subject are welcome. Pekka P=E4=E4kk=F6nen draft URL: http://www.ietf.org/internet-drafts/draft-paakkonen-addressing-htr-manet-00.= txt =20 From exim@www1.ietf.org Tue Dec 16 17:36:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11658 for ; Tue, 16 Dec 2003 17:36: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 1AWNnU-0001Ol-Sk for nemo-archive@odin.ietf.org; Tue, 16 Dec 2003 17:36:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGMa825005369 for nemo-archive@odin.ietf.org; Tue, 16 Dec 2003 17:36:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNnU-0001OT-N1 for nemo-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 17:36:08 -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 RAA11603 for ; Tue, 16 Dec 2003 17:36:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWNnS-0000XU-00 for nemo-web-archive@ietf.org; Tue, 16 Dec 2003 17:36:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWNnR-0000XL-00 for nemo-web-archive@ietf.org; Tue, 16 Dec 2003 17:36:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWNnR-0000XI-00 for nemo-web-archive@ietf.org; Tue, 16 Dec 2003 17:36:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNnM-0001ME-RH; Tue, 16 Dec 2003 17:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW8rk-0001Jm-D7 for nemo@optimus.ietf.org; Tue, 16 Dec 2003 01: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 BAA19025 for ; Tue, 16 Dec 2003 01:39:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW8rh-0002gE-00 for nemo@ietf.org; Tue, 16 Dec 2003 01:39:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW8rg-0002g7-00 for nemo@ietf.org; Tue, 16 Dec 2003 01:39:28 -0500 Received: from melanieb.vtt.fi ([130.188.1.12]) by ietf-mx with esmtp (Exim 4.12) id 1AW8re-0002fT-00; Tue, 16 Dec 2003 01:39:27 -0500 Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi (8.12.9/8.12.9) with ESMTP id hBG6c635017434; Tue, 16 Dec 2003 08:38:06 +0200 (EET) Received: from oulkv10326.vtt.fi (ele4114.ele.vtt.fi [130.188.94.114]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with ESMTP id IAA11163; Tue, 16 Dec 2003 08:38:55 +0200 (EET) Message-Id: <4.3.2.7.2.20031216082217.00c37420@elemail.ele.vtt.fi> X-Sender: eleppa@elemail.ele.vtt.fi X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Dec 2003 08:38:52 +0200 To: manet@ietf.org;, nemo@ietf.org From: Pekka =?iso-8859-1?Q?Pääkkönen?= Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Subject: [nemo] draft submission Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 all, I have submitted an individual draft, which focuses on IPv6 addressing in a heterogeneous MANET-network. Any comments on the subject are welcome. Pekka P=E4=E4kk=F6nen draft URL: http://www.ietf.org/internet-drafts/draft-paakkonen-addressing-htr-manet-00.= txt =20 From nemo-admin@ietf.org Thu Dec 18 00:35:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23809 for ; Thu, 18 Dec 2003 00:35: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 1AWqoR-0006vY-9y; Thu, 18 Dec 2003 00:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWqoI-0006uq-FS for nemo@optimus.ietf.org; Thu, 18 Dec 2003 00:34: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 AAA23789 for ; Thu, 18 Dec 2003 00:34:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWqoF-0001fE-00 for nemo@ietf.org; Thu, 18 Dec 2003 00:34:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWqoE-0001f7-00 for nemo@ietf.org; Thu, 18 Dec 2003 00:34:51 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AWqoE-0001cq-00 for nemo@ietf.org; Thu, 18 Dec 2003 00:34:50 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 30A9E5D285; Thu, 18 Dec 2003 14:34:18 +0900 (JST) Date: Thu, 18 Dec 2003 14:36:45 +0900 From: Thierry Ernst To: "Pascal Thubert (pthubert)" Cc: alexandru.petrescu@motorola.com, vijayd@iprg.nokia.com, nemo@ietf.org Subject: Re: [nemo] Issue 28 Message-Id: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, "Pascal Thubert (pthubert)" wrote: > > Let me remind you that we have a separate terminology because the WG > > aggreed it; and that the terminology doc contains more terms that are > > needed in NEMO Basic Support. So, if you want to move some definitions > > in the NEMO Basic Support doc, we would still need a doc for the other > > terms ... > > > > I support leaving the definitions in terminology if it goes RFC, as I mentioned implicitly in the thread. Question: should we also move the definitions from the usage draft into the terminology (I assume yes)? Which definitions would be candidates ones ? I will update the terminology draft before Xmas, and include terms from NEMO Basic Support, if any. > > > For example, MR would be good to be defined in the Terminology section > > > but TLMR would be defined in the Terminology document, because the basic > > > support draft does not talk about TLMR's at all. > > > > - generic terms are defined in draft-ietf-seamoby-terminology, included > > MR. > > > > - TMLR doesn't exist anymore, it's root-MR. > > I support leaving TLMR in the terminology as a deprecated synonym for root-MR; reason is it's been used for awhile. I can certainly do this. I would also like to propose MNet for "mobile networks" (this term has been proposed by Nicolas M), since NEMO stands for NEtwork MObility and MONET may be confused with MANET. Alexandru also proposed some terms, but I didn't find them reasonably clear. Comments ? Thierry. > > > Finally, the clarification of MH, MR and MN should be re-stated > > > somewhere, because currently there is much confusion about this. Most > > > text I've read and speech I've heard refers to MN as being a Mobile > > > Host; while in reality MN could be either a MH or a MR (by the > > > definition in the Mobile IPv6 spec). > > > > Anyone is free to propose a rephrasing (that is shared by ML members). > > To me, a MN is either a host or a router, I think the definitions are > > clear about this. > > > > > > I think the NEMO Basic Support doc should only define specific terms, if > > needed. For instance, LFN is better defined in an other document, as it > > will be used in discussions not only turning around Basic Support. On > > the other hand, if we want to define a term R-BU (Router Binding Update, > > to distinguish with the MIPv6 BU), the NEMO Basic Support doc is a > > better place. > > > > So, what terms would you like to see in the NEMO Basic Support doc ? > > > > > > About the status of the terminology doc, I have not issued the WG last > > call because I think the terminology about multihoming is not clear > > enough and may be enhanced based on the discussion about the coming > > multihoming WG document. > > > Thierry: this doc will always evolve. So we have to cut RFCs when needed and start a follow on. From exim@www1.ietf.org Thu Dec 18 00:35:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23824 for ; Thu, 18 Dec 2003 00:35: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 1AWqoc-0006wf-67 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 00:35:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI5ZEcH026691 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 00:35:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWqoc-0006wQ-1O for nemo-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 00:35: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 AAA23800 for ; Thu, 18 Dec 2003 00:35:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWqoZ-0001fg-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 00:35:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWqoY-0001fV-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 00:35:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWqoY-0001fQ-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 00:35:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWqoR-0006vY-9y; Thu, 18 Dec 2003 00:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWqoI-0006uq-FS for nemo@optimus.ietf.org; Thu, 18 Dec 2003 00:34: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 AAA23789 for ; Thu, 18 Dec 2003 00:34:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWqoF-0001fE-00 for nemo@ietf.org; Thu, 18 Dec 2003 00:34:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWqoE-0001f7-00 for nemo@ietf.org; Thu, 18 Dec 2003 00:34:51 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AWqoE-0001cq-00 for nemo@ietf.org; Thu, 18 Dec 2003 00:34:50 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 30A9E5D285; Thu, 18 Dec 2003 14:34:18 +0900 (JST) Date: Thu, 18 Dec 2003 14:36:45 +0900 From: Thierry Ernst To: "Pascal Thubert (pthubert)" Cc: alexandru.petrescu@motorola.com, vijayd@iprg.nokia.com, nemo@ietf.org Subject: Re: [nemo] Issue 28 Message-Id: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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, "Pascal Thubert (pthubert)" wrote: > > Let me remind you that we have a separate terminology because the WG > > aggreed it; and that the terminology doc contains more terms that are > > needed in NEMO Basic Support. So, if you want to move some definitions > > in the NEMO Basic Support doc, we would still need a doc for the other > > terms ... > > > > I support leaving the definitions in terminology if it goes RFC, as I mentioned implicitly in the thread. Question: should we also move the definitions from the usage draft into the terminology (I assume yes)? Which definitions would be candidates ones ? I will update the terminology draft before Xmas, and include terms from NEMO Basic Support, if any. > > > For example, MR would be good to be defined in the Terminology section > > > but TLMR would be defined in the Terminology document, because the basic > > > support draft does not talk about TLMR's at all. > > > > - generic terms are defined in draft-ietf-seamoby-terminology, included > > MR. > > > > - TMLR doesn't exist anymore, it's root-MR. > > I support leaving TLMR in the terminology as a deprecated synonym for root-MR; reason is it's been used for awhile. I can certainly do this. I would also like to propose MNet for "mobile networks" (this term has been proposed by Nicolas M), since NEMO stands for NEtwork MObility and MONET may be confused with MANET. Alexandru also proposed some terms, but I didn't find them reasonably clear. Comments ? Thierry. > > > Finally, the clarification of MH, MR and MN should be re-stated > > > somewhere, because currently there is much confusion about this. Most > > > text I've read and speech I've heard refers to MN as being a Mobile > > > Host; while in reality MN could be either a MH or a MR (by the > > > definition in the Mobile IPv6 spec). > > > > Anyone is free to propose a rephrasing (that is shared by ML members). > > To me, a MN is either a host or a router, I think the definitions are > > clear about this. > > > > > > I think the NEMO Basic Support doc should only define specific terms, if > > needed. For instance, LFN is better defined in an other document, as it > > will be used in discussions not only turning around Basic Support. On > > the other hand, if we want to define a term R-BU (Router Binding Update, > > to distinguish with the MIPv6 BU), the NEMO Basic Support doc is a > > better place. > > > > So, what terms would you like to see in the NEMO Basic Support doc ? > > > > > > About the status of the terminology doc, I have not issued the WG last > > call because I think the terminology about multihoming is not clear > > enough and may be enhanced based on the discussion about the coming > > multihoming WG document. > > > Thierry: this doc will always evolve. So we have to cut RFCs when needed and start a follow on. From nemo-admin@ietf.org Thu Dec 18 00:44:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24068 for ; Thu, 18 Dec 2003 00:44: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 1AWqx6-0007Rx-VY; Thu, 18 Dec 2003 00:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWqwp-0007RM-PG for nemo@optimus.ietf.org; Thu, 18 Dec 2003 00:43: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 AAA24024 for ; Thu, 18 Dec 2003 00:43:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWqwn-0001uT-00 for nemo@ietf.org; Thu, 18 Dec 2003 00:43:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWqwl-0001uA-00 for nemo@ietf.org; Thu, 18 Dec 2003 00:43:40 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AWqwl-0001oJ-00 for nemo@ietf.org; Thu, 18 Dec 2003 00:43:39 -0500 Received: from [64.36.73.246] (wideload.kniveton.com [64.36.73.246]) by multihop.net (8.12.10/8.12.10) with ESMTP id hBI5gRr4031661 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 17 Dec 2003 21:42:28 -0800 (PST) (envelope-from tj@kniveton.com) Mime-Version: 1.0 (Apple Message framework v609) In-Reply-To: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--1070387922; protocol="application/pkcs7-signature" Message-Id: From: "T.J. Kniveton" Subject: MNet (was Re: [nemo] Issue 28) Date: Wed, 17 Dec 2003 21:41:32 -0800 To: nemo@ietf.org X-Mailer: Apple Mail (2.609) 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--1070387922 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Dec 17, 2003, at 9:36 PM, Thierry Ernst wrote: > I would also like to propose MNet for "mobile networks" (this term has > been proposed by Nicolas M), since NEMO stands for NEtwork MObility and > MONET may be confused with MANET. Alexandru also proposed some terms, > but I didn't find them reasonably clear. Comments ? > I would rather say mobile network than MNet. MoNet makes more sense to me. We renamed the working group from MONET to NEMO to avoid the similarity to MANET.. but in the context of NEMO documents, and in its usage, I don't see how there could be any confusion..? Maybe someone has a better idea than monet.. but MNet is hard to pronounce and doesn't do all that much to shorten or clarify things... (just my opinion). TJ --Apple-Mail-3--1070387922 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 ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTIxODA1NDEz M1owIwYJKoZIhvcNAQkEMRYEFPCzGe6CBjVwTd9VQgWvHpCJrF7QMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgDukooJiA2gC19IOOnOpNgqVsbbkBEBeanVnFhdYvvKW m/kgSMxA3oY6s87+mWuBsIYiyJObybROzcVwqCB+bgvxktqKaCFAdfq3LDPLkVD8jnTeX9psRvDl imrGtsc96xRoQxB7GZsIp9rdRTWaFWBGBXhidA/uZzS0fv944T9DAAAAAAAA --Apple-Mail-3--1070387922-- From exim@www1.ietf.org Thu Dec 18 00:44:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24083 for ; Thu, 18 Dec 2003 00:44: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 1AWqx8-0007Sw-TI for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 00:44:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI5i2RK028695 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 00:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWqx8-0007Sk-PB for nemo-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 00:44: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 AAA24040 for ; Thu, 18 Dec 2003 00:43:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWqx6-0001vV-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 00:44:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWqx5-0001vO-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 00:43:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWqx5-0001vL-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 00:43:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWqx6-0007Rx-VY; Thu, 18 Dec 2003 00:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWqwp-0007RM-PG for nemo@optimus.ietf.org; Thu, 18 Dec 2003 00:43: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 AAA24024 for ; Thu, 18 Dec 2003 00:43:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWqwn-0001uT-00 for nemo@ietf.org; Thu, 18 Dec 2003 00:43:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWqwl-0001uA-00 for nemo@ietf.org; Thu, 18 Dec 2003 00:43:40 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AWqwl-0001oJ-00 for nemo@ietf.org; Thu, 18 Dec 2003 00:43:39 -0500 Received: from [64.36.73.246] (wideload.kniveton.com [64.36.73.246]) by multihop.net (8.12.10/8.12.10) with ESMTP id hBI5gRr4031661 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 17 Dec 2003 21:42:28 -0800 (PST) (envelope-from tj@kniveton.com) Mime-Version: 1.0 (Apple Message framework v609) In-Reply-To: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--1070387922; protocol="application/pkcs7-signature" Message-Id: From: "T.J. Kniveton" Subject: MNet (was Re: [nemo] Issue 28) Date: Wed, 17 Dec 2003 21:41:32 -0800 To: nemo@ietf.org X-Mailer: Apple Mail (2.609) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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--1070387922 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Dec 17, 2003, at 9:36 PM, Thierry Ernst wrote: > I would also like to propose MNet for "mobile networks" (this term has > been proposed by Nicolas M), since NEMO stands for NEtwork MObility and > MONET may be confused with MANET. Alexandru also proposed some terms, > but I didn't find them reasonably clear. Comments ? > I would rather say mobile network than MNet. MoNet makes more sense to me. We renamed the working group from MONET to NEMO to avoid the similarity to MANET.. but in the context of NEMO documents, and in its usage, I don't see how there could be any confusion..? Maybe someone has a better idea than monet.. but MNet is hard to pronounce and doesn't do all that much to shorten or clarify things... (just my opinion). TJ --Apple-Mail-3--1070387922 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 ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTIxODA1NDEz M1owIwYJKoZIhvcNAQkEMRYEFPCzGe6CBjVwTd9VQgWvHpCJrF7QMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgDukooJiA2gC19IOOnOpNgqVsbbkBEBeanVnFhdYvvKW m/kgSMxA3oY6s87+mWuBsIYiyJObybROzcVwqCB+bgvxktqKaCFAdfq3LDPLkVD8jnTeX9psRvDl imrGtsc96xRoQxB7GZsIp9rdRTWaFWBGBXhidA/uZzS0fv944T9DAAAAAAAA --Apple-Mail-3--1070387922-- From nemo-admin@ietf.org Thu Dec 18 03:18:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10887 for ; Thu, 18 Dec 2003 03:18: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 1AWtM9-0005bT-NM; Thu, 18 Dec 2003 03: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 1AWtLR-0005ap-6N for nemo@optimus.ietf.org; Thu, 18 Dec 2003 03:17: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 DAA10852 for ; Thu, 18 Dec 2003 03:17:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWtLO-0005SI-00 for nemo@ietf.org; Thu, 18 Dec 2003 03:17:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWtLO-0005SB-00 for nemo@ietf.org; Thu, 18 Dec 2003 03:17:14 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AWtLN-0005RU-00 for nemo@ietf.org; Thu, 18 Dec 2003 03:17:13 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hBI8GXK11686; Thu, 18 Dec 2003 00:16:33 -0800 X-mProtect: <200312180816> Nokia Silicon Valley Messaging Protection Received: from danira-pool050143.americas.nokia.com (10.241.50.143, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNv16cr; Thu, 18 Dec 2003 00:16:32 PST Message-ID: <3FE16255.1080705@iprg.nokia.com> Date: Thu, 18 Dec 2003 00:16:21 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko , Mattias Pettersson , yasu@sfc.wide.ad.jp CC: nemo@ietf.org 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] Closing issue 29 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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, here is some text (to be added to the section on Dynamic routing protocols) for closing issue 29. Since the routing protocol messages from the Home Agent to the Mobile Router could potentially contain information about the internal routing structure of the home network, these messages require authentications and confidentiality protection. Confidentialy protection using IPsec ESP [4] MUST be supported and SHOULD be used. For protecting routing protocol messages using ESP, the bi-directional tunnel between the Mobile Router and the Home Agent should be treated as the outgoing interface, with link local addresses as source and destination addresses for the messages. IPsec ESP with a non-null encryption algorithm should be used in transport mode for protecting the routing protocol messages. Examples of SPD entries for protecting OSPFv3 messages are described in [13]. [13] M. Gupta and N. Melam. Authentication/Confidentiality for OSPFv3. Internet Draft, IETF. draft-ietf-ospf-ospfv3-auth-04.txt (work in progress). December 2003. comments/suggestions welcome. Vijay From exim@www1.ietf.org Thu Dec 18 03:18:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10902 for ; Thu, 18 Dec 2003 03: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 1AWtMF-0005cR-81 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 03:18:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI8I7jP021600 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 03:18:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWtME-0005cJ-Vq for nemo-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 03:18:07 -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 DAA10869 for ; Thu, 18 Dec 2003 03:18:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWtMC-0005Ta-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 03:18:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWtMB-0005TR-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 03:18:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWtMB-0005TO-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 03:18:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWtM9-0005bT-NM; Thu, 18 Dec 2003 03: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 1AWtLR-0005ap-6N for nemo@optimus.ietf.org; Thu, 18 Dec 2003 03:17: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 DAA10852 for ; Thu, 18 Dec 2003 03:17:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWtLO-0005SI-00 for nemo@ietf.org; Thu, 18 Dec 2003 03:17:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWtLO-0005SB-00 for nemo@ietf.org; Thu, 18 Dec 2003 03:17:14 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AWtLN-0005RU-00 for nemo@ietf.org; Thu, 18 Dec 2003 03:17:13 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hBI8GXK11686; Thu, 18 Dec 2003 00:16:33 -0800 X-mProtect: <200312180816> Nokia Silicon Valley Messaging Protection Received: from danira-pool050143.americas.nokia.com (10.241.50.143, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNv16cr; Thu, 18 Dec 2003 00:16:32 PST Message-ID: <3FE16255.1080705@iprg.nokia.com> Date: Thu, 18 Dec 2003 00:16:21 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko , Mattias Pettersson , yasu@sfc.wide.ad.jp CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Closing issue 29 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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, here is some text (to be added to the section on Dynamic routing protocols) for closing issue 29. Since the routing protocol messages from the Home Agent to the Mobile Router could potentially contain information about the internal routing structure of the home network, these messages require authentications and confidentiality protection. Confidentialy protection using IPsec ESP [4] MUST be supported and SHOULD be used. For protecting routing protocol messages using ESP, the bi-directional tunnel between the Mobile Router and the Home Agent should be treated as the outgoing interface, with link local addresses as source and destination addresses for the messages. IPsec ESP with a non-null encryption algorithm should be used in transport mode for protecting the routing protocol messages. Examples of SPD entries for protecting OSPFv3 messages are described in [13]. [13] M. Gupta and N. Melam. Authentication/Confidentiality for OSPFv3. Internet Draft, IETF. draft-ietf-ospf-ospfv3-auth-04.txt (work in progress). December 2003. comments/suggestions welcome. Vijay From nemo-admin@ietf.org Thu Dec 18 06:26:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15526 for ; Thu, 18 Dec 2003 06:26: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 1AWwI7-0003wa-9y; Thu, 18 Dec 2003 06:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwHB-0003vp-1L for nemo@optimus.ietf.org; Thu, 18 Dec 2003 06:25:07 -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 GAA15520 for ; Thu, 18 Dec 2003 06:25:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWwH7-0002GN-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:25:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWwH6-0002GG-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:25:00 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AWwH5-0002GD-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:24:59 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id hBIBOuY5014998; Thu, 18 Dec 2003 04:24:56 -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 hBIBOqVo004088; Thu, 18 Dec 2003 05:24:53 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 8E18E85272F; Thu, 18 Dec 2003 12:24:52 +0100 (CET) Message-ID: <3FE18E84.9010701@motorola.com> Date: Thu, 18 Dec 2003 12:24:52 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: "Pascal Thubert (pthubert)" , Alexandru Petrescu , vijayd@iprg.nokia.com, nemo@ietf.org Subject: Re: [nemo] Issue 28 References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> In-Reply-To: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: > I would also like to propose MNet for "mobile networks" Against this. We can always use 'mobile network' at its full length. Similarly, the spec never reads HA, but Home Agent. If on the other hand 'MNet' is intended for ephemeral conversations, then that's fine, I can key 'MNet', no problem, but no need to set in stone in document (sorry if I repeat). I think it's too late to start new NEMO definitions... > Alexandru also proposed some terms, but I didn't find them reasonably > clear. Comments ? I find it unreasonably unclear which terms are referred(?) :-) What I would like to have is to have the terms used by the base support defined in the base support draft itself. These are not many, and most of them are already defined by the MIP6 spec. "Mobile Router" is one of them. A Mobile Node refers to an entity that can work as a Mobile Host or as a Mobile Router. A Mobile Host does not implement the R-bit in BU, a Mobile Router does. Subsequently and paradoxically, a Mobile Node does implement the R-bit. This does not mean that the separate terminology draft has no reason to exist, there are many other NEMO terms that it defines and that are not used in the base doc. I also support Pascal's proposal to add the terms of draft-usages into the terminology document. Alex From exim@www1.ietf.org Thu Dec 18 06:27:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15549 for ; Thu, 18 Dec 2003 06:27: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 1AWwJ0-00041S-5E for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 06:26:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIBQw7i015458 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 06:26:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwIz-00041F-W9 for nemo-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 06:26:58 -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 GAA15542 for ; Thu, 18 Dec 2003 06:26:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWwIr-0002Gh-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 06:26:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWwIQ-0002GY-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 06:26:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWwIQ-0002GT-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 06:26:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwI7-0003wa-9y; Thu, 18 Dec 2003 06:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwHB-0003vp-1L for nemo@optimus.ietf.org; Thu, 18 Dec 2003 06:25:07 -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 GAA15520 for ; Thu, 18 Dec 2003 06:25:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWwH7-0002GN-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:25:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWwH6-0002GG-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:25:00 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AWwH5-0002GD-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:24:59 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id hBIBOuY5014998; Thu, 18 Dec 2003 04:24:56 -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 hBIBOqVo004088; Thu, 18 Dec 2003 05:24:53 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 8E18E85272F; Thu, 18 Dec 2003 12:24:52 +0100 (CET) Message-ID: <3FE18E84.9010701@motorola.com> Date: Thu, 18 Dec 2003 12:24:52 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: "Pascal Thubert (pthubert)" , Alexandru Petrescu , vijayd@iprg.nokia.com, nemo@ietf.org Subject: Re: [nemo] Issue 28 References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> In-Reply-To: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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: > I would also like to propose MNet for "mobile networks" Against this. We can always use 'mobile network' at its full length. Similarly, the spec never reads HA, but Home Agent. If on the other hand 'MNet' is intended for ephemeral conversations, then that's fine, I can key 'MNet', no problem, but no need to set in stone in document (sorry if I repeat). I think it's too late to start new NEMO definitions... > Alexandru also proposed some terms, but I didn't find them reasonably > clear. Comments ? I find it unreasonably unclear which terms are referred(?) :-) What I would like to have is to have the terms used by the base support defined in the base support draft itself. These are not many, and most of them are already defined by the MIP6 spec. "Mobile Router" is one of them. A Mobile Node refers to an entity that can work as a Mobile Host or as a Mobile Router. A Mobile Host does not implement the R-bit in BU, a Mobile Router does. Subsequently and paradoxically, a Mobile Node does implement the R-bit. This does not mean that the separate terminology draft has no reason to exist, there are many other NEMO terms that it defines and that are not used in the base doc. I also support Pascal's proposal to add the terms of draft-usages into the terminology document. Alex From nemo-admin@ietf.org Thu Dec 18 06:33:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15759 for ; Thu, 18 Dec 2003 06:33: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 1AWwOq-00046e-W6; Thu, 18 Dec 2003 06:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwON-00046P-68 for nemo@optimus.ietf.org; Thu, 18 Dec 2003 06:32: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 GAA15674 for ; Thu, 18 Dec 2003 06:32:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWwOJ-0002N5-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:32:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWwOH-0002My-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:32:26 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AWwOH-0002Mh-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:32:25 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Dec 2003 12:32:51 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hBIBVaot024119; Thu, 18 Dec 2003 12:31:37 +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, 18 Dec 2003 11:31:51 +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] Issue 28 Date: Thu, 18 Dec 2003 11:31:50 -0000 Message-ID: Thread-Topic: [nemo] Issue 28 Thread-Index: AcPFKKAHEMFlvvKxRhiHNcmMiL+GWgAMMCJw From: "Pascal Thubert (pthubert)" To: "Thierry Ernst" Cc: , , X-OriginalArrivalTime: 18 Dec 2003 11:31:51.0395 (UTC) FILETIME=[87E1B330:01C3C55A] 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 Thierry: Usages defines the following additional terminology: Home Link: The link attached to the interface at the Home Agent on which the Home Prefix is configured. The interface can be a virtual interface, in which case the Home Link is a virtual Home Link. Home Network: The Network formed by the application of the Home Prefix on the Home Link. With Nemo, the concept of Home Network is extended as explained below. Home Address: With Mobile IPv6, a Home Address is derived from the Home Network prefix. This is generalized in Nemo, with some limitations: A Home Address can be either derived from the Home Network or from one of the Mobile Router's Mobile Network prefixes. MRHA Tunnel: The bi-directional tunnel between a Mobile Router and its Home Agent Mobile Aggregated Prefix: An aggregation of Mobile Network Prefixes. Aggregated Home Network: The Home Network associated with a Mobile Aggregated Prefix. This Aggregation is advertised as a subnet on the Home Link, and thus used as Home Network for Nemo purposes. Extended Home Network: The network associated with the aggregation of one or more Home Network(s) and Mobile Network(s). As opposed to the Mobile IPv6 Home Network that is a subnet, the extended Home Network is an aggregation and is further subnetted. Virtual Home Network: The Home Network associated with a Virtual Network. The Extended Home Network and the Aggregated Home Network can be configured as Virtual Home Network. What do you think? > -----Original Message----- > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > Sent: jeudi 18 d=E9cembre 2003 06:37 > To: Pascal Thubert (pthubert) > Cc: alexandru.petrescu@motorola.com; vijayd@iprg.nokia.com; = nemo@ietf.org > Subject: Re: [nemo] Issue 28 >=20 >=20 > Hi, >=20 >=20 > "Pascal Thubert (pthubert)" wrote: >=20 > > > Let me remind you that we have a separate terminology because the = WG > > > aggreed it; and that the terminology doc contains more terms that = are > > > needed in NEMO Basic Support. So, if you want to move some = definitions > > > in the NEMO Basic Support doc, we would still need a doc for the = other > > > terms ... > > > > > > > I support leaving the definitions in terminology if it goes RFC, as = I mentioned implicitly > in the thread. Question: should we also move the definitions from the = usage draft into the > terminology (I assume yes)? >=20 > Which definitions would be candidates ones ? I will update the > terminology draft before Xmas, and include terms from NEMO Basic > Support, if any. >=20 > > > > For example, MR would be good to be defined in the Terminology = section > > > > but TLMR would be defined in the Terminology document, because = the basic > > > > support draft does not talk about TLMR's at all. > > > > > > - generic terms are defined in draft-ietf-seamoby-terminology, = included > > > MR. > > > > > > - TMLR doesn't exist anymore, it's root-MR. > > > > I support leaving TLMR in the terminology as a deprecated synonym = for root-MR; reason is > it's been used for awhile. >=20 > I can certainly do this. >=20 > I would also like to propose MNet for "mobile networks" (this term has > been proposed by Nicolas M), since NEMO stands for NEtwork MObility = and > MONET may be confused with MANET. Alexandru also proposed some terms, > but I didn't find them reasonably clear. Comments ? >=20 > Thierry. >=20 > > > > Finally, the clarification of MH, MR and MN should be re-stated > > > > somewhere, because currently there is much confusion about this. = Most > > > > text I've read and speech I've heard refers to MN as being a = Mobile > > > > Host; while in reality MN could be either a MH or a MR (by the > > > > definition in the Mobile IPv6 spec). > > > > > > Anyone is free to propose a rephrasing (that is shared by ML = members). > > > To me, a MN is either a host or a router, I think the definitions = are > > > clear about this. > > > > > > > > > I think the NEMO Basic Support doc should only define specific = terms, if > > > needed. For instance, LFN is better defined in an other document, = as it > > > will be used in discussions not only turning around Basic Support. = On > > > the other hand, if we want to define a term R-BU (Router Binding = Update, > > > to distinguish with the MIPv6 BU), the NEMO Basic Support doc is a > > > better place. > > > > > > So, what terms would you like to see in the NEMO Basic Support doc = ? > > > > > > > > > About the status of the terminology doc, I have not issued the WG = last > > > call because I think the terminology about multihoming is not = clear > > > enough and may be enhanced based on the discussion about the = coming > > > multihoming WG document. > > > > > Thierry: this doc will always evolve. So we have to cut RFCs when = needed and start a follow > on. From exim@www1.ietf.org Thu Dec 18 06:33:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15774 for ; Thu, 18 Dec 2003 06:33: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 1AWwOt-00047e-C0 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 06:33:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIBX32b015840 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 06:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwOt-00047P-4P for nemo-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 06:33: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 GAA15694 for ; Thu, 18 Dec 2003 06:32:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWwOp-0002NK-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 06:32:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWwOn-0002ND-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 06:32:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWwOn-0002NA-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 06:32:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwOq-00046e-W6; Thu, 18 Dec 2003 06:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwON-00046P-68 for nemo@optimus.ietf.org; Thu, 18 Dec 2003 06:32: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 GAA15674 for ; Thu, 18 Dec 2003 06:32:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWwOJ-0002N5-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:32:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWwOH-0002My-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:32:26 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AWwOH-0002Mh-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:32:25 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Dec 2003 12:32:51 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hBIBVaot024119; Thu, 18 Dec 2003 12:31:37 +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, 18 Dec 2003 11:31:51 +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] Issue 28 Date: Thu, 18 Dec 2003 11:31:50 -0000 Message-ID: Thread-Topic: [nemo] Issue 28 Thread-Index: AcPFKKAHEMFlvvKxRhiHNcmMiL+GWgAMMCJw From: "Pascal Thubert (pthubert)" To: "Thierry Ernst" Cc: , , X-OriginalArrivalTime: 18 Dec 2003 11:31:51.0395 (UTC) FILETIME=[87E1B330:01C3C55A] 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 Thierry: Usages defines the following additional terminology: Home Link: The link attached to the interface at the Home Agent on which the Home Prefix is configured. The interface can be a virtual interface, in which case the Home Link is a virtual Home Link. Home Network: The Network formed by the application of the Home Prefix on the Home Link. With Nemo, the concept of Home Network is extended as explained below. Home Address: With Mobile IPv6, a Home Address is derived from the Home Network prefix. This is generalized in Nemo, with some limitations: A Home Address can be either derived from the Home Network or from one of the Mobile Router's Mobile Network prefixes. MRHA Tunnel: The bi-directional tunnel between a Mobile Router and its Home Agent Mobile Aggregated Prefix: An aggregation of Mobile Network Prefixes. Aggregated Home Network: The Home Network associated with a Mobile Aggregated Prefix. This Aggregation is advertised as a subnet on the Home Link, and thus used as Home Network for Nemo purposes. Extended Home Network: The network associated with the aggregation of one or more Home Network(s) and Mobile Network(s). As opposed to the Mobile IPv6 Home Network that is a subnet, the extended Home Network is an aggregation and is further subnetted. Virtual Home Network: The Home Network associated with a Virtual Network. The Extended Home Network and the Aggregated Home Network can be configured as Virtual Home Network. What do you think? > -----Original Message----- > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > Sent: jeudi 18 d=E9cembre 2003 06:37 > To: Pascal Thubert (pthubert) > Cc: alexandru.petrescu@motorola.com; vijayd@iprg.nokia.com; = nemo@ietf.org > Subject: Re: [nemo] Issue 28 >=20 >=20 > Hi, >=20 >=20 > "Pascal Thubert (pthubert)" wrote: >=20 > > > Let me remind you that we have a separate terminology because the = WG > > > aggreed it; and that the terminology doc contains more terms that = are > > > needed in NEMO Basic Support. So, if you want to move some = definitions > > > in the NEMO Basic Support doc, we would still need a doc for the = other > > > terms ... > > > > > > > I support leaving the definitions in terminology if it goes RFC, as = I mentioned implicitly > in the thread. Question: should we also move the definitions from the = usage draft into the > terminology (I assume yes)? >=20 > Which definitions would be candidates ones ? I will update the > terminology draft before Xmas, and include terms from NEMO Basic > Support, if any. >=20 > > > > For example, MR would be good to be defined in the Terminology = section > > > > but TLMR would be defined in the Terminology document, because = the basic > > > > support draft does not talk about TLMR's at all. > > > > > > - generic terms are defined in draft-ietf-seamoby-terminology, = included > > > MR. > > > > > > - TMLR doesn't exist anymore, it's root-MR. > > > > I support leaving TLMR in the terminology as a deprecated synonym = for root-MR; reason is > it's been used for awhile. >=20 > I can certainly do this. >=20 > I would also like to propose MNet for "mobile networks" (this term has > been proposed by Nicolas M), since NEMO stands for NEtwork MObility = and > MONET may be confused with MANET. Alexandru also proposed some terms, > but I didn't find them reasonably clear. Comments ? >=20 > Thierry. >=20 > > > > Finally, the clarification of MH, MR and MN should be re-stated > > > > somewhere, because currently there is much confusion about this. = Most > > > > text I've read and speech I've heard refers to MN as being a = Mobile > > > > Host; while in reality MN could be either a MH or a MR (by the > > > > definition in the Mobile IPv6 spec). > > > > > > Anyone is free to propose a rephrasing (that is shared by ML = members). > > > To me, a MN is either a host or a router, I think the definitions = are > > > clear about this. > > > > > > > > > I think the NEMO Basic Support doc should only define specific = terms, if > > > needed. For instance, LFN is better defined in an other document, = as it > > > will be used in discussions not only turning around Basic Support. = On > > > the other hand, if we want to define a term R-BU (Router Binding = Update, > > > to distinguish with the MIPv6 BU), the NEMO Basic Support doc is a > > > better place. > > > > > > So, what terms would you like to see in the NEMO Basic Support doc = ? > > > > > > > > > About the status of the terminology doc, I have not issued the WG = last > > > call because I think the terminology about multihoming is not = clear > > > enough and may be enhanced based on the discussion about the = coming > > > multihoming WG document. > > > > > Thierry: this doc will always evolve. So we have to cut RFCs when = needed and start a follow > on. From nemo-admin@ietf.org Thu Dec 18 06:39:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15957 for ; Thu, 18 Dec 2003 06:39: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 1AWwUe-0004YI-IZ; Thu, 18 Dec 2003 06:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwTq-0004Xu-Uc for nemo@optimus.ietf.org; Thu, 18 Dec 2003 06:38: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 GAA15919 for ; Thu, 18 Dec 2003 06:38:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWwTm-0002RJ-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:38:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWwTm-0002RC-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:38:06 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AWwTl-0002Qr-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:38:05 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 886AA5D016 for ; Thu, 18 Dec 2003 20:37:35 +0900 (JST) Date: Thu, 18 Dec 2003 20:40:01 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Issue 28 Message-Id: <20031218204001.4edb949e.ernst@sfc.wide.ad.jp> In-Reply-To: <3FE18E84.9010701@motorola.com> References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> <3FE18E84.9010701@motorola.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.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 would also like to propose MNet for "mobile networks" > > Against this. We can always use 'mobile network' at its full length. > Similarly, the spec never reads HA, but Home Agent. If on the other > hand 'MNet' is intended for ephemeral conversations, then that's fine, I > can key 'MNet', no problem, but no need to set in stone in document > (sorry if I repeat). OK, OK, I will never raised this again. But I would like people to stop saying "[...] a NEMO [...]", etc. NEMO = NEtwork MObility, not noun. > I think it's too late to start new NEMO definitions... Why would it be too late ? It's not. > > Alexandru also proposed some terms, but I didn't find them reasonably > > clear. Comments ? > > I find it unreasonably unclear which terms are referred(?) :-) > > What I would like to have is to have the terms used by the base support > defined in the base support draft itself. These are not many, and most > of them are already defined by the MIP6 spec. "Mobile Router" is one of > them. A Mobile Node refers to an entity that can work as a Mobile Host > or as a Mobile Router. A Mobile Host does not implement the R-bit in > BU, a Mobile Router does. Subsequently and paradoxically, a Mobile Node > does implement the R-bit. "Mobile Router" is already defined in draft-ietf-seamoby, so what you propose is a re-definition. In draft-ietf-seamoby, it's a generic definition, i.e. with no meaning particular to NEMO Basic Support. May be in NEMO Extended Support the MR won't need to implement the R-bit, so your definition must be clearly defined in the context of NEMO Basic Support. I don't think you need a mention about the R-bit in the definition. What you may need is something else than the term "mobile router": "NEMO-enable router": a MR which implement the NEMO Basic Support's MR functionality. As opposed to MIPv6-enable node. > This does not mean that the separate terminology draft has no reason to > exist, there are many other NEMO terms that it defines and that are not > used in the base doc. I also support Pascal's proposal to add the terms > of draft-usages into the terminology document. OK, but then I request Pascal to send me directly the candidates terms and their definition. Thierry. From exim@www1.ietf.org Thu Dec 18 06:39:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15972 for ; Thu, 18 Dec 2003 06:39: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 1AWwUk-0004aQ-3Q for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 06:39:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIBd692017631 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 06:39:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwUj-0004aI-Vh for nemo-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 06:39: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 GAA15944 for ; Thu, 18 Dec 2003 06:39:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWwUg-0002S4-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 06:39:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWwUe-0002Rx-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 06:39:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWwUe-0002Ru-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 06:39:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwUe-0004YI-IZ; Thu, 18 Dec 2003 06:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwTq-0004Xu-Uc for nemo@optimus.ietf.org; Thu, 18 Dec 2003 06:38: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 GAA15919 for ; Thu, 18 Dec 2003 06:38:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWwTm-0002RJ-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:38:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWwTm-0002RC-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:38:06 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AWwTl-0002Qr-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:38:05 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 886AA5D016 for ; Thu, 18 Dec 2003 20:37:35 +0900 (JST) Date: Thu, 18 Dec 2003 20:40:01 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Issue 28 Message-Id: <20031218204001.4edb949e.ernst@sfc.wide.ad.jp> In-Reply-To: <3FE18E84.9010701@motorola.com> References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> <3FE18E84.9010701@motorola.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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > I would also like to propose MNet for "mobile networks" > > Against this. We can always use 'mobile network' at its full length. > Similarly, the spec never reads HA, but Home Agent. If on the other > hand 'MNet' is intended for ephemeral conversations, then that's fine, I > can key 'MNet', no problem, but no need to set in stone in document > (sorry if I repeat). OK, OK, I will never raised this again. But I would like people to stop saying "[...] a NEMO [...]", etc. NEMO = NEtwork MObility, not noun. > I think it's too late to start new NEMO definitions... Why would it be too late ? It's not. > > Alexandru also proposed some terms, but I didn't find them reasonably > > clear. Comments ? > > I find it unreasonably unclear which terms are referred(?) :-) > > What I would like to have is to have the terms used by the base support > defined in the base support draft itself. These are not many, and most > of them are already defined by the MIP6 spec. "Mobile Router" is one of > them. A Mobile Node refers to an entity that can work as a Mobile Host > or as a Mobile Router. A Mobile Host does not implement the R-bit in > BU, a Mobile Router does. Subsequently and paradoxically, a Mobile Node > does implement the R-bit. "Mobile Router" is already defined in draft-ietf-seamoby, so what you propose is a re-definition. In draft-ietf-seamoby, it's a generic definition, i.e. with no meaning particular to NEMO Basic Support. May be in NEMO Extended Support the MR won't need to implement the R-bit, so your definition must be clearly defined in the context of NEMO Basic Support. I don't think you need a mention about the R-bit in the definition. What you may need is something else than the term "mobile router": "NEMO-enable router": a MR which implement the NEMO Basic Support's MR functionality. As opposed to MIPv6-enable node. > This does not mean that the separate terminology draft has no reason to > exist, there are many other NEMO terms that it defines and that are not > used in the base doc. I also support Pascal's proposal to add the terms > of draft-usages into the terminology document. OK, but then I request Pascal to send me directly the candidates terms and their definition. Thierry. From nemo-admin@ietf.org Thu Dec 18 06:42:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16046 for ; Thu, 18 Dec 2003 06:42: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 1AWwXZ-0004fu-8k; Thu, 18 Dec 2003 06:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwXM-0004fd-LX for nemo@optimus.ietf.org; Thu, 18 Dec 2003 06:41: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 GAA16029 for ; Thu, 18 Dec 2003 06:41:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWwXI-0002V8-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:41:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWwXH-0002V1-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:41:44 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AWwXH-0002UH-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:41:43 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 988B35D016 for ; Thu, 18 Dec 2003 20:41:14 +0900 (JST) Date: Thu, 18 Dec 2003 20:43:40 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Issue 28 Message-Id: <20031218204340.7c29c069.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Pascal, > Usages defines the following additional terminology: > > Home Link: The link attached to the interface at the Home Agent on > which the Home Prefix is configured. The interface can be a > virtual interface, in which case the Home Link is a virtual Home > Link. > > Home Network: The Network formed by the application of the Home > Prefix on the Home Link. With Nemo, the concept of Home Network is > extended as explained below. > > Home Address: With Mobile IPv6, a Home Address is derived from the > Home Network prefix. This is generalized in Nemo, with some > limitations: A Home Address can be either derived from the Home > Network or from one of the Mobile Router's Mobile Network > prefixes. > > MRHA Tunnel: The bi-directional tunnel between a Mobile Router and > its Home Agent > > Mobile Aggregated Prefix: An aggregation of Mobile Network Prefixes. > > Aggregated Home Network: The Home Network associated with a Mobile > Aggregated Prefix. This Aggregation is advertised as a subnet on > the Home Link, and thus used as Home Network for Nemo purposes. > > Extended Home Network: The network associated with the aggregation of > one or more Home Network(s) and Mobile Network(s). As opposed to > the Mobile IPv6 Home Network that is a subnet, the extended Home > Network is an aggregation and is further subnetted. > > Virtual Home Network: The Home Network associated with a Virtual > Network. The Extended Home Network and the Aggregated Home Network > can be configured as Virtual Home Network. > > > What do you think? That some of your definitions are already defined in draft-ietf-seamoby, so it's a re-definition (home link, home address), and we need more words to make it clear or another term. Anyway, I would agree to move that to draft-ietf-nemo-terminology. Thierry. From exim@www1.ietf.org Thu Dec 18 06:42:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16061 for ; Thu, 18 Dec 2003 06:42: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 1AWwXb-0004gv-9Y for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 06:42:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIBg3v3018027 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 06:42:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwXb-0004gg-59 for nemo-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 06:42: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 GAA16038 for ; Thu, 18 Dec 2003 06:41:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWwXX-0002WW-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 06:41:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWwXW-0002WP-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 06:41:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWwXW-0002WM-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 06:41:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwXZ-0004fu-8k; Thu, 18 Dec 2003 06:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWwXM-0004fd-LX for nemo@optimus.ietf.org; Thu, 18 Dec 2003 06:41: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 GAA16029 for ; Thu, 18 Dec 2003 06:41:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWwXI-0002V8-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:41:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWwXH-0002V1-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:41:44 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AWwXH-0002UH-00 for nemo@ietf.org; Thu, 18 Dec 2003 06:41:43 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 988B35D016 for ; Thu, 18 Dec 2003 20:41:14 +0900 (JST) Date: Thu, 18 Dec 2003 20:43:40 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Issue 28 Message-Id: <20031218204340.7c29c069.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Pascal, > Usages defines the following additional terminology: > > Home Link: The link attached to the interface at the Home Agent on > which the Home Prefix is configured. The interface can be a > virtual interface, in which case the Home Link is a virtual Home > Link. > > Home Network: The Network formed by the application of the Home > Prefix on the Home Link. With Nemo, the concept of Home Network is > extended as explained below. > > Home Address: With Mobile IPv6, a Home Address is derived from the > Home Network prefix. This is generalized in Nemo, with some > limitations: A Home Address can be either derived from the Home > Network or from one of the Mobile Router's Mobile Network > prefixes. > > MRHA Tunnel: The bi-directional tunnel between a Mobile Router and > its Home Agent > > Mobile Aggregated Prefix: An aggregation of Mobile Network Prefixes. > > Aggregated Home Network: The Home Network associated with a Mobile > Aggregated Prefix. This Aggregation is advertised as a subnet on > the Home Link, and thus used as Home Network for Nemo purposes. > > Extended Home Network: The network associated with the aggregation of > one or more Home Network(s) and Mobile Network(s). As opposed to > the Mobile IPv6 Home Network that is a subnet, the extended Home > Network is an aggregation and is further subnetted. > > Virtual Home Network: The Home Network associated with a Virtual > Network. The Extended Home Network and the Aggregated Home Network > can be configured as Virtual Home Network. > > > What do you think? That some of your definitions are already defined in draft-ietf-seamoby, so it's a re-definition (home link, home address), and we need more words to make it clear or another term. Anyway, I would agree to move that to draft-ietf-nemo-terminology. Thierry. From nemo-admin@ietf.org Thu Dec 18 07:31:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17693 for ; Thu, 18 Dec 2003 07:31: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 1AWxJ0-00076L-SZ; Thu, 18 Dec 2003 07: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 1AWxI3-00074K-MX for nemo@optimus.ietf.org; Thu, 18 Dec 2003 07:30: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 HAA17534 for ; Thu, 18 Dec 2003 07:30:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWxI3-0004E5-00 for nemo@ietf.org; Thu, 18 Dec 2003 07:30:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWxHv-0004Cg-00 for nemo@ietf.org; Thu, 18 Dec 2003 07:30:02 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AWxHu-0004CX-00 for nemo@ietf.org; Thu, 18 Dec 2003 07:29:54 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 5E4B16A907; Thu, 18 Dec 2003 14:29:53 +0200 (EET) Message-ID: <3FE19D8F.4070809@kolumbus.fi> Date: Thu, 18 Dec 2003 14:29:03 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Cc: Thierry Ernst , "Pascal Thubert (pthubert)" , vijayd@iprg.nokia.com, nemo@ietf.org Subject: Re: [nemo] Issue 28 References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> <3FE18E84.9010701@motorola.com> In-Reply-To: <3FE18E84.9010701@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 Alexandru Petrescu wrote: > What I would like to have is to have the terms used by the base support > defined in the base support draft itself. These are not many, and most > of them are already defined by the MIP6 spec. "Mobile Router" is one of > them. A Mobile Node refers to an entity that can work as a Mobile Host > or as a Mobile Router. A Mobile Host does not implement the R-bit in > BU, a Mobile Router does. Subsequently and paradoxically, a Mobile Node > does implement the R-bit. > > This does not mean that the separate terminology draft has no reason to > exist, there are many other NEMO terms that it defines and that are not > used in the base doc. I also support Pascal's proposal to add the terms > of draft-usages into the terminology document. Right. --Jari From exim@www1.ietf.org Thu Dec 18 07:31:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17717 for ; Thu, 18 Dec 2003 07:31: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 1AWxJ4-00078i-T8 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 07:31:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBICV679027444 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 07:31:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWxJ4-00078X-I1 for nemo-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 07:31: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 HAA17631 for ; Thu, 18 Dec 2003 07:31:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWxJ3-0004Hw-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 07:31:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWxJ2-0004Hh-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 07:31:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWxJ2-0004Hd-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 07:31:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWxJ0-00076L-SZ; Thu, 18 Dec 2003 07: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 1AWxI3-00074K-MX for nemo@optimus.ietf.org; Thu, 18 Dec 2003 07:30: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 HAA17534 for ; Thu, 18 Dec 2003 07:30:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWxI3-0004E5-00 for nemo@ietf.org; Thu, 18 Dec 2003 07:30:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWxHv-0004Cg-00 for nemo@ietf.org; Thu, 18 Dec 2003 07:30:02 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AWxHu-0004CX-00 for nemo@ietf.org; Thu, 18 Dec 2003 07:29:54 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 5E4B16A907; Thu, 18 Dec 2003 14:29:53 +0200 (EET) Message-ID: <3FE19D8F.4070809@kolumbus.fi> Date: Thu, 18 Dec 2003 14:29:03 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Cc: Thierry Ernst , "Pascal Thubert (pthubert)" , vijayd@iprg.nokia.com, nemo@ietf.org Subject: Re: [nemo] Issue 28 References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> <3FE18E84.9010701@motorola.com> In-Reply-To: <3FE18E84.9010701@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 Alexandru Petrescu wrote: > What I would like to have is to have the terms used by the base support > defined in the base support draft itself. These are not many, and most > of them are already defined by the MIP6 spec. "Mobile Router" is one of > them. A Mobile Node refers to an entity that can work as a Mobile Host > or as a Mobile Router. A Mobile Host does not implement the R-bit in > BU, a Mobile Router does. Subsequently and paradoxically, a Mobile Node > does implement the R-bit. > > This does not mean that the separate terminology draft has no reason to > exist, there are many other NEMO terms that it defines and that are not > used in the base doc. I also support Pascal's proposal to add the terms > of draft-usages into the terminology document. Right. --Jari From nemo-admin@ietf.org Thu Dec 18 08:03:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19228 for ; Thu, 18 Dec 2003 08:03: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 1AWxnw-0000H8-SH; Thu, 18 Dec 2003 08:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWxnB-0000FW-SN for nemo@optimus.ietf.org; Thu, 18 Dec 2003 08:02: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 IAA19094 for ; Thu, 18 Dec 2003 08:02:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWxnA-00061c-00 for nemo@ietf.org; Thu, 18 Dec 2003 08:02:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWxmx-0005zW-00 for nemo@ietf.org; Thu, 18 Dec 2003 08:02:10 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AWxmw-0005z7-00 for nemo@ietf.org; Thu, 18 Dec 2003 08:01:58 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id hBID1mkA000457; Thu, 18 Dec 2003 06:01:48 -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 hBID1nVo005801; Thu, 18 Dec 2003 07:01:50 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 7E92E85272C; Thu, 18 Dec 2003 14:01:49 +0100 (CET) Message-ID: <3FE1A53D.5010001@motorola.com> Date: Thu, 18 Dec 2003 14:01:49 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: nemo@ietf.org Subject: Re: [nemo] Issue 28 References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> <3FE18E84.9010701@motorola.com> <20031218204001.4edb949e.ernst@sfc.wide.ad.jp> In-Reply-To: <20031218204001.4edb949e.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: >>> I would also like to propose MNet for "mobile networks" >> >> Against this. We can always use 'mobile network' at its full >> length. Similarly, the spec never reads HA, but Home Agent. If on >> the other hand 'MNet' is intended for ephemeral conversations, then >> that's fine, I can key 'MNet', no problem, but no need to set in >> stone in document (sorry if I repeat). > > > OK, OK, I will never raised this again. But I would like people to > stop saying "[...] a NEMO [...]", etc. NEMO = NEtwork MObility, not > noun. Very good, me too. So where is the NEMO term itself defined? Just add something to its definition: "not to be used as a noun". > "Mobile Router" is already defined in draft-ietf-seamoby, so what you > propose is a re-definition. I don't think Seamoby did any protocol related to Mobile Routers. I think the intent of that document is to gather together _all_ mobility-related terms, a nice endeavour, but prone to failure of course if it does not succeed to gather all useful terms (like all the NEMO terminology document) and defines new and little used terms (like 'mobility factor'). Once it is not accepted to merge the entire NEMO terminology document within the Seamoby terminology document, there is a problem anyways. > In draft-ietf-seamoby, it's a generic definition, i.e. with no > meaning particular to NEMO Basic Support. May be in NEMO Extended > Support the MR won't need to implement the R-bit, so your definition > must be clearly defined in the context of NEMO Basic Support. I don't > think you need a mention about the R-bit in the definition. > > What you may need is something else than the term "mobile router": > "NEMO-enable router": a MR which implement the NEMO Basic Support's > MR functionality. As opposed to MIPv6-enable node. Independently of what draft Seamoby says and independently of what the MANET group thinks about a Mobile Router. A Mobile Router _is_ a Mobile IPv6-capable router. That fact that we use the term "Mobile" is direct relation to Mobile IPv6. A router that is moving in the physical dimension, but stays attached to the same access systems, keeps same address, is _not_ a "mobile" router at all. A router looks at the world from an IP perspective, so if it sees no change in its IP address then everything appears static, nothing moves. One could call it a mobile L2 d > > >> This does not mean that the separate terminology draft has no >> reason to exist, there are many other NEMO terms that it defines >> and that are not used in the base doc. I also support Pascal's >> proposal to add the terms of draft-usages into the terminology >> document. > > > OK, but then I request Pascal to send me directly the candidates > terms and their definition. > > Thierry. > From exim@www1.ietf.org Thu Dec 18 08:03:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19243 for ; Thu, 18 Dec 2003 08:03: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 1AWxo1-0000IQ-CM for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 08:03:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBID354r001128 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 08:03:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWxo1-0000I7-7Q for nemo-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 08:03: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 IAA19194 for ; Thu, 18 Dec 2003 08:03:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWxo0-00067T-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 08:03:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWxny-00067J-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 08:03:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWxny-00067G-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 08:03:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWxnw-0000H8-SH; Thu, 18 Dec 2003 08:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWxnB-0000FW-SN for nemo@optimus.ietf.org; Thu, 18 Dec 2003 08:02: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 IAA19094 for ; Thu, 18 Dec 2003 08:02:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWxnA-00061c-00 for nemo@ietf.org; Thu, 18 Dec 2003 08:02:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWxmx-0005zW-00 for nemo@ietf.org; Thu, 18 Dec 2003 08:02:10 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AWxmw-0005z7-00 for nemo@ietf.org; Thu, 18 Dec 2003 08:01:58 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id hBID1mkA000457; Thu, 18 Dec 2003 06:01:48 -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 hBID1nVo005801; Thu, 18 Dec 2003 07:01:50 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 7E92E85272C; Thu, 18 Dec 2003 14:01:49 +0100 (CET) Message-ID: <3FE1A53D.5010001@motorola.com> Date: Thu, 18 Dec 2003 14:01:49 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: nemo@ietf.org Subject: Re: [nemo] Issue 28 References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> <3FE18E84.9010701@motorola.com> <20031218204001.4edb949e.ernst@sfc.wide.ad.jp> In-Reply-To: <20031218204001.4edb949e.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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: >>> I would also like to propose MNet for "mobile networks" >> >> Against this. We can always use 'mobile network' at its full >> length. Similarly, the spec never reads HA, but Home Agent. If on >> the other hand 'MNet' is intended for ephemeral conversations, then >> that's fine, I can key 'MNet', no problem, but no need to set in >> stone in document (sorry if I repeat). > > > OK, OK, I will never raised this again. But I would like people to > stop saying "[...] a NEMO [...]", etc. NEMO = NEtwork MObility, not > noun. Very good, me too. So where is the NEMO term itself defined? Just add something to its definition: "not to be used as a noun". > "Mobile Router" is already defined in draft-ietf-seamoby, so what you > propose is a re-definition. I don't think Seamoby did any protocol related to Mobile Routers. I think the intent of that document is to gather together _all_ mobility-related terms, a nice endeavour, but prone to failure of course if it does not succeed to gather all useful terms (like all the NEMO terminology document) and defines new and little used terms (like 'mobility factor'). Once it is not accepted to merge the entire NEMO terminology document within the Seamoby terminology document, there is a problem anyways. > In draft-ietf-seamoby, it's a generic definition, i.e. with no > meaning particular to NEMO Basic Support. May be in NEMO Extended > Support the MR won't need to implement the R-bit, so your definition > must be clearly defined in the context of NEMO Basic Support. I don't > think you need a mention about the R-bit in the definition. > > What you may need is something else than the term "mobile router": > "NEMO-enable router": a MR which implement the NEMO Basic Support's > MR functionality. As opposed to MIPv6-enable node. Independently of what draft Seamoby says and independently of what the MANET group thinks about a Mobile Router. A Mobile Router _is_ a Mobile IPv6-capable router. That fact that we use the term "Mobile" is direct relation to Mobile IPv6. A router that is moving in the physical dimension, but stays attached to the same access systems, keeps same address, is _not_ a "mobile" router at all. A router looks at the world from an IP perspective, so if it sees no change in its IP address then everything appears static, nothing moves. One could call it a mobile L2 d > > >> This does not mean that the separate terminology draft has no >> reason to exist, there are many other NEMO terms that it defines >> and that are not used in the base doc. I also support Pascal's >> proposal to add the terms of draft-usages into the terminology >> document. > > > OK, but then I request Pascal to send me directly the candidates > terms and their definition. > > Thierry. > From nemo-admin@ietf.org Thu Dec 18 08:35:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21233 for ; Thu, 18 Dec 2003 08:35: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 1AWyIw-0001uM-Vv; Thu, 18 Dec 2003 08:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyIW-0001tK-UQ for nemo@optimus.ietf.org; Thu, 18 Dec 2003 08:34: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 IAA21198 for ; Thu, 18 Dec 2003 08:34:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWyIV-000183-00 for nemo@ietf.org; Thu, 18 Dec 2003 08:34:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWyIU-00017v-00 for nemo@ietf.org; Thu, 18 Dec 2003 08:34:35 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AWyIU-00017r-00 for nemo@ietf.org; Thu, 18 Dec 2003 08:34:34 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBIDYXSs029000; Thu, 18 Dec 2003 14:34:33 +0100 (MET) Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.75]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id Z1FXVDPP; Thu, 18 Dec 2003 14:35:44 +0100 Message-ID: <3FE1ACE7.2010005@ericsson.com> Date: Thu, 18 Dec 2003 14:34:31 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 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: Alexandru Petrescu CC: Thierry Ernst , nemo@ietf.org Subject: Re: [nemo] Issue 28 References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> <3FE18E84.9010701@motorola.com> <20031218204001.4edb949e.ernst@sfc.wide.ad.jp> <3FE1A53D.5010001@motorola.com> In-Reply-To: <3FE1A53D.5010001@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 Alexandru Petrescu wrote: > Thierry Ernst wrote: > >>>> I would also like to propose MNet for "mobile networks" >>> >>> >>> Against this. We can always use 'mobile network' at its full length. >>> Similarly, the spec never reads HA, but Home Agent. If on the other >>> hand 'MNet' is intended for ephemeral conversations, then >>> that's fine, I can key 'MNet', no problem, but no need to set in >>> stone in document (sorry if I repeat). >> >> >> >> OK, OK, I will never raised this again. But I would like people to >> stop saying "[...] a NEMO [...]", etc. NEMO = NEtwork MObility, not noun. > > > Very good, me too. So where is the NEMO term itself defined? Just add > something to its definition: "not to be used as a noun". > What happened to the alternative meaning of NEMO; NEtwork in MOtion? It is a noun, and permits the use of "a NEMO". Sorry, Thierry... :) Personally, I prefer to talk about "a moving network". /Mattias From exim@www1.ietf.org Thu Dec 18 08:35:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21248 for ; Thu, 18 Dec 2003 08: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 1AWyJ0-0001vP-Lx for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 08:35:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIDZ6Qb007393 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 08:35:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyJ0-0001vA-Gs for nemo-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 08:35: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 IAA21224 for ; Thu, 18 Dec 2003 08:35:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWyIz-00019E-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 08:35:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWyIy-000197-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 08:35:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWyIy-000194-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 08:35:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyIw-0001uM-Vv; Thu, 18 Dec 2003 08:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyIW-0001tK-UQ for nemo@optimus.ietf.org; Thu, 18 Dec 2003 08:34: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 IAA21198 for ; Thu, 18 Dec 2003 08:34:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWyIV-000183-00 for nemo@ietf.org; Thu, 18 Dec 2003 08:34:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWyIU-00017v-00 for nemo@ietf.org; Thu, 18 Dec 2003 08:34:35 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AWyIU-00017r-00 for nemo@ietf.org; Thu, 18 Dec 2003 08:34:34 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBIDYXSs029000; Thu, 18 Dec 2003 14:34:33 +0100 (MET) Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.75]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id Z1FXVDPP; Thu, 18 Dec 2003 14:35:44 +0100 Message-ID: <3FE1ACE7.2010005@ericsson.com> Date: Thu, 18 Dec 2003 14:34:31 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 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: Alexandru Petrescu CC: Thierry Ernst , nemo@ietf.org Subject: Re: [nemo] Issue 28 References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> <3FE18E84.9010701@motorola.com> <20031218204001.4edb949e.ernst@sfc.wide.ad.jp> <3FE1A53D.5010001@motorola.com> In-Reply-To: <3FE1A53D.5010001@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 Alexandru Petrescu wrote: > Thierry Ernst wrote: > >>>> I would also like to propose MNet for "mobile networks" >>> >>> >>> Against this. We can always use 'mobile network' at its full length. >>> Similarly, the spec never reads HA, but Home Agent. If on the other >>> hand 'MNet' is intended for ephemeral conversations, then >>> that's fine, I can key 'MNet', no problem, but no need to set in >>> stone in document (sorry if I repeat). >> >> >> >> OK, OK, I will never raised this again. But I would like people to >> stop saying "[...] a NEMO [...]", etc. NEMO = NEtwork MObility, not noun. > > > Very good, me too. So where is the NEMO term itself defined? Just add > something to its definition: "not to be used as a noun". > What happened to the alternative meaning of NEMO; NEtwork in MOtion? It is a noun, and permits the use of "a NEMO". Sorry, Thierry... :) Personally, I prefer to talk about "a moving network". /Mattias From nemo-admin@ietf.org Thu Dec 18 08:52:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21944 for ; Thu, 18 Dec 2003 08:52: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 1AWyZM-0002r4-Pn; Thu, 18 Dec 2003 08:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyYR-0002i3-Bo for nemo@optimus.ietf.org; Thu, 18 Dec 2003 08:51: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 IAA21833 for ; Thu, 18 Dec 2003 08:51:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWyYP-0001oP-00 for nemo@ietf.org; Thu, 18 Dec 2003 08:51:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWyYO-0001oI-00 for nemo@ietf.org; Thu, 18 Dec 2003 08:51:01 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1AWyYO-0001oE-00 for nemo@ietf.org; Thu, 18 Dec 2003 08:51:00 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id hBIDoGfL018389; Thu, 18 Dec 2003 06:50:19 -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 hBIDldVo007034; Thu, 18 Dec 2003 07:47:40 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 1F13085272C; Thu, 18 Dec 2003 14:47:39 +0100 (CET) Message-ID: <3FE1AFFA.7070301@motorola.com> Date: Thu, 18 Dec 2003 14:47:38 +0100 From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mattias Pettersson Cc: Alexandru Petrescu , Thierry Ernst , nemo@ietf.org Subject: Re: [nemo] Issue 28 References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> <3FE18E84.9010701@motorola.com> <20031218204001.4edb949e.ernst@sfc.wide.ad.jp> <3FE1A53D.5010001@motorola.com> <3FE1ACE7.2010005@ericsson.com> In-Reply-To: <3FE1ACE7.2010005@ericsson.com> X-Enigmail-Version: 0.75.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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 Mattias Pettersson wrote: > > > Alexandru Petrescu wrote: > >> Thierry Ernst wrote: >> >>>>> I would also like to propose MNet for "mobile networks" >>>> >>>> >>>> >>>> Against this. We can always use 'mobile network' at its full >>>> length. Similarly, the spec never reads HA, but Home Agent. If >>>> on the other hand 'MNet' is intended for ephemeral >>>> conversations, then that's fine, I can key 'MNet', no problem, >>>> but no need to set in stone in document (sorry if I repeat). >>> >>> >>> >>> >>> OK, OK, I will never raised this again. But I would like people >>> to stop saying "[...] a NEMO [...]", etc. NEMO = NEtwork >>> MObility, not noun. >> >> >> >> Very good, me too. So where is the NEMO term itself defined? Just >> add something to its definition: "not to be used as a noun". >> > > What happened to the alternative meaning of NEMO; NEtwork in MOtion? > It is a noun, and permits the use of "a NEMO". > > Sorry, Thierry... :) > > Personally, I prefer to talk about "a moving network". Yes, me too sometimes, because it does not clash with the established "mobile network" term typically used in telco text. That is an infrastructure that supports mobile devices (e.g. the established term "GPRS mobile network" is the set of GGSN/SGSN's, node b's, rnc's and bs's that are, in fact, the fixed infrastructure, and just support "mobile handsets"). Alex From exim@www1.ietf.org Thu Dec 18 08:52:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21959 for ; Thu, 18 Dec 2003 08: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 1AWyZQ-0002tg-2B for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 08:52:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIDq4K7011135 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 08:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyZP-0002sj-Tg for nemo-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 08:52: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 IAA21902 for ; Thu, 18 Dec 2003 08:52:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWyZO-0001rP-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 08:52:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWyZN-0001rH-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 08:52:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWyZN-0001rE-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 08:52:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyZM-0002r4-Pn; Thu, 18 Dec 2003 08:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyYR-0002i3-Bo for nemo@optimus.ietf.org; Thu, 18 Dec 2003 08:51: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 IAA21833 for ; Thu, 18 Dec 2003 08:51:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWyYP-0001oP-00 for nemo@ietf.org; Thu, 18 Dec 2003 08:51:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWyYO-0001oI-00 for nemo@ietf.org; Thu, 18 Dec 2003 08:51:01 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1AWyYO-0001oE-00 for nemo@ietf.org; Thu, 18 Dec 2003 08:51:00 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id hBIDoGfL018389; Thu, 18 Dec 2003 06:50:19 -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 hBIDldVo007034; Thu, 18 Dec 2003 07:47:40 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 1F13085272C; Thu, 18 Dec 2003 14:47:39 +0100 (CET) Message-ID: <3FE1AFFA.7070301@motorola.com> Date: Thu, 18 Dec 2003 14:47:38 +0100 From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mattias Pettersson Cc: Alexandru Petrescu , Thierry Ernst , nemo@ietf.org Subject: Re: [nemo] Issue 28 References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> <3FE18E84.9010701@motorola.com> <20031218204001.4edb949e.ernst@sfc.wide.ad.jp> <3FE1A53D.5010001@motorola.com> <3FE1ACE7.2010005@ericsson.com> In-Reply-To: <3FE1ACE7.2010005@ericsson.com> X-Enigmail-Version: 0.75.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 Mattias Pettersson wrote: > > > Alexandru Petrescu wrote: > >> Thierry Ernst wrote: >> >>>>> I would also like to propose MNet for "mobile networks" >>>> >>>> >>>> >>>> Against this. We can always use 'mobile network' at its full >>>> length. Similarly, the spec never reads HA, but Home Agent. If >>>> on the other hand 'MNet' is intended for ephemeral >>>> conversations, then that's fine, I can key 'MNet', no problem, >>>> but no need to set in stone in document (sorry if I repeat). >>> >>> >>> >>> >>> OK, OK, I will never raised this again. But I would like people >>> to stop saying "[...] a NEMO [...]", etc. NEMO = NEtwork >>> MObility, not noun. >> >> >> >> Very good, me too. So where is the NEMO term itself defined? Just >> add something to its definition: "not to be used as a noun". >> > > What happened to the alternative meaning of NEMO; NEtwork in MOtion? > It is a noun, and permits the use of "a NEMO". > > Sorry, Thierry... :) > > Personally, I prefer to talk about "a moving network". Yes, me too sometimes, because it does not clash with the established "mobile network" term typically used in telco text. That is an infrastructure that supports mobile devices (e.g. the established term "GPRS mobile network" is the set of GGSN/SGSN's, node b's, rnc's and bs's that are, in fact, the fixed infrastructure, and just support "mobile handsets"). Alex From nemo-admin@ietf.org Thu Dec 18 09:28:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23191 for ; Thu, 18 Dec 2003 09:28: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 1AWz8D-0004Xh-Ec; Thu, 18 Dec 2003 09:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWz7f-0004Wc-8J for nemo@optimus.ietf.org; Thu, 18 Dec 2003 09:27: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 JAA23124 for ; Thu, 18 Dec 2003 09:27:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWz7W-0003Yn-00 for nemo@ietf.org; Thu, 18 Dec 2003 09:27:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWz76-0003XQ-00 for nemo@ietf.org; Thu, 18 Dec 2003 09:26:52 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AWz76-0003VV-00 for nemo@ietf.org; Thu, 18 Dec 2003 09:26:52 -0500 Received: from huez (U190239.ppp.dion.ne.jp [218.222.190.239]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 58CE85D0A1; Thu, 18 Dec 2003 23:25:49 +0900 (JST) Date: Thu, 18 Dec 2003 23:33:31 +0900 From: Thierry Ernst To: Mattias Pettersson Cc: alexandru.petrescu@motorola.com, nemo@ietf.org Subject: Re: [nemo] Issue 28 Message-Id: <20031218233331.43e4e0f7.ernst@sfc.wide.ad.jp> In-Reply-To: <3FE1ACE7.2010005@ericsson.com> References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> <3FE18E84.9010701@motorola.com> <20031218204001.4edb949e.ernst@sfc.wide.ad.jp> <3FE1A53D.5010001@motorola.com> <3FE1ACE7.2010005@ericsson.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 > What happened to the alternative meaning of NEMO; NEtwork in MOtion? It > is a noun, and permits the use of "a NEMO". > > Sorry, Thierry... :) No, it was discarded. I was personnaly trying to use NEMO as both an acronym and a noun, but we reached the conclusion it shouldn't. And, "in motion" was perceived as missleading, since a network can change its point of attachment without actually moving ... :-) > Personally, I prefer to talk about "a moving network". From exim@www1.ietf.org Thu Dec 18 09:29:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23274 for ; Thu, 18 Dec 2003 09:29:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWz95-0004dU-90 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 09:28:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIEStEx017814 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 09:28:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWz95-0004dF-1d for nemo-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 09:28: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 JAA23224 for ; Thu, 18 Dec 2003 09:28:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWz8y-0003el-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 09:28:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWz8W-0003di-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 09:28:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWz8W-0003cM-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 09:28:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWz8D-0004Xh-Ec; Thu, 18 Dec 2003 09:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWz7f-0004Wc-8J for nemo@optimus.ietf.org; Thu, 18 Dec 2003 09:27: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 JAA23124 for ; Thu, 18 Dec 2003 09:27:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWz7W-0003Yn-00 for nemo@ietf.org; Thu, 18 Dec 2003 09:27:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWz76-0003XQ-00 for nemo@ietf.org; Thu, 18 Dec 2003 09:26:52 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AWz76-0003VV-00 for nemo@ietf.org; Thu, 18 Dec 2003 09:26:52 -0500 Received: from huez (U190239.ppp.dion.ne.jp [218.222.190.239]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 58CE85D0A1; Thu, 18 Dec 2003 23:25:49 +0900 (JST) Date: Thu, 18 Dec 2003 23:33:31 +0900 From: Thierry Ernst To: Mattias Pettersson Cc: alexandru.petrescu@motorola.com, nemo@ietf.org Subject: Re: [nemo] Issue 28 Message-Id: <20031218233331.43e4e0f7.ernst@sfc.wide.ad.jp> In-Reply-To: <3FE1ACE7.2010005@ericsson.com> References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> <3FE18E84.9010701@motorola.com> <20031218204001.4edb949e.ernst@sfc.wide.ad.jp> <3FE1A53D.5010001@motorola.com> <3FE1ACE7.2010005@ericsson.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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 > What happened to the alternative meaning of NEMO; NEtwork in MOtion? It > is a noun, and permits the use of "a NEMO". > > Sorry, Thierry... :) No, it was discarded. I was personnaly trying to use NEMO as both an acronym and a noun, but we reached the conclusion it shouldn't. And, "in motion" was perceived as missleading, since a network can change its point of attachment without actually moving ... :-) > Personally, I prefer to talk about "a moving network". From nemo-admin@ietf.org Thu Dec 18 09:44:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24132 for ; Thu, 18 Dec 2003 09:44: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 1AWzNh-0005Xs-RY; Thu, 18 Dec 2003 09: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 1AWzN2-0005XN-3X for nemo@optimus.ietf.org; Thu, 18 Dec 2003 09:43: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 JAA24036 for ; Thu, 18 Dec 2003 09:43:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWzN0-0004Se-00 for nemo@ietf.org; Thu, 18 Dec 2003 09:43:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWzMy-0004SS-00 for nemo@ietf.org; Thu, 18 Dec 2003 09:43:17 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AWzMx-0004QD-00 for nemo@ietf.org; Thu, 18 Dec 2003 09:43:15 -0500 Received: from huez (U190239.ppp.dion.ne.jp [218.222.190.239]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 000665D197; Thu, 18 Dec 2003 23:42:38 +0900 (JST) Date: Thu, 18 Dec 2003 23:50:26 +0900 From: Thierry Ernst To: Alexandru Petrescu Cc: nemo@ietf.org Subject: Re: [nemo] Issue 28 Message-Id: <20031218235026.0bb78636.ernst@sfc.wide.ad.jp> In-Reply-To: <3FE1A53D.5010001@motorola.com> References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> <3FE18E84.9010701@motorola.com> <20031218204001.4edb949e.ernst@sfc.wide.ad.jp> <3FE1A53D.5010001@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, > > OK, OK, I will never raised this again. But I would like people to > > stop saying "[...] a NEMO [...]", etc. NEMO = NEtwork MObility, not > > noun. > > Very good, me too. So where is the NEMO term itself defined? Just add > something to its definition: "not to be used as a noun". Good point, there is no formal definition for 'NEMO' in the present draft. > > "Mobile Router" is already defined in draft-ietf-seamoby, so what you > > propose is a re-definition. > > I don't think Seamoby did any protocol related to Mobile Routers. No, so what ? The mobility terminology document is edited there because no other WG was taking care of it. Once it becomes a RFC, nobody will ever care about the WG where it was devised. > I think the intent of that document is to gather together _all_ > mobility-related terms, a nice endeavour, but prone to failure of course Diseagree. A common terminology is missing and I will enforce that the NEMO WG sticks to the terminology defined in draft-ietf-seamoby-terminology. The purpose of that document is to list generic definitions. Mobile Router as presently defined there is generic. More below after (*) > if it does not succeed to gather all useful terms (like all the NEMO > terminology document) and defines new and little used terms (like > 'mobility factor'). > Once it is not accepted to merge the entire NEMO terminology document > within the Seamoby terminology document, there is a problem anyways. I disagree. draft-ietf-nemo-terminology list attempts to list terms specific to network mobility, but not specific to NEMO Basic Support. I support modularity, as long as we make sure each module interact well with its neighbours. This is true for protocols, but also for definition. > > In draft-ietf-seamoby, it's a generic definition, i.e. with no > > meaning particular to NEMO Basic Support. May be in NEMO Extended > > Support the MR won't need to implement the R-bit, so your definition > > must be clearly defined in the context of NEMO Basic Support. I don't > > think you need a mention about the R-bit in the definition. > > > > > What you may need is something else than the term "mobile router": > > "NEMO-enable router": a MR which implement the NEMO Basic Support's > > MR functionality. As opposed to MIPv6-enable node. > > Independently of what draft Seamoby says and independently of what the > MANET group thinks about a Mobile Router. A Mobile Router _is_ a Mobile > IPv6-capable router. Disagree. (*) A Mobile Router is a router that changes the point of attachment of its egress interface. The mobility management of such change of point of attachment could be done by any protocol, not necessarily Mobile IPv6 (and, indeed, it's NEMO, not Mobile IPv6, so kill your own argument here). The definition of MR as it is stated in draft-..-seamoby can be used by MANET and NEMO WG the same way. On the other hand, NEMO Basic Support is defining functionalities to be added to the Mobile Router so that the mobility of the network is solely managed by the MR. > That fact that we use the term "Mobile" is direct relation to Mobile IPv6. No. > A router that is moving in the physical dimension, but stays attached to > the same access systems, keeps same address, is _not_ a "mobile" router > at all. A router looks at the world from an IP perspective, so if it > sees no change in its IP address then everything appears static, nothing > moves. Totally agree ! That's exactly what defines "mobility". So, the definition of MR (and other terms) should be independent to the mechanism used to manage mobility. It should merely specify what are the characteristics of the node, i.e. changing its address. Thierry. From exim@www1.ietf.org Thu Dec 18 09:44:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24155 for ; Thu, 18 Dec 2003 09:44: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 1AWzNq-0005ZG-Q2 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 09:44:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIEiAD0021396 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 09:44:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWzNq-0005Z1-LO for nemo-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 09:44: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 JAA24099 for ; Thu, 18 Dec 2003 09:44:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWzNn-0004XM-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 09:44:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWzNl-0004Wz-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 09:44:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWzNk-0004Wu-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 09:44:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWzNh-0005Xs-RY; Thu, 18 Dec 2003 09: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 1AWzN2-0005XN-3X for nemo@optimus.ietf.org; Thu, 18 Dec 2003 09:43: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 JAA24036 for ; Thu, 18 Dec 2003 09:43:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWzN0-0004Se-00 for nemo@ietf.org; Thu, 18 Dec 2003 09:43:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWzMy-0004SS-00 for nemo@ietf.org; Thu, 18 Dec 2003 09:43:17 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AWzMx-0004QD-00 for nemo@ietf.org; Thu, 18 Dec 2003 09:43:15 -0500 Received: from huez (U190239.ppp.dion.ne.jp [218.222.190.239]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 000665D197; Thu, 18 Dec 2003 23:42:38 +0900 (JST) Date: Thu, 18 Dec 2003 23:50:26 +0900 From: Thierry Ernst To: Alexandru Petrescu Cc: nemo@ietf.org Subject: Re: [nemo] Issue 28 Message-Id: <20031218235026.0bb78636.ernst@sfc.wide.ad.jp> In-Reply-To: <3FE1A53D.5010001@motorola.com> References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> <3FE18E84.9010701@motorola.com> <20031218204001.4edb949e.ernst@sfc.wide.ad.jp> <3FE1A53D.5010001@motorola.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , 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, > > OK, OK, I will never raised this again. But I would like people to > > stop saying "[...] a NEMO [...]", etc. NEMO = NEtwork MObility, not > > noun. > > Very good, me too. So where is the NEMO term itself defined? Just add > something to its definition: "not to be used as a noun". Good point, there is no formal definition for 'NEMO' in the present draft. > > "Mobile Router" is already defined in draft-ietf-seamoby, so what you > > propose is a re-definition. > > I don't think Seamoby did any protocol related to Mobile Routers. No, so what ? The mobility terminology document is edited there because no other WG was taking care of it. Once it becomes a RFC, nobody will ever care about the WG where it was devised. > I think the intent of that document is to gather together _all_ > mobility-related terms, a nice endeavour, but prone to failure of course Diseagree. A common terminology is missing and I will enforce that the NEMO WG sticks to the terminology defined in draft-ietf-seamoby-terminology. The purpose of that document is to list generic definitions. Mobile Router as presently defined there is generic. More below after (*) > if it does not succeed to gather all useful terms (like all the NEMO > terminology document) and defines new and little used terms (like > 'mobility factor'). > Once it is not accepted to merge the entire NEMO terminology document > within the Seamoby terminology document, there is a problem anyways. I disagree. draft-ietf-nemo-terminology list attempts to list terms specific to network mobility, but not specific to NEMO Basic Support. I support modularity, as long as we make sure each module interact well with its neighbours. This is true for protocols, but also for definition. > > In draft-ietf-seamoby, it's a generic definition, i.e. with no > > meaning particular to NEMO Basic Support. May be in NEMO Extended > > Support the MR won't need to implement the R-bit, so your definition > > must be clearly defined in the context of NEMO Basic Support. I don't > > think you need a mention about the R-bit in the definition. > > > > > What you may need is something else than the term "mobile router": > > "NEMO-enable router": a MR which implement the NEMO Basic Support's > > MR functionality. As opposed to MIPv6-enable node. > > Independently of what draft Seamoby says and independently of what the > MANET group thinks about a Mobile Router. A Mobile Router _is_ a Mobile > IPv6-capable router. Disagree. (*) A Mobile Router is a router that changes the point of attachment of its egress interface. The mobility management of such change of point of attachment could be done by any protocol, not necessarily Mobile IPv6 (and, indeed, it's NEMO, not Mobile IPv6, so kill your own argument here). The definition of MR as it is stated in draft-..-seamoby can be used by MANET and NEMO WG the same way. On the other hand, NEMO Basic Support is defining functionalities to be added to the Mobile Router so that the mobility of the network is solely managed by the MR. > That fact that we use the term "Mobile" is direct relation to Mobile IPv6. No. > A router that is moving in the physical dimension, but stays attached to > the same access systems, keeps same address, is _not_ a "mobile" router > at all. A router looks at the world from an IP perspective, so if it > sees no change in its IP address then everything appears static, nothing > moves. Totally agree ! That's exactly what defines "mobility". So, the definition of MR (and other terms) should be independent to the mechanism used to manage mobility. It should merely specify what are the characteristics of the node, i.e. changing its address. Thierry. From nemo-admin@ietf.org Thu Dec 18 14:57:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12209 for ; Thu, 18 Dec 2003 14: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 1AX4Gb-0004Uf-1a; Thu, 18 Dec 2003 14: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 1AX4Fc-0004Sy-7b for nemo@optimus.ietf.org; Thu, 18 Dec 2003 14:56: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 OAA12132 for ; Thu, 18 Dec 2003 14:55:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX4FZ-0004gj-00 for nemo@ietf.org; Thu, 18 Dec 2003 14:55:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX4FY-0004gc-00 for nemo@ietf.org; Thu, 18 Dec 2003 14:55:57 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AX4FX-0004dP-00 for nemo@ietf.org; Thu, 18 Dec 2003 14:55:56 -0500 Received: from [64.36.73.246] (wideload.kniveton.com [64.36.73.246]) by multihop.net (8.12.10/8.12.10) with ESMTP id hBIJsir4039967 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 18 Dec 2003 11:54:44 -0800 (PST) (envelope-from tj@kniveton.com) Mime-Version: 1.0 (Apple Message framework v609) In-Reply-To: <3FE1A53D.5010001@motorola.com> References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> <3FE18E84.9010701@motorola.com> <20031218204001.4edb949e.ernst@sfc.wide.ad.jp> <3FE1A53D.5010001@motorola.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7--1019252318; protocol="application/pkcs7-signature" Message-Id: From: "T.J. Kniveton" Subject: Re: [nemo] Issue 28 Date: Thu, 18 Dec 2003 11:53:47 -0800 To: nemo@ietf.org X-Mailer: Apple Mail (2.609) 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-7--1019252318 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Dec 18, 2003, at 5:01 AM, Alexandru Petrescu wrote: > Thierry Ernst wrote: >>>> I would also like to propose MNet for "mobile networks" >>> Against this. We can always use 'mobile network' at its full >>> length. Similarly, the spec never reads HA, but Home Agent. If on >>> the other hand 'MNet' is intended for ephemeral conversations, then >>> that's fine, I can key 'MNet', no problem, but no need to set in >>> stone in document (sorry if I repeat). >> OK, OK, I will never raised this again. But I would like people to >> stop saying "[...] a NEMO [...]", etc. NEMO = NEtwork MObility, not >> noun. > > Very good, me too. So where is the NEMO term itself defined? Just add > something to its definition: "not to be used as a noun". Why not? It's short, concise, and people know what it means - a NEtwork that's MObile. I don't have any problem using NEMO as a noun the same way we used to use MONET. If we introduce a new term it has the potential to be more cumbersome. TJ > >> "Mobile Router" is already defined in draft-ietf-seamoby, so what you >> propose is a re-definition. > > I don't think Seamoby did any protocol related to Mobile Routers. The NEMO WG is where the locus of work on mobile routers is happening. So it makes sense to (re)define the term, at least for our own purposes. > >> In draft-ietf-seamoby, it's a generic definition, i.e. with no >> meaning particular to NEMO Basic Support. May be in NEMO Extended >> Support the MR won't need to implement the R-bit, so your definition >> must be clearly defined in the context of NEMO Basic Support. I don't >> think you need a mention about the R-bit in the definition. > What you may need is something else than the term "mobile router": "NEMO-enable router": a MR which implement the NEMO Basic Support's MR functionality. As opposed to MIPv6-enable node. NEMOR. :-) TJ --Apple-Mail-7--1019252318 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 ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTIxODE5NTM0 OFowIwYJKoZIhvcNAQkEMRYEFHSLprJZ08yUGGLYsIz9Oi2tDXg8MIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgMKGX151NiMCiIZmG/zGoZwuBVuY7q/uQcY3a/VWO4WJ w/E8dBRIvWT7+7KsBawyDc8Pg35v+W8dhuYaqtyfCSZWHC2KiiEvCNfpKz/Ipv6MDOliOd2kG/9a QmGJrl7BWXOcjK5HewrpSBqZkl6zmKT/i+ZPc64xO5v5605nHILzAAAAAAAA --Apple-Mail-7--1019252318-- From exim@www1.ietf.org Thu Dec 18 14:57:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12224 for ; Thu, 18 Dec 2003 14:57: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 1AX4Gg-0004Vi-C4 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 14:57:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIJv6FJ017332 for nemo-archive@odin.ietf.org; Thu, 18 Dec 2003 14:57:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4Gg-0004VT-8I for nemo-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 14:57: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 OAA12178 for ; Thu, 18 Dec 2003 14:57:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX4Gd-0004jH-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 14:57:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX4Gb-0004iu-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 14:57:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX4Gb-0004ir-00 for nemo-web-archive@ietf.org; Thu, 18 Dec 2003 14: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 1AX4Gb-0004Uf-1a; Thu, 18 Dec 2003 14: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 1AX4Fc-0004Sy-7b for nemo@optimus.ietf.org; Thu, 18 Dec 2003 14:56: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 OAA12132 for ; Thu, 18 Dec 2003 14:55:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX4FZ-0004gj-00 for nemo@ietf.org; Thu, 18 Dec 2003 14:55:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX4FY-0004gc-00 for nemo@ietf.org; Thu, 18 Dec 2003 14:55:57 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AX4FX-0004dP-00 for nemo@ietf.org; Thu, 18 Dec 2003 14:55:56 -0500 Received: from [64.36.73.246] (wideload.kniveton.com [64.36.73.246]) by multihop.net (8.12.10/8.12.10) with ESMTP id hBIJsir4039967 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 18 Dec 2003 11:54:44 -0800 (PST) (envelope-from tj@kniveton.com) Mime-Version: 1.0 (Apple Message framework v609) In-Reply-To: <3FE1A53D.5010001@motorola.com> References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> <3FE18E84.9010701@motorola.com> <20031218204001.4edb949e.ernst@sfc.wide.ad.jp> <3FE1A53D.5010001@motorola.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7--1019252318; protocol="application/pkcs7-signature" Message-Id: From: "T.J. Kniveton" Subject: Re: [nemo] Issue 28 Date: Thu, 18 Dec 2003 11:53:47 -0800 To: nemo@ietf.org X-Mailer: Apple Mail (2.609) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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-7--1019252318 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Dec 18, 2003, at 5:01 AM, Alexandru Petrescu wrote: > Thierry Ernst wrote: >>>> I would also like to propose MNet for "mobile networks" >>> Against this. We can always use 'mobile network' at its full >>> length. Similarly, the spec never reads HA, but Home Agent. If on >>> the other hand 'MNet' is intended for ephemeral conversations, then >>> that's fine, I can key 'MNet', no problem, but no need to set in >>> stone in document (sorry if I repeat). >> OK, OK, I will never raised this again. But I would like people to >> stop saying "[...] a NEMO [...]", etc. NEMO = NEtwork MObility, not >> noun. > > Very good, me too. So where is the NEMO term itself defined? Just add > something to its definition: "not to be used as a noun". Why not? It's short, concise, and people know what it means - a NEtwork that's MObile. I don't have any problem using NEMO as a noun the same way we used to use MONET. If we introduce a new term it has the potential to be more cumbersome. TJ > >> "Mobile Router" is already defined in draft-ietf-seamoby, so what you >> propose is a re-definition. > > I don't think Seamoby did any protocol related to Mobile Routers. The NEMO WG is where the locus of work on mobile routers is happening. So it makes sense to (re)define the term, at least for our own purposes. > >> In draft-ietf-seamoby, it's a generic definition, i.e. with no >> meaning particular to NEMO Basic Support. May be in NEMO Extended >> Support the MR won't need to implement the R-bit, so your definition >> must be clearly defined in the context of NEMO Basic Support. I don't >> think you need a mention about the R-bit in the definition. > What you may need is something else than the term "mobile router": "NEMO-enable router": a MR which implement the NEMO Basic Support's MR functionality. As opposed to MIPv6-enable node. NEMOR. :-) TJ --Apple-Mail-7--1019252318 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 ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTIxODE5NTM0 OFowIwYJKoZIhvcNAQkEMRYEFHSLprJZ08yUGGLYsIz9Oi2tDXg8MIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgMKGX151NiMCiIZmG/zGoZwuBVuY7q/uQcY3a/VWO4WJ w/E8dBRIvWT7+7KsBawyDc8Pg35v+W8dhuYaqtyfCSZWHC2KiiEvCNfpKz/Ipv6MDOliOd2kG/9a QmGJrl7BWXOcjK5HewrpSBqZkl6zmKT/i+ZPc64xO5v5605nHILzAAAAAAAA --Apple-Mail-7--1019252318-- From nemo-admin@ietf.org Fri Dec 19 02:19:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27295 for ; Fri, 19 Dec 2003 02:19: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 1AXEuc-0003Mk-7f; Fri, 19 Dec 2003 02:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXEua-0003MQ-8R for nemo@optimus.ietf.org; Fri, 19 Dec 2003 02:19: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 CAA27230 for ; Fri, 19 Dec 2003 02:18:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXEuW-0000DG-00 for nemo@ietf.org; Fri, 19 Dec 2003 02:18:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXEuV-0000D9-00 for nemo@ietf.org; Fri, 19 Dec 2003 02:18:56 -0500 Received: from 94.180.32.202.ts.2iij.net ([202.32.180.94] helo=mail.64translator.com) by ietf-mx with esmtp (Exim 4.12) id 1AXEuV-0000D0-00 for nemo@ietf.org; Fri, 19 Dec 2003 02:18:55 -0500 Received: from bahamas.64translator.com ([10.21.32.3]) by mail.64translator.com (8.12.6p3/8.12.6) with ESMTP id hBJ7IP40010341 for ; Fri, 19 Dec 2003 16:18:25 +0900 (JST) (envelope-from h.miyata@jp.yokogawa.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by bahamas.64translator.com (8.12.9p2/8.12.9) with ESMTP id hBJ7IKAv011320 for ; Fri, 19 Dec 2003 16:18:20 +0900 (JST) (envelope-from h.miyata@jp.yokogawa.com) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: <85B1EC14-31F3-11D8-A79D-000A9599E546@jp.yokogawa.com> Content-Type: text/plain; charset=ISO-2022-JP; format=flowed To: nemo@ietf.org From: Hiroshi MIYATA Date: Fri, 19 Dec 2003 16:18:19 +0900 X-Mailer: Apple Mail (2.609) 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] NEMO interoperability test @ Connectathon Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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, This is Hiroshi Miyata@tahi project. I'm in charge of MIPv6 interoperability test coordination at Connectahon 2004. Now I'm also planing NEMO interoperability test beside$B!!(Bor with the MIPv6 test. So, I want to know how many person/implementation will be there. If you are interested in NEMO interoperability test, please let me know asap. P.S. Early Discount will be close tomorrow. Best Regards, .... MIYATA@TAHI From exim@www1.ietf.org Fri Dec 19 02:19:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27316 for ; Fri, 19 Dec 2003 02:19: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 1AXEun-0003OQ-6I for nemo-archive@odin.ietf.org; Fri, 19 Dec 2003 02:19:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJ7JD3H013036 for nemo-archive@odin.ietf.org; Fri, 19 Dec 2003 02:19:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXEuj-0003OB-M9 for nemo-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 02:19: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 CAA27251 for ; Fri, 19 Dec 2003 02:19:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXEug-0000Di-00 for nemo-web-archive@ietf.org; Fri, 19 Dec 2003 02:19:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXEuf-0000DZ-00 for nemo-web-archive@ietf.org; Fri, 19 Dec 2003 02:19:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXEue-0000DW-00 for nemo-web-archive@ietf.org; Fri, 19 Dec 2003 02:19:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXEuc-0003Mk-7f; Fri, 19 Dec 2003 02:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXEua-0003MQ-8R for nemo@optimus.ietf.org; Fri, 19 Dec 2003 02:19: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 CAA27230 for ; Fri, 19 Dec 2003 02:18:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXEuW-0000DG-00 for nemo@ietf.org; Fri, 19 Dec 2003 02:18:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXEuV-0000D9-00 for nemo@ietf.org; Fri, 19 Dec 2003 02:18:56 -0500 Received: from 94.180.32.202.ts.2iij.net ([202.32.180.94] helo=mail.64translator.com) by ietf-mx with esmtp (Exim 4.12) id 1AXEuV-0000D0-00 for nemo@ietf.org; Fri, 19 Dec 2003 02:18:55 -0500 Received: from bahamas.64translator.com ([10.21.32.3]) by mail.64translator.com (8.12.6p3/8.12.6) with ESMTP id hBJ7IP40010341 for ; Fri, 19 Dec 2003 16:18:25 +0900 (JST) (envelope-from h.miyata@jp.yokogawa.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by bahamas.64translator.com (8.12.9p2/8.12.9) with ESMTP id hBJ7IKAv011320 for ; Fri, 19 Dec 2003 16:18:20 +0900 (JST) (envelope-from h.miyata@jp.yokogawa.com) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: <85B1EC14-31F3-11D8-A79D-000A9599E546@jp.yokogawa.com> Content-Type: text/plain; charset=ISO-2022-JP; format=flowed To: nemo@ietf.org From: Hiroshi MIYATA Date: Fri, 19 Dec 2003 16:18:19 +0900 X-Mailer: Apple Mail (2.609) Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO interoperability test @ Connectathon Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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, This is Hiroshi Miyata@tahi project. I'm in charge of MIPv6 interoperability test coordination at Connectahon 2004. Now I'm also planing NEMO interoperability test beside$B!!(Bor with the MIPv6 test. So, I want to know how many person/implementation will be there. If you are interested in NEMO interoperability test, please let me know asap. P.S. Early Discount will be close tomorrow. Best Regards, .... MIYATA@TAHI From nemo-admin@ietf.org Fri Dec 19 02:29:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27618 for ; Fri, 19 Dec 2003 02:29: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 1AXF4H-0003mM-Ur; Fri, 19 Dec 2003 02:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXF42-0003lt-K1 for nemo@optimus.ietf.org; Fri, 19 Dec 2003 02:28: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 CAA27594 for ; Fri, 19 Dec 2003 02:28:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXF3t-0000OC-00 for nemo@ietf.org; Fri, 19 Dec 2003 02:28:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXF3P-0000Nt-00 for nemo@ietf.org; Fri, 19 Dec 2003 02:28:07 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AXF3O-0000Mw-00 for nemo@ietf.org; Fri, 19 Dec 2003 02:28:07 -0500 Received: from wanwan.sfc.wide.ad.jp (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 61BC05D0AC; Fri, 19 Dec 2003 16:27:22 +0900 (JST) Date: Fri, 19 Dec 2003 16:27:22 +0900 Message-ID: From: Koshiro MITSUYA To: Hiroshi MIYATA Cc: nemo@ietf.org Subject: Re: [nemo] NEMO interoperability test @ Connectathon In-Reply-To: <85B1EC14-31F3-11D8-A79D-000A9599E546@jp.yokogawa.com> References: <85B1EC14-31F3-11D8-A79D-000A9599E546@jp.yokogawa.com> User-Agent: Wanderlust/2.8.1 (Something) EMIKO/1.14.1 (Choanoflagellata) LIMIT/1.14.7 (Fujiidera) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.8) MULE/4.0 (HANANOEN) Organization: Keio University MIME-Version: 1.0 (generated by EMIKO 1.14.1 - "Choanoflagellata") Content-Type: text/plain; charset=ISO-2022-JP 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: , Miyata-san, I, Nautilus6 Project, have the implementation. I have interesting in the testing. regards, Koshiro http://www.nautilus6.org/ At Fri, 19 Dec 2003 16:18:19 +0900, Hiroshi MIYATA wrote: > > Hi all, > > This is Hiroshi Miyata@tahi project. > I'm in charge of MIPv6 interoperability test coordination > at Connectahon 2004. > > Now I'm also planing NEMO interoperability test beside$B!!(Bor with > the MIPv6 test. > > So, I want to know how many person/implementation will be there. > > If you are interested in NEMO interoperability test, please > let me know asap. > > P.S. > Early Discount will be close tomorrow. > > Best Regards, > > .... MIYATA@TAHI > From exim@www1.ietf.org Fri Dec 19 02:30:03 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27714 for ; Fri, 19 Dec 2003 02:30:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXF4o-0003rl-UG for nemo-archive@odin.ietf.org; Fri, 19 Dec 2003 02:29:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJ7TYfI014857 for nemo-archive@odin.ietf.org; Fri, 19 Dec 2003 02:29:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXF4k-0003rT-Ei for nemo-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 02:29: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 CAA27610 for ; Fri, 19 Dec 2003 02:29:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXF4g-0000Pq-00 for nemo-web-archive@ietf.org; Fri, 19 Dec 2003 02:29:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXF4c-0000P2-00 for nemo-web-archive@ietf.org; Fri, 19 Dec 2003 02:29:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXF4c-0000OZ-00 for nemo-web-archive@ietf.org; Fri, 19 Dec 2003 02:29:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXF4H-0003mM-Ur; Fri, 19 Dec 2003 02:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXF42-0003lt-K1 for nemo@optimus.ietf.org; Fri, 19 Dec 2003 02:28: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 CAA27594 for ; Fri, 19 Dec 2003 02:28:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXF3t-0000OC-00 for nemo@ietf.org; Fri, 19 Dec 2003 02:28:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXF3P-0000Nt-00 for nemo@ietf.org; Fri, 19 Dec 2003 02:28:07 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AXF3O-0000Mw-00 for nemo@ietf.org; Fri, 19 Dec 2003 02:28:07 -0500 Received: from wanwan.sfc.wide.ad.jp (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 61BC05D0AC; Fri, 19 Dec 2003 16:27:22 +0900 (JST) Date: Fri, 19 Dec 2003 16:27:22 +0900 Message-ID: From: Koshiro MITSUYA To: Hiroshi MIYATA Cc: nemo@ietf.org Subject: Re: [nemo] NEMO interoperability test @ Connectathon In-Reply-To: <85B1EC14-31F3-11D8-A79D-000A9599E546@jp.yokogawa.com> References: <85B1EC14-31F3-11D8-A79D-000A9599E546@jp.yokogawa.com> User-Agent: Wanderlust/2.8.1 (Something) EMIKO/1.14.1 (Choanoflagellata) LIMIT/1.14.7 (Fujiidera) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.8) MULE/4.0 (HANANOEN) Organization: Keio University MIME-Version: 1.0 (generated by EMIKO 1.14.1 - "Choanoflagellata") Content-Type: text/plain; charset=ISO-2022-JP Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 Miyata-san, I, Nautilus6 Project, have the implementation. I have interesting in the testing. regards, Koshiro http://www.nautilus6.org/ At Fri, 19 Dec 2003 16:18:19 +0900, Hiroshi MIYATA wrote: > > Hi all, > > This is Hiroshi Miyata@tahi project. > I'm in charge of MIPv6 interoperability test coordination > at Connectahon 2004. > > Now I'm also planing NEMO interoperability test beside$B!!(Bor with > the MIPv6 test. > > So, I want to know how many person/implementation will be there. > > If you are interested in NEMO interoperability test, please > let me know asap. > > P.S. > Early Discount will be close tomorrow. > > Best Regards, > > .... MIYATA@TAHI > From nemo-admin@ietf.org Fri Dec 19 03:54:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29512 for ; Fri, 19 Dec 2003 03:54: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 1AXGOX-00078R-Dy; Fri, 19 Dec 2003 03: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 1AXGOJ-00077d-31 for nemo@optimus.ietf.org; Fri, 19 Dec 2003 03:53: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 DAA29495 for ; Fri, 19 Dec 2003 03:53:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXGOG-0002EE-00 for nemo@ietf.org; Fri, 19 Dec 2003 03:53:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXGOF-0002E7-00 for nemo@ietf.org; Fri, 19 Dec 2003 03:53:44 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AXGOF-0002E3-00 for nemo@ietf.org; Fri, 19 Dec 2003 03:53:43 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hBJ8rAC02104; Fri, 19 Dec 2003 00:53:10 -0800 X-mProtect: <200312190853> Nokia Silicon Valley Messaging Protection Received: from esnira-pool1012148.nokia.com (10.162.12.148, claiming to be "nokia.com") by darkstar.iprg.nokia.com smtpdLLEiU3; Fri, 19 Dec 2003 00:53:08 PST Message-ID: <3FE2BC5E.6070106@nokia.com> Date: Fri, 19 Dec 2003 00:52:46 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Hiroshi MIYATA CC: nemo@ietf.org Subject: Re: [nemo] NEMO interoperability test @ Connectathon References: <85B1EC14-31F3-11D8-A79D-000A9599E546@jp.yokogawa.com> In-Reply-To: <85B1EC14-31F3-11D8-A79D-000A9599E546@jp.yokogawa.com> Content-Type: text/plain; charset=ISO-2022-JP 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 Nokia Research will be there with a Home Agent implementation with Mobile Router support. Vijay ext Hiroshi MIYATA wrote: > Hi all, > > This is Hiroshi Miyata@tahi project. > I'm in charge of MIPv6 interoperability test coordination > at Connectahon 2004. > > Now I'm also planing NEMO interoperability test beside$B!!(Bor with > the MIPv6 test. > > So, I want to know how many person/implementation will be there. > > If you are interested in NEMO interoperability test, please > let me know asap. > > P.S. > Early Discount will be close tomorrow. > > Best Regards, > > .... MIYATA@TAHI > > From exim@www1.ietf.org Fri Dec 19 03:54:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29527 for ; Fri, 19 Dec 2003 03:54: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 1AXGOc-00079K-CN for nemo-archive@odin.ietf.org; Fri, 19 Dec 2003 03:54:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJ8s6w5027483 for nemo-archive@odin.ietf.org; Fri, 19 Dec 2003 03:54:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXGOb-00079C-Rg for nemo-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 03:54: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 DAA29499 for ; Fri, 19 Dec 2003 03:54:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXGOZ-0002ES-00 for nemo-web-archive@ietf.org; Fri, 19 Dec 2003 03:54:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXGOY-0002EL-00 for nemo-web-archive@ietf.org; Fri, 19 Dec 2003 03:54:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXGOY-0002EI-00 for nemo-web-archive@ietf.org; Fri, 19 Dec 2003 03:54:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXGOX-00078R-Dy; Fri, 19 Dec 2003 03: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 1AXGOJ-00077d-31 for nemo@optimus.ietf.org; Fri, 19 Dec 2003 03:53: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 DAA29495 for ; Fri, 19 Dec 2003 03:53:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXGOG-0002EE-00 for nemo@ietf.org; Fri, 19 Dec 2003 03:53:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXGOF-0002E7-00 for nemo@ietf.org; Fri, 19 Dec 2003 03:53:44 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AXGOF-0002E3-00 for nemo@ietf.org; Fri, 19 Dec 2003 03:53:43 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hBJ8rAC02104; Fri, 19 Dec 2003 00:53:10 -0800 X-mProtect: <200312190853> Nokia Silicon Valley Messaging Protection Received: from esnira-pool1012148.nokia.com (10.162.12.148, claiming to be "nokia.com") by darkstar.iprg.nokia.com smtpdLLEiU3; Fri, 19 Dec 2003 00:53:08 PST Message-ID: <3FE2BC5E.6070106@nokia.com> Date: Fri, 19 Dec 2003 00:52:46 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Hiroshi MIYATA CC: nemo@ietf.org Subject: Re: [nemo] NEMO interoperability test @ Connectathon References: <85B1EC14-31F3-11D8-A79D-000A9599E546@jp.yokogawa.com> In-Reply-To: <85B1EC14-31F3-11D8-A79D-000A9599E546@jp.yokogawa.com> Content-Type: text/plain; charset=ISO-2022-JP 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 Nokia Research will be there with a Home Agent implementation with Mobile Router support. Vijay ext Hiroshi MIYATA wrote: > Hi all, > > This is Hiroshi Miyata@tahi project. > I'm in charge of MIPv6 interoperability test coordination > at Connectahon 2004. > > Now I'm also planing NEMO interoperability test beside$B!!(Bor with > the MIPv6 test. > > So, I want to know how many person/implementation will be there. > > If you are interested in NEMO interoperability test, please > let me know asap. > > P.S. > Early Discount will be close tomorrow. > > Best Regards, > > .... MIYATA@TAHI > > From nemo-admin@ietf.org Fri Dec 19 14:08:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20251 for ; Fri, 19 Dec 2003 14:08: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 1AXPyj-00071i-PP; Fri, 19 Dec 2003 14:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXPyV-000707-Jp for nemo@optimus.ietf.org; Fri, 19 Dec 2003 14:07: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 OAA20204 for ; Fri, 19 Dec 2003 14:07:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXPyT-0004ck-00 for nemo@ietf.org; Fri, 19 Dec 2003 14:07:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXPyS-0004cb-00 for nemo@ietf.org; Fri, 19 Dec 2003 14:07:44 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AXPyR-0004Zz-00 for nemo@ietf.org; Fri, 19 Dec 2003 14:07:43 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hBJJ7AK02356; Fri, 19 Dec 2003 11:07:10 -0800 X-mProtect: <200312191907> Nokia Silicon Valley Messaging Protection Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "kniveton.com") by darkstar.iprg.nokia.com smtpdpfHvny; Fri, 19 Dec 2003 11:07:09 PST Message-ID: <3FE34C53.F940CEFE@kniveton.com> Date: Fri, 19 Dec 2003 11:06:59 -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@ietf.org, Margaret Wasserman , Thomas Narten 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] New 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: , Content-Transfer-Encoding: 7bit We are pleased to announce that the newest revision of the NEMO Basic Support draft has been released. This version addresses all of the issues raised during working group last call. In addition, we received two thorough reviews from Jari Arkko and James Kempf, which helped us to refine the draft even further. This version is a candidate for IETF last call. Please make any comments on the mailing list. http://www.mobilenetworks.org/nemo/drafts/draft-ietf-nemo-basic-support-02.txt Also, the minutes from IETF58 are on the web, as well as a zip file of all of the slide files called "allslides.zip". Please see the web site. From exim@www1.ietf.org Fri Dec 19 14:08:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20266 for ; Fri, 19 Dec 2003 14:08: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 1AXPyq-00074Z-A0 for nemo-archive@odin.ietf.org; Fri, 19 Dec 2003 14:08:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJJ88lE027183 for nemo-archive@odin.ietf.org; Fri, 19 Dec 2003 14:08:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXPyq-00074M-4a for nemo-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 14:08:08 -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 OAA20212 for ; Fri, 19 Dec 2003 14:08:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXPyn-0004dL-00 for nemo-web-archive@ietf.org; Fri, 19 Dec 2003 14:08:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXPym-0004dB-00 for nemo-web-archive@ietf.org; Fri, 19 Dec 2003 14:08:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXPym-0004d8-00 for nemo-web-archive@ietf.org; Fri, 19 Dec 2003 14:08:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXPyj-00071i-PP; Fri, 19 Dec 2003 14:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXPyV-000707-Jp for nemo@optimus.ietf.org; Fri, 19 Dec 2003 14:07: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 OAA20204 for ; Fri, 19 Dec 2003 14:07:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXPyT-0004ck-00 for nemo@ietf.org; Fri, 19 Dec 2003 14:07:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXPyS-0004cb-00 for nemo@ietf.org; Fri, 19 Dec 2003 14:07:44 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AXPyR-0004Zz-00 for nemo@ietf.org; Fri, 19 Dec 2003 14:07:43 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hBJJ7AK02356; Fri, 19 Dec 2003 11:07:10 -0800 X-mProtect: <200312191907> Nokia Silicon Valley Messaging Protection Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "kniveton.com") by darkstar.iprg.nokia.com smtpdpfHvny; Fri, 19 Dec 2003 11:07:09 PST Message-ID: <3FE34C53.F940CEFE@kniveton.com> Date: Fri, 19 Dec 2003 11:06:59 -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@ietf.org, Margaret Wasserman , Thomas Narten Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] New 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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We are pleased to announce that the newest revision of the NEMO Basic Support draft has been released. This version addresses all of the issues raised during working group last call. In addition, we received two thorough reviews from Jari Arkko and James Kempf, which helped us to refine the draft even further. This version is a candidate for IETF last call. Please make any comments on the mailing list. http://www.mobilenetworks.org/nemo/drafts/draft-ietf-nemo-basic-support-02.txt Also, the minutes from IETF58 are on the web, as well as a zip file of all of the slide files called "allslides.zip". Please see the web site. From nemo-admin@ietf.org Sun Dec 21 21:12:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15166 for ; Sun, 21 Dec 2003 21:12: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 1AYFY9-0003Lz-0b; Sun, 21 Dec 2003 21:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYFXV-0003Jp-R9 for nemo@optimus.ietf.org; Sun, 21 Dec 2003 21:11:21 -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 VAA15117 for ; Sun, 21 Dec 2003 21:11:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYFXR-000135-00 for nemo@ietf.org; Sun, 21 Dec 2003 21:11:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYFXL-00012y-00 for nemo@ietf.org; Sun, 21 Dec 2003 21:11:11 -0500 Received: from 94.180.32.202.ts.2iij.net ([202.32.180.94] helo=mail.64translator.com) by ietf-mx with esmtp (Exim 4.12) id 1AYFXK-000127-00 for nemo@ietf.org; Sun, 21 Dec 2003 21:11:10 -0500 Received: from bahamas.64translator.com ([10.21.32.3]) by mail.64translator.com (8.12.6p3/8.12.6) with ESMTP id hBM2AY40020442 for ; Mon, 22 Dec 2003 11:10:34 +0900 (JST) (envelope-from h.miyata@jp.yokogawa.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by bahamas.64translator.com (8.12.9p2/8.12.9) with ESMTP id hBM2ATAv029445 for ; Mon, 22 Dec 2003 11:10:29 +0900 (JST) (envelope-from h.miyata@jp.yokogawa.com) Mime-Version: 1.0 (Apple Message framework v609) In-Reply-To: <3FE2BC5E.6070106@nokia.com> References: <85B1EC14-31F3-11D8-A79D-000A9599E546@jp.yokogawa.com> <3FE2BC5E.6070106@nokia.com> Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <03D32424-3424-11D8-90F3-000A9599E546@jp.yokogawa.com> Content-Transfer-Encoding: 7bit From: Hiroshi MIYATA Subject: Re: [nemo] NEMO interoperability test @ Connectathon Date: Mon, 22 Dec 2003 11:10:29 +0900 To: nemo@ietf.org X-Mailer: Apple Mail (2.609) 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 Then, at least two implementations will be there. Nautilus6: ? (Please fill > Koshiro) Nokia Research: HA Thanks for your info. Let's enjoy the test! Regards, ...miyata On 2003/12/19, at 17:52, Vijay Devarapalli wrote: > Nokia Research will be there with a Home Agent implementation > with Mobile Router support. > > Vijay > > ext Hiroshi MIYATA wrote: >> Hi all, >> >> This is Hiroshi Miyata@tahi project. >> I'm in charge of MIPv6 interoperability test coordination >> at Connectahon 2004. >> >> Now I'm also planing NEMO interoperability test beside$B!!(Bor with >> the MIPv6 test. >> >> So, I want to know how many person/implementation will be there. >> >> If you are interested in NEMO interoperability test, please >> let me know asap. >> >> P.S. >> Early Discount will be close tomorrow. >> >> Best Regards, >> >> .... MIYATA@TAHI >> >> > > From exim@www1.ietf.org Sun Dec 21 21:12:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15192 for ; Sun, 21 Dec 2003 21:12: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 1AYFYE-0003ND-5D for nemo-archive@odin.ietf.org; Sun, 21 Dec 2003 21:12:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBM2C6ps012963 for nemo-archive@odin.ietf.org; Sun, 21 Dec 2003 21:12:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYFYE-0003N0-1k for nemo-web-archive@optimus.ietf.org; Sun, 21 Dec 2003 21:12: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 VAA15143 for ; Sun, 21 Dec 2003 21:12:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYFYB-00014M-00 for nemo-web-archive@ietf.org; Sun, 21 Dec 2003 21:12:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYFYA-00014E-00 for nemo-web-archive@ietf.org; Sun, 21 Dec 2003 21:12:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYFYA-000149-00 for nemo-web-archive@ietf.org; Sun, 21 Dec 2003 21: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 1AYFY9-0003Lz-0b; Sun, 21 Dec 2003 21:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYFXV-0003Jp-R9 for nemo@optimus.ietf.org; Sun, 21 Dec 2003 21:11:21 -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 VAA15117 for ; Sun, 21 Dec 2003 21:11:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYFXR-000135-00 for nemo@ietf.org; Sun, 21 Dec 2003 21:11:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYFXL-00012y-00 for nemo@ietf.org; Sun, 21 Dec 2003 21:11:11 -0500 Received: from 94.180.32.202.ts.2iij.net ([202.32.180.94] helo=mail.64translator.com) by ietf-mx with esmtp (Exim 4.12) id 1AYFXK-000127-00 for nemo@ietf.org; Sun, 21 Dec 2003 21:11:10 -0500 Received: from bahamas.64translator.com ([10.21.32.3]) by mail.64translator.com (8.12.6p3/8.12.6) with ESMTP id hBM2AY40020442 for ; Mon, 22 Dec 2003 11:10:34 +0900 (JST) (envelope-from h.miyata@jp.yokogawa.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by bahamas.64translator.com (8.12.9p2/8.12.9) with ESMTP id hBM2ATAv029445 for ; Mon, 22 Dec 2003 11:10:29 +0900 (JST) (envelope-from h.miyata@jp.yokogawa.com) Mime-Version: 1.0 (Apple Message framework v609) In-Reply-To: <3FE2BC5E.6070106@nokia.com> References: <85B1EC14-31F3-11D8-A79D-000A9599E546@jp.yokogawa.com> <3FE2BC5E.6070106@nokia.com> Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <03D32424-3424-11D8-90F3-000A9599E546@jp.yokogawa.com> Content-Transfer-Encoding: 7bit From: Hiroshi MIYATA Subject: Re: [nemo] NEMO interoperability test @ Connectathon Date: Mon, 22 Dec 2003 11:10:29 +0900 To: nemo@ietf.org X-Mailer: Apple Mail (2.609) 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 Then, at least two implementations will be there. Nautilus6: ? (Please fill > Koshiro) Nokia Research: HA Thanks for your info. Let's enjoy the test! Regards, ...miyata On 2003/12/19, at 17:52, Vijay Devarapalli wrote: > Nokia Research will be there with a Home Agent implementation > with Mobile Router support. > > Vijay > > ext Hiroshi MIYATA wrote: >> Hi all, >> >> This is Hiroshi Miyata@tahi project. >> I'm in charge of MIPv6 interoperability test coordination >> at Connectahon 2004. >> >> Now I'm also planing NEMO interoperability test beside$B!!(Bor with >> the MIPv6 test. >> >> So, I want to know how many person/implementation will be there. >> >> If you are interested in NEMO interoperability test, please >> let me know asap. >> >> P.S. >> Early Discount will be close tomorrow. >> >> Best Regards, >> >> .... MIYATA@TAHI >> >> > > From nemo-admin@ietf.org Sun Dec 21 22:56:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17601 for ; Sun, 21 Dec 2003 22:56: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 1AYHAo-0005pC-IG; Sun, 21 Dec 2003 22:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYHAJ-0005n8-EZ for nemo@optimus.ietf.org; Sun, 21 Dec 2003 22:55: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 WAA17474 for ; Sun, 21 Dec 2003 22:55:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYHAF-0003d4-00 for nemo@ietf.org; Sun, 21 Dec 2003 22:55:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYHAD-0003ch-00 for nemo@ietf.org; Sun, 21 Dec 2003 22:55:27 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AYHAD-0003bf-00 for nemo@ietf.org; Sun, 21 Dec 2003 22:55:25 -0500 Received: from wanwan.sfc.wide.ad.jp (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id E01475D1B9; Mon, 22 Dec 2003 12:54:53 +0900 (JST) Date: Mon, 22 Dec 2003 12:54:53 +0900 Message-ID: From: Koshiro MITSUYA To: Hiroshi MIYATA Cc: nemo@ietf.org Subject: Re: [nemo] NEMO interoperability test @ Connectathon In-Reply-To: <03D32424-3424-11D8-90F3-000A9599E546@jp.yokogawa.com> References: <85B1EC14-31F3-11D8-A79D-000A9599E546@jp.yokogawa.com> <3FE2BC5E.6070106@nokia.com> <03D32424-3424-11D8-90F3-000A9599E546@jp.yokogawa.com> User-Agent: Wanderlust/2.8.1 (Something) EMIKO/1.14.1 (Choanoflagellata) LIMIT/1.14.7 (Fujiidera) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.8) MULE/4.0 (HANANOEN) Organization: Keio University MIME-Version: 1.0 (generated by EMIKO 1.14.1 - "Choanoflagellata") Content-Type: text/plain; charset=ISO-2022-JP 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, We will bring MR and HA. Nautilus6: MR, HA Nokia Research: HA regards, Koshiro At Mon, 22 Dec 2003 11:10:29 +0900, Hiroshi MIYATA wrote: > > Then, at least two implementations will be there. > > Nautilus6: ? (Please fill > Koshiro) > Nokia Research: HA > > Thanks for your info. > Let's enjoy the test! > > Regards, > > ...miyata > > > On 2003/12/19, at 17:52, Vijay Devarapalli wrote: > > > Nokia Research will be there with a Home Agent implementation > > with Mobile Router support. > > > > Vijay > > > > ext Hiroshi MIYATA wrote: > >> Hi all, > >> > >> This is Hiroshi Miyata@tahi project. > >> I'm in charge of MIPv6 interoperability test coordination > >> at Connectahon 2004. > >> > >> Now I'm also planing NEMO interoperability test beside$B!!(Bor with > >> the MIPv6 test. > >> > >> So, I want to know how many person/implementation will be there. > >> > >> If you are interested in NEMO interoperability test, please > >> let me know asap. > >> > >> P.S. > >> Early Discount will be close tomorrow. > >> > >> Best Regards, > >> > >> .... MIYATA@TAHI > >> > >> > > > > > From exim@www1.ietf.org Sun Dec 21 22:56:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17629 for ; Sun, 21 Dec 2003 22:56: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 1AYHAt-0005qj-EL for nemo-archive@odin.ietf.org; Sun, 21 Dec 2003 22:56:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBM3u7kT022479 for nemo-archive@odin.ietf.org; Sun, 21 Dec 2003 22:56:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYHAt-0005qU-9o for nemo-web-archive@optimus.ietf.org; Sun, 21 Dec 2003 22:56:07 -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 WAA17550 for ; Sun, 21 Dec 2003 22:56:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYHAp-0003jj-00 for nemo-web-archive@ietf.org; Sun, 21 Dec 2003 22:56:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYHAn-0003jG-00 for nemo-web-archive@ietf.org; Sun, 21 Dec 2003 22:56:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYHAn-0003jD-00 for nemo-web-archive@ietf.org; Sun, 21 Dec 2003 22:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYHAo-0005pC-IG; Sun, 21 Dec 2003 22:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYHAJ-0005n8-EZ for nemo@optimus.ietf.org; Sun, 21 Dec 2003 22:55: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 WAA17474 for ; Sun, 21 Dec 2003 22:55:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYHAF-0003d4-00 for nemo@ietf.org; Sun, 21 Dec 2003 22:55:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYHAD-0003ch-00 for nemo@ietf.org; Sun, 21 Dec 2003 22:55:27 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AYHAD-0003bf-00 for nemo@ietf.org; Sun, 21 Dec 2003 22:55:25 -0500 Received: from wanwan.sfc.wide.ad.jp (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id E01475D1B9; Mon, 22 Dec 2003 12:54:53 +0900 (JST) Date: Mon, 22 Dec 2003 12:54:53 +0900 Message-ID: From: Koshiro MITSUYA To: Hiroshi MIYATA Cc: nemo@ietf.org Subject: Re: [nemo] NEMO interoperability test @ Connectathon In-Reply-To: <03D32424-3424-11D8-90F3-000A9599E546@jp.yokogawa.com> References: <85B1EC14-31F3-11D8-A79D-000A9599E546@jp.yokogawa.com> <3FE2BC5E.6070106@nokia.com> <03D32424-3424-11D8-90F3-000A9599E546@jp.yokogawa.com> User-Agent: Wanderlust/2.8.1 (Something) EMIKO/1.14.1 (Choanoflagellata) LIMIT/1.14.7 (Fujiidera) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.8) MULE/4.0 (HANANOEN) Organization: Keio University MIME-Version: 1.0 (generated by EMIKO 1.14.1 - "Choanoflagellata") Content-Type: text/plain; charset=ISO-2022-JP Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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, We will bring MR and HA. Nautilus6: MR, HA Nokia Research: HA regards, Koshiro At Mon, 22 Dec 2003 11:10:29 +0900, Hiroshi MIYATA wrote: > > Then, at least two implementations will be there. > > Nautilus6: ? (Please fill > Koshiro) > Nokia Research: HA > > Thanks for your info. > Let's enjoy the test! > > Regards, > > ...miyata > > > On 2003/12/19, at 17:52, Vijay Devarapalli wrote: > > > Nokia Research will be there with a Home Agent implementation > > with Mobile Router support. > > > > Vijay > > > > ext Hiroshi MIYATA wrote: > >> Hi all, > >> > >> This is Hiroshi Miyata@tahi project. > >> I'm in charge of MIPv6 interoperability test coordination > >> at Connectahon 2004. > >> > >> Now I'm also planing NEMO interoperability test beside$B!!(Bor with > >> the MIPv6 test. > >> > >> So, I want to know how many person/implementation will be there. > >> > >> If you are interested in NEMO interoperability test, please > >> let me know asap. > >> > >> P.S. > >> Early Discount will be close tomorrow. > >> > >> Best Regards, > >> > >> .... MIYATA@TAHI > >> > >> > > > > > From nemo-admin@ietf.org Tue Dec 23 14:23:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02419 for ; Tue, 23 Dec 2003 14: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 1AYs7R-0004FZ-7K; Tue, 23 Dec 2003 14:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYs6w-0004DJ-AK for nemo@optimus.ietf.org; Tue, 23 Dec 2003 14:22: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 OAA02164 for ; Tue, 23 Dec 2003 14:22:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYs6t-0004PQ-00 for nemo@ietf.org; Tue, 23 Dec 2003 14:22:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYs49-0003g2-00 for nemo@ietf.org; Tue, 23 Dec 2003 14:19:42 -0500 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1AYs24-00039m-00 for nemo@ietf.org; Tue, 23 Dec 2003 14:17:29 -0500 Received: from [192.168.0.11] (pdd81b9.tkyoac00.ap.so-net.ne.jp [218.221.129.185]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id hBNJFstx008321; Wed, 24 Dec 2003 04:15:54 +0900 Date: Wed, 24 Dec 2003 04:22:34 +0900 From: Ryuji Wakikawa To: Koshiro MITSUYA Subject: Re: [nemo] NEMO interoperability test @ Connectathon Cc: Hiroshi MIYATA , nemo@ietf.org In-Reply-To: References: <03D32424-3424-11D8-90F3-000A9599E546@jp.yokogawa.com> Message-Id: <20031224041921.5E26.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" 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 KEIO University (SFCMIP) can test MR and HA. The implementation is based on draft-ietf-nemo-basic-01.txt. ryuji > Hi, > > We will bring MR and HA. > > Nautilus6: MR, HA > Nokia Research: HA > > regards, > Koshiro > > > At Mon, 22 Dec 2003 11:10:29 +0900, > Hiroshi MIYATA wrote: > > > > Then, at least two implementations will be there. > > > > Nautilus6: ? (Please fill > Koshiro) > > Nokia Research: HA > > > > Thanks for your info. > > Let's enjoy the test! > > > > Regards, > > > > ...miyata > > > > > > On 2003/12/19, at 17:52, Vijay Devarapalli wrote: > > > > > Nokia Research will be there with a Home Agent implementation > > > with Mobile Router support. > > > > > > Vijay > > > > > > ext Hiroshi MIYATA wrote: > > >> Hi all, > > >> > > >> This is Hiroshi Miyata@tahi project. > > >> I'm in charge of MIPv6 interoperability test coordination > > >> at Connectahon 2004. > > >> > > >> Now I'm also planing NEMO interoperability test beside$B!!(Bor with > > >> the MIPv6 test. > > >> > > >> So, I want to know how many person/implementation will be there. > > >> > > >> If you are interested in NEMO interoperability test, please > > >> let me know asap. > > >> > > >> P.S. > > >> Early Discount will be close tomorrow. > > >> > > >> Best Regards, > > >> > > >> .... MIYATA@TAHI > > >> > > >> > > > > > > > > From exim@www1.ietf.org Tue Dec 23 14:29:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02980 for ; Tue, 23 Dec 2003 14:29:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYsDT-0004b6-TB for nemo-archive@odin.ietf.org; Tue, 23 Dec 2003 14:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNJTFKh017671 for nemo-archive@odin.ietf.org; Tue, 23 Dec 2003 14:29:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYsDT-0004aw-Om for nemo-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 14: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 OAA02919 for ; Tue, 23 Dec 2003 14:29:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYsDR-0005XD-00 for nemo-web-archive@ietf.org; Tue, 23 Dec 2003 14:29:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYsAo-00051w-00 for nemo-web-archive@ietf.org; Tue, 23 Dec 2003 14:26:30 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AYs7X-0004aA-00 for nemo-web-archive@ietf.org; Tue, 23 Dec 2003 14:23:07 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AYs7X-0000og-Av for nemo-web-archive@ietf.org; Tue, 23 Dec 2003 14:23:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYs7R-0004FZ-7K; Tue, 23 Dec 2003 14:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYs6w-0004DJ-AK for nemo@optimus.ietf.org; Tue, 23 Dec 2003 14:22: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 OAA02164 for ; Tue, 23 Dec 2003 14:22:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYs6t-0004PQ-00 for nemo@ietf.org; Tue, 23 Dec 2003 14:22:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYs49-0003g2-00 for nemo@ietf.org; Tue, 23 Dec 2003 14:19:42 -0500 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1AYs24-00039m-00 for nemo@ietf.org; Tue, 23 Dec 2003 14:17:29 -0500 Received: from [192.168.0.11] (pdd81b9.tkyoac00.ap.so-net.ne.jp [218.221.129.185]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id hBNJFstx008321; Wed, 24 Dec 2003 04:15:54 +0900 Date: Wed, 24 Dec 2003 04:22:34 +0900 From: Ryuji Wakikawa To: Koshiro MITSUYA Subject: Re: [nemo] NEMO interoperability test @ Connectathon Cc: Hiroshi MIYATA , nemo@ietf.org In-Reply-To: References: <03D32424-3424-11D8-90F3-000A9599E546@jp.yokogawa.com> Message-Id: <20031224041921.5E26.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" 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 KEIO University (SFCMIP) can test MR and HA. The implementation is based on draft-ietf-nemo-basic-01.txt. ryuji > Hi, > > We will bring MR and HA. > > Nautilus6: MR, HA > Nokia Research: HA > > regards, > Koshiro > > > At Mon, 22 Dec 2003 11:10:29 +0900, > Hiroshi MIYATA wrote: > > > > Then, at least two implementations will be there. > > > > Nautilus6: ? (Please fill > Koshiro) > > Nokia Research: HA > > > > Thanks for your info. > > Let's enjoy the test! > > > > Regards, > > > > ...miyata > > > > > > On 2003/12/19, at 17:52, Vijay Devarapalli wrote: > > > > > Nokia Research will be there with a Home Agent implementation > > > with Mobile Router support. > > > > > > Vijay > > > > > > ext Hiroshi MIYATA wrote: > > >> Hi all, > > >> > > >> This is Hiroshi Miyata@tahi project. > > >> I'm in charge of MIPv6 interoperability test coordination > > >> at Connectahon 2004. > > >> > > >> Now I'm also planing NEMO interoperability test beside$B!!(Bor with > > >> the MIPv6 test. > > >> > > >> So, I want to know how many person/implementation will be there. > > >> > > >> If you are interested in NEMO interoperability test, please > > >> let me know asap. > > >> > > >> P.S. > > >> Early Discount will be close tomorrow. > > >> > > >> Best Regards, > > >> > > >> .... MIYATA@TAHI > > >> > > >> > > > > > > > > From nemo-admin@ietf.org Tue Dec 23 15:36:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08212 for ; Tue, 23 Dec 2003 15:36: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 1AYtG5-0007gj-Cs; Tue, 23 Dec 2003 15:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtFA-0007WM-ES for nemo@optimus.ietf.org; Tue, 23 Dec 2003 15:35:04 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07954; Tue, 23 Dec 2003 15:35:01 -0500 (EST) Message-Id: <200312232035.PAA07954@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: Tue, 23 Dec 2003 15:35:01 -0500 Subject: [nemo] I-D ACTION:draft-ietf-nemo-basic-support-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 : Nemo Basic Support Protocol Author(s) : V. Devarapalli Filename : draft-ietf-nemo-basic-support-02.txt Pages : 37 Date : 2003-12-23 This document describes the Nemo Basic Support protocol to support network mobility as the mobile network attaches to different points in the Internet. The protocol is based on extensions to Mobile IPv6 and allows for session continuity for every node in the mobile network as the network moves. It also allows every node in the mobile network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed in such a way that network mobility is transparent to the nodes inside the mobile network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-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-basic-support-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-basic-support-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: <2003-12-23153136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-basic-support-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-basic-support-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-23153136.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Tue Dec 23 15:40:10 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08753 for ; Tue, 23 Dec 2003 15:40: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 1AYtJe-0008Tk-Du for nemo-archive@odin.ietf.org; Tue, 23 Dec 2003 15:39:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNKdggK032588 for nemo-archive@odin.ietf.org; Tue, 23 Dec 2003 15:39:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtJe-0008TX-Aq for nemo-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 15:39: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 PAA08660 for ; Tue, 23 Dec 2003 15:39:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYtJc-00023r-00 for nemo-web-archive@ietf.org; Tue, 23 Dec 2003 15:39:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYtHp-0001yV-00 for nemo-web-archive@ietf.org; Tue, 23 Dec 2003 15:37:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYtG8-0001uX-00 for nemo-web-archive@ietf.org; Tue, 23 Dec 2003 15:36:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtG5-0007gj-Cs; Tue, 23 Dec 2003 15:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtFA-0007WM-ES for nemo@optimus.ietf.org; Tue, 23 Dec 2003 15:35:04 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07954; Tue, 23 Dec 2003 15:35:01 -0500 (EST) Message-Id: <200312232035.PAA07954@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: Tue, 23 Dec 2003 15:35:01 -0500 Subject: [nemo] I-D ACTION:draft-ietf-nemo-basic-support-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.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 : Nemo Basic Support Protocol Author(s) : V. Devarapalli Filename : draft-ietf-nemo-basic-support-02.txt Pages : 37 Date : 2003-12-23 This document describes the Nemo Basic Support protocol to support network mobility as the mobile network attaches to different points in the Internet. The protocol is based on extensions to Mobile IPv6 and allows for session continuity for every node in the mobile network as the network moves. It also allows every node in the mobile network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed in such a way that network mobility is transparent to the nodes inside the mobile network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-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-basic-support-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-basic-support-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: <2003-12-23153136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-basic-support-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-basic-support-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-23153136.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-admin@ietf.org Wed Dec 24 15:29:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21906 for ; Wed, 24 Dec 2003 15:29: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 1AZFcr-0001Dr-Cu; Wed, 24 Dec 2003 15:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZFc2-0001DF-JT for nemo@optimus.ietf.org; Wed, 24 Dec 2003 15:28:11 -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 PAA21886 for ; Wed, 24 Dec 2003 15:28:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZFc1-0007Ds-00 for nemo@ietf.org; Wed, 24 Dec 2003 15:28:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZFaC-0007Ay-00 for nemo@ietf.org; Wed, 24 Dec 2003 15:26:16 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1AZFZI-00077U-00 for nemo@ietf.org; Wed, 24 Dec 2003 15:25:20 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id hBOKOZ5K023845; Wed, 24 Dec 2003 13:24:35 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id hBOKOQ75028161; Wed, 24 Dec 2003 14:24:27 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 98C6C85272C; Wed, 24 Dec 2003 21:24:45 +0100 (CET) Message-ID: <3FE9F60D.8020902@motorola.com> Date: Wed, 24 Dec 2003 21:24:45 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: vijayd@iprg.nokia.com, nemo@ietf.org References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> In-Reply-To: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: Mobile Security Gateways (was: Issue 28) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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: >>> Let me remind you that we have a separate terminology because the >>> WG aggreed it; and that the terminology doc contains more terms >>> that are needed in NEMO Basic Support. So, if you want to move >>> some definitions in the NEMO Basic Support doc, we would still >>> need a doc for the other terms ... >>> >> >> I support leaving the definitions in terminology if it goes RFC, as >> I mentioned implicitly in the thread. Question: should we also >> move the definitions from the usage draft into the terminology (I >> assume yes)? > > Which definitions would be candidates ones ? Let's talk about "Mobile Security Gateways" what do you think? From an IPsec perspective, I have difficulty defining MR as an "IPsec Host" or as a "Security Gateway". A Mobile Security Gateway would act as an IPsec Host when sending BU's but as a Security Gateway (ESP in tunnel mode) when forwarding traffic from an LFN to the HA (through the tunnel). For that matter HA would simply be a Security Gateway, that's easy. A Mobile Security Gateway should not be interpreted as a fixed Security Gateway that supports mobile hosts roaming far away (e.g. a VPN Gateway to which roaming users connect); it should be interpreted as Security Gateway that actually moves. Alex From exim@www1.ietf.org Wed Dec 24 15:32:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21979 for ; Wed, 24 Dec 2003 15:32: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 1AZFfr-0001L1-2J for nemo-archive@odin.ietf.org; Wed, 24 Dec 2003 15:32:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBOKW6NL005137 for nemo-archive@odin.ietf.org; Wed, 24 Dec 2003 15:32:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZFfq-0001Km-Rk for nemo-web-archive@optimus.ietf.org; Wed, 24 Dec 2003 15:32: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 PAA21967 for ; Wed, 24 Dec 2003 15:32:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZFfp-0007JM-00 for nemo-web-archive@ietf.org; Wed, 24 Dec 2003 15:32:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZFe8-0007HY-00 for nemo-web-archive@ietf.org; Wed, 24 Dec 2003 15:30:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AZFcw-0007F3-00 for nemo-web-archive@ietf.org; Wed, 24 Dec 2003 15:29:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZFcr-0001Dr-Cu; Wed, 24 Dec 2003 15:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZFc2-0001DF-JT for nemo@optimus.ietf.org; Wed, 24 Dec 2003 15:28:11 -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 PAA21886 for ; Wed, 24 Dec 2003 15:28:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZFc1-0007Ds-00 for nemo@ietf.org; Wed, 24 Dec 2003 15:28:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZFaC-0007Ay-00 for nemo@ietf.org; Wed, 24 Dec 2003 15:26:16 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1AZFZI-00077U-00 for nemo@ietf.org; Wed, 24 Dec 2003 15:25:20 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id hBOKOZ5K023845; Wed, 24 Dec 2003 13:24:35 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id hBOKOQ75028161; Wed, 24 Dec 2003 14:24:27 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 98C6C85272C; Wed, 24 Dec 2003 21:24:45 +0100 (CET) Message-ID: <3FE9F60D.8020902@motorola.com> Date: Wed, 24 Dec 2003 21:24:45 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: vijayd@iprg.nokia.com, nemo@ietf.org References: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> In-Reply-To: <20031218143645.7406c58b.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Mobile Security Gateways (was: Issue 28) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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: >>> Let me remind you that we have a separate terminology because the >>> WG aggreed it; and that the terminology doc contains more terms >>> that are needed in NEMO Basic Support. So, if you want to move >>> some definitions in the NEMO Basic Support doc, we would still >>> need a doc for the other terms ... >>> >> >> I support leaving the definitions in terminology if it goes RFC, as >> I mentioned implicitly in the thread. Question: should we also >> move the definitions from the usage draft into the terminology (I >> assume yes)? > > Which definitions would be candidates ones ? Let's talk about "Mobile Security Gateways" what do you think? From an IPsec perspective, I have difficulty defining MR as an "IPsec Host" or as a "Security Gateway". A Mobile Security Gateway would act as an IPsec Host when sending BU's but as a Security Gateway (ESP in tunnel mode) when forwarding traffic from an LFN to the HA (through the tunnel). For that matter HA would simply be a Security Gateway, that's easy. A Mobile Security Gateway should not be interpreted as a fixed Security Gateway that supports mobile hosts roaming far away (e.g. a VPN Gateway to which roaming users connect); it should be interpreted as Security Gateway that actually moves. Alex From nemo-admin@ietf.org Tue Dec 30 06:00:44 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19142 for ; Tue, 30 Dec 2003 06:00: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 1AbHbX-00024n-Td; Tue, 30 Dec 2003 06: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 1AbHak-00023z-DY for nemo@optimus.ietf.org; Tue, 30 Dec 2003 05:59: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 FAA19089 for ; Tue, 30 Dec 2003 05:59:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AbHaW-0001TH-00 for nemo@ietf.org; Tue, 30 Dec 2003 05:59:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AbHWh-0001PN-00 for nemo@ietf.org; Tue, 30 Dec 2003 05:55:03 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AbHUv-0001Le-00 for nemo@ietf.org; Tue, 30 Dec 2003 05:53:13 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id hBUAq9Ok010327 for ; Tue, 30 Dec 2003 03:52:09 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id hBUAoSBi003511 for ; Tue, 30 Dec 2003 04:50:31 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 785FD85272C for ; Tue, 30 Dec 2003 11:50:33 +0100 (CET) Message-ID: <3FF15879.4010404@motorola.com> Date: Tue, 30 Dec 2003 11:50:33 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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] MNP in the explicit BU when returning home? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 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. Alex From exim@www1.ietf.org Tue Dec 30 06:08:06 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19308 for ; Tue, 30 Dec 2003 06:08: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 1AbHit-0002WT-9Q for nemo-archive@odin.ietf.org; Tue, 30 Dec 2003 06:07:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBUB7dOg009691 for nemo-archive@odin.ietf.org; Tue, 30 Dec 2003 06:07:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AbHis-0002W6-O7 for nemo-web-archive@optimus.ietf.org; Tue, 30 Dec 2003 06:07: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 GAA19293 for ; Tue, 30 Dec 2003 06:07:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AbHip-0001fi-00 for nemo-web-archive@ietf.org; Tue, 30 Dec 2003 06:07:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AbHe2-0001Zo-00 for nemo-web-archive@ietf.org; Tue, 30 Dec 2003 06:02:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AbHbx-0001Uh-00 for nemo-web-archive@ietf.org; Tue, 30 Dec 2003 06:00:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AbHbX-00024n-Td; Tue, 30 Dec 2003 06: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 1AbHak-00023z-DY for nemo@optimus.ietf.org; Tue, 30 Dec 2003 05:59: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 FAA19089 for ; Tue, 30 Dec 2003 05:59:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AbHaW-0001TH-00 for nemo@ietf.org; Tue, 30 Dec 2003 05:59:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AbHWh-0001PN-00 for nemo@ietf.org; Tue, 30 Dec 2003 05:55:03 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AbHUv-0001Le-00 for nemo@ietf.org; Tue, 30 Dec 2003 05:53:13 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id hBUAq9Ok010327 for ; Tue, 30 Dec 2003 03:52:09 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id hBUAoSBi003511 for ; Tue, 30 Dec 2003 04:50:31 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 785FD85272C for ; Tue, 30 Dec 2003 11:50:33 +0100 (CET) Message-ID: <3FF15879.4010404@motorola.com> Date: Tue, 30 Dec 2003 11:50:33 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@ietf.org X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] MNP in the explicit BU when returning home? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 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. Alex