From nemo-admin@ietf.org Tue Nov 4 10:26:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18371 for ; Tue, 4 Nov 2003 10:26: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 1AH34D-0003Cu-VZ; Tue, 04 Nov 2003 10:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH33L-0003AQ-Sr for nemo@optimus.ietf.org; Tue, 04 Nov 2003 10: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 KAA18294 for ; Tue, 4 Nov 2003 10:24:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH33J-0006uZ-00 for nemo@ietf.org; Tue, 04 Nov 2003 10:25:05 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AH33I-0006uB-00 for nemo@ietf.org; Tue, 04 Nov 2003 10:25:04 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 04 Nov 2003 16:22:16 +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 hA4FOKOI023860; Tue, 4 Nov 2003 16:24:21 +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, 4 Nov 2003 15:24: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Nov 2003 15:24:27 -0000 Message-ID: Thread-Topic: ro draft Thread-Index: AcOfUfWq0JNAIGM2Ro+tGGDNIXxEsADkL91g From: "Pascal Thubert (pthubert)" To: "Hiroyuki OHNISHI" Cc: X-OriginalArrivalTime: 04 Nov 2003 15:24:28.0702 (UTC) FILETIME=[BCE8BBE0:01C3A2E7] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: ro 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: quoted-printable Hi Hiroyuki-san: I believe this draft is important, and it reflects base thoughts that should be built upon. A solution like this improves the nemo basic support dramatically. We really need to open the RO discussion(s) ASAP. Chairs: do we need to recharter? One high level comment: there are to forms of RO addressed here, the "HMIP for Nemo" part, which addresses the pinball routing, and the RO for CN to LFN. I believe that they are orthogonal and should be in separate drafts. On HMIP for Nemo: 1) I hope this mechanism gets finally merged into HMIP draft. IMHO, it is the logical application of HMIP to Nemo. Did you start a discussion with Hesham? 2) The relation between the MR and the MAP is still a classical MRHA relationship. Pinball routing is avoided because the MAP is the HA for all the nested structure. But for the rest, most of the comments in RRH draft chapter "1.1 Recursive complexity" still apply. In other words, RRH is still very useful to simplify the HA operation, mostly for the nesting of tunnels and the computation of the recursive path (5.4.2). The 2 solutions are not opposed, and there's a great value to actually combine them. 3) The MAP option should be changed in order to advertise the Nemo capability 4) The solution should work for LFN since Basic Nemo is used. It would be nice to expand 'Data' in fig 9 to show that it can be an actual packet from LFN to CN. 5) I like fig 6, and I believe the MAP should be placed that way (fixed) as opposed to mobile. So I disagree with some text in 5.1. The MAP option should be always there in the tree, and it is not the way to detect that a MR is root. I suggest that you inherit that feature from the TIO option in RRH draft, which is meant for that, as opposed to overloading the MAP option. ON the RO to LFN We discussed that model on the ML. I mentioned that I do not like it too much because the RR test is tricked, since the CoA (the MR) is not collocated with the HoA (the LFN), which is what the test is supposed to confirm. So you need to start snooping and it's pretty unclean. Alternates were already discussed, like in Ryuji's initial basic nemo draft, and the correspondent router model which is an evolution of your MBG. Maybe we should write that draft :) There are also alternatives based on nemo aware nodes, for instance having the node send zeroed out RRHs (see RRH appendix 1) in the COTi, and then with the packets if the test flies.=20 Pascal From exim@www1.ietf.org Tue Nov 4 10:26:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18388 for ; Tue, 4 Nov 2003 10:26: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 1AH34K-0003EG-GW for nemo-archive@odin.ietf.org; Tue, 04 Nov 2003 10:26:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4FQ8KK012408 for nemo-archive@odin.ietf.org; Tue, 4 Nov 2003 10:26:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH34K-0003E3-BF for nemo-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 10:26: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 KAA18352 for ; Tue, 4 Nov 2003 10:25:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH34I-0006vh-00 for nemo-web-archive@ietf.org; Tue, 04 Nov 2003 10:26:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH34H-0006vb-00 for nemo-web-archive@ietf.org; Tue, 04 Nov 2003 10: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 1AH34D-0003Cu-VZ; Tue, 04 Nov 2003 10:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH33L-0003AQ-Sr for nemo@optimus.ietf.org; Tue, 04 Nov 2003 10: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 KAA18294 for ; Tue, 4 Nov 2003 10:24:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH33J-0006uZ-00 for nemo@ietf.org; Tue, 04 Nov 2003 10:25:05 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AH33I-0006uB-00 for nemo@ietf.org; Tue, 04 Nov 2003 10:25:04 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 04 Nov 2003 16:22:16 +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 hA4FOKOI023860; Tue, 4 Nov 2003 16:24:21 +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, 4 Nov 2003 15:24: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Nov 2003 15:24:27 -0000 Message-ID: Thread-Topic: ro draft Thread-Index: AcOfUfWq0JNAIGM2Ro+tGGDNIXxEsADkL91g From: "Pascal Thubert (pthubert)" To: "Hiroyuki OHNISHI" Cc: X-OriginalArrivalTime: 04 Nov 2003 15:24:28.0702 (UTC) FILETIME=[BCE8BBE0:01C3A2E7] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: ro 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: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Hiroyuki-san: I believe this draft is important, and it reflects base thoughts that should be built upon. A solution like this improves the nemo basic support dramatically. We really need to open the RO discussion(s) ASAP. Chairs: do we need to recharter? One high level comment: there are to forms of RO addressed here, the "HMIP for Nemo" part, which addresses the pinball routing, and the RO for CN to LFN. I believe that they are orthogonal and should be in separate drafts. On HMIP for Nemo: 1) I hope this mechanism gets finally merged into HMIP draft. IMHO, it is the logical application of HMIP to Nemo. Did you start a discussion with Hesham? 2) The relation between the MR and the MAP is still a classical MRHA relationship. Pinball routing is avoided because the MAP is the HA for all the nested structure. But for the rest, most of the comments in RRH draft chapter "1.1 Recursive complexity" still apply. In other words, RRH is still very useful to simplify the HA operation, mostly for the nesting of tunnels and the computation of the recursive path (5.4.2). The 2 solutions are not opposed, and there's a great value to actually combine them. 3) The MAP option should be changed in order to advertise the Nemo capability 4) The solution should work for LFN since Basic Nemo is used. It would be nice to expand 'Data' in fig 9 to show that it can be an actual packet from LFN to CN. 5) I like fig 6, and I believe the MAP should be placed that way (fixed) as opposed to mobile. So I disagree with some text in 5.1. The MAP option should be always there in the tree, and it is not the way to detect that a MR is root. I suggest that you inherit that feature from the TIO option in RRH draft, which is meant for that, as opposed to overloading the MAP option. ON the RO to LFN We discussed that model on the ML. I mentioned that I do not like it too much because the RR test is tricked, since the CoA (the MR) is not collocated with the HoA (the LFN), which is what the test is supposed to confirm. So you need to start snooping and it's pretty unclean. Alternates were already discussed, like in Ryuji's initial basic nemo draft, and the correspondent router model which is an evolution of your MBG. Maybe we should write that draft :) There are also alternatives based on nemo aware nodes, for instance having the node send zeroed out RRHs (see RRH appendix 1) in the COTi, and then with the packets if the test flies.=20 Pascal From nemo-admin@ietf.org Tue Nov 4 15:05:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01838 for ; Tue, 4 Nov 2003 15:05:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7QE-00018g-4c; Tue, 04 Nov 2003 15:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4yI-0004Ry-U8 for nemo@optimus.ietf.org; Tue, 04 Nov 2003 12:28: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 MAA24315 for ; Tue, 4 Nov 2003 12:27:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH4yH-0001LX-00 for nemo@ietf.org; Tue, 04 Nov 2003 12:28:01 -0500 Received: from fw.hel.fi.ssh.com ([195.20.116.97]) by ietf-mx with esmtp (Exim 4.12) id 1AH4yG-0001LC-00 for nemo@ietf.org; Tue, 04 Nov 2003 12:28:00 -0500 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.16) with SMTP id hA4HRpEU000883 for ; Tue, 4 Nov 2003 19:27:51 +0200 (EET) Received: (qmail 23501 invoked from network); 4 Nov 2003 17:27:51 -0000 Received: from unknown (HELO ryijy.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 4 Nov 2003 17:27:51 -0000 Received: (from kivinen@localhost) by ryijy.hel.fi.ssh.com (8.11.6/8.11.0) id hA4HRpD14874; Tue, 4 Nov 2003 19:27:51 +0200 (EET) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f Message-ID: <16295.57671.83.671707@ryijy.hel.fi.ssh.com> Date: Tue, 4 Nov 2003 19:26:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: nemo@ietf.org X-Mailer: VM 7.07 under Emacs 20.7.1 X-Edit-Time: 1 min X-Total-Time: 1173 min Content-Transfer-Encoding: 7bit Subject: [nemo] IKEv2 Mobility and Multihoming BOF Tue, Nov 11, 1700-1800 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit There has been some interest in the IPsec working group to add features to IKEv2 to support roaming, mobility, and multihoming. The IPsec working group decided that those issues are not included as part of the current IKEv2 core protocol, but instead they are handled in separate documents and/or working group. The mobility features are need to support Mobile IP efficiently, and are also used in the cases where devices perform roaming (move around and the IP address changes), and they do want to keep the existing IKE and IPsec SAs in place even when the IP address changes without full rekeying. The features needed include way to update the IKEv2 SA and IPsec SA endpoint addresses without need of the rekeying the SAs, and also authenticating those changes (return routability or similar). Another feature needed is to support multihoming and support having multiple IP addresses tied to one IKEv2 SA and IPsec SA. This support is needed by routers having multiple interfaces, when using SCTP, and in cases where for example mobile device might have multiple different connections to the internet (i.e for example WLAN and GPRS). Some way to authenticate those multiple IP addresses is also needed. The features should then be used by the Mobile IP, HIP, etc working groups as building blocks to create their final protocols, but some of the features can immediately be used in the IPsec VPNs too (client roaming in VPN case, SCTP, multihoming support). The BOF is currently scheduled for Tuesday, November 11, 2003, at 1700-1800. The BOF have some kind of web pages at http://mobike.kivinen.iki.fi/index.html. The web pages have agenda for the meeting, proposed charter and basic introduction to the problem. The BOF mailing list: General Discussion: mobike@machshav.com To subscribe: mobike-request@machshav.com Archive and general information: https://www.machshav.com/mailman/listinfo/mobike The MOBIKE BOF's goal is to verify that we have enough interest to define mobility and multihoming extensions to the current IKEv2 protocol. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From exim@www1.ietf.org Tue Nov 4 15:05:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01853 for ; Tue, 4 Nov 2003 15:05: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 1AH7QH-00019e-6u for nemo-archive@odin.ietf.org; Tue, 04 Nov 2003 15:05:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4K555h004432 for nemo-archive@odin.ietf.org; Tue, 4 Nov 2003 15: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 1AH7QG-00019P-U9 for nemo-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 15:05: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 PAA01785 for ; Tue, 4 Nov 2003 15:04:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH7QD-0004FQ-00 for nemo-web-archive@ietf.org; Tue, 04 Nov 2003 15:05:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH7QD-0004FN-00 for nemo-web-archive@ietf.org; Tue, 04 Nov 2003 15: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 1AH7QE-00018g-4c; Tue, 04 Nov 2003 15:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4yI-0004Ry-U8 for nemo@optimus.ietf.org; Tue, 04 Nov 2003 12:28: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 MAA24315 for ; Tue, 4 Nov 2003 12:27:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH4yH-0001LX-00 for nemo@ietf.org; Tue, 04 Nov 2003 12:28:01 -0500 Received: from fw.hel.fi.ssh.com ([195.20.116.97]) by ietf-mx with esmtp (Exim 4.12) id 1AH4yG-0001LC-00 for nemo@ietf.org; Tue, 04 Nov 2003 12:28:00 -0500 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.16) with SMTP id hA4HRpEU000883 for ; Tue, 4 Nov 2003 19:27:51 +0200 (EET) Received: (qmail 23501 invoked from network); 4 Nov 2003 17:27:51 -0000 Received: from unknown (HELO ryijy.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 4 Nov 2003 17:27:51 -0000 Received: (from kivinen@localhost) by ryijy.hel.fi.ssh.com (8.11.6/8.11.0) id hA4HRpD14874; Tue, 4 Nov 2003 19:27:51 +0200 (EET) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f Message-ID: <16295.57671.83.671707@ryijy.hel.fi.ssh.com> Date: Tue, 4 Nov 2003 19:26:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: nemo@ietf.org X-Mailer: VM 7.07 under Emacs 20.7.1 X-Edit-Time: 1 min X-Total-Time: 1173 min Content-Transfer-Encoding: 7bit Subject: [nemo] IKEv2 Mobility and Multihoming BOF Tue, Nov 11, 1700-1800 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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 There has been some interest in the IPsec working group to add features to IKEv2 to support roaming, mobility, and multihoming. The IPsec working group decided that those issues are not included as part of the current IKEv2 core protocol, but instead they are handled in separate documents and/or working group. The mobility features are need to support Mobile IP efficiently, and are also used in the cases where devices perform roaming (move around and the IP address changes), and they do want to keep the existing IKE and IPsec SAs in place even when the IP address changes without full rekeying. The features needed include way to update the IKEv2 SA and IPsec SA endpoint addresses without need of the rekeying the SAs, and also authenticating those changes (return routability or similar). Another feature needed is to support multihoming and support having multiple IP addresses tied to one IKEv2 SA and IPsec SA. This support is needed by routers having multiple interfaces, when using SCTP, and in cases where for example mobile device might have multiple different connections to the internet (i.e for example WLAN and GPRS). Some way to authenticate those multiple IP addresses is also needed. The features should then be used by the Mobile IP, HIP, etc working groups as building blocks to create their final protocols, but some of the features can immediately be used in the IPsec VPNs too (client roaming in VPN case, SCTP, multihoming support). The BOF is currently scheduled for Tuesday, November 11, 2003, at 1700-1800. The BOF have some kind of web pages at http://mobike.kivinen.iki.fi/index.html. The web pages have agenda for the meeting, proposed charter and basic introduction to the problem. The BOF mailing list: General Discussion: mobike@machshav.com To subscribe: mobike-request@machshav.com Archive and general information: https://www.machshav.com/mailman/listinfo/mobike The MOBIKE BOF's goal is to verify that we have enough interest to define mobility and multihoming extensions to the current IKEv2 protocol. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From nemo-admin@ietf.org Wed Nov 5 01:08:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25050 for ; Wed, 5 Nov 2003 01:08: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 1AHGpm-0006Hd-9E; Wed, 05 Nov 2003 01: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 1AHGpQ-0006Cr-AE for nemo@optimus.ietf.org; Wed, 05 Nov 2003 01:07:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25039 for ; Wed, 5 Nov 2003 01:07:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHGpN-000503-00 for nemo@ietf.org; Wed, 05 Nov 2003 01:07:37 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AHGpM-0004zn-00 for nemo@ietf.org; Wed, 05 Nov 2003 01:07:36 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id E98F85D14B; Wed, 5 Nov 2003 15:07:05 +0900 (JST) Date: Wed, 5 Nov 2003 15:01:33 +0900 From: Thierry Ernst To: "Pascal Thubert (pthubert)" Cc: ohnishi.hiroyuki@lab.ntt.co.jp, nemo@ietf.org Subject: Re: [nemo] RE: ro draft Message-Id: <20031105150133.5acdc289.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > I believe this draft is important, and it reflects base thoughts that > should be built upon. A solution like this improves the nemo basic > support dramatically. We really need to open the RO discussion(s) ASAP. > Chairs: do we need to recharter? I will give my own point of view. First thing first, we have important milestones where no contribution has been performed so far (MIB) or almost not (threat analysis). I would like to see these been taken of first, prior to opening the RO debate. Second, the charter says: The WG will work on: - An informational document which specifies a detailed problem statement for route optimization and looks at various approaches to solving this problem. This document will look into the issues and tradeoffs involved in making the network's movement visible to some nodes, by optionally making them "NEMO aware". The interaction between route optimization and IP routing will also be described in this document. Furthermore, security considerations for the various approaches will also be considered. Milestones: Jun 04 Shut down or recharter the WG to solve the route optimization. Which means we need to work on the problem statement first (including analysis of the solution space), not on the solutions. So far, I only saw solutions. I wish people would commit to the tasks of the WG. I personnaly don't mind other issues being investigated as long as the agreed objectives are being taken care of. Thierry. From exim@www1.ietf.org Wed Nov 5 01:08:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25065 for ; Wed, 5 Nov 2003 01:08: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 1AHGpq-0006JU-Rd for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 01:08:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA56863d024265 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 01:08:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHGpq-0006JI-Me for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 01: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 BAA25043 for ; Wed, 5 Nov 2003 01:07:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHGpn-00050G-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 01:08:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHGpn-00050C-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 01:08:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHGpm-0006Hd-9E; Wed, 05 Nov 2003 01: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 1AHGpQ-0006Cr-AE for nemo@optimus.ietf.org; Wed, 05 Nov 2003 01:07:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25039 for ; Wed, 5 Nov 2003 01:07:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHGpN-000503-00 for nemo@ietf.org; Wed, 05 Nov 2003 01:07:37 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AHGpM-0004zn-00 for nemo@ietf.org; Wed, 05 Nov 2003 01:07:36 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id E98F85D14B; Wed, 5 Nov 2003 15:07:05 +0900 (JST) Date: Wed, 5 Nov 2003 15:01:33 +0900 From: Thierry Ernst To: "Pascal Thubert (pthubert)" Cc: ohnishi.hiroyuki@lab.ntt.co.jp, nemo@ietf.org Subject: Re: [nemo] RE: ro draft Message-Id: <20031105150133.5acdc289.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > I believe this draft is important, and it reflects base thoughts that > should be built upon. A solution like this improves the nemo basic > support dramatically. We really need to open the RO discussion(s) ASAP. > Chairs: do we need to recharter? I will give my own point of view. First thing first, we have important milestones where no contribution has been performed so far (MIB) or almost not (threat analysis). I would like to see these been taken of first, prior to opening the RO debate. Second, the charter says: The WG will work on: - An informational document which specifies a detailed problem statement for route optimization and looks at various approaches to solving this problem. This document will look into the issues and tradeoffs involved in making the network's movement visible to some nodes, by optionally making them "NEMO aware". The interaction between route optimization and IP routing will also be described in this document. Furthermore, security considerations for the various approaches will also be considered. Milestones: Jun 04 Shut down or recharter the WG to solve the route optimization. Which means we need to work on the problem statement first (including analysis of the solution space), not on the solutions. So far, I only saw solutions. I wish people would commit to the tasks of the WG. I personnaly don't mind other issues being investigated as long as the agreed objectives are being taken care of. Thierry. From nemo-admin@ietf.org Wed Nov 5 01:59:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26437 for ; Wed, 5 Nov 2003 01:59: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 1AHHd7-0000nX-2W; Wed, 05 Nov 2003 01: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 1AHHci-0000mj-DG for nemo@optimus.ietf.org; Wed, 05 Nov 2003 01:58: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 BAA26420 for ; Wed, 5 Nov 2003 01:58:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHHce-0005cy-00 for nemo@ietf.org; Wed, 05 Nov 2003 01:58:33 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AHHcd-0005cs-00 for nemo@ietf.org; Wed, 05 Nov 2003 01:58:31 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id hA56o2Rn015292; Wed, 5 Nov 2003 14:50:02 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 6178910E95DA; Wed, 5 Nov 2003 14:58:32 +0800 (SGT) Subject: Re: [nemo] RE: ro draft From: Chan-Wah NG To: Thierry Ernst Cc: "Pascal Thubert (pthubert)" , ohnishi.hiroyuki@lab.ntt.co.jp, IETF NEMO WG In-Reply-To: <20031105150133.5acdc289.ernst@sfc.wide.ad.jp> References: <20031105150133.5acdc289.ernst@sfc.wide.ad.jp> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1068015512.6785.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 05 Nov 2003 14:58:32 +0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, Thierry, Pascal, On Wed, 2003-11-05 at 14:01, Thierry Ernst wrote: > Which means we need to work on the problem statement first (including > analysis of the solution space), not on the solutions. So far, I only > saw solutions. > Not really. Pascal and myself has submitted the RO-taxonomy draft which is not meant to be solution, but more of a problem-space or solution-space thingy. An update would most likely be necessary to further tune it to the current charter (especially to be in sync with basic NEMO solution), but as an co-author, I don't foresee the document to become solution-oriented. It should stay on the path of describing the problem space. Of-course, the focus needs to be on the more eminent work items, which is why I have not updated the ARO draft after it has expired for so long ;) /rgds /cwng From exim@www1.ietf.org Wed Nov 5 01:59:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26452 for ; Wed, 5 Nov 2003 01:59: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 1AHHd9-0000oW-QT for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 01:59:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA56x36W003122 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 01:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHHd9-0000oH-IN for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 01:59: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 BAA26431 for ; Wed, 5 Nov 2003 01:58:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHHd6-0005dD-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 01:59:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHHd5-0005dA-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 01:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHHd7-0000nX-2W; Wed, 05 Nov 2003 01: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 1AHHci-0000mj-DG for nemo@optimus.ietf.org; Wed, 05 Nov 2003 01:58: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 BAA26420 for ; Wed, 5 Nov 2003 01:58:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHHce-0005cy-00 for nemo@ietf.org; Wed, 05 Nov 2003 01:58:33 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AHHcd-0005cs-00 for nemo@ietf.org; Wed, 05 Nov 2003 01:58:31 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id hA56o2Rn015292; Wed, 5 Nov 2003 14:50:02 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 6178910E95DA; Wed, 5 Nov 2003 14:58:32 +0800 (SGT) Subject: Re: [nemo] RE: ro draft From: Chan-Wah NG To: Thierry Ernst Cc: "Pascal Thubert (pthubert)" , ohnishi.hiroyuki@lab.ntt.co.jp, IETF NEMO WG In-Reply-To: <20031105150133.5acdc289.ernst@sfc.wide.ad.jp> References: <20031105150133.5acdc289.ernst@sfc.wide.ad.jp> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1068015512.6785.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 05 Nov 2003 14:58:32 +0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Thierry, Pascal, On Wed, 2003-11-05 at 14:01, Thierry Ernst wrote: > Which means we need to work on the problem statement first (including > analysis of the solution space), not on the solutions. So far, I only > saw solutions. > Not really. Pascal and myself has submitted the RO-taxonomy draft which is not meant to be solution, but more of a problem-space or solution-space thingy. An update would most likely be necessary to further tune it to the current charter (especially to be in sync with basic NEMO solution), but as an co-author, I don't foresee the document to become solution-oriented. It should stay on the path of describing the problem space. Of-course, the focus needs to be on the more eminent work items, which is why I have not updated the ARO draft after it has expired for so long ;) /rgds /cwng From nemo-admin@ietf.org Wed Nov 5 02:13:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09027 for ; Wed, 5 Nov 2003 02:13: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 1AHHqf-0002mv-GS; Wed, 05 Nov 2003 02:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHHqX-0002lz-LK for nemo@optimus.ietf.org; Wed, 05 Nov 2003 02:12: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 CAA08928 for ; Wed, 5 Nov 2003 02:12:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHHqT-0005pR-00 for nemo@ietf.org; Wed, 05 Nov 2003 02:12:49 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AHHqT-0005og-00 for nemo@ietf.org; Wed, 05 Nov 2003 02:12:49 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 294825D0F7; Wed, 5 Nov 2003 16:12:19 +0900 (JST) Date: Wed, 5 Nov 2003 16:06:46 +0900 From: Thierry Ernst To: Chan-Wah NG Cc: pthubert@cisco.com, ohnishi.hiroyuki@lab.ntt.co.jp, nemo@ietf.org Subject: Re: [nemo] RE: ro draft Message-Id: <20031105160646.14a07ac4.ernst@sfc.wide.ad.jp> In-Reply-To: <1068015512.6785.6.camel@localhost> References: <20031105150133.5acdc289.ernst@sfc.wide.ad.jp> <1068015512.6785.6.camel@localhost> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi ChanWah, > > Which means we need to work on the problem statement first (including > > analysis of the solution space), not on the solutions. So far, I only > > saw solutions. > > > > Not really. Pascal and myself has submitted the RO-taxonomy draft which > is not meant to be solution, but more of a problem-space or > solution-space thingy. An update would most likely be necessary to > further tune it to the current charter (especially to be in sync with > basic NEMO solution), but as an co-author, I don't foresee the document > to become solution-oriented. It should stay on the path of describing > the problem space. OK, I haven't had a chance to read the document yet, and I missed the point it was not a solution document. The analysis of the solution space will have to cover not only MIP-like solutions as this was aknowledged during the charter set up. I wish the discussion could start after Minneapolis. > Of-course, the focus needs to be on the more eminent work items, which > is why I have not updated the ARO draft after it has expired for so long > ;) Thanks for your approval in this ! Thierry. From exim@www1.ietf.org Wed Nov 5 02:13:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09050 for ; Wed, 5 Nov 2003 02:13: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 1AHHqp-0002oP-QB for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 02:13:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA57DBFI010805 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 02:13:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHHqo-0002oC-Vw for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 02:13: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 CAA08972 for ; Wed, 5 Nov 2003 02:12:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHHqi-0005pl-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 02:13:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHHqi-0005pi-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 02:13:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHHqf-0002mv-GS; Wed, 05 Nov 2003 02:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHHqX-0002lz-LK for nemo@optimus.ietf.org; Wed, 05 Nov 2003 02:12: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 CAA08928 for ; Wed, 5 Nov 2003 02:12:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHHqT-0005pR-00 for nemo@ietf.org; Wed, 05 Nov 2003 02:12:49 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AHHqT-0005og-00 for nemo@ietf.org; Wed, 05 Nov 2003 02:12:49 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 294825D0F7; Wed, 5 Nov 2003 16:12:19 +0900 (JST) Date: Wed, 5 Nov 2003 16:06:46 +0900 From: Thierry Ernst To: Chan-Wah NG Cc: pthubert@cisco.com, ohnishi.hiroyuki@lab.ntt.co.jp, nemo@ietf.org Subject: Re: [nemo] RE: ro draft Message-Id: <20031105160646.14a07ac4.ernst@sfc.wide.ad.jp> In-Reply-To: <1068015512.6785.6.camel@localhost> References: <20031105150133.5acdc289.ernst@sfc.wide.ad.jp> <1068015512.6785.6.camel@localhost> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi ChanWah, > > Which means we need to work on the problem statement first (including > > analysis of the solution space), not on the solutions. So far, I only > > saw solutions. > > > > Not really. Pascal and myself has submitted the RO-taxonomy draft which > is not meant to be solution, but more of a problem-space or > solution-space thingy. An update would most likely be necessary to > further tune it to the current charter (especially to be in sync with > basic NEMO solution), but as an co-author, I don't foresee the document > to become solution-oriented. It should stay on the path of describing > the problem space. OK, I haven't had a chance to read the document yet, and I missed the point it was not a solution document. The analysis of the solution space will have to cover not only MIP-like solutions as this was aknowledged during the charter set up. I wish the discussion could start after Minneapolis. > Of-course, the focus needs to be on the more eminent work items, which > is why I have not updated the ARO draft after it has expired for so long > ;) Thanks for your approval in this ! Thierry. From nemo-admin@ietf.org Wed Nov 5 04:27:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27889 for ; Wed, 5 Nov 2003 04:27: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 1AHJwM-0004Mg-AT; Wed, 05 Nov 2003 04:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJvn-0004LE-LD for nemo@optimus.ietf.org; Wed, 05 Nov 2003 04:26:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27854 for ; Wed, 5 Nov 2003 04:26:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHJvk-00005q-00 for nemo@ietf.org; Wed, 05 Nov 2003 04:26:24 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AHJvj-00005c-00 for nemo@ietf.org; Wed, 05 Nov 2003 04:26:23 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id hA59IFRn019517; Wed, 5 Nov 2003 17:18:15 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id E53C610E95DA; Wed, 5 Nov 2003 17:26:44 +0800 (SGT) Subject: Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt From: Chan-Wah NG To: "T.J. Kniveton" Cc: IETF NEMO WG , Margaret Wasserman , Thomas Narten In-Reply-To: References: Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1068024404.6779.27.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 05 Nov 2003 17:26:44 +0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, Here are some issues on the NEMO Basic Support. Most are of cosmetic nature requiring only minor editorial changes, but I would like to call upon the WG's attention on the first 3 issues, which in my opinion must be resolved before the draft can go through LC (and presumably be submitted to the IESG). Major (or Non-Minor) Issues --------------------------- (1) IANA Considerations - Page 25 - Section 9 In addition to the mobility options type, I would think that the various new Status values in Binding Acknowledgement need IANA considerations as well when MIPv6 becomes an RFC, though I am not too sure what needs and what does not need IANA considerations. (2) Is Issue 11 resolved? Three modes of operations were specified for NEMO operations. It was explicitly stated that the Home Agent MUST implement all three (which partially resolved issue 11). However, no such statement were made about the Mobile Router. I presume it means that the Mobile Router is free to implement any combinations of the three. According to the Issues webpage, there seems to be a consensus on issue 11 that there will be explicit statements specifying the mobile router implement any one of the modes. However, I fail to find such statement in the -01 draft. Might be also helpful to discuss which mode is better suited for what situations. (3) ESP is a MUST? - Page 24, Sect 7 The last sentence of Section 7 says the "tunneled routing messages MUST be authenticated and encrypted using IPsec ESP in tunnel mode". Even the original MIPv6 Specs (-24) is not so strict in specifying what kind of encryption scheme must be used to protect the BU. I suggest adopting an approach similar to MIPv6 by requiring that MR and HA "MUST support and SHOULD use IPsec ESP to protect ...". This forces MR and HA to implements ESP as a baseline for interoperability, yet allows implementors to choose other forms of encryption when both MR and HA implement it. Minor Editorial Issues ----------------------- (1) Page 1 - Title: "Nemo Basic Support Protocol" I am under the assumption that it is generally considered not very good style to use non-well-known abbreviation in I-Draft/RFC titles (well known being limited to a very small range of abbreviations like IP, TCP, UDP). It might be a good idea to change the title to "Network Mobility Basic Support Protocol". On the same note, a lot of abbreviations are used without giving their full meanings in the document, like OSPF, RIPng, ESP, etc. Though proper end reference are given, it might be good to expand them when they are first used, instead of forcing readers to dig into end-references to get the fully-expanded phrase. (2) Page 5 - Sect 2. Terminology The appearance of definition of 'Prefix Table' is awkward. There is no sentence in the preceding paragraph leading to it. Some sentences like 'In addition, the following term is defined ... ' or the equivalence might be necessary. (3) Page 11 - Sect 4.3 Mobile Network Prefix Option It might be better to change 'contains' to 'containing' to be consistent with the use of continuous tense in the descriptions of other fields. (4) Page 11 - Sect 4.4 Mobile Network Prefix Length Option 2nd Paragraph: 'The Mobile Network Option cannot be present ...' Perhaps we should use the stronger phrase of 'MUST NOT' instead, since RFC2119 does not contain the term 'cannot'. (5) Page 14 - Sect 5.3 Recieving Binding Acknoweldgement The last line of the page, a space after the period '.' is missing. --> '... Network.The ...' (6) Page 19 - Sect 6.2 The first bullet of the second paragraph, 3rd line, '... MUST be an Home Address ...'. 'an' --> 'a'? (7) Page 22 - Sect 6.6 The first paragraph, '.. same rules it uses for sending Binding Acknowledgment to Mobile Hosts, ...' : Perhaps a reference to [1] will be nice to explicitly define what those 'same rules' are? (8) Page 23 - Sect 7 1st paragraph, 4th line, ' ... to run a intra-domain ...' 'a' -> 'an'? (9) Page 7 - Sect 1 2nd paragraph on Page 7, the abbreviation 'HA' is first used without explanation. In most part of the document, the full term 'Home Agent' is used, with occasional use of 'HA' popping up. I suggest searching through the document and replace 'HA' with 'Home Agent' for coherence and consistence. (10) Page 25 - Sect 8 The 5th line in the 2nd paragraph: "The source address of the outer IPv6 header MUST be set the Mobile Router's ..." should read "... MUST be set to the ...". Continuing from this line, "... MUST belong to the Mobile Network Prefix owned by the Mobile Router" suggest only one prefix can be owned by a mobile router. It should perhaps be changed to "... MUST belong to one of the Mobile Network Prefix(es) owned ...". (11) Page 25 - Sect 9 A period is missing in the last sentence of Sect 9. (12) Page 17 - Sect 5.5 Last sentence in this section is a 'See [3].' Should be changed to a better formulated sentence, such as 'Please refer to [3] for more details' or something like that. (13) Page 20 - Sect 6.2 Pardon my poor command of English, but the second last paragraph of Sect 6.2 is difficult to read. I suspect the word 'like' in "... by multicasting onto the home like a Neighbor ..." is mis-typed (my guess is the correct word is 'link', but I am not too sure because the way the sentence was structured). In addition, the 2nd sentence in the same paragraph begins with "All fields in each such Neighbor Advertisement ..." , in my humble opinion, should read "... every such ...". Furthermore, this is one of the rare paragraphs in the whole document where "mobile router" is not first-letter-captitalized. (14) Clarifications on Sect 5.6. It was unclear to me on the first few reads that the first paragraph refer to the behaviour when the mobile router is at home, and the next paragraphs refer to the behaviour when mobile router is away. Perhaps some annotation or opening phrases like 'When the Mobile Router is at home, ...' and 'When the Mobile Router is away, ...' should precede paragraph 1 and paragraph 2 respectively. /rgds /cwng On Fri, 2003-10-24 at 17:27, T.J. Kniveton wrote: > Hi folks, > > The Basic Support draft has been issued for a while now and has had no > significant issues pending in this version. We would like to encourage > everyone in the working group to make sure you have read this draft and > contributed any open issues so that they can be resolved and we can move on > from this charter item. > > So, we would like to issue a working group last call for this draft, which > will extend for two weeks, until November 7th. Based on the response during > this time, the working group will decide how to update the draft and move > forward. > > Thanks, > > -TJ Kniveton, Thierry Ernst. > NEMO chairs > > > From exim@www1.ietf.org Wed Nov 5 04:27:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27912 for ; Wed, 5 Nov 2003 04:27: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 1AHJwW-0004Ob-6z for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 04:27:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA59RCG9016890 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 04:27:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJwV-0004OL-Ov for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 04:27: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 EAA27867 for ; Wed, 5 Nov 2003 04:26:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHJwS-00006E-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 04:27:08 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHJwS-00006B-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 04:27:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJwM-0004Mg-AT; Wed, 05 Nov 2003 04:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJvn-0004LE-LD for nemo@optimus.ietf.org; Wed, 05 Nov 2003 04:26:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27854 for ; Wed, 5 Nov 2003 04:26:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHJvk-00005q-00 for nemo@ietf.org; Wed, 05 Nov 2003 04:26:24 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AHJvj-00005c-00 for nemo@ietf.org; Wed, 05 Nov 2003 04:26:23 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id hA59IFRn019517; Wed, 5 Nov 2003 17:18:15 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id E53C610E95DA; Wed, 5 Nov 2003 17:26:44 +0800 (SGT) Subject: Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt From: Chan-Wah NG To: "T.J. Kniveton" Cc: IETF NEMO WG , Margaret Wasserman , Thomas Narten In-Reply-To: References: Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1068024404.6779.27.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 05 Nov 2003 17:26:44 +0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Here are some issues on the NEMO Basic Support. Most are of cosmetic nature requiring only minor editorial changes, but I would like to call upon the WG's attention on the first 3 issues, which in my opinion must be resolved before the draft can go through LC (and presumably be submitted to the IESG). Major (or Non-Minor) Issues --------------------------- (1) IANA Considerations - Page 25 - Section 9 In addition to the mobility options type, I would think that the various new Status values in Binding Acknowledgement need IANA considerations as well when MIPv6 becomes an RFC, though I am not too sure what needs and what does not need IANA considerations. (2) Is Issue 11 resolved? Three modes of operations were specified for NEMO operations. It was explicitly stated that the Home Agent MUST implement all three (which partially resolved issue 11). However, no such statement were made about the Mobile Router. I presume it means that the Mobile Router is free to implement any combinations of the three. According to the Issues webpage, there seems to be a consensus on issue 11 that there will be explicit statements specifying the mobile router implement any one of the modes. However, I fail to find such statement in the -01 draft. Might be also helpful to discuss which mode is better suited for what situations. (3) ESP is a MUST? - Page 24, Sect 7 The last sentence of Section 7 says the "tunneled routing messages MUST be authenticated and encrypted using IPsec ESP in tunnel mode". Even the original MIPv6 Specs (-24) is not so strict in specifying what kind of encryption scheme must be used to protect the BU. I suggest adopting an approach similar to MIPv6 by requiring that MR and HA "MUST support and SHOULD use IPsec ESP to protect ...". This forces MR and HA to implements ESP as a baseline for interoperability, yet allows implementors to choose other forms of encryption when both MR and HA implement it. Minor Editorial Issues ----------------------- (1) Page 1 - Title: "Nemo Basic Support Protocol" I am under the assumption that it is generally considered not very good style to use non-well-known abbreviation in I-Draft/RFC titles (well known being limited to a very small range of abbreviations like IP, TCP, UDP). It might be a good idea to change the title to "Network Mobility Basic Support Protocol". On the same note, a lot of abbreviations are used without giving their full meanings in the document, like OSPF, RIPng, ESP, etc. Though proper end reference are given, it might be good to expand them when they are first used, instead of forcing readers to dig into end-references to get the fully-expanded phrase. (2) Page 5 - Sect 2. Terminology The appearance of definition of 'Prefix Table' is awkward. There is no sentence in the preceding paragraph leading to it. Some sentences like 'In addition, the following term is defined ... ' or the equivalence might be necessary. (3) Page 11 - Sect 4.3 Mobile Network Prefix Option It might be better to change 'contains' to 'containing' to be consistent with the use of continuous tense in the descriptions of other fields. (4) Page 11 - Sect 4.4 Mobile Network Prefix Length Option 2nd Paragraph: 'The Mobile Network Option cannot be present ...' Perhaps we should use the stronger phrase of 'MUST NOT' instead, since RFC2119 does not contain the term 'cannot'. (5) Page 14 - Sect 5.3 Recieving Binding Acknoweldgement The last line of the page, a space after the period '.' is missing. --> '... Network.The ...' (6) Page 19 - Sect 6.2 The first bullet of the second paragraph, 3rd line, '... MUST be an Home Address ...'. 'an' --> 'a'? (7) Page 22 - Sect 6.6 The first paragraph, '.. same rules it uses for sending Binding Acknowledgment to Mobile Hosts, ...' : Perhaps a reference to [1] will be nice to explicitly define what those 'same rules' are? (8) Page 23 - Sect 7 1st paragraph, 4th line, ' ... to run a intra-domain ...' 'a' -> 'an'? (9) Page 7 - Sect 1 2nd paragraph on Page 7, the abbreviation 'HA' is first used without explanation. In most part of the document, the full term 'Home Agent' is used, with occasional use of 'HA' popping up. I suggest searching through the document and replace 'HA' with 'Home Agent' for coherence and consistence. (10) Page 25 - Sect 8 The 5th line in the 2nd paragraph: "The source address of the outer IPv6 header MUST be set the Mobile Router's ..." should read "... MUST be set to the ...". Continuing from this line, "... MUST belong to the Mobile Network Prefix owned by the Mobile Router" suggest only one prefix can be owned by a mobile router. It should perhaps be changed to "... MUST belong to one of the Mobile Network Prefix(es) owned ...". (11) Page 25 - Sect 9 A period is missing in the last sentence of Sect 9. (12) Page 17 - Sect 5.5 Last sentence in this section is a 'See [3].' Should be changed to a better formulated sentence, such as 'Please refer to [3] for more details' or something like that. (13) Page 20 - Sect 6.2 Pardon my poor command of English, but the second last paragraph of Sect 6.2 is difficult to read. I suspect the word 'like' in "... by multicasting onto the home like a Neighbor ..." is mis-typed (my guess is the correct word is 'link', but I am not too sure because the way the sentence was structured). In addition, the 2nd sentence in the same paragraph begins with "All fields in each such Neighbor Advertisement ..." , in my humble opinion, should read "... every such ...". Furthermore, this is one of the rare paragraphs in the whole document where "mobile router" is not first-letter-captitalized. (14) Clarifications on Sect 5.6. It was unclear to me on the first few reads that the first paragraph refer to the behaviour when the mobile router is at home, and the next paragraphs refer to the behaviour when mobile router is away. Perhaps some annotation or opening phrases like 'When the Mobile Router is at home, ...' and 'When the Mobile Router is away, ...' should precede paragraph 1 and paragraph 2 respectively. /rgds /cwng On Fri, 2003-10-24 at 17:27, T.J. Kniveton wrote: > Hi folks, > > The Basic Support draft has been issued for a while now and has had no > significant issues pending in this version. We would like to encourage > everyone in the working group to make sure you have read this draft and > contributed any open issues so that they can be resolved and we can move on > from this charter item. > > So, we would like to issue a working group last call for this draft, which > will extend for two weeks, until November 7th. Based on the response during > this time, the working group will decide how to update the draft and move > forward. > > Thanks, > > -TJ Kniveton, Thierry Ernst. > NEMO chairs > > > From nemo-admin@ietf.org Wed Nov 5 06:03:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00499 for ; Wed, 5 Nov 2003 06:03: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 1AHLRF-0000b9-4y; Wed, 05 Nov 2003 06: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 1AHLQu-0000Ys-Pr for nemo@optimus.ietf.org; Wed, 05 Nov 2003 06:02:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00464 for ; Wed, 5 Nov 2003 06:02:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHLQq-0001Lo-00 for nemo@ietf.org; Wed, 05 Nov 2003 06:02:37 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AHLQq-0001L2-00 for nemo@ietf.org; Wed, 05 Nov 2003 06:02:36 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Nov 2003 11:59:53 +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 hA5B1sH8012467; Wed, 5 Nov 2003 12:01: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, 5 Nov 2003 11:02:03 +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: ro draft Date: Wed, 5 Nov 2003 11:02:02 -0000 Message-ID: Thread-Topic: [nemo] RE: ro draft Thread-Index: AcOjbDdTRPC3O9C7QA2fxYBvbq9gnQAClxiA From: "Pascal Thubert (pthubert)" To: "Thierry Ernst" , "Chan-Wah NG" Cc: , X-OriginalArrivalTime: 05 Nov 2003 11:02:03.0085 (UTC) FILETIME=[3E33FFD0:01C3A38C] 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 > > > Which means we need to work on the problem statement first (including > > > analysis of the solution space), not on the solutions. So far, I only > > > saw solutions. > > > > > > > Not really. Pascal and myself has submitted the RO-taxonomy draft which > > is not meant to be solution, but more of a problem-space or > > solution-space thingy. An update would most likely be necessary to > > further tune it to the current charter (especially to be in sync with > > basic NEMO solution), but as an co-author, I don't foresee the document > > to become solution-oriented. It should stay on the path of describing > > the problem space. >=20 > OK, I haven't had a chance to read the document yet, and I missed the > point it was not a solution document. The analysis of the solution space > will have to cover not only MIP-like solutions as this was aknowledged > during the charter set up. >=20 Right. The draft is http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-01.tx t=20 and the prez we made at IETF 55 in Atlanta is http://www.mobilenetworks.org/nemo/ietf55/slides/NEMO-IETF-RO-Taxonomy-2 0021120-v3.ppt=20 It's impressive to realize how many RO solution drafts were published since then! Realistically, there's a chicken and an egg problem between our draft and the RO solutions being published, because you need to have an idea of the possible solutions in order to list them. So there's no surprise that the authors of the taxonomy are also the first who proposed solutions for RO.=20 Yet, it's impossible to guess everything that can be invented next. This is why the draft scopes only at building the taxonomy of the problem space, in a "split and conquer" approach. The taxonomy is not MIP-only; for instance (AODV cloud + gateway) is part of a group of solutions called "Internal Routing and gateway", while Hiroyuki's approach belongs explicitly to the "Surrogate" group. Since we published _00, more solutions were disclosed, and the draft was updated once as new openings were raised; obviously, it could be improved again, and we expect comments if someone believes that his approach is not covered enough in the taxonomy. _01 is a bit old now, but since there's no discussion over it, it's been left dormant. Note that I started the effort based on the solutions we (in my group at cisco) had brain stormed over. Since our conclusion was (: and still is :) that RRH is the way to go for the problem it addresses, it's no surprise that the _00 draft was RRH-biased. A part of Chan Wah's contribution was to help unbias the draft.=20 Also, the draft does not address only the pinball routing problem, but attempts to list all the flows that could be optimized, as the slides at IETF 55 illustrate. Pascal=20 From exim@www1.ietf.org Wed Nov 5 06:03:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00514 for ; Wed, 5 Nov 2003 06: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 1AHLRH-0000c5-Ga for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 06:03:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5B33fO002351 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 06:03:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHLRH-0000bq-BS for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 06:03: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 GAA00480 for ; Wed, 5 Nov 2003 06:02:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHLRD-0001MB-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 06:02:59 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHLRD-0001M8-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 06:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHLRF-0000b9-4y; Wed, 05 Nov 2003 06: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 1AHLQu-0000Ys-Pr for nemo@optimus.ietf.org; Wed, 05 Nov 2003 06:02:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00464 for ; Wed, 5 Nov 2003 06:02:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHLQq-0001Lo-00 for nemo@ietf.org; Wed, 05 Nov 2003 06:02:37 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AHLQq-0001L2-00 for nemo@ietf.org; Wed, 05 Nov 2003 06:02:36 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Nov 2003 11:59:53 +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 hA5B1sH8012467; Wed, 5 Nov 2003 12:01: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, 5 Nov 2003 11:02:03 +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: ro draft Date: Wed, 5 Nov 2003 11:02:02 -0000 Message-ID: Thread-Topic: [nemo] RE: ro draft Thread-Index: AcOjbDdTRPC3O9C7QA2fxYBvbq9gnQAClxiA From: "Pascal Thubert (pthubert)" To: "Thierry Ernst" , "Chan-Wah NG" Cc: , X-OriginalArrivalTime: 05 Nov 2003 11:02:03.0085 (UTC) FILETIME=[3E33FFD0:01C3A38C] 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 > > > Which means we need to work on the problem statement first (including > > > analysis of the solution space), not on the solutions. So far, I only > > > saw solutions. > > > > > > > Not really. Pascal and myself has submitted the RO-taxonomy draft which > > is not meant to be solution, but more of a problem-space or > > solution-space thingy. An update would most likely be necessary to > > further tune it to the current charter (especially to be in sync with > > basic NEMO solution), but as an co-author, I don't foresee the document > > to become solution-oriented. It should stay on the path of describing > > the problem space. >=20 > OK, I haven't had a chance to read the document yet, and I missed the > point it was not a solution document. The analysis of the solution space > will have to cover not only MIP-like solutions as this was aknowledged > during the charter set up. >=20 Right. The draft is http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-01.tx t=20 and the prez we made at IETF 55 in Atlanta is http://www.mobilenetworks.org/nemo/ietf55/slides/NEMO-IETF-RO-Taxonomy-2 0021120-v3.ppt=20 It's impressive to realize how many RO solution drafts were published since then! Realistically, there's a chicken and an egg problem between our draft and the RO solutions being published, because you need to have an idea of the possible solutions in order to list them. So there's no surprise that the authors of the taxonomy are also the first who proposed solutions for RO.=20 Yet, it's impossible to guess everything that can be invented next. This is why the draft scopes only at building the taxonomy of the problem space, in a "split and conquer" approach. The taxonomy is not MIP-only; for instance (AODV cloud + gateway) is part of a group of solutions called "Internal Routing and gateway", while Hiroyuki's approach belongs explicitly to the "Surrogate" group. Since we published _00, more solutions were disclosed, and the draft was updated once as new openings were raised; obviously, it could be improved again, and we expect comments if someone believes that his approach is not covered enough in the taxonomy. _01 is a bit old now, but since there's no discussion over it, it's been left dormant. Note that I started the effort based on the solutions we (in my group at cisco) had brain stormed over. Since our conclusion was (: and still is :) that RRH is the way to go for the problem it addresses, it's no surprise that the _00 draft was RRH-biased. A part of Chan Wah's contribution was to help unbias the draft.=20 Also, the draft does not address only the pinball routing problem, but attempts to list all the flows that could be optimized, as the slides at IETF 55 illustrate. Pascal=20 From nemo-admin@ietf.org Wed Nov 5 07:23:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02840 for ; Wed, 5 Nov 2003 07:23: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 1AHMgf-000540-Gp; Wed, 05 Nov 2003 07: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 1AHMg1-00053a-5U for nemo@optimus.ietf.org; Wed, 05 Nov 2003 07:22: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 HAA02806 for ; Wed, 5 Nov 2003 07:22:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHMg0-0002f1-00 for nemo@ietf.org; Wed, 05 Nov 2003 07:22:20 -0500 Received: from smtp.mei.co.jp ([133.183.129.25] helo=jazz.mei.co.jp) by ietf-mx with esmtp (Exim 4.12) id 1AHMfz-0002eC-00 for nemo@ietf.org; Wed, 05 Nov 2003 07:22:20 -0500 Received: by jazz.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id hA5CLjD7027454 for ; Wed, 5 Nov 2003 21:21:45 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id hA5CLlQ24712 for ; Wed, 5 Nov 2003 21:21:47 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id hA5CLkU06026; Wed, 5 Nov 2003 21:21:47 +0900 (JST) Received: from STRATOS ([10.96.152.147]) by mrit.mrit.mei.co.jp (8.12.6p2/3.7W-03060222) with SMTP id hA5CLh2t075968; Wed, 5 Nov 2003 21:21:44 +0900 (JST) Message-Id: <200311051221.hA5CLh2t075968@mrit.mrit.mei.co.jp> Date: Wed, 05 Nov 2003 12:22:04 +0000 From: MATSUMOTO Taisuke To: nemo@ietf.org Organization: Matsushita Electric Industrial Co., Ltd. X-Mailer: Datula version 1.52.01 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Subject: [nemo] Behavior of HA Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 NEMO WG members, I'm trying to implement the NEMO protocol stack, and I find a problem. I set up my test network according to the figure 1 in the basic support draft page 28. See below. +-------------------+ 3:: 2+-------+ | Internet |------| CN_MR | +-------------------+ +-------+ 4:: | | 2+-------------+3 +--+-+ +---+---+ | MR | | HA_MR | +--+-+ +-------+ 5:: |1 ---------- 2| +--+-+ | LFN| +--+-+ I tried to run the MR in the explicit prefix length mode. When the mobile router was attached to the foreign link, the MR tried to send the binding update message which consists of '5::1' for the home address and '64' for the prefix length. But the HA rejected that BU message and returned the BA message with the status code 132. This behavior is defined in the section 10.3.1 of the mobile IPv6 draft, draft-ietf-mobileip-ipv6-24.txt. The explicit prefix length mode uses the IP address of the ingress interface as the home address of the mobile router. In this case, the IP address of the ingress interface is not an on-link IP address of the HA. So, I think that some schemes to avoid that restriction of the mobile IPv6 specifications is required for the NEMO basic support. Best regards, Taisuke MATSUMOTO From exim@www1.ietf.org Wed Nov 5 07:23:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02855 for ; Wed, 5 Nov 2003 07:23: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 1AHMgh-00054r-Nr for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 07:23:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5CN3OY019516 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 07:23:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHMgh-00054h-K0 for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 07:23: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 HAA02826 for ; Wed, 5 Nov 2003 07:22:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHMgh-0002fp-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 07:23:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHMgg-0002fm-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 07:23:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHMgf-000540-Gp; Wed, 05 Nov 2003 07: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 1AHMg1-00053a-5U for nemo@optimus.ietf.org; Wed, 05 Nov 2003 07:22: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 HAA02806 for ; Wed, 5 Nov 2003 07:22:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHMg0-0002f1-00 for nemo@ietf.org; Wed, 05 Nov 2003 07:22:20 -0500 Received: from smtp.mei.co.jp ([133.183.129.25] helo=jazz.mei.co.jp) by ietf-mx with esmtp (Exim 4.12) id 1AHMfz-0002eC-00 for nemo@ietf.org; Wed, 05 Nov 2003 07:22:20 -0500 Received: by jazz.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id hA5CLjD7027454 for ; Wed, 5 Nov 2003 21:21:45 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id hA5CLlQ24712 for ; Wed, 5 Nov 2003 21:21:47 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id hA5CLkU06026; Wed, 5 Nov 2003 21:21:47 +0900 (JST) Received: from STRATOS ([10.96.152.147]) by mrit.mrit.mei.co.jp (8.12.6p2/3.7W-03060222) with SMTP id hA5CLh2t075968; Wed, 5 Nov 2003 21:21:44 +0900 (JST) Message-Id: <200311051221.hA5CLh2t075968@mrit.mrit.mei.co.jp> Date: Wed, 05 Nov 2003 12:22:04 +0000 From: MATSUMOTO Taisuke To: nemo@ietf.org Organization: Matsushita Electric Industrial Co., Ltd. X-Mailer: Datula version 1.52.01 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Subject: [nemo] Behavior of HA Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 NEMO WG members, I'm trying to implement the NEMO protocol stack, and I find a problem. I set up my test network according to the figure 1 in the basic support draft page 28. See below. +-------------------+ 3:: 2+-------+ | Internet |------| CN_MR | +-------------------+ +-------+ 4:: | | 2+-------------+3 +--+-+ +---+---+ | MR | | HA_MR | +--+-+ +-------+ 5:: |1 ---------- 2| +--+-+ | LFN| +--+-+ I tried to run the MR in the explicit prefix length mode. When the mobile router was attached to the foreign link, the MR tried to send the binding update message which consists of '5::1' for the home address and '64' for the prefix length. But the HA rejected that BU message and returned the BA message with the status code 132. This behavior is defined in the section 10.3.1 of the mobile IPv6 draft, draft-ietf-mobileip-ipv6-24.txt. The explicit prefix length mode uses the IP address of the ingress interface as the home address of the mobile router. In this case, the IP address of the ingress interface is not an on-link IP address of the HA. So, I think that some schemes to avoid that restriction of the mobile IPv6 specifications is required for the NEMO basic support. Best regards, Taisuke MATSUMOTO From nemo-admin@ietf.org Wed Nov 5 08:58:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05711 for ; Wed, 5 Nov 2003 08: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 1AHOAa-0002h8-Mw; Wed, 05 Nov 2003 08:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHO9u-0002el-TQ for nemo@optimus.ietf.org; Wed, 05 Nov 2003 08:57: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 IAA05674 for ; Wed, 5 Nov 2003 08:57:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHO9t-0004TO-00 for nemo@ietf.org; Wed, 05 Nov 2003 08:57:17 -0500 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 1AHO9t-0004TK-00 for nemo@ietf.org; Wed, 05 Nov 2003 08:57:17 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA5DudlQ276756; Wed, 5 Nov 2003 08:56:39 -0500 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA5Ducj8296856; Wed, 5 Nov 2003 06:56:39 -0700 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id hA5DrJoA001080; Wed, 5 Nov 2003 08:53:19 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id hA5DrIRo001076; Wed, 5 Nov 2003 08:53:19 -0500 Message-Id: <200311051353.hA5DrIRo001076@rotala.raleigh.ibm.com> To: Chan-Wah NG cc: "T.J. Kniveton" , IETF NEMO WG , Margaret Wasserman Subject: Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt In-Reply-To: Message from cwng@psl.com.sg of "Wed, 05 Nov 2003 17:26:44 +0800." <1068024404.6779.27.camel@localhost> Date: Wed, 05 Nov 2003 08:53:18 -0500 From: Thomas Narten Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > Here are some issues on the NEMO Basic Support. Most are of cosmetic > nature requiring only minor editorial changes, but I would like to call > upon the WG's attention on the first 3 issues, which in my opinion must > be resolved before the draft can go through LC (and presumably be > submitted to the IESG). Any reason not to forward these comments to the WG directly? Thomas From exim@www1.ietf.org Wed Nov 5 08:58:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05726 for ; Wed, 5 Nov 2003 08:58: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 1AHOAf-0002i5-A5 for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 08:58:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Dw5BG010411 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 08: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 1AHOAe-0002hq-Rx for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 08: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 IAA05705 for ; Wed, 5 Nov 2003 08:57:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHOAd-0004Tp-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 08:58:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHOAd-0004Tm-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 08: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 1AHOAa-0002h8-Mw; Wed, 05 Nov 2003 08:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHO9u-0002el-TQ for nemo@optimus.ietf.org; Wed, 05 Nov 2003 08:57: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 IAA05674 for ; Wed, 5 Nov 2003 08:57:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHO9t-0004TO-00 for nemo@ietf.org; Wed, 05 Nov 2003 08:57:17 -0500 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 1AHO9t-0004TK-00 for nemo@ietf.org; Wed, 05 Nov 2003 08:57:17 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA5DudlQ276756; Wed, 5 Nov 2003 08:56:39 -0500 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA5Ducj8296856; Wed, 5 Nov 2003 06:56:39 -0700 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id hA5DrJoA001080; Wed, 5 Nov 2003 08:53:19 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id hA5DrIRo001076; Wed, 5 Nov 2003 08:53:19 -0500 Message-Id: <200311051353.hA5DrIRo001076@rotala.raleigh.ibm.com> To: Chan-Wah NG cc: "T.J. Kniveton" , IETF NEMO WG , Margaret Wasserman Subject: Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt In-Reply-To: Message from cwng@psl.com.sg of "Wed, 05 Nov 2003 17:26:44 +0800." <1068024404.6779.27.camel@localhost> Date: Wed, 05 Nov 2003 08:53:18 -0500 From: Thomas Narten Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > Here are some issues on the NEMO Basic Support. Most are of cosmetic > nature requiring only minor editorial changes, but I would like to call > upon the WG's attention on the first 3 issues, which in my opinion must > be resolved before the draft can go through LC (and presumably be > submitted to the IESG). Any reason not to forward these comments to the WG directly? Thomas From nemo-admin@ietf.org Wed Nov 5 09:14:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06169 for ; Wed, 5 Nov 2003 09:14: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 1AHOQ5-0003Yk-G0; Wed, 05 Nov 2003 09:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHOPe-0003YV-KB for nemo@optimus.ietf.org; Wed, 05 Nov 2003 09:13: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 JAA06156 for ; Wed, 5 Nov 2003 09:13:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHOPd-0004ig-00 for nemo@ietf.org; Wed, 05 Nov 2003 09:13:33 -0500 Received: from e6.ny.us.ibm.com ([32.97.182.106]) by ietf-mx with esmtp (Exim 4.12) id 1AHOPc-0004ic-00 for nemo@ietf.org; Wed, 05 Nov 2003 09:13:32 -0500 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA5ED1Vn638574; Wed, 5 Nov 2003 09:13:01 -0500 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA5ED0bR071744; Wed, 5 Nov 2003 09:13:00 -0500 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id hA5E9goA001257; Wed, 5 Nov 2003 09:09:42 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id hA5E9fOn001252; Wed, 5 Nov 2003 09:09:41 -0500 Message-Id: <200311051409.hA5E9fOn001252@rotala.raleigh.ibm.com> To: Chan-Wah NG cc: nemo@ietf.org Subject: Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt In-Reply-To: Message from cwng@psl.com.sg of "Wed, 05 Nov 2003 22:11:59 +0800." <1068041518.6779.32.camel@localhost> Date: Wed, 05 Nov 2003 09:09:41 -0500 From: Thomas Narten Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > Is there a mistake here? Yes. I didn't look at the cc field closely enough, as you did cc' the WG in your note. :-( Sorry about the confusion. Thomas From exim@www1.ietf.org Wed Nov 5 09:14:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06184 for ; Wed, 5 Nov 2003 09:14: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 1AHOQ6-0003Zg-Lb for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 09:14:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5EE2Ks013734 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 09: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 1AHOQ6-0003ZR-Fp for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 09:14: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 JAA06164 for ; Wed, 5 Nov 2003 09:13:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHOQ4-0004iq-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 09:14:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHOQ4-0004in-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 09:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHOQ5-0003Yk-G0; Wed, 05 Nov 2003 09:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHOPe-0003YV-KB for nemo@optimus.ietf.org; Wed, 05 Nov 2003 09:13: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 JAA06156 for ; Wed, 5 Nov 2003 09:13:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHOPd-0004ig-00 for nemo@ietf.org; Wed, 05 Nov 2003 09:13:33 -0500 Received: from e6.ny.us.ibm.com ([32.97.182.106]) by ietf-mx with esmtp (Exim 4.12) id 1AHOPc-0004ic-00 for nemo@ietf.org; Wed, 05 Nov 2003 09:13:32 -0500 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA5ED1Vn638574; Wed, 5 Nov 2003 09:13:01 -0500 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA5ED0bR071744; Wed, 5 Nov 2003 09:13:00 -0500 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id hA5E9goA001257; Wed, 5 Nov 2003 09:09:42 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id hA5E9fOn001252; Wed, 5 Nov 2003 09:09:41 -0500 Message-Id: <200311051409.hA5E9fOn001252@rotala.raleigh.ibm.com> To: Chan-Wah NG cc: nemo@ietf.org Subject: Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt In-Reply-To: Message from cwng@psl.com.sg of "Wed, 05 Nov 2003 22:11:59 +0800." <1068041518.6779.32.camel@localhost> Date: Wed, 05 Nov 2003 09:09:41 -0500 From: Thomas Narten Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > Is there a mistake here? Yes. I didn't look at the cc field closely enough, as you did cc' the WG in your note. :-( Sorry about the confusion. Thomas From nemo-admin@ietf.org Wed Nov 5 09:55:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07378 for ; Wed, 5 Nov 2003 09:55: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 1AHP3m-0005v3-Ai; Wed, 05 Nov 2003 09:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHHRT-0000X1-9E for nemo@optimus.ietf.org; Wed, 05 Nov 2003 01:46: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 BAA26144 for ; Wed, 5 Nov 2003 01:46:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHHRP-0005XM-00 for nemo@ietf.org; Wed, 05 Nov 2003 01:46:55 -0500 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1AHHRP-0005X7-00 for nemo@ietf.org; Wed, 05 Nov 2003 01:46:55 -0500 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id C295E689A4 for ; Wed, 5 Nov 2003 01:46:21 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.9) with ESMTP id hA56kLUh027415 for ; Wed, 5 Nov 2003 01:46:21 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.10/8.12.9) with ESMTP id hA56kHh9001525 for ; Wed, 5 Nov 2003 01:46:19 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20031104110908.01fc42b0@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 04 Nov 2003 11:22:30 -0500 To: nemo@ietf.org From: William D Ivancic Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_551693==.ALT" Subject: [nemo] Nemo Basic Support - IP in IP tunneling vs NAT transversal Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --=====================_551693==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed From the basic support document page 7: " Once the binding process completes, a bi-directional tunnel is established between the Home Agent and the Mobile Router. The tunnel end points are Mobile Router's Care-of Address and the Home Agent's address. If a packet with a source address belonging to the Mobile Network Prefix is received from the Mobile Network, the Mobile Router reverse-tunnels the packet to the Home Agent through this tunnel. This reverse-tunneling is done by using IP-in-IP encapsulation [3]. " In the requirements document, one of the requirements is to make sure we consider NATs. Although most may consider NATs to only exist in IPv4, I strongly suspect they will occur in IPv6 in order to manage security at a single location (rather that to increase the available address space). Thus, should we consider something like IP-in-UDP encapsulation also. I believe this is the solution for NAT transversal in IPv4. Note, this is not necessarily just a NAT issue. I was running IPv4 mobile network code (Cisco Systems IOS version) in T-Mobile's network (GPRS) with public address space. It was working until they implemented a security policy that stopped data into the T-Mobile network unless it originated from the T-Mobile network. Thus, they are not NATing, but they are administratively filtering. I believe NAT transversal code will solve this, but have not tried it yet. I was able to obtain information from T-Mobile indicating that the policy was put in place to keep excess traffic off of the GPRS network (excess traffic was being generated by Internet address searching software and worms. T-Mobile indicated that the GPRS links are considered valuable resources that need to be protected. They were unwilling to change their policy. Will ======================================= Will Ivancic NASA Glenn Research Center 21000 Brookpark Road MS 54-5 Cleveland, Ohio 44135 Phone +1 (216)433-3494 Fax +1 (216) 433-8705 Yahoo Instant Messenger ID: ivancic http://roland.grc.nasa.gov/~ivancic --=====================_551693==.ALT Content-Type: text/html; charset="us-ascii" From the basic support document page 7:

"  Once the binding process completes, a bi-directional tunnel is
   established between the Home Agent and the Mobile Router.  The tunnel
   end points are Mobile Router's Care-of Address and the Home Agent's
   address.  If a packet with a source address belonging to the Mobile
   Network Prefix is received from the Mobile Network, the Mobile Router
   reverse-tunnels the packet to the Home Agent through this tunnel.
   This reverse-tunneling is done by using IP-in-IP encapsulation [3].  "
 
In the requirements document, one of the requirements is to make sure we consider NATs.  Although most may consider NATs to only exist in IPv4,  I strongly suspect they will occur in IPv6 in order to manage security at a single location (rather that to increase the available address space).

Thus, should we consider something like IP-in-UDP encapsulation also.  I believe this is the solution for NAT transversal in IPv4.

Note, this is not necessarily just a NAT issue.  I was running  IPv4 mobile network code (Cisco Systems IOS version) in T-Mobile's network (GPRS) with public address space.  It was working until they implemented a security policy that stopped data into the T-Mobile network unless it originated from the T-Mobile network.  Thus, they are not NATing, but they are administratively filtering.  I believe NAT transversal code will solve this, but have not tried it yet.

I was able to obtain information from T-Mobile indicating that the policy was put in place to keep excess traffic off of the GPRS network (excess traffic was being generated by Internet address searching software and worms.  T-Mobile indicated that the GPRS links are considered valuable resources that need to be protected.  They were unwilling to change their policy.

Will



=======================================
Will Ivancic
NASA Glenn Research Center
21000 Brookpark Road    MS 54-5
Cleveland, Ohio  44135
Phone +1 (216)433-3494
Fax +1 (216) 433-8705
Yahoo Instant Messenger  ID: ivancic
http://roland.grc.nasa.gov/~ivancic

 --=====================_551693==.ALT-- From exim@www1.ietf.org Wed Nov 5 09:55:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07393 for ; Wed, 5 Nov 2003 09: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 1AHP3r-0005wZ-1F for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 09:55:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Et6Cu022841 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 09:55:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHP3q-0005wK-Ne for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 09:55: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 JAA07360 for ; Wed, 5 Nov 2003 09:54:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHP3o-0005He-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 09:55:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHP3o-0005Hb-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 09:55:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHP3m-0005v3-Ai; Wed, 05 Nov 2003 09:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHHRT-0000X1-9E for nemo@optimus.ietf.org; Wed, 05 Nov 2003 01:46: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 BAA26144 for ; Wed, 5 Nov 2003 01:46:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHHRP-0005XM-00 for nemo@ietf.org; Wed, 05 Nov 2003 01:46:55 -0500 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1AHHRP-0005X7-00 for nemo@ietf.org; Wed, 05 Nov 2003 01:46:55 -0500 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id C295E689A4 for ; Wed, 5 Nov 2003 01:46:21 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.9) with ESMTP id hA56kLUh027415 for ; Wed, 5 Nov 2003 01:46:21 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.10/8.12.9) with ESMTP id hA56kHh9001525 for ; Wed, 5 Nov 2003 01:46:19 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20031104110908.01fc42b0@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 04 Nov 2003 11:22:30 -0500 To: nemo@ietf.org From: William D Ivancic Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_551693==.ALT" Subject: [nemo] Nemo Basic Support - IP in IP tunneling vs NAT transversal Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --=====================_551693==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed From the basic support document page 7: " Once the binding process completes, a bi-directional tunnel is established between the Home Agent and the Mobile Router. The tunnel end points are Mobile Router's Care-of Address and the Home Agent's address. If a packet with a source address belonging to the Mobile Network Prefix is received from the Mobile Network, the Mobile Router reverse-tunnels the packet to the Home Agent through this tunnel. This reverse-tunneling is done by using IP-in-IP encapsulation [3]. " In the requirements document, one of the requirements is to make sure we consider NATs. Although most may consider NATs to only exist in IPv4, I strongly suspect they will occur in IPv6 in order to manage security at a single location (rather that to increase the available address space). Thus, should we consider something like IP-in-UDP encapsulation also. I believe this is the solution for NAT transversal in IPv4. Note, this is not necessarily just a NAT issue. I was running IPv4 mobile network code (Cisco Systems IOS version) in T-Mobile's network (GPRS) with public address space. It was working until they implemented a security policy that stopped data into the T-Mobile network unless it originated from the T-Mobile network. Thus, they are not NATing, but they are administratively filtering. I believe NAT transversal code will solve this, but have not tried it yet. I was able to obtain information from T-Mobile indicating that the policy was put in place to keep excess traffic off of the GPRS network (excess traffic was being generated by Internet address searching software and worms. T-Mobile indicated that the GPRS links are considered valuable resources that need to be protected. They were unwilling to change their policy. Will ======================================= Will Ivancic NASA Glenn Research Center 21000 Brookpark Road MS 54-5 Cleveland, Ohio 44135 Phone +1 (216)433-3494 Fax +1 (216) 433-8705 Yahoo Instant Messenger ID: ivancic http://roland.grc.nasa.gov/~ivancic --=====================_551693==.ALT Content-Type: text/html; charset="us-ascii" From the basic support document page 7:

"  Once the binding process completes, a bi-directional tunnel is
   established between the Home Agent and the Mobile Router.  The tunnel
   end points are Mobile Router's Care-of Address and the Home Agent's
   address.  If a packet with a source address belonging to the Mobile
   Network Prefix is received from the Mobile Network, the Mobile Router
   reverse-tunnels the packet to the Home Agent through this tunnel.
   This reverse-tunneling is done by using IP-in-IP encapsulation [3].  "
 
In the requirements document, one of the requirements is to make sure we consider NATs.  Although most may consider NATs to only exist in IPv4,  I strongly suspect they will occur in IPv6 in order to manage security at a single location (rather that to increase the available address space).

Thus, should we consider something like IP-in-UDP encapsulation also.  I believe this is the solution for NAT transversal in IPv4.

Note, this is not necessarily just a NAT issue.  I was running  IPv4 mobile network code (Cisco Systems IOS version) in T-Mobile's network (GPRS) with public address space.  It was working until they implemented a security policy that stopped data into the T-Mobile network unless it originated from the T-Mobile network.  Thus, they are not NATing, but they are administratively filtering.  I believe NAT transversal code will solve this, but have not tried it yet.

I was able to obtain information from T-Mobile indicating that the policy was put in place to keep excess traffic off of the GPRS network (excess traffic was being generated by Internet address searching software and worms.  T-Mobile indicated that the GPRS links are considered valuable resources that need to be protected.  They were unwilling to change their policy.

Will



=======================================
Will Ivancic
NASA Glenn Research Center
21000 Brookpark Road    MS 54-5
Cleveland, Ohio  44135
Phone +1 (216)433-3494
Fax +1 (216) 433-8705
Yahoo Instant Messenger  ID: ivancic
http://roland.grc.nasa.gov/~ivancic

 --=====================_551693==.ALT-- From nemo-admin@ietf.org Wed Nov 5 10:16:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09374 for ; Wed, 5 Nov 2003 10: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 1AHPO6-0007Bu-7R; Wed, 05 Nov 2003 10:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPN9-000789-Tp for nemo@optimus.ietf.org; Wed, 05 Nov 2003 10:15: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 KAA09222 for ; Wed, 5 Nov 2003 10:14:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPN7-0005Yr-00 for nemo@ietf.org; Wed, 05 Nov 2003 10:15:01 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AHPN6-0005Yj-00 for nemo@ietf.org; Wed, 05 Nov 2003 10:15:00 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Nov 2003 16:12:15 +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 hA5FEJo8005263; Wed, 5 Nov 2003 16:14:20 +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, 5 Nov 2003 15:14:28 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A3AF.813853E4" Subject: RE: [nemo] Nemo Basic Support - IP in IP tunneling vs NAT transversal Date: Wed, 5 Nov 2003 15:14:27 -0000 Message-ID: Thread-Topic: [nemo] Nemo Basic Support - IP in IP tunneling vs NAT transversal Thread-Index: AcOjrPLa34kgXjHYR1eErYsQdMXgcQAAhZQw From: "Pascal Thubert (pthubert)" To: "William D Ivancic" , X-OriginalArrivalTime: 05 Nov 2003 15:14:28.0726 (UTC) FILETIME=[81B56960:01C3A3AF] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A3AF.813853E4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi William =20 Note that Doors should work with the T-Mobile IPv4 infrastructure an dtheir active filters, at least if IP-in-UDP does for IPv4 mobile tunnels. =20 Pascal -----Original Message----- From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of William D Ivancic Sent: mardi 4 novembre 2003 17:23 To: nemo@ietf.org Subject: [nemo] Nemo Basic Support - IP in IP tunneling vs NAT transversal =20 >From the basic support document page 7: " Once the binding process completes, a bi-directional tunnel is established between the Home Agent and the Mobile Router. The tunnel end points are Mobile Router's Care-of Address and the Home Agent's address. If a packet with a source address belonging to the Mobile Network Prefix is received from the Mobile Network, the Mobile Router reverse-tunnels the packet to the Home Agent through this tunnel. This reverse-tunneling is done by using IP-in-IP encapsulation [3]. " =20 In the requirements document, one of the requirements is to make sure we consider NATs. Although most may consider NATs to only exist in IPv4, I strongly suspect they will occur in IPv6 in order to manage security at a single location (rather that to increase the available address space). Thus, should we consider something like IP-in-UDP encapsulation also. I believe this is the solution for NAT transversal in IPv4. Note, this is not necessarily just a NAT issue. I was running IPv4 mobile network code (Cisco Systems IOS version) in T-Mobile's network (GPRS) with public address space. It was working until they implemented a security policy that stopped data into the T-Mobile network unless it originated from the T-Mobile network. Thus, they are not NATing, but they are administratively filtering. I believe NAT transversal code will solve this, but have not tried it yet. I was able to obtain information from T-Mobile indicating that the policy was put in place to keep excess traffic off of the GPRS network (excess traffic was being generated by Internet address searching software and worms. T-Mobile indicated that the GPRS links are considered valuable resources that need to be protected. They were unwilling to change their policy. Will =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Will Ivancic NASA Glenn Research Center 21000 Brookpark Road MS 54-5 Cleveland, Ohio 44135 Phone +1 (216)433-3494 Fax +1 (216) 433-8705 Yahoo Instant Messenger ID: ivancic http://roland.grc.nasa.gov/~ivancic ------_=_NextPart_001_01C3A3AF.813853E4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi William

 

Note that Doors should work with = the T-Mobile IPv4 infrastructure an dtheir active filters, at least if = IP-in-UDP does for IPv4 mobile tunnels.

 

Pascal

-----Original Message-----
From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On = Behalf Of William D Ivancic
Sent: mardi 4 novembre = 2003 17:23
To: nemo@ietf.org
Subject: [nemo] Nemo = Basic Support - IP in IP tunneling vs NAT transversal

 

From the basic support document page 7:

"  Once the binding process completes, a bi-directional tunnel = is
   established between the Home Agent and the Mobile = Router.  The tunnel
   end points are Mobile Router's Care-of Address and the Home Agent's
   address.  If a packet with a source address belonging = to the Mobile
   Network Prefix is received from the Mobile Network, the = Mobile Router
   reverse-tunnels the packet to the Home Agent through this = tunnel.
   This reverse-tunneling is done by using IP-in-IP = encapsulation [3].  "
 
In the requirements document, one of the requirements is to make sure we consider NATs.  Although most may consider NATs to only exist in IPv4,  I strongly suspect they will occur in IPv6 in order to = manage security at a single location (rather that to increase the available = address space).

Thus, should we consider something like IP-in-UDP encapsulation = also.  I believe this is the solution for NAT transversal in IPv4.

Note, this is not necessarily just a NAT issue.  I was = running  IPv4 mobile network code (Cisco Systems IOS version) in T-Mobile's network = (GPRS) with public address space.  It was working until they implemented a security policy that stopped data into the T-Mobile network unless it originated from the T-Mobile network.  Thus, they are not NATing, = but they are administratively filtering.  I believe NAT transversal code = will solve this, but have not tried it yet.

I was able to obtain information from T-Mobile indicating that the = policy was put in place to keep excess traffic off of the GPRS network (excess = traffic was being generated by Internet address searching software and worms.  T-Mobile indicated that the GPRS links are considered valuable resources = that need to be protected.  They were unwilling to change their = policy.

Will




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= Will Ivancic
NASA Glenn Research Center
21000 Brookpark Road    MS 54-5
Cleveland, Ohio  44135
Phone +1 (216)433-3494
Fax +1 (216) 433-8705
Yahoo Instant Messenger  ID: ivancic
http://roland.grc.nasa.gov/~ivancic

------_=_NextPart_001_01C3A3AF.813853E4-- From exim@www1.ietf.org Wed Nov 5 10:16:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09387 for ; Wed, 5 Nov 2003 10:16: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 1AHPO9-0007Ct-TY for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 10:16:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5FG5K5027697 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 10:16:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPO9-0007Ce-Nj for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 10:16: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 KAA09320 for ; Wed, 5 Nov 2003 10:15:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPO7-0005bN-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 10:16:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHPO7-0005bK-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 10: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 1AHPO6-0007Bu-7R; Wed, 05 Nov 2003 10:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPN9-000789-Tp for nemo@optimus.ietf.org; Wed, 05 Nov 2003 10:15: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 KAA09222 for ; Wed, 5 Nov 2003 10:14:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPN7-0005Yr-00 for nemo@ietf.org; Wed, 05 Nov 2003 10:15:01 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AHPN6-0005Yj-00 for nemo@ietf.org; Wed, 05 Nov 2003 10:15:00 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Nov 2003 16:12:15 +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 hA5FEJo8005263; Wed, 5 Nov 2003 16:14:20 +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, 5 Nov 2003 15:14:28 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A3AF.813853E4" Subject: RE: [nemo] Nemo Basic Support - IP in IP tunneling vs NAT transversal Date: Wed, 5 Nov 2003 15:14:27 -0000 Message-ID: Thread-Topic: [nemo] Nemo Basic Support - IP in IP tunneling vs NAT transversal Thread-Index: AcOjrPLa34kgXjHYR1eErYsQdMXgcQAAhZQw From: "Pascal Thubert (pthubert)" To: "William D Ivancic" , X-OriginalArrivalTime: 05 Nov 2003 15:14:28.0726 (UTC) FILETIME=[81B56960:01C3A3AF] Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A3AF.813853E4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi William =20 Note that Doors should work with the T-Mobile IPv4 infrastructure an dtheir active filters, at least if IP-in-UDP does for IPv4 mobile tunnels. =20 Pascal -----Original Message----- From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of William D Ivancic Sent: mardi 4 novembre 2003 17:23 To: nemo@ietf.org Subject: [nemo] Nemo Basic Support - IP in IP tunneling vs NAT transversal =20 >From the basic support document page 7: " Once the binding process completes, a bi-directional tunnel is established between the Home Agent and the Mobile Router. The tunnel end points are Mobile Router's Care-of Address and the Home Agent's address. If a packet with a source address belonging to the Mobile Network Prefix is received from the Mobile Network, the Mobile Router reverse-tunnels the packet to the Home Agent through this tunnel. This reverse-tunneling is done by using IP-in-IP encapsulation [3]. " =20 In the requirements document, one of the requirements is to make sure we consider NATs. Although most may consider NATs to only exist in IPv4, I strongly suspect they will occur in IPv6 in order to manage security at a single location (rather that to increase the available address space). Thus, should we consider something like IP-in-UDP encapsulation also. I believe this is the solution for NAT transversal in IPv4. Note, this is not necessarily just a NAT issue. I was running IPv4 mobile network code (Cisco Systems IOS version) in T-Mobile's network (GPRS) with public address space. It was working until they implemented a security policy that stopped data into the T-Mobile network unless it originated from the T-Mobile network. Thus, they are not NATing, but they are administratively filtering. I believe NAT transversal code will solve this, but have not tried it yet. I was able to obtain information from T-Mobile indicating that the policy was put in place to keep excess traffic off of the GPRS network (excess traffic was being generated by Internet address searching software and worms. T-Mobile indicated that the GPRS links are considered valuable resources that need to be protected. They were unwilling to change their policy. Will =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Will Ivancic NASA Glenn Research Center 21000 Brookpark Road MS 54-5 Cleveland, Ohio 44135 Phone +1 (216)433-3494 Fax +1 (216) 433-8705 Yahoo Instant Messenger ID: ivancic http://roland.grc.nasa.gov/~ivancic ------_=_NextPart_001_01C3A3AF.813853E4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi William

 

Note that Doors should work with = the T-Mobile IPv4 infrastructure an dtheir active filters, at least if = IP-in-UDP does for IPv4 mobile tunnels.

 

Pascal

-----Original Message-----
From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On = Behalf Of William D Ivancic
Sent: mardi 4 novembre = 2003 17:23
To: nemo@ietf.org
Subject: [nemo] Nemo = Basic Support - IP in IP tunneling vs NAT transversal

 

From the basic support document page 7:

"  Once the binding process completes, a bi-directional tunnel = is
   established between the Home Agent and the Mobile = Router.  The tunnel
   end points are Mobile Router's Care-of Address and the Home Agent's
   address.  If a packet with a source address belonging = to the Mobile
   Network Prefix is received from the Mobile Network, the = Mobile Router
   reverse-tunnels the packet to the Home Agent through this = tunnel.
   This reverse-tunneling is done by using IP-in-IP = encapsulation [3].  "
 
In the requirements document, one of the requirements is to make sure we consider NATs.  Although most may consider NATs to only exist in IPv4,  I strongly suspect they will occur in IPv6 in order to = manage security at a single location (rather that to increase the available = address space).

Thus, should we consider something like IP-in-UDP encapsulation = also.  I believe this is the solution for NAT transversal in IPv4.

Note, this is not necessarily just a NAT issue.  I was = running  IPv4 mobile network code (Cisco Systems IOS version) in T-Mobile's network = (GPRS) with public address space.  It was working until they implemented a security policy that stopped data into the T-Mobile network unless it originated from the T-Mobile network.  Thus, they are not NATing, = but they are administratively filtering.  I believe NAT transversal code = will solve this, but have not tried it yet.

I was able to obtain information from T-Mobile indicating that the = policy was put in place to keep excess traffic off of the GPRS network (excess = traffic was being generated by Internet address searching software and worms.  T-Mobile indicated that the GPRS links are considered valuable resources = that need to be protected.  They were unwilling to change their = policy.

Will




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= Will Ivancic
NASA Glenn Research Center
21000 Brookpark Road    MS 54-5
Cleveland, Ohio  44135
Phone +1 (216)433-3494
Fax +1 (216) 433-8705
Yahoo Instant Messenger  ID: ivancic
http://roland.grc.nasa.gov/~ivancic

------_=_NextPart_001_01C3A3AF.813853E4-- From nemo-admin@ietf.org Wed Nov 5 11:18:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11617 for ; Wed, 5 Nov 2003 11:18: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 1AHQM5-0002vo-1a; Wed, 05 Nov 2003 11: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 1AHQLA-0002tW-5J for nemo@optimus.ietf.org; Wed, 05 Nov 2003 11: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 LAA11563 for ; Wed, 5 Nov 2003 11:16:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHQL9-0006Mv-00 for nemo@ietf.org; Wed, 05 Nov 2003 11:17:03 -0500 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1AHQL8-0006Mr-00 for nemo@ietf.org; Wed, 05 Nov 2003 11:17:02 -0500 Received: from modena.sfc.wide.ad.jp (p29f6a3.ykhmac00.ap.so-net.ne.jp [218.41.246.163]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id hA5GH04u026677 for ; Thu, 6 Nov 2003 01:17:00 +0900 Date: Thu, 06 Nov 2003 01:16:58 +0900 Message-ID: From: Koshiro MITSUYA To: nemo@ietf.org User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.4 Emacs/21.2 (i386--netbsdelf) MULE/5.0 (SAKAKI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Subject: [nemo] Dynamic Routing Protocol Operation on MR Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hello, Dose anyone have a good idea how to operate or implement Dynamic Routing Protocl Support on MR? The specification said, 7. Support for Dynamic Routing Protocols When the Mobile Router is attached to the home link, it runs a routing protocol by sending routing updates through its egress interface. When the mobile router moves and attaches to a visited network, it MUST stop sending routing updates on the interface with which it attaches to the visited link. This is very important so that IPv6 prefixes specific to the Mobile Network do not leak into the visited network. The Mobile Router then starts sending routing protocol messages through the bi-directional tunnel towards the Home Agent. Most routing protocols use link local addresses as source addresses for the routing information messages. The Mobile Router is allowed to use link local addresses for the inner IPv6 header of an encapsulated packet. But these messages after decapsulation MUST NOT be forwarded to another link by either the Mobile Router or the Home Agent. My problem is, how the routing daemon on MR stop the advertisement? how to change the advertised interface between the egress interface and bi-directional tunnel? I remember a solution (maybe Pascal said on the ML). MR has a virtual interface like vif0 which pointing the bi-directional tunnel. When MR move to foreign from home, MR change the configuration of routing daemon like eth0 to vif0 and restart the routing daemon. Is this the best way? If there is another method, please teach me. thank you, Koshiro From exim@www1.ietf.org Wed Nov 5 11:18:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11632 for ; Wed, 5 Nov 2003 11:18: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 1AHQMB-0002wp-Vc for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 11:18:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5GI7hf011325 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 11: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 1AHQMB-0002wa-RP for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 11: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 LAA11593 for ; Wed, 5 Nov 2003 11:17:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHQMB-0006NP-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 11:18:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHQMA-0006NL-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 11:18:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHQM5-0002vo-1a; Wed, 05 Nov 2003 11: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 1AHQLA-0002tW-5J for nemo@optimus.ietf.org; Wed, 05 Nov 2003 11: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 LAA11563 for ; Wed, 5 Nov 2003 11:16:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHQL9-0006Mv-00 for nemo@ietf.org; Wed, 05 Nov 2003 11:17:03 -0500 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1AHQL8-0006Mr-00 for nemo@ietf.org; Wed, 05 Nov 2003 11:17:02 -0500 Received: from modena.sfc.wide.ad.jp (p29f6a3.ykhmac00.ap.so-net.ne.jp [218.41.246.163]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id hA5GH04u026677 for ; Thu, 6 Nov 2003 01:17:00 +0900 Date: Thu, 06 Nov 2003 01:16:58 +0900 Message-ID: From: Koshiro MITSUYA To: nemo@ietf.org User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.4 Emacs/21.2 (i386--netbsdelf) MULE/5.0 (SAKAKI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Subject: [nemo] Dynamic Routing Protocol Operation on MR Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hello, Dose anyone have a good idea how to operate or implement Dynamic Routing Protocl Support on MR? The specification said, 7. Support for Dynamic Routing Protocols When the Mobile Router is attached to the home link, it runs a routing protocol by sending routing updates through its egress interface. When the mobile router moves and attaches to a visited network, it MUST stop sending routing updates on the interface with which it attaches to the visited link. This is very important so that IPv6 prefixes specific to the Mobile Network do not leak into the visited network. The Mobile Router then starts sending routing protocol messages through the bi-directional tunnel towards the Home Agent. Most routing protocols use link local addresses as source addresses for the routing information messages. The Mobile Router is allowed to use link local addresses for the inner IPv6 header of an encapsulated packet. But these messages after decapsulation MUST NOT be forwarded to another link by either the Mobile Router or the Home Agent. My problem is, how the routing daemon on MR stop the advertisement? how to change the advertised interface between the egress interface and bi-directional tunnel? I remember a solution (maybe Pascal said on the ML). MR has a virtual interface like vif0 which pointing the bi-directional tunnel. When MR move to foreign from home, MR change the configuration of routing daemon like eth0 to vif0 and restart the routing daemon. Is this the best way? If there is another method, please teach me. thank you, Koshiro From nemo-admin@ietf.org Wed Nov 5 13:21:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15811 for ; Wed, 5 Nov 2003 13:21: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 1AHSH8-00020N-Fm; Wed, 05 Nov 2003 13:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSGO-0001zU-BN for nemo@optimus.ietf.org; Wed, 05 Nov 2003 13:20: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 NAA15751 for ; Wed, 5 Nov 2003 13:20:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHSGM-0000Gb-00 for nemo@ietf.org; Wed, 05 Nov 2003 13:20:14 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AHSGL-0000GB-00 for nemo@ietf.org; Wed, 05 Nov 2003 13:20:13 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA5IJS506788; Wed, 5 Nov 2003 10:19:28 -0800 X-mProtect: <200311051819> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlHswhk; Wed, 05 Nov 2003 10:19:27 PST Message-ID: <3FA93FF0.9060608@iprg.nokia.com> Date: Wed, 05 Nov 2003 10:22:40 -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: Chan-Wah NG CC: "T.J. Kniveton" , IETF NEMO WG , Margaret Wasserman , Thomas Narten Subject: Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt References: <1068024404.6779.27.camel@localhost> In-Reply-To: <1068024404.6779.27.camel@localhost> 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 Chan-Wah NG wrote: > > Major (or Non-Minor) Issues > --------------------------- > > (1) IANA Considerations - Page 25 - Section 9 > > In addition to the mobility options type, I would think that the various > new Status values in Binding Acknowledgement need IANA considerations as > well when MIPv6 becomes an RFC, though I am not too sure what needs and > what does not need IANA considerations. good question. since Mobile IPv6 specificaction does not require IANA action for Binding Ack status values and defines them in the document itself, we assumed we should do the same. but now that the Binding Ack status values are spread over two differnt documents (and maybe more in the future), maybe IANA needs to be involved. I am not sure. I think this needs AD clarification... > (2) Is Issue 11 resolved? > > Three modes of operations were specified for NEMO operations. It was > explicitly stated that the Home Agent MUST implement all three (which > partially resolved issue 11). However, no such statement were made > about the Mobile Router. I presume it means that the Mobile Router is > free to implement any combinations of the three. According to the > Issues webpage, there seems to be a consensus on issue 11 that there > will be explicit statements specifying the mobile router implement any > one of the modes. However, I fail to find such statement in the -01 > draft. section 5.2 The Mobile Router uses one of the following modes to instruct the Home Agent to determine the prefixes owned by the Mobile Router. In all three modes, the Mobile Router sets the Mobile Router flag 'R'. > Might be also helpful to discuss which mode is better suited for > what situations. thats a rathole... :) one mode that should work in all cases, is the Explicit Network mode. > (3) ESP is a MUST? - Page 24, Sect 7 > > The last sentence of Section 7 says the "tunneled routing messages MUST > be authenticated and encrypted using IPsec ESP in tunnel mode". Even > the original MIPv6 Specs (-24) is not so strict in specifying what kind > of encryption scheme must be used to protect the BU. I think you misunderstood this. the basic support document does not require ESP tunnel encryption for Binding Updates. section 7 is about dynamic routing protocol messages. routing protocol messages from the Home Agent to the Mobile Router could potentially contain a lot of information about the internal routing structure of the home domain. simple authentication wont be enough if these messages could be observed by others. that is why the strict requirement. > Minor Editorial Issues > ----------------------- > > (1) Page 1 - Title: "Nemo Basic Support Protocol" > > I am under the assumption that it is generally considered not very good > style to use non-well-known abbreviation in I-Draft/RFC titles (well > known being limited to a very small range of abbreviations like IP, TCP, > UDP). It might be a good idea to change the title to "Network Mobility > Basic Support Protocol". I am fine with the suggestion. > On the same note, a lot of abbreviations are > used without giving their full meanings in the document, like OSPF, > RIPng, ESP, etc. Though proper end reference are given, it might be > good to expand them when they are first used, instead of forcing readers > to dig into end-references to get the fully-expanded phrase. if you are implementing NEMO, you better have heard about OSPF, RIP and ESP. :) seriously, I think they are too well known. > > (2) Page 5 - Sect 2. Terminology > > The appearance of definition of 'Prefix Table' is awkward. There is no > sentence in the preceding paragraph leading to it. Some sentences like > 'In addition, the following term is defined ... ' or the equivalence > might be necessary. > > (3) Page 11 - Sect 4.3 Mobile Network Prefix Option > > It might be better to change 'contains' to 'containing' to be consistent > with the use of continuous tense in the descriptions of other fields. > > (4) Page 11 - Sect 4.4 Mobile Network Prefix Length Option > > 2nd Paragraph: 'The Mobile Network Option cannot be present ...' > Perhaps we should use the stronger phrase of 'MUST NOT' instead, since > RFC2119 does not contain the term 'cannot'. > > (5) Page 14 - Sect 5.3 Recieving Binding Acknoweldgement > > The last line of the page, a space after the period '.' is missing. > --> '... Network.The ...' > > (6) Page 19 - Sect 6.2 > > The first bullet of the second paragraph, 3rd line, '... MUST be an > Home Address ...'. > 'an' --> 'a'? > > (7) Page 22 - Sect 6.6 > > The first paragraph, '.. same rules it uses for sending Binding > Acknowledgment to Mobile Hosts, ...' : Perhaps a reference to [1] will > be nice to explicitly define what those 'same rules' are? > > (8) Page 23 - Sect 7 > > 1st paragraph, 4th line, ' ... to run a intra-domain ...' > 'a' -> 'an'? > > (9) Page 7 - Sect 1 > > 2nd paragraph on Page 7, the abbreviation 'HA' is first used without > explanation. In most part of the document, the full term 'Home Agent' > is used, with occasional use of 'HA' popping up. I suggest searching > through the document and replace 'HA' with 'Home Agent' for coherence > and consistence. > > (10) Page 25 - Sect 8 > > The 5th line in the 2nd paragraph: "The source address of the outer IPv6 > header MUST be set the Mobile Router's ..." should read "... MUST be set > to the ...". Continuing from this line, "... MUST belong to the Mobile > Network Prefix owned by the Mobile Router" suggest only one prefix can > be owned by a mobile router. It should perhaps be changed to "... MUST > belong to one of the Mobile Network Prefix(es) owned ...". > > (11) Page 25 - Sect 9 > > A period is missing in the last sentence of Sect 9. > > (12) Page 17 - Sect 5.5 > > Last sentence in this section is a 'See [3].' Should be changed to a > better formulated sentence, such as 'Please refer to [3] for more > details' or something like that. > > (13) Page 20 - Sect 6.2 > > Pardon my poor command of English, but the second last paragraph of Sect > 6.2 is difficult to read. I suspect the word 'like' in "... by > multicasting onto the home like a Neighbor ..." is mis-typed (my guess > is the correct word is 'link', but I am not too sure because the way the > sentence was structured). In addition, the 2nd sentence in the same > paragraph begins with "All fields in each such Neighbor Advertisement > ..." , in my humble opinion, should read "... every such ...". > Furthermore, this is one of the rare paragraphs in the whole document > where "mobile router" is not first-letter-captitalized. > > (14) Clarifications on Sect 5.6. > > It was unclear to me on the first few reads that the first paragraph > refer to the behaviour when the mobile router is at home, and the next > paragraphs refer to the behaviour when mobile router is away. Perhaps > some annotation or opening phrases like 'When the Mobile Router is at > home, ...' and 'When the Mobile Router is away, ...' should precede > paragraph 1 and paragraph 2 respectively. thanks for catching all these. Vijay From exim@www1.ietf.org Wed Nov 5 13:21:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15826 for ; Wed, 5 Nov 2003 13:21: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 1AHSHE-00021S-TD for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 13:21:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5IL8RH007768 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 13:21:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSHE-00021D-L9 for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 13:21: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 NAA15796 for ; Wed, 5 Nov 2003 13:20:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHSHC-0000H9-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 13:21:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHSHC-0000H6-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 13:21:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSH8-00020N-Fm; Wed, 05 Nov 2003 13:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSGO-0001zU-BN for nemo@optimus.ietf.org; Wed, 05 Nov 2003 13:20: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 NAA15751 for ; Wed, 5 Nov 2003 13:20:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHSGM-0000Gb-00 for nemo@ietf.org; Wed, 05 Nov 2003 13:20:14 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AHSGL-0000GB-00 for nemo@ietf.org; Wed, 05 Nov 2003 13:20:13 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA5IJS506788; Wed, 5 Nov 2003 10:19:28 -0800 X-mProtect: <200311051819> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlHswhk; Wed, 05 Nov 2003 10:19:27 PST Message-ID: <3FA93FF0.9060608@iprg.nokia.com> Date: Wed, 05 Nov 2003 10:22:40 -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: Chan-Wah NG CC: "T.J. Kniveton" , IETF NEMO WG , Margaret Wasserman , Thomas Narten Subject: Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt References: <1068024404.6779.27.camel@localhost> In-Reply-To: <1068024404.6779.27.camel@localhost> 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 Chan-Wah NG wrote: > > Major (or Non-Minor) Issues > --------------------------- > > (1) IANA Considerations - Page 25 - Section 9 > > In addition to the mobility options type, I would think that the various > new Status values in Binding Acknowledgement need IANA considerations as > well when MIPv6 becomes an RFC, though I am not too sure what needs and > what does not need IANA considerations. good question. since Mobile IPv6 specificaction does not require IANA action for Binding Ack status values and defines them in the document itself, we assumed we should do the same. but now that the Binding Ack status values are spread over two differnt documents (and maybe more in the future), maybe IANA needs to be involved. I am not sure. I think this needs AD clarification... > (2) Is Issue 11 resolved? > > Three modes of operations were specified for NEMO operations. It was > explicitly stated that the Home Agent MUST implement all three (which > partially resolved issue 11). However, no such statement were made > about the Mobile Router. I presume it means that the Mobile Router is > free to implement any combinations of the three. According to the > Issues webpage, there seems to be a consensus on issue 11 that there > will be explicit statements specifying the mobile router implement any > one of the modes. However, I fail to find such statement in the -01 > draft. section 5.2 The Mobile Router uses one of the following modes to instruct the Home Agent to determine the prefixes owned by the Mobile Router. In all three modes, the Mobile Router sets the Mobile Router flag 'R'. > Might be also helpful to discuss which mode is better suited for > what situations. thats a rathole... :) one mode that should work in all cases, is the Explicit Network mode. > (3) ESP is a MUST? - Page 24, Sect 7 > > The last sentence of Section 7 says the "tunneled routing messages MUST > be authenticated and encrypted using IPsec ESP in tunnel mode". Even > the original MIPv6 Specs (-24) is not so strict in specifying what kind > of encryption scheme must be used to protect the BU. I think you misunderstood this. the basic support document does not require ESP tunnel encryption for Binding Updates. section 7 is about dynamic routing protocol messages. routing protocol messages from the Home Agent to the Mobile Router could potentially contain a lot of information about the internal routing structure of the home domain. simple authentication wont be enough if these messages could be observed by others. that is why the strict requirement. > Minor Editorial Issues > ----------------------- > > (1) Page 1 - Title: "Nemo Basic Support Protocol" > > I am under the assumption that it is generally considered not very good > style to use non-well-known abbreviation in I-Draft/RFC titles (well > known being limited to a very small range of abbreviations like IP, TCP, > UDP). It might be a good idea to change the title to "Network Mobility > Basic Support Protocol". I am fine with the suggestion. > On the same note, a lot of abbreviations are > used without giving their full meanings in the document, like OSPF, > RIPng, ESP, etc. Though proper end reference are given, it might be > good to expand them when they are first used, instead of forcing readers > to dig into end-references to get the fully-expanded phrase. if you are implementing NEMO, you better have heard about OSPF, RIP and ESP. :) seriously, I think they are too well known. > > (2) Page 5 - Sect 2. Terminology > > The appearance of definition of 'Prefix Table' is awkward. There is no > sentence in the preceding paragraph leading to it. Some sentences like > 'In addition, the following term is defined ... ' or the equivalence > might be necessary. > > (3) Page 11 - Sect 4.3 Mobile Network Prefix Option > > It might be better to change 'contains' to 'containing' to be consistent > with the use of continuous tense in the descriptions of other fields. > > (4) Page 11 - Sect 4.4 Mobile Network Prefix Length Option > > 2nd Paragraph: 'The Mobile Network Option cannot be present ...' > Perhaps we should use the stronger phrase of 'MUST NOT' instead, since > RFC2119 does not contain the term 'cannot'. > > (5) Page 14 - Sect 5.3 Recieving Binding Acknoweldgement > > The last line of the page, a space after the period '.' is missing. > --> '... Network.The ...' > > (6) Page 19 - Sect 6.2 > > The first bullet of the second paragraph, 3rd line, '... MUST be an > Home Address ...'. > 'an' --> 'a'? > > (7) Page 22 - Sect 6.6 > > The first paragraph, '.. same rules it uses for sending Binding > Acknowledgment to Mobile Hosts, ...' : Perhaps a reference to [1] will > be nice to explicitly define what those 'same rules' are? > > (8) Page 23 - Sect 7 > > 1st paragraph, 4th line, ' ... to run a intra-domain ...' > 'a' -> 'an'? > > (9) Page 7 - Sect 1 > > 2nd paragraph on Page 7, the abbreviation 'HA' is first used without > explanation. In most part of the document, the full term 'Home Agent' > is used, with occasional use of 'HA' popping up. I suggest searching > through the document and replace 'HA' with 'Home Agent' for coherence > and consistence. > > (10) Page 25 - Sect 8 > > The 5th line in the 2nd paragraph: "The source address of the outer IPv6 > header MUST be set the Mobile Router's ..." should read "... MUST be set > to the ...". Continuing from this line, "... MUST belong to the Mobile > Network Prefix owned by the Mobile Router" suggest only one prefix can > be owned by a mobile router. It should perhaps be changed to "... MUST > belong to one of the Mobile Network Prefix(es) owned ...". > > (11) Page 25 - Sect 9 > > A period is missing in the last sentence of Sect 9. > > (12) Page 17 - Sect 5.5 > > Last sentence in this section is a 'See [3].' Should be changed to a > better formulated sentence, such as 'Please refer to [3] for more > details' or something like that. > > (13) Page 20 - Sect 6.2 > > Pardon my poor command of English, but the second last paragraph of Sect > 6.2 is difficult to read. I suspect the word 'like' in "... by > multicasting onto the home like a Neighbor ..." is mis-typed (my guess > is the correct word is 'link', but I am not too sure because the way the > sentence was structured). In addition, the 2nd sentence in the same > paragraph begins with "All fields in each such Neighbor Advertisement > ..." , in my humble opinion, should read "... every such ...". > Furthermore, this is one of the rare paragraphs in the whole document > where "mobile router" is not first-letter-captitalized. > > (14) Clarifications on Sect 5.6. > > It was unclear to me on the first few reads that the first paragraph > refer to the behaviour when the mobile router is at home, and the next > paragraphs refer to the behaviour when mobile router is away. Perhaps > some annotation or opening phrases like 'When the Mobile Router is at > home, ...' and 'When the Mobile Router is away, ...' should precede > paragraph 1 and paragraph 2 respectively. thanks for catching all these. Vijay From nemo-admin@ietf.org Wed Nov 5 14:12:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17736 for ; Wed, 5 Nov 2003 14: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 1AHT4U-0005K0-Is; Wed, 05 Nov 2003 14: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 1AHT4H-0005IF-B9 for nemo@optimus.ietf.org; Wed, 05 Nov 2003 14:11: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 OAA17699 for ; Wed, 5 Nov 2003 14:11:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHT4E-0000z3-00 for nemo@ietf.org; Wed, 05 Nov 2003 14:11:46 -0500 Received: from smtp-out4.blueyonder.co.uk ([195.188.213.7]) by ietf-mx with esmtp (Exim 4.12) id 1AHT4E-0000z0-00 for nemo@ietf.org; Wed, 05 Nov 2003 14:11:46 -0500 Received: from blackbox ([82.41.207.218]) by smtp-out4.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.5600); Wed, 5 Nov 2003 19:11:47 +0000 To: nemo@ietf.org Subject: Re: [NEMO] Behavior of HA From: cam Organization: none Content-Type: text/plain; format=flowed; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Wed, 05 Nov 2003 19:11:37 -0000 Message-ID: User-Agent: Opera7.21/Win32 M2 build 3218 X-OriginalArrivalTime: 05 Nov 2003 19:11:47.0954 (UTC) FILETIME=[A8F32D20:01C3A3D0] 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 On Wed, 05 Nov 2003 12:22:04 +0000, MATSUMOTO Taisuke wrote: > I'm trying to implement the NEMO protocol stack, and I find a problem. > > I set up my test network according to the figure 1 in the basic support > draft page 28. See below. > > +-------------------+ 3:: 2+-------+ > | Internet |------| CN_MR | > +-------------------+ +-------+ > 4:: | > | > 2+-------------+3 > +--+-+ +---+---+ > | MR | | HA_MR | > +--+-+ +-------+ > 5:: |1 > ---------- > 2| +--+-+ > | LFN| > +--+-+>> > > I tried to run the MR in the explicit prefix length mode. When the > mobile router was attached to the foreign link, the MR tried to send the > binding update message which consists of '5::1' for the home address and > '64' for the prefix length. > > But the HA rejected that BU message and returned the BA message with the > status code 132. This behavior is defined in the section 10.3.1 of the > mobile IPv6 draft, draft-ietf-mobileip-ipv6-24.txt. > > > The explicit prefix length mode uses the IP address of the ingress > interface as the home address of the mobile router. In this case, the IP > address of the ingress interface is not an on-link IP address of the HA. As a side issue, am I right in saying that the assumption for Explicit Prefix Length Mode is that the Home Address is the address on the MR's ingress interface? This is something that confused me when I recently read the NEMO spec. I had thought, as with MIPv6, that the Home Address would be the address on the egress interface and so, couldn't see how the prefix could be obtained from the Home Address. Should the spec make this clear? Cheers, cam -- cam@blueyonder.co.uk From exim@www1.ietf.org Wed Nov 5 14:12:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17754 for ; Wed, 5 Nov 2003 14:12: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 1AHT4X-0005L0-0v for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 14:12:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5JC48u020512 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 14:12:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHT4W-0005Kl-TT for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 14: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 OAA17711 for ; Wed, 5 Nov 2003 14:11:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHT4U-0000zP-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 14:12:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHT4U-0000zI-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 14: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 1AHT4U-0005K0-Is; Wed, 05 Nov 2003 14: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 1AHT4H-0005IF-B9 for nemo@optimus.ietf.org; Wed, 05 Nov 2003 14:11: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 OAA17699 for ; Wed, 5 Nov 2003 14:11:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHT4E-0000z3-00 for nemo@ietf.org; Wed, 05 Nov 2003 14:11:46 -0500 Received: from smtp-out4.blueyonder.co.uk ([195.188.213.7]) by ietf-mx with esmtp (Exim 4.12) id 1AHT4E-0000z0-00 for nemo@ietf.org; Wed, 05 Nov 2003 14:11:46 -0500 Received: from blackbox ([82.41.207.218]) by smtp-out4.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.5600); Wed, 5 Nov 2003 19:11:47 +0000 To: nemo@ietf.org Subject: Re: [NEMO] Behavior of HA From: cam Organization: none Content-Type: text/plain; format=flowed; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Wed, 05 Nov 2003 19:11:37 -0000 Message-ID: User-Agent: Opera7.21/Win32 M2 build 3218 X-OriginalArrivalTime: 05 Nov 2003 19:11:47.0954 (UTC) FILETIME=[A8F32D20:01C3A3D0] 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 On Wed, 05 Nov 2003 12:22:04 +0000, MATSUMOTO Taisuke wrote: > I'm trying to implement the NEMO protocol stack, and I find a problem. > > I set up my test network according to the figure 1 in the basic support > draft page 28. See below. > > +-------------------+ 3:: 2+-------+ > | Internet |------| CN_MR | > +-------------------+ +-------+ > 4:: | > | > 2+-------------+3 > +--+-+ +---+---+ > | MR | | HA_MR | > +--+-+ +-------+ > 5:: |1 > ---------- > 2| +--+-+ > | LFN| > +--+-+>> > > I tried to run the MR in the explicit prefix length mode. When the > mobile router was attached to the foreign link, the MR tried to send the > binding update message which consists of '5::1' for the home address and > '64' for the prefix length. > > But the HA rejected that BU message and returned the BA message with the > status code 132. This behavior is defined in the section 10.3.1 of the > mobile IPv6 draft, draft-ietf-mobileip-ipv6-24.txt. > > > The explicit prefix length mode uses the IP address of the ingress > interface as the home address of the mobile router. In this case, the IP > address of the ingress interface is not an on-link IP address of the HA. As a side issue, am I right in saying that the assumption for Explicit Prefix Length Mode is that the Home Address is the address on the MR's ingress interface? This is something that confused me when I recently read the NEMO spec. I had thought, as with MIPv6, that the Home Address would be the address on the egress interface and so, couldn't see how the prefix could be obtained from the Home Address. Should the spec make this clear? Cheers, cam -- cam@blueyonder.co.uk From nemo-admin@ietf.org Wed Nov 5 14:59:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20546 for ; Wed, 5 Nov 2003 14:59: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 1AHTnx-0001Oa-9T; Wed, 05 Nov 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 1AHTn5-0001Ms-QU for nemo@optimus.ietf.org; Wed, 05 Nov 2003 14:58: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 OAA20493 for ; Wed, 5 Nov 2003 14:57:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTn2-000288-00 for nemo@ietf.org; Wed, 05 Nov 2003 14:58:04 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AHTn2-00027h-00 for nemo@ietf.org; Wed, 05 Nov 2003 14:58:04 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA5JvUD21728; Wed, 5 Nov 2003 11:57:30 -0800 X-mProtect: <200311051957> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2Ic1IC; Wed, 05 Nov 2003 11:57:29 PST Message-ID: <3FA956EB.9020307@iprg.nokia.com> Date: Wed, 05 Nov 2003 12:00:43 -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: cam CC: nemo@ietf.org Subject: Re: [NEMO] Behavior of HA 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 cam wrote: > > As a side issue, am I right in saying that the assumption for Explicit > Prefix Length Mode is that the Home Address is the address on the MR's > ingress interface? yes. > This is something that confused me when I recently > read the NEMO spec. I had thought, as with MIPv6, that the Home Address > would be the address on the egress interface Nemo relaxes this. the Home Address can be assigned to any interface (even a virtual interface). and so, couldn't see how > the prefix could be obtained from the Home Address. > > Should the spec make this clear? section 3 contains A Mobile Router has an unique Home Address through which it is always reachable. The Home Address is configured from a prefix that is aggregated and advertised by its Home Agent. The prefix could either be the prefix advertised on the home link or the prefix delegated to the Mobile Router. The Mobile Router can have more than one Home Address if there are multiple prefixes in the home link. what clarification are you looking for? Vijay From exim@www1.ietf.org Wed Nov 5 14:59:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20576 for ; Wed, 5 Nov 2003 14: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 1AHTo0-0001QI-BO for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 14:59:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Jx4nD005464 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 14:59:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTo0-0001Q3-6o for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 14:59: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 OAA20531 for ; Wed, 5 Nov 2003 14:58:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTnx-0002A2-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 14:59:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHTnx-00029z-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 14:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTnx-0001Oa-9T; Wed, 05 Nov 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 1AHTn5-0001Ms-QU for nemo@optimus.ietf.org; Wed, 05 Nov 2003 14:58: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 OAA20493 for ; Wed, 5 Nov 2003 14:57:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTn2-000288-00 for nemo@ietf.org; Wed, 05 Nov 2003 14:58:04 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AHTn2-00027h-00 for nemo@ietf.org; Wed, 05 Nov 2003 14:58:04 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA5JvUD21728; Wed, 5 Nov 2003 11:57:30 -0800 X-mProtect: <200311051957> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2Ic1IC; Wed, 05 Nov 2003 11:57:29 PST Message-ID: <3FA956EB.9020307@iprg.nokia.com> Date: Wed, 05 Nov 2003 12:00:43 -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: cam CC: nemo@ietf.org Subject: Re: [NEMO] Behavior of HA 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 cam wrote: > > As a side issue, am I right in saying that the assumption for Explicit > Prefix Length Mode is that the Home Address is the address on the MR's > ingress interface? yes. > This is something that confused me when I recently > read the NEMO spec. I had thought, as with MIPv6, that the Home Address > would be the address on the egress interface Nemo relaxes this. the Home Address can be assigned to any interface (even a virtual interface). and so, couldn't see how > the prefix could be obtained from the Home Address. > > Should the spec make this clear? section 3 contains A Mobile Router has an unique Home Address through which it is always reachable. The Home Address is configured from a prefix that is aggregated and advertised by its Home Agent. The prefix could either be the prefix advertised on the home link or the prefix delegated to the Mobile Router. The Mobile Router can have more than one Home Address if there are multiple prefixes in the home link. what clarification are you looking for? Vijay From nemo-admin@ietf.org Wed Nov 5 15:06:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21117 for ; Wed, 5 Nov 2003 15:06: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 1AHTuj-0001yw-5p; Wed, 05 Nov 2003 15: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 1AHTu0-0001yL-Vi for nemo@optimus.ietf.org; Wed, 05 Nov 2003 15:05: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 PAA20971 for ; Wed, 5 Nov 2003 15:05:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTtx-0002H4-00 for nemo@ietf.org; Wed, 05 Nov 2003 15:05:14 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AHTtx-0002Go-00 for nemo@ietf.org; Wed, 05 Nov 2003 15:05:13 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA5K4aR29058; Wed, 5 Nov 2003 12:04:36 -0800 X-mProtect: <200311052004> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdECgYi2; Wed, 05 Nov 2003 12:04:35 PST Message-ID: <3FA95896.7010002@iprg.nokia.com> Date: Wed, 05 Nov 2003 12:07:50 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MATSUMOTO Taisuke CC: nemo@ietf.org Subject: Re: [nemo] Behavior of HA References: <200311051221.hA5CLh2t075968@mrit.mrit.mei.co.jp> In-Reply-To: <200311051221.hA5CLh2t075968@mrit.mrit.mei.co.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 hi, thanks for catching this. MATSUMOTO Taisuke wrote: > Dear NEMO WG members, > > I'm trying to implement the NEMO protocol stack, and I find a > problem. > > I set up my test network according to the figure 1 in the basic > support draft page 28. See below. > > +-------------------+ 3:: 2+-------+ > | Internet |------| CN_MR | > +-------------------+ +-------+ > 4:: | > | > 2+-------------+3 > +--+-+ +---+---+ > | MR | | HA_MR | > +--+-+ +-------+ > 5:: |1 > ---------- > 2| > +--+-+ > | LFN| > +--+-+ > > I tried to run the MR in the explicit prefix length mode. When > the mobile router was attached to the foreign link, the MR tried > to send the binding update message which consists of '5::1' for > the home address and '64' for the prefix length. > > But the HA rejected that BU message and returned the BA message > with the status code 132. This behavior is defined in the section > 10.3.1 of the mobile IPv6 draft, draft-ietf-mobileip-ipv6-24.txt. > > The explicit prefix length mode uses the IP address of the ingress > interface as the home address of the mobile router. In this case, > the IP address of the ingress interface is not an on-link IP > address of the HA. > > So, I think that some schemes to avoid that restriction of the > mobile IPv6 specifications is required for the NEMO basic support. yes. the mobile IPv6 restriction needs to be relaxed. currently section 10.3.1 of MIPv6 says if the home address for the binding (the Home Address field in the packet's Home Address option) is not an on-link IPv6 address with respect to the home agent's current Prefix List, then the home agent MUST reject the Binding Update and SHOULD return a Binding Acknowledgement to the mobile node, in which the Status field is set to 132 (not home subnet). for Nemo, the Home Agent should not reject the Binding if the home address is from a prefix that has been delegated to a Mobile Router. comments? Vijay From exim@www1.ietf.org Wed Nov 5 15:06:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21134 for ; Wed, 5 Nov 2003 15:06: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 1AHTuk-000200-D5 for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 15:06:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5K62BA007678 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 15: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 1AHTuk-0001zl-6K for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 15:06: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 PAA21059 for ; Wed, 5 Nov 2003 15:05:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTuh-0002Hi-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 15:05:59 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHTug-0002Hf-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 15:05:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTuj-0001yw-5p; Wed, 05 Nov 2003 15: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 1AHTu0-0001yL-Vi for nemo@optimus.ietf.org; Wed, 05 Nov 2003 15:05: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 PAA20971 for ; Wed, 5 Nov 2003 15:05:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTtx-0002H4-00 for nemo@ietf.org; Wed, 05 Nov 2003 15:05:14 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AHTtx-0002Go-00 for nemo@ietf.org; Wed, 05 Nov 2003 15:05:13 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA5K4aR29058; Wed, 5 Nov 2003 12:04:36 -0800 X-mProtect: <200311052004> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdECgYi2; Wed, 05 Nov 2003 12:04:35 PST Message-ID: <3FA95896.7010002@iprg.nokia.com> Date: Wed, 05 Nov 2003 12:07:50 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MATSUMOTO Taisuke CC: nemo@ietf.org Subject: Re: [nemo] Behavior of HA References: <200311051221.hA5CLh2t075968@mrit.mrit.mei.co.jp> In-Reply-To: <200311051221.hA5CLh2t075968@mrit.mrit.mei.co.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 hi, thanks for catching this. MATSUMOTO Taisuke wrote: > Dear NEMO WG members, > > I'm trying to implement the NEMO protocol stack, and I find a > problem. > > I set up my test network according to the figure 1 in the basic > support draft page 28. See below. > > +-------------------+ 3:: 2+-------+ > | Internet |------| CN_MR | > +-------------------+ +-------+ > 4:: | > | > 2+-------------+3 > +--+-+ +---+---+ > | MR | | HA_MR | > +--+-+ +-------+ > 5:: |1 > ---------- > 2| > +--+-+ > | LFN| > +--+-+ > > I tried to run the MR in the explicit prefix length mode. When > the mobile router was attached to the foreign link, the MR tried > to send the binding update message which consists of '5::1' for > the home address and '64' for the prefix length. > > But the HA rejected that BU message and returned the BA message > with the status code 132. This behavior is defined in the section > 10.3.1 of the mobile IPv6 draft, draft-ietf-mobileip-ipv6-24.txt. > > The explicit prefix length mode uses the IP address of the ingress > interface as the home address of the mobile router. In this case, > the IP address of the ingress interface is not an on-link IP > address of the HA. > > So, I think that some schemes to avoid that restriction of the > mobile IPv6 specifications is required for the NEMO basic support. yes. the mobile IPv6 restriction needs to be relaxed. currently section 10.3.1 of MIPv6 says if the home address for the binding (the Home Address field in the packet's Home Address option) is not an on-link IPv6 address with respect to the home agent's current Prefix List, then the home agent MUST reject the Binding Update and SHOULD return a Binding Acknowledgement to the mobile node, in which the Status field is set to 132 (not home subnet). for Nemo, the Home Agent should not reject the Binding if the home address is from a prefix that has been delegated to a Mobile Router. comments? Vijay From nemo-admin@ietf.org Wed Nov 5 16:24:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24498 for ; Wed, 5 Nov 2003 16:24:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV8H-0005JQ-K1; Wed, 05 Nov 2003 16:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHU4k-0002jy-IO for nemo@optimus.ietf.org; Wed, 05 Nov 2003 15:16: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 PAA22162 for ; Wed, 5 Nov 2003 15:16:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHU4j-0002Qb-00 for nemo@ietf.org; Wed, 05 Nov 2003 15:16:21 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AHU4i-0002QY-00 for nemo@ietf.org; Wed, 05 Nov 2003 15:16:20 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA5KFlO09222; Wed, 5 Nov 2003 12:15:47 -0800 X-mProtect: <200311052015> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTxAM5a; Wed, 05 Nov 2003 12:15:46 PST Message-ID: <3FA95B34.2070301@iprg.nokia.com> Date: Wed, 05 Nov 2003 12:19: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: Koshiro MITSUYA CC: nemo@ietf.org Subject: Re: [nemo] Dynamic Routing Protocol Operation on MR 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 Koshiro MITSUYA wrote: > Hello, > > Dose anyone have a good idea how to operate or implement Dynamic > Routing Protocl Support on MR? > > > The specification said, > > 7. Support for Dynamic Routing Protocols > > > > When the Mobile Router is attached to the home link, it runs a > routing protocol by sending routing updates through its egress > interface. When the mobile router moves and attaches to a visited > network, it MUST stop sending routing updates on the interface with > which it attaches to the visited link. This is very important so > that IPv6 prefixes specific to the Mobile Network do not leak into > the visited network. The Mobile Router then starts sending routing > protocol messages through the bi-directional tunnel towards the Home > Agent. Most routing protocols use link local addresses as source > addresses for the routing information messages. The Mobile Router is > allowed to use link local addresses for the inner IPv6 header of an > encapsulated packet. But these messages after decapsulation MUST NOT > be forwarded to another link by either the Mobile Router or the Home > Agent. > > > > My problem is, how the routing daemon on MR stop the advertisement? > how to change the advertised interface between the egress interface > and bi-directional tunnel? > > I remember a solution (maybe Pascal said on the ML). MR has a virtual > interface like vif0 which pointing the bi-directional tunnel. When MR > move to foreign from home, MR change the configuration of routing > daemon like eth0 to vif0 and restart the routing daemon. > > Is this the best way? If there is another method, please teach me. it is totally implementation dependent. in some implementations there is one instance of routing protocol per interface. in this case, it is matter of stopping the instance on the egress interface and starting it for the tunnel interface. Vijay From exim@www1.ietf.org Wed Nov 5 16:24:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24590 for ; Wed, 5 Nov 2003 16:24:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV8e-0005ew-Kp for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 16:24:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5LOS8E021744 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 16:24:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV8e-0005eY-Cm for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 16:24: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 QAA24353 for ; Wed, 5 Nov 2003 16:24:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHV8c-0003aF-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 16:24:26 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHV8c-0003ZC-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 16:24:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV8H-0005JQ-K1; Wed, 05 Nov 2003 16:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHU4k-0002jy-IO for nemo@optimus.ietf.org; Wed, 05 Nov 2003 15:16: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 PAA22162 for ; Wed, 5 Nov 2003 15:16:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHU4j-0002Qb-00 for nemo@ietf.org; Wed, 05 Nov 2003 15:16:21 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AHU4i-0002QY-00 for nemo@ietf.org; Wed, 05 Nov 2003 15:16:20 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA5KFlO09222; Wed, 5 Nov 2003 12:15:47 -0800 X-mProtect: <200311052015> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTxAM5a; Wed, 05 Nov 2003 12:15:46 PST Message-ID: <3FA95B34.2070301@iprg.nokia.com> Date: Wed, 05 Nov 2003 12:19: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: Koshiro MITSUYA CC: nemo@ietf.org Subject: Re: [nemo] Dynamic Routing Protocol Operation on MR 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 Koshiro MITSUYA wrote: > Hello, > > Dose anyone have a good idea how to operate or implement Dynamic > Routing Protocl Support on MR? > > > The specification said, > > 7. Support for Dynamic Routing Protocols > > > > When the Mobile Router is attached to the home link, it runs a > routing protocol by sending routing updates through its egress > interface. When the mobile router moves and attaches to a visited > network, it MUST stop sending routing updates on the interface with > which it attaches to the visited link. This is very important so > that IPv6 prefixes specific to the Mobile Network do not leak into > the visited network. The Mobile Router then starts sending routing > protocol messages through the bi-directional tunnel towards the Home > Agent. Most routing protocols use link local addresses as source > addresses for the routing information messages. The Mobile Router is > allowed to use link local addresses for the inner IPv6 header of an > encapsulated packet. But these messages after decapsulation MUST NOT > be forwarded to another link by either the Mobile Router or the Home > Agent. > > > > My problem is, how the routing daemon on MR stop the advertisement? > how to change the advertised interface between the egress interface > and bi-directional tunnel? > > I remember a solution (maybe Pascal said on the ML). MR has a virtual > interface like vif0 which pointing the bi-directional tunnel. When MR > move to foreign from home, MR change the configuration of routing > daemon like eth0 to vif0 and restart the routing daemon. > > Is this the best way? If there is another method, please teach me. it is totally implementation dependent. in some implementations there is one instance of routing protocol per interface. in this case, it is matter of stopping the instance on the egress interface and starting it for the tunnel interface. Vijay From nemo-admin@ietf.org Wed Nov 5 18:24:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00566 for ; Wed, 5 Nov 2003 18:24: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 1AHX0M-0004Yp-CN; Wed, 05 Nov 2003 18: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 1AHWzd-0004Y2-JK for nemo@optimus.ietf.org; Wed, 05 Nov 2003 18:23: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 SAA00535 for ; Wed, 5 Nov 2003 18:23:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHWza-0005Yp-00 for nemo@ietf.org; Wed, 05 Nov 2003 18:23:14 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AHWza-0005Ym-00 for nemo@ietf.org; Wed, 05 Nov 2003 18:23:14 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hA5NNDKD023206; Wed, 5 Nov 2003 16:23:13 -0700 (MST) Received: from motorola.com ([163.14.20.31]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hA5NMtAY008282; Wed, 5 Nov 2003 17:23:00 -0600 Message-ID: <3FA9864C.3090804@motorola.com> Date: Thu, 06 Nov 2003 00:22: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: Vijay Devarapalli CC: Koshiro MITSUYA , nemo@ietf.org Subject: Re: [nemo] Dynamic Routing Protocol Operation on MR References: <3FA95B34.2070301@iprg.nokia.com> In-Reply-To: <3FA95B34.2070301@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: > Koshiro MITSUYA wrote: > >> Hello, >> >> Dose anyone have a good idea how to operate or implement Dynamic >> Routing Protocl Support on MR? Ideas plenty, but what you call a good idea... >> The specification said, 7. Support for Dynamic Routing Protocols >> >> >> >> When the Mobile Router is attached to the home link, it runs a >> routing protocol by sending routing updates through its egress >> interface. When the mobile router moves and attaches to a visited >> network, it MUST stop sending routing updates on the interface with >> which it attaches to the visited link. This is very important so >> that IPv6 prefixes specific to the Mobile Network do not leak into >> the visited network. The Mobile Router then starts sending routing >> protocol messages through the bi-directional tunnel towards the >> Home Agent. Most routing protocols use link local addresses as >> source addresses for the routing information messages. The Mobile >> Router is allowed to use link local addresses for the inner IPv6 >> header of an encapsulated packet. But these messages after >> decapsulation MUST NOT be forwarded to another link by either the >> Mobile Router or the Home Agent. >> >> >> >> My problem is, how the routing daemon on MR stop the advertisement? >> how to change the advertised interface between the egress >> interface and bi-directional tunnel? >> >> I remember a solution (maybe Pascal said on the ML). MR has a >> virtual interface like vif0 which pointing the bi-directional >> tunnel. When MR move to foreign from home, MR change the >> configuration of routing daemon like eth0 to vif0 and restart the >> routing daemon. Re-starting the routing daemon? What happens to all entries that existed in the app-level rt table entries when the MR was at home? They get lost when the MR moves away from home and re-get introduced when the MR talks back to the HA? >> Is this the best way? If there is another method, please teach me. > > it is totally implementation dependent. it is more or less implementation dependent. > in some implementations there is one instance of routing protocol per > interface. in this case, it is matter of stopping the instance on > the egress interface and starting it for the tunnel interface. It is hardly doable to stop and start that instance, when this trigger supposedly comes from the kernel space (where stacks run traditionally) to the userland (where rt daemons run traditionally). A possible way to implement dynamic routing protocol over the MR-HA tunnel is not to have the bidir tunnel as an interface (virtual or other). Instead, the encapsulation happens according to searches in the rt table and in the bc. When HA routes a packet towards MR, it searches a corresponding entry in its bc and if found then encapsulate. This logic does not apply similarly at the MR of course since that hasn't a bc. So the MR needs to 'flag' its entries in its rt that correspond to the real interface that connects to the home link, (named egress interface, or name it mobile interface). When MR moves away from home, it moves all its rt entries corresponding to its mobile interface to a new table. Modify the kernel ctls that are called by the rt daemon such as instead of reading/writing in the normal rt table, r/w into this new table, when referring to that interface. In this way, the rt protocol instance runs as before, over the same interface visible in the userspace. But it magically maintains the kernel routes in this new table instead of in the normal kernel rt table. This also allows for the same rt protocol application to run another instance over the egress interface but directly towards the access system, since the relevant entries for home were declared when it moved. Routing interactions with the access system are not addressed by NEMO (but in other contexts this _is_ interesting, for example look at OSPF wireless interfaces). Now there was a sort of discussion about dynamic rt protocol over the MR-HA tunnel very early in the DT, together with indications about how we (Mot) did it late last year. I would qualify that discussion as public and non IPR'ed only if the NEMO WG considers that the NEMO basic solution should be non-IPR'ed; if the NEMO WG considers that the basic NEMO solution could be IPR'ed - a plausible reason I could imagine to see being that NEMO would in itself be not a "base" but rather an "extension" of Mobile IPv6, and with the attached IETF licensing scheme, open source licensing, RAND and such - then I qualify that DT discussion as secret and our source code also as secret and very difficult to discuss about until my employer gets a publicly-visible patent (read visible w/o a fee on the uspto site, even though EU and JP patents show to paying subscribers in other places earlier) for it as well as an IETF IPR declaration along the lines of rfc2026 and along the lines of what the IPR WG currently suggests. Alex GBU From exim@www1.ietf.org Wed Nov 5 18:24:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00584 for ; Wed, 5 Nov 2003 18:24: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 1AHX0Q-0004Zn-GS for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 18:24:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5NO6vx017585 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 18:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHX0Q-0004ZY-6P for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 18:24: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 SAA00539 for ; Wed, 5 Nov 2003 18:23:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHX0N-0005Yw-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 18:24:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHX0M-0005Yt-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 18:24:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHX0M-0004Yp-CN; Wed, 05 Nov 2003 18: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 1AHWzd-0004Y2-JK for nemo@optimus.ietf.org; Wed, 05 Nov 2003 18:23: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 SAA00535 for ; Wed, 5 Nov 2003 18:23:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHWza-0005Yp-00 for nemo@ietf.org; Wed, 05 Nov 2003 18:23:14 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AHWza-0005Ym-00 for nemo@ietf.org; Wed, 05 Nov 2003 18:23:14 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hA5NNDKD023206; Wed, 5 Nov 2003 16:23:13 -0700 (MST) Received: from motorola.com ([163.14.20.31]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hA5NMtAY008282; Wed, 5 Nov 2003 17:23:00 -0600 Message-ID: <3FA9864C.3090804@motorola.com> Date: Thu, 06 Nov 2003 00:22: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: Vijay Devarapalli CC: Koshiro MITSUYA , nemo@ietf.org Subject: Re: [nemo] Dynamic Routing Protocol Operation on MR References: <3FA95B34.2070301@iprg.nokia.com> In-Reply-To: <3FA95B34.2070301@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: > Koshiro MITSUYA wrote: > >> Hello, >> >> Dose anyone have a good idea how to operate or implement Dynamic >> Routing Protocl Support on MR? Ideas plenty, but what you call a good idea... >> The specification said, 7. Support for Dynamic Routing Protocols >> >> >> >> When the Mobile Router is attached to the home link, it runs a >> routing protocol by sending routing updates through its egress >> interface. When the mobile router moves and attaches to a visited >> network, it MUST stop sending routing updates on the interface with >> which it attaches to the visited link. This is very important so >> that IPv6 prefixes specific to the Mobile Network do not leak into >> the visited network. The Mobile Router then starts sending routing >> protocol messages through the bi-directional tunnel towards the >> Home Agent. Most routing protocols use link local addresses as >> source addresses for the routing information messages. The Mobile >> Router is allowed to use link local addresses for the inner IPv6 >> header of an encapsulated packet. But these messages after >> decapsulation MUST NOT be forwarded to another link by either the >> Mobile Router or the Home Agent. >> >> >> >> My problem is, how the routing daemon on MR stop the advertisement? >> how to change the advertised interface between the egress >> interface and bi-directional tunnel? >> >> I remember a solution (maybe Pascal said on the ML). MR has a >> virtual interface like vif0 which pointing the bi-directional >> tunnel. When MR move to foreign from home, MR change the >> configuration of routing daemon like eth0 to vif0 and restart the >> routing daemon. Re-starting the routing daemon? What happens to all entries that existed in the app-level rt table entries when the MR was at home? They get lost when the MR moves away from home and re-get introduced when the MR talks back to the HA? >> Is this the best way? If there is another method, please teach me. > > it is totally implementation dependent. it is more or less implementation dependent. > in some implementations there is one instance of routing protocol per > interface. in this case, it is matter of stopping the instance on > the egress interface and starting it for the tunnel interface. It is hardly doable to stop and start that instance, when this trigger supposedly comes from the kernel space (where stacks run traditionally) to the userland (where rt daemons run traditionally). A possible way to implement dynamic routing protocol over the MR-HA tunnel is not to have the bidir tunnel as an interface (virtual or other). Instead, the encapsulation happens according to searches in the rt table and in the bc. When HA routes a packet towards MR, it searches a corresponding entry in its bc and if found then encapsulate. This logic does not apply similarly at the MR of course since that hasn't a bc. So the MR needs to 'flag' its entries in its rt that correspond to the real interface that connects to the home link, (named egress interface, or name it mobile interface). When MR moves away from home, it moves all its rt entries corresponding to its mobile interface to a new table. Modify the kernel ctls that are called by the rt daemon such as instead of reading/writing in the normal rt table, r/w into this new table, when referring to that interface. In this way, the rt protocol instance runs as before, over the same interface visible in the userspace. But it magically maintains the kernel routes in this new table instead of in the normal kernel rt table. This also allows for the same rt protocol application to run another instance over the egress interface but directly towards the access system, since the relevant entries for home were declared when it moved. Routing interactions with the access system are not addressed by NEMO (but in other contexts this _is_ interesting, for example look at OSPF wireless interfaces). Now there was a sort of discussion about dynamic rt protocol over the MR-HA tunnel very early in the DT, together with indications about how we (Mot) did it late last year. I would qualify that discussion as public and non IPR'ed only if the NEMO WG considers that the NEMO basic solution should be non-IPR'ed; if the NEMO WG considers that the basic NEMO solution could be IPR'ed - a plausible reason I could imagine to see being that NEMO would in itself be not a "base" but rather an "extension" of Mobile IPv6, and with the attached IETF licensing scheme, open source licensing, RAND and such - then I qualify that DT discussion as secret and our source code also as secret and very difficult to discuss about until my employer gets a publicly-visible patent (read visible w/o a fee on the uspto site, even though EU and JP patents show to paying subscribers in other places earlier) for it as well as an IETF IPR declaration along the lines of rfc2026 and along the lines of what the IPR WG currently suggests. Alex GBU From nemo-admin@ietf.org Wed Nov 5 21:16:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06040 for ; Wed, 5 Nov 2003 21:16: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 1AHZgn-0000Zo-4l; Wed, 05 Nov 2003 21: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 1AHZg7-0000Yt-CA for nemo@optimus.ietf.org; Wed, 05 Nov 2003 21:15: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 VAA05990 for ; Wed, 5 Nov 2003 21:15:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHZg4-00002p-00 for nemo@ietf.org; Wed, 05 Nov 2003 21:15:16 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AHZg4-00000A-00 for nemo@ietf.org; Wed, 05 Nov 2003 21:15:16 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 2177B5D0AD; Thu, 6 Nov 2003 11:14:43 +0900 (JST) Date: Thu, 6 Nov 2003 11:09:08 +0900 From: Thierry Ernst To: Vijay Devarapalli Cc: cam@blueyonder.co.uk, nemo@ietf.org Subject: Re: [NEMO] Behavior of HA Message-Id: <20031106110908.113f2a5d.ernst@sfc.wide.ad.jp> In-Reply-To: <3FA956EB.9020307@iprg.nokia.com> References: <3FA956EB.9020307@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > > Should the spec make this clear? > > section 3 contains > > A Mobile Router has an unique Home Address through which it is always > reachable. The Home Address is configured from a prefix that is > aggregated and advertised by its Home Agent. The prefix could either > be the prefix advertised on the home link or the prefix delegated to > the Mobile Router. The Mobile Router can have more than one Home > Address if there are multiple prefixes in the home link. > > what clarification are you looking for? May be a mention about "ingress interface" or "egress interface" of the MR ? But my understanding is that this will be clarified in other document, won't it ? Thierry. From exim@www1.ietf.org Wed Nov 5 21:16:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06062 for ; Wed, 5 Nov 2003 21: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 1AHZgp-0000c2-8N for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 21:16:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA62G3Th002336 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 21:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHZgp-0000aY-16 for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 21:16: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 VAA06031 for ; Wed, 5 Nov 2003 21:15:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHZgm-00003w-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 21:16:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHZgm-00003q-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 21:16:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHZgn-0000Zo-4l; Wed, 05 Nov 2003 21: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 1AHZg7-0000Yt-CA for nemo@optimus.ietf.org; Wed, 05 Nov 2003 21:15: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 VAA05990 for ; Wed, 5 Nov 2003 21:15:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHZg4-00002p-00 for nemo@ietf.org; Wed, 05 Nov 2003 21:15:16 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AHZg4-00000A-00 for nemo@ietf.org; Wed, 05 Nov 2003 21:15:16 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 2177B5D0AD; Thu, 6 Nov 2003 11:14:43 +0900 (JST) Date: Thu, 6 Nov 2003 11:09:08 +0900 From: Thierry Ernst To: Vijay Devarapalli Cc: cam@blueyonder.co.uk, nemo@ietf.org Subject: Re: [NEMO] Behavior of HA Message-Id: <20031106110908.113f2a5d.ernst@sfc.wide.ad.jp> In-Reply-To: <3FA956EB.9020307@iprg.nokia.com> References: <3FA956EB.9020307@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > > Should the spec make this clear? > > section 3 contains > > A Mobile Router has an unique Home Address through which it is always > reachable. The Home Address is configured from a prefix that is > aggregated and advertised by its Home Agent. The prefix could either > be the prefix advertised on the home link or the prefix delegated to > the Mobile Router. The Mobile Router can have more than one Home > Address if there are multiple prefixes in the home link. > > what clarification are you looking for? May be a mention about "ingress interface" or "egress interface" of the MR ? But my understanding is that this will be clarified in other document, won't it ? Thierry. From nemo-admin@ietf.org Wed Nov 5 23:00:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08903 for ; Wed, 5 Nov 2003 23:00: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 1AHbJS-0006Ip-Ja; Wed, 05 Nov 2003 23: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 1AHbIj-0006Hv-DU for nemo@optimus.ietf.org; Wed, 05 Nov 2003 22:59: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 WAA08825 for ; Wed, 5 Nov 2003 22:59:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHbIf-0001Lr-00 for nemo@ietf.org; Wed, 05 Nov 2003 22:59:13 -0500 Received: from ns2.sea.interquest.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1AHbIe-0001Ln-00 for nemo@ietf.org; Wed, 05 Nov 2003 22:59:12 -0500 Received: from SOUHWANSENSQ (ip162.adobe-evergrn.sfo.interquest.net [66.199.85.162]) by ns2.sea (8.12.10/8.12.5) with SMTP id hA63x2JT031653 for ; Wed, 5 Nov 2003 19:59:06 -0800 Message-ID: <009501c3a41a$519af2c0$2302a8c0@SOUHWANSENSQ> From: "Souhwan Jung" To: Date: Thu, 6 Nov 2003 12:58:28 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0090_01C3A465.AC506D30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [nemo] comments on new threats Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0090_01C3A465.AC506D30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNClRoZSBuZXcgdGhyZWF0IGFuYWx5c2lzIGRyYWZ0IGlzIGF2YWlsYWJsZSBh dCB0aGUgZm9sbG93aW5nIGxvY2F0aW9uLg0KDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1qdW5nLW5lbW8tdGhyZWF0LWFuYWx5c2lzLTAxLnR4dA0KDQpTb21lIG5l dyB0aHJlYXRzIHNwZWNpZmljIHRvIE5FTU8gYmFzaWMgc3VwcG9ydCBwcm90b2NvbCB3ZXJlIGlu Y2x1ZGVkIGF0IHRoZSBkcmFmdC4gQW55IGNvbW1lbnRzIG9uIHRoZW0gd2lsbCBiZSBncmVhdGx5 IGFwcHJlY2lhdGVkLg0KDQpUaGFua3MuDQoNClNvdWh3YW4= ------=_NextPart_000_0090_01C3A465.AC506D30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjgwMC4xMjY0IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7JiM0NzU0 ODs+DQo8RElWPkRlYXIgYWxsLDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+VGhlIG5l dyB0aHJlYXQgYW5hbHlzaXMgZHJhZnQgaXMgYXZhaWxhYmxlJm5ic3A7YXQgdGhlIGZvbGxvd2lu ZyANCmxvY2F0aW9uLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEEgDQpocmVmPSJo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qdW5nLW5lbW8tdGhyZWF0 LWFuYWx5c2lzLTAxLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtanVuZy1uZW1vLXRocmVhdC1hbmFseXNpcy0wMS50eHQ8L0E+PC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj5Tb21lJm5ic3A7bmV3IHRocmVhdHMgc3BlY2lmaWMgdG8gTkVNTyBiYXNp YyBzdXBwb3J0IHByb3RvY29sIHdlcmUgaW5jbHVkZWQgDQphdCB0aGUgZHJhZnQuIEFueSBjb21t ZW50cyBvbiZuYnNwO3RoZW0gd2lsbCBiZSBncmVhdGx5IGFwcHJlY2lhdGVkLjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+VGhhbmtzLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+U291aHdhbjwvRElWPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0090_01C3A465.AC506D30-- From exim@www1.ietf.org Wed Nov 5 23:00:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08920 for ; Wed, 5 Nov 2003 23:00: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 1AHbJX-0006KJ-QO for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 23:00:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA64075o024304 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 23:00:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHbJW-0006Jp-Gs for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 23:00: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 WAA08865 for ; Wed, 5 Nov 2003 22:59:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHbJS-0001MZ-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 23:00:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHbJS-0001MW-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 23:00:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHbJS-0006Ip-Ja; Wed, 05 Nov 2003 23: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 1AHbIj-0006Hv-DU for nemo@optimus.ietf.org; Wed, 05 Nov 2003 22:59: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 WAA08825 for ; Wed, 5 Nov 2003 22:59:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHbIf-0001Lr-00 for nemo@ietf.org; Wed, 05 Nov 2003 22:59:13 -0500 Received: from ns2.sea.interquest.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1AHbIe-0001Ln-00 for nemo@ietf.org; Wed, 05 Nov 2003 22:59:12 -0500 Received: from SOUHWANSENSQ (ip162.adobe-evergrn.sfo.interquest.net [66.199.85.162]) by ns2.sea (8.12.10/8.12.5) with SMTP id hA63x2JT031653 for ; Wed, 5 Nov 2003 19:59:06 -0800 Message-ID: <009501c3a41a$519af2c0$2302a8c0@SOUHWANSENSQ> From: "Souhwan Jung" To: Date: Thu, 6 Nov 2003 12:58:28 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0090_01C3A465.AC506D30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [nemo] comments on new threats Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0090_01C3A465.AC506D30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNClRoZSBuZXcgdGhyZWF0IGFuYWx5c2lzIGRyYWZ0IGlzIGF2YWlsYWJsZSBh dCB0aGUgZm9sbG93aW5nIGxvY2F0aW9uLg0KDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1qdW5nLW5lbW8tdGhyZWF0LWFuYWx5c2lzLTAxLnR4dA0KDQpTb21lIG5l dyB0aHJlYXRzIHNwZWNpZmljIHRvIE5FTU8gYmFzaWMgc3VwcG9ydCBwcm90b2NvbCB3ZXJlIGlu Y2x1ZGVkIGF0IHRoZSBkcmFmdC4gQW55IGNvbW1lbnRzIG9uIHRoZW0gd2lsbCBiZSBncmVhdGx5 IGFwcHJlY2lhdGVkLg0KDQpUaGFua3MuDQoNClNvdWh3YW4= ------=_NextPart_000_0090_01C3A465.AC506D30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjgwMC4xMjY0IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7JiM0NzU0 ODs+DQo8RElWPkRlYXIgYWxsLDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+VGhlIG5l dyB0aHJlYXQgYW5hbHlzaXMgZHJhZnQgaXMgYXZhaWxhYmxlJm5ic3A7YXQgdGhlIGZvbGxvd2lu ZyANCmxvY2F0aW9uLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEEgDQpocmVmPSJo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qdW5nLW5lbW8tdGhyZWF0 LWFuYWx5c2lzLTAxLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtanVuZy1uZW1vLXRocmVhdC1hbmFseXNpcy0wMS50eHQ8L0E+PC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj5Tb21lJm5ic3A7bmV3IHRocmVhdHMgc3BlY2lmaWMgdG8gTkVNTyBiYXNp YyBzdXBwb3J0IHByb3RvY29sIHdlcmUgaW5jbHVkZWQgDQphdCB0aGUgZHJhZnQuIEFueSBjb21t ZW50cyBvbiZuYnNwO3RoZW0gd2lsbCBiZSBncmVhdGx5IGFwcHJlY2lhdGVkLjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+VGhhbmtzLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+U291aHdhbjwvRElWPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0090_01C3A465.AC506D30-- From nemo-admin@ietf.org Wed Nov 5 23:16:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09296 for ; Wed, 5 Nov 2003 23:16: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 1AHbYw-00071u-Ft; Wed, 05 Nov 2003 23:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHbYi-00070q-I6 for nemo@optimus.ietf.org; Wed, 05 Nov 2003 23:15: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 XAA09271 for ; Wed, 5 Nov 2003 23:15:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHbYg-0001ZG-00 for nemo@ietf.org; Wed, 05 Nov 2003 23:15:46 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AHbYf-0001Yv-00 for nemo@ietf.org; Wed, 05 Nov 2003 23:15:45 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id hA647bRn001954; Thu, 6 Nov 2003 12:07:37 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 45A7510E95DA; Thu, 6 Nov 2003 12:16:03 +0800 (SGT) Subject: Re: [nemo] Behavior of HA From: Chan-Wah NG To: Vijay Devarapalli Cc: MATSUMOTO Taisuke , IETF NEMO WG In-Reply-To: <3FA95896.7010002@iprg.nokia.com> References: <200311051221.hA5CLh2t075968@mrit.mrit.mei.co.jp> <3FA95896.7010002@iprg.nokia.com> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1068092162.11303.94.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 06 Nov 2003 12:16:03 +0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 2003-11-06 at 04:07, Vijay Devarapalli wrote: > hi, > > thanks for catching this. > > MATSUMOTO Taisuke wrote: > > Dear NEMO WG members, > > > > I'm trying to implement the NEMO protocol stack, and I find a > > problem. > > > > I set up my test network according to the figure 1 in the basic > > support draft page 28. See below. > > > > +-------------------+ 3:: 2+-------+ > > | Internet |------| CN_MR | > > +-------------------+ +-------+ > > 4:: | > > | > > 2+-------------+3 > > +--+-+ +---+---+ > > | MR | | HA_MR | > > +--+-+ +-------+ > > 5:: |1 > > ---------- > > 2| > > +--+-+ > > | LFN| > > +--+-+ > > > > I tried to run the MR in the explicit prefix length mode. When > > the mobile router was attached to the foreign link, the MR tried > > to send the binding update message which consists of '5::1' for > > the home address and '64' for the prefix length. > > > > But the HA rejected that BU message and returned the BA message > > with the status code 132. This behavior is defined in the section > > 10.3.1 of the mobile IPv6 draft, draft-ietf-mobileip-ipv6-24.txt. > > > > The explicit prefix length mode uses the IP address of the ingress > > interface as the home address of the mobile router. In this case, > > the IP address of the ingress interface is not an on-link IP > > address of the HA. > > > > So, I think that some schemes to avoid that restriction of the > > mobile IPv6 specifications is required for the NEMO basic support. > > yes. the mobile IPv6 restriction needs to be relaxed. currently > section 10.3.1 of MIPv6 says > > if the home address for the binding (the Home Address field > in the packet's Home Address option) is not an on-link IPv6 > address with respect to the home agent's current Prefix List, then > the home agent MUST reject the Binding Update and SHOULD return a > Binding Acknowledgement to the mobile node, in which the Status > field is set to 132 (not home subnet). > > for Nemo, the Home Agent should not reject the Binding if the > home address is from a prefix that has been delegated to a > Mobile Router. > > comments? > So that means for a HA with NEMO functionality, the HA after checking the HoA, found out that the HoA is not an on-link IPv6 address, will (instead of rejecting the BU as per a 'classical' MIPv6 HA does) go on to check if the HoA belongs to a MR, and accept it if it is, and reject it otherwise? Some descriptions must be added to the section 6. /rgds /cwng From exim@www1.ietf.org Wed Nov 5 23:16:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09311 for ; Wed, 5 Nov 2003 23:16: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 1AHbZ0-00072m-5i for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 23:16:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA64G6eZ027077 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 23:16:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHbYz-00072e-MG for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 23:16: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 XAA09275 for ; Wed, 5 Nov 2003 23:15:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHbYx-0001ZW-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 23:16:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHbYx-0001ZT-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 23: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 1AHbYw-00071u-Ft; Wed, 05 Nov 2003 23:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHbYi-00070q-I6 for nemo@optimus.ietf.org; Wed, 05 Nov 2003 23:15: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 XAA09271 for ; Wed, 5 Nov 2003 23:15:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHbYg-0001ZG-00 for nemo@ietf.org; Wed, 05 Nov 2003 23:15:46 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AHbYf-0001Yv-00 for nemo@ietf.org; Wed, 05 Nov 2003 23:15:45 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id hA647bRn001954; Thu, 6 Nov 2003 12:07:37 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 45A7510E95DA; Thu, 6 Nov 2003 12:16:03 +0800 (SGT) Subject: Re: [nemo] Behavior of HA From: Chan-Wah NG To: Vijay Devarapalli Cc: MATSUMOTO Taisuke , IETF NEMO WG In-Reply-To: <3FA95896.7010002@iprg.nokia.com> References: <200311051221.hA5CLh2t075968@mrit.mrit.mei.co.jp> <3FA95896.7010002@iprg.nokia.com> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1068092162.11303.94.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 06 Nov 2003 12:16:03 +0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2003-11-06 at 04:07, Vijay Devarapalli wrote: > hi, > > thanks for catching this. > > MATSUMOTO Taisuke wrote: > > Dear NEMO WG members, > > > > I'm trying to implement the NEMO protocol stack, and I find a > > problem. > > > > I set up my test network according to the figure 1 in the basic > > support draft page 28. See below. > > > > +-------------------+ 3:: 2+-------+ > > | Internet |------| CN_MR | > > +-------------------+ +-------+ > > 4:: | > > | > > 2+-------------+3 > > +--+-+ +---+---+ > > | MR | | HA_MR | > > +--+-+ +-------+ > > 5:: |1 > > ---------- > > 2| > > +--+-+ > > | LFN| > > +--+-+ > > > > I tried to run the MR in the explicit prefix length mode. When > > the mobile router was attached to the foreign link, the MR tried > > to send the binding update message which consists of '5::1' for > > the home address and '64' for the prefix length. > > > > But the HA rejected that BU message and returned the BA message > > with the status code 132. This behavior is defined in the section > > 10.3.1 of the mobile IPv6 draft, draft-ietf-mobileip-ipv6-24.txt. > > > > The explicit prefix length mode uses the IP address of the ingress > > interface as the home address of the mobile router. In this case, > > the IP address of the ingress interface is not an on-link IP > > address of the HA. > > > > So, I think that some schemes to avoid that restriction of the > > mobile IPv6 specifications is required for the NEMO basic support. > > yes. the mobile IPv6 restriction needs to be relaxed. currently > section 10.3.1 of MIPv6 says > > if the home address for the binding (the Home Address field > in the packet's Home Address option) is not an on-link IPv6 > address with respect to the home agent's current Prefix List, then > the home agent MUST reject the Binding Update and SHOULD return a > Binding Acknowledgement to the mobile node, in which the Status > field is set to 132 (not home subnet). > > for Nemo, the Home Agent should not reject the Binding if the > home address is from a prefix that has been delegated to a > Mobile Router. > > comments? > So that means for a HA with NEMO functionality, the HA after checking the HoA, found out that the HoA is not an on-link IPv6 address, will (instead of rejecting the BU as per a 'classical' MIPv6 HA does) go on to check if the HoA belongs to a MR, and accept it if it is, and reject it otherwise? Some descriptions must be added to the section 6. /rgds /cwng From nemo-admin@ietf.org Wed Nov 5 23:50:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10170 for ; Wed, 5 Nov 2003 23:50: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 1AHc5q-0000PY-F8; Wed, 05 Nov 2003 23:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHc4q-0000Nz-5u for nemo@optimus.ietf.org; Wed, 05 Nov 2003 23:49: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 XAA10144 for ; Wed, 5 Nov 2003 23:48:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHc4n-0001xP-00 for nemo@ietf.org; Wed, 05 Nov 2003 23:48:57 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AHc4m-0001xA-00 for nemo@ietf.org; Wed, 05 Nov 2003 23:48:57 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id hA64eeRn002736; Thu, 6 Nov 2003 12:40:41 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id B469B10E95DA; Thu, 6 Nov 2003 12:49:06 +0800 (SGT) Subject: Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt From: Chan-Wah NG To: Vijay Devarapalli Cc: "T.J. Kniveton" , IETF NEMO WG , Margaret Wasserman , Thomas Narten In-Reply-To: <3FA93FF0.9060608@iprg.nokia.com> References: <1068024404.6779.27.camel@localhost> <3FA93FF0.9060608@iprg.nokia.com> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1068094146.11301.127.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 06 Nov 2003 12:49:06 +0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Vijay, Please see responses in-line. /rgds /cwng On Thu, 2003-11-06 at 02:22, Vijay Devarapalli wrote: > Chan-Wah NG wrote: > > > > > Major (or Non-Minor) Issues > > --------------------------- > > > > (1) IANA Considerations - Page 25 - Section 9 > > > > In addition to the mobility options type, I would think that the various > > new Status values in Binding Acknowledgement need IANA considerations as > > well when MIPv6 becomes an RFC, though I am not too sure what needs and > > what does not need IANA considerations. > > good question. since Mobile IPv6 specificaction does not require IANA > action for Binding Ack status values and defines them in the document > itself, we assumed we should do the same. but now that the Binding Ack > status values are spread over two differnt documents (and maybe more > in the future), maybe IANA needs to be involved. I am not sure. > That's what I thought too. > I think this needs AD clarification... > > > (2) Is Issue 11 resolved? > > > > Three modes of operations were specified for NEMO operations. It was > > explicitly stated that the Home Agent MUST implement all three (which > > partially resolved issue 11). However, no such statement were made > > about the Mobile Router. I presume it means that the Mobile Router is > > free to implement any combinations of the three. According to the > > Issues webpage, there seems to be a consensus on issue 11 that there > > will be explicit statements specifying the mobile router implement any > > one of the modes. However, I fail to find such statement in the -01 > > draft. > > section 5.2 > > The Mobile Router uses > one of the following modes to instruct the Home Agent to determine > the prefixes owned by the Mobile Router. In all three modes, the > Mobile Router sets the Mobile Router flag 'R'. > I would actually prefer a stronger indication involving one of the MUST MIGHT SHOULD etc keywords, but that's just me. > > Might be also helpful to discuss which mode is better suited for > > what situations. > > thats a rathole... :) one mode that should work in all cases, is the > Explicit Network mode. > > > > (3) ESP is a MUST? - Page 24, Sect 7 > > > > The last sentence of Section 7 says the "tunneled routing messages MUST > > be authenticated and encrypted using IPsec ESP in tunnel mode". Even > > the original MIPv6 Specs (-24) is not so strict in specifying what kind > > of encryption scheme must be used to protect the BU. > > I think you misunderstood this. the basic support document does not > require ESP tunnel encryption for Binding Updates. I presume Binding Updates are protected the same way as MIPv6 specified, which is that BU MUST be protected using an IPsec security association, and both MN and HA MUST support and SHOULD use ESP. So there is no misunderstanding there. > section 7 is about > dynamic routing protocol messages. routing protocol messages from the > Home Agent to the Mobile Router could potentially contain a lot of > information about the internal routing structure of the home domain. > simple authentication wont be enough if these messages could be > observed by others. that is why the strict requirement. > Yes, I understand that as well. I am not questioning the need to encrypt tunnel packets containing routing protocols messages. I am just asking do we need to limit the encryption mechanism to ESP? I understand ESP is the currently prevailing (perhaps even the only) mechanism that encrypt a payload packet in tunneled mode, but there might be new protocols in the future. By saying "tunneled routing messages MUST be authenticated and encrypted by using IPsec ESP in tunnel mode", you are closing the door to using other mechanisms. I would prefer the MIPv6 style of saying saying the tunnel messages must be encrypted,and using ESP as the encryption mechanism MUST be supported and SHOULD be used by MR and HA". > > > Minor Editorial Issues > > ----------------------- > > > > On the same note, a lot of abbreviations are > > used without giving their full meanings in the document, like OSPF, > > RIPng, ESP, etc. Though proper end reference are given, it might be > > good to expand them when they are first used, instead of forcing readers > > to dig into end-references to get the fully-expanded phrase. > > if you are implementing NEMO, you better have heard about OSPF, RIP > and ESP. :) seriously, I think they are too well known. > I am not so sure, but to quote the "Guidelines to Authors of Internet-Drafts" on the IETF webpage, I will rather 'err on the side of explicitness'. > thanks for catching all these. > Don't mention it, it is afterall a WG document, and it is our job to make sure the document is presentation-wise as well as technical-wise sound before submitting it to the IESG. /rgds /cwng > Vijay > > > From exim@www1.ietf.org Wed Nov 5 23:50:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10185 for ; Wed, 5 Nov 2003 23:50: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 1AHc5t-0000QW-7U for nemo-archive@odin.ietf.org; Wed, 05 Nov 2003 23:50:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA64o5rQ001634 for nemo-archive@odin.ietf.org; Wed, 5 Nov 2003 23:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHc5t-0000QH-1h for nemo-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 23:50: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 XAA10167 for ; Wed, 5 Nov 2003 23:49:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHc5q-0001y2-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 23:50:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHc5q-0001xz-00 for nemo-web-archive@ietf.org; Wed, 05 Nov 2003 23:50:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHc5q-0000PY-F8; Wed, 05 Nov 2003 23:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHc4q-0000Nz-5u for nemo@optimus.ietf.org; Wed, 05 Nov 2003 23:49: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 XAA10144 for ; Wed, 5 Nov 2003 23:48:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHc4n-0001xP-00 for nemo@ietf.org; Wed, 05 Nov 2003 23:48:57 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AHc4m-0001xA-00 for nemo@ietf.org; Wed, 05 Nov 2003 23:48:57 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id hA64eeRn002736; Thu, 6 Nov 2003 12:40:41 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id B469B10E95DA; Thu, 6 Nov 2003 12:49:06 +0800 (SGT) Subject: Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt From: Chan-Wah NG To: Vijay Devarapalli Cc: "T.J. Kniveton" , IETF NEMO WG , Margaret Wasserman , Thomas Narten In-Reply-To: <3FA93FF0.9060608@iprg.nokia.com> References: <1068024404.6779.27.camel@localhost> <3FA93FF0.9060608@iprg.nokia.com> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1068094146.11301.127.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 06 Nov 2003 12:49:06 +0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Vijay, Please see responses in-line. /rgds /cwng On Thu, 2003-11-06 at 02:22, Vijay Devarapalli wrote: > Chan-Wah NG wrote: > > > > > Major (or Non-Minor) Issues > > --------------------------- > > > > (1) IANA Considerations - Page 25 - Section 9 > > > > In addition to the mobility options type, I would think that the various > > new Status values in Binding Acknowledgement need IANA considerations as > > well when MIPv6 becomes an RFC, though I am not too sure what needs and > > what does not need IANA considerations. > > good question. since Mobile IPv6 specificaction does not require IANA > action for Binding Ack status values and defines them in the document > itself, we assumed we should do the same. but now that the Binding Ack > status values are spread over two differnt documents (and maybe more > in the future), maybe IANA needs to be involved. I am not sure. > That's what I thought too. > I think this needs AD clarification... > > > (2) Is Issue 11 resolved? > > > > Three modes of operations were specified for NEMO operations. It was > > explicitly stated that the Home Agent MUST implement all three (which > > partially resolved issue 11). However, no such statement were made > > about the Mobile Router. I presume it means that the Mobile Router is > > free to implement any combinations of the three. According to the > > Issues webpage, there seems to be a consensus on issue 11 that there > > will be explicit statements specifying the mobile router implement any > > one of the modes. However, I fail to find such statement in the -01 > > draft. > > section 5.2 > > The Mobile Router uses > one of the following modes to instruct the Home Agent to determine > the prefixes owned by the Mobile Router. In all three modes, the > Mobile Router sets the Mobile Router flag 'R'. > I would actually prefer a stronger indication involving one of the MUST MIGHT SHOULD etc keywords, but that's just me. > > Might be also helpful to discuss which mode is better suited for > > what situations. > > thats a rathole... :) one mode that should work in all cases, is the > Explicit Network mode. > > > > (3) ESP is a MUST? - Page 24, Sect 7 > > > > The last sentence of Section 7 says the "tunneled routing messages MUST > > be authenticated and encrypted using IPsec ESP in tunnel mode". Even > > the original MIPv6 Specs (-24) is not so strict in specifying what kind > > of encryption scheme must be used to protect the BU. > > I think you misunderstood this. the basic support document does not > require ESP tunnel encryption for Binding Updates. I presume Binding Updates are protected the same way as MIPv6 specified, which is that BU MUST be protected using an IPsec security association, and both MN and HA MUST support and SHOULD use ESP. So there is no misunderstanding there. > section 7 is about > dynamic routing protocol messages. routing protocol messages from the > Home Agent to the Mobile Router could potentially contain a lot of > information about the internal routing structure of the home domain. > simple authentication wont be enough if these messages could be > observed by others. that is why the strict requirement. > Yes, I understand that as well. I am not questioning the need to encrypt tunnel packets containing routing protocols messages. I am just asking do we need to limit the encryption mechanism to ESP? I understand ESP is the currently prevailing (perhaps even the only) mechanism that encrypt a payload packet in tunneled mode, but there might be new protocols in the future. By saying "tunneled routing messages MUST be authenticated and encrypted by using IPsec ESP in tunnel mode", you are closing the door to using other mechanisms. I would prefer the MIPv6 style of saying saying the tunnel messages must be encrypted,and using ESP as the encryption mechanism MUST be supported and SHOULD be used by MR and HA". > > > Minor Editorial Issues > > ----------------------- > > > > On the same note, a lot of abbreviations are > > used without giving their full meanings in the document, like OSPF, > > RIPng, ESP, etc. Though proper end reference are given, it might be > > good to expand them when they are first used, instead of forcing readers > > to dig into end-references to get the fully-expanded phrase. > > if you are implementing NEMO, you better have heard about OSPF, RIP > and ESP. :) seriously, I think they are too well known. > I am not so sure, but to quote the "Guidelines to Authors of Internet-Drafts" on the IETF webpage, I will rather 'err on the side of explicitness'. > thanks for catching all these. > Don't mention it, it is afterall a WG document, and it is our job to make sure the document is presentation-wise as well as technical-wise sound before submitting it to the IESG. /rgds /cwng > Vijay > > > From nemo-admin@ietf.org Thu Nov 6 01:24:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12712 for ; Thu, 6 Nov 2003 01:24: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 1AHdYm-0004Td-NQ; Thu, 06 Nov 2003 01:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHdYQ-0004TR-1o for nemo@optimus.ietf.org; Thu, 06 Nov 2003 01:23: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 BAA12702 for ; Thu, 6 Nov 2003 01:23:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHdYM-00038q-00 for nemo@ietf.org; Thu, 06 Nov 2003 01:23:34 -0500 Received: from pec.etri.re.kr ([129.254.114.50]) by ietf-mx with esmtp (Exim 4.12) id 1AHdY9-00038W-00 for nemo@ietf.org; Thu, 06 Nov 2003 01:23:21 -0500 Received: from kjlee (leekj3.etri.re.kr [129.254.112.172]) by pec.etri.re.kr (8.12.10/8.12.10) with SMTP id hA66bf5l028118 for ; Thu, 6 Nov 2003 15:37:41 +0900 (KST) Message-ID: <015f01c3a42e$64a8f0b0$ac70fe81@kjlee> From: "KyeongJin Lee" To: Date: Thu, 6 Nov 2003 15:22:40 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Subject: [nemo] BA(status 140) in explicit mode. Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGksDQpJJ3ZlIGEgcXVlc3Rpb24gb24gdGhlIE5FTU8gQmFzaWMgU3VwcG9ydC4NCiANCmluIHNl Y3QgNi4yDQpXaGVuIGEgSEEgcmVjZWl2ZWQgQlUgd2l0aCBSIGZsYWcgc2V0LCANCmlmIHRoZSBI IGZsYWcgaXMgbm90IHNldCwgdGhlIEhBIHNlbmQgQkEgd2l0aCBzdGF0dXMgc2V0IHRvIDE0MCB0 byBNUi4NCg0KYnV0IGluIHNlY3QgNQ0KTVIgTVVTVCBkaXNjYXJkIEJBKHN0YXR1cyAxNDApIGlm IGl0IGlzIG5vdCBvcGVyYXRlIGluIGltcGxpY2l0IG1vZGUuDQogDQpJIHdvbmRlciB3aHkgdGhl IE1SIE1VU1QgZGlzY2FyZCB0aGUgQkEoc3RhdHVzIDE0MCkgaW4gZXhwbGljaXQgbW9kZS4NCkkg dGhpbmsgTVIgbXVzdCBwcm9jZXNzIHRoZSBCQSBzdGF0dXMgMTQwIGluIGFsbCAzIG1vZGVzLg== From exim@www1.ietf.org Thu Nov 6 01:24:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12730 for ; Thu, 6 Nov 2003 01:24: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 1AHdYs-0004UX-Ro for nemo-archive@odin.ietf.org; Thu, 06 Nov 2003 01:24:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA66O6sQ017262 for nemo-archive@odin.ietf.org; Thu, 6 Nov 2003 01:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHdYs-0004UL-L2 for nemo-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 01:24: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 BAA12706 for ; Thu, 6 Nov 2003 01:23:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHdYp-000392-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 01:24:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHdYp-00038z-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 01: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 1AHdYm-0004Td-NQ; Thu, 06 Nov 2003 01:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHdYQ-0004TR-1o for nemo@optimus.ietf.org; Thu, 06 Nov 2003 01:23: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 BAA12702 for ; Thu, 6 Nov 2003 01:23:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHdYM-00038q-00 for nemo@ietf.org; Thu, 06 Nov 2003 01:23:34 -0500 Received: from pec.etri.re.kr ([129.254.114.50]) by ietf-mx with esmtp (Exim 4.12) id 1AHdY9-00038W-00 for nemo@ietf.org; Thu, 06 Nov 2003 01:23:21 -0500 Received: from kjlee (leekj3.etri.re.kr [129.254.112.172]) by pec.etri.re.kr (8.12.10/8.12.10) with SMTP id hA66bf5l028118 for ; Thu, 6 Nov 2003 15:37:41 +0900 (KST) Message-ID: <015f01c3a42e$64a8f0b0$ac70fe81@kjlee> From: "KyeongJin Lee" To: Date: Thu, 6 Nov 2003 15:22:40 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Subject: [nemo] BA(status 140) in explicit mode. Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGksDQpJJ3ZlIGEgcXVlc3Rpb24gb24gdGhlIE5FTU8gQmFzaWMgU3VwcG9ydC4NCiANCmluIHNl Y3QgNi4yDQpXaGVuIGEgSEEgcmVjZWl2ZWQgQlUgd2l0aCBSIGZsYWcgc2V0LCANCmlmIHRoZSBI IGZsYWcgaXMgbm90IHNldCwgdGhlIEhBIHNlbmQgQkEgd2l0aCBzdGF0dXMgc2V0IHRvIDE0MCB0 byBNUi4NCg0KYnV0IGluIHNlY3QgNQ0KTVIgTVVTVCBkaXNjYXJkIEJBKHN0YXR1cyAxNDApIGlm IGl0IGlzIG5vdCBvcGVyYXRlIGluIGltcGxpY2l0IG1vZGUuDQogDQpJIHdvbmRlciB3aHkgdGhl IE1SIE1VU1QgZGlzY2FyZCB0aGUgQkEoc3RhdHVzIDE0MCkgaW4gZXhwbGljaXQgbW9kZS4NCkkg dGhpbmsgTVIgbXVzdCBwcm9jZXNzIHRoZSBCQSBzdGF0dXMgMTQwIGluIGFsbCAzIG1vZGVzLg== From nemo-admin@ietf.org Thu Nov 6 04:24:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00366 for ; Thu, 6 Nov 2003 04:24:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgNY-0007wI-78; Thu, 06 Nov 2003 04:24:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHfjn-0005fL-1a for nemo@optimus.ietf.org; Thu, 06 Nov 2003 03:43:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29097 for ; Thu, 6 Nov 2003 03:43:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHfjk-0004zT-00 for nemo@ietf.org; Thu, 06 Nov 2003 03:43:28 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AHfjj-0004zD-00 for nemo@ietf.org; Thu, 06 Nov 2003 03:43:27 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 79FA95D0E5; Thu, 6 Nov 2003 17:42:57 +0900 (JST) Date: Thu, 6 Nov 2003 17:37:21 +0900 From: Thierry Ernst To: "Souhwan Jung" Cc: nemo@ietf.org Subject: Re: [nemo] comments on new threats Message-Id: <20031106173721.4ebb7f69.ernst@sfc.wide.ad.jp> In-Reply-To: <009501c3a41a$519af2c0$2302a8c0@SOUHWANSENSQ> References: <009501c3a41a$519af2c0$2302a8c0@SOUHWANSENSQ> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear Souhwan, > The new threat analysis draft is available at the following location. > > http://www.ietf.org/internet-drafts/draft-jung-nemo-threat-analysis-01.txt > > Some new threats specific to NEMO basic support protocol were included at the draft. Any comments on them will be greatly appreciated. Here are some comments to your draft. General Comments: ~~~~~~~~~~~~~~~~~ - I think it would be useful to explain what is new in the -01 version of your draft, so that people who already read version -00 can rapidly check what is important. - Does your new version catch the conversion we had on security at IETF Wien ? - I think the nested case and the multihoming cases require a more-in-depth analysis. It could an interesting future contribution of your work. - could you make the disctinction between potential threat, the ones peculiar to NEMO Basic Support, the one that generally apply to the concept of network mobility (taken in general, with no specific protocol in mind (i.e. without NEMO Basic Support, MIPv6, etc) 1. Motivations ~~~~~~~~~~~~~~ It would be useful to say there that the protocol to manage the mobility of the mobile network, i.e. network mobility support, is NEMO Basic Support, itself based on Mobile IPv6. Then you can say it introduces a new entity, the MR. You don't state explicitly if your draft address vulnerabilities specific to NEMO Basic Support, or network mobility in general, as a concept. When you speak about the general concept, you should also deal with the authorization for the sending node to fill up the BU with information that can be proven (e.g. the prefix actually belongs to the MR). Section 2 ~~~~~~~~~ You use the acronym "FA". You could get rid of it, there are no FA in NEMO. You probably mean the access router the MR is connected to, so would better replace FA with AR. Section 3.1 ~~~~~~~~~~~ Same remark, no FA. In addition, if you meant AR, you should clarify which signaling is under threat. RAs ? Is there any issue peculiar to NEMO right here ? Section 4.1 ~~~~~~~~~~~~ MR-HA spoofing MR-HA is the permanent address assigned statically or dynamically to the MR by HA. MR-HA should be used for identification of MR while it is in the visited domain. The compromised MR can register to FA with a spoofed MR-HA, and try to collect data destinated to the victim address. -> MR-HA does not registered with the AR. MR's egress iface gets a CoA on AR's link, that's all. 4.3 Traffic Analysis ~~~~~~~~~~~~~~~~~~~~ Between MR and HA: Here, you are assuming the attacker is somewhere between the MR and HA. Between MR and MNN: you are assuming some sort of Route Optimization which doesn't yet exist. Of course this is a problem RO will have to face, but I would suggest to emphasize your assumptions. If that is the case you should clarify that section 3 is a conceptual analysis and that it does focus on NEMO Basic Support. 5.Threats specific to the NEMO basic support protocol ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Please give a ref to the appropriate draft. 5.3 Attack to Location Privacy by Traffic Analysis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Where do you assume the attacker is located in order to monitor both path 2 and 3 ? Besides this, packets on path 2 (MR<->HA) will have all have same ; i.e. one packet may actually be sent by MNN1, and the next one by MNN2, so how can you conclude on path based on packet interleaving ? 6.4 ~~~ I'm curious how this could be done. But if such a solution exists, it would give the HA the right to check what are the MNNs behind the MR, so it turns to be a privacy concern. 6.5 ~~~ The important point is what are the potential threats. Privacy is one of them, so any solution should make sure that MNNs can keep their location at least as secrete has if there were located in a fixed network. Reference ~~~~~~~~~ - you missed to list NEMO Basic Support. - on the other hand, you cite 2 expired drafts: this is missleading for new reader. I think you should remove. [3] Wakikawa, R., et al, "Basic Network Mobility Support", Internet Draft: draft-wakikawa-nemo-basic-00.txt, Work In Progress, February 2003. [6] Kniveton, T. J., et al, "Mobile Router Tunneling Protocol", Internet Draft: draft-kniveton-mobrtr-03.txt, Work In Progress, November 2002. Thierry. From exim@www1.ietf.org Thu Nov 6 04:41:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01129 for ; Thu, 6 Nov 2003 04:41: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 1AHgdZ-0001cK-KX for nemo-archive@odin.ietf.org; Thu, 06 Nov 2003 04:41:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA69f7YY006172 for nemo-archive@odin.ietf.org; Thu, 6 Nov 2003 04:41:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgdS-0001aW-Dc for nemo-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 04:41: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 EAA00984 for ; Thu, 6 Nov 2003 04:40:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHgdO-0005k7-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 04:40:58 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AHgdN-0005ju-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 04:40:58 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AHgdD-0001hk-Jb for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 04:40:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgNY-0007wI-78; Thu, 06 Nov 2003 04:24:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHfjn-0005fL-1a for nemo@optimus.ietf.org; Thu, 06 Nov 2003 03:43:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29097 for ; Thu, 6 Nov 2003 03:43:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHfjk-0004zT-00 for nemo@ietf.org; Thu, 06 Nov 2003 03:43:28 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AHfjj-0004zD-00 for nemo@ietf.org; Thu, 06 Nov 2003 03:43:27 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 79FA95D0E5; Thu, 6 Nov 2003 17:42:57 +0900 (JST) Date: Thu, 6 Nov 2003 17:37:21 +0900 From: Thierry Ernst To: "Souhwan Jung" Cc: nemo@ietf.org Subject: Re: [nemo] comments on new threats Message-Id: <20031106173721.4ebb7f69.ernst@sfc.wide.ad.jp> In-Reply-To: <009501c3a41a$519af2c0$2302a8c0@SOUHWANSENSQ> References: <009501c3a41a$519af2c0$2302a8c0@SOUHWANSENSQ> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear Souhwan, > The new threat analysis draft is available at the following location. > > http://www.ietf.org/internet-drafts/draft-jung-nemo-threat-analysis-01.txt > > Some new threats specific to NEMO basic support protocol were included at the draft. Any comments on them will be greatly appreciated. Here are some comments to your draft. General Comments: ~~~~~~~~~~~~~~~~~ - I think it would be useful to explain what is new in the -01 version of your draft, so that people who already read version -00 can rapidly check what is important. - Does your new version catch the conversion we had on security at IETF Wien ? - I think the nested case and the multihoming cases require a more-in-depth analysis. It could an interesting future contribution of your work. - could you make the disctinction between potential threat, the ones peculiar to NEMO Basic Support, the one that generally apply to the concept of network mobility (taken in general, with no specific protocol in mind (i.e. without NEMO Basic Support, MIPv6, etc) 1. Motivations ~~~~~~~~~~~~~~ It would be useful to say there that the protocol to manage the mobility of the mobile network, i.e. network mobility support, is NEMO Basic Support, itself based on Mobile IPv6. Then you can say it introduces a new entity, the MR. You don't state explicitly if your draft address vulnerabilities specific to NEMO Basic Support, or network mobility in general, as a concept. When you speak about the general concept, you should also deal with the authorization for the sending node to fill up the BU with information that can be proven (e.g. the prefix actually belongs to the MR). Section 2 ~~~~~~~~~ You use the acronym "FA". You could get rid of it, there are no FA in NEMO. You probably mean the access router the MR is connected to, so would better replace FA with AR. Section 3.1 ~~~~~~~~~~~ Same remark, no FA. In addition, if you meant AR, you should clarify which signaling is under threat. RAs ? Is there any issue peculiar to NEMO right here ? Section 4.1 ~~~~~~~~~~~~ MR-HA spoofing MR-HA is the permanent address assigned statically or dynamically to the MR by HA. MR-HA should be used for identification of MR while it is in the visited domain. The compromised MR can register to FA with a spoofed MR-HA, and try to collect data destinated to the victim address. -> MR-HA does not registered with the AR. MR's egress iface gets a CoA on AR's link, that's all. 4.3 Traffic Analysis ~~~~~~~~~~~~~~~~~~~~ Between MR and HA: Here, you are assuming the attacker is somewhere between the MR and HA. Between MR and MNN: you are assuming some sort of Route Optimization which doesn't yet exist. Of course this is a problem RO will have to face, but I would suggest to emphasize your assumptions. If that is the case you should clarify that section 3 is a conceptual analysis and that it does focus on NEMO Basic Support. 5.Threats specific to the NEMO basic support protocol ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Please give a ref to the appropriate draft. 5.3 Attack to Location Privacy by Traffic Analysis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Where do you assume the attacker is located in order to monitor both path 2 and 3 ? Besides this, packets on path 2 (MR<->HA) will have all have same ; i.e. one packet may actually be sent by MNN1, and the next one by MNN2, so how can you conclude on path based on packet interleaving ? 6.4 ~~~ I'm curious how this could be done. But if such a solution exists, it would give the HA the right to check what are the MNNs behind the MR, so it turns to be a privacy concern. 6.5 ~~~ The important point is what are the potential threats. Privacy is one of them, so any solution should make sure that MNNs can keep their location at least as secrete has if there were located in a fixed network. Reference ~~~~~~~~~ - you missed to list NEMO Basic Support. - on the other hand, you cite 2 expired drafts: this is missleading for new reader. I think you should remove. [3] Wakikawa, R., et al, "Basic Network Mobility Support", Internet Draft: draft-wakikawa-nemo-basic-00.txt, Work In Progress, February 2003. [6] Kniveton, T. J., et al, "Mobile Router Tunneling Protocol", Internet Draft: draft-kniveton-mobrtr-03.txt, Work In Progress, November 2002. Thierry. From nemo-admin@ietf.org Thu Nov 6 04:51:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02021 for ; Thu, 6 Nov 2003 04:51: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 1AHgmD-000341-7l; Thu, 06 Nov 2003 04:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgj9-0002QR-KP for nemo@optimus.ietf.org; Thu, 06 Nov 2003 04:46:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01746 for ; Thu, 6 Nov 2003 04:46:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHgj0-00061P-00 for nemo@ietf.org; Thu, 06 Nov 2003 04:46:46 -0500 Received: from smtp.mei.co.jp ([133.183.129.25] helo=jazz.mei.co.jp) by ietf-mx with esmtp (Exim 4.12) id 1AHgiz-00060Y-00 for nemo@ietf.org; Thu, 06 Nov 2003 04:46:45 -0500 Received: by jazz.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id hA69k5Ou009454; Thu, 6 Nov 2003 18:46:05 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id hA69k7L05646; Thu, 6 Nov 2003 18:46:07 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/astros2) with ESMTP id hA69k7S23280; Thu, 6 Nov 2003 18:46:07 +0900 (JST) Received: from STRATOS ([10.96.152.147]) by mrit.mrit.mei.co.jp (8.12.6p2/3.7W-03060222) with SMTP id hA69k32t032659; Thu, 6 Nov 2003 18:46:04 +0900 (JST) Message-Id: <200311060946.hA69k32t032659@mrit.mrit.mei.co.jp> Date: Thu, 06 Nov 2003 09:46:25 +0000 From: MATSUMOTO Taisuke Subject: Re: [nemo] Behavior of HA To: "Vijay Devarapalli" Cc: nemo@ietf.org Organization: Matsushita Electric Industrial Co., Ltd. In-Reply-To: <3FA95896.7010002@iprg.nokia.com> References: <200311051221.hA5CLh2t075968@mrit.mrit.mei.co.jp> <3FA95896.7010002@iprg.nokia.com> X-Mailer: Datula version 1.52.01 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Vijay, Thank you for your response. > > So, I think that some schemes to avoid that restriction of the > > mobile IPv6 specifications is required for the NEMO basic support. > > yes. the mobile IPv6 restriction needs to be relaxed. currently > section 10.3.1 of MIPv6 says > > if the home address for the binding (the Home Address field > in the packet's Home Address option) is not an on-link IPv6 > address with respect to the home agent's current Prefix List, then > the home agent MUST reject the Binding Update and SHOULD return a > Binding Acknowledgement to the mobile node, in which the Status > field is set to 132 (not home subnet). > > for Nemo, the Home Agent should not reject the Binding if the > home address is from a prefix that has been delegated to a > Mobile Router. > > comments? I think that your comment is reasonabie. But I have another question how to know if the prefix is delegated to the mobile router. If it should be pre-configured in the home agent, it makes the explicit prefix length mode lose an advantage to the implicit mode. Am I misunderstanding anything? Taisuke From nemo-admin@ietf.org Thu Nov 6 05:06:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02378 for ; Thu, 6 Nov 2003 05:06: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 1AHh1d-0003sQ-Q5; Thu, 06 Nov 2003 05:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHh0z-0003rf-2A for nemo@optimus.ietf.org; Thu, 06 Nov 2003 05:05: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 FAA02364 for ; Thu, 6 Nov 2003 05:05:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHh0r-0006IY-00 for nemo@ietf.org; Thu, 06 Nov 2003 05:05:13 -0500 Received: from smtp.mei.co.jp ([133.183.129.25] helo=jazz.mei.co.jp) by ietf-mx with esmtp (Exim 4.12) id 1AHh0q-0006IL-00 for nemo@ietf.org; Thu, 06 Nov 2003 05:05:12 -0500 Received: by jazz.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id hA6A4dOu023611; Thu, 6 Nov 2003 19:04:39 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id hA6A4fL14990; Thu, 6 Nov 2003 19:04:41 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/astros2) with ESMTP id hA6A4fS09598; Thu, 6 Nov 2003 19:04:41 +0900 (JST) Received: from STRATOS ([10.96.152.147]) by mrit.mrit.mei.co.jp (8.12.6p2/3.7W-03060222) with SMTP id hA6A4Z2t034944; Thu, 6 Nov 2003 19:04:37 +0900 (JST) Message-Id: <200311061004.hA6A4Z2t034944@mrit.mrit.mei.co.jp> Date: Thu, 06 Nov 2003 10:04:58 +0000 From: MATSUMOTO Taisuke Subject: Re: [NEMO] Behavior of HA To: "Thierry Ernst" Cc: "Vijay Devarapalli" , cam@blueyonder.co.uk, nemo@ietf.org Organization: Matsushita Electric Industrial Co., Ltd. In-Reply-To: <20031106110908.113f2a5d.ernst@sfc.wide.ad.jp> References: <3FA956EB.9020307@iprg.nokia.com> <20031106110908.113f2a5d.ernst@sfc.wide.ad.jp> X-Mailer: Datula version 1.52.01 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Thierry and all, > > > Should the spec make this clear? > > > > section 3 contains > > > > A Mobile Router has an unique Home Address through which it is always > > reachable. The Home Address is configured from a prefix that is > > aggregated and advertised by its Home Agent. The prefix could either > > be the prefix advertised on the home link or the prefix delegated to > > the Mobile Router. The Mobile Router can have more than one Home > > Address if there are multiple prefixes in the home link. > > > > what clarification are you looking for? > > May be a mention about "ingress interface" or "egress interface" of the MR ? > > But my understanding is that this will be clarified in other document, won't it ? I'm sorry but I feel difficult to agree with your opinion. I think that the nemo basic support document should be enough to implement the basic mobile network. I could implement the explicit prefix length mode because I knew Mr. Wakikawa's personal draft inputed before the San Francisco meeting. But after I read Mr./Ms. Cam's mail, I think that the basic support draft should be revised to have the clear description about the configuration of entities. Any comments? Taisuke From exim@www1.ietf.org Thu Nov 6 05:06:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02400 for ; Thu, 6 Nov 2003 05: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 1AHh1g-0003tI-SG for nemo-archive@odin.ietf.org; Thu, 06 Nov 2003 05:06:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6A641K014956 for nemo-archive@odin.ietf.org; Thu, 6 Nov 2003 05:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHh1g-0003t9-DX for nemo-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 05:06: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 FAA02369 for ; Thu, 6 Nov 2003 05:05:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHh1d-0006It-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 05:06:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHh1c-0006Iq-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 05:06:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHh1d-0003sQ-Q5; Thu, 06 Nov 2003 05:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHh0z-0003rf-2A for nemo@optimus.ietf.org; Thu, 06 Nov 2003 05:05: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 FAA02364 for ; Thu, 6 Nov 2003 05:05:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHh0r-0006IY-00 for nemo@ietf.org; Thu, 06 Nov 2003 05:05:13 -0500 Received: from smtp.mei.co.jp ([133.183.129.25] helo=jazz.mei.co.jp) by ietf-mx with esmtp (Exim 4.12) id 1AHh0q-0006IL-00 for nemo@ietf.org; Thu, 06 Nov 2003 05:05:12 -0500 Received: by jazz.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id hA6A4dOu023611; Thu, 6 Nov 2003 19:04:39 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id hA6A4fL14990; Thu, 6 Nov 2003 19:04:41 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/astros2) with ESMTP id hA6A4fS09598; Thu, 6 Nov 2003 19:04:41 +0900 (JST) Received: from STRATOS ([10.96.152.147]) by mrit.mrit.mei.co.jp (8.12.6p2/3.7W-03060222) with SMTP id hA6A4Z2t034944; Thu, 6 Nov 2003 19:04:37 +0900 (JST) Message-Id: <200311061004.hA6A4Z2t034944@mrit.mrit.mei.co.jp> Date: Thu, 06 Nov 2003 10:04:58 +0000 From: MATSUMOTO Taisuke Subject: Re: [NEMO] Behavior of HA To: "Thierry Ernst" Cc: "Vijay Devarapalli" , cam@blueyonder.co.uk, nemo@ietf.org Organization: Matsushita Electric Industrial Co., Ltd. In-Reply-To: <20031106110908.113f2a5d.ernst@sfc.wide.ad.jp> References: <3FA956EB.9020307@iprg.nokia.com> <20031106110908.113f2a5d.ernst@sfc.wide.ad.jp> X-Mailer: Datula version 1.52.01 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hi Thierry and all, > > > Should the spec make this clear? > > > > section 3 contains > > > > A Mobile Router has an unique Home Address through which it is always > > reachable. The Home Address is configured from a prefix that is > > aggregated and advertised by its Home Agent. The prefix could either > > be the prefix advertised on the home link or the prefix delegated to > > the Mobile Router. The Mobile Router can have more than one Home > > Address if there are multiple prefixes in the home link. > > > > what clarification are you looking for? > > May be a mention about "ingress interface" or "egress interface" of the MR ? > > But my understanding is that this will be clarified in other document, won't it ? I'm sorry but I feel difficult to agree with your opinion. I think that the nemo basic support document should be enough to implement the basic mobile network. I could implement the explicit prefix length mode because I knew Mr. Wakikawa's personal draft inputed before the San Francisco meeting. But after I read Mr./Ms. Cam's mail, I think that the basic support draft should be revised to have the clear description about the configuration of entities. Any comments? Taisuke From nemo-admin@ietf.org Thu Nov 6 16:18:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01584 for ; Thu, 6 Nov 2003 16:18:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrVx-0004eP-RB; Thu, 06 Nov 2003 16: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 1AHrV0-0004cH-Cb for nemo@optimus.ietf.org; Thu, 06 Nov 2003 16:17: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 QAA01449 for ; Thu, 6 Nov 2003 16:16:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrUy-0000hz-00 for nemo@ietf.org; Thu, 06 Nov 2003 16:17:00 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AHrUx-0000ht-00 for nemo@ietf.org; Thu, 06 Nov 2003 16:16:59 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id hA6LGwJl024200; Thu, 6 Nov 2003 14:16:58 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id hA6LGtBJ011733; Thu, 6 Nov 2003 15:16:57 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 7074E2EC95; Thu, 6 Nov 2003 22:16:56 +0100 (CET) Message-ID: <3FAABA48.6060603@motorola.com> Date: Thu, 06 Nov 2003 22:16:56 +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: KyeongJin Lee Cc: nemo@ietf.org Subject: Re: [nemo] BA(status 140) in explicit mode. References: <015f01c3a42e$64a8f0b0$ac70fe81@kjlee> In-Reply-To: <015f01c3a42e$64a8f0b0$ac70fe81@kjlee> 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 KyeongJin Lee wrote: > Hi, I've a question on the NEMO Basic Support. > > in sect 6.2 When a HA received BU with R flag set, if the H flag is > not set, the HA send BA with status set to 140 to MR. > > but in sect 5 MR MUST discard BA(status 140) if it is not operate in > implicit mode. This so happens because the 4 BAck error messages (140...143) are split in two sets: 140 and 143 for implicit mode and 141 and 142 for explicit mode. If the MR sends a BU to HA in implicit mode and receives 140 it will try the other two explicit modes. If the MR sends a BU to HA in explicit mode and receives 140 it will simply discard the error and then that's it, end of the story, its HA doesn't support network mobility. > I wonder why the MR MUST discard the BA(status 140) in explicit mode. > I think MR must process the BA status 140 in all 3 modes. Ok, I agree that error processing is difficult to make work. Finding errors in the error processing procedure itself is a neverending story. If we put the forced end as above then loops are avoided. A loop can appear when MR cycles between various modes and various HA's and always getting 140 back. So we were trying to avoid this loop. No? Alex GBU From exim@www1.ietf.org Thu Nov 6 16:18:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01599 for ; Thu, 6 Nov 2003 16:18: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 1AHrW7-0004fz-1Y for nemo-archive@odin.ietf.org; Thu, 06 Nov 2003 16:18:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6LIAKs017969 for nemo-archive@odin.ietf.org; Thu, 6 Nov 2003 16:18:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrW6-0004fk-Sw for nemo-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 16:18: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 QAA01550 for ; Thu, 6 Nov 2003 16:17:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrW5-0000ja-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 16:18:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHrW4-0000jV-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 16:18:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrVx-0004eP-RB; Thu, 06 Nov 2003 16: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 1AHrV0-0004cH-Cb for nemo@optimus.ietf.org; Thu, 06 Nov 2003 16:17: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 QAA01449 for ; Thu, 6 Nov 2003 16:16:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrUy-0000hz-00 for nemo@ietf.org; Thu, 06 Nov 2003 16:17:00 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AHrUx-0000ht-00 for nemo@ietf.org; Thu, 06 Nov 2003 16:16:59 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id hA6LGwJl024200; Thu, 6 Nov 2003 14:16:58 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id hA6LGtBJ011733; Thu, 6 Nov 2003 15:16:57 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 7074E2EC95; Thu, 6 Nov 2003 22:16:56 +0100 (CET) Message-ID: <3FAABA48.6060603@motorola.com> Date: Thu, 06 Nov 2003 22:16:56 +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: KyeongJin Lee Cc: nemo@ietf.org Subject: Re: [nemo] BA(status 140) in explicit mode. References: <015f01c3a42e$64a8f0b0$ac70fe81@kjlee> In-Reply-To: <015f01c3a42e$64a8f0b0$ac70fe81@kjlee> 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 KyeongJin Lee wrote: > Hi, I've a question on the NEMO Basic Support. > > in sect 6.2 When a HA received BU with R flag set, if the H flag is > not set, the HA send BA with status set to 140 to MR. > > but in sect 5 MR MUST discard BA(status 140) if it is not operate in > implicit mode. This so happens because the 4 BAck error messages (140...143) are split in two sets: 140 and 143 for implicit mode and 141 and 142 for explicit mode. If the MR sends a BU to HA in implicit mode and receives 140 it will try the other two explicit modes. If the MR sends a BU to HA in explicit mode and receives 140 it will simply discard the error and then that's it, end of the story, its HA doesn't support network mobility. > I wonder why the MR MUST discard the BA(status 140) in explicit mode. > I think MR must process the BA status 140 in all 3 modes. Ok, I agree that error processing is difficult to make work. Finding errors in the error processing procedure itself is a neverending story. If we put the forced end as above then loops are avoided. A loop can appear when MR cycles between various modes and various HA's and always getting 140 back. So we were trying to avoid this loop. No? Alex GBU From nemo-admin@ietf.org Thu Nov 6 16:33:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02173 for ; Thu, 6 Nov 2003 16:33: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 1AHrkT-00051Q-4K; Thu, 06 Nov 2003 16:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrkQ-00050m-3Q for nemo@optimus.ietf.org; Thu, 06 Nov 2003 16:32: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 QAA02144 for ; Thu, 6 Nov 2003 16:32:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrkO-0000wu-00 for nemo@ietf.org; Thu, 06 Nov 2003 16:32:56 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AHrkN-0000wr-00 for nemo@ietf.org; Thu, 06 Nov 2003 16:32:55 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hA6LWq4W005270; Thu, 6 Nov 2003 14:32:52 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id hA6LWnkl006396; Thu, 6 Nov 2003 15:32:50 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 7191A2EC95; Thu, 6 Nov 2003 22:32:49 +0100 (CET) Message-ID: <3FAABE01.9030500@motorola.com> Date: Thu, 06 Nov 2003 22:32: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: cam Cc: nemo@ietf.org Subject: Re: [NEMO] Behavior of HA References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit cam wrote: > As a side issue, am I right in saying that the assumption for > Explicit Prefix Length Mode is that the Home Address is the address > on the MR's ingress interface? This is something that confused me > when I recently read the NEMO spec. I had thought, as with MIPv6, > that the Home Address would be the address on the egress interface > and so, couldn't see how the prefix could be obtained from the Home > Address. With implicit mode and explicit network mode, the Home Address is indeed the address of the egress interface (the one that connects to the home link). People are free to implement whatever mode they see best fit. With explicit prefix len mode, one could try to get a better understanding by reading the explicit prefix len companion draft-thubert-nemo-basic-usages-00.txt that describes particular home networks that best accomodate the explicit prefix len mode. > Should the spec make this clear? There are several ways in which this spec can make the explicit prefix len mode clearer. One would be to eliminate entirely this mode from basic, another would be to change the draft-thubert-... into a WG item and yet another way would be to add a short phrase somewhere in the current basic draft. In this latter way please suggest a short phrase that looks clear to you cam (Camelia? C.A.M.?). Also, if one considers the IPR aspects then it seems that the explicit prefix len mode is the only non-IPR'ed mode, that adds to the discussion. Alex GBU From exim@www1.ietf.org Thu Nov 6 16:33:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02194 for ; Thu, 6 Nov 2003 16:33: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 1AHrkX-00052e-55 for nemo-archive@odin.ietf.org; Thu, 06 Nov 2003 16:33:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6LX59F019381 for nemo-archive@odin.ietf.org; Thu, 6 Nov 2003 16:33:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrkW-00052W-Vh for nemo-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 16:33: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 QAA02155 for ; Thu, 6 Nov 2003 16:32:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrkV-0000xK-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 16:33:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHrkU-0000xH-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 16:33:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrkT-00051Q-4K; Thu, 06 Nov 2003 16:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrkQ-00050m-3Q for nemo@optimus.ietf.org; Thu, 06 Nov 2003 16:32: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 QAA02144 for ; Thu, 6 Nov 2003 16:32:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrkO-0000wu-00 for nemo@ietf.org; Thu, 06 Nov 2003 16:32:56 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AHrkN-0000wr-00 for nemo@ietf.org; Thu, 06 Nov 2003 16:32:55 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hA6LWq4W005270; Thu, 6 Nov 2003 14:32:52 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id hA6LWnkl006396; Thu, 6 Nov 2003 15:32:50 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 7191A2EC95; Thu, 6 Nov 2003 22:32:49 +0100 (CET) Message-ID: <3FAABE01.9030500@motorola.com> Date: Thu, 06 Nov 2003 22:32: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: cam Cc: nemo@ietf.org Subject: Re: [NEMO] Behavior of HA References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit cam wrote: > As a side issue, am I right in saying that the assumption for > Explicit Prefix Length Mode is that the Home Address is the address > on the MR's ingress interface? This is something that confused me > when I recently read the NEMO spec. I had thought, as with MIPv6, > that the Home Address would be the address on the egress interface > and so, couldn't see how the prefix could be obtained from the Home > Address. With implicit mode and explicit network mode, the Home Address is indeed the address of the egress interface (the one that connects to the home link). People are free to implement whatever mode they see best fit. With explicit prefix len mode, one could try to get a better understanding by reading the explicit prefix len companion draft-thubert-nemo-basic-usages-00.txt that describes particular home networks that best accomodate the explicit prefix len mode. > Should the spec make this clear? There are several ways in which this spec can make the explicit prefix len mode clearer. One would be to eliminate entirely this mode from basic, another would be to change the draft-thubert-... into a WG item and yet another way would be to add a short phrase somewhere in the current basic draft. In this latter way please suggest a short phrase that looks clear to you cam (Camelia? C.A.M.?). Also, if one considers the IPR aspects then it seems that the explicit prefix len mode is the only non-IPR'ed mode, that adds to the discussion. Alex GBU From nemo-admin@ietf.org Thu Nov 6 16:38:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02419 for ; Thu, 6 Nov 2003 16:38: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 1AHrpJ-0005VY-9N; Thu, 06 Nov 2003 16: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 1AHroo-0005PR-AA for nemo@optimus.ietf.org; Thu, 06 Nov 2003 16:37: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 QAA02385 for ; Thu, 6 Nov 2003 16:37:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrom-000109-00 for nemo@ietf.org; Thu, 06 Nov 2003 16:37:28 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AHrol-0000za-00 for nemo@ietf.org; Thu, 06 Nov 2003 16:37:27 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA6Laoo16217; Thu, 6 Nov 2003 13:36:50 -0800 X-mProtect: <200311062136> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAjUEQa; Thu, 06 Nov 2003 13:36:49 PST Message-ID: <3FAABFB8.1040208@iprg.nokia.com> Date: Thu, 06 Nov 2003 13:40:08 -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: MATSUMOTO Taisuke CC: nemo@ietf.org Subject: Re: [nemo] Behavior of HA References: <200311051221.hA5CLh2t075968@mrit.mrit.mei.co.jp> <3FA95896.7010002@iprg.nokia.com> <200311060946.hA69k32t032659@mrit.mrit.mei.co.jp> In-Reply-To: <200311060946.hA69k32t032659@mrit.mrit.mei.co.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 MATSUMOTO Taisuke wrote: > Hi Vijay, > > Thank you for your response. > > >>>So, I think that some schemes to avoid that restriction of the >>>mobile IPv6 specifications is required for the NEMO basic support. >> >>yes. the mobile IPv6 restriction needs to be relaxed. currently >>section 10.3.1 of MIPv6 says >> >> if the home address for the binding (the Home Address field >> in the packet's Home Address option) is not an on-link IPv6 >> address with respect to the home agent's current Prefix List, then >> the home agent MUST reject the Binding Update and SHOULD return a >> Binding Acknowledgement to the mobile node, in which the Status >> field is set to 132 (not home subnet). >> >>for Nemo, the Home Agent should not reject the Binding if the >>home address is from a prefix that has been delegated to a >>Mobile Router. >> > > I think that your comment is reasonabie. But I have another > question how to know if the prefix is delegated to the mobile > router. If it should be pre-configured in the home agent, it makes > the explicit prefix length mode lose an advantage to the implicit > mode. looks like what I suggested earlier might not be a good idea at all. instead, here is another proposal. Mobile IPv6 specifies that the Home Agent should reject a Binding Update if the home address in the received Binding Update is not an on-link IPv6 address with respect to the prefixes being advertised on the home link. This document relaxes this restriction so that the Home Agent should reject the Binding Update only if the home address does not belong to the home prefix that the Home Agent is serving. this is more generic. the Home Agent knows the home prefix that it is serving. if the Mobile Network Prefix is a subset of this prefix, then the Home Agent should accept binding updates from addresses configured from the Mobile Network Prefix. the Home Agent has to just verfiy that the home address belongs to the prefix it is serving. comments? Vijay From exim@www1.ietf.org Thu Nov 6 16:38:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02441 for ; Thu, 6 Nov 2003 16: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 1AHrpO-0005Xm-5b for nemo-archive@odin.ietf.org; Thu, 06 Nov 2003 16:38:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6Lc5j1021304 for nemo-archive@odin.ietf.org; Thu, 6 Nov 2003 16:38:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrpM-0005Wx-RQ for nemo-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 16: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 QAA02408 for ; Thu, 6 Nov 2003 16:37:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrpK-00010a-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 16:38:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHrpK-00010X-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 16:38:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrpJ-0005VY-9N; Thu, 06 Nov 2003 16: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 1AHroo-0005PR-AA for nemo@optimus.ietf.org; Thu, 06 Nov 2003 16:37: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 QAA02385 for ; Thu, 6 Nov 2003 16:37:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrom-000109-00 for nemo@ietf.org; Thu, 06 Nov 2003 16:37:28 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AHrol-0000za-00 for nemo@ietf.org; Thu, 06 Nov 2003 16:37:27 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA6Laoo16217; Thu, 6 Nov 2003 13:36:50 -0800 X-mProtect: <200311062136> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAjUEQa; Thu, 06 Nov 2003 13:36:49 PST Message-ID: <3FAABFB8.1040208@iprg.nokia.com> Date: Thu, 06 Nov 2003 13:40:08 -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: MATSUMOTO Taisuke CC: nemo@ietf.org Subject: Re: [nemo] Behavior of HA References: <200311051221.hA5CLh2t075968@mrit.mrit.mei.co.jp> <3FA95896.7010002@iprg.nokia.com> <200311060946.hA69k32t032659@mrit.mrit.mei.co.jp> In-Reply-To: <200311060946.hA69k32t032659@mrit.mrit.mei.co.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 MATSUMOTO Taisuke wrote: > Hi Vijay, > > Thank you for your response. > > >>>So, I think that some schemes to avoid that restriction of the >>>mobile IPv6 specifications is required for the NEMO basic support. >> >>yes. the mobile IPv6 restriction needs to be relaxed. currently >>section 10.3.1 of MIPv6 says >> >> if the home address for the binding (the Home Address field >> in the packet's Home Address option) is not an on-link IPv6 >> address with respect to the home agent's current Prefix List, then >> the home agent MUST reject the Binding Update and SHOULD return a >> Binding Acknowledgement to the mobile node, in which the Status >> field is set to 132 (not home subnet). >> >>for Nemo, the Home Agent should not reject the Binding if the >>home address is from a prefix that has been delegated to a >>Mobile Router. >> > > I think that your comment is reasonabie. But I have another > question how to know if the prefix is delegated to the mobile > router. If it should be pre-configured in the home agent, it makes > the explicit prefix length mode lose an advantage to the implicit > mode. looks like what I suggested earlier might not be a good idea at all. instead, here is another proposal. Mobile IPv6 specifies that the Home Agent should reject a Binding Update if the home address in the received Binding Update is not an on-link IPv6 address with respect to the prefixes being advertised on the home link. This document relaxes this restriction so that the Home Agent should reject the Binding Update only if the home address does not belong to the home prefix that the Home Agent is serving. this is more generic. the Home Agent knows the home prefix that it is serving. if the Mobile Network Prefix is a subset of this prefix, then the Home Agent should accept binding updates from addresses configured from the Mobile Network Prefix. the Home Agent has to just verfiy that the home address belongs to the prefix it is serving. comments? Vijay From nemo-admin@ietf.org Thu Nov 6 17:02:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03818 for ; Thu, 6 Nov 2003 17:02: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 1AHsCY-0007dW-CM; Thu, 06 Nov 2003 17: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 1AHsCM-0007cN-JO for nemo@optimus.ietf.org; Thu, 06 Nov 2003 17:01: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 RAA03792 for ; Thu, 6 Nov 2003 17:01:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsCK-0001WG-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:01:48 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1AHsCJ-0001WD-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:01:47 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id hA6M1hSr001696 for ; Thu, 6 Nov 2003 15:01:45 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id hA6M1IBJ019583 for ; Thu, 6 Nov 2003 16:01:21 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 17ED92EC95 for ; Thu, 6 Nov 2003 23:01:19 +0100 (CET) Message-ID: <3FAAC4AE.5060602@motorola.com> Date: Thu, 06 Nov 2003 23:01:18 +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] Short comment on draft-thubert-nemo-basic-usages-00 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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 to authors of draft-thubert-nemo-basic-usages-00.txt I think the words "Examples of basic nemo usages" in the title are claiming more than the draft actually describes. The draft mainly describes the architecture of the home network, or NEMO is about the home network _and_ the mobile network. I would suggest a better title to say "Examples of home networks for NEMO". > 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. ...and in which case there is no need for Proxy ND (an essential feature of MIPv6), or there is a need for a Virtual Proxy ND, to be figured out. > With Mobile IPv6, the Home Network is generally a physical network > interconnecting the Home Agents, It would sound better IMHO to say that a MIPv6 Home Network is a physical _link_ (instead of a physical network). Network sounds to me like yes being physical, but having routers connecting links, or the MIPv6 home network linking the HA's together has no routers in between. Finally, I think that the draft misses an important opportunity to first describe a simple MIPv6 home network that accomodates NEMO mobile networks (implicit and explicit network modes), which is the following: | route v /48 HA | /52 --+-----+--+- . -+- . -+-- | | | | MR1 MR2 MRi MRN /56 /56 /56 /56 In this home network the prefixes are aggregated. If one wonders how can a link be assigned a shorter-than-64 prefix and still have the stateless autoconfiguration work then one needs to consider that the length of the prefixlen advertised by RA on that link is not necessarily the prefix len in the routing tables of routers pointing to that link. In other words, HA's rt entry towards MR1 would be len 56 but MR1 would send RA's with prefix len 64 inside on its first link such that its first-level LFN's could configure IPv6 addresses with their Ethernet-like cards. Note that RFC2462 does not relate the prefix lens in the RA to the prefix lens existing in routing tables. That doc acknowledges that most people use EUI-64 and asks that: > It is the responsibility of the system administrator to insure that > the lengths of prefixes contained in Router Advertisements are > consistent with the length of interface identifiers for that link > type. So, I would suggest to add a simple description of this simple home network and say what are its problems. Alex GBU From nemo-admin@ietf.org Thu Nov 6 17:04:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04008 for ; Thu, 6 Nov 2003 17:04: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 1AHsET-0007kQ-O9; Thu, 06 Nov 2003 17:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsEO-0007jr-29 for nemo@optimus.ietf.org; Thu, 06 Nov 2003 17:03:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03898 for ; Thu, 6 Nov 2003 17:03:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsEL-0001YL-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:03:53 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AHsEK-0001Xj-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:03:53 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA6M3Du07488; Thu, 6 Nov 2003 14:03:13 -0800 X-mProtect: <200311062203> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBUgbKm; Thu, 06 Nov 2003 14:03:12 PST Message-ID: <3FAAC5E7.80205@iprg.nokia.com> Date: Thu, 06 Nov 2003 14:06: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: Chan-Wah NG CC: IETF NEMO WG Subject: Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt References: <1068024404.6779.27.camel@localhost> <3FA93FF0.9060608@iprg.nokia.com> <1068094146.11301.127.camel@localhost> In-Reply-To: <1068094146.11301.127.camel@localhost> 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 Chan-Wah NG wrote: >>section 5.2 >> >> The Mobile Router uses >> one of the following modes to instruct the Home Agent to determine >> the prefixes owned by the Mobile Router. In all three modes, the >> Mobile Router sets the Mobile Router flag 'R'. >> > > > I would actually prefer a stronger indication involving one of the MUST > MIGHT SHOULD etc keywords, but that's just me. MUST/SHOULD are sometimes indiscriminately. they should be used mainly to make sure the protocol is interoperable. for example saying "the Mobile Router should do..." is stronger than saying "the Mobile Router SHOULD do...". in this particular case, we are just describing the basic protocol operation. there is no question of the Mobile Router not using any of the three modes specified in the draft. there is no need for these keywords. >>section 7 is about >>dynamic routing protocol messages. routing protocol messages from the >>Home Agent to the Mobile Router could potentially contain a lot of >>information about the internal routing structure of the home domain. >>simple authentication wont be enough if these messages could be >>observed by others. that is why the strict requirement. >> > > > Yes, I understand that as well. I am not questioning the need to > encrypt tunnel packets containing routing protocols messages. I am just > asking do we need to limit the encryption mechanism to ESP? I understand > ESP is the currently prevailing (perhaps even the only) mechanism that > encrypt a payload packet in tunneled mode, but there might be new > protocols in the future. By saying "tunneled routing messages MUST be > authenticated and encrypted by using IPsec ESP in tunnel mode", you are > closing the door to using other mechanisms. I would prefer the MIPv6 > style of saying saying the tunnel messages must be encrypted,and using > ESP as the encryption mechanism MUST be supported and SHOULD be used by > MR and HA". good point. I am fine with SHOULD. others? Vijay From exim@www1.ietf.org Thu Nov 6 17:04:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04023 for ; Thu, 6 Nov 2003 17:04: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 1AHsEV-0007mg-4M for nemo-archive@odin.ietf.org; Thu, 06 Nov 2003 17:04:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6M43aH029916 for nemo-archive@odin.ietf.org; Thu, 6 Nov 2003 17:04:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsEU-0007mR-Ue for nemo-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 17:04: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 RAA03905 for ; Thu, 6 Nov 2003 17:03:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsES-0001YW-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 17:04:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHsES-0001YT-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 17:04:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsET-0007kQ-O9; Thu, 06 Nov 2003 17:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsEO-0007jr-29 for nemo@optimus.ietf.org; Thu, 06 Nov 2003 17:03:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03898 for ; Thu, 6 Nov 2003 17:03:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsEL-0001YL-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:03:53 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AHsEK-0001Xj-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:03:53 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA6M3Du07488; Thu, 6 Nov 2003 14:03:13 -0800 X-mProtect: <200311062203> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBUgbKm; Thu, 06 Nov 2003 14:03:12 PST Message-ID: <3FAAC5E7.80205@iprg.nokia.com> Date: Thu, 06 Nov 2003 14:06: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: Chan-Wah NG CC: IETF NEMO WG Subject: Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt References: <1068024404.6779.27.camel@localhost> <3FA93FF0.9060608@iprg.nokia.com> <1068094146.11301.127.camel@localhost> In-Reply-To: <1068094146.11301.127.camel@localhost> 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 Chan-Wah NG wrote: >>section 5.2 >> >> The Mobile Router uses >> one of the following modes to instruct the Home Agent to determine >> the prefixes owned by the Mobile Router. In all three modes, the >> Mobile Router sets the Mobile Router flag 'R'. >> > > > I would actually prefer a stronger indication involving one of the MUST > MIGHT SHOULD etc keywords, but that's just me. MUST/SHOULD are sometimes indiscriminately. they should be used mainly to make sure the protocol is interoperable. for example saying "the Mobile Router should do..." is stronger than saying "the Mobile Router SHOULD do...". in this particular case, we are just describing the basic protocol operation. there is no question of the Mobile Router not using any of the three modes specified in the draft. there is no need for these keywords. >>section 7 is about >>dynamic routing protocol messages. routing protocol messages from the >>Home Agent to the Mobile Router could potentially contain a lot of >>information about the internal routing structure of the home domain. >>simple authentication wont be enough if these messages could be >>observed by others. that is why the strict requirement. >> > > > Yes, I understand that as well. I am not questioning the need to > encrypt tunnel packets containing routing protocols messages. I am just > asking do we need to limit the encryption mechanism to ESP? I understand > ESP is the currently prevailing (perhaps even the only) mechanism that > encrypt a payload packet in tunneled mode, but there might be new > protocols in the future. By saying "tunneled routing messages MUST be > authenticated and encrypted by using IPsec ESP in tunnel mode", you are > closing the door to using other mechanisms. I would prefer the MIPv6 > style of saying saying the tunnel messages must be encrypted,and using > ESP as the encryption mechanism MUST be supported and SHOULD be used by > MR and HA". good point. I am fine with SHOULD. others? Vijay From nemo-admin@ietf.org Thu Nov 6 17:20:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04736 for ; Thu, 6 Nov 2003 17:20: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 1AHsU0-0000mP-9R; Thu, 06 Nov 2003 17: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 1AHsTm-0000jT-W2 for nemo@optimus.ietf.org; Thu, 06 Nov 2003 17:19: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 RAA04688 for ; Thu, 6 Nov 2003 17:19:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsTk-0001qy-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:19:48 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AHsTj-0001qp-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:19:47 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id hA6MJeJl019632; Thu, 6 Nov 2003 15:19:40 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hA6MFfAY022663; Thu, 6 Nov 2003 16:15:43 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 41EE42EC95; Thu, 6 Nov 2003 23:15:41 +0100 (CET) Message-ID: <3FAAC80D.6020901@motorola.com> Date: Thu, 06 Nov 2003 23:15:41 +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: William D Ivancic , nemo@ietf.org Subject: Re: [nemo] Nemo Basic Support - IP in IP tunneling vs NAT transversal References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Note that Doors should work with the T-Mobile IPv4 infrastructure an > dtheir active filters, at least if IP-in-UDP does for IPv4 mobile > tunnels. Until the day T-Mobile realizes that Doors bubbles try to get through so T-Mobile will stop the Doors bubbles too, no? Filters mean that they look at every bit of the packet (from IP version number up to TCP/UDP headers HTTP data and even at the last bit of the payload). So they can filter out whatever they want. I think the only way one could get through this is to imagine a protocol with an apparently random bit pattern but following a strict rule known only by the two nodes (one behind T-Mobile and one outside). And this implying secrecy (don't tell this rule to T-Mobile), can not be standardized. Alex GBU From exim@www1.ietf.org Thu Nov 6 17:20:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04763 for ; Thu, 6 Nov 2003 17:20: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 1AHsU8-0000pV-GE for nemo-archive@odin.ietf.org; Thu, 06 Nov 2003 17:20:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6MKCka003156 for nemo-archive@odin.ietf.org; Thu, 6 Nov 2003 17:20:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsU7-0000on-Us for nemo-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 17: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 RAA04711 for ; Thu, 6 Nov 2003 17:19:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsU5-0001rY-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 17:20:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHsU5-0001rV-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 17:20:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsU0-0000mP-9R; Thu, 06 Nov 2003 17: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 1AHsTm-0000jT-W2 for nemo@optimus.ietf.org; Thu, 06 Nov 2003 17:19: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 RAA04688 for ; Thu, 6 Nov 2003 17:19:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsTk-0001qy-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:19:48 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AHsTj-0001qp-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:19:47 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id hA6MJeJl019632; Thu, 6 Nov 2003 15:19:40 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hA6MFfAY022663; Thu, 6 Nov 2003 16:15:43 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 41EE42EC95; Thu, 6 Nov 2003 23:15:41 +0100 (CET) Message-ID: <3FAAC80D.6020901@motorola.com> Date: Thu, 06 Nov 2003 23:15:41 +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: William D Ivancic , nemo@ietf.org Subject: Re: [nemo] Nemo Basic Support - IP in IP tunneling vs NAT transversal References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Note that Doors should work with the T-Mobile IPv4 infrastructure an > dtheir active filters, at least if IP-in-UDP does for IPv4 mobile > tunnels. Until the day T-Mobile realizes that Doors bubbles try to get through so T-Mobile will stop the Doors bubbles too, no? Filters mean that they look at every bit of the packet (from IP version number up to TCP/UDP headers HTTP data and even at the last bit of the payload). So they can filter out whatever they want. I think the only way one could get through this is to imagine a protocol with an apparently random bit pattern but following a strict rule known only by the two nodes (one behind T-Mobile and one outside). And this implying secrecy (don't tell this rule to T-Mobile), can not be standardized. Alex GBU From nemo-admin@ietf.org Thu Nov 6 17:25:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05046 for ; Thu, 6 Nov 2003 17:25: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 1AHsYo-0001Qp-2q; Thu, 06 Nov 2003 17:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsYU-0001QF-K7 for nemo@optimus.ietf.org; Thu, 06 Nov 2003 17:24: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 RAA04995 for ; Thu, 6 Nov 2003 17:24:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsYS-0001wF-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:24:40 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AHsYR-0001vx-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:24:39 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA6MNsN21162; Thu, 6 Nov 2003 14:23:54 -0800 X-mProtect: <200311062223> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpduympNZ; Thu, 06 Nov 2003 14:23:52 PST Message-ID: <3FAACABF.2010003@iprg.nokia.com> Date: Thu, 06 Nov 2003 14:27: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: Alexandru Petrescu CC: nemo@ietf.org Subject: Re: [nemo] Short comment on draft-thubert-nemo-basic-usages-00 References: <3FAAC4AE.5060602@motorola.com> In-Reply-To: <3FAAC4AE.5060602@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 hi Alex, Alexandru Petrescu wrote: > > | > route v /48 > > HA > | /52 > --+-----+--+- . -+- . -+-- > | | | | > MR1 MR2 MRi MRN > /56 /56 /56 /56 > the draft currently has HA | /56 Aggreg /56 --+-----+--+- . -+- . -+-- | | | | MR1 MR2 MRi MRN ------ ------ ------ ------ /64 /64 /64 /64 Aggreg|i /64 0 < i <= N arent both same? only the prefix lengths are different. Vijay From exim@www1.ietf.org Thu Nov 6 17:25:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05061 for ; Thu, 6 Nov 2003 17:25: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 1AHsYq-0001SE-5u for nemo-archive@odin.ietf.org; Thu, 06 Nov 2003 17:25:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6MP4oT005584 for nemo-archive@odin.ietf.org; Thu, 6 Nov 2003 17:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsYq-0001Rz-0i for nemo-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 17:25: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 RAA05017 for ; Thu, 6 Nov 2003 17:24:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsYn-0001wj-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 17:25:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHsYn-0001wg-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 17:25:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsYo-0001Qp-2q; Thu, 06 Nov 2003 17:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsYU-0001QF-K7 for nemo@optimus.ietf.org; Thu, 06 Nov 2003 17:24: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 RAA04995 for ; Thu, 6 Nov 2003 17:24:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsYS-0001wF-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:24:40 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AHsYR-0001vx-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:24:39 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA6MNsN21162; Thu, 6 Nov 2003 14:23:54 -0800 X-mProtect: <200311062223> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpduympNZ; Thu, 06 Nov 2003 14:23:52 PST Message-ID: <3FAACABF.2010003@iprg.nokia.com> Date: Thu, 06 Nov 2003 14:27: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: Alexandru Petrescu CC: nemo@ietf.org Subject: Re: [nemo] Short comment on draft-thubert-nemo-basic-usages-00 References: <3FAAC4AE.5060602@motorola.com> In-Reply-To: <3FAAC4AE.5060602@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 hi Alex, Alexandru Petrescu wrote: > > | > route v /48 > > HA > | /52 > --+-----+--+- . -+- . -+-- > | | | | > MR1 MR2 MRi MRN > /56 /56 /56 /56 > the draft currently has HA | /56 Aggreg /56 --+-----+--+- . -+- . -+-- | | | | MR1 MR2 MRi MRN ------ ------ ------ ------ /64 /64 /64 /64 Aggreg|i /64 0 < i <= N arent both same? only the prefix lengths are different. Vijay From nemo-admin@ietf.org Thu Nov 6 17:29:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05186 for ; Thu, 6 Nov 2003 17: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 1AHscf-0001bk-Fx; Thu, 06 Nov 2003 17: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 1AHscH-0001ag-P7 for nemo@optimus.ietf.org; Thu, 06 Nov 2003 17:28: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 RAA05155 for ; Thu, 6 Nov 2003 17:28:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHscF-0001zv-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:28:35 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AHscE-0001zs-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:28:34 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hA6MRa7q018533; Thu, 6 Nov 2003 15:27:38 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id hA6MSELU001367; Thu, 6 Nov 2003 16:28:14 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id E435A2EC95; Thu, 6 Nov 2003 23:28:14 +0100 (CET) Message-ID: <3FAACAFE.7060605@motorola.com> Date: Thu, 06 Nov 2003 23:28:14 +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: William D Ivancic Cc: nemo@ietf.org Subject: Re: [nemo] Nemo Basic Support - IP in IP tunneling vs NAT transversal References: <5.1.1.5.2.20031104110908.01fc42b0@popserve.grc.nasa.gov> In-Reply-To: <5.1.1.5.2.20031104110908.01fc42b0@popserve.grc.nasa.gov> 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 William D Ivancic wrote: > From the basic support document page 7: > > " Once the binding process completes, a bi-directional tunnel is > established between the Home Agent and the Mobile Router. The tunnel > end points are Mobile Router's Care-of Address and the Home Agent's > address. If a packet with a source address belonging to the Mobile > Network Prefix is received from the Mobile Network, the Mobile Router > reverse-tunnels the packet to the Home Agent through this tunnel. > This reverse-tunneling is done by using IP-in-IP encapsulation [3]. " > > In the requirements document, one of the requirements is to make sure we > consider NATs. Although most may consider NATs to only exist in IPv4, > I strongly suspect they will occur in IPv6 in order to manage security > at a single location (rather that to increase the available address space). > > Thus, should we consider something like IP-in-UDP encapsulation also. I > believe this is the solution for NAT transversal in IPv4. Even if we don't consider IPv6 NAT's, _most_ (in number of users) cellular access systems today are NAT and probably in future too (3GPP/UMTS was apparently considering IPv6 but my first glimpses into _some_ UMTS deployment looks not only to be v4 but also behind NAT). In this context, if one wants to connect a NEMO (exclusively Mobile IPv6 no Mobile IPv4) to such a wide reach cellular access system, one does need a form of NAT traversal. The optimization that may exist for this problem, maybe, is to consider that the tunnel between MR and HA may be actually the NAT traversal tunnel, such as less encapsulation. > Note, this is not necessarily just a NAT issue. I was running IPv4 > mobile network code (Cisco Systems IOS version) in T-Mobile's network > (GPRS) with public address space. It was working until they implemented > a security policy that stopped data into the T-Mobile network unless it > originated from the T-Mobile network. Thus, they are not NATing, but > they are administratively filtering. I believe NAT transversal code > will solve this, but have not tried it yet. > > I was able to obtain information from T-Mobile indicating that the > policy was put in place to keep excess traffic off of the GPRS network > (excess traffic was being generated by Internet address searching > software and worms. T-Mobile indicated that the GPRS links are > considered valuable resources that need to be protected. They were > unwilling to change their policy. Thanks for this description, it is very good to know. A suggestion for T-Mobile is to consider filtering out bad worms coming from outside (and not the legitimate users coming from inside). The problem of filtering out outside worms is as hard as defending from an insider trying to traverse, only it looks to them easier to filter the insiders. Alex GBU From exim@www1.ietf.org Thu Nov 6 17:29:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05202 for ; Thu, 6 Nov 2003 17:29: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 1AHscg-0001ck-P6 for nemo-archive@odin.ietf.org; Thu, 06 Nov 2003 17:29:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6MT28C006236 for nemo-archive@odin.ietf.org; Thu, 6 Nov 2003 17:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHscg-0001cV-KH for nemo-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 17: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 RAA05171 for ; Thu, 6 Nov 2003 17:28:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsce-00020K-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 17:29:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHscd-00020E-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 17: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 1AHscf-0001bk-Fx; Thu, 06 Nov 2003 17: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 1AHscH-0001ag-P7 for nemo@optimus.ietf.org; Thu, 06 Nov 2003 17:28: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 RAA05155 for ; Thu, 6 Nov 2003 17:28:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHscF-0001zv-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:28:35 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AHscE-0001zs-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:28:34 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hA6MRa7q018533; Thu, 6 Nov 2003 15:27:38 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id hA6MSELU001367; Thu, 6 Nov 2003 16:28:14 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id E435A2EC95; Thu, 6 Nov 2003 23:28:14 +0100 (CET) Message-ID: <3FAACAFE.7060605@motorola.com> Date: Thu, 06 Nov 2003 23:28:14 +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: William D Ivancic Cc: nemo@ietf.org Subject: Re: [nemo] Nemo Basic Support - IP in IP tunneling vs NAT transversal References: <5.1.1.5.2.20031104110908.01fc42b0@popserve.grc.nasa.gov> In-Reply-To: <5.1.1.5.2.20031104110908.01fc42b0@popserve.grc.nasa.gov> 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 William D Ivancic wrote: > From the basic support document page 7: > > " Once the binding process completes, a bi-directional tunnel is > established between the Home Agent and the Mobile Router. The tunnel > end points are Mobile Router's Care-of Address and the Home Agent's > address. If a packet with a source address belonging to the Mobile > Network Prefix is received from the Mobile Network, the Mobile Router > reverse-tunnels the packet to the Home Agent through this tunnel. > This reverse-tunneling is done by using IP-in-IP encapsulation [3]. " > > In the requirements document, one of the requirements is to make sure we > consider NATs. Although most may consider NATs to only exist in IPv4, > I strongly suspect they will occur in IPv6 in order to manage security > at a single location (rather that to increase the available address space). > > Thus, should we consider something like IP-in-UDP encapsulation also. I > believe this is the solution for NAT transversal in IPv4. Even if we don't consider IPv6 NAT's, _most_ (in number of users) cellular access systems today are NAT and probably in future too (3GPP/UMTS was apparently considering IPv6 but my first glimpses into _some_ UMTS deployment looks not only to be v4 but also behind NAT). In this context, if one wants to connect a NEMO (exclusively Mobile IPv6 no Mobile IPv4) to such a wide reach cellular access system, one does need a form of NAT traversal. The optimization that may exist for this problem, maybe, is to consider that the tunnel between MR and HA may be actually the NAT traversal tunnel, such as less encapsulation. > Note, this is not necessarily just a NAT issue. I was running IPv4 > mobile network code (Cisco Systems IOS version) in T-Mobile's network > (GPRS) with public address space. It was working until they implemented > a security policy that stopped data into the T-Mobile network unless it > originated from the T-Mobile network. Thus, they are not NATing, but > they are administratively filtering. I believe NAT transversal code > will solve this, but have not tried it yet. > > I was able to obtain information from T-Mobile indicating that the > policy was put in place to keep excess traffic off of the GPRS network > (excess traffic was being generated by Internet address searching > software and worms. T-Mobile indicated that the GPRS links are > considered valuable resources that need to be protected. They were > unwilling to change their policy. Thanks for this description, it is very good to know. A suggestion for T-Mobile is to consider filtering out bad worms coming from outside (and not the legitimate users coming from inside). The problem of filtering out outside worms is as hard as defending from an insider trying to traverse, only it looks to them easier to filter the insiders. Alex GBU From nemo-admin@ietf.org Thu Nov 6 17:44:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05831 for ; Thu, 6 Nov 2003 17:44: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 1AHsrC-0002at-3M; Thu, 06 Nov 2003 17: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 1AHsqx-0002aH-Ew for nemo@optimus.ietf.org; Thu, 06 Nov 2003 17:43: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 RAA05778 for ; Thu, 6 Nov 2003 17:43:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsqu-0002Fw-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:43:44 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1AHsqt-0002Ft-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:43:43 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id hA6MhfSr025524; Thu, 6 Nov 2003 15:43:41 -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 hA6Mgbcv028730; Thu, 6 Nov 2003 16:43:06 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 142EC2EC95; Thu, 6 Nov 2003 23:42:37 +0100 (CET) Message-ID: <3FAACE5C.3090508@motorola.com> Date: Thu, 06 Nov 2003 23:42:36 +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: Alexandru Petrescu , nemo@ietf.org Subject: Re: [nemo] Short comment on draft-thubert-nemo-basic-usages-00 References: <3FAAC4AE.5060602@motorola.com> <3FAACABF.2010003@iprg.nokia.com> In-Reply-To: <3FAACABF.2010003@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > hi Alex, > > Alexandru Petrescu wrote: > >> >> | >> route v /48 >> >> HA >> | /52 >> --+-----+--+- . -+- . -+-- >> | | | | >> MR1 MR2 MRi MRN >> /56 /56 /56 /56 >> > > the draft currently has > > HA > | /56 Aggreg /56 > --+-----+--+- . -+- . -+-- > | | | | > MR1 MR2 MRi MRN > ------ ------ ------ ------ > /64 /64 /64 /64 Aggreg|i /64 0 < i <= N > > > arent both same? only the prefix lengths are different. Right, looks to me like being the same; I had this doubt: having /64 below the MR suggests to me that there can not be another FR below MR that could support aggregation too (because can't reasonably have a /66 prefix below that FR and still send RA's with prefix len /64). Second, I find that, if we are on the same wavelength with the above descriptions, then they should appear at the beginning of the document (_before_ the extended, since it is the most basic home network). Third, section 5 that describes the above configuration says: > Note: a Mobile Router coming Home sees overlapping prefixes between > the ingress and the egress interface and some specific support may be > needed. I do not see any specific support that may be needed. > Thus, the Home Agent MUST intercept all the packets to the MNNs on > the registered prefixes. In order to do so, the Home Agent MAY > perform ND proxying for all addresses in all registered Mobile > Network Prefixes, and protect the Mobile Network Prefix space from > autoconfiguration by uncontrolled visitors on the Home Link. This paragraph I truly do not understand. In the picture of the home network that I did above there is no need for HA to perform ND proxying for all addresses in all registered Mobile Network Prefixes. HA does proxy ND only for the home addresses of the MR's. I do not understand also how does HA protect the MNP space from autoconfiguration by uncontrolled visitors on the Home Link. Is this a PANA or SEND or AAA related method? Alex From exim@www1.ietf.org Thu Nov 6 17:44:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05850 for ; Thu, 6 Nov 2003 17:44: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 1AHsrL-0002hI-04 for nemo-archive@odin.ietf.org; Thu, 06 Nov 2003 17:44:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6MiAC0010363 for nemo-archive@odin.ietf.org; Thu, 6 Nov 2003 17: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 1AHsrK-0002h0-KL for nemo-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 17: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 RAA05803 for ; Thu, 6 Nov 2003 17:43:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsrH-0002GM-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 17:44:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHsrH-0002GC-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 17:44:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsrC-0002at-3M; Thu, 06 Nov 2003 17: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 1AHsqx-0002aH-Ew for nemo@optimus.ietf.org; Thu, 06 Nov 2003 17:43: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 RAA05778 for ; Thu, 6 Nov 2003 17:43:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsqu-0002Fw-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:43:44 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1AHsqt-0002Ft-00 for nemo@ietf.org; Thu, 06 Nov 2003 17:43:43 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id hA6MhfSr025524; Thu, 6 Nov 2003 15:43:41 -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 hA6Mgbcv028730; Thu, 6 Nov 2003 16:43:06 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 142EC2EC95; Thu, 6 Nov 2003 23:42:37 +0100 (CET) Message-ID: <3FAACE5C.3090508@motorola.com> Date: Thu, 06 Nov 2003 23:42:36 +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: Alexandru Petrescu , nemo@ietf.org Subject: Re: [nemo] Short comment on draft-thubert-nemo-basic-usages-00 References: <3FAAC4AE.5060602@motorola.com> <3FAACABF.2010003@iprg.nokia.com> In-Reply-To: <3FAACABF.2010003@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > hi Alex, > > Alexandru Petrescu wrote: > >> >> | >> route v /48 >> >> HA >> | /52 >> --+-----+--+- . -+- . -+-- >> | | | | >> MR1 MR2 MRi MRN >> /56 /56 /56 /56 >> > > the draft currently has > > HA > | /56 Aggreg /56 > --+-----+--+- . -+- . -+-- > | | | | > MR1 MR2 MRi MRN > ------ ------ ------ ------ > /64 /64 /64 /64 Aggreg|i /64 0 < i <= N > > > arent both same? only the prefix lengths are different. Right, looks to me like being the same; I had this doubt: having /64 below the MR suggests to me that there can not be another FR below MR that could support aggregation too (because can't reasonably have a /66 prefix below that FR and still send RA's with prefix len /64). Second, I find that, if we are on the same wavelength with the above descriptions, then they should appear at the beginning of the document (_before_ the extended, since it is the most basic home network). Third, section 5 that describes the above configuration says: > Note: a Mobile Router coming Home sees overlapping prefixes between > the ingress and the egress interface and some specific support may be > needed. I do not see any specific support that may be needed. > Thus, the Home Agent MUST intercept all the packets to the MNNs on > the registered prefixes. In order to do so, the Home Agent MAY > perform ND proxying for all addresses in all registered Mobile > Network Prefixes, and protect the Mobile Network Prefix space from > autoconfiguration by uncontrolled visitors on the Home Link. This paragraph I truly do not understand. In the picture of the home network that I did above there is no need for HA to perform ND proxying for all addresses in all registered Mobile Network Prefixes. HA does proxy ND only for the home addresses of the MR's. I do not understand also how does HA protect the MNP space from autoconfiguration by uncontrolled visitors on the Home Link. Is this a PANA or SEND or AAA related method? Alex From nemo-admin@ietf.org Thu Nov 6 18:03:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06445 for ; Thu, 6 Nov 2003 18: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 1AHt9Y-0003qu-CS; Thu, 06 Nov 2003 18: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 1AHt9S-0003qf-JF for nemo@optimus.ietf.org; Thu, 06 Nov 2003 18:02:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06424 for ; Thu, 6 Nov 2003 18:02:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHt9P-0002VT-00 for nemo@ietf.org; Thu, 06 Nov 2003 18:02:51 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1AHt9O-0002VQ-00 for nemo@ietf.org; Thu, 06 Nov 2003 18:02:50 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id hA6N2lm5021269; Thu, 6 Nov 2003 16:02:49 -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 hA6MsoFX019844; Thu, 6 Nov 2003 16:54:51 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 04A4E2EC95; Thu, 6 Nov 2003 23:54:51 +0100 (CET) Message-ID: <3FAAD13A.50305@motorola.com> Date: Thu, 06 Nov 2003 23:54:50 +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: MATSUMOTO Taisuke , nemo@ietf.org Subject: Re: [nemo] Behavior of HA References: <200311051221.hA5CLh2t075968@mrit.mrit.mei.co.jp> <3FA95896.7010002@iprg.nokia.com> <200311060946.hA69k32t032659@mrit.mrit.mei.co.jp> <3FAABFB8.1040208@iprg.nokia.com> In-Reply-To: <3FAABFB8.1040208@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: > MATSUMOTO Taisuke wrote: > >> Hi Vijay, >> >> Thank you for your response. >> >> >>>> So, I think that some schemes to avoid that restriction of the >>>> mobile IPv6 specifications is required for the NEMO basic >>>> support. >>> >>> >>> yes. the mobile IPv6 restriction needs to be relaxed. currently >>> section 10.3.1 of MIPv6 says >>> >>> if the home address for the binding (the Home Address field in >>> the packet's Home Address option) is not an on-link IPv6 address >>> with respect to the home agent's current Prefix List, then the >>> home agent MUST reject the Binding Update and SHOULD return a >>> Binding Acknowledgement to the mobile node, in which the Status >>> field is set to 132 (not home subnet). >>> >>> for Nemo, the Home Agent should not reject the Binding if the >>> home address is from a prefix that has been delegated to a Mobile >>> Router. >>> >> >> I think that your comment is reasonabie. But I have another >> question how to know if the prefix is delegated to the mobile >> router. If it should be pre-configured in the home agent, it makes >> the explicit prefix length mode lose an advantage to the implicit >> mode. > > > looks like what I suggested earlier might not be a good idea at all. > instead, here is another proposal. > > Mobile IPv6 specifies that the Home Agent should reject a Binding > Update if the home address in the received Binding Update is not an > on-link IPv6 address with respect to the prefixes being advertised on > the home link. This document relaxes this restriction so that the > Home Agent should reject the Binding Update only if the home address > does not belong to the home prefix that the Home Agent is serving. > > this is more generic. the Home Agent knows the home prefix that it is > serving. if the Mobile Network Prefix is a subset of this prefix, > then the Home Agent should accept binding updates from addresses > configured from the Mobile Network Prefix. the Home Agent has to just > verfiy that the home address belongs to the prefix it is serving. > > comments? Sure, here's my try. If you do the last paragraph, that in explicit prefix len mode the MNP's below a HA MUST be part of the home network prefix. Or there exist deployments where the MNP inside a moving network is related in no way to the prefixes of the home link. Agree these are not respecting the aggregation recommentation but that recommendation is just a recommendation, not enforced by anything else. I guess NEMO can't enforce the aggregation recommendation either. With implicit and explicit network modes, MNP's can be totally different than the home link prefix. Alex GBU From exim@www1.ietf.org Thu Nov 6 18:03:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06459 for ; Thu, 6 Nov 2003 18:03: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 1AHt9c-0003rt-Ty for nemo-archive@odin.ietf.org; Thu, 06 Nov 2003 18:03:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6N34ZR014869 for nemo-archive@odin.ietf.org; Thu, 6 Nov 2003 18:03:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHt9c-0003rk-PD for nemo-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 18: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 SAA06433 for ; Thu, 6 Nov 2003 18:02:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHt9a-0002Vn-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 18:03:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHt9Z-0002Vk-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 18:03:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHt9Y-0003qu-CS; Thu, 06 Nov 2003 18: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 1AHt9S-0003qf-JF for nemo@optimus.ietf.org; Thu, 06 Nov 2003 18:02:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06424 for ; Thu, 6 Nov 2003 18:02:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHt9P-0002VT-00 for nemo@ietf.org; Thu, 06 Nov 2003 18:02:51 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1AHt9O-0002VQ-00 for nemo@ietf.org; Thu, 06 Nov 2003 18:02:50 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id hA6N2lm5021269; Thu, 6 Nov 2003 16:02:49 -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 hA6MsoFX019844; Thu, 6 Nov 2003 16:54:51 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 04A4E2EC95; Thu, 6 Nov 2003 23:54:51 +0100 (CET) Message-ID: <3FAAD13A.50305@motorola.com> Date: Thu, 06 Nov 2003 23:54:50 +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: MATSUMOTO Taisuke , nemo@ietf.org Subject: Re: [nemo] Behavior of HA References: <200311051221.hA5CLh2t075968@mrit.mrit.mei.co.jp> <3FA95896.7010002@iprg.nokia.com> <200311060946.hA69k32t032659@mrit.mrit.mei.co.jp> <3FAABFB8.1040208@iprg.nokia.com> In-Reply-To: <3FAABFB8.1040208@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: > MATSUMOTO Taisuke wrote: > >> Hi Vijay, >> >> Thank you for your response. >> >> >>>> So, I think that some schemes to avoid that restriction of the >>>> mobile IPv6 specifications is required for the NEMO basic >>>> support. >>> >>> >>> yes. the mobile IPv6 restriction needs to be relaxed. currently >>> section 10.3.1 of MIPv6 says >>> >>> if the home address for the binding (the Home Address field in >>> the packet's Home Address option) is not an on-link IPv6 address >>> with respect to the home agent's current Prefix List, then the >>> home agent MUST reject the Binding Update and SHOULD return a >>> Binding Acknowledgement to the mobile node, in which the Status >>> field is set to 132 (not home subnet). >>> >>> for Nemo, the Home Agent should not reject the Binding if the >>> home address is from a prefix that has been delegated to a Mobile >>> Router. >>> >> >> I think that your comment is reasonabie. But I have another >> question how to know if the prefix is delegated to the mobile >> router. If it should be pre-configured in the home agent, it makes >> the explicit prefix length mode lose an advantage to the implicit >> mode. > > > looks like what I suggested earlier might not be a good idea at all. > instead, here is another proposal. > > Mobile IPv6 specifies that the Home Agent should reject a Binding > Update if the home address in the received Binding Update is not an > on-link IPv6 address with respect to the prefixes being advertised on > the home link. This document relaxes this restriction so that the > Home Agent should reject the Binding Update only if the home address > does not belong to the home prefix that the Home Agent is serving. > > this is more generic. the Home Agent knows the home prefix that it is > serving. if the Mobile Network Prefix is a subset of this prefix, > then the Home Agent should accept binding updates from addresses > configured from the Mobile Network Prefix. the Home Agent has to just > verfiy that the home address belongs to the prefix it is serving. > > comments? Sure, here's my try. If you do the last paragraph, that in explicit prefix len mode the MNP's below a HA MUST be part of the home network prefix. Or there exist deployments where the MNP inside a moving network is related in no way to the prefixes of the home link. Agree these are not respecting the aggregation recommentation but that recommendation is just a recommendation, not enforced by anything else. I guess NEMO can't enforce the aggregation recommendation either. With implicit and explicit network modes, MNP's can be totally different than the home link prefix. Alex GBU From nemo-admin@ietf.org Thu Nov 6 18:11:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07362 for ; Thu, 6 Nov 2003 18:11: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 1AHtHK-0004Pe-A8; Thu, 06 Nov 2003 18:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHtGf-0004OR-Tv for nemo@optimus.ietf.org; Thu, 06 Nov 2003 18:10: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 SAA07214 for ; Thu, 6 Nov 2003 18:10:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHtGd-0002Zc-00 for nemo@ietf.org; Thu, 06 Nov 2003 18:10:19 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AHtGc-0002ZE-00 for nemo@ietf.org; Thu, 06 Nov 2003 18:10:18 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA6N9dA20654; Thu, 6 Nov 2003 15:09:39 -0800 X-mProtect: <200311062309> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCQ8MrK; Thu, 06 Nov 2003 15:09:37 PST Message-ID: <3FAAD579.5000209@iprg.nokia.com> Date: Thu, 06 Nov 2003 15:12: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: Alexandru Petrescu CC: MATSUMOTO Taisuke , nemo@ietf.org Subject: Re: [nemo] Behavior of HA References: <200311051221.hA5CLh2t075968@mrit.mrit.mei.co.jp> <3FA95896.7010002@iprg.nokia.com> <200311060946.hA69k32t032659@mrit.mrit.mei.co.jp> <3FAABFB8.1040208@iprg.nokia.com> <3FAAD13A.50305@motorola.com> In-Reply-To: <3FAAD13A.50305@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: >> looks like what I suggested earlier might not be a good idea at all. >> instead, here is another proposal. >> >> Mobile IPv6 specifies that the Home Agent should reject a Binding >> Update if the home address in the received Binding Update is not an >> on-link IPv6 address with respect to the prefixes being advertised on >> the home link. This document relaxes this restriction so that the >> Home Agent should reject the Binding Update only if the home address >> does not belong to the home prefix that the Home Agent is serving. >> >> this is more generic. the Home Agent knows the home prefix that it is >> serving. if the Mobile Network Prefix is a subset of this prefix, >> then the Home Agent should accept binding updates from addresses >> configured from the Mobile Network Prefix. the Home Agent has to just >> verfiy that the home address belongs to the prefix it is serving. >> >> comments? > > > Sure, here's my try. > > If you do the last paragraph, that in explicit prefix len mode the MNP's > below a HA MUST be part of the home network prefix. right. I didnt say prefixes advertised on the home link. MIPv6 is specific. it says prefixes advertised on the home link. for Nemo we relax it a bit so that the home address belongs to the home prefix that the HA is serving. if the HA is configured to serve a prefix that is not advertised on the home link, it should accept binding updates for addresses configured from that prefix. Vijay From exim@www1.ietf.org Thu Nov 6 18:11:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07381 for ; Thu, 6 Nov 2003 18:11: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 1AHtHM-0004Rt-4i for nemo-archive@odin.ietf.org; Thu, 06 Nov 2003 18:11:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6NB4qO017095 for nemo-archive@odin.ietf.org; Thu, 6 Nov 2003 18:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHtHL-0004Rd-R9 for nemo-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 18:11: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 SAA07294 for ; Thu, 6 Nov 2003 18:10:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHtHI-0002aN-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 18:11:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHtHI-0002aK-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 18:11:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHtHK-0004Pe-A8; Thu, 06 Nov 2003 18:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHtGf-0004OR-Tv for nemo@optimus.ietf.org; Thu, 06 Nov 2003 18:10: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 SAA07214 for ; Thu, 6 Nov 2003 18:10:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHtGd-0002Zc-00 for nemo@ietf.org; Thu, 06 Nov 2003 18:10:19 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AHtGc-0002ZE-00 for nemo@ietf.org; Thu, 06 Nov 2003 18:10:18 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA6N9dA20654; Thu, 6 Nov 2003 15:09:39 -0800 X-mProtect: <200311062309> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCQ8MrK; Thu, 06 Nov 2003 15:09:37 PST Message-ID: <3FAAD579.5000209@iprg.nokia.com> Date: Thu, 06 Nov 2003 15:12: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: Alexandru Petrescu CC: MATSUMOTO Taisuke , nemo@ietf.org Subject: Re: [nemo] Behavior of HA References: <200311051221.hA5CLh2t075968@mrit.mrit.mei.co.jp> <3FA95896.7010002@iprg.nokia.com> <200311060946.hA69k32t032659@mrit.mrit.mei.co.jp> <3FAABFB8.1040208@iprg.nokia.com> <3FAAD13A.50305@motorola.com> In-Reply-To: <3FAAD13A.50305@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: >> looks like what I suggested earlier might not be a good idea at all. >> instead, here is another proposal. >> >> Mobile IPv6 specifies that the Home Agent should reject a Binding >> Update if the home address in the received Binding Update is not an >> on-link IPv6 address with respect to the prefixes being advertised on >> the home link. This document relaxes this restriction so that the >> Home Agent should reject the Binding Update only if the home address >> does not belong to the home prefix that the Home Agent is serving. >> >> this is more generic. the Home Agent knows the home prefix that it is >> serving. if the Mobile Network Prefix is a subset of this prefix, >> then the Home Agent should accept binding updates from addresses >> configured from the Mobile Network Prefix. the Home Agent has to just >> verfiy that the home address belongs to the prefix it is serving. >> >> comments? > > > Sure, here's my try. > > If you do the last paragraph, that in explicit prefix len mode the MNP's > below a HA MUST be part of the home network prefix. right. I didnt say prefixes advertised on the home link. MIPv6 is specific. it says prefixes advertised on the home link. for Nemo we relax it a bit so that the home address belongs to the home prefix that the HA is serving. if the HA is configured to serve a prefix that is not advertised on the home link, it should accept binding updates for addresses configured from that prefix. Vijay From nemo-admin@ietf.org Thu Nov 6 18:37:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08599 for ; Thu, 6 Nov 2003 18:37:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHtgT-0005pA-8e; Thu, 06 Nov 2003 18:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHtfo-0005oD-Mo for nemo@optimus.ietf.org; Thu, 06 Nov 2003 18:36: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 SAA08566 for ; Thu, 6 Nov 2003 18:36:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHtfl-0002sB-00 for nemo@ietf.org; Thu, 06 Nov 2003 18:36:17 -0500 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1AHtfl-0002s8-00 for nemo@ietf.org; Thu, 06 Nov 2003 18:36:17 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (Motorola/Motgate) with ESMTP id hA6NaHHc009626; Thu, 6 Nov 2003 16:36:17 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id hA6NZEDX022387; Thu, 6 Nov 2003 17:35:14 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id BBB972EC95; Fri, 7 Nov 2003 00:36:13 +0100 (CET) Message-ID: <3FAADAED.1090209@motorola.com> Date: Fri, 07 Nov 2003 00:36:13 +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: MATSUMOTO Taisuke , nemo@ietf.org Subject: Re: [nemo] Behavior of HA References: <200311051221.hA5CLh2t075968@mrit.mrit.mei.co.jp> <3FA95896.7010002@iprg.nokia.com> <200311060946.hA69k32t032659@mrit.mrit.mei.co.jp> <3FAABFB8.1040208@iprg.nokia.com> <3FAAD13A.50305@motorola.com> <3FAAD579.5000209@iprg.nokia.com> In-Reply-To: <3FAAD579.5000209@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: > Alexandru Petrescu wrote: > >>> looks like what I suggested earlier might not be a good idea at >>> all. instead, here is another proposal. >>> >>> Mobile IPv6 specifies that the Home Agent should reject a Binding >>> Update if the home address in the received Binding Update is not >>> an on-link IPv6 address with respect to the prefixes being >>> advertised on the home link. This document relaxes this >>> restriction so that the Home Agent should reject the Binding >>> Update only if the home address does not belong to the home >>> prefix that the Home Agent is serving. >>> >>> this is more generic. the Home Agent knows the home prefix that >>> it is serving. if the Mobile Network Prefix is a subset of this >>> prefix, then the Home Agent should accept binding updates from >>> addresses configured from the Mobile Network Prefix. the Home >>> Agent has to just verfiy that the home address belongs to the >>> prefix it is serving. >>> >>> comments? >> >> >> >> Sure, here's my try. >> >> If you do the last paragraph, that in explicit prefix len mode the >> MNP's below a HA MUST be part of the home network prefix. > > > right. I didnt say prefixes advertised on the home link. MIPv6 is > specific. it says prefixes advertised on the home link. for Nemo we > relax it a bit so that the home address belongs to the home prefix > that the HA is serving. if the HA is configured to serve a prefix > that is not advertised on the home link, it should accept binding > updates for addresses configured from that prefix. That sounds good. (if you didn't name this MNP a "home prefix"). Before accepting that BU, HA could also fully check the received HoA against the next hop field of the MNP rt entry (not only the prefixlen bits match of the HoA and the MNP). Alex From exim@www1.ietf.org Thu Nov 6 18:37:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08617 for ; Thu, 6 Nov 2003 18:37: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 1AHtgW-0005r4-HS for nemo-archive@odin.ietf.org; Thu, 06 Nov 2003 18:37:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6Nb4aX022500 for nemo-archive@odin.ietf.org; Thu, 6 Nov 2003 18:37:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHtgW-0005qm-0g for nemo-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 18:37: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 SAA08591 for ; Thu, 6 Nov 2003 18:36:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHtgS-0002sd-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 18:37:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHtgS-0002sa-00 for nemo-web-archive@ietf.org; Thu, 06 Nov 2003 18:37:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHtgT-0005pA-8e; Thu, 06 Nov 2003 18:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHtfo-0005oD-Mo for nemo@optimus.ietf.org; Thu, 06 Nov 2003 18:36: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 SAA08566 for ; Thu, 6 Nov 2003 18:36:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHtfl-0002sB-00 for nemo@ietf.org; Thu, 06 Nov 2003 18:36:17 -0500 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1AHtfl-0002s8-00 for nemo@ietf.org; Thu, 06 Nov 2003 18:36:17 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (Motorola/Motgate) with ESMTP id hA6NaHHc009626; Thu, 6 Nov 2003 16:36:17 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id hA6NZEDX022387; Thu, 6 Nov 2003 17:35:14 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id BBB972EC95; Fri, 7 Nov 2003 00:36:13 +0100 (CET) Message-ID: <3FAADAED.1090209@motorola.com> Date: Fri, 07 Nov 2003 00:36:13 +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: MATSUMOTO Taisuke , nemo@ietf.org Subject: Re: [nemo] Behavior of HA References: <200311051221.hA5CLh2t075968@mrit.mrit.mei.co.jp> <3FA95896.7010002@iprg.nokia.com> <200311060946.hA69k32t032659@mrit.mrit.mei.co.jp> <3FAABFB8.1040208@iprg.nokia.com> <3FAAD13A.50305@motorola.com> <3FAAD579.5000209@iprg.nokia.com> In-Reply-To: <3FAAD579.5000209@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: > Alexandru Petrescu wrote: > >>> looks like what I suggested earlier might not be a good idea at >>> all. instead, here is another proposal. >>> >>> Mobile IPv6 specifies that the Home Agent should reject a Binding >>> Update if the home address in the received Binding Update is not >>> an on-link IPv6 address with respect to the prefixes being >>> advertised on the home link. This document relaxes this >>> restriction so that the Home Agent should reject the Binding >>> Update only if the home address does not belong to the home >>> prefix that the Home Agent is serving. >>> >>> this is more generic. the Home Agent knows the home prefix that >>> it is serving. if the Mobile Network Prefix is a subset of this >>> prefix, then the Home Agent should accept binding updates from >>> addresses configured from the Mobile Network Prefix. the Home >>> Agent has to just verfiy that the home address belongs to the >>> prefix it is serving. >>> >>> comments? >> >> >> >> Sure, here's my try. >> >> If you do the last paragraph, that in explicit prefix len mode the >> MNP's below a HA MUST be part of the home network prefix. > > > right. I didnt say prefixes advertised on the home link. MIPv6 is > specific. it says prefixes advertised on the home link. for Nemo we > relax it a bit so that the home address belongs to the home prefix > that the HA is serving. if the HA is configured to serve a prefix > that is not advertised on the home link, it should accept binding > updates for addresses configured from that prefix. That sounds good. (if you didn't name this MNP a "home prefix"). Before accepting that BU, HA could also fully check the received HoA against the next hop field of the MNP rt entry (not only the prefixlen bits match of the HoA and the MNP). Alex From nemo-admin@ietf.org Fri Nov 7 02:52:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03949 for ; Fri, 7 Nov 2003 02:52: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 1AI1PV-0004SG-GE; Fri, 07 Nov 2003 02:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1P4-0004Nu-US for nemo@optimus.ietf.org; Fri, 07 Nov 2003 02:51: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 CAA03919 for ; Fri, 7 Nov 2003 02:51:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1P0-0000cW-00 for nemo@ietf.org; Fri, 07 Nov 2003 02:51:31 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AI1P0-0000cK-00 for nemo@ietf.org; Fri, 07 Nov 2003 02:51:30 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Nov 2003 08:48:43 +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 hA77ongN003580; Fri, 7 Nov 2003 08:50:50 +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, 7 Nov 2003 07:50:57 +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] Short comment on draft-thubert-nemo-basic-usages-00 Date: Fri, 7 Nov 2003 07:50:56 -0000 Message-ID: Thread-Topic: [nemo] Short comment on draft-thubert-nemo-basic-usages-00 Thread-Index: AcOkt5i0XhcAtyQ0TVS3znEWd84DqwASzR+Q From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 07 Nov 2003 07:50:57.0982 (UTC) FILETIME=[E14B9DE0:01C3A503] 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 Alex, >=20 > Alexandru Petrescu wrote: >=20 >> >> | >> route v /48 >> >> HA >> | /52 >> --+-----+--+- . -+- . -+-- >> | | | | >> MR1 MR2 MRi MRN >> /56 /56 /56 /56 >> The route /48 troubles me. Are the /56 aggregated by the /52, in which case it is the aggregated home net model, or are the /52 and the /56 aggregated into the /48, in which case this is an extended home network? The prefix lengths are given as examples. Obviously they are not the core of the difference between the models. Pascal From exim@www1.ietf.org Fri Nov 7 02:52:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03972 for ; Fri, 7 Nov 2003 02:52: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 1AI1Pc-0004UM-UI for nemo-archive@odin.ietf.org; Fri, 07 Nov 2003 02:52:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA77q8Q4017245 for nemo-archive@odin.ietf.org; Fri, 7 Nov 2003 02:52:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1Pc-0004To-EK for nemo-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 02:52: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 CAA03937 for ; Fri, 7 Nov 2003 02:51:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1PY-0000d8-00 for nemo-web-archive@ietf.org; Fri, 07 Nov 2003 02:52:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI1PY-0000d5-00 for nemo-web-archive@ietf.org; Fri, 07 Nov 2003 02:52:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1PV-0004SG-GE; Fri, 07 Nov 2003 02:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1P4-0004Nu-US for nemo@optimus.ietf.org; Fri, 07 Nov 2003 02:51: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 CAA03919 for ; Fri, 7 Nov 2003 02:51:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1P0-0000cW-00 for nemo@ietf.org; Fri, 07 Nov 2003 02:51:31 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AI1P0-0000cK-00 for nemo@ietf.org; Fri, 07 Nov 2003 02:51:30 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Nov 2003 08:48:43 +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 hA77ongN003580; Fri, 7 Nov 2003 08:50:50 +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, 7 Nov 2003 07:50:57 +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] Short comment on draft-thubert-nemo-basic-usages-00 Date: Fri, 7 Nov 2003 07:50:56 -0000 Message-ID: Thread-Topic: [nemo] Short comment on draft-thubert-nemo-basic-usages-00 Thread-Index: AcOkt5i0XhcAtyQ0TVS3znEWd84DqwASzR+Q From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 07 Nov 2003 07:50:57.0982 (UTC) FILETIME=[E14B9DE0:01C3A503] 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 Alex, >=20 > Alexandru Petrescu wrote: >=20 >> >> | >> route v /48 >> >> HA >> | /52 >> --+-----+--+- . -+- . -+-- >> | | | | >> MR1 MR2 MRi MRN >> /56 /56 /56 /56 >> The route /48 troubles me. Are the /56 aggregated by the /52, in which case it is the aggregated home net model, or are the /52 and the /56 aggregated into the /48, in which case this is an extended home network? The prefix lengths are given as examples. Obviously they are not the core of the difference between the models. Pascal From nemo-admin@ietf.org Fri Nov 7 03:06:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04413 for ; Fri, 7 Nov 2003 03:06: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 1AI1d3-0005DL-FW; Fri, 07 Nov 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 1AI1cW-0005C7-Rv for nemo@optimus.ietf.org; Fri, 07 Nov 2003 03:05: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 DAA04319 for ; Fri, 7 Nov 2003 03:05:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1cS-0000li-00 for nemo@ietf.org; Fri, 07 Nov 2003 03:05:24 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AI1cS-0000lP-00 for nemo@ietf.org; Fri, 07 Nov 2003 03:05:24 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Nov 2003 09:02:38 +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 hA784iAE006031; Fri, 7 Nov 2003 09:04:45 +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, 7 Nov 2003 08:04:54 +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] Behavior of HA Date: Fri, 7 Nov 2003 08:04:53 -0000 Message-ID: Thread-Topic: [nemo] Behavior of HA Thread-Index: AcOkrlygnnYCttHWTfK9kZ+aZaswHQAVXIcw From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "MATSUMOTO Taisuke" Cc: X-OriginalArrivalTime: 07 Nov 2003 08:04:54.0316 (UTC) FILETIME=[D3CA0EC0:01C3A505] 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 >=20 > MATSUMOTO Taisuke wrote: > > Hi Vijay, > >=20 > > Thank you for your response. > >=20 > >=20 > >>>So, I think that some schemes to avoid that restriction of the > >>>mobile IPv6 specifications is required for the NEMO basic support. > >> > >>yes. the mobile IPv6 restriction needs to be relaxed. currently=20 > >>section 10.3.1 of MIPv6 says > >> > >> if the home address for the binding (the Home Address field > >> in the packet's Home Address option) is not an on-link IPv6 > >> address with respect to the home agent's current=20 > Prefix List, then > >> the home agent MUST reject the Binding Update and=20 > SHOULD return a > >> Binding Acknowledgement to the mobile node, in which=20 > the Status > >> field is set to 132 (not home subnet). > >> > >>for Nemo, the Home Agent should not reject the Binding if the home=20 > >>address is from a prefix that has been delegated to a Mobile Router. > >> > >=20 > > I think that your comment is reasonabie. But I have another > > question how to know if the prefix is delegated to the mobile=20 > > router. If it should be pre-configured in the home agent, it makes=20 > > the explicit prefix length mode lose an advantage to the implicit=20 > > mode. >=20 > looks like what I suggested earlier might not be a good idea=20 > at all. instead, here is another proposal. >=20 > Mobile IPv6 specifies that the Home Agent should reject a Binding > Update if the home address in the received Binding Update is not > an on-link IPv6 address with respect to the prefixes being > advertised on the home link. This document relaxes this=20 > restriction > so that the Home Agent should reject the Binding Update=20 > only if the > home address does not belong to the home prefix that the=20 > Home Agent > is serving. >=20 > this is more generic. the Home Agent knows the home prefix=20 > that it is serving. if the Mobile Network Prefix is a subset=20 > of this prefix, then the Home Agent should accept binding=20 > updates from addresses configured from the Mobile Network=20 > Prefix. the Home Agent has to just verfiy that the home=20 > address belongs to the prefix it is serving. >=20 > comments? >=20 This is when the terminology introduced in the usage draft could be useful. There can be a Home link serving as Home Network for MIP purposes, but your text refers to the extended or aggregated Home Networks :) Note that basic -00 had specific text about this that case: " The Home Network is configured on a physical interface as defined in MIPv6. A Mobile Router may own a Home Address that is built out of the Home Network prefix and use it for Nemo registration and to come back Home. In that case, the Home Network Prefix and prefix length are used in the Binding Update. A Mobile Router owns one or several Mobile Networks. It may form extended Home Addresses from the prefixes of its Mobile Network(s) and register them to the Home Agent using the extended Home Network prefix and prefix length. An extended Home Address may be used for only one registration that it identifies uniquely, regardless of the Home Agent, as for normal Home Addresses " What do you think? Pascal From exim@www1.ietf.org Fri Nov 7 03:06:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04436 for ; Fri, 7 Nov 2003 03: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 1AI1d6-0005G1-FQ for nemo-archive@odin.ietf.org; Fri, 07 Nov 2003 03:06:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7864cp020207 for nemo-archive@odin.ietf.org; Fri, 7 Nov 2003 03:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1d5-0005Fo-RO for nemo-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 03:06: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 DAA04364 for ; Fri, 7 Nov 2003 03:05:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1d1-0000mT-00 for nemo-web-archive@ietf.org; Fri, 07 Nov 2003 03:05:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI1d1-0000mQ-00 for nemo-web-archive@ietf.org; Fri, 07 Nov 2003 03:05:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1d3-0005DL-FW; Fri, 07 Nov 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 1AI1cW-0005C7-Rv for nemo@optimus.ietf.org; Fri, 07 Nov 2003 03:05: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 DAA04319 for ; Fri, 7 Nov 2003 03:05:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1cS-0000li-00 for nemo@ietf.org; Fri, 07 Nov 2003 03:05:24 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AI1cS-0000lP-00 for nemo@ietf.org; Fri, 07 Nov 2003 03:05:24 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Nov 2003 09:02:38 +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 hA784iAE006031; Fri, 7 Nov 2003 09:04:45 +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, 7 Nov 2003 08:04:54 +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] Behavior of HA Date: Fri, 7 Nov 2003 08:04:53 -0000 Message-ID: Thread-Topic: [nemo] Behavior of HA Thread-Index: AcOkrlygnnYCttHWTfK9kZ+aZaswHQAVXIcw From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "MATSUMOTO Taisuke" Cc: X-OriginalArrivalTime: 07 Nov 2003 08:04:54.0316 (UTC) FILETIME=[D3CA0EC0:01C3A505] 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 >=20 > MATSUMOTO Taisuke wrote: > > Hi Vijay, > >=20 > > Thank you for your response. > >=20 > >=20 > >>>So, I think that some schemes to avoid that restriction of the > >>>mobile IPv6 specifications is required for the NEMO basic support. > >> > >>yes. the mobile IPv6 restriction needs to be relaxed. currently=20 > >>section 10.3.1 of MIPv6 says > >> > >> if the home address for the binding (the Home Address field > >> in the packet's Home Address option) is not an on-link IPv6 > >> address with respect to the home agent's current=20 > Prefix List, then > >> the home agent MUST reject the Binding Update and=20 > SHOULD return a > >> Binding Acknowledgement to the mobile node, in which=20 > the Status > >> field is set to 132 (not home subnet). > >> > >>for Nemo, the Home Agent should not reject the Binding if the home=20 > >>address is from a prefix that has been delegated to a Mobile Router. > >> > >=20 > > I think that your comment is reasonabie. But I have another > > question how to know if the prefix is delegated to the mobile=20 > > router. If it should be pre-configured in the home agent, it makes=20 > > the explicit prefix length mode lose an advantage to the implicit=20 > > mode. >=20 > looks like what I suggested earlier might not be a good idea=20 > at all. instead, here is another proposal. >=20 > Mobile IPv6 specifies that the Home Agent should reject a Binding > Update if the home address in the received Binding Update is not > an on-link IPv6 address with respect to the prefixes being > advertised on the home link. This document relaxes this=20 > restriction > so that the Home Agent should reject the Binding Update=20 > only if the > home address does not belong to the home prefix that the=20 > Home Agent > is serving. >=20 > this is more generic. the Home Agent knows the home prefix=20 > that it is serving. if the Mobile Network Prefix is a subset=20 > of this prefix, then the Home Agent should accept binding=20 > updates from addresses configured from the Mobile Network=20 > Prefix. the Home Agent has to just verfiy that the home=20 > address belongs to the prefix it is serving. >=20 > comments? >=20 This is when the terminology introduced in the usage draft could be useful. There can be a Home link serving as Home Network for MIP purposes, but your text refers to the extended or aggregated Home Networks :) Note that basic -00 had specific text about this that case: " The Home Network is configured on a physical interface as defined in MIPv6. A Mobile Router may own a Home Address that is built out of the Home Network prefix and use it for Nemo registration and to come back Home. In that case, the Home Network Prefix and prefix length are used in the Binding Update. A Mobile Router owns one or several Mobile Networks. It may form extended Home Addresses from the prefixes of its Mobile Network(s) and register them to the Home Agent using the extended Home Network prefix and prefix length. An extended Home Address may be used for only one registration that it identifies uniquely, regardless of the Home Agent, as for normal Home Addresses " What do you think? Pascal From nemo-admin@ietf.org Fri Nov 7 03:23:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05036 for ; Fri, 7 Nov 2003 03: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 1AI1tV-0006bN-Js; Fri, 07 Nov 2003 03: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 1AI1tP-0006aq-C1 for nemo@optimus.ietf.org; Fri, 07 Nov 2003 03: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 DAA05021 for ; Fri, 7 Nov 2003 03:22:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1tM-00010P-00 for nemo@ietf.org; Fri, 07 Nov 2003 03:22:53 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AI1tM-00010J-00 for nemo@ietf.org; Fri, 07 Nov 2003 03:22:52 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Nov 2003 09:20:07 +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 hA78MDgd009329; Fri, 7 Nov 2003 09:22:14 +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); Fri, 7 Nov 2003 08:22:22 +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] Nemo Basic Support - IP in IP tunneling vs NAT transversal Date: Fri, 7 Nov 2003 08:22:21 -0000 Message-ID: Thread-Topic: [nemo] Nemo Basic Support - IP in IP tunneling vs NAT transversal Thread-Index: AcOktCMXdNO9O3KCRJGFhLLO5WDDOgAUfbFQ From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" Cc: "William D Ivancic" , X-OriginalArrivalTime: 07 Nov 2003 08:22:22.0075 (UTC) FILETIME=[444D64B0:01C3A508] 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 > Pascal Thubert (pthubert) wrote: > > Note that Doors should work with the T-Mobile IPv4 infrastructure an > > dtheir active filters, at least if IP-in-UDP does for IPv4 mobile=20 > > tunnels. >=20 > Until the day T-Mobile realizes that Doors bubbles try to get=20 > through so T-Mobile will stop the Doors bubbles too, no? >=20 For the record, doors does not have bubbles (that's teredo), but the equivalent service is obtained naturally from Binding Updates. My understanding is that the probes that T-Mobile is filtering out are generally offensive and can be seen as DOS attacks on a low bandwidth s.a. GPRS. This is about filtering things coming from the outside, just like a firewall. If T-Mobile wished to deploy a MIPv6 or Nemo service that uses their CURRENT IPv4 GPRS structure, I believe that they could do so, even with these filters active, using doors. The 'bubbles' would not be filtered because: - they come from the inside - T-Mobile does not wish to kill their own service We have an implementation of doors that has already been successfully tested with some GPRS deployments. I'd be glad to try more :) Pascal From exim@www1.ietf.org Fri Nov 7 03:23:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05052 for ; Fri, 7 Nov 2003 03:23: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 1AI1tY-0006cq-7m for nemo-archive@odin.ietf.org; Fri, 07 Nov 2003 03:23:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA78N4QW025462 for nemo-archive@odin.ietf.org; Fri, 7 Nov 2003 03:23:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1tX-0006cb-Um for nemo-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 03:23: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 DAA05025 for ; Fri, 7 Nov 2003 03:22:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1tV-00010Y-00 for nemo-web-archive@ietf.org; Fri, 07 Nov 2003 03:23:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI1tV-00010V-00 for nemo-web-archive@ietf.org; Fri, 07 Nov 2003 03: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 1AI1tV-0006bN-Js; Fri, 07 Nov 2003 03: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 1AI1tP-0006aq-C1 for nemo@optimus.ietf.org; Fri, 07 Nov 2003 03: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 DAA05021 for ; Fri, 7 Nov 2003 03:22:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1tM-00010P-00 for nemo@ietf.org; Fri, 07 Nov 2003 03:22:53 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AI1tM-00010J-00 for nemo@ietf.org; Fri, 07 Nov 2003 03:22:52 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Nov 2003 09:20:07 +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 hA78MDgd009329; Fri, 7 Nov 2003 09:22:14 +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); Fri, 7 Nov 2003 08:22:22 +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] Nemo Basic Support - IP in IP tunneling vs NAT transversal Date: Fri, 7 Nov 2003 08:22:21 -0000 Message-ID: Thread-Topic: [nemo] Nemo Basic Support - IP in IP tunneling vs NAT transversal Thread-Index: AcOktCMXdNO9O3KCRJGFhLLO5WDDOgAUfbFQ From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" Cc: "William D Ivancic" , X-OriginalArrivalTime: 07 Nov 2003 08:22:22.0075 (UTC) FILETIME=[444D64B0:01C3A508] 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 > Pascal Thubert (pthubert) wrote: > > Note that Doors should work with the T-Mobile IPv4 infrastructure an > > dtheir active filters, at least if IP-in-UDP does for IPv4 mobile=20 > > tunnels. >=20 > Until the day T-Mobile realizes that Doors bubbles try to get=20 > through so T-Mobile will stop the Doors bubbles too, no? >=20 For the record, doors does not have bubbles (that's teredo), but the equivalent service is obtained naturally from Binding Updates. My understanding is that the probes that T-Mobile is filtering out are generally offensive and can be seen as DOS attacks on a low bandwidth s.a. GPRS. This is about filtering things coming from the outside, just like a firewall. If T-Mobile wished to deploy a MIPv6 or Nemo service that uses their CURRENT IPv4 GPRS structure, I believe that they could do so, even with these filters active, using doors. The 'bubbles' would not be filtered because: - they come from the inside - T-Mobile does not wish to kill their own service We have an implementation of doors that has already been successfully tested with some GPRS deployments. I'd be glad to try more :) Pascal From nemo-admin@ietf.org Fri Nov 7 04:20:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06776 for ; Fri, 7 Nov 2003 04:20: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 1AI2mh-000259-HK; Fri, 07 Nov 2003 04: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 1AI2lw-00021d-G4 for nemo@optimus.ietf.org; Fri, 07 Nov 2003 04:19: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 EAA06730 for ; Fri, 7 Nov 2003 04:19:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI2lt-0001hK-00 for nemo@ietf.org; Fri, 07 Nov 2003 04:19:13 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1AI2ls-0001hH-00 for nemo@ietf.org; Fri, 07 Nov 2003 04:19:13 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA79J7UC001631; Fri, 7 Nov 2003 18:19:07 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA79J7po026208; Fri, 7 Nov 2003 18:19:07 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA79J58H018088; Fri, 7 Nov 2003 18:19:05 +0900 (JST) Received: from imd.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id SAA02251; Fri, 7 Nov 2003 18:19:05 +0900 (JST) Received: from [127.0.0.1] by imd.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id SAA18157; Fri, 7 Nov 2003 18:19:05 +0900 (JST) Date: Fri, 07 Nov 2003 18:18:55 +0900 From: Hiroyuki OHNISHI To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] RE: ro draft Cc: In-Reply-To: References: Message-Id: <20031107165837.4A82.OHNISHI.HIROYUKI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Pascal-san, Thank you for your comments. On Tue, 4 Nov 2003 15:24:27 -0000 "Pascal Thubert (pthubert)" wrote: > > Hi Hiroyuki-san: > > I believe this draft is important, and it reflects base thoughts that > should be built upon. A solution like this improves the nemo basic > support dramatically. We really need to open the RO discussion(s) ASAP. > Chairs: do we need to recharter? > > One high level comment: there are to forms of RO addressed here, the > "HMIP for Nemo" part, which addresses the pinball routing, and the RO > for CN to LFN. I believe that they are orthogonal and should be in > separate drafts. > > On HMIP for Nemo: > > 1) I hope this mechanism gets finally merged into HMIP draft. IMHO, it > is the logical application of HMIP to Nemo. Did you start a discussion > with Hesham? > Yes, he is now reviewing this draft. > 2) The relation between the MR and the MAP is still a classical MRHA > relationship. Pinball routing is avoided because the MAP is the HA for > all the nested structure. But for the rest, most of the comments in RRH > draft chapter "1.1 Recursive complexity" still apply. In other words, > RRH is still very useful to simplify the HA operation, mostly for the > nesting of tunnels and the computation of the recursive path (5.4.2). > The 2 solutions are not opposed, and there's a great value to actually > combine them. If I understand "recursive complexity" correctly, this problem will occur in MAP or root-MR in my solution. I think this problem is not so heavy compared with that for HA or CN. As you suggested, "combination" is an interesting approach. I will think about that. > 3) The MAP option should be changed in order to advertise the Nemo > capability > Yes. To support multi-homing case, this option has to carry multiple CoAs. I want to extend capability in next draft. > 4) The solution should work for LFN since Basic Nemo is used. It would > be nice to expand 'Data' in fig 9 to show that it can be an actual > packet from LFN to CN. This solution can also work for LFN. I will add the figure that explaind the data flow from LFN to CN. > > 5) I like fig 6, and I believe the MAP should be placed that way (fixed) > as opposed to mobile. So I disagree with some text in 5.1. The MAP > option should be always there in the tree, and it is not the way to > detect that a MR is root. I suggest that you inherit that feature from > the TIO option in RRH draft, which is meant for that, as opposed to > overloading the MAP option. I am sorry that fig 6 and the text in 5.1 lead some misunderstanding. I also assume the case in which MAP is not deployed in the network because whether MAP is deployed or not depends on the network's services. "If the MR receives an RA without a MAP option, it recognizes that it is the root-MR." assumes that situation. > ON the RO to LFN > > We discussed that model on the ML. I mentioned that I do not like it too > much because the RR test is tricked, since the CoA (the MR) is not > collocated with the HoA (the LFN), which is what the test is supposed to > confirm. So you need to start snooping and it's pretty unclean. > I understand your points. But if LFN and MR have some security relationship, I think this method is not so tricky. When LFN join the mobile network(in this case LFN does not care the network is mobile network or fixed network), LFN is authenticated by network. If the authentication is done by MR, LFN and MR can have some security association. This MR is something like FA in Mobile IPv4. > Alternates were already discussed, like in Ryuji's initial basic nemo > draft, and the correspondent router model which is an evolution of your > MBG. Maybe we should write that draft :) There are also alternatives > based on nemo aware nodes, for instance having the node send zeroed out > RRHs (see RRH appendix 1) in the COTi, and then with the packets if the > test flies. > > Pascal Yes. Route optimization has many situations and there are many solutions for each cases. But I think we do not need to create the solution which solves all the situations. Maybe that kind of work takes more time. I want to discuss what kind of situations people are thinking about route optimization. That is also helpful for my clarification. As Thierry suggested in his e-mail, I want to contribute to your RO-taxonomy draft. -- Hiroyuki OHNISHI NTT Network Service Systems Laboratories Phone: +81-422-59-4132, Fax: +81-422-60-7460 mailto: ohnishi.hiroyuki@lab.ntt.co.jp From exim@www1.ietf.org Fri Nov 7 04:20:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06794 for ; Fri, 7 Nov 2003 04:20: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 1AI2mn-00027Y-JX for nemo-archive@odin.ietf.org; Fri, 07 Nov 2003 04:20:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA79K9Xi008141 for nemo-archive@odin.ietf.org; Fri, 7 Nov 2003 04:20:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2ml-00026y-Bk for nemo-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 04:20: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 EAA06754 for ; Fri, 7 Nov 2003 04:19:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI2mi-0001hy-00 for nemo-web-archive@ietf.org; Fri, 07 Nov 2003 04:20:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI2mi-0001hv-00 for nemo-web-archive@ietf.org; Fri, 07 Nov 2003 04:20:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2mh-000259-HK; Fri, 07 Nov 2003 04: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 1AI2lw-00021d-G4 for nemo@optimus.ietf.org; Fri, 07 Nov 2003 04:19: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 EAA06730 for ; Fri, 7 Nov 2003 04:19:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI2lt-0001hK-00 for nemo@ietf.org; Fri, 07 Nov 2003 04:19:13 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1AI2ls-0001hH-00 for nemo@ietf.org; Fri, 07 Nov 2003 04:19:13 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA79J7UC001631; Fri, 7 Nov 2003 18:19:07 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA79J7po026208; Fri, 7 Nov 2003 18:19:07 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA79J58H018088; Fri, 7 Nov 2003 18:19:05 +0900 (JST) Received: from imd.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id SAA02251; Fri, 7 Nov 2003 18:19:05 +0900 (JST) Received: from [127.0.0.1] by imd.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id SAA18157; Fri, 7 Nov 2003 18:19:05 +0900 (JST) Date: Fri, 07 Nov 2003 18:18:55 +0900 From: Hiroyuki OHNISHI To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] RE: ro draft Cc: In-Reply-To: References: Message-Id: <20031107165837.4A82.OHNISHI.HIROYUKI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Pascal-san, Thank you for your comments. On Tue, 4 Nov 2003 15:24:27 -0000 "Pascal Thubert (pthubert)" wrote: > > Hi Hiroyuki-san: > > I believe this draft is important, and it reflects base thoughts that > should be built upon. A solution like this improves the nemo basic > support dramatically. We really need to open the RO discussion(s) ASAP. > Chairs: do we need to recharter? > > One high level comment: there are to forms of RO addressed here, the > "HMIP for Nemo" part, which addresses the pinball routing, and the RO > for CN to LFN. I believe that they are orthogonal and should be in > separate drafts. > > On HMIP for Nemo: > > 1) I hope this mechanism gets finally merged into HMIP draft. IMHO, it > is the logical application of HMIP to Nemo. Did you start a discussion > with Hesham? > Yes, he is now reviewing this draft. > 2) The relation between the MR and the MAP is still a classical MRHA > relationship. Pinball routing is avoided because the MAP is the HA for > all the nested structure. But for the rest, most of the comments in RRH > draft chapter "1.1 Recursive complexity" still apply. In other words, > RRH is still very useful to simplify the HA operation, mostly for the > nesting of tunnels and the computation of the recursive path (5.4.2). > The 2 solutions are not opposed, and there's a great value to actually > combine them. If I understand "recursive complexity" correctly, this problem will occur in MAP or root-MR in my solution. I think this problem is not so heavy compared with that for HA or CN. As you suggested, "combination" is an interesting approach. I will think about that. > 3) The MAP option should be changed in order to advertise the Nemo > capability > Yes. To support multi-homing case, this option has to carry multiple CoAs. I want to extend capability in next draft. > 4) The solution should work for LFN since Basic Nemo is used. It would > be nice to expand 'Data' in fig 9 to show that it can be an actual > packet from LFN to CN. This solution can also work for LFN. I will add the figure that explaind the data flow from LFN to CN. > > 5) I like fig 6, and I believe the MAP should be placed that way (fixed) > as opposed to mobile. So I disagree with some text in 5.1. The MAP > option should be always there in the tree, and it is not the way to > detect that a MR is root. I suggest that you inherit that feature from > the TIO option in RRH draft, which is meant for that, as opposed to > overloading the MAP option. I am sorry that fig 6 and the text in 5.1 lead some misunderstanding. I also assume the case in which MAP is not deployed in the network because whether MAP is deployed or not depends on the network's services. "If the MR receives an RA without a MAP option, it recognizes that it is the root-MR." assumes that situation. > ON the RO to LFN > > We discussed that model on the ML. I mentioned that I do not like it too > much because the RR test is tricked, since the CoA (the MR) is not > collocated with the HoA (the LFN), which is what the test is supposed to > confirm. So you need to start snooping and it's pretty unclean. > I understand your points. But if LFN and MR have some security relationship, I think this method is not so tricky. When LFN join the mobile network(in this case LFN does not care the network is mobile network or fixed network), LFN is authenticated by network. If the authentication is done by MR, LFN and MR can have some security association. This MR is something like FA in Mobile IPv4. > Alternates were already discussed, like in Ryuji's initial basic nemo > draft, and the correspondent router model which is an evolution of your > MBG. Maybe we should write that draft :) There are also alternatives > based on nemo aware nodes, for instance having the node send zeroed out > RRHs (see RRH appendix 1) in the COTi, and then with the packets if the > test flies. > > Pascal Yes. Route optimization has many situations and there are many solutions for each cases. But I think we do not need to create the solution which solves all the situations. Maybe that kind of work takes more time. I want to discuss what kind of situations people are thinking about route optimization. That is also helpful for my clarification. As Thierry suggested in his e-mail, I want to contribute to your RO-taxonomy draft. -- Hiroyuki OHNISHI NTT Network Service Systems Laboratories Phone: +81-422-59-4132, Fax: +81-422-60-7460 mailto: ohnishi.hiroyuki@lab.ntt.co.jp From nemo-admin@ietf.org Fri Nov 7 04:35:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07267 for ; Fri, 7 Nov 2003 04:35: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 1AI31E-0002nL-I5; Fri, 07 Nov 2003 04:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI30l-0002mX-Nc for nemo@optimus.ietf.org; Fri, 07 Nov 2003 04:34: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 EAA07224 for ; Fri, 7 Nov 2003 04:34:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI30h-0001se-00 for nemo@ietf.org; Fri, 07 Nov 2003 04:34:32 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AI30h-0001s2-00 for nemo@ietf.org; Fri, 07 Nov 2003 04:34:31 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Nov 2003 10:31:45 +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 hA79Xqe2026262; Fri, 7 Nov 2003 10:33:52 +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, 7 Nov 2003 09:34:01 +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: ro draft Date: Fri, 7 Nov 2003 09:34:00 -0000 Message-ID: Thread-Topic: [nemo] RE: ro draft Thread-Index: AcOlEFK1muSsHGXrRMKehJrZIWCjUgAAOAOA From: "Pascal Thubert (pthubert)" To: "Hiroyuki OHNISHI" Cc: X-OriginalArrivalTime: 07 Nov 2003 09:34:01.0116 (UTC) FILETIME=[46BAFDC0:01C3A512] 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 > > 3) The MAP option should be changed in order to advertise the Nemo=20 > > capability > >=20 > Yes. To support multi-homing case, this option has to carry=20 > multiple CoAs. I want to extend capability in next draft. >=20 >=20 If the MAP is not Nemo aware, the whole design fails. So unless this becomes part of standard HMIP, the capability must be advertised. This is different deom basic nemo where the HA is well known. > >=20 > > 5) I like fig 6, and I believe the MAP should be placed that way=20 > > (fixed) as opposed to mobile. So I disagree with some text=20 > in 5.1. The=20 > > MAP option should be always there in the tree, and it is=20 > not the way=20 > > to detect that a MR is root. I suggest that you inherit=20 > that feature=20 > > from the TIO option in RRH draft, which is meant for that,=20 > as opposed=20 > > to overloading the MAP option. >=20 > I am sorry that fig 6 and the text in 5.1 lead some=20 > misunderstanding. I also assume the case in which MAP is not=20 > deployed in the network because whether MAP is deployed or=20 > not depends on the network's services. >=20 My point is that if the root-MR moves, the whole tree looses its MAP. I would not do that... >=20 > Yes. Route optimization has many situations and there are=20 > many solutions for each cases. But I think we do not need to=20 > create the solution which solves all the situations. Maybe=20 > that kind of work takes more time. I want to discuss what=20 > kind of situations people are thinking about route=20 > optimization. That is also helpful for my clarification. As=20 > Thierry suggested in his e-mail, I want to contribute to your=20 > RO-taxonomy draft. >=20 Yes, exposing the possible approaches is the goal of the taxonomy. From there the group can decide what to explore in which order. Mixing 2 solutions in a same draft makes it difficult to move forward. Pascal From exim@www1.ietf.org Fri Nov 7 04:35:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07285 for ; Fri, 7 Nov 2003 04:35: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 1AI31K-0002oN-0P for nemo-archive@odin.ietf.org; Fri, 07 Nov 2003 04:35:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA79Z9gO010808 for nemo-archive@odin.ietf.org; Fri, 7 Nov 2003 04: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 1AI31I-0002oE-V8 for nemo-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 04: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 EAA07247 for ; Fri, 7 Nov 2003 04:34:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI31F-0001tO-00 for nemo-web-archive@ietf.org; Fri, 07 Nov 2003 04:35:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI31F-0001tI-00 for nemo-web-archive@ietf.org; Fri, 07 Nov 2003 04: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 1AI31E-0002nL-I5; Fri, 07 Nov 2003 04:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI30l-0002mX-Nc for nemo@optimus.ietf.org; Fri, 07 Nov 2003 04:34: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 EAA07224 for ; Fri, 7 Nov 2003 04:34:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI30h-0001se-00 for nemo@ietf.org; Fri, 07 Nov 2003 04:34:32 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AI30h-0001s2-00 for nemo@ietf.org; Fri, 07 Nov 2003 04:34:31 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Nov 2003 10:31:45 +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 hA79Xqe2026262; Fri, 7 Nov 2003 10:33:52 +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, 7 Nov 2003 09:34:01 +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: ro draft Date: Fri, 7 Nov 2003 09:34:00 -0000 Message-ID: Thread-Topic: [nemo] RE: ro draft Thread-Index: AcOlEFK1muSsHGXrRMKehJrZIWCjUgAAOAOA From: "Pascal Thubert (pthubert)" To: "Hiroyuki OHNISHI" Cc: X-OriginalArrivalTime: 07 Nov 2003 09:34:01.0116 (UTC) FILETIME=[46BAFDC0:01C3A512] 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 > > 3) The MAP option should be changed in order to advertise the Nemo=20 > > capability > >=20 > Yes. To support multi-homing case, this option has to carry=20 > multiple CoAs. I want to extend capability in next draft. >=20 >=20 If the MAP is not Nemo aware, the whole design fails. So unless this becomes part of standard HMIP, the capability must be advertised. This is different deom basic nemo where the HA is well known. > >=20 > > 5) I like fig 6, and I believe the MAP should be placed that way=20 > > (fixed) as opposed to mobile. So I disagree with some text=20 > in 5.1. The=20 > > MAP option should be always there in the tree, and it is=20 > not the way=20 > > to detect that a MR is root. I suggest that you inherit=20 > that feature=20 > > from the TIO option in RRH draft, which is meant for that,=20 > as opposed=20 > > to overloading the MAP option. >=20 > I am sorry that fig 6 and the text in 5.1 lead some=20 > misunderstanding. I also assume the case in which MAP is not=20 > deployed in the network because whether MAP is deployed or=20 > not depends on the network's services. >=20 My point is that if the root-MR moves, the whole tree looses its MAP. I would not do that... >=20 > Yes. Route optimization has many situations and there are=20 > many solutions for each cases. But I think we do not need to=20 > create the solution which solves all the situations. Maybe=20 > that kind of work takes more time. I want to discuss what=20 > kind of situations people are thinking about route=20 > optimization. That is also helpful for my clarification. As=20 > Thierry suggested in his e-mail, I want to contribute to your=20 > RO-taxonomy draft. >=20 Yes, exposing the possible approaches is the goal of the taxonomy. From there the group can decide what to explore in which order. Mixing 2 solutions in a same draft makes it difficult to move forward. Pascal From nemo-admin@ietf.org Fri Nov 7 05:08:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08568 for ; Fri, 7 Nov 2003 05:08: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 1AI3X7-0005QQ-5w; Fri, 07 Nov 2003 05: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 1AI3X3-0005Oy-6O for nemo@optimus.ietf.org; Fri, 07 Nov 2003 05:07: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 FAA08562 for ; Fri, 7 Nov 2003 05:07:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3Wz-0002PY-00 for nemo@ietf.org; Fri, 07 Nov 2003 05:07:53 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1AI3Wz-0002PL-00 for nemo@ietf.org; Fri, 07 Nov 2003 05:07:53 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id hA7A7USr026379; Fri, 7 Nov 2003 03:07:30 -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 hA7A7PFX027822; Fri, 7 Nov 2003 04:07:27 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id C96002EC95; Fri, 7 Nov 2003 11:07:24 +0100 (CET) Message-ID: <3FAB6EDC.6040504@motorola.com> Date: Fri, 07 Nov 2003 11:07:24 +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: Vijay Devarapalli , nemo@ietf.org Subject: Re: [nemo] Short comment on draft-thubert-nemo-basic-usages-00 References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Hi Alex, > > >>Alexandru Petrescu wrote: >> >> >>> | >>> route v /48 >>> >>> HA >>> | /52 >>> --+-----+--+- . -+- . -+-- >>> | | | | >>> MR1 MR2 MRi MRN >>> /56 /56 /56 /56 >>> > > > The route /48 troubles me. Are the /56 aggregated by the /52, in > which case it is the aggregated home net model, The top-level /48 prefix has the same first 48 bits as the /52 and all the /56. The /52 prefix has the same first 52 bits as all the /56 prefixes. > or are the /52 and the /56 aggregated into the /48, in which case > this is an extended home network? In the picture above, the first 48 bits of the /48 prefix are the same as the first 48 bits of the /52 prefix and of the /56 prefixes. It's the same as above. Or, how do you see the /52 and /56 prefixes aggregated into the /48 such that it becomes an extended home network? Should I understand from you that if the /48 has the first 48 bits the same as the /52 (but the /52 has not the same first 52 bits as the /56's) then it is an extended home network and if the /52 has the first 52 bits the same as the first 52 bits of the /56 (but the /48 has not the same first 48 bits as the /52) then it is called an aggregated home network? Alex GBU From exim@www1.ietf.org Fri Nov 7 05:08:57 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08603 for ; Fri, 7 Nov 2003 05:08:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3Xi-0005Yt-7s for nemo-archive@odin.ietf.org; Fri, 07 Nov 2003 05:08:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7A8c6Y021378 for nemo-archive@odin.ietf.org; Fri, 7 Nov 2003 05:08:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3Xh-0005Yf-HZ for nemo-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 05:08:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08587 for ; Fri, 7 Nov 2003 05:08:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3Xd-0002Pt-00 for nemo-web-archive@ietf.org; Fri, 07 Nov 2003 05:08:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI3Xd-0002Ph-00 for nemo-web-archive@ietf.org; Fri, 07 Nov 2003 05:08:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3X7-0005QQ-5w; Fri, 07 Nov 2003 05: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 1AI3X3-0005Oy-6O for nemo@optimus.ietf.org; Fri, 07 Nov 2003 05:07: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 FAA08562 for ; Fri, 7 Nov 2003 05:07:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3Wz-0002PY-00 for nemo@ietf.org; Fri, 07 Nov 2003 05:07:53 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1AI3Wz-0002PL-00 for nemo@ietf.org; Fri, 07 Nov 2003 05:07:53 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id hA7A7USr026379; Fri, 7 Nov 2003 03:07:30 -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 hA7A7PFX027822; Fri, 7 Nov 2003 04:07:27 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id C96002EC95; Fri, 7 Nov 2003 11:07:24 +0100 (CET) Message-ID: <3FAB6EDC.6040504@motorola.com> Date: Fri, 07 Nov 2003 11:07:24 +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: Vijay Devarapalli , nemo@ietf.org Subject: Re: [nemo] Short comment on draft-thubert-nemo-basic-usages-00 References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Hi Alex, > > >>Alexandru Petrescu wrote: >> >> >>> | >>> route v /48 >>> >>> HA >>> | /52 >>> --+-----+--+- . -+- . -+-- >>> | | | | >>> MR1 MR2 MRi MRN >>> /56 /56 /56 /56 >>> > > > The route /48 troubles me. Are the /56 aggregated by the /52, in > which case it is the aggregated home net model, The top-level /48 prefix has the same first 48 bits as the /52 and all the /56. The /52 prefix has the same first 52 bits as all the /56 prefixes. > or are the /52 and the /56 aggregated into the /48, in which case > this is an extended home network? In the picture above, the first 48 bits of the /48 prefix are the same as the first 48 bits of the /52 prefix and of the /56 prefixes. It's the same as above. Or, how do you see the /52 and /56 prefixes aggregated into the /48 such that it becomes an extended home network? Should I understand from you that if the /48 has the first 48 bits the same as the /52 (but the /52 has not the same first 52 bits as the /56's) then it is an extended home network and if the /52 has the first 52 bits the same as the first 52 bits of the /56 (but the /48 has not the same first 48 bits as the /52) then it is called an aggregated home network? Alex GBU From nemo-admin@ietf.org Fri Nov 7 05:34:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09269 for ; Fri, 7 Nov 2003 05:34: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 1AI3wH-0006gL-E6; Fri, 07 Nov 2003 05: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 1AI3vi-0006fN-Uu for nemo@optimus.ietf.org; Fri, 07 Nov 2003 05:33:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09213 for ; Fri, 7 Nov 2003 05:33:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3vf-0002ha-00 for nemo@ietf.org; Fri, 07 Nov 2003 05:33:23 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AI3ve-0002hW-00 for nemo@ietf.org; Fri, 07 Nov 2003 05:33:22 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hA7AWN7q004293; Fri, 7 Nov 2003 03:32:23 -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 hA7AXEFX012354; Fri, 7 Nov 2003 04:33:15 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 0FE762EC95; Fri, 7 Nov 2003 11:33:15 +0100 (CET) Message-ID: <3FAB74EA.5050502@motorola.com> Date: Fri, 07 Nov 2003 11:33:14 +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: William D Ivancic , nemo@ietf.org Subject: Re: [nemo] Nemo Basic Support - IP in IP tunneling vs NAT transversal References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > For the record, doors does not have bubbles (that's teredo), but the > equivalent service is obtained naturally from Binding Updates. Thanks for the clarification. > My understanding is that the probes that T-Mobile is filtering out > are generally offensive and can be seen as DOS attacks on a low > bandwidth s.a. GPRS. This is about filtering things coming from the > outside, just like a firewall. Yes, that is right. I had it the other way around. > If T-Mobile wished to deploy a MIPv6 or Nemo service that uses their > CURRENT IPv4 GPRS structure, I believe that they could do so, even > with these filters active, using doors. Ok, I would like to stop talk about T-Mobile explicitely, but a "telecom operator". I was not looking at how a telecom operator might deploy MIP6 into the GPRS infrastructure. I was looking at how to use MIP6 or NEMO over the GPRS infrastructure of _any_ telecom operator offering GPRS and/or UMTS, not only one particular provider that might have MIP6. Basically use those as data pipes. Experience with several of those operators show that they behave in very different ways in terms of IP. Moreover continuous experience shows the firewall behaviour evolves: today they let pass some traffic tomorrow they stop other traffic. Some operators have NAT's that change the IP address _and_ the source port number, others change only the IP address. > The 'bubbles' would not be filtered because: > > - they come from the inside > - T-Mobile does not wish to kill their own service If abuses of network resources start to be popular among users of bubbles then bubbles will be filtered in the wink of the eye. > We have an implementation of doors that has already been successfully > tested with some GPRS deployments. I'd be glad to try more :) And we have an implementation of parts of UDP-in-IP NAT Traversal of Mobile IPv4 (RFC3519) combined with another implementation of NEMO and that we tested with several EU GPRS deployments (two in France, two in Portugal, one in Italy). Some of the operators we tested are active in several countries (e.g. Orange is active at least in France, Portugal and UK and surprisingly they use the same public IP address of their NAT farm(?) regardless of connecting to their GPRS in France or Portugal). Seems that T-Mobile in Germany too gives publicly routable addresses (non-NAT'ed) and for sure Vodafone in Chicago, Illinois gives non-NAT'ed addresses. So, where did you try the doors implementation, and what was the NAT behaviour? Alex GBU From exim@www1.ietf.org Fri Nov 7 05:34:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09286 for ; Fri, 7 Nov 2003 05:34: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 1AI3wK-0006hj-PQ for nemo-archive@odin.ietf.org; Fri, 07 Nov 2003 05:34:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7AY4Qx025765 for nemo-archive@odin.ietf.org; Fri, 7 Nov 2003 05:34:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3wK-0006hU-Kh for nemo-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 05: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 FAA09251 for ; Fri, 7 Nov 2003 05:33:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3wH-0002iM-00 for nemo-web-archive@ietf.org; Fri, 07 Nov 2003 05:34:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI3wG-0002iJ-00 for nemo-web-archive@ietf.org; Fri, 07 Nov 2003 05: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 1AI3wH-0006gL-E6; Fri, 07 Nov 2003 05: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 1AI3vi-0006fN-Uu for nemo@optimus.ietf.org; Fri, 07 Nov 2003 05:33:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09213 for ; Fri, 7 Nov 2003 05:33:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3vf-0002ha-00 for nemo@ietf.org; Fri, 07 Nov 2003 05:33:23 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AI3ve-0002hW-00 for nemo@ietf.org; Fri, 07 Nov 2003 05:33:22 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hA7AWN7q004293; Fri, 7 Nov 2003 03:32:23 -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 hA7AXEFX012354; Fri, 7 Nov 2003 04:33:15 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 0FE762EC95; Fri, 7 Nov 2003 11:33:15 +0100 (CET) Message-ID: <3FAB74EA.5050502@motorola.com> Date: Fri, 07 Nov 2003 11:33:14 +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: William D Ivancic , nemo@ietf.org Subject: Re: [nemo] Nemo Basic Support - IP in IP tunneling vs NAT transversal References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > For the record, doors does not have bubbles (that's teredo), but the > equivalent service is obtained naturally from Binding Updates. Thanks for the clarification. > My understanding is that the probes that T-Mobile is filtering out > are generally offensive and can be seen as DOS attacks on a low > bandwidth s.a. GPRS. This is about filtering things coming from the > outside, just like a firewall. Yes, that is right. I had it the other way around. > If T-Mobile wished to deploy a MIPv6 or Nemo service that uses their > CURRENT IPv4 GPRS structure, I believe that they could do so, even > with these filters active, using doors. Ok, I would like to stop talk about T-Mobile explicitely, but a "telecom operator". I was not looking at how a telecom operator might deploy MIP6 into the GPRS infrastructure. I was looking at how to use MIP6 or NEMO over the GPRS infrastructure of _any_ telecom operator offering GPRS and/or UMTS, not only one particular provider that might have MIP6. Basically use those as data pipes. Experience with several of those operators show that they behave in very different ways in terms of IP. Moreover continuous experience shows the firewall behaviour evolves: today they let pass some traffic tomorrow they stop other traffic. Some operators have NAT's that change the IP address _and_ the source port number, others change only the IP address. > The 'bubbles' would not be filtered because: > > - they come from the inside > - T-Mobile does not wish to kill their own service If abuses of network resources start to be popular among users of bubbles then bubbles will be filtered in the wink of the eye. > We have an implementation of doors that has already been successfully > tested with some GPRS deployments. I'd be glad to try more :) And we have an implementation of parts of UDP-in-IP NAT Traversal of Mobile IPv4 (RFC3519) combined with another implementation of NEMO and that we tested with several EU GPRS deployments (two in France, two in Portugal, one in Italy). Some of the operators we tested are active in several countries (e.g. Orange is active at least in France, Portugal and UK and surprisingly they use the same public IP address of their NAT farm(?) regardless of connecting to their GPRS in France or Portugal). Seems that T-Mobile in Germany too gives publicly routable addresses (non-NAT'ed) and for sure Vodafone in Chicago, Illinois gives non-NAT'ed addresses. So, where did you try the doors implementation, and what was the NAT behaviour? Alex GBU From nemo-admin@ietf.org Fri Nov 7 13:45:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28699 for ; Fri, 7 Nov 2003 13:45: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 1AIBbT-0006vi-4P; Fri, 07 Nov 2003 13:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBb8-0006q6-FB for nemo@optimus.ietf.org; Fri, 07 Nov 2003 13:44: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 NAA28601 for ; Fri, 7 Nov 2003 13:44:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBb6-00014p-00 for nemo@ietf.org; Fri, 07 Nov 2003 13:44:40 -0500 Received: from letters.cs.ucsb.edu ([128.111.41.13]) by ietf-mx with esmtp (Exim 4.12) id 1AIBb5-00014l-00 for nemo@ietf.org; Fri, 07 Nov 2003 13:44:39 -0500 Received: from ella (ella [128.111.43.201]) by letters.cs.ucsb.edu (8.11.7+Sun/8.11.7) with ESMTP id hA7Iic221834 for ; Fri, 7 Nov 2003 10:44:38 -0800 (PST) Date: Fri, 7 Nov 2003 10:44:38 -0800 (PST) From: "Krishna N. Ramachandran" X-Sender: krishna@ella To: nemo@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [nemo] AODV @ IETF Project Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 there, Mobile ad hoc networks have typically been deployed on a small scale in restricted environments. The AODV@IETF project aims to make available the first ever publicly-usable ad hoc network at the 58th IETF conference to be held in Minneapolis, MN, USA from November 9-14. The AODV network, scheduled to go live at 12:01 AM on the 10th of November, a Monday, will support Internet capable AODV implementations for the Microsoft Windows XP and Linux operating systems. Our goals behind the project are to demonstrate the capabilities of ad hoc networks to the general public and also to evaluate the performance of ad hoc networks when used on a large-scale in the real world. We welcome and encourage your participation in the ad hoc network at the IETF. Please visit the AODV@IETF website: http://moment.cs.ucsb.edu/aodv-ietf for more details. On the same website, we will very soon make available the software packages needed to join the ad hoc network. Please email me if you have any questions at krishna@cs.ucsb.edu. Thank you and looking forward to your participation, Krishna Ramachandran, UC Santa Barbara. From exim@www1.ietf.org Fri Nov 7 13:45:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28716 for ; Fri, 7 Nov 2003 13:45: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 1AIBbX-00071B-Gk for nemo-archive@odin.ietf.org; Fri, 07 Nov 2003 13:45:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7Ij7Zp026971 for nemo-archive@odin.ietf.org; Fri, 7 Nov 2003 13:45:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBbX-0006zY-8G for nemo-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 13:45: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 NAA28650 for ; Fri, 7 Nov 2003 13:44:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBbV-00015E-00 for nemo-web-archive@ietf.org; Fri, 07 Nov 2003 13:45:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIBbU-00015B-00 for nemo-web-archive@ietf.org; Fri, 07 Nov 2003 13:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBbT-0006vi-4P; Fri, 07 Nov 2003 13:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBb8-0006q6-FB for nemo@optimus.ietf.org; Fri, 07 Nov 2003 13:44: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 NAA28601 for ; Fri, 7 Nov 2003 13:44:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBb6-00014p-00 for nemo@ietf.org; Fri, 07 Nov 2003 13:44:40 -0500 Received: from letters.cs.ucsb.edu ([128.111.41.13]) by ietf-mx with esmtp (Exim 4.12) id 1AIBb5-00014l-00 for nemo@ietf.org; Fri, 07 Nov 2003 13:44:39 -0500 Received: from ella (ella [128.111.43.201]) by letters.cs.ucsb.edu (8.11.7+Sun/8.11.7) with ESMTP id hA7Iic221834 for ; Fri, 7 Nov 2003 10:44:38 -0800 (PST) Date: Fri, 7 Nov 2003 10:44:38 -0800 (PST) From: "Krishna N. Ramachandran" X-Sender: krishna@ella To: nemo@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [nemo] AODV @ IETF Project Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: 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 there, Mobile ad hoc networks have typically been deployed on a small scale in restricted environments. The AODV@IETF project aims to make available the first ever publicly-usable ad hoc network at the 58th IETF conference to be held in Minneapolis, MN, USA from November 9-14. The AODV network, scheduled to go live at 12:01 AM on the 10th of November, a Monday, will support Internet capable AODV implementations for the Microsoft Windows XP and Linux operating systems. Our goals behind the project are to demonstrate the capabilities of ad hoc networks to the general public and also to evaluate the performance of ad hoc networks when used on a large-scale in the real world. We welcome and encourage your participation in the ad hoc network at the IETF. Please visit the AODV@IETF website: http://moment.cs.ucsb.edu/aodv-ietf for more details. On the same website, we will very soon make available the software packages needed to join the ad hoc network. Please email me if you have any questions at krishna@cs.ucsb.edu. Thank you and looking forward to your participation, Krishna Ramachandran, UC Santa Barbara. From nemo-admin@ietf.org Sat Nov 8 22:06:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04994 for ; Sat, 8 Nov 2003 22:06: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 1AIftr-0002gp-Ju; Sat, 08 Nov 2003 22:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIfQZ-0001m5-Pw for nemo@optimus.ietf.org; Sat, 08 Nov 2003 21:35: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 VAA04509 for ; Sat, 8 Nov 2003 21:35:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIfQW-0000y1-00 for nemo@ietf.org; Sat, 08 Nov 2003 21:35:44 -0500 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1AIfQW-0000xc-00 for nemo@ietf.org; Sat, 08 Nov 2003 21:35:44 -0500 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id DD4E8689B8 for ; Sat, 8 Nov 2003 21:35:14 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id hA92ZEJs025987 for ; Sat, 8 Nov 2003 21:35:14 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.10/8.12.10) with ESMTP id hA92ZD7J005016 for ; Sat, 8 Nov 2003 21:35:13 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20031108213150.017b92a8@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sat, 08 Nov 2003 21:34:31 -0500 To: From: William D Ivancic Subject: RE: [nemo] Nemo Basic Support - IP in IP tunneling vs NAT transversal In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , The document at this URL was generated to explain the packet filtering problem to T-Mobile. Perhaps this helps. http://roland.grc.nasa.gov/~ivancic/t-mobile/administrative_filtering.pdf Don't be surprised when others begin implementing such filtering. Will From nemo-admin@ietf.org Sat Nov 8 22:06:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04991 for ; Sat, 8 Nov 2003 22:06: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 1AIftq-0002fs-7q; Sat, 08 Nov 2003 22: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 1AIeoy-0000Uy-TW for nemo@optimus.ietf.org; Sat, 08 Nov 2003 20:56:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03818 for ; Sat, 8 Nov 2003 20:56:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIeow-0000UW-00 for nemo@ietf.org; Sat, 08 Nov 2003 20:56:54 -0500 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 1AIeov-0000UE-00 for nemo@ietf.org; Sat, 08 Nov 2003 20:56:53 -0500 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 8B53B6B9CD for ; Sat, 8 Nov 2003 20:56:23 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id hA91uMJs022567 for ; Sat, 8 Nov 2003 20:56:22 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.10/8.12.10) with ESMTP id hA91uK7J001048 for ; Sat, 8 Nov 2003 20:56:20 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20031108084928.01fc5328@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sat, 08 Nov 2003 09:01:07 -0500 To: nemo@ietf.org From: William D Ivancic Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_52054370==.ALT" Subject: [nemo] multihoming drafts Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --=====================_52054370==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I have been re-reading the mulihoming drafts and wanted to capture this thought before I forget it. First, I like the idea of eventually combining theses drafts and appreciate the time the authors took putting them together. Second (the captured thought), It is stated in various places and ways that "No assumptions is made on whether or not the home agents belongs to the same administrative domain." I believe this is a good assumption as we shouldn't preclude this. However, I think it would be useful and wise to place as a statement somewhere (probably the security considerations section) that having multiple home agents in multiple administrative domains does present some security concerns for both the mobile network and those networks which have now been attached via the mobile network. Whereas I can think of reason to do this, particularly for personal mobile networks. I can also see corporate security policy disallowing such configurations. Will --=====================_52054370==.ALT Content-Type: text/html; charset="us-ascii" I have been re-reading the mulihoming drafts and wanted to capture this thought before I forget it.

First, I like the idea of eventually combining theses drafts and appreciate the time the authors took putting them together.

Second (the captured thought), It is stated in various places and ways that "No assumptions is made on whether or not the home agents belongs to the same administrative domain."  I believe this is a good assumption as we shouldn't preclude this.  However, I think it would be useful and wise to place as a statement somewhere (probably the security considerations section) that having multiple home agents in multiple administrative domains does present some security concerns for both the mobile network and those networks which have now been attached via the mobile network.  Whereas I can think of reason to do this, particularly for personal mobile networks.  I can also see corporate security policy disallowing such configurations.

Will


 --=====================_52054370==.ALT-- From exim@www1.ietf.org Sat Nov 8 22:06:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05052 for ; Sat, 8 Nov 2003 22:06:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIfu3-0002jz-Vs for nemo-archive@odin.ietf.org; Sat, 08 Nov 2003 22:06:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA936FHY010529 for nemo-archive@odin.ietf.org; Sat, 8 Nov 2003 22:06:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIfu3-0002jk-Qf for nemo-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 22:06: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 WAA04973 for ; Sat, 8 Nov 2003 22:06:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIfu0-0001Ie-00 for nemo-web-archive@ietf.org; Sat, 08 Nov 2003 22:06:12 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AIfu0-0001IQ-00 for nemo-web-archive@ietf.org; Sat, 08 Nov 2003 22:06:12 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AIfu1-0001j9-BH for nemo-web-archive@ietf.org; Sat, 08 Nov 2003 22:06:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIftq-0002gW-PQ; Sat, 08 Nov 2003 22: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 1AIeoz-0000V3-2V for nemo@optimus.ietf.org; Sat, 08 Nov 2003 20:56: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 UAA03820 for ; Sat, 8 Nov 2003 20:56:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIeow-0000UZ-00 for nemo@ietf.org; Sat, 08 Nov 2003 20:56:54 -0500 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1AIeov-0000UF-00 for nemo@ietf.org; Sat, 08 Nov 2003 20:56:54 -0500 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 1BA13689B8 for ; Sat, 8 Nov 2003 20:56:24 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id hA91uNJs022572 for ; Sat, 8 Nov 2003 20:56:23 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.10/8.12.10) with ESMTP id hA91uK7L001048 for ; Sat, 8 Nov 2003 20:56:23 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20031108092238.02148788@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sat, 08 Nov 2003 09:28:57 -0500 To: nemo@ietf.org From: William D Ivancic Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [nemo] Multihoming and Load sharing. Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Whereas I can see configurations where it would be advantageous to allow load sharing such as if one has two or three G3 wireless links up all with relatively the same cost and bandwidth. However, IMHO there should definitely be a mechanism to turn load sharing off. It would be quite useless and very expensive to load share between and WiFi link cost $80.00 per month unlimited service and a 64 kbps satellite link costing $1.00 per minute. Will From exim@www1.ietf.org Sat Nov 8 22:06:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05051 for ; Sat, 8 Nov 2003 22:06:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIfu3-0002ji-N3 for nemo-archive@odin.ietf.org; Sat, 08 Nov 2003 22:06:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA936FxY010512 for nemo-archive@odin.ietf.org; Sat, 8 Nov 2003 22:06:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIfu3-0002jT-Bl for nemo-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 22:06: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 WAA04966 for ; Sat, 8 Nov 2003 22:06:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIfu0-0001IW-00 for nemo-web-archive@ietf.org; Sat, 08 Nov 2003 22:06:12 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AIftz-0001IQ-00 for nemo-web-archive@ietf.org; Sat, 08 Nov 2003 22:06:11 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AIftz-0001j7-Tl for nemo-web-archive@ietf.org; Sat, 08 Nov 2003 22:06:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIftr-0002gp-Ju; Sat, 08 Nov 2003 22:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIfQZ-0001m5-Pw for nemo@optimus.ietf.org; Sat, 08 Nov 2003 21:35: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 VAA04509 for ; Sat, 8 Nov 2003 21:35:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIfQW-0000y1-00 for nemo@ietf.org; Sat, 08 Nov 2003 21:35:44 -0500 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1AIfQW-0000xc-00 for nemo@ietf.org; Sat, 08 Nov 2003 21:35:44 -0500 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id DD4E8689B8 for ; Sat, 8 Nov 2003 21:35:14 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id hA92ZEJs025987 for ; Sat, 8 Nov 2003 21:35:14 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.10/8.12.10) with ESMTP id hA92ZD7J005016 for ; Sat, 8 Nov 2003 21:35:13 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20031108213150.017b92a8@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sat, 08 Nov 2003 21:34:31 -0500 To: From: William D Ivancic Subject: RE: [nemo] Nemo Basic Support - IP in IP tunneling vs NAT transversal In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , The document at this URL was generated to explain the packet filtering problem to T-Mobile. Perhaps this helps. http://roland.grc.nasa.gov/~ivancic/t-mobile/administrative_filtering.pdf Don't be surprised when others begin implementing such filtering. Will From nemo-admin@ietf.org Sat Nov 8 22:52:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04992 for ; Sat, 8 Nov 2003 22:06: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 1AIftq-0002gW-PQ; Sat, 08 Nov 2003 22: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 1AIeoz-0000V3-2V for nemo@optimus.ietf.org; Sat, 08 Nov 2003 20:56: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 UAA03820 for ; Sat, 8 Nov 2003 20:56:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIeow-0000UZ-00 for nemo@ietf.org; Sat, 08 Nov 2003 20:56:54 -0500 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1AIeov-0000UF-00 for nemo@ietf.org; Sat, 08 Nov 2003 20:56:54 -0500 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 1BA13689B8 for ; Sat, 8 Nov 2003 20:56:24 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id hA91uNJs022572 for ; Sat, 8 Nov 2003 20:56:23 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.10/8.12.10) with ESMTP id hA91uK7L001048 for ; Sat, 8 Nov 2003 20:56:23 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20031108092238.02148788@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sat, 08 Nov 2003 09:28:57 -0500 To: nemo@ietf.org From: William D Ivancic Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [nemo] Multihoming and Load sharing. Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Whereas I can see configurations where it would be advantageous to allow load sharing such as if one has two or three G3 wireless links up all with relatively the same cost and bandwidth. However, IMHO there should definitely be a mechanism to turn load sharing off. It would be quite useless and very expensive to load share between and WiFi link cost $80.00 per month unlimited service and a 64 kbps satellite link costing $1.00 per minute. Will From nemo-admin@ietf.org Sat Nov 8 22:52:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04993 for ; Sat, 8 Nov 2003 22:06: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 1AIftr-0002gh-6O; Sat, 08 Nov 2003 22:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIeoz-0000V8-Qn for nemo@optimus.ietf.org; Sat, 08 Nov 2003 20:56: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 UAA03824 for ; Sat, 8 Nov 2003 20:56:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIeox-0000Ug-00 for nemo@ietf.org; Sat, 08 Nov 2003 20:56:55 -0500 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 1AIeow-0000UG-00 for nemo@ietf.org; Sat, 08 Nov 2003 20:56:54 -0500 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 463CD6B9D8 for ; Sat, 8 Nov 2003 20:56:25 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id hA91uOJs022575 for ; Sat, 8 Nov 2003 20:56:24 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.10/8.12.10) with ESMTP id hA91uK7N001048 for ; Sat, 8 Nov 2003 20:56:24 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20031108092920.02148a60@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sat, 08 Nov 2003 09:42:10 -0500 To: nemo@ietf.org From: William D Ivancic Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_52054440==.ALT" Subject: [nemo] Multihoming and Policy-Base routing regarding dynamic interfaces Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --=====================_52054440==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Relative to draft draft-charbon-nemo-multihoming-evaluation-00 Although not strictly within the scope of the nemo charter, I think this may be useful to understand. I (and probably others) am ignorant on setting up policy-base routing. I believe this is somewhat straight forward when interfaces are static and assumed to be active (the same goes for load sharing). However, It appears that this would be very difficult when interfaces (via tunnels) are dynamically being created and removed. Can anyone provide some insight as to how this might be done and if it would require significant modifications to today's router implementations? It seams to me that if a force some traffic over a route and that route goes away, one may still wish for that traffic to get through on another interface (tunnel). Will --=====================_52054440==.ALT Content-Type: text/html; charset="us-ascii" Relative to draft draft-charbon-nemo-multihoming-evaluation-00


Although not strictly within the scope of the nemo charter, I think this may be useful to understand.  I (and probably others) am ignorant on setting up policy-base routing.   I believe this is somewhat straight forward when interfaces are static and assumed to be active (the same goes for load sharing).  However, It appears that this would be very difficult when  interfaces (via tunnels) are dynamically being created and removed.

Can anyone provide some insight as to how this might be done and if it would require significant modifications to today's router implementations?

It seams to me that if a force some traffic over a route and that route goes away, one may still wish for that traffic to get through on another interface (tunnel).

Will --=====================_52054440==.ALT-- From exim@www1.ietf.org Sat Nov 8 22:52:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05056 for ; Sat, 8 Nov 2003 22:06:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIfu4-0002ka-9e for nemo-archive@odin.ietf.org; Sat, 08 Nov 2003 22:06:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA936GYt010566 for nemo-archive@odin.ietf.org; Sat, 8 Nov 2003 22:06:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIfu3-0002jj-PH for nemo-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 22:06: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 WAA04970 for ; Sat, 8 Nov 2003 22:06:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIfu0-0001IZ-00 for nemo-web-archive@ietf.org; Sat, 08 Nov 2003 22:06:12 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AIftz-0001IR-00 for nemo-web-archive@ietf.org; Sat, 08 Nov 2003 22:06:11 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AIftz-0001j8-Vb for nemo-web-archive@ietf.org; Sat, 08 Nov 2003 22:06:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIftr-0002gh-6O; Sat, 08 Nov 2003 22:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIeoz-0000V8-Qn for nemo@optimus.ietf.org; Sat, 08 Nov 2003 20:56: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 UAA03824 for ; Sat, 8 Nov 2003 20:56:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIeox-0000Ug-00 for nemo@ietf.org; Sat, 08 Nov 2003 20:56:55 -0500 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 1AIeow-0000UG-00 for nemo@ietf.org; Sat, 08 Nov 2003 20:56:54 -0500 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 463CD6B9D8 for ; Sat, 8 Nov 2003 20:56:25 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id hA91uOJs022575 for ; Sat, 8 Nov 2003 20:56:24 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.10/8.12.10) with ESMTP id hA91uK7N001048 for ; Sat, 8 Nov 2003 20:56:24 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20031108092920.02148a60@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sat, 08 Nov 2003 09:42:10 -0500 To: nemo@ietf.org From: William D Ivancic Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_52054440==.ALT" Subject: [nemo] Multihoming and Policy-Base routing regarding dynamic interfaces Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --=====================_52054440==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Relative to draft draft-charbon-nemo-multihoming-evaluation-00 Although not strictly within the scope of the nemo charter, I think this may be useful to understand. I (and probably others) am ignorant on setting up policy-base routing. I believe this is somewhat straight forward when interfaces are static and assumed to be active (the same goes for load sharing). However, It appears that this would be very difficult when interfaces (via tunnels) are dynamically being created and removed. Can anyone provide some insight as to how this might be done and if it would require significant modifications to today's router implementations? It seams to me that if a force some traffic over a route and that route goes away, one may still wish for that traffic to get through on another interface (tunnel). Will --=====================_52054440==.ALT Content-Type: text/html; charset="us-ascii" Relative to draft draft-charbon-nemo-multihoming-evaluation-00


Although not strictly within the scope of the nemo charter, I think this may be useful to understand.  I (and probably others) am ignorant on setting up policy-base routing.   I believe this is somewhat straight forward when interfaces are static and assumed to be active (the same goes for load sharing).  However, It appears that this would be very difficult when  interfaces (via tunnels) are dynamically being created and removed.

Can anyone provide some insight as to how this might be done and if it would require significant modifications to today's router implementations?

It seams to me that if a force some traffic over a route and that route goes away, one may still wish for that traffic to get through on another interface (tunnel).

Will --=====================_52054440==.ALT-- From exim@www1.ietf.org Sat Nov 8 22:52:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05053 for ; Sat, 8 Nov 2003 22:06:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIfu4-0002kJ-4z for nemo-archive@odin.ietf.org; Sat, 08 Nov 2003 22:06:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA936G1o010549 for nemo-archive@odin.ietf.org; Sat, 8 Nov 2003 22:06:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIfu4-0002k0-0c for nemo-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 22:06: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 WAA04976 for ; Sat, 8 Nov 2003 22:06:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIfu0-0001Ij-00 for nemo-web-archive@ietf.org; Sat, 08 Nov 2003 22:06:12 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AIfu0-0001IR-00 for nemo-web-archive@ietf.org; Sat, 08 Nov 2003 22:06:12 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AIfu0-0001j6-JR for nemo-web-archive@ietf.org; Sat, 08 Nov 2003 22:06:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIftq-0002fs-7q; Sat, 08 Nov 2003 22: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 1AIeoy-0000Uy-TW for nemo@optimus.ietf.org; Sat, 08 Nov 2003 20:56:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03818 for ; Sat, 8 Nov 2003 20:56:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIeow-0000UW-00 for nemo@ietf.org; Sat, 08 Nov 2003 20:56:54 -0500 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 1AIeov-0000UE-00 for nemo@ietf.org; Sat, 08 Nov 2003 20:56:53 -0500 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 8B53B6B9CD for ; Sat, 8 Nov 2003 20:56:23 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id hA91uMJs022567 for ; Sat, 8 Nov 2003 20:56:22 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.10/8.12.10) with ESMTP id hA91uK7J001048 for ; Sat, 8 Nov 2003 20:56:20 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20031108084928.01fc5328@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sat, 08 Nov 2003 09:01:07 -0500 To: nemo@ietf.org From: William D Ivancic Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_52054370==.ALT" Subject: [nemo] multihoming drafts Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --=====================_52054370==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I have been re-reading the mulihoming drafts and wanted to capture this thought before I forget it. First, I like the idea of eventually combining theses drafts and appreciate the time the authors took putting them together. Second (the captured thought), It is stated in various places and ways that "No assumptions is made on whether or not the home agents belongs to the same administrative domain." I believe this is a good assumption as we shouldn't preclude this. However, I think it would be useful and wise to place as a statement somewhere (probably the security considerations section) that having multiple home agents in multiple administrative domains does present some security concerns for both the mobile network and those networks which have now been attached via the mobile network. Whereas I can think of reason to do this, particularly for personal mobile networks. I can also see corporate security policy disallowing such configurations. Will --=====================_52054370==.ALT Content-Type: text/html; charset="us-ascii" I have been re-reading the mulihoming drafts and wanted to capture this thought before I forget it.

First, I like the idea of eventually combining theses drafts and appreciate the time the authors took putting them together.

Second (the captured thought), It is stated in various places and ways that "No assumptions is made on whether or not the home agents belongs to the same administrative domain."  I believe this is a good assumption as we shouldn't preclude this.  However, I think it would be useful and wise to place as a statement somewhere (probably the security considerations section) that having multiple home agents in multiple administrative domains does present some security concerns for both the mobile network and those networks which have now been attached via the mobile network.  Whereas I can think of reason to do this, particularly for personal mobile networks.  I can also see corporate security policy disallowing such configurations.

Will


 --=====================_52054370==.ALT-- From nemo-admin@ietf.org Sat Nov 8 23:39:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06960 for ; Sat, 8 Nov 2003 23:39: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 1AIhLo-0006qO-Tl; Sat, 08 Nov 2003 23: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 1AIhLL-0006nE-A3 for nemo@optimus.ietf.org; Sat, 08 Nov 2003 23:38: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 XAA06897 for ; Sat, 8 Nov 2003 23:38:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIhLJ-0002XS-00 for nemo@ietf.org; Sat, 08 Nov 2003 23:38:29 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AIhLI-0002XA-00 for nemo@ietf.org; Sat, 08 Nov 2003 23:38:28 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA94bOm26492; Sat, 8 Nov 2003 20:37:24 -0800 X-mProtect: <200311090437> Nokia Silicon Valley Messaging Protection Received: from danira-pool051115.americas.nokia.com (10.241.51.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdodZqAQ; Sat, 08 Nov 2003 20:37:23 PST Message-ID: <3FADC478.6080200@iprg.nokia.com> Date: Sat, 08 Nov 2003 20:37:12 -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: souhwanj@ssu.ac.kr CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] commens on draft-jung-nemo-threat-analysis-01.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi, I just read through the threat analysis document and sorry to say I was disappointed with the document. many of the threats are not Nemo specific. for example it talks about a compromised Access Router, an attacker injecting false Router Advertisement information in the home link, a compromised Home Agent, etc.... all these threats should be removed from the document. some of the threats are also not valid. specific comments follow. Vijay > - Discard registration messages from MR to FA > This threat is a sort of DoS attack to block network connectivity > service to MR. The attacker compromises the FA, and keep discarding > the registration message from MR. The result of the attack is no > availability of network connection service to the mobile networks. remove this threat. it is not really Nemo specific. if the access router is compromised, there isnt much you can do about it. the access router could deny network connection to mobile nodes, fixed nodes with wireless access, etc. > > - Corrupted routing information > Attacker may send corrupted routing information to MR and cause > network instability such as network congestion or looping. If the > MR is in the visited domain, it will not respond to the unsolicited > RA. But while the MR is in home domain, it still accepts the RA > messages, and may get screwed up with wrong routing information. if an attacker gets into the home domain and sends "corrupted routing information", you have a lot more serious problem at hand. remove this. > - eavesdropping/replay of messages between MR and HA > All the data packets between MR and HA have to go through the > bi-directional tunnel. This tunnel should be secured by IPsec. > But some of the routing information that may not go through > this tunnel should be secured. this didnt make a lot of sense. > - eavesdropping/replay of messages between MNN and CN > The messages between MNN and CN are going through the > bi-directional tunnel, but there is no protection against > sniffing data between MR and MNN or between HA and CN. So > security mechanisms should be applied on the part of the > path uncovered. again, nothing Nemo specific. this is applicable to any two nodes (whether mobile or not). the best solution for this is to have end-to-end security between MNN and CN. > > - location privacy > Monitoring and analyzing the characteristics of data traffic > along the communication paths reveals some information on routing > and location privacy. not Nemo specific. please remove. > - MR-HA spoofing > MR-HA is the permanent address assigned statically or > dynamically to the MR by HA. MR-HA should be used for > identification of MR while it is in the visited domain. > The compromised MR can register to FA with a spoofed MR-HA, > and try to collect data destinated to the victim address. this is an IPv4 model. in Nemo, MR deals directly with the HA. it does no registration with FA/AR. > - Cache poisoning > The cache data for routing table in MR can be corrupted to > subvert routing path. The data packet could be redirected or > looped causing network instability. which "Cache"? > 4.2 Misbehavior of HA > - sniffing of tunneled packet > The IPsec transport mode should be used for securing the > tunneled packets between MR and HA. With the compromise of > the HA, the attacker can sniff the decrypted data packet > in HA. > > - corruption of binding cache > HA keeps managing the BU information on binding cache. > With the corruption of binding information, the attacker > can redirects packets to where he want to deliver them. remove 4.2. I dont expect the HA to misbehave. there isnt much the Nemo protocol basic/extended can do if the HA misbehaves. > > 4.4 Denial of Service > Denial of Service attack is possible against MR and HA by flooding > BU messages and bogus tunneled packets. The attack can be more > effective with distributed fake MRs or HAs. Binding Updates are rate-limited. this maybe not be possible. > 5.1 Corruption of Binding Cache by inside attacker the entire section 5.1 needs to be re-written without assuming NAT or NAT-PT on the mobile router. > 5.3 Attack to Location Privacy by Traffic Analysis > > In the basic NEMO configurations, all the traffic from mobile > network are supposed to go through the bi-directional tunnel > between MR and HA. The HA can collect all the packets in > IP-in-IP tunne, decapsulates them, and forwards them to the CNs. > > > |-----| |----| IP-in-IP tunnel |----| |----| > | MNN |---------| MR | ================== | HA |---------| CN | > |-----| 1 |----| 2 |----| 3 |----| > > > The outside attacker can monitor the traffic in path 2 and 3. how is the attacker on both path 2 and 3? > 6. Security Requirements for NEMO > > The basic support protocol for NEMO is based on the MIPv6 > operations except the bi-directional tunnel operations between > MR and HA. Therefore, most of the security requirements are > already addressed in MIPv6 WG documents[4], so this draft describes > the security requirements only against new threats in NEMO. > The following security requirements SHOULD be addressed in NEMO > basic and extended documents. > > 6.1 MR SHOULD check the contents of the packet from MNN inside , > and assure that the packet does not include fake information > in the critical messages such as BU, prefix discovery, or > ICMP messages. this is a really bad idea. the only thing the MR should be doing is ingress filtering and access control check. it *should* not look into the packet contents. and what if the MNN is using end-to-end ESP encryption? the MR cant see the packet even if it wants to. > 6.2 The IP-in-IP encapsulated packet SHOULD be authenticated > between MR and HA, and per-packet authentication at MR > SHOULD be enforced. authenticated? why? the HA already makes sure that the CoA (on the outer header) is authorized to tunnel packets for MNN's address (in the inner header). you dont need per-packet authentication. > 6.3 The amount of traffic from MNN through the IP-in-IP tunnel > SHOULD be secured to protect the location privacy against > traffic analysis. The amount of traffic through IP-in-IP > tunnel MAY be secured using expanded field as in IPsec > ESP[10]. when did location privacy become a strong requirement? if the MNN is concerned about this, it should be using RFC 3041 addresses. From exim@www1.ietf.org Sat Nov 8 23:39:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06978 for ; Sat, 8 Nov 2003 23:39: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 1AIhLv-0006tD-5i for nemo-archive@odin.ietf.org; Sat, 08 Nov 2003 23:39:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA94d7Mt026477 for nemo-archive@odin.ietf.org; Sat, 8 Nov 2003 23:39:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIhLv-0006sy-09 for nemo-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 23:39: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 XAA06927 for ; Sat, 8 Nov 2003 23:38:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIhLs-0002Y8-00 for nemo-web-archive@ietf.org; Sat, 08 Nov 2003 23:39:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIhLs-0002Y5-00 for nemo-web-archive@ietf.org; Sat, 08 Nov 2003 23:39:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIhLo-0006qO-Tl; Sat, 08 Nov 2003 23: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 1AIhLL-0006nE-A3 for nemo@optimus.ietf.org; Sat, 08 Nov 2003 23:38: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 XAA06897 for ; Sat, 8 Nov 2003 23:38:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIhLJ-0002XS-00 for nemo@ietf.org; Sat, 08 Nov 2003 23:38:29 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AIhLI-0002XA-00 for nemo@ietf.org; Sat, 08 Nov 2003 23:38:28 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA94bOm26492; Sat, 8 Nov 2003 20:37:24 -0800 X-mProtect: <200311090437> Nokia Silicon Valley Messaging Protection Received: from danira-pool051115.americas.nokia.com (10.241.51.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdodZqAQ; Sat, 08 Nov 2003 20:37:23 PST Message-ID: <3FADC478.6080200@iprg.nokia.com> Date: Sat, 08 Nov 2003 20:37:12 -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: souhwanj@ssu.ac.kr CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] commens on draft-jung-nemo-threat-analysis-01.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi, I just read through the threat analysis document and sorry to say I was disappointed with the document. many of the threats are not Nemo specific. for example it talks about a compromised Access Router, an attacker injecting false Router Advertisement information in the home link, a compromised Home Agent, etc.... all these threats should be removed from the document. some of the threats are also not valid. specific comments follow. Vijay > - Discard registration messages from MR to FA > This threat is a sort of DoS attack to block network connectivity > service to MR. The attacker compromises the FA, and keep discarding > the registration message from MR. The result of the attack is no > availability of network connection service to the mobile networks. remove this threat. it is not really Nemo specific. if the access router is compromised, there isnt much you can do about it. the access router could deny network connection to mobile nodes, fixed nodes with wireless access, etc. > > - Corrupted routing information > Attacker may send corrupted routing information to MR and cause > network instability such as network congestion or looping. If the > MR is in the visited domain, it will not respond to the unsolicited > RA. But while the MR is in home domain, it still accepts the RA > messages, and may get screwed up with wrong routing information. if an attacker gets into the home domain and sends "corrupted routing information", you have a lot more serious problem at hand. remove this. > - eavesdropping/replay of messages between MR and HA > All the data packets between MR and HA have to go through the > bi-directional tunnel. This tunnel should be secured by IPsec. > But some of the routing information that may not go through > this tunnel should be secured. this didnt make a lot of sense. > - eavesdropping/replay of messages between MNN and CN > The messages between MNN and CN are going through the > bi-directional tunnel, but there is no protection against > sniffing data between MR and MNN or between HA and CN. So > security mechanisms should be applied on the part of the > path uncovered. again, nothing Nemo specific. this is applicable to any two nodes (whether mobile or not). the best solution for this is to have end-to-end security between MNN and CN. > > - location privacy > Monitoring and analyzing the characteristics of data traffic > along the communication paths reveals some information on routing > and location privacy. not Nemo specific. please remove. > - MR-HA spoofing > MR-HA is the permanent address assigned statically or > dynamically to the MR by HA. MR-HA should be used for > identification of MR while it is in the visited domain. > The compromised MR can register to FA with a spoofed MR-HA, > and try to collect data destinated to the victim address. this is an IPv4 model. in Nemo, MR deals directly with the HA. it does no registration with FA/AR. > - Cache poisoning > The cache data for routing table in MR can be corrupted to > subvert routing path. The data packet could be redirected or > looped causing network instability. which "Cache"? > 4.2 Misbehavior of HA > - sniffing of tunneled packet > The IPsec transport mode should be used for securing the > tunneled packets between MR and HA. With the compromise of > the HA, the attacker can sniff the decrypted data packet > in HA. > > - corruption of binding cache > HA keeps managing the BU information on binding cache. > With the corruption of binding information, the attacker > can redirects packets to where he want to deliver them. remove 4.2. I dont expect the HA to misbehave. there isnt much the Nemo protocol basic/extended can do if the HA misbehaves. > > 4.4 Denial of Service > Denial of Service attack is possible against MR and HA by flooding > BU messages and bogus tunneled packets. The attack can be more > effective with distributed fake MRs or HAs. Binding Updates are rate-limited. this maybe not be possible. > 5.1 Corruption of Binding Cache by inside attacker the entire section 5.1 needs to be re-written without assuming NAT or NAT-PT on the mobile router. > 5.3 Attack to Location Privacy by Traffic Analysis > > In the basic NEMO configurations, all the traffic from mobile > network are supposed to go through the bi-directional tunnel > between MR and HA. The HA can collect all the packets in > IP-in-IP tunne, decapsulates them, and forwards them to the CNs. > > > |-----| |----| IP-in-IP tunnel |----| |----| > | MNN |---------| MR | ================== | HA |---------| CN | > |-----| 1 |----| 2 |----| 3 |----| > > > The outside attacker can monitor the traffic in path 2 and 3. how is the attacker on both path 2 and 3? > 6. Security Requirements for NEMO > > The basic support protocol for NEMO is based on the MIPv6 > operations except the bi-directional tunnel operations between > MR and HA. Therefore, most of the security requirements are > already addressed in MIPv6 WG documents[4], so this draft describes > the security requirements only against new threats in NEMO. > The following security requirements SHOULD be addressed in NEMO > basic and extended documents. > > 6.1 MR SHOULD check the contents of the packet from MNN inside , > and assure that the packet does not include fake information > in the critical messages such as BU, prefix discovery, or > ICMP messages. this is a really bad idea. the only thing the MR should be doing is ingress filtering and access control check. it *should* not look into the packet contents. and what if the MNN is using end-to-end ESP encryption? the MR cant see the packet even if it wants to. > 6.2 The IP-in-IP encapsulated packet SHOULD be authenticated > between MR and HA, and per-packet authentication at MR > SHOULD be enforced. authenticated? why? the HA already makes sure that the CoA (on the outer header) is authorized to tunnel packets for MNN's address (in the inner header). you dont need per-packet authentication. > 6.3 The amount of traffic from MNN through the IP-in-IP tunnel > SHOULD be secured to protect the location privacy against > traffic analysis. The amount of traffic through IP-in-IP > tunnel MAY be secured using expanded field as in IPsec > ESP[10]. when did location privacy become a strong requirement? if the MNN is concerned about this, it should be using RFC 3041 addresses. From nemo-admin@ietf.org Sun Nov 9 11:03:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02489 for ; Sun, 9 Nov 2003 11:03: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 1AIs1l-0000Ky-4o; Sun, 09 Nov 2003 11: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 1AIrxv-0000BP-1K for nemo@optimus.ietf.org; Sun, 09 Nov 2003 10:59: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 KAA02373; Sun, 9 Nov 2003 10:58:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIrxs-0002wt-00; Sun, 09 Nov 2003 10:59:00 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AIrxr-0002wk-00; Sun, 09 Nov 2003 10:58:59 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hA9Fwt4W022593; Sun, 9 Nov 2003 08:58:56 -0700 (MST) Received: from nal.motlabs.com ([163.14.20.38]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id hA9FvKLv014415; Sun, 9 Nov 2003 09:57:24 -0600 Message-ID: <12D4C285.5000505@nal.motlabs.com> Date: Sat, 05 Jan 1980 16:15:17 +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: mip6@ietf.org CC: 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] HAHA slot at both MIP6 and 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 Hello to MIP6 and NEMO WG members and Chairs. The current agendas of both MIP6 and NEMO WG's feature the draft on the HA-HA protocol: mip6: > MONDAY, November 10, 2003 1530-1730 Afternoon Sessions II [...] > 4. Inter Home Agents Protocol (HAHA) 10 Mins Ryuji Wakikawa I-D: > draft-wakikawa-mip6-nemo-haha-00.txt > > Home agent reliability is a part of the MIP6 charter. This I-D > explores a possible solution. The intent is to seek WG support for > this item. nemo: > Wednesday, November 12 at 1530-1730 o Home Agent protocol > .......................................10 mins Ryuji Wakikawa > http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-haha-00.txt The presentations take place on different days. I really find this to be redundant. The presentation slides are supposedly exactly the same, since it is a unique draft. The fact that the draft has "mip6" and "nemo" in its name can not mean that it should be dealt with by both WG's. Very much discussions about this has happened on the mip6 mailing list, and only a little on the nemo list. So maybe it should be presented at the mip6 meeting exclusively. So I suggest this draft be presented exclusively at the mip6 meeting. (It is interesting to notice also, how certain submitted drafts were refused presentation slots, while others were allocated twice.) Alex GBU From exim@www1.ietf.org Sun Nov 9 11:03:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02504 for ; Sun, 9 Nov 2003 11:03: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 1AIs1u-0000Lt-15 for nemo-archive@odin.ietf.org; Sun, 09 Nov 2003 11:03:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9G3AWr001349 for nemo-archive@odin.ietf.org; Sun, 9 Nov 2003 11: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 1AIs1t-0000Lg-SI for nemo-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 11:03: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 LAA02483 for ; Sun, 9 Nov 2003 11:02:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIs1r-00033K-00 for nemo-web-archive@ietf.org; Sun, 09 Nov 2003 11:03:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIs1q-00033H-00 for nemo-web-archive@ietf.org; Sun, 09 Nov 2003 11:03:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIs1l-0000Ky-4o; Sun, 09 Nov 2003 11: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 1AIrxv-0000BP-1K for nemo@optimus.ietf.org; Sun, 09 Nov 2003 10:59: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 KAA02373; Sun, 9 Nov 2003 10:58:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIrxs-0002wt-00; Sun, 09 Nov 2003 10:59:00 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AIrxr-0002wk-00; Sun, 09 Nov 2003 10:58:59 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hA9Fwt4W022593; Sun, 9 Nov 2003 08:58:56 -0700 (MST) Received: from nal.motlabs.com ([163.14.20.38]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id hA9FvKLv014415; Sun, 9 Nov 2003 09:57:24 -0600 Message-ID: <12D4C285.5000505@nal.motlabs.com> Date: Sat, 05 Jan 1980 16:15:17 +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: mip6@ietf.org CC: 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] HAHA slot at both MIP6 and 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 Hello to MIP6 and NEMO WG members and Chairs. The current agendas of both MIP6 and NEMO WG's feature the draft on the HA-HA protocol: mip6: > MONDAY, November 10, 2003 1530-1730 Afternoon Sessions II [...] > 4. Inter Home Agents Protocol (HAHA) 10 Mins Ryuji Wakikawa I-D: > draft-wakikawa-mip6-nemo-haha-00.txt > > Home agent reliability is a part of the MIP6 charter. This I-D > explores a possible solution. The intent is to seek WG support for > this item. nemo: > Wednesday, November 12 at 1530-1730 o Home Agent protocol > .......................................10 mins Ryuji Wakikawa > http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-haha-00.txt The presentations take place on different days. I really find this to be redundant. The presentation slides are supposedly exactly the same, since it is a unique draft. The fact that the draft has "mip6" and "nemo" in its name can not mean that it should be dealt with by both WG's. Very much discussions about this has happened on the mip6 mailing list, and only a little on the nemo list. So maybe it should be presented at the mip6 meeting exclusively. So I suggest this draft be presented exclusively at the mip6 meeting. (It is interesting to notice also, how certain submitted drafts were refused presentation slots, while others were allocated twice.) Alex GBU From nemo-admin@ietf.org Sun Nov 9 11:41:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03354 for ; Sun, 9 Nov 2003 11:41: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 1AIscW-0001k2-Bo; Sun, 09 Nov 2003 11:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIscT-0001jo-Lp for nemo@optimus.ietf.org; Sun, 09 Nov 2003 11:40: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 LAA03324 for ; Sun, 9 Nov 2003 11:40:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIscS-0003YH-00 for nemo@ietf.org; Sun, 09 Nov 2003 11:40:56 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AIscR-0003Y9-00 for nemo@ietf.org; Sun, 09 Nov 2003 11:40:55 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hA9Gd27q008378; Sun, 9 Nov 2003 09:39:02 -0700 (MST) Received: from motorola.com ([163.14.20.38]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id hA9GcFLv002142; Sun, 9 Nov 2003 10:38:19 -0600 Message-ID: <12D4CC22.3000809@motorola.com> Date: Sat, 05 Jan 1980 16:56:18 +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: souhwanj@ssu.ac.kr, nemo@ietf.org Subject: Re: [nemo] commens on draft-jung-nemo-threat-analysis-01.txt References: <3FADC478.6080200@iprg.nokia.com> In-Reply-To: <3FADC478.6080200@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > hi, > > I just read through the threat analysis document and sorry to say I > was disappointed with the document. > > many of the threats are not Nemo specific. Exactly, that is my reading too. And since the agenda item describing this presentation invites to think how to proceed with this WG item, I'd suggest to start with the Security Considerations of draft-ietf-nemo-basic-support-01.txt and with section 5 of draft-petrescu-nemo-mrha-03.txt. Starting point should be acknowledging that the only NEMO-specific security risks are related to interactions between MR and HA. Then the IPsec tool protecting this should be described in more detail, more specifically that it protects against eavesdropping between the two, and masquerading of an attacker between the two. Then describe what that IPsec tool does _not_ protect against. Then describe in detail the checks suggested by the basic support, like the ingress filtering of draft-ietf-nemo-basic. Then describe the threats appearing when MR and HA belong to different admin domains. Then describe the problem of the built-in authentication of dynamic routing protocols not covering the relations between prefix being advertised and having the right to advertise that prefix; the prefix table of basic support might help with this; an alternative way of dealing with this being draft-ietf-ospf-ospfv3-auth-01.txt, in case of OSPF. So, that's my suggestion of how to proceed with this WG item. [...] > this is a really bad idea. the only thing the MR should be doing is > ingress filtering and access control check. it *should* not look into > the packet contents. and what if the MNN is using end-to-end ESP > encryption? the MR cant see the packet even if it wants to. I agree with the all the points you had down to the ellipsis. The "ingress filtering" aspect you say seems also reasonable. But, HA looking _inside_ the packet contents (beyond the headers explicitely addressed to itself, and _if_ ESP is not present) might help with solving the "cross-over" tunnels problem (see section B.6 of draft-petrescu-nemo-mrha-03.txt for a description of this problem). >> 6.3 The amount of traffic from MNN through the IP-in-IP tunnel >> SHOULD be secured to protect the location privacy against traffic >> analysis. The amount of traffic through IP-in-IP tunnel MAY be >> secured using expanded field as in IPsec ESP[10]. > > > when did location privacy become a strong requirement? if the MNN is > concerned about this, it should be using RFC 3041 addresses. Yes I agree with this too. Alex GBU From exim@www1.ietf.org Sun Nov 9 11:42:02 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03376 for ; Sun, 9 Nov 2003 11:42:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIscf-0001lC-AQ for nemo-archive@odin.ietf.org; Sun, 09 Nov 2003 11:41:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9Gf9Sv006760 for nemo-archive@odin.ietf.org; Sun, 9 Nov 2003 11:41:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIscf-0001kx-4M for nemo-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 11:41: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 LAA03328 for ; Sun, 9 Nov 2003 11:40:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIsce-0003YN-00 for nemo-web-archive@ietf.org; Sun, 09 Nov 2003 11:41:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIscd-0003YK-00 for nemo-web-archive@ietf.org; Sun, 09 Nov 2003 11:41:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIscW-0001k2-Bo; Sun, 09 Nov 2003 11:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIscT-0001jo-Lp for nemo@optimus.ietf.org; Sun, 09 Nov 2003 11:40: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 LAA03324 for ; Sun, 9 Nov 2003 11:40:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIscS-0003YH-00 for nemo@ietf.org; Sun, 09 Nov 2003 11:40:56 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AIscR-0003Y9-00 for nemo@ietf.org; Sun, 09 Nov 2003 11:40:55 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hA9Gd27q008378; Sun, 9 Nov 2003 09:39:02 -0700 (MST) Received: from motorola.com ([163.14.20.38]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id hA9GcFLv002142; Sun, 9 Nov 2003 10:38:19 -0600 Message-ID: <12D4CC22.3000809@motorola.com> Date: Sat, 05 Jan 1980 16:56:18 +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: souhwanj@ssu.ac.kr, nemo@ietf.org Subject: Re: [nemo] commens on draft-jung-nemo-threat-analysis-01.txt References: <3FADC478.6080200@iprg.nokia.com> In-Reply-To: <3FADC478.6080200@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > hi, > > I just read through the threat analysis document and sorry to say I > was disappointed with the document. > > many of the threats are not Nemo specific. Exactly, that is my reading too. And since the agenda item describing this presentation invites to think how to proceed with this WG item, I'd suggest to start with the Security Considerations of draft-ietf-nemo-basic-support-01.txt and with section 5 of draft-petrescu-nemo-mrha-03.txt. Starting point should be acknowledging that the only NEMO-specific security risks are related to interactions between MR and HA. Then the IPsec tool protecting this should be described in more detail, more specifically that it protects against eavesdropping between the two, and masquerading of an attacker between the two. Then describe what that IPsec tool does _not_ protect against. Then describe in detail the checks suggested by the basic support, like the ingress filtering of draft-ietf-nemo-basic. Then describe the threats appearing when MR and HA belong to different admin domains. Then describe the problem of the built-in authentication of dynamic routing protocols not covering the relations between prefix being advertised and having the right to advertise that prefix; the prefix table of basic support might help with this; an alternative way of dealing with this being draft-ietf-ospf-ospfv3-auth-01.txt, in case of OSPF. So, that's my suggestion of how to proceed with this WG item. [...] > this is a really bad idea. the only thing the MR should be doing is > ingress filtering and access control check. it *should* not look into > the packet contents. and what if the MNN is using end-to-end ESP > encryption? the MR cant see the packet even if it wants to. I agree with the all the points you had down to the ellipsis. The "ingress filtering" aspect you say seems also reasonable. But, HA looking _inside_ the packet contents (beyond the headers explicitely addressed to itself, and _if_ ESP is not present) might help with solving the "cross-over" tunnels problem (see section B.6 of draft-petrescu-nemo-mrha-03.txt for a description of this problem). >> 6.3 The amount of traffic from MNN through the IP-in-IP tunnel >> SHOULD be secured to protect the location privacy against traffic >> analysis. The amount of traffic through IP-in-IP tunnel MAY be >> secured using expanded field as in IPsec ESP[10]. > > > when did location privacy become a strong requirement? if the MNN is > concerned about this, it should be using RFC 3041 addresses. Yes I agree with this too. Alex GBU From nemo-admin@ietf.org Sun Nov 9 13:38:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05847 for ; Sun, 9 Nov 2003 13: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 1AIuRl-00069z-FL; Sun, 09 Nov 2003 13: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 1AIuQr-0005sm-5K for nemo@optimus.ietf.org; Sun, 09 Nov 2003 13:37: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 NAA05802; Sun, 9 Nov 2003 13:36:50 -0500 (EST) From: Vijay.Devarapalli@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIuQn-00059v-00; Sun, 09 Nov 2003 13:37:01 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AIuQm-00059r-00; Sun, 09 Nov 2003 13:37:01 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA9IaxA05953; Sun, 9 Nov 2003 20:36:59 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 9 Nov 2003 20:36:59 +0200 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 9 Nov 2003 12:36:36 -0600 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: Sun, 9 Nov 2003 10:36:35 -0800 Message-ID: Thread-Topic: [Mip6] HAHA slot at both MIP6 and NEMO? Thread-Index: AcOm2wJpl8p/a33gS0qrtpryl3Lh4gAFTG3w To: , Cc: X-OriginalArrivalTime: 09 Nov 2003 18:36:36.0573 (UTC) FILETIME=[681F00D0:01C3A6F0] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: [Mip6] HAHA slot at both MIP6 and 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 Alex, the draft is relevant to both WGs. that why it is being presented in both WGs meetings. the presentations are not going to be the same. in MIP6 WG, there will be more stuff on the problem statement.=20 Vijay > -----Original Message----- > From: mip6-admin@ietf.org [mailto:mip6-admin@ietf.org]On Behalf Of ext > Alexandru Petrescu > Sent: Saturday, January 05, 1980 7:15 AM > To: mip6@ietf.org > Cc: nemo@ietf.org > Subject: [Mip6] HAHA slot at both MIP6 and NEMO? >=20 >=20 > Hello to MIP6 and NEMO WG members and Chairs. >=20 > The current agendas of both MIP6 and NEMO WG's feature the=20 > draft on the=20 > HA-HA protocol: >=20 > mip6: > > MONDAY, November 10, 2003 1530-1730 Afternoon Sessions II > [...] > > 4. Inter Home Agents Protocol (HAHA) 10 Mins Ryuji=20 > Wakikawa I-D:=20 > > draft-wakikawa-mip6-nemo-haha-00.txt > >=20 > > Home agent reliability is a part of the MIP6 charter. This I-D=20 > > explores a possible solution. The intent is to seek WG support for=20 > > this item. >=20 > nemo: > > Wednesday, November 12 at 1530-1730 o Home Agent protocol=20 > > .......................................10 mins Ryuji Wakikawa=20 > >=20 > http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-h aha-00.txt The presentations take place on different days. I really find this to be redundant. The presentation slides are supposedly exactly the same, since it is a unique draft. The fact that the draft has "mip6" and "nemo" in its name can not mean that it should be dealt with by both = WG's. Very much discussions about this has happened on the mip6 mailing list, and only a little on the nemo list. So maybe it should be presented at the mip6 meeting exclusively. So I suggest this draft be presented=20 exclusively at the mip6 meeting. (It is interesting to notice also, how certain submitted drafts were refused presentation slots, while others were allocated twice.) Alex GBU _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Nov 9 13:38:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05875 for ; Sun, 9 Nov 2003 13: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 1AIuRs-0006Cj-4O for nemo-archive@odin.ietf.org; Sun, 09 Nov 2003 13:38:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9Ic7R7023835 for nemo-archive@odin.ietf.org; Sun, 9 Nov 2003 13: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 1AIuRr-0006CM-L0 for nemo-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 13:38: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 NAA05825 for ; Sun, 9 Nov 2003 13:37:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIuRp-0005B7-00 for nemo-web-archive@ietf.org; Sun, 09 Nov 2003 13:38:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIuRp-0005B4-00 for nemo-web-archive@ietf.org; Sun, 09 Nov 2003 13:38:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIuRl-00069z-FL; Sun, 09 Nov 2003 13: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 1AIuQr-0005sm-5K for nemo@optimus.ietf.org; Sun, 09 Nov 2003 13:37: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 NAA05802; Sun, 9 Nov 2003 13:36:50 -0500 (EST) From: Vijay.Devarapalli@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIuQn-00059v-00; Sun, 09 Nov 2003 13:37:01 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AIuQm-00059r-00; Sun, 09 Nov 2003 13:37:01 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA9IaxA05953; Sun, 9 Nov 2003 20:36:59 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 9 Nov 2003 20:36:59 +0200 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 9 Nov 2003 12:36:36 -0600 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: Sun, 9 Nov 2003 10:36:35 -0800 Message-ID: Thread-Topic: [Mip6] HAHA slot at both MIP6 and NEMO? Thread-Index: AcOm2wJpl8p/a33gS0qrtpryl3Lh4gAFTG3w To: , Cc: X-OriginalArrivalTime: 09 Nov 2003 18:36:36.0573 (UTC) FILETIME=[681F00D0:01C3A6F0] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: [Mip6] HAHA slot at both MIP6 and 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 Alex, the draft is relevant to both WGs. that why it is being presented in both WGs meetings. the presentations are not going to be the same. in MIP6 WG, there will be more stuff on the problem statement.=20 Vijay > -----Original Message----- > From: mip6-admin@ietf.org [mailto:mip6-admin@ietf.org]On Behalf Of ext > Alexandru Petrescu > Sent: Saturday, January 05, 1980 7:15 AM > To: mip6@ietf.org > Cc: nemo@ietf.org > Subject: [Mip6] HAHA slot at both MIP6 and NEMO? >=20 >=20 > Hello to MIP6 and NEMO WG members and Chairs. >=20 > The current agendas of both MIP6 and NEMO WG's feature the=20 > draft on the=20 > HA-HA protocol: >=20 > mip6: > > MONDAY, November 10, 2003 1530-1730 Afternoon Sessions II > [...] > > 4. Inter Home Agents Protocol (HAHA) 10 Mins Ryuji=20 > Wakikawa I-D:=20 > > draft-wakikawa-mip6-nemo-haha-00.txt > >=20 > > Home agent reliability is a part of the MIP6 charter. This I-D=20 > > explores a possible solution. The intent is to seek WG support for=20 > > this item. >=20 > nemo: > > Wednesday, November 12 at 1530-1730 o Home Agent protocol=20 > > .......................................10 mins Ryuji Wakikawa=20 > >=20 > http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-h aha-00.txt The presentations take place on different days. I really find this to be redundant. The presentation slides are supposedly exactly the same, since it is a unique draft. The fact that the draft has "mip6" and "nemo" in its name can not mean that it should be dealt with by both = WG's. Very much discussions about this has happened on the mip6 mailing list, and only a little on the nemo list. So maybe it should be presented at the mip6 meeting exclusively. So I suggest this draft be presented=20 exclusively at the mip6 meeting. (It is interesting to notice also, how certain submitted drafts were refused presentation slots, while others were allocated twice.) Alex GBU _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From nemo-admin@ietf.org Sun Nov 9 15:10:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08551 for ; Sun, 9 Nov 2003 15:10: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 1AIvso-0002PE-CZ; Sun, 09 Nov 2003 15:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIvsi-0002Od-5j for nemo@optimus.ietf.org; Sun, 09 Nov 2003 15:09:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08459; Sun, 9 Nov 2003 15:09:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIvsS-0006Ny-00; Sun, 09 Nov 2003 15:09:40 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AIvsR-0006Nv-00; Sun, 09 Nov 2003 15:09:39 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hA9K8e7q013369; Sun, 9 Nov 2003 13:08:40 -0700 (MST) Received: from motorola.com ([163.14.20.64]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hA9K9Jui026495; Sun, 9 Nov 2003 14:09:24 -0600 Message-ID: <12D4FD44.3000708@motorola.com> Date: Sat, 05 Jan 1980 20:25:56 +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@nokia.com CC: mip6@ietf.org, 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: [Mip6] HAHA slot at both MIP6 and 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 Vijay.Devarapalli@nokia.com wrote: > the draft is relevant to both WGs. that why it is being presented in > both WGs meetings. I can't grasp the reasons of why this draft is relevant to both WG's. It is as much relevant to both WG's as every MIP6 draft is relevant to NEMO and as every NEMO draft is relevant to MIP6. Maybe thought and discussion should have been given to splitting the draft in two. Do a first simple HAHA problem with a simple mobile host solution and only then do it for NEMO. But coming up with all the stuff in one doc and forcing it down the throats of both WG's without any prior public discussion is really, errr, how to say, a bit annoying, right? > the presentations are not going to be the same. in MIP6 WG, there > will be more stuff on the problem statement. And in NEMO, what will there be? To which particular NEMO Charter issue, or to which "goal" in the goals document, does this particular draft pertain? I find none. To which public discussion in NEMO WG (prior to announcement) does the HAHA draft offer a solution? I remember of none. Alex GBU From exim@www1.ietf.org Sun Nov 9 15:10:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08569 for ; Sun, 9 Nov 2003 15:10: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 1AIvsu-0002QQ-8G for nemo-archive@odin.ietf.org; Sun, 09 Nov 2003 15:10:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9KA8St009316 for nemo-archive@odin.ietf.org; Sun, 9 Nov 2003 15:10:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIvst-0002QB-W8 for nemo-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 15:10: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 PAA08502 for ; Sun, 9 Nov 2003 15:09:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIvsq-0006OC-00 for nemo-web-archive@ietf.org; Sun, 09 Nov 2003 15:10:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIvsq-0006O9-00 for nemo-web-archive@ietf.org; Sun, 09 Nov 2003 15:10:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIvso-0002PE-CZ; Sun, 09 Nov 2003 15:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIvsi-0002Od-5j for nemo@optimus.ietf.org; Sun, 09 Nov 2003 15:09:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08459; Sun, 9 Nov 2003 15:09:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIvsS-0006Ny-00; Sun, 09 Nov 2003 15:09:40 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AIvsR-0006Nv-00; Sun, 09 Nov 2003 15:09:39 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hA9K8e7q013369; Sun, 9 Nov 2003 13:08:40 -0700 (MST) Received: from motorola.com ([163.14.20.64]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hA9K9Jui026495; Sun, 9 Nov 2003 14:09:24 -0600 Message-ID: <12D4FD44.3000708@motorola.com> Date: Sat, 05 Jan 1980 20:25:56 +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@nokia.com CC: mip6@ietf.org, 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: [Mip6] HAHA slot at both MIP6 and 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 Vijay.Devarapalli@nokia.com wrote: > the draft is relevant to both WGs. that why it is being presented in > both WGs meetings. I can't grasp the reasons of why this draft is relevant to both WG's. It is as much relevant to both WG's as every MIP6 draft is relevant to NEMO and as every NEMO draft is relevant to MIP6. Maybe thought and discussion should have been given to splitting the draft in two. Do a first simple HAHA problem with a simple mobile host solution and only then do it for NEMO. But coming up with all the stuff in one doc and forcing it down the throats of both WG's without any prior public discussion is really, errr, how to say, a bit annoying, right? > the presentations are not going to be the same. in MIP6 WG, there > will be more stuff on the problem statement. And in NEMO, what will there be? To which particular NEMO Charter issue, or to which "goal" in the goals document, does this particular draft pertain? I find none. To which public discussion in NEMO WG (prior to announcement) does the HAHA draft offer a solution? I remember of none. Alex GBU From nemo-admin@ietf.org Sun Nov 9 16:16:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10560 for ; Sun, 9 Nov 2003 16:16: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 1AIwug-0005Mf-0u; Sun, 09 Nov 2003 16:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIwud-0005MH-QL for nemo@optimus.ietf.org; Sun, 09 Nov 2003 16:15: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 QAA10539 for ; Sun, 9 Nov 2003 16:15:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIwub-0007DY-00 for nemo@ietf.org; Sun, 09 Nov 2003 16:15:57 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AIwub-0007DV-00 for nemo@ietf.org; Sun, 09 Nov 2003 16:15:57 -0500 Received: from kniveton.com (dyn136-249.ietf58.ietf.org [130.129.136.249]) by multihop.net (8.12.10/8.12.9) with ESMTP id hA9LFxqT024152 for ; Sun, 9 Nov 2003 13:15:59 -0800 (PST) (envelope-from tj@kniveton.com) Message-ID: <3FAECA8A.7090009@kniveton.com> Date: Sun, 09 Nov 2003 15:15:22 -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] RE: ro draft References: <20031105150133.5acdc289.ernst@sfc.wide.ad.jp> In-Reply-To: <20031105150133.5acdc289.ernst@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 Thierry Ernst wrote: >Hi, > > > >>I believe this draft is important, and it reflects base thoughts that >>should be built upon. A solution like this improves the nemo basic >>support dramatically. We really need to open the RO discussion(s) ASAP. >>Chairs: do we need to recharter? >> >> > >I will give my own point of view. > >First thing first, we have important milestones where no contribution >has been performed so far (MIB) or almost not (threat analysis). I would >like to see these been taken of first, prior to opening the RO debate. > It's fine to talk about RO.. but it MUST not distract from getting the working group work done. Thierry points out that the milestones of the group that we have committed to, are not getting addressed. If this continues, we will have to cut off RO conversation at all on the ML. If there is no basic solution and its corresponding support drafts, MIBs, etc., there will be nothing to Optimize. This is probably obvious to everyone already.. > >Second, the charter says: > >The WG will work on: >- An informational document which specifies a detailed problem >statement for route optimization and looks at various approaches to >solving this problem. This document will look into the issues and >tradeoffs involved in making the network's movement visible to some >nodes, by optionally making them "NEMO aware". The interaction between >route optimization and IP routing will also be described in this >document. Furthermore, security considerations for the various >approaches will also be considered. > >Milestones: >Jun 04 Shut down or recharter the WG to solve the route optimization. > > >Which means we need to work on the problem statement first (including >analysis of the solution space), not on the solutions. So far, I only >saw solutions. > There is an analysis of the solution space as pointed out.. But not a very good understanding of the requirements.. > >I wish people would commit to the tasks of the WG. I personnaly don't >mind other issues being investigated as long as the agreed objectives >are being taken care of. > I agree 100%... of course we are a bit biased toward getting the work done. Hopefully others are too!! :) TJ From exim@www1.ietf.org Sun Nov 9 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 QAA10574 for ; Sun, 9 Nov 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 1AIwul-0005Nk-Cf for nemo-archive@odin.ietf.org; Sun, 09 Nov 2003 16:16:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9LG7jg020682 for nemo-archive@odin.ietf.org; Sun, 9 Nov 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 1AIwul-0005NV-8o for nemo-web-archive@optimus.ietf.org; Sun, 09 Nov 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 QAA10546 for ; Sun, 9 Nov 2003 16:15:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIwuj-0007Dk-00 for nemo-web-archive@ietf.org; Sun, 09 Nov 2003 16:16:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIwuj-0007Dh-00 for nemo-web-archive@ietf.org; Sun, 09 Nov 2003 16:16:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIwug-0005Mf-0u; Sun, 09 Nov 2003 16:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIwud-0005MH-QL for nemo@optimus.ietf.org; Sun, 09 Nov 2003 16:15: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 QAA10539 for ; Sun, 9 Nov 2003 16:15:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIwub-0007DY-00 for nemo@ietf.org; Sun, 09 Nov 2003 16:15:57 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AIwub-0007DV-00 for nemo@ietf.org; Sun, 09 Nov 2003 16:15:57 -0500 Received: from kniveton.com (dyn136-249.ietf58.ietf.org [130.129.136.249]) by multihop.net (8.12.10/8.12.9) with ESMTP id hA9LFxqT024152 for ; Sun, 9 Nov 2003 13:15:59 -0800 (PST) (envelope-from tj@kniveton.com) Message-ID: <3FAECA8A.7090009@kniveton.com> Date: Sun, 09 Nov 2003 15:15:22 -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] RE: ro draft References: <20031105150133.5acdc289.ernst@sfc.wide.ad.jp> In-Reply-To: <20031105150133.5acdc289.ernst@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 Thierry Ernst wrote: >Hi, > > > >>I believe this draft is important, and it reflects base thoughts that >>should be built upon. A solution like this improves the nemo basic >>support dramatically. We really need to open the RO discussion(s) ASAP. >>Chairs: do we need to recharter? >> >> > >I will give my own point of view. > >First thing first, we have important milestones where no contribution >has been performed so far (MIB) or almost not (threat analysis). I would >like to see these been taken of first, prior to opening the RO debate. > It's fine to talk about RO.. but it MUST not distract from getting the working group work done. Thierry points out that the milestones of the group that we have committed to, are not getting addressed. If this continues, we will have to cut off RO conversation at all on the ML. If there is no basic solution and its corresponding support drafts, MIBs, etc., there will be nothing to Optimize. This is probably obvious to everyone already.. > >Second, the charter says: > >The WG will work on: >- An informational document which specifies a detailed problem >statement for route optimization and looks at various approaches to >solving this problem. This document will look into the issues and >tradeoffs involved in making the network's movement visible to some >nodes, by optionally making them "NEMO aware". The interaction between >route optimization and IP routing will also be described in this >document. Furthermore, security considerations for the various >approaches will also be considered. > >Milestones: >Jun 04 Shut down or recharter the WG to solve the route optimization. > > >Which means we need to work on the problem statement first (including >analysis of the solution space), not on the solutions. So far, I only >saw solutions. > There is an analysis of the solution space as pointed out.. But not a very good understanding of the requirements.. > >I wish people would commit to the tasks of the WG. I personnaly don't >mind other issues being investigated as long as the agreed objectives >are being taken care of. > I agree 100%... of course we are a bit biased toward getting the work done. Hopefully others are too!! :) TJ From nemo-admin@ietf.org Sun Nov 9 16:21:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10708 for ; Sun, 9 Nov 2003 16:21: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 1AIwzV-0005Zk-If; Sun, 09 Nov 2003 16: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 1AIwyj-0005Yz-As for nemo@optimus.ietf.org; Sun, 09 Nov 2003 16:20: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 QAA10683; Sun, 9 Nov 2003 16:19:59 -0500 (EST) From: Vijay.Devarapalli@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIwyh-0007GK-00; Sun, 09 Nov 2003 16:20:11 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AIwyg-0007GH-00; Sun, 09 Nov 2003 16:20:10 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA9LKAA06817; Sun, 9 Nov 2003 23:20:10 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 9 Nov 2003 23:20:10 +0200 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 9 Nov 2003 13:20:07 -0800 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: Sun, 9 Nov 2003 13:20:07 -0800 Message-ID: Thread-Topic: [Mip6] HAHA slot at both MIP6 and NEMO? Thread-Index: AcOm/Wr0COuF1aJOSLCV98O7Fnux2gACW2Fg To: Cc: , X-OriginalArrivalTime: 09 Nov 2003 21:20:08.0149 (UTC) FILETIME=[4046B050:01C3A707] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: [Mip6] HAHA slot at both MIP6 and 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 > Maybe thought and discussion should have been given to splitting the > draft in two. Do a first simple HAHA problem with a simple=20 > mobile host > solution and only then do it for NEMO. But coming up with=20 > all the stuff > in one doc and forcing it down the throats of both WG's without any > prior public discussion is really, errr, how to say, a bit annoying, > right? huh?? it is an individual submission. the authors are free to put what they want in the spec.=20 a WG draft is different. the WG decides what goes into it. Vijay From exim@www1.ietf.org Sun Nov 9 16:21:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10726 for ; Sun, 9 Nov 2003 16:21: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 1AIwzW-0005cI-Sd for nemo-archive@odin.ietf.org; Sun, 09 Nov 2003 16:21:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9LL2N7021583 for nemo-archive@odin.ietf.org; Sun, 9 Nov 2003 16:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIwzW-0005c2-Lh for nemo-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 16:21: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 QAA10687 for ; Sun, 9 Nov 2003 16:20:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIwzU-0007GR-00 for nemo-web-archive@ietf.org; Sun, 09 Nov 2003 16:21:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIwzU-0007GO-00 for nemo-web-archive@ietf.org; Sun, 09 Nov 2003 16: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 1AIwzV-0005Zk-If; Sun, 09 Nov 2003 16: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 1AIwyj-0005Yz-As for nemo@optimus.ietf.org; Sun, 09 Nov 2003 16:20: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 QAA10683; Sun, 9 Nov 2003 16:19:59 -0500 (EST) From: Vijay.Devarapalli@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIwyh-0007GK-00; Sun, 09 Nov 2003 16:20:11 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AIwyg-0007GH-00; Sun, 09 Nov 2003 16:20:10 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA9LKAA06817; Sun, 9 Nov 2003 23:20:10 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 9 Nov 2003 23:20:10 +0200 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 9 Nov 2003 13:20:07 -0800 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: Sun, 9 Nov 2003 13:20:07 -0800 Message-ID: Thread-Topic: [Mip6] HAHA slot at both MIP6 and NEMO? Thread-Index: AcOm/Wr0COuF1aJOSLCV98O7Fnux2gACW2Fg To: Cc: , X-OriginalArrivalTime: 09 Nov 2003 21:20:08.0149 (UTC) FILETIME=[4046B050:01C3A707] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: [Mip6] HAHA slot at both MIP6 and 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 > Maybe thought and discussion should have been given to splitting the > draft in two. Do a first simple HAHA problem with a simple=20 > mobile host > solution and only then do it for NEMO. But coming up with=20 > all the stuff > in one doc and forcing it down the throats of both WG's without any > prior public discussion is really, errr, how to say, a bit annoying, > right? huh?? it is an individual submission. the authors are free to put what they want in the spec.=20 a WG draft is different. the WG decides what goes into it. Vijay From nemo-admin@ietf.org Sun Nov 9 16:43:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11524 for ; Sun, 9 Nov 2003 16:43:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxKn-0007bW-5b; Sun, 09 Nov 2003 16: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 1AIxK6-0007bB-Ch for nemo@optimus.ietf.org; Sun, 09 Nov 2003 16:42: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 QAA11508; Sun, 9 Nov 2003 16:42:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIxK4-0007bf-00; Sun, 09 Nov 2003 16:42:16 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AIxK3-0007bc-00; Sun, 09 Nov 2003 16:42:15 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA9Lfg721650; Sun, 9 Nov 2003 13:41:42 -0800 X-mProtect: <200311092141> Nokia Silicon Valley Messaging Protection Received: from danira-pool054120.americas.nokia.com (10.241.54.120, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdRsZDQ9; Sun, 09 Nov 2003 13:41:40 PST Message-ID: <3FAEB489.7060305@iprg.nokia.com> Date: Sun, 09 Nov 2003 13:41:29 -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: mip6@ietf.org, Basavaraj Patil , nemo@ietf.org References: <3FAE8CDC.10804@kolumbus.fi> In-Reply-To: <3FAE8CDC.10804@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: [Mip6] MIPv6 and IANA actions -- Status codes Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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 agree IANA action is required. the Nemo basic protocol draft-ietf-nemo-basic-support-01.txt defines new binding ack status values. this was discussed in the Nemo WG and we werent sure what to do because Mobile IPv6 spec did not require IANA action. the text you propose looks fine. Vijay Jari Arkko wrote: > > Hi, > > We are currently setting up the IANA registry for Mobile > IPv6 reserved numbers with IANA. While doing this, we > noticed that the current IANA Considerations section > does not say anything about Status codes. Our thinking > is that these values too need to be registered at IANA > in the same manner as MH type codes and options. > > If you think this is acceptable, I'd like to insert > the following text to the draft (perhaps in AUTH48): > > Finally, this document creates a third new name space "Status > Code" for the Status field in the Binding Acknowledgement > message. The current values are described in Section 6.1.8, and > are the following: > > 0 Binding Update accepted > > 1 Accepted but prefix discovery necessary > > 128 Reason unspecified > > 129 Administratively prohibited > > 130 Insufficient resources > > 131 Home registration not supported > > 132 Not home subnet > > 133 Not home agent for this mobile node > > 134 Duplicate Address Detection failed > > 135 Sequence number out of window > > 136 Expired home nonce index > > 137 Expired care-of nonce index > > 138 Expired nonces > > 139 Registration type change disallowed > > Future values of the Status field can be allocated using standards > action [10]. > > --Jari > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Nov 9 16:43:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11545 for ; Sun, 9 Nov 2003 16: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 1AIxKp-0007e3-88 for nemo-archive@odin.ietf.org; Sun, 09 Nov 2003 16:43:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9Lh3gv029381 for nemo-archive@odin.ietf.org; Sun, 9 Nov 2003 16:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxKp-0007do-2b for nemo-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 16:43: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 QAA11515 for ; Sun, 9 Nov 2003 16:42:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIxKn-0007br-00 for nemo-web-archive@ietf.org; Sun, 09 Nov 2003 16:43:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIxKm-0007bo-00 for nemo-web-archive@ietf.org; Sun, 09 Nov 2003 16:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIxKn-0007bW-5b; Sun, 09 Nov 2003 16: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 1AIxK6-0007bB-Ch for nemo@optimus.ietf.org; Sun, 09 Nov 2003 16:42: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 QAA11508; Sun, 9 Nov 2003 16:42:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIxK4-0007bf-00; Sun, 09 Nov 2003 16:42:16 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AIxK3-0007bc-00; Sun, 09 Nov 2003 16:42:15 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA9Lfg721650; Sun, 9 Nov 2003 13:41:42 -0800 X-mProtect: <200311092141> Nokia Silicon Valley Messaging Protection Received: from danira-pool054120.americas.nokia.com (10.241.54.120, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdRsZDQ9; Sun, 09 Nov 2003 13:41:40 PST Message-ID: <3FAEB489.7060305@iprg.nokia.com> Date: Sun, 09 Nov 2003 13:41:29 -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: mip6@ietf.org, Basavaraj Patil , nemo@ietf.org References: <3FAE8CDC.10804@kolumbus.fi> In-Reply-To: <3FAE8CDC.10804@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: [Mip6] MIPv6 and IANA actions -- Status codes Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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 agree IANA action is required. the Nemo basic protocol draft-ietf-nemo-basic-support-01.txt defines new binding ack status values. this was discussed in the Nemo WG and we werent sure what to do because Mobile IPv6 spec did not require IANA action. the text you propose looks fine. Vijay Jari Arkko wrote: > > Hi, > > We are currently setting up the IANA registry for Mobile > IPv6 reserved numbers with IANA. While doing this, we > noticed that the current IANA Considerations section > does not say anything about Status codes. Our thinking > is that these values too need to be registered at IANA > in the same manner as MH type codes and options. > > If you think this is acceptable, I'd like to insert > the following text to the draft (perhaps in AUTH48): > > Finally, this document creates a third new name space "Status > Code" for the Status field in the Binding Acknowledgement > message. The current values are described in Section 6.1.8, and > are the following: > > 0 Binding Update accepted > > 1 Accepted but prefix discovery necessary > > 128 Reason unspecified > > 129 Administratively prohibited > > 130 Insufficient resources > > 131 Home registration not supported > > 132 Not home subnet > > 133 Not home agent for this mobile node > > 134 Duplicate Address Detection failed > > 135 Sequence number out of window > > 136 Expired home nonce index > > 137 Expired care-of nonce index > > 138 Expired nonces > > 139 Registration type change disallowed > > Future values of the Status field can be allocated using standards > action [10]. > > --Jari > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 From nemo-admin@ietf.org Sun Nov 9 17:45:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15115 for ; Sun, 9 Nov 2003 17:45: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 1AIyIo-0003bY-K7; Sun, 09 Nov 2003 17:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyE0-00038u-8u for nemo@optimus.ietf.org; Sun, 09 Nov 2003 17:40: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 RAA13658; Sun, 9 Nov 2003 17:39:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyDv-0000oF-00; Sun, 09 Nov 2003 17:39:59 -0500 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1AIyDu-0000o7-00; Sun, 09 Nov 2003 17:39:59 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id hA9MdvHc010582; Sun, 9 Nov 2003 15:39:57 -0700 (MST) Received: from nal.motlabs.com ([163.14.20.55]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id hA9MdhBJ024456; Sun, 9 Nov 2003 16:39:48 -0600 Message-ID: <3FAEC22C.7060700@nal.motlabs.com> Date: Sun, 09 Nov 2003 23:39:40 +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@nokia.com CC: mip6@ietf.org, 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: ok (was: HAHA slot at both MIP6 and 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 Vijay.Devarapalli@nokia.com wrote: >> Maybe thought and discussion should have been given to splitting >> the draft in two. Do a first simple HAHA problem with a simple >> mobile host solution and only then do it for NEMO. But coming up >> with all the stuff in one doc and forcing it down the throats of >> both WG's without any prior public discussion is really, errr, how >> to say, a bit annoying, right? > > huh?? it is an individual submission. the authors are free to put > what they want in the spec. Vijay, I suppose you got my point. This is about many other individual submissions being rejected slots (or imposed very tight time constraints) on grounds of non-relation to Charters, while this particularly negatively reviewed individual submission generously got 2 slots. This can be so only because of its apparent appeal of a nice technique promissing many things to many problems, and its apparent novelty. There is text in the draft that relates it to MIP6 for hosts, to NEMO MR's, might look as a solution for HA reliability, might look as help for RO too. Maybe presenting it to MIPSHOP would be a good idea too, they also deal with an HA closer to MN (the MAP). > a WG draft is different. the WG decides what goes into it. Absolutely, and it would have been even better if one of that WG's member oppinion were taken into account when preparing the NEMO agenda (the only oppinion apart an author's oppinion). This reads: the draft HAHA was published, member reacted negatively, author positively, and so the draft popped up in the agenda :-) But, finally, I think this goes above my humble comprehension of facts, so I'll sit, watch and see. So I'm eager to see the slides and the minutes. Alex GBU From exim@www1.ietf.org Sun Nov 9 17:45:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15136 for ; Sun, 9 Nov 2003 17:45: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 1AIyIs-0003ce-Ja for nemo-archive@odin.ietf.org; Sun, 09 Nov 2003 17:45:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9Mj6lJ013918 for nemo-archive@odin.ietf.org; Sun, 9 Nov 2003 17:45:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyIs-0003cP-9N for nemo-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 17:45: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 RAA15023 for ; Sun, 9 Nov 2003 17:44:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyIp-00011a-00 for nemo-web-archive@ietf.org; Sun, 09 Nov 2003 17:45:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIyIp-00011X-00 for nemo-web-archive@ietf.org; Sun, 09 Nov 2003 17:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyIo-0003bY-K7; Sun, 09 Nov 2003 17:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIyE0-00038u-8u for nemo@optimus.ietf.org; Sun, 09 Nov 2003 17:40: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 RAA13658; Sun, 9 Nov 2003 17:39:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyDv-0000oF-00; Sun, 09 Nov 2003 17:39:59 -0500 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1AIyDu-0000o7-00; Sun, 09 Nov 2003 17:39:59 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id hA9MdvHc010582; Sun, 9 Nov 2003 15:39:57 -0700 (MST) Received: from nal.motlabs.com ([163.14.20.55]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id hA9MdhBJ024456; Sun, 9 Nov 2003 16:39:48 -0600 Message-ID: <3FAEC22C.7060700@nal.motlabs.com> Date: Sun, 09 Nov 2003 23:39:40 +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@nokia.com CC: mip6@ietf.org, 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: ok (was: HAHA slot at both MIP6 and 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 Vijay.Devarapalli@nokia.com wrote: >> Maybe thought and discussion should have been given to splitting >> the draft in two. Do a first simple HAHA problem with a simple >> mobile host solution and only then do it for NEMO. But coming up >> with all the stuff in one doc and forcing it down the throats of >> both WG's without any prior public discussion is really, errr, how >> to say, a bit annoying, right? > > huh?? it is an individual submission. the authors are free to put > what they want in the spec. Vijay, I suppose you got my point. This is about many other individual submissions being rejected slots (or imposed very tight time constraints) on grounds of non-relation to Charters, while this particularly negatively reviewed individual submission generously got 2 slots. This can be so only because of its apparent appeal of a nice technique promissing many things to many problems, and its apparent novelty. There is text in the draft that relates it to MIP6 for hosts, to NEMO MR's, might look as a solution for HA reliability, might look as help for RO too. Maybe presenting it to MIPSHOP would be a good idea too, they also deal with an HA closer to MN (the MAP). > a WG draft is different. the WG decides what goes into it. Absolutely, and it would have been even better if one of that WG's member oppinion were taken into account when preparing the NEMO agenda (the only oppinion apart an author's oppinion). This reads: the draft HAHA was published, member reacted negatively, author positively, and so the draft popped up in the agenda :-) But, finally, I think this goes above my humble comprehension of facts, so I'll sit, watch and see. So I'm eager to see the slides and the minutes. Alex GBU From nemo-admin@ietf.org Sun Nov 9 17:55:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16163 for ; Sun, 9 Nov 2003 17:55: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 1AIySV-00051h-IP; Sun, 09 Nov 2003 17: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 1AIyRy-00050Y-Ml for nemo@optimus.ietf.org; Sun, 09 Nov 2003 17:54: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 RAA16022; Sun, 9 Nov 2003 17:54:15 -0500 (EST) From: Vijay.Devarapalli@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyRv-0001N8-00; Sun, 09 Nov 2003 17:54:27 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AIyRu-0001Mq-00; Sun, 09 Nov 2003 17:54:27 -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 hA9MsFe23024; Mon, 10 Nov 2003 00:54:15 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Nov 2003 00:54:15 +0200 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 9 Nov 2003 16:54:13 -0600 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: Sun, 9 Nov 2003 14:54:12 -0800 Message-ID: Thread-Topic: ok (was: HAHA slot at both MIP6 and NEMO?) Thread-Index: AcOnEmwAijO0LYkCTWK3T2fYoMCKogAAOEmg To: Cc: , X-OriginalArrivalTime: 09 Nov 2003 22:54:13.0600 (UTC) FILETIME=[653A2600:01C3A714] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: ok (was: HAHA slot at both MIP6 and 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 > > huh?? it is an individual submission. the authors are free to put=20 > > what they want in the spec. >=20 > Vijay, I suppose you got my point. not yet. >=20 > This is about many other individual submissions being=20 > rejected slots (or > imposed very tight time constraints) on grounds of non-relation to > Charters, while this particularly negatively reviewed individual > submission generously got 2 slots. having a draft out does not guarantee a slot at the WG meeting. WG meeting time is used mainly for resolving issues, not=20 presenting one's solution or one's draft. > > a WG draft is different. the WG decides what goes into it. >=20 > Absolutely, and it would have been even better if one of that WG's > member oppinion were taken into account when preparing the NEMO agenda > (the only oppinion apart an author's oppinion). This reads: the draft > HAHA was published, member reacted negatively, author positively, and > so the draft popped up in the agenda :-) its the WG chairs who decide the agenda after getting feedback from everyone. and Agenda Bashing is part of the agenda. :) the agenda can=20 still be changed. Vijay From exim@www1.ietf.org Sun Nov 9 17:55:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16190 for ; Sun, 9 Nov 2003 17:55: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 1AIySY-00053y-31 for nemo-archive@odin.ietf.org; Sun, 09 Nov 2003 17:55:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9Mt6VF019456 for nemo-archive@odin.ietf.org; Sun, 9 Nov 2003 17:55:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIySX-00053j-Uq for nemo-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 17:55: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 RAA16107 for ; Sun, 9 Nov 2003 17:54:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIySV-0001OR-00 for nemo-web-archive@ietf.org; Sun, 09 Nov 2003 17:55:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIySU-0001OO-00 for nemo-web-archive@ietf.org; Sun, 09 Nov 2003 17:55:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIySV-00051h-IP; Sun, 09 Nov 2003 17: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 1AIyRy-00050Y-Ml for nemo@optimus.ietf.org; Sun, 09 Nov 2003 17:54: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 RAA16022; Sun, 9 Nov 2003 17:54:15 -0500 (EST) From: Vijay.Devarapalli@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIyRv-0001N8-00; Sun, 09 Nov 2003 17:54:27 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AIyRu-0001Mq-00; Sun, 09 Nov 2003 17:54:27 -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 hA9MsFe23024; Mon, 10 Nov 2003 00:54:15 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Nov 2003 00:54:15 +0200 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 9 Nov 2003 16:54:13 -0600 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: Sun, 9 Nov 2003 14:54:12 -0800 Message-ID: Thread-Topic: ok (was: HAHA slot at both MIP6 and NEMO?) Thread-Index: AcOnEmwAijO0LYkCTWK3T2fYoMCKogAAOEmg To: Cc: , X-OriginalArrivalTime: 09 Nov 2003 22:54:13.0600 (UTC) FILETIME=[653A2600:01C3A714] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: ok (was: HAHA slot at both MIP6 and 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 > > huh?? it is an individual submission. the authors are free to put=20 > > what they want in the spec. >=20 > Vijay, I suppose you got my point. not yet. >=20 > This is about many other individual submissions being=20 > rejected slots (or > imposed very tight time constraints) on grounds of non-relation to > Charters, while this particularly negatively reviewed individual > submission generously got 2 slots. having a draft out does not guarantee a slot at the WG meeting. WG meeting time is used mainly for resolving issues, not=20 presenting one's solution or one's draft. > > a WG draft is different. the WG decides what goes into it. >=20 > Absolutely, and it would have been even better if one of that WG's > member oppinion were taken into account when preparing the NEMO agenda > (the only oppinion apart an author's oppinion). This reads: the draft > HAHA was published, member reacted negatively, author positively, and > so the draft popped up in the agenda :-) its the WG chairs who decide the agenda after getting feedback from everyone. and Agenda Bashing is part of the agenda. :) the agenda can=20 still be changed. Vijay From nemo-admin@ietf.org Mon Nov 10 14:43:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08293 for ; Mon, 10 Nov 2003 14:43:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHwD-0004G3-0D; Mon, 10 Nov 2003 14: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 1AJHvL-0004F2-Lw for nemo@optimus.ietf.org; Mon, 10 Nov 2003 14: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 OAA08172 for ; Mon, 10 Nov 2003 14:41:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJHvI-00036C-00 for nemo@ietf.org; Mon, 10 Nov 2003 14:42:04 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AJHvH-00035X-00 for nemo@ietf.org; Mon, 10 Nov 2003 14:42:04 -0500 Received: from huez (dyn143-171.ietf58.ietf.org [130.129.143.171]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 820395D0C0; Tue, 11 Nov 2003 04:41:30 +0900 (JST) Date: Tue, 11 Nov 2003 04:40:52 +0900 From: Thierry Ernst To: Alexandru Petrescu Cc: vijayd@iprg.nokia.com, souhwanj@ssu.ac.kr, nemo@ietf.org Subject: Re: [nemo] commens on draft-jung-nemo-threat-analysis-01.txt Message-Id: <20031111044052.5e3ab93a.ernst@sfc.wide.ad.jp> In-Reply-To: <12D4CC22.3000809@motorola.com> References: <3FADC478.6080200@iprg.nokia.com> <12D4CC22.3000809@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, I definitely agree that the slot at the meeting should discuss about threats specific to NEMO Basic Support. However, while Vijay mentioned that some threats in dtraft-jung-nemo-threat-analysis-01.txt are not specific to NEMO, I still think it's useful to keep those in mind and the best way is a written document. The non-NEMO issues may not be solved in NEMO WG, but they need to be brought to the attention of the relevant people. We should then use that kind of information as an input to the WG that is in the best position to solve it. Alex, what you wrote below is very interesting. Why don't you write a short I-D and get help from other people ? It's good to have a starting document on the table. Thierry. Alexandru Petrescu wrote: > Vijay Devarapalli wrote: > > I just read through the threat analysis document and sorry to say I > > was disappointed with the document. > > > > many of the threats are not Nemo specific. > > Exactly, that is my reading too. > > And since the agenda item describing this presentation invites to think > how to proceed with this WG item, I'd suggest to start with the Security > Considerations of draft-ietf-nemo-basic-support-01.txt and with section > 5 of draft-petrescu-nemo-mrha-03.txt. > > Starting point should be acknowledging that the only NEMO-specific > security risks are related to interactions between MR and HA. > > Then the IPsec tool protecting this should be described in more detail, > more specifically that it protects against eavesdropping between the > two, and masquerading of an attacker between the two. > > Then describe what that IPsec tool does _not_ protect against. > > Then describe in detail the checks suggested by the basic support, like > the ingress filtering of draft-ietf-nemo-basic. > > Then describe the threats appearing when MR and HA belong to different > admin domains. > > Then describe the problem of the built-in authentication of dynamic > routing protocols not covering the relations between prefix being > advertised and having the right to advertise that prefix; the prefix > table of basic support might help with this; an alternative way of > dealing with this being draft-ietf-ospf-ospfv3-auth-01.txt, in case of > OSPF. > > So, that's my suggestion of how to proceed with this WG item. > > [...] > > > this is a really bad idea. the only thing the MR should be doing is > > ingress filtering and access control check. it *should* not look into > > the packet contents. and what if the MNN is using end-to-end ESP > > encryption? the MR cant see the packet even if it wants to. > > I agree with the all the points you had down to the ellipsis. > > The "ingress filtering" aspect you say seems also reasonable. > > But, HA looking _inside_ the packet contents (beyond the headers > explicitely addressed to itself, and _if_ ESP is not present) might help > with solving the "cross-over" tunnels problem (see section B.6 of > draft-petrescu-nemo-mrha-03.txt for a description of this problem). > > >> 6.3 The amount of traffic from MNN through the IP-in-IP tunnel > >> SHOULD be secured to protect the location privacy against traffic > >> analysis. The amount of traffic through IP-in-IP tunnel MAY be > >> secured using expanded field as in IPsec ESP[10]. > > > > > > when did location privacy become a strong requirement? if the MNN is > > concerned about this, it should be using RFC 3041 addresses. > > Yes I agree with this too. From exim@www1.ietf.org Mon Nov 10 14:43:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08308 for ; Mon, 10 Nov 2003 14:43:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHwF-0004HS-VR for nemo-archive@odin.ietf.org; Mon, 10 Nov 2003 14:43:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAJh3jx016450 for nemo-archive@odin.ietf.org; Mon, 10 Nov 2003 14:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHwF-0004HF-Q1 for nemo-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 14:43: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 OAA08259 for ; Mon, 10 Nov 2003 14:42:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJHwC-00037u-00 for nemo-web-archive@ietf.org; Mon, 10 Nov 2003 14:43:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJHwC-00037m-00 for nemo-web-archive@ietf.org; Mon, 10 Nov 2003 14:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHwD-0004G3-0D; Mon, 10 Nov 2003 14: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 1AJHvL-0004F2-Lw for nemo@optimus.ietf.org; Mon, 10 Nov 2003 14: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 OAA08172 for ; Mon, 10 Nov 2003 14:41:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJHvI-00036C-00 for nemo@ietf.org; Mon, 10 Nov 2003 14:42:04 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AJHvH-00035X-00 for nemo@ietf.org; Mon, 10 Nov 2003 14:42:04 -0500 Received: from huez (dyn143-171.ietf58.ietf.org [130.129.143.171]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 820395D0C0; Tue, 11 Nov 2003 04:41:30 +0900 (JST) Date: Tue, 11 Nov 2003 04:40:52 +0900 From: Thierry Ernst To: Alexandru Petrescu Cc: vijayd@iprg.nokia.com, souhwanj@ssu.ac.kr, nemo@ietf.org Subject: Re: [nemo] commens on draft-jung-nemo-threat-analysis-01.txt Message-Id: <20031111044052.5e3ab93a.ernst@sfc.wide.ad.jp> In-Reply-To: <12D4CC22.3000809@motorola.com> References: <3FADC478.6080200@iprg.nokia.com> <12D4CC22.3000809@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, I definitely agree that the slot at the meeting should discuss about threats specific to NEMO Basic Support. However, while Vijay mentioned that some threats in dtraft-jung-nemo-threat-analysis-01.txt are not specific to NEMO, I still think it's useful to keep those in mind and the best way is a written document. The non-NEMO issues may not be solved in NEMO WG, but they need to be brought to the attention of the relevant people. We should then use that kind of information as an input to the WG that is in the best position to solve it. Alex, what you wrote below is very interesting. Why don't you write a short I-D and get help from other people ? It's good to have a starting document on the table. Thierry. Alexandru Petrescu wrote: > Vijay Devarapalli wrote: > > I just read through the threat analysis document and sorry to say I > > was disappointed with the document. > > > > many of the threats are not Nemo specific. > > Exactly, that is my reading too. > > And since the agenda item describing this presentation invites to think > how to proceed with this WG item, I'd suggest to start with the Security > Considerations of draft-ietf-nemo-basic-support-01.txt and with section > 5 of draft-petrescu-nemo-mrha-03.txt. > > Starting point should be acknowledging that the only NEMO-specific > security risks are related to interactions between MR and HA. > > Then the IPsec tool protecting this should be described in more detail, > more specifically that it protects against eavesdropping between the > two, and masquerading of an attacker between the two. > > Then describe what that IPsec tool does _not_ protect against. > > Then describe in detail the checks suggested by the basic support, like > the ingress filtering of draft-ietf-nemo-basic. > > Then describe the threats appearing when MR and HA belong to different > admin domains. > > Then describe the problem of the built-in authentication of dynamic > routing protocols not covering the relations between prefix being > advertised and having the right to advertise that prefix; the prefix > table of basic support might help with this; an alternative way of > dealing with this being draft-ietf-ospf-ospfv3-auth-01.txt, in case of > OSPF. > > So, that's my suggestion of how to proceed with this WG item. > > [...] > > > this is a really bad idea. the only thing the MR should be doing is > > ingress filtering and access control check. it *should* not look into > > the packet contents. and what if the MNN is using end-to-end ESP > > encryption? the MR cant see the packet even if it wants to. > > I agree with the all the points you had down to the ellipsis. > > The "ingress filtering" aspect you say seems also reasonable. > > But, HA looking _inside_ the packet contents (beyond the headers > explicitely addressed to itself, and _if_ ESP is not present) might help > with solving the "cross-over" tunnels problem (see section B.6 of > draft-petrescu-nemo-mrha-03.txt for a description of this problem). > > >> 6.3 The amount of traffic from MNN through the IP-in-IP tunnel > >> SHOULD be secured to protect the location privacy against traffic > >> analysis. The amount of traffic through IP-in-IP tunnel MAY be > >> secured using expanded field as in IPsec ESP[10]. > > > > > > when did location privacy become a strong requirement? if the MNN is > > concerned about this, it should be using RFC 3041 addresses. > > Yes I agree with this too. From nemo-admin@ietf.org Mon Nov 10 14:49:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08576 for ; Mon, 10 Nov 2003 14:49: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 1AJI21-0004aR-0e; Mon, 10 Nov 2003 14: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 1AJI1g-0004Zu-PO for nemo@optimus.ietf.org; Mon, 10 Nov 2003 14:48:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08553 for ; Mon, 10 Nov 2003 14:48:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJI1d-0003Fk-00 for nemo@ietf.org; Mon, 10 Nov 2003 14:48:37 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AJI1d-0003F9-00 for nemo@ietf.org; Mon, 10 Nov 2003 14:48:37 -0500 Received: from huez (dyn143-171.ietf58.ietf.org [130.129.143.171]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 86FCB5D188 for ; Tue, 11 Nov 2003 04:46:16 +0900 (JST) Date: Tue, 11 Nov 2003 04:45:40 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Multihoming and Load sharing. Message-Id: <20031111044540.07973228.ernst@sfc.wide.ad.jp> In-Reply-To: <5.1.1.5.2.20031108092238.02148788@popserve.grc.nasa.gov> References: <5.1.1.5.2.20031108092238.02148788@popserve.grc.nasa.gov> 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 Will, When speaking about load-sharing, do you refer to a particular document ? As far I know, load-sharing is only described as a potential benefit, not as something that must be supported. This is a result of being multihomed, not as pre-requisite. That fully allow it, other mechanisms are necessary on top of the signaling mechanism. The former may not be an IETF task. Thierry. > Whereas I can see configurations where it would be advantageous to allow > load sharing such as if one has two or three G3 wireless links up all with > relatively the same cost and bandwidth. > > However, IMHO there should definitely be a mechanism to turn load sharing > off. It would be quite useless and very expensive to load share between > and WiFi link cost $80.00 per month unlimited service and a 64 kbps > satellite link costing $1.00 per minute. From exim@www1.ietf.org Mon Nov 10 14:49:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08594 for ; Mon, 10 Nov 2003 14:49: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 1AJI24-0004bU-W6 for nemo-archive@odin.ietf.org; Mon, 10 Nov 2003 14:49:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAJn4pK017690 for nemo-archive@odin.ietf.org; Mon, 10 Nov 2003 14: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 1AJI24-0004bF-PX for nemo-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 14: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 OAA08565 for ; Mon, 10 Nov 2003 14:48:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJI20-0003Fz-00 for nemo-web-archive@ietf.org; Mon, 10 Nov 2003 14:49:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJI20-0003Fw-00 for nemo-web-archive@ietf.org; Mon, 10 Nov 2003 14:49:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJI21-0004aR-0e; Mon, 10 Nov 2003 14: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 1AJI1g-0004Zu-PO for nemo@optimus.ietf.org; Mon, 10 Nov 2003 14:48:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08553 for ; Mon, 10 Nov 2003 14:48:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJI1d-0003Fk-00 for nemo@ietf.org; Mon, 10 Nov 2003 14:48:37 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AJI1d-0003F9-00 for nemo@ietf.org; Mon, 10 Nov 2003 14:48:37 -0500 Received: from huez (dyn143-171.ietf58.ietf.org [130.129.143.171]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 86FCB5D188 for ; Tue, 11 Nov 2003 04:46:16 +0900 (JST) Date: Tue, 11 Nov 2003 04:45:40 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Multihoming and Load sharing. Message-Id: <20031111044540.07973228.ernst@sfc.wide.ad.jp> In-Reply-To: <5.1.1.5.2.20031108092238.02148788@popserve.grc.nasa.gov> References: <5.1.1.5.2.20031108092238.02148788@popserve.grc.nasa.gov> 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 Will, When speaking about load-sharing, do you refer to a particular document ? As far I know, load-sharing is only described as a potential benefit, not as something that must be supported. This is a result of being multihomed, not as pre-requisite. That fully allow it, other mechanisms are necessary on top of the signaling mechanism. The former may not be an IETF task. Thierry. > Whereas I can see configurations where it would be advantageous to allow > load sharing such as if one has two or three G3 wireless links up all with > relatively the same cost and bandwidth. > > However, IMHO there should definitely be a mechanism to turn load sharing > off. It would be quite useless and very expensive to load share between > and WiFi link cost $80.00 per month unlimited service and a 64 kbps > satellite link costing $1.00 per minute. From nemo-admin@ietf.org Mon Nov 10 17:27:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17574 for ; Mon, 10 Nov 2003 17:27: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 1AJKUu-0001WC-Ul; Mon, 10 Nov 2003 17:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKU1-0001Qr-Os for nemo@optimus.ietf.org; Mon, 10 Nov 2003 17:26: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 RAA17453 for ; Mon, 10 Nov 2003 17:25:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKTy-000671-00 for nemo@ietf.org; Mon, 10 Nov 2003 17:26:02 -0500 Received: from delicious.ietf58.ietf.org ([130.129.16.24]) by ietf-mx with esmtp (Exim 4.12) id 1AJKTx-00066y-00 for nemo@ietf.org; Mon, 10 Nov 2003 17:26:01 -0500 Received: from SOUHWANSENSQ (dyn136-127.ietf58.ietf.org [130.129.136.127]) by delicious.ietf58.ietf.org (8.12.10/8.12.10) with SMTP id hAAMQ6Ki004938; Mon, 10 Nov 2003 16:26:07 -0600 (CST) Message-ID: <003701c3a7d1$3f3817b0$7f888182@SOUHWANSENSQ> From: "Souhwan Jung" To: "Vijay Devarapalli" Cc: References: <3FADC478.6080200@iprg.nokia.com> Date: Tue, 11 Nov 2003 06:25:59 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Subject: [nemo] Re: commens on draft-jung-nemo-threat-analysis-01.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGksIFZpamF5DQoNCkZpcnN0LCBJIGFwcHJlY2lhdGUgeW91ciBjb21tZW50cyBvbiBteSBkcmFm dCwgdGhvdWdoIHRoZXkgYXJlIHByZXR0eSBtdWNoIGFnYWluc3QgdG8gb3VyIGFwcHJvYWNoLg0K DQpUaGUgbWFqb3IgdGhyZWF0cyB3ZSBoYXZlIGRpc2NvdmVyZWQgc28gZmFyLCB3aGljaCBhcmUg dmVyeSBzcGVjaWZpYyB0byBORU1PIGJhc2ljIHN1cHBvcnQgcHJvdG9jb2wsIGFyZSB0aGUgdGhy ZWF0cyBmcm9tIFNlY3Rpb24gNS4xIGFuZCA1LjIgaW4gdGhlIGRyYWZ0LiBUaGUgb3RoZXIgc3R1 ZmYgbWF5IGJlIGtpbmQgb2YgImdlbmVyaWMiIHRocmVhdHMgdG8gYW55IGhvc3RzIG9yIHJvdXRl cnMuIEJ1dCB0aGUgcmVhc29uIHRvIGluY2x1ZGUgdGhvc2UgImdlbmVyaWMiIHRocmVhdHMgaW4g dGhlIGRyYWZ0IGlzIHRvIGludmVzdGlnYXRlIGFsbCBwb3RlbnRpYWwgdGhyZWF0cyB0aGF0IGFy ZSByZWxldmFudCB0byBORU1PIHByb3RvY29sLCBhbmQgdG8gZmluZCB0aHJlYXRzIG1vcmUgc3Bl Y2lmaWMgdG8gTkVNTyBwcm90b2NvbC4NCg0KSWYgeW91IGZvY3VzIG9uIHRoZSBORU1PIGJhc2lj IHByb3RvY29sIG9ubHksIHRoZW4gdGhlIHNjb3BlIGlzIHByZXR0eSBuYXJyb3csIGFuZCBJIGFt IGFmcmFpZCB5b3UgbWF5IG1pc3Mgc29tZSBvZiB0aGUgcG90ZW50aWFsIHRocmVhdHMgdGhhdCBz aG91bGQgYmUgY29uc2lkZXJlZCBpbiB0aGUgbmVhciBmdXR1cmUsIGUuZy4gdGhyZWF0cyBmb3Ig ZXh0ZW5kZWQgTkVNTyBwcm90b2NvbHMuDQoNCkFueXdheSwgeW91IGRpZG4ndCB0ZWxsIG11Y2gg YWJvdXQgdGhlIHRocmVhdHMgaW4gU2VjdGlvbiA1LjEgYW5kIDUuMiB0aGF0IGNvdWxkIGJlIHZl cnkgY3JpdGljYWwsIHdlIGJlbGlldmUuIEp1c3QgZG9pbmcgaW5ncmVzcyBmaWx0ZXJpbmcgaW4g TVIgY2FuIG5vdCBwcm90ZWN0IHRoZSBhdHRhY2tzLiBDYW4geW91IGdpdmUgc29tZSBjb21tZW50 cyBvbiB0aG9zZSB0aHJlYXRzPw0KDQpUaGFua3MuDQoNClNvdWh3YW4gIA0KDQoNCi0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiVmlqYXkgRGV2YXJhcGFsbGkiIDx2aWpheWRA aXByZy5ub2tpYS5jb20+DQpUbzogPHNvdWh3YW5qQHNzdS5hYy5rcj4NCkNjOiA8bmVtb0BpZXRm Lm9yZz4NClNlbnQ6IFN1bmRheSwgTm92ZW1iZXIgMDksIDIwMDMgMTozNyBQTQ0KU3ViamVjdDog Y29tbWVucyBvbiBkcmFmdC1qdW5nLW5lbW8tdGhyZWF0LWFuYWx5c2lzLTAxLnR4dA0KDQoNCj4g aGksDQo+IA0KPiBJIGp1c3QgcmVhZCB0aHJvdWdoIHRoZSB0aHJlYXQgYW5hbHlzaXMgZG9jdW1l bnQgYW5kIHNvcnJ5IHRvIHNheQ0KPiBJIHdhcyBkaXNhcHBvaW50ZWQgd2l0aCB0aGUgZG9jdW1l bnQuDQo+IA0KPiBtYW55IG9mIHRoZSB0aHJlYXRzIGFyZSBub3QgTmVtbyBzcGVjaWZpYy4gZm9y IGV4YW1wbGUgaXQgdGFsa3MNCj4gYWJvdXQgYSBjb21wcm9taXNlZCBBY2Nlc3MgUm91dGVyLCBh biBhdHRhY2tlciBpbmplY3RpbmcgZmFsc2UNCj4gUm91dGVyIEFkdmVydGlzZW1lbnQgaW5mb3Jt YXRpb24gaW4gdGhlIGhvbWUgbGluaywgYSBjb21wcm9taXNlZA0KPiBIb21lIEFnZW50LCBldGMu Li4uIGFsbCB0aGVzZSB0aHJlYXRzIHNob3VsZCBiZSByZW1vdmVkIGZyb20gdGhlDQo+IGRvY3Vt ZW50Lg0KPiANCj4gc29tZSBvZiB0aGUgdGhyZWF0cyBhcmUgYWxzbyBub3QgdmFsaWQuDQo+IA0K PiBzcGVjaWZpYyBjb21tZW50cyBmb2xsb3cuDQo+IA0KPiBWaWpheQ0KPiANCj4gDQo+ID4gICAg ICAtIERpc2NhcmQgcmVnaXN0cmF0aW9uIG1lc3NhZ2VzIGZyb20gTVIgdG8gRkENCj4gPiAgICAg ICAgVGhpcyB0aHJlYXQgaXMgYSBzb3J0IG9mIERvUyBhdHRhY2sgdG8gYmxvY2sgbmV0d29yayBj b25uZWN0aXZpdHkgDQo+ID4gICAgICAgIHNlcnZpY2UgdG8gTVIuIFRoZSBhdHRhY2tlciBjb21w cm9taXNlcyB0aGUgRkEsIGFuZCBrZWVwIGRpc2NhcmRpbmcgDQo+ID4gICAgICAgIHRoZSByZWdp c3RyYXRpb24gbWVzc2FnZSBmcm9tIE1SLiBUaGUgcmVzdWx0IG9mIHRoZSBhdHRhY2sgaXMgbm8g DQo+ID4gICAgICAgIGF2YWlsYWJpbGl0eSBvZiBuZXR3b3JrIGNvbm5lY3Rpb24gc2VydmljZSB0 byB0aGUgbW9iaWxlIG5ldHdvcmtzLg0KPiANCj4gcmVtb3ZlIHRoaXMgdGhyZWF0LiBpdCBpcyBu b3QgcmVhbGx5IE5lbW8gc3BlY2lmaWMuIGlmIHRoZSBhY2Nlc3MNCj4gcm91dGVyIGlzIGNvbXBy b21pc2VkLCB0aGVyZSBpc250IG11Y2ggeW91IGNhbiBkbyBhYm91dCBpdC4gdGhlDQo+IGFjY2Vz cyByb3V0ZXIgY291bGQgZGVueSBuZXR3b3JrIGNvbm5lY3Rpb24gdG8gbW9iaWxlIG5vZGVzLCBm aXhlZA0KPiBub2RlcyB3aXRoIHdpcmVsZXNzIGFjY2VzcywgZXRjLg0KPiANCj4gPiANCj4gPiAg ICAgIC0gQ29ycnVwdGVkIHJvdXRpbmcgaW5mb3JtYXRpb24NCj4gPiAgICAgICAgQXR0YWNrZXIg bWF5IHNlbmQgY29ycnVwdGVkIHJvdXRpbmcgaW5mb3JtYXRpb24gdG8gTVIgYW5kIGNhdXNlIA0K PiA+ICAgICAgICBuZXR3b3JrIGluc3RhYmlsaXR5IHN1Y2ggYXMgbmV0d29yayBjb25nZXN0aW9u IG9yIGxvb3BpbmcuIElmIHRoZSANCj4gPiAgICAgICAgTVIgaXMgaW4gdGhlIHZpc2l0ZWQgZG9t YWluLCBpdCB3aWxsIG5vdCByZXNwb25kIHRvIHRoZSB1bnNvbGljaXRlZCANCj4gPiAgICAgICAg UkEuIEJ1dCB3aGlsZSB0aGUgTVIgaXMgaW4gaG9tZSBkb21haW4sIGl0IHN0aWxsIGFjY2VwdHMg dGhlIFJBIA0KPiA+ICAgICAgICBtZXNzYWdlcywgYW5kIG1heSBnZXQgc2NyZXdlZCB1cCB3aXRo IHdyb25nIHJvdXRpbmcgaW5mb3JtYXRpb24uDQo+IA0KPiBpZiBhbiBhdHRhY2tlciBnZXRzIGlu dG8gdGhlIGhvbWUgZG9tYWluIGFuZCBzZW5kcyAiY29ycnVwdGVkIHJvdXRpbmcNCj4gaW5mb3Jt YXRpb24iLCB5b3UgaGF2ZSBhIGxvdCBtb3JlIHNlcmlvdXMgcHJvYmxlbSBhdCBoYW5kLiByZW1v dmUgdGhpcy4NCj4gDQo+IA0KPiA+ICAgICAgIC0gZWF2ZXNkcm9wcGluZy9yZXBsYXkgb2YgbWVz c2FnZXMgYmV0d2VlbiBNUiBhbmQgSEENCj4gPiAgICAgICAgICBBbGwgdGhlIGRhdGEgcGFja2V0 cyBiZXR3ZWVuIE1SIGFuZCBIQSBoYXZlIHRvIGdvIHRocm91Z2ggdGhlIA0KPiA+ICAgICAgICAg IGJpLWRpcmVjdGlvbmFsIHR1bm5lbC4gVGhpcyB0dW5uZWwgc2hvdWxkIGJlIHNlY3VyZWQgYnkg SVBzZWMuIA0KPiA+ICAgICAgICAgIEJ1dCBzb21lIG9mIHRoZSByb3V0aW5nIGluZm9ybWF0aW9u IHRoYXQgbWF5IG5vdCBnbyB0aHJvdWdoIA0KPiA+ICAgICAgICAgIHRoaXMgdHVubmVsIHNob3Vs ZCBiZSBzZWN1cmVkLg0KPiANCj4gdGhpcyBkaWRudCBtYWtlIGEgbG90IG9mIHNlbnNlLg0KPiAN Cj4gPiAgICAgICAtIGVhdmVzZHJvcHBpbmcvcmVwbGF5IG9mIG1lc3NhZ2VzIGJldHdlZW4gTU5O IGFuZCBDTg0KPiA+ICAgICAgICAgIFRoZSBtZXNzYWdlcyBiZXR3ZWVuIE1OTiBhbmQgQ04gYXJl IGdvaW5nIHRocm91Z2ggdGhlIA0KPiA+ICAgICAgICAgIGJpLWRpcmVjdGlvbmFsIHR1bm5lbCwg YnV0IHRoZXJlIGlzIG5vIHByb3RlY3Rpb24gYWdhaW5zdCANCj4gPiAgICAgICAgICBzbmlmZmlu ZyBkYXRhIGJldHdlZW4gTVIgYW5kIE1OTiBvciBiZXR3ZWVuIEhBIGFuZCBDTi4gU28gDQo+ID4g ICAgICAgICAgc2VjdXJpdHkgbWVjaGFuaXNtcyBzaG91bGQgYmUgYXBwbGllZCBvbiB0aGUgcGFy dCBvZiB0aGUgDQo+ID4gICAgICAgICAgcGF0aCB1bmNvdmVyZWQuDQo+IA0KPiBhZ2Fpbiwgbm90 aGluZyBOZW1vIHNwZWNpZmljLiB0aGlzIGlzIGFwcGxpY2FibGUgdG8gYW55IHR3byBub2Rlcw0K PiAod2hldGhlciBtb2JpbGUgb3Igbm90KS4gdGhlIGJlc3Qgc29sdXRpb24gZm9yIHRoaXMgaXMg dG8gaGF2ZQ0KPiBlbmQtdG8tZW5kIHNlY3VyaXR5IGJldHdlZW4gTU5OIGFuZCBDTi4NCj4gDQo+ ID4gDQo+ID4gICAgICAgLSBsb2NhdGlvbiBwcml2YWN5DQo+ID4gICAgICAgICBNb25pdG9yaW5n IGFuZCBhbmFseXppbmcgdGhlIGNoYXJhY3RlcmlzdGljcyBvZiBkYXRhIHRyYWZmaWMgDQo+ID4g ICAgICAgICBhbG9uZyB0aGUgY29tbXVuaWNhdGlvbiBwYXRocyByZXZlYWxzIHNvbWUgaW5mb3Jt YXRpb24gb24gcm91dGluZyANCj4gPiAgICAgICAgIGFuZCBsb2NhdGlvbiBwcml2YWN5Lg0KPiAN Cj4gbm90IE5lbW8gc3BlY2lmaWMuIHBsZWFzZSByZW1vdmUuDQo+IA0KPiA+IC0gTVItSEEgc3Bv b2ZpbmcNCj4gPiAgICAgICAgICAgTVItSEEgaXMgdGhlIHBlcm1hbmVudCBhZGRyZXNzIGFzc2ln bmVkIHN0YXRpY2FsbHkgb3IgDQo+ID4gICAgICAgICAgIGR5bmFtaWNhbGx5IHRvIHRoZSBNUiBi eSBIQS4gTVItSEEgc2hvdWxkIGJlIHVzZWQgZm9yIA0KPiA+ICAgICAgICAgICBpZGVudGlmaWNh dGlvbiBvZiBNUiB3aGlsZSBpdCBpcyBpbiB0aGUgdmlzaXRlZCBkb21haW4uIA0KPiA+ICAgICAg ICAgICBUaGUgY29tcHJvbWlzZWQgTVIgY2FuIHJlZ2lzdGVyIHRvIEZBIHdpdGggYSBzcG9vZmVk IE1SLUhBLCANCj4gPiAgICAgICAgICAgYW5kIHRyeSB0byBjb2xsZWN0IGRhdGEgZGVzdGluYXRl ZCB0byB0aGUgdmljdGltIGFkZHJlc3MuDQo+IA0KPiB0aGlzIGlzIGFuIElQdjQgbW9kZWwuIGlu IE5lbW8sIE1SIGRlYWxzIGRpcmVjdGx5IHdpdGggdGhlIEhBLiBpdCBkb2VzDQo+IG5vIHJlZ2lz dHJhdGlvbiB3aXRoIEZBL0FSLg0KPiANCj4gPiAtIENhY2hlIHBvaXNvbmluZyANCj4gPiAgICAg ICAgICAgVGhlIGNhY2hlIGRhdGEgZm9yIHJvdXRpbmcgdGFibGUgaW4gTVIgY2FuIGJlIGNvcnJ1 cHRlZCB0byANCj4gPiAgICAgICAgICAgc3VidmVydCByb3V0aW5nIHBhdGguIFRoZSBkYXRhIHBh Y2tldCBjb3VsZCBiZSByZWRpcmVjdGVkIG9yIA0KPiA+ICAgICAgICAgICBsb29wZWQgY2F1c2lu ZyBuZXR3b3JrIGluc3RhYmlsaXR5Lg0KPiANCj4gd2hpY2ggIkNhY2hlIj8NCj4gDQo+IA0KPiA+ ICAgIDQuMiBNaXNiZWhhdmlvciBvZiBIQQ0KPiA+ICAgICAgICAgLSBzbmlmZmluZyBvZiB0dW5u ZWxlZCBwYWNrZXQNCj4gPiAgICAgICAgICAgVGhlIElQc2VjIHRyYW5zcG9ydCBtb2RlIHNob3Vs ZCBiZSB1c2VkIGZvciBzZWN1cmluZyB0aGUgDQo+ID4gICAgICAgICAgIHR1bm5lbGVkIHBhY2tl dHMgYmV0d2VlbiBNUiBhbmQgSEEuIFdpdGggdGhlIGNvbXByb21pc2Ugb2YgDQo+ID4gICAgICAg ICAgIHRoZSBIQSwgdGhlIGF0dGFja2VyIGNhbiBzbmlmZiB0aGUgZGVjcnlwdGVkIGRhdGEgcGFj a2V0IA0KPiA+ICAgICAgICAgICBpbiBIQS4NCj4gPiANCj4gPiAgICAgICAgIC0gY29ycnVwdGlv biBvZiBiaW5kaW5nIGNhY2hlDQo+ID4gICAgICAgICAgIEhBIGtlZXBzIG1hbmFnaW5nIHRoZSBC VSBpbmZvcm1hdGlvbiBvbiBiaW5kaW5nIGNhY2hlLiANCj4gPiAgICAgICAgICAgV2l0aCB0aGUg Y29ycnVwdGlvbiBvZiBiaW5kaW5nIGluZm9ybWF0aW9uLCB0aGUgYXR0YWNrZXIgDQo+ID4gICAg ICAgICAgIGNhbiByZWRpcmVjdHMgcGFja2V0cyB0byB3aGVyZSBoZSB3YW50IHRvIGRlbGl2ZXIg dGhlbS4NCj4gDQo+IHJlbW92ZSA0LjIuIEkgZG9udCBleHBlY3QgdGhlIEhBIHRvIG1pc2JlaGF2 ZS4gdGhlcmUgaXNudCBtdWNoIHRoZQ0KPiBOZW1vIHByb3RvY29sIGJhc2ljL2V4dGVuZGVkIGNh biBkbyBpZiB0aGUgSEEgbWlzYmVoYXZlcy4NCj4gDQo+ID4gICAgICAgIA0KPiA+ICAgIDQuNCBE ZW5pYWwgb2YgU2VydmljZQ0KPiA+ICAgICAgICBEZW5pYWwgb2YgU2VydmljZSBhdHRhY2sgaXMg cG9zc2libGUgYWdhaW5zdCBNUiBhbmQgSEEgYnkgZmxvb2RpbmcgDQo+ID4gICAgICAgIEJVIG1l c3NhZ2VzIGFuZCBib2d1cyB0dW5uZWxlZCBwYWNrZXRzLiBUaGUgYXR0YWNrIGNhbiBiZSBtb3Jl IA0KPiA+ICAgICAgICBlZmZlY3RpdmUgd2l0aCBkaXN0cmlidXRlZCBmYWtlIE1ScyBvciBIQXMu ICAgICANCj4gDQo+IEJpbmRpbmcgVXBkYXRlcyBhcmUgcmF0ZS1saW1pdGVkLiB0aGlzIG1heWJl IG5vdCBiZSBwb3NzaWJsZS4NCj4gDQo+ID4gICAgIDUuMSBDb3JydXB0aW9uIG9mIEJpbmRpbmcg Q2FjaGUgYnkgaW5zaWRlIGF0dGFja2VyDQo+IA0KPiB0aGUgZW50aXJlIHNlY3Rpb24gNS4xIG5l ZWRzIHRvIGJlIHJlLXdyaXR0ZW4gd2l0aG91dCBhc3N1bWluZw0KPiBOQVQgb3IgTkFULVBUIG9u IHRoZSBtb2JpbGUgcm91dGVyLg0KPiANCj4gPiAgICAgNS4zIEF0dGFjayB0byBMb2NhdGlvbiBQ cml2YWN5IGJ5IFRyYWZmaWMgQW5hbHlzaXMNCj4gPiAgICAgIA0KPiA+ICAgICAgICAgSW4gdGhl IGJhc2ljIE5FTU8gY29uZmlndXJhdGlvbnMsIGFsbCB0aGUgdHJhZmZpYyBmcm9tIG1vYmlsZSAN Cj4gPiAgICAgICAgIG5ldHdvcmsgYXJlIHN1cHBvc2VkIHRvIGdvIHRocm91Z2ggdGhlIGJpLWRp cmVjdGlvbmFsIHR1bm5lbA0KPiA+ICAgICAgICAgYmV0d2VlbiBNUiBhbmQgSEEuIFRoZSBIQSBj YW4gY29sbGVjdCBhbGwgdGhlIHBhY2tldHMgaW4gDQo+ID4gICAgICAgICBJUC1pbi1JUCB0dW5u ZSwgZGVjYXBzdWxhdGVzIHRoZW0sIGFuZCBmb3J3YXJkcyB0aGVtIHRvIHRoZSBDTnMuDQo+ID4g ICAgICAgICANCj4gPiAgICAgICAgICANCj4gPiAgICAgICAgIHwtLS0tLXwgICAgICAgICB8LS0t LXwgICBJUC1pbi1JUCB0dW5uZWwgIHwtLS0tfCAgICAgICAgIHwtLS0tfA0KPiA+ICAgICAgICAg fCBNTk4gfC0tLS0tLS0tLXwgTVIgfCA9PT09PT09PT09PT09PT09PT0gfCBIQSB8LS0tLS0tLS0t fCBDTiB8DQo+ID4gICAgICAgICB8LS0tLS18ICAgIDEgICAgfC0tLS18ICAgICAgICAgIDIgICAg ICAgICB8LS0tLXwgICAgMyAgICB8LS0tLXwNCj4gPiAgICAgICAgIA0KPiA+ICANCj4gPiAgICAg ICAgIFRoZSBvdXRzaWRlIGF0dGFja2VyIGNhbiBtb25pdG9yIHRoZSB0cmFmZmljIGluIHBhdGgg MiBhbmQgMy4gDQo+IA0KPiBob3cgaXMgdGhlIGF0dGFja2VyIG9uIGJvdGggcGF0aCAyIGFuZCAz Pw0KPiANCj4gPiA2LiAgICAgIFNlY3VyaXR5IFJlcXVpcmVtZW50cyBmb3IgTkVNTw0KPiA+IA0K PiA+ICAgICAgICAgVGhlIGJhc2ljIHN1cHBvcnQgcHJvdG9jb2wgZm9yIE5FTU8gaXMgYmFzZWQg b24gdGhlIE1JUHY2IA0KPiA+ICAgICAgICAgb3BlcmF0aW9ucyBleGNlcHQgdGhlIGJpLWRpcmVj dGlvbmFsIHR1bm5lbCBvcGVyYXRpb25zIGJldHdlZW4gDQo+ID4gICAgICAgICBNUiBhbmQgSEEu IFRoZXJlZm9yZSwgbW9zdCBvZiB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGFyZSANCj4gPiAg ICAgICAgIGFscmVhZHkgYWRkcmVzc2VkIGluIE1JUHY2IFdHIGRvY3VtZW50c1s0XSwgc28gdGhp cyBkcmFmdCBkZXNjcmliZXMgDQo+ID4gICAgICAgICB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRz IG9ubHkgYWdhaW5zdCBuZXcgdGhyZWF0cyBpbiBORU1PLiANCj4gPiAgICAgICAgIFRoZSBmb2xs b3dpbmcgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIFNIT1VMRCBiZSBhZGRyZXNzZWQgaW4gTkVNTyAN Cj4gPiAgICAgICAgIGJhc2ljIGFuZCBleHRlbmRlZCBkb2N1bWVudHMuDQo+ID4gICAgICAgICAN Cj4gPiAgICAgICAgIDYuMSBNUiBTSE9VTEQgY2hlY2sgdGhlIGNvbnRlbnRzIG9mIHRoZSBwYWNr ZXQgZnJvbSBNTk4gaW5zaWRlICwgDQo+ID4gICAgICAgICAgICAgYW5kIGFzc3VyZSB0aGF0IHRo ZSBwYWNrZXQgZG9lcyBub3QgaW5jbHVkZSBmYWtlIGluZm9ybWF0aW9uDQo+ID4gICAgICAgICAg ICAgaW4gdGhlIGNyaXRpY2FsIG1lc3NhZ2VzIHN1Y2ggYXMgQlUsIHByZWZpeCBkaXNjb3Zlcnks IG9yIA0KPiA+ICAgICAgICAgICAgIElDTVAgbWVzc2FnZXMuDQo+IA0KPiB0aGlzIGlzIGEgcmVh bGx5IGJhZCBpZGVhLiB0aGUgb25seSB0aGluZyB0aGUgTVIgc2hvdWxkIGJlIGRvaW5nIGlzDQo+ IGluZ3Jlc3MgZmlsdGVyaW5nIGFuZCBhY2Nlc3MgY29udHJvbCBjaGVjay4gaXQgKnNob3VsZCog bm90IGxvb2sgaW50bw0KPiB0aGUgcGFja2V0IGNvbnRlbnRzLiBhbmQgd2hhdCBpZiB0aGUgTU5O IGlzIHVzaW5nIGVuZC10by1lbmQgRVNQDQo+IGVuY3J5cHRpb24/IHRoZSBNUiBjYW50IHNlZSB0 aGUgcGFja2V0IGV2ZW4gaWYgaXQgd2FudHMgdG8uDQo+IA0KPiANCj4gPiAgICAgICAgIDYuMiBU aGUgSVAtaW4tSVAgZW5jYXBzdWxhdGVkIHBhY2tldCBTSE9VTEQgYmUgYXV0aGVudGljYXRlZCAN Cj4gPiAgICAgICAgICAgICBiZXR3ZWVuIE1SIGFuZCBIQSwgYW5kIHBlci1wYWNrZXQgYXV0aGVu dGljYXRpb24gYXQgTVIgDQo+ID4gICAgICAgICAgICAgU0hPVUxEIGJlIGVuZm9yY2VkLiANCj4g DQo+IGF1dGhlbnRpY2F0ZWQ/IHdoeT8gdGhlIEhBIGFscmVhZHkgbWFrZXMgc3VyZSB0aGF0IHRo ZSBDb0EgKG9uIHRoZQ0KPiBvdXRlciBoZWFkZXIpIGlzIGF1dGhvcml6ZWQgdG8gdHVubmVsIHBh Y2tldHMgZm9yIE1OTidzIGFkZHJlc3MNCj4gKGluIHRoZSBpbm5lciBoZWFkZXIpLiB5b3UgZG9u dCBuZWVkIHBlci1wYWNrZXQgYXV0aGVudGljYXRpb24uDQo+IA0KPiA+ICAgICAgICAgNi4zIFRo ZSBhbW91bnQgb2YgdHJhZmZpYyBmcm9tIE1OTiB0aHJvdWdoIHRoZSBJUC1pbi1JUCB0dW5uZWwg DQo+ID4gICAgICAgICAgICAgU0hPVUxEIGJlIHNlY3VyZWQgdG8gcHJvdGVjdCB0aGUgbG9jYXRp b24gcHJpdmFjeSBhZ2FpbnN0IA0KPiA+ICAgICAgICAgICAgIHRyYWZmaWMgYW5hbHlzaXMuIFRo ZSBhbW91bnQgb2YgdHJhZmZpYyB0aHJvdWdoIElQLWluLUlQIA0KPiA+ICAgICAgICAgICAgIHR1 bm5lbCBNQVkgYmUgc2VjdXJlZCB1c2luZyBleHBhbmRlZCBmaWVsZCBhcyBpbiBJUHNlYyANCj4g PiAgICAgICAgICAgICBFU1BbMTBdLiANCj4gDQo+IHdoZW4gZGlkIGxvY2F0aW9uIHByaXZhY3kg YmVjb21lIGEgc3Ryb25nIHJlcXVpcmVtZW50PyBpZiB0aGUgTU5ODQo+IGlzIGNvbmNlcm5lZCBh Ym91dCB0aGlzLCBpdCBzaG91bGQgYmUgdXNpbmcgUkZDIDMwNDEgYWRkcmVzc2VzLg0KPiANCj4g DQo+IA0KPiA= From exim@www1.ietf.org Mon Nov 10 17:27:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17592 for ; Mon, 10 Nov 2003 17:27: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 1AJKV4-0001ZT-0j for nemo-archive@odin.ietf.org; Mon, 10 Nov 2003 17:27:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAMR9V5006040 for nemo-archive@odin.ietf.org; Mon, 10 Nov 2003 17:27:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKV3-0001ZJ-5Z for nemo-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 17:27: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 RAA17543 for ; Mon, 10 Nov 2003 17:26:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKV0-00068G-00 for nemo-web-archive@ietf.org; Mon, 10 Nov 2003 17:27:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJKV0-00068D-00 for nemo-web-archive@ietf.org; Mon, 10 Nov 2003 17:27:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKUu-0001WC-Ul; Mon, 10 Nov 2003 17:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKU1-0001Qr-Os for nemo@optimus.ietf.org; Mon, 10 Nov 2003 17:26: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 RAA17453 for ; Mon, 10 Nov 2003 17:25:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKTy-000671-00 for nemo@ietf.org; Mon, 10 Nov 2003 17:26:02 -0500 Received: from delicious.ietf58.ietf.org ([130.129.16.24]) by ietf-mx with esmtp (Exim 4.12) id 1AJKTx-00066y-00 for nemo@ietf.org; Mon, 10 Nov 2003 17:26:01 -0500 Received: from SOUHWANSENSQ (dyn136-127.ietf58.ietf.org [130.129.136.127]) by delicious.ietf58.ietf.org (8.12.10/8.12.10) with SMTP id hAAMQ6Ki004938; Mon, 10 Nov 2003 16:26:07 -0600 (CST) Message-ID: <003701c3a7d1$3f3817b0$7f888182@SOUHWANSENSQ> From: "Souhwan Jung" To: "Vijay Devarapalli" Cc: References: <3FADC478.6080200@iprg.nokia.com> Date: Tue, 11 Nov 2003 06:25:59 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Subject: [nemo] Re: commens on draft-jung-nemo-threat-analysis-01.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGksIFZpamF5DQoNCkZpcnN0LCBJIGFwcHJlY2lhdGUgeW91ciBjb21tZW50cyBvbiBteSBkcmFm dCwgdGhvdWdoIHRoZXkgYXJlIHByZXR0eSBtdWNoIGFnYWluc3QgdG8gb3VyIGFwcHJvYWNoLg0K DQpUaGUgbWFqb3IgdGhyZWF0cyB3ZSBoYXZlIGRpc2NvdmVyZWQgc28gZmFyLCB3aGljaCBhcmUg dmVyeSBzcGVjaWZpYyB0byBORU1PIGJhc2ljIHN1cHBvcnQgcHJvdG9jb2wsIGFyZSB0aGUgdGhy ZWF0cyBmcm9tIFNlY3Rpb24gNS4xIGFuZCA1LjIgaW4gdGhlIGRyYWZ0LiBUaGUgb3RoZXIgc3R1 ZmYgbWF5IGJlIGtpbmQgb2YgImdlbmVyaWMiIHRocmVhdHMgdG8gYW55IGhvc3RzIG9yIHJvdXRl cnMuIEJ1dCB0aGUgcmVhc29uIHRvIGluY2x1ZGUgdGhvc2UgImdlbmVyaWMiIHRocmVhdHMgaW4g dGhlIGRyYWZ0IGlzIHRvIGludmVzdGlnYXRlIGFsbCBwb3RlbnRpYWwgdGhyZWF0cyB0aGF0IGFy ZSByZWxldmFudCB0byBORU1PIHByb3RvY29sLCBhbmQgdG8gZmluZCB0aHJlYXRzIG1vcmUgc3Bl Y2lmaWMgdG8gTkVNTyBwcm90b2NvbC4NCg0KSWYgeW91IGZvY3VzIG9uIHRoZSBORU1PIGJhc2lj IHByb3RvY29sIG9ubHksIHRoZW4gdGhlIHNjb3BlIGlzIHByZXR0eSBuYXJyb3csIGFuZCBJIGFt IGFmcmFpZCB5b3UgbWF5IG1pc3Mgc29tZSBvZiB0aGUgcG90ZW50aWFsIHRocmVhdHMgdGhhdCBz aG91bGQgYmUgY29uc2lkZXJlZCBpbiB0aGUgbmVhciBmdXR1cmUsIGUuZy4gdGhyZWF0cyBmb3Ig ZXh0ZW5kZWQgTkVNTyBwcm90b2NvbHMuDQoNCkFueXdheSwgeW91IGRpZG4ndCB0ZWxsIG11Y2gg YWJvdXQgdGhlIHRocmVhdHMgaW4gU2VjdGlvbiA1LjEgYW5kIDUuMiB0aGF0IGNvdWxkIGJlIHZl cnkgY3JpdGljYWwsIHdlIGJlbGlldmUuIEp1c3QgZG9pbmcgaW5ncmVzcyBmaWx0ZXJpbmcgaW4g TVIgY2FuIG5vdCBwcm90ZWN0IHRoZSBhdHRhY2tzLiBDYW4geW91IGdpdmUgc29tZSBjb21tZW50 cyBvbiB0aG9zZSB0aHJlYXRzPw0KDQpUaGFua3MuDQoNClNvdWh3YW4gIA0KDQoNCi0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiVmlqYXkgRGV2YXJhcGFsbGkiIDx2aWpheWRA aXByZy5ub2tpYS5jb20+DQpUbzogPHNvdWh3YW5qQHNzdS5hYy5rcj4NCkNjOiA8bmVtb0BpZXRm Lm9yZz4NClNlbnQ6IFN1bmRheSwgTm92ZW1iZXIgMDksIDIwMDMgMTozNyBQTQ0KU3ViamVjdDog Y29tbWVucyBvbiBkcmFmdC1qdW5nLW5lbW8tdGhyZWF0LWFuYWx5c2lzLTAxLnR4dA0KDQoNCj4g aGksDQo+IA0KPiBJIGp1c3QgcmVhZCB0aHJvdWdoIHRoZSB0aHJlYXQgYW5hbHlzaXMgZG9jdW1l bnQgYW5kIHNvcnJ5IHRvIHNheQ0KPiBJIHdhcyBkaXNhcHBvaW50ZWQgd2l0aCB0aGUgZG9jdW1l bnQuDQo+IA0KPiBtYW55IG9mIHRoZSB0aHJlYXRzIGFyZSBub3QgTmVtbyBzcGVjaWZpYy4gZm9y IGV4YW1wbGUgaXQgdGFsa3MNCj4gYWJvdXQgYSBjb21wcm9taXNlZCBBY2Nlc3MgUm91dGVyLCBh biBhdHRhY2tlciBpbmplY3RpbmcgZmFsc2UNCj4gUm91dGVyIEFkdmVydGlzZW1lbnQgaW5mb3Jt YXRpb24gaW4gdGhlIGhvbWUgbGluaywgYSBjb21wcm9taXNlZA0KPiBIb21lIEFnZW50LCBldGMu Li4uIGFsbCB0aGVzZSB0aHJlYXRzIHNob3VsZCBiZSByZW1vdmVkIGZyb20gdGhlDQo+IGRvY3Vt ZW50Lg0KPiANCj4gc29tZSBvZiB0aGUgdGhyZWF0cyBhcmUgYWxzbyBub3QgdmFsaWQuDQo+IA0K PiBzcGVjaWZpYyBjb21tZW50cyBmb2xsb3cuDQo+IA0KPiBWaWpheQ0KPiANCj4gDQo+ID4gICAg ICAtIERpc2NhcmQgcmVnaXN0cmF0aW9uIG1lc3NhZ2VzIGZyb20gTVIgdG8gRkENCj4gPiAgICAg ICAgVGhpcyB0aHJlYXQgaXMgYSBzb3J0IG9mIERvUyBhdHRhY2sgdG8gYmxvY2sgbmV0d29yayBj b25uZWN0aXZpdHkgDQo+ID4gICAgICAgIHNlcnZpY2UgdG8gTVIuIFRoZSBhdHRhY2tlciBjb21w cm9taXNlcyB0aGUgRkEsIGFuZCBrZWVwIGRpc2NhcmRpbmcgDQo+ID4gICAgICAgIHRoZSByZWdp c3RyYXRpb24gbWVzc2FnZSBmcm9tIE1SLiBUaGUgcmVzdWx0IG9mIHRoZSBhdHRhY2sgaXMgbm8g DQo+ID4gICAgICAgIGF2YWlsYWJpbGl0eSBvZiBuZXR3b3JrIGNvbm5lY3Rpb24gc2VydmljZSB0 byB0aGUgbW9iaWxlIG5ldHdvcmtzLg0KPiANCj4gcmVtb3ZlIHRoaXMgdGhyZWF0LiBpdCBpcyBu b3QgcmVhbGx5IE5lbW8gc3BlY2lmaWMuIGlmIHRoZSBhY2Nlc3MNCj4gcm91dGVyIGlzIGNvbXBy b21pc2VkLCB0aGVyZSBpc250IG11Y2ggeW91IGNhbiBkbyBhYm91dCBpdC4gdGhlDQo+IGFjY2Vz cyByb3V0ZXIgY291bGQgZGVueSBuZXR3b3JrIGNvbm5lY3Rpb24gdG8gbW9iaWxlIG5vZGVzLCBm aXhlZA0KPiBub2RlcyB3aXRoIHdpcmVsZXNzIGFjY2VzcywgZXRjLg0KPiANCj4gPiANCj4gPiAg ICAgIC0gQ29ycnVwdGVkIHJvdXRpbmcgaW5mb3JtYXRpb24NCj4gPiAgICAgICAgQXR0YWNrZXIg bWF5IHNlbmQgY29ycnVwdGVkIHJvdXRpbmcgaW5mb3JtYXRpb24gdG8gTVIgYW5kIGNhdXNlIA0K PiA+ICAgICAgICBuZXR3b3JrIGluc3RhYmlsaXR5IHN1Y2ggYXMgbmV0d29yayBjb25nZXN0aW9u IG9yIGxvb3BpbmcuIElmIHRoZSANCj4gPiAgICAgICAgTVIgaXMgaW4gdGhlIHZpc2l0ZWQgZG9t YWluLCBpdCB3aWxsIG5vdCByZXNwb25kIHRvIHRoZSB1bnNvbGljaXRlZCANCj4gPiAgICAgICAg UkEuIEJ1dCB3aGlsZSB0aGUgTVIgaXMgaW4gaG9tZSBkb21haW4sIGl0IHN0aWxsIGFjY2VwdHMg dGhlIFJBIA0KPiA+ICAgICAgICBtZXNzYWdlcywgYW5kIG1heSBnZXQgc2NyZXdlZCB1cCB3aXRo IHdyb25nIHJvdXRpbmcgaW5mb3JtYXRpb24uDQo+IA0KPiBpZiBhbiBhdHRhY2tlciBnZXRzIGlu dG8gdGhlIGhvbWUgZG9tYWluIGFuZCBzZW5kcyAiY29ycnVwdGVkIHJvdXRpbmcNCj4gaW5mb3Jt YXRpb24iLCB5b3UgaGF2ZSBhIGxvdCBtb3JlIHNlcmlvdXMgcHJvYmxlbSBhdCBoYW5kLiByZW1v dmUgdGhpcy4NCj4gDQo+IA0KPiA+ICAgICAgIC0gZWF2ZXNkcm9wcGluZy9yZXBsYXkgb2YgbWVz c2FnZXMgYmV0d2VlbiBNUiBhbmQgSEENCj4gPiAgICAgICAgICBBbGwgdGhlIGRhdGEgcGFja2V0 cyBiZXR3ZWVuIE1SIGFuZCBIQSBoYXZlIHRvIGdvIHRocm91Z2ggdGhlIA0KPiA+ICAgICAgICAg IGJpLWRpcmVjdGlvbmFsIHR1bm5lbC4gVGhpcyB0dW5uZWwgc2hvdWxkIGJlIHNlY3VyZWQgYnkg SVBzZWMuIA0KPiA+ICAgICAgICAgIEJ1dCBzb21lIG9mIHRoZSByb3V0aW5nIGluZm9ybWF0aW9u IHRoYXQgbWF5IG5vdCBnbyB0aHJvdWdoIA0KPiA+ICAgICAgICAgIHRoaXMgdHVubmVsIHNob3Vs ZCBiZSBzZWN1cmVkLg0KPiANCj4gdGhpcyBkaWRudCBtYWtlIGEgbG90IG9mIHNlbnNlLg0KPiAN Cj4gPiAgICAgICAtIGVhdmVzZHJvcHBpbmcvcmVwbGF5IG9mIG1lc3NhZ2VzIGJldHdlZW4gTU5O IGFuZCBDTg0KPiA+ICAgICAgICAgIFRoZSBtZXNzYWdlcyBiZXR3ZWVuIE1OTiBhbmQgQ04gYXJl IGdvaW5nIHRocm91Z2ggdGhlIA0KPiA+ICAgICAgICAgIGJpLWRpcmVjdGlvbmFsIHR1bm5lbCwg YnV0IHRoZXJlIGlzIG5vIHByb3RlY3Rpb24gYWdhaW5zdCANCj4gPiAgICAgICAgICBzbmlmZmlu ZyBkYXRhIGJldHdlZW4gTVIgYW5kIE1OTiBvciBiZXR3ZWVuIEhBIGFuZCBDTi4gU28gDQo+ID4g ICAgICAgICAgc2VjdXJpdHkgbWVjaGFuaXNtcyBzaG91bGQgYmUgYXBwbGllZCBvbiB0aGUgcGFy dCBvZiB0aGUgDQo+ID4gICAgICAgICAgcGF0aCB1bmNvdmVyZWQuDQo+IA0KPiBhZ2Fpbiwgbm90 aGluZyBOZW1vIHNwZWNpZmljLiB0aGlzIGlzIGFwcGxpY2FibGUgdG8gYW55IHR3byBub2Rlcw0K PiAod2hldGhlciBtb2JpbGUgb3Igbm90KS4gdGhlIGJlc3Qgc29sdXRpb24gZm9yIHRoaXMgaXMg dG8gaGF2ZQ0KPiBlbmQtdG8tZW5kIHNlY3VyaXR5IGJldHdlZW4gTU5OIGFuZCBDTi4NCj4gDQo+ ID4gDQo+ID4gICAgICAgLSBsb2NhdGlvbiBwcml2YWN5DQo+ID4gICAgICAgICBNb25pdG9yaW5n IGFuZCBhbmFseXppbmcgdGhlIGNoYXJhY3RlcmlzdGljcyBvZiBkYXRhIHRyYWZmaWMgDQo+ID4g ICAgICAgICBhbG9uZyB0aGUgY29tbXVuaWNhdGlvbiBwYXRocyByZXZlYWxzIHNvbWUgaW5mb3Jt YXRpb24gb24gcm91dGluZyANCj4gPiAgICAgICAgIGFuZCBsb2NhdGlvbiBwcml2YWN5Lg0KPiAN Cj4gbm90IE5lbW8gc3BlY2lmaWMuIHBsZWFzZSByZW1vdmUuDQo+IA0KPiA+IC0gTVItSEEgc3Bv b2ZpbmcNCj4gPiAgICAgICAgICAgTVItSEEgaXMgdGhlIHBlcm1hbmVudCBhZGRyZXNzIGFzc2ln bmVkIHN0YXRpY2FsbHkgb3IgDQo+ID4gICAgICAgICAgIGR5bmFtaWNhbGx5IHRvIHRoZSBNUiBi eSBIQS4gTVItSEEgc2hvdWxkIGJlIHVzZWQgZm9yIA0KPiA+ICAgICAgICAgICBpZGVudGlmaWNh dGlvbiBvZiBNUiB3aGlsZSBpdCBpcyBpbiB0aGUgdmlzaXRlZCBkb21haW4uIA0KPiA+ICAgICAg ICAgICBUaGUgY29tcHJvbWlzZWQgTVIgY2FuIHJlZ2lzdGVyIHRvIEZBIHdpdGggYSBzcG9vZmVk IE1SLUhBLCANCj4gPiAgICAgICAgICAgYW5kIHRyeSB0byBjb2xsZWN0IGRhdGEgZGVzdGluYXRl ZCB0byB0aGUgdmljdGltIGFkZHJlc3MuDQo+IA0KPiB0aGlzIGlzIGFuIElQdjQgbW9kZWwuIGlu IE5lbW8sIE1SIGRlYWxzIGRpcmVjdGx5IHdpdGggdGhlIEhBLiBpdCBkb2VzDQo+IG5vIHJlZ2lz dHJhdGlvbiB3aXRoIEZBL0FSLg0KPiANCj4gPiAtIENhY2hlIHBvaXNvbmluZyANCj4gPiAgICAg ICAgICAgVGhlIGNhY2hlIGRhdGEgZm9yIHJvdXRpbmcgdGFibGUgaW4gTVIgY2FuIGJlIGNvcnJ1 cHRlZCB0byANCj4gPiAgICAgICAgICAgc3VidmVydCByb3V0aW5nIHBhdGguIFRoZSBkYXRhIHBh Y2tldCBjb3VsZCBiZSByZWRpcmVjdGVkIG9yIA0KPiA+ICAgICAgICAgICBsb29wZWQgY2F1c2lu ZyBuZXR3b3JrIGluc3RhYmlsaXR5Lg0KPiANCj4gd2hpY2ggIkNhY2hlIj8NCj4gDQo+IA0KPiA+ ICAgIDQuMiBNaXNiZWhhdmlvciBvZiBIQQ0KPiA+ICAgICAgICAgLSBzbmlmZmluZyBvZiB0dW5u ZWxlZCBwYWNrZXQNCj4gPiAgICAgICAgICAgVGhlIElQc2VjIHRyYW5zcG9ydCBtb2RlIHNob3Vs ZCBiZSB1c2VkIGZvciBzZWN1cmluZyB0aGUgDQo+ID4gICAgICAgICAgIHR1bm5lbGVkIHBhY2tl dHMgYmV0d2VlbiBNUiBhbmQgSEEuIFdpdGggdGhlIGNvbXByb21pc2Ugb2YgDQo+ID4gICAgICAg ICAgIHRoZSBIQSwgdGhlIGF0dGFja2VyIGNhbiBzbmlmZiB0aGUgZGVjcnlwdGVkIGRhdGEgcGFj a2V0IA0KPiA+ICAgICAgICAgICBpbiBIQS4NCj4gPiANCj4gPiAgICAgICAgIC0gY29ycnVwdGlv biBvZiBiaW5kaW5nIGNhY2hlDQo+ID4gICAgICAgICAgIEhBIGtlZXBzIG1hbmFnaW5nIHRoZSBC VSBpbmZvcm1hdGlvbiBvbiBiaW5kaW5nIGNhY2hlLiANCj4gPiAgICAgICAgICAgV2l0aCB0aGUg Y29ycnVwdGlvbiBvZiBiaW5kaW5nIGluZm9ybWF0aW9uLCB0aGUgYXR0YWNrZXIgDQo+ID4gICAg ICAgICAgIGNhbiByZWRpcmVjdHMgcGFja2V0cyB0byB3aGVyZSBoZSB3YW50IHRvIGRlbGl2ZXIg dGhlbS4NCj4gDQo+IHJlbW92ZSA0LjIuIEkgZG9udCBleHBlY3QgdGhlIEhBIHRvIG1pc2JlaGF2 ZS4gdGhlcmUgaXNudCBtdWNoIHRoZQ0KPiBOZW1vIHByb3RvY29sIGJhc2ljL2V4dGVuZGVkIGNh biBkbyBpZiB0aGUgSEEgbWlzYmVoYXZlcy4NCj4gDQo+ID4gICAgICAgIA0KPiA+ICAgIDQuNCBE ZW5pYWwgb2YgU2VydmljZQ0KPiA+ICAgICAgICBEZW5pYWwgb2YgU2VydmljZSBhdHRhY2sgaXMg cG9zc2libGUgYWdhaW5zdCBNUiBhbmQgSEEgYnkgZmxvb2RpbmcgDQo+ID4gICAgICAgIEJVIG1l c3NhZ2VzIGFuZCBib2d1cyB0dW5uZWxlZCBwYWNrZXRzLiBUaGUgYXR0YWNrIGNhbiBiZSBtb3Jl IA0KPiA+ICAgICAgICBlZmZlY3RpdmUgd2l0aCBkaXN0cmlidXRlZCBmYWtlIE1ScyBvciBIQXMu ICAgICANCj4gDQo+IEJpbmRpbmcgVXBkYXRlcyBhcmUgcmF0ZS1saW1pdGVkLiB0aGlzIG1heWJl IG5vdCBiZSBwb3NzaWJsZS4NCj4gDQo+ID4gICAgIDUuMSBDb3JydXB0aW9uIG9mIEJpbmRpbmcg Q2FjaGUgYnkgaW5zaWRlIGF0dGFja2VyDQo+IA0KPiB0aGUgZW50aXJlIHNlY3Rpb24gNS4xIG5l ZWRzIHRvIGJlIHJlLXdyaXR0ZW4gd2l0aG91dCBhc3N1bWluZw0KPiBOQVQgb3IgTkFULVBUIG9u IHRoZSBtb2JpbGUgcm91dGVyLg0KPiANCj4gPiAgICAgNS4zIEF0dGFjayB0byBMb2NhdGlvbiBQ cml2YWN5IGJ5IFRyYWZmaWMgQW5hbHlzaXMNCj4gPiAgICAgIA0KPiA+ICAgICAgICAgSW4gdGhl IGJhc2ljIE5FTU8gY29uZmlndXJhdGlvbnMsIGFsbCB0aGUgdHJhZmZpYyBmcm9tIG1vYmlsZSAN Cj4gPiAgICAgICAgIG5ldHdvcmsgYXJlIHN1cHBvc2VkIHRvIGdvIHRocm91Z2ggdGhlIGJpLWRp cmVjdGlvbmFsIHR1bm5lbA0KPiA+ICAgICAgICAgYmV0d2VlbiBNUiBhbmQgSEEuIFRoZSBIQSBj YW4gY29sbGVjdCBhbGwgdGhlIHBhY2tldHMgaW4gDQo+ID4gICAgICAgICBJUC1pbi1JUCB0dW5u ZSwgZGVjYXBzdWxhdGVzIHRoZW0sIGFuZCBmb3J3YXJkcyB0aGVtIHRvIHRoZSBDTnMuDQo+ID4g ICAgICAgICANCj4gPiAgICAgICAgICANCj4gPiAgICAgICAgIHwtLS0tLXwgICAgICAgICB8LS0t LXwgICBJUC1pbi1JUCB0dW5uZWwgIHwtLS0tfCAgICAgICAgIHwtLS0tfA0KPiA+ICAgICAgICAg fCBNTk4gfC0tLS0tLS0tLXwgTVIgfCA9PT09PT09PT09PT09PT09PT0gfCBIQSB8LS0tLS0tLS0t fCBDTiB8DQo+ID4gICAgICAgICB8LS0tLS18ICAgIDEgICAgfC0tLS18ICAgICAgICAgIDIgICAg ICAgICB8LS0tLXwgICAgMyAgICB8LS0tLXwNCj4gPiAgICAgICAgIA0KPiA+ICANCj4gPiAgICAg ICAgIFRoZSBvdXRzaWRlIGF0dGFja2VyIGNhbiBtb25pdG9yIHRoZSB0cmFmZmljIGluIHBhdGgg MiBhbmQgMy4gDQo+IA0KPiBob3cgaXMgdGhlIGF0dGFja2VyIG9uIGJvdGggcGF0aCAyIGFuZCAz Pw0KPiANCj4gPiA2LiAgICAgIFNlY3VyaXR5IFJlcXVpcmVtZW50cyBmb3IgTkVNTw0KPiA+IA0K PiA+ICAgICAgICAgVGhlIGJhc2ljIHN1cHBvcnQgcHJvdG9jb2wgZm9yIE5FTU8gaXMgYmFzZWQg b24gdGhlIE1JUHY2IA0KPiA+ICAgICAgICAgb3BlcmF0aW9ucyBleGNlcHQgdGhlIGJpLWRpcmVj dGlvbmFsIHR1bm5lbCBvcGVyYXRpb25zIGJldHdlZW4gDQo+ID4gICAgICAgICBNUiBhbmQgSEEu IFRoZXJlZm9yZSwgbW9zdCBvZiB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGFyZSANCj4gPiAg ICAgICAgIGFscmVhZHkgYWRkcmVzc2VkIGluIE1JUHY2IFdHIGRvY3VtZW50c1s0XSwgc28gdGhp cyBkcmFmdCBkZXNjcmliZXMgDQo+ID4gICAgICAgICB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRz IG9ubHkgYWdhaW5zdCBuZXcgdGhyZWF0cyBpbiBORU1PLiANCj4gPiAgICAgICAgIFRoZSBmb2xs b3dpbmcgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIFNIT1VMRCBiZSBhZGRyZXNzZWQgaW4gTkVNTyAN Cj4gPiAgICAgICAgIGJhc2ljIGFuZCBleHRlbmRlZCBkb2N1bWVudHMuDQo+ID4gICAgICAgICAN Cj4gPiAgICAgICAgIDYuMSBNUiBTSE9VTEQgY2hlY2sgdGhlIGNvbnRlbnRzIG9mIHRoZSBwYWNr ZXQgZnJvbSBNTk4gaW5zaWRlICwgDQo+ID4gICAgICAgICAgICAgYW5kIGFzc3VyZSB0aGF0IHRo ZSBwYWNrZXQgZG9lcyBub3QgaW5jbHVkZSBmYWtlIGluZm9ybWF0aW9uDQo+ID4gICAgICAgICAg ICAgaW4gdGhlIGNyaXRpY2FsIG1lc3NhZ2VzIHN1Y2ggYXMgQlUsIHByZWZpeCBkaXNjb3Zlcnks IG9yIA0KPiA+ICAgICAgICAgICAgIElDTVAgbWVzc2FnZXMuDQo+IA0KPiB0aGlzIGlzIGEgcmVh bGx5IGJhZCBpZGVhLiB0aGUgb25seSB0aGluZyB0aGUgTVIgc2hvdWxkIGJlIGRvaW5nIGlzDQo+ IGluZ3Jlc3MgZmlsdGVyaW5nIGFuZCBhY2Nlc3MgY29udHJvbCBjaGVjay4gaXQgKnNob3VsZCog bm90IGxvb2sgaW50bw0KPiB0aGUgcGFja2V0IGNvbnRlbnRzLiBhbmQgd2hhdCBpZiB0aGUgTU5O IGlzIHVzaW5nIGVuZC10by1lbmQgRVNQDQo+IGVuY3J5cHRpb24/IHRoZSBNUiBjYW50IHNlZSB0 aGUgcGFja2V0IGV2ZW4gaWYgaXQgd2FudHMgdG8uDQo+IA0KPiANCj4gPiAgICAgICAgIDYuMiBU aGUgSVAtaW4tSVAgZW5jYXBzdWxhdGVkIHBhY2tldCBTSE9VTEQgYmUgYXV0aGVudGljYXRlZCAN Cj4gPiAgICAgICAgICAgICBiZXR3ZWVuIE1SIGFuZCBIQSwgYW5kIHBlci1wYWNrZXQgYXV0aGVu dGljYXRpb24gYXQgTVIgDQo+ID4gICAgICAgICAgICAgU0hPVUxEIGJlIGVuZm9yY2VkLiANCj4g DQo+IGF1dGhlbnRpY2F0ZWQ/IHdoeT8gdGhlIEhBIGFscmVhZHkgbWFrZXMgc3VyZSB0aGF0IHRo ZSBDb0EgKG9uIHRoZQ0KPiBvdXRlciBoZWFkZXIpIGlzIGF1dGhvcml6ZWQgdG8gdHVubmVsIHBh Y2tldHMgZm9yIE1OTidzIGFkZHJlc3MNCj4gKGluIHRoZSBpbm5lciBoZWFkZXIpLiB5b3UgZG9u dCBuZWVkIHBlci1wYWNrZXQgYXV0aGVudGljYXRpb24uDQo+IA0KPiA+ICAgICAgICAgNi4zIFRo ZSBhbW91bnQgb2YgdHJhZmZpYyBmcm9tIE1OTiB0aHJvdWdoIHRoZSBJUC1pbi1JUCB0dW5uZWwg DQo+ID4gICAgICAgICAgICAgU0hPVUxEIGJlIHNlY3VyZWQgdG8gcHJvdGVjdCB0aGUgbG9jYXRp b24gcHJpdmFjeSBhZ2FpbnN0IA0KPiA+ICAgICAgICAgICAgIHRyYWZmaWMgYW5hbHlzaXMuIFRo ZSBhbW91bnQgb2YgdHJhZmZpYyB0aHJvdWdoIElQLWluLUlQIA0KPiA+ICAgICAgICAgICAgIHR1 bm5lbCBNQVkgYmUgc2VjdXJlZCB1c2luZyBleHBhbmRlZCBmaWVsZCBhcyBpbiBJUHNlYyANCj4g PiAgICAgICAgICAgICBFU1BbMTBdLiANCj4gDQo+IHdoZW4gZGlkIGxvY2F0aW9uIHByaXZhY3kg YmVjb21lIGEgc3Ryb25nIHJlcXVpcmVtZW50PyBpZiB0aGUgTU5ODQo+IGlzIGNvbmNlcm5lZCBh Ym91dCB0aGlzLCBpdCBzaG91bGQgYmUgdXNpbmcgUkZDIDMwNDEgYWRkcmVzc2VzLg0KPiANCj4g DQo+IA0KPiA= From nemo-admin@ietf.org Tue Nov 11 12:21:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11015 for ; Tue, 11 Nov 2003 12:21: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 1AJcCK-0002mL-T3; Tue, 11 Nov 2003 12:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcC2-0002lb-HH for nemo@optimus.ietf.org; Tue, 11 Nov 2003 12:20: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 MAA10981 for ; Tue, 11 Nov 2003 12:20:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcC1-0006OU-00 for nemo@ietf.org; Tue, 11 Nov 2003 12:20:41 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AJcC0-0006OD-00 for nemo@ietf.org; Tue, 11 Nov 2003 12:20:40 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hABHJaV22021; Tue, 11 Nov 2003 09:19:36 -0800 X-mProtect: <200311111719> Nokia Silicon Valley Messaging Protection Received: from danira-pool04831.americas.nokia.com (10.241.48.31, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdR6nWlk; Tue, 11 Nov 2003 09:19:35 PST Message-ID: <3FB11A1B.2010307@iprg.nokia.com> Date: Tue, 11 Nov 2003 09:19:23 -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: Souhwan Jung CC: nemo@ietf.org Subject: Re: [nemo] Re: commens on draft-jung-nemo-threat-analysis-01.txt References: <3FADC478.6080200@iprg.nokia.com> <003701c3a7d1$3f3817b0$7f888182@SOUHWANSENSQ> In-Reply-To: <003701c3a7d1$3f3817b0$7f888182@SOUHWANSENSQ> 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 Souhwan Jung wrote: > Anyway, you didn't tell much about the threats in Section 5.1 and 5.2 that could be very critical, we believe. Just doing ingress filtering in MR can not protect the attacks. Can you give some comments on those threats? I will. once you re-write the section eliminating NATs and NAT-PTs. Vijay From exim@www1.ietf.org Tue Nov 11 12:21:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11033 for ; Tue, 11 Nov 2003 12:21: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 1AJcCQ-0002nd-7A for nemo-archive@odin.ietf.org; Tue, 11 Nov 2003 12:21:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABHL6IR010758 for nemo-archive@odin.ietf.org; Tue, 11 Nov 2003 12:21:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcCQ-0002nR-0q for nemo-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 12:21: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 MAA11006 for ; Tue, 11 Nov 2003 12:20:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcCO-0006P9-00 for nemo-web-archive@ietf.org; Tue, 11 Nov 2003 12:21:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJcCO-0006P6-00 for nemo-web-archive@ietf.org; Tue, 11 Nov 2003 12:21:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcCK-0002mL-T3; Tue, 11 Nov 2003 12:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcC2-0002lb-HH for nemo@optimus.ietf.org; Tue, 11 Nov 2003 12:20: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 MAA10981 for ; Tue, 11 Nov 2003 12:20:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcC1-0006OU-00 for nemo@ietf.org; Tue, 11 Nov 2003 12:20:41 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AJcC0-0006OD-00 for nemo@ietf.org; Tue, 11 Nov 2003 12:20:40 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hABHJaV22021; Tue, 11 Nov 2003 09:19:36 -0800 X-mProtect: <200311111719> Nokia Silicon Valley Messaging Protection Received: from danira-pool04831.americas.nokia.com (10.241.48.31, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdR6nWlk; Tue, 11 Nov 2003 09:19:35 PST Message-ID: <3FB11A1B.2010307@iprg.nokia.com> Date: Tue, 11 Nov 2003 09:19:23 -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: Souhwan Jung CC: nemo@ietf.org Subject: Re: [nemo] Re: commens on draft-jung-nemo-threat-analysis-01.txt References: <3FADC478.6080200@iprg.nokia.com> <003701c3a7d1$3f3817b0$7f888182@SOUHWANSENSQ> In-Reply-To: <003701c3a7d1$3f3817b0$7f888182@SOUHWANSENSQ> 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 Souhwan Jung wrote: > Anyway, you didn't tell much about the threats in Section 5.1 and 5.2 that could be very critical, we believe. Just doing ingress filtering in MR can not protect the attacks. Can you give some comments on those threats? I will. once you re-write the section eliminating NATs and NAT-PTs. Vijay From nemo-admin@ietf.org Tue Nov 11 13:19:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14139 for ; Tue, 11 Nov 2003 13:19: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 1AJd6T-0000LG-1u; Tue, 11 Nov 2003 13:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbVa-0005Vy-5c for nemo@optimus.ietf.org; Tue, 11 Nov 2003 11:36: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 LAA08735 for ; Tue, 11 Nov 2003 11:36:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbVZ-0005b0-00 for nemo@ietf.org; Tue, 11 Nov 2003 11:36:49 -0500 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1AJbVY-0005aE-00 for nemo@ietf.org; Tue, 11 Nov 2003 11:36:48 -0500 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id D1ED9689E6 for ; Tue, 11 Nov 2003 11:36:17 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id hABGaDgG016093; Tue, 11 Nov 2003 11:36:13 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.10/8.12.10) with ESMTP id hABGa87J016356; Tue, 11 Nov 2003 11:36:10 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20031111112645.02171de8@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 11 Nov 2003 11:35:13 -0500 To: Thierry Ernst From: William D Ivancic Subject: Re: [nemo] Multihoming and Load sharing. Cc: nemo@ietf.org In-Reply-To: <20031111044540.07973228.ernst@sfc.wide.ad.jp> References: <5.1.1.5.2.20031108092238.02148788@popserve.grc.nasa.gov> <5.1.1.5.2.20031108092238.02148788@popserve.grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hello Theirry, Actually most if not all of the multihoming documents refer to load sharing a policy routing. draft-charbon-nemo-multihoming-evaluation-00 draft-ng-nemo-multihoming-issues-02 draft-paik-nemo-multihoming-problem-00 I agree that load sharing is not a MUST. However it certainly may be desirable as is policy-based routing. I simply want to point out that one should be careful to use such mechanisms wisely least your performance may suffer (or at least not gain as much benefit as thought) and/or you budget may suffer. The later can be much more painful. Will At 04:45 AM 11/11/2003 +0900, Thierry Ernst wrote: >Hi Will, > >When speaking about load-sharing, do you refer to a particular document >? > >As far I know, load-sharing is only described as a potential benefit, >not as something that must be supported. This is a result of being >multihomed, not as pre-requisite. That fully allow it, other mechanisms >are necessary on top of the signaling mechanism. The former may not be >an IETF task. > >Thierry. > > > Whereas I can see configurations where it would be advantageous to allow > > load sharing such as if one has two or three G3 wireless links up all with > > relatively the same cost and bandwidth. > > > > However, IMHO there should definitely be a mechanism to turn load sharing > > off. It would be quite useless and very expensive to load share between > > and WiFi link cost $80.00 per month unlimited service and a 64 kbps > > satellite link costing $1.00 per minute. From exim@www1.ietf.org Tue Nov 11 13:19:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14171 for ; Tue, 11 Nov 2003 13:19: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 1AJd6W-0000N5-Ok for nemo-archive@odin.ietf.org; Tue, 11 Nov 2003 13:19:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABIJ4nr001417 for nemo-archive@odin.ietf.org; Tue, 11 Nov 2003 13:19:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJd6W-0000Ml-AV for nemo-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 13:19: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 NAA14130 for ; Tue, 11 Nov 2003 13:18:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJd6U-0007Sg-00 for nemo-web-archive@ietf.org; Tue, 11 Nov 2003 13:19:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJd6T-0007Sa-00 for nemo-web-archive@ietf.org; Tue, 11 Nov 2003 13:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJd6T-0000LG-1u; Tue, 11 Nov 2003 13:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbVa-0005Vy-5c for nemo@optimus.ietf.org; Tue, 11 Nov 2003 11:36: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 LAA08735 for ; Tue, 11 Nov 2003 11:36:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbVZ-0005b0-00 for nemo@ietf.org; Tue, 11 Nov 2003 11:36:49 -0500 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1AJbVY-0005aE-00 for nemo@ietf.org; Tue, 11 Nov 2003 11:36:48 -0500 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id D1ED9689E6 for ; Tue, 11 Nov 2003 11:36:17 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id hABGaDgG016093; Tue, 11 Nov 2003 11:36:13 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.10/8.12.10) with ESMTP id hABGa87J016356; Tue, 11 Nov 2003 11:36:10 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20031111112645.02171de8@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 11 Nov 2003 11:35:13 -0500 To: Thierry Ernst From: William D Ivancic Subject: Re: [nemo] Multihoming and Load sharing. Cc: nemo@ietf.org In-Reply-To: <20031111044540.07973228.ernst@sfc.wide.ad.jp> References: <5.1.1.5.2.20031108092238.02148788@popserve.grc.nasa.gov> <5.1.1.5.2.20031108092238.02148788@popserve.grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Hello Theirry, Actually most if not all of the multihoming documents refer to load sharing a policy routing. draft-charbon-nemo-multihoming-evaluation-00 draft-ng-nemo-multihoming-issues-02 draft-paik-nemo-multihoming-problem-00 I agree that load sharing is not a MUST. However it certainly may be desirable as is policy-based routing. I simply want to point out that one should be careful to use such mechanisms wisely least your performance may suffer (or at least not gain as much benefit as thought) and/or you budget may suffer. The later can be much more painful. Will At 04:45 AM 11/11/2003 +0900, Thierry Ernst wrote: >Hi Will, > >When speaking about load-sharing, do you refer to a particular document >? > >As far I know, load-sharing is only described as a potential benefit, >not as something that must be supported. This is a result of being >multihomed, not as pre-requisite. That fully allow it, other mechanisms >are necessary on top of the signaling mechanism. The former may not be >an IETF task. > >Thierry. > > > Whereas I can see configurations where it would be advantageous to allow > > load sharing such as if one has two or three G3 wireless links up all with > > relatively the same cost and bandwidth. > > > > However, IMHO there should definitely be a mechanism to turn load sharing > > off. It would be quite useless and very expensive to load share between > > and WiFi link cost $80.00 per month unlimited service and a 64 kbps > > satellite link costing $1.00 per minute. From nemo-admin@ietf.org Tue Nov 11 13:24:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14298 for ; Tue, 11 Nov 2003 13:24: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 1AJdBJ-0000Ze-Fz; Tue, 11 Nov 2003 13: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 1AJdAO-0000YY-6y for nemo@optimus.ietf.org; Tue, 11 Nov 2003 13:23: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 NAA14250 for ; Tue, 11 Nov 2003 13:22:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdAK-0007UN-00 for nemo@ietf.org; Tue, 11 Nov 2003 13:23:00 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AJdAJ-0007UJ-00 for nemo@ietf.org; Tue, 11 Nov 2003 13:23:00 -0500 Received: from kniveton.com (dyn134-83.ietf58.ietf.org [130.129.134.83]) by multihop.net (8.12.10/8.12.9) with ESMTP id hABINEqT033870 for ; Tue, 11 Nov 2003 10:23:15 -0800 (PST) (envelope-from tj@kniveton.com) Message-ID: <3FB14507.6000603@kniveton.com> Date: Tue, 11 Nov 2003 12:22:31 -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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Note takers Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, We have had some problems in the past identifying anyone willing to take minutes during the meeting. The meeting DOES NOT start until we have people who will take notes. We need at least 2-3 people to take notes tomorrow. If you are a somewhat good note taker, and are willing to take notes for the entire meeting, please e-mail me. Thanks, -TJ From exim@www1.ietf.org Tue Nov 11 13:24:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14316 for ; Tue, 11 Nov 2003 13:24: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 1AJdBL-0000ae-Tx for nemo-archive@odin.ietf.org; Tue, 11 Nov 2003 13:24:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABIO3gV002262 for nemo-archive@odin.ietf.org; Tue, 11 Nov 2003 13:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdBL-0000aP-OX for nemo-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 13:24: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 NAA14287 for ; Tue, 11 Nov 2003 13:23:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdBJ-0007VE-00 for nemo-web-archive@ietf.org; Tue, 11 Nov 2003 13:24:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJdBJ-0007VB-00 for nemo-web-archive@ietf.org; Tue, 11 Nov 2003 13:24:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdBJ-0000Ze-Fz; Tue, 11 Nov 2003 13: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 1AJdAO-0000YY-6y for nemo@optimus.ietf.org; Tue, 11 Nov 2003 13:23: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 NAA14250 for ; Tue, 11 Nov 2003 13:22:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdAK-0007UN-00 for nemo@ietf.org; Tue, 11 Nov 2003 13:23:00 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AJdAJ-0007UJ-00 for nemo@ietf.org; Tue, 11 Nov 2003 13:23:00 -0500 Received: from kniveton.com (dyn134-83.ietf58.ietf.org [130.129.134.83]) by multihop.net (8.12.10/8.12.9) with ESMTP id hABINEqT033870 for ; Tue, 11 Nov 2003 10:23:15 -0800 (PST) (envelope-from tj@kniveton.com) Message-ID: <3FB14507.6000603@kniveton.com> Date: Tue, 11 Nov 2003 12:22:31 -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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Note takers Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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, We have had some problems in the past identifying anyone willing to take minutes during the meeting. The meeting DOES NOT start until we have people who will take notes. We need at least 2-3 people to take notes tomorrow. If you are a somewhat good note taker, and are willing to take notes for the entire meeting, please e-mail me. Thanks, -TJ From nemo-admin@ietf.org Tue Nov 11 13:34:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14596 for ; Tue, 11 Nov 2003 13:34: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 1AJdKz-0000sE-IG; Tue, 11 Nov 2003 13: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 1AJdK3-0000rI-Ik for nemo@optimus.ietf.org; Tue, 11 Nov 2003 13: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 NAA14550 for ; Tue, 11 Nov 2003 13:32:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdK1-0007bh-00 for nemo@ietf.org; Tue, 11 Nov 2003 13:33:01 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AJdK0-0007bd-00 for nemo@ietf.org; Tue, 11 Nov 2003 13:33:00 -0500 Received: from kniveton.com (dyn134-83.ietf58.ietf.org [130.129.134.83]) by multihop.net (8.12.10/8.12.9) with ESMTP id hABIXCqT033912; Tue, 11 Nov 2003 10:33:12 -0800 (PST) (envelope-from tj@kniveton.com) Message-ID: <3FB1475C.60707@kniveton.com> Date: Tue, 11 Nov 2003 12:32:28 -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: William D Ivancic CC: Vijay Devarapalli , souhwanj@ssu.ac.kr, nemo@ietf.org Subject: Re: [nemo] commens on draft-jung-nemo-threat-analysis-01.txt References: <5.1.1.5.2.20031111114635.0204be48@popserve.grc.nasa.gov> In-Reply-To: <5.1.1.5.2.20031111114635.0204be48@popserve.grc.nasa.gov> 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 William D Ivancic wrote: > So, the question I have is should the treat analysis only apply to > those threats that are: > > 1) mobile network specific (ipv4 and ipv6)? If so, where does this > document belong ( ipv4 or nemo ?) > > 2) nemo mobile network ipv6 specific? > > 3) nemo basic support specific? > > 4) should the IPv4 treats be sent to ipv4 WG? The document should demonstrate and document threats that are NEMO Basic Support-specific. Any work categorizing IPv4 threats belongs far outside this document, since we have not even had any work done on IPv4 NEMO networks yet. As an aside, a few parties had made verbal commitments to work on IPv4-based Mobile Router solutions within the NEMO group. No one has submitted anything yet. TJ From exim@www1.ietf.org Tue Nov 11 13:34:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14613 for ; Tue, 11 Nov 2003 13:34: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 1AJdL1-0000vN-OR for nemo-archive@odin.ietf.org; Tue, 11 Nov 2003 13:34:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABIY3Y7003547 for nemo-archive@odin.ietf.org; Tue, 11 Nov 2003 13: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 1AJdL1-0000v8-JQ for nemo-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 13:34: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 NAA14581 for ; Tue, 11 Nov 2003 13:33:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdKz-0007ck-00 for nemo-web-archive@ietf.org; Tue, 11 Nov 2003 13:34:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJdKz-0007ch-00 for nemo-web-archive@ietf.org; Tue, 11 Nov 2003 13:34:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdKz-0000sE-IG; Tue, 11 Nov 2003 13: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 1AJdK3-0000rI-Ik for nemo@optimus.ietf.org; Tue, 11 Nov 2003 13: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 NAA14550 for ; Tue, 11 Nov 2003 13:32:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdK1-0007bh-00 for nemo@ietf.org; Tue, 11 Nov 2003 13:33:01 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1AJdK0-0007bd-00 for nemo@ietf.org; Tue, 11 Nov 2003 13:33:00 -0500 Received: from kniveton.com (dyn134-83.ietf58.ietf.org [130.129.134.83]) by multihop.net (8.12.10/8.12.9) with ESMTP id hABIXCqT033912; Tue, 11 Nov 2003 10:33:12 -0800 (PST) (envelope-from tj@kniveton.com) Message-ID: <3FB1475C.60707@kniveton.com> Date: Tue, 11 Nov 2003 12:32:28 -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: William D Ivancic CC: Vijay Devarapalli , souhwanj@ssu.ac.kr, nemo@ietf.org Subject: Re: [nemo] commens on draft-jung-nemo-threat-analysis-01.txt References: <5.1.1.5.2.20031111114635.0204be48@popserve.grc.nasa.gov> In-Reply-To: <5.1.1.5.2.20031111114635.0204be48@popserve.grc.nasa.gov> 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 William D Ivancic wrote: > So, the question I have is should the treat analysis only apply to > those threats that are: > > 1) mobile network specific (ipv4 and ipv6)? If so, where does this > document belong ( ipv4 or nemo ?) > > 2) nemo mobile network ipv6 specific? > > 3) nemo basic support specific? > > 4) should the IPv4 treats be sent to ipv4 WG? The document should demonstrate and document threats that are NEMO Basic Support-specific. Any work categorizing IPv4 threats belongs far outside this document, since we have not even had any work done on IPv4 NEMO networks yet. As an aside, a few parties had made verbal commitments to work on IPv4-based Mobile Router solutions within the NEMO group. No one has submitted anything yet. TJ From nemo-admin@ietf.org Tue Nov 11 14:05:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14140 for ; Tue, 11 Nov 2003 13:19: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 1AJd6T-0000Lc-IY; Tue, 11 Nov 2003 13:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbsT-000123-7S for nemo@optimus.ietf.org; Tue, 11 Nov 2003 12:00: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 MAA10018 for ; Tue, 11 Nov 2003 12:00:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbsR-00063L-00 for nemo@ietf.org; Tue, 11 Nov 2003 12:00:27 -0500 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1AJbsQ-00062w-00 for nemo@ietf.org; Tue, 11 Nov 2003 12:00:26 -0500 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id CFD7B68999 for ; Tue, 11 Nov 2003 11:59:56 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id hABGxugG020137; Tue, 11 Nov 2003 11:59:56 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.10/8.12.10) with ESMTP id hABGxp7J020419; Tue, 11 Nov 2003 11:59:53 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20031111114635.0204be48@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 11 Nov 2003 11:58:54 -0500 To: Vijay Devarapalli From: William D Ivancic Subject: Re: [nemo] commens on draft-jung-nemo-threat-analysis-01.txt Cc: souhwanj@ssu.ac.kr, nemo@ietf.org In-Reply-To: <3FADC478.6080200@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Vijay and Souhwanj, When I read this document I had some of the thoughts that Vijay had. In particular, much of the treats are not "nemo" specific if one assumes "nemo" means ipv6 basic support. Many references are for IPv4 issues. However, these are mobile networks. There are also some issues that are not necessarily mobile network specific; however, they may be more easily exploited in a mobile network. So, the question I have is should the treat analysis only apply to those threats that are: 1) mobile network specific (ipv4 and ipv6)? If so, where does this document belong ( ipv4 or nemo ?) 2) nemo mobile network ipv6 specific? 3) nemo basic support specific? 4) should the IPv4 treats be sent to ipv4 WG? My initial impression is to propose 3 and 4. If we don't bound the problem, it will be difficult to develop a complete document that is useful for development and deployment of basic nemo. If we recharter to address RO later, than a revised or additional treat analysis document would be warranted. Please note, I was not disappointed with the treat document, but though it may be to broad which may limit its usefulness rather than improve its usefulness. Will At 08:37 PM 11/8/2003 -0800, Vijay Devarapalli wrote: >hi, > >I just read through the threat analysis document and sorry to say >I was disappointed with the document. > >many of the threats are not Nemo specific. for example it talks >about a compromised Access Router, an attacker injecting false >Router Advertisement information in the home link, a compromised >Home Agent, etc.... all these threats should be removed from the >document. > >some of the threats are also not valid. > >specific comments follow. > >Vijay > > >> - Discard registration messages from MR to FA >> This threat is a sort of DoS attack to block network >> connectivity service to MR. The attacker compromises the FA, and >> keep discarding the registration message from MR. The result of >> the attack is no availability of network connection service to >> the mobile networks. > >remove this threat. it is not really Nemo specific. if the access >router is compromised, there isnt much you can do about it. the >access router could deny network connection to mobile nodes, fixed >nodes with wireless access, etc. > >> - Corrupted routing information >> Attacker may send corrupted routing information to MR and >> cause network instability such as network congestion or looping. >> If the MR is in the visited domain, it will not respond to the >> unsolicited RA. But while the MR is in home domain, it still >> accepts the RA messages, and may get screwed up with wrong >> routing information. > >if an attacker gets into the home domain and sends "corrupted routing >information", you have a lot more serious problem at hand. remove this. > > >> - eavesdropping/replay of messages between MR and HA >> All the data packets between MR and HA have to go through >> the bi-directional tunnel. This tunnel should be secured by >> IPsec. But some of the routing information that may not go >> through this tunnel should be secured. > >this didnt make a lot of sense. > >> - eavesdropping/replay of messages between MNN and CN >> The messages between MNN and CN are going through >> the bi-directional tunnel, but there is no protection >> against sniffing data between MR and MNN or between HA and CN. >> So security mechanisms should be applied on the part of >> the path uncovered. > >again, nothing Nemo specific. this is applicable to any two nodes >(whether mobile or not). the best solution for this is to have >end-to-end security between MNN and CN. > >> - location privacy >> Monitoring and analyzing the characteristics of data >> traffic along the communication paths reveals some information >> on routing and location privacy. > >not Nemo specific. please remove. > >> - MR-HA spoofing >> MR-HA is the permanent address assigned statically >> or dynamically to the MR by HA. MR-HA should be used >> for identification of MR while it is in the visited >> domain. The compromised MR can register to FA with a spoofed >> MR-HA, and try to collect data destinated to the victim address. > >this is an IPv4 model. in Nemo, MR deals directly with the HA. it does >no registration with FA/AR. > >> - Cache poisoning The cache data for routing table in >> MR can be corrupted to subvert routing path. The data packet >> could be redirected or looped causing network instability. > >which "Cache"? > > >> 4.2 Misbehavior of HA >> - sniffing of tunneled packet >> The IPsec transport mode should be used for securing >> the tunneled packets between MR and HA. With the compromise >> of the HA, the attacker can sniff the decrypted data >> packet in HA. >> - corruption of binding cache >> HA keeps managing the BU information on binding >> cache. With the corruption of binding information, the >> attacker can redirects packets to where he want to deliver them. > >remove 4.2. I dont expect the HA to misbehave. there isnt much the >Nemo protocol basic/extended can do if the HA misbehaves. > >> >> 4.4 Denial of Service >> Denial of Service attack is possible against MR and HA by >> flooding BU messages and bogus tunneled packets. The attack can >> be more effective with distributed fake MRs or HAs. > >Binding Updates are rate-limited. this maybe not be possible. > >> 5.1 Corruption of Binding Cache by inside attacker > >the entire section 5.1 needs to be re-written without assuming >NAT or NAT-PT on the mobile router. > >> 5.3 Attack to Location Privacy by Traffic Analysis >> >> In the basic NEMO configurations, all the traffic from >> mobile network are supposed to go through the bi-directional tunnel >> between MR and HA. The HA can collect all the packets >> in IP-in-IP tunne, decapsulates them, and forwards them to the CNs. >> >> >> |-----| |----| IP-in-IP tunnel |----| |----| >> | MNN |---------| MR | ================== | HA |---------| CN | >> |-----| 1 |----| 2 |----| 3 |----| >> >> >> The outside attacker can monitor the traffic in path 2 and 3. > >how is the attacker on both path 2 and 3? > >>6. Security Requirements for NEMO >> The basic support protocol for NEMO is based on the >> MIPv6 operations except the bi-directional tunnel operations >> between MR and HA. Therefore, most of the security requirements >> are already addressed in MIPv6 WG documents[4], so this draft >> describes the security requirements only against new threats in >> NEMO. The following security requirements SHOULD be addressed in >> NEMO basic and extended documents. >> >> 6.1 MR SHOULD check the contents of the packet from MNN inside >> , and assure that the packet does not include fake information >> in the critical messages such as BU, prefix discovery, >> or ICMP messages. > >this is a really bad idea. the only thing the MR should be doing is >ingress filtering and access control check. it *should* not look into >the packet contents. and what if the MNN is using end-to-end ESP >encryption? the MR cant see the packet even if it wants to. > > >> 6.2 The IP-in-IP encapsulated packet SHOULD be >> authenticated between MR and HA, and per-packet >> authentication at MR SHOULD be enforced. > >authenticated? why? the HA already makes sure that the CoA (on the >outer header) is authorized to tunnel packets for MNN's address >(in the inner header). you dont need per-packet authentication. > >> 6.3 The amount of traffic from MNN through the IP-in-IP >> tunnel SHOULD be secured to protect the location privacy >> against traffic analysis. The amount of traffic through >> IP-in-IP tunnel MAY be secured using expanded field as in >> IPsec ESP[10]. > >when did location privacy become a strong requirement? if the MNN >is concerned about this, it should be using RFC 3041 addresses. > > > From exim@www1.ietf.org Tue Nov 11 14:05:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14169 for ; Tue, 11 Nov 2003 13:19: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 1AJd6W-0000NG-Qy for nemo-archive@odin.ietf.org; Tue, 11 Nov 2003 13:19:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABIJ44Z001432 for nemo-archive@odin.ietf.org; Tue, 11 Nov 2003 13:19:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJd6W-0000Mm-Fq for nemo-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 13:19: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 NAA14132 for ; Tue, 11 Nov 2003 13:18:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJd6U-0007Sd-00 for nemo-web-archive@ietf.org; Tue, 11 Nov 2003 13:19:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJd6T-0007SZ-00 for nemo-web-archive@ietf.org; Tue, 11 Nov 2003 13:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJd6T-0000Lc-IY; Tue, 11 Nov 2003 13:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbsT-000123-7S for nemo@optimus.ietf.org; Tue, 11 Nov 2003 12:00: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 MAA10018 for ; Tue, 11 Nov 2003 12:00:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbsR-00063L-00 for nemo@ietf.org; Tue, 11 Nov 2003 12:00:27 -0500 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1AJbsQ-00062w-00 for nemo@ietf.org; Tue, 11 Nov 2003 12:00:26 -0500 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id CFD7B68999 for ; Tue, 11 Nov 2003 11:59:56 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id hABGxugG020137; Tue, 11 Nov 2003 11:59:56 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.10/8.12.10) with ESMTP id hABGxp7J020419; Tue, 11 Nov 2003 11:59:53 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20031111114635.0204be48@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 11 Nov 2003 11:58:54 -0500 To: Vijay Devarapalli From: William D Ivancic Subject: Re: [nemo] commens on draft-jung-nemo-threat-analysis-01.txt Cc: souhwanj@ssu.ac.kr, nemo@ietf.org In-Reply-To: <3FADC478.6080200@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Vijay and Souhwanj, When I read this document I had some of the thoughts that Vijay had. In particular, much of the treats are not "nemo" specific if one assumes "nemo" means ipv6 basic support. Many references are for IPv4 issues. However, these are mobile networks. There are also some issues that are not necessarily mobile network specific; however, they may be more easily exploited in a mobile network. So, the question I have is should the treat analysis only apply to those threats that are: 1) mobile network specific (ipv4 and ipv6)? If so, where does this document belong ( ipv4 or nemo ?) 2) nemo mobile network ipv6 specific? 3) nemo basic support specific? 4) should the IPv4 treats be sent to ipv4 WG? My initial impression is to propose 3 and 4. If we don't bound the problem, it will be difficult to develop a complete document that is useful for development and deployment of basic nemo. If we recharter to address RO later, than a revised or additional treat analysis document would be warranted. Please note, I was not disappointed with the treat document, but though it may be to broad which may limit its usefulness rather than improve its usefulness. Will At 08:37 PM 11/8/2003 -0800, Vijay Devarapalli wrote: >hi, > >I just read through the threat analysis document and sorry to say >I was disappointed with the document. > >many of the threats are not Nemo specific. for example it talks >about a compromised Access Router, an attacker injecting false >Router Advertisement information in the home link, a compromised >Home Agent, etc.... all these threats should be removed from the >document. > >some of the threats are also not valid. > >specific comments follow. > >Vijay > > >> - Discard registration messages from MR to FA >> This threat is a sort of DoS attack to block network >> connectivity service to MR. The attacker compromises the FA, and >> keep discarding the registration message from MR. The result of >> the attack is no availability of network connection service to >> the mobile networks. > >remove this threat. it is not really Nemo specific. if the access >router is compromised, there isnt much you can do about it. the >access router could deny network connection to mobile nodes, fixed >nodes with wireless access, etc. > >> - Corrupted routing information >> Attacker may send corrupted routing information to MR and >> cause network instability such as network congestion or looping. >> If the MR is in the visited domain, it will not respond to the >> unsolicited RA. But while the MR is in home domain, it still >> accepts the RA messages, and may get screwed up with wrong >> routing information. > >if an attacker gets into the home domain and sends "corrupted routing >information", you have a lot more serious problem at hand. remove this. > > >> - eavesdropping/replay of messages between MR and HA >> All the data packets between MR and HA have to go through >> the bi-directional tunnel. This tunnel should be secured by >> IPsec. But some of the routing information that may not go >> through this tunnel should be secured. > >this didnt make a lot of sense. > >> - eavesdropping/replay of messages between MNN and CN >> The messages between MNN and CN are going through >> the bi-directional tunnel, but there is no protection >> against sniffing data between MR and MNN or between HA and CN. >> So security mechanisms should be applied on the part of >> the path uncovered. > >again, nothing Nemo specific. this is applicable to any two nodes >(whether mobile or not). the best solution for this is to have >end-to-end security between MNN and CN. > >> - location privacy >> Monitoring and analyzing the characteristics of data >> traffic along the communication paths reveals some information >> on routing and location privacy. > >not Nemo specific. please remove. > >> - MR-HA spoofing >> MR-HA is the permanent address assigned statically >> or dynamically to the MR by HA. MR-HA should be used >> for identification of MR while it is in the visited >> domain. The compromised MR can register to FA with a spoofed >> MR-HA, and try to collect data destinated to the victim address. > >this is an IPv4 model. in Nemo, MR deals directly with the HA. it does >no registration with FA/AR. > >> - Cache poisoning The cache data for routing table in >> MR can be corrupted to subvert routing path. The data packet >> could be redirected or looped causing network instability. > >which "Cache"? > > >> 4.2 Misbehavior of HA >> - sniffing of tunneled packet >> The IPsec transport mode should be used for securing >> the tunneled packets between MR and HA. With the compromise >> of the HA, the attacker can sniff the decrypted data >> packet in HA. >> - corruption of binding cache >> HA keeps managing the BU information on binding >> cache. With the corruption of binding information, the >> attacker can redirects packets to where he want to deliver them. > >remove 4.2. I dont expect the HA to misbehave. there isnt much the >Nemo protocol basic/extended can do if the HA misbehaves. > >> >> 4.4 Denial of Service >> Denial of Service attack is possible against MR and HA by >> flooding BU messages and bogus tunneled packets. The attack can >> be more effective with distributed fake MRs or HAs. > >Binding Updates are rate-limited. this maybe not be possible. > >> 5.1 Corruption of Binding Cache by inside attacker > >the entire section 5.1 needs to be re-written without assuming >NAT or NAT-PT on the mobile router. > >> 5.3 Attack to Location Privacy by Traffic Analysis >> >> In the basic NEMO configurations, all the traffic from >> mobile network are supposed to go through the bi-directional tunnel >> between MR and HA. The HA can collect all the packets >> in IP-in-IP tunne, decapsulates them, and forwards them to the CNs. >> >> >> |-----| |----| IP-in-IP tunnel |----| |----| >> | MNN |---------| MR | ================== | HA |---------| CN | >> |-----| 1 |----| 2 |----| 3 |----| >> >> >> The outside attacker can monitor the traffic in path 2 and 3. > >how is the attacker on both path 2 and 3? > >>6. Security Requirements for NEMO >> The basic support protocol for NEMO is based on the >> MIPv6 operations except the bi-directional tunnel operations >> between MR and HA. Therefore, most of the security requirements >> are already addressed in MIPv6 WG documents[4], so this draft >> describes the security requirements only against new threats in >> NEMO. The following security requirements SHOULD be addressed in >> NEMO basic and extended documents. >> >> 6.1 MR SHOULD check the contents of the packet from MNN inside >> , and assure that the packet does not include fake information >> in the critical messages such as BU, prefix discovery, >> or ICMP messages. > >this is a really bad idea. the only thing the MR should be doing is >ingress filtering and access control check. it *should* not look into >the packet contents. and what if the MNN is using end-to-end ESP >encryption? the MR cant see the packet even if it wants to. > > >> 6.2 The IP-in-IP encapsulated packet SHOULD be >> authenticated between MR and HA, and per-packet >> authentication at MR SHOULD be enforced. > >authenticated? why? the HA already makes sure that the CoA (on the >outer header) is authorized to tunnel packets for MNN's address >(in the inner header). you dont need per-packet authentication. > >> 6.3 The amount of traffic from MNN through the IP-in-IP >> tunnel SHOULD be secured to protect the location privacy >> against traffic analysis. The amount of traffic through >> IP-in-IP tunnel MAY be secured using expanded field as in >> IPsec ESP[10]. > >when did location privacy become a strong requirement? if the MNN >is concerned about this, it should be using RFC 3041 addresses. > > > From nemo-admin@ietf.org Tue Nov 11 15:53:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21380 for ; Tue, 11 Nov 2003 15:53: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 1AJfVV-0003ph-9k; Tue, 11 Nov 2003 15:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfUa-0003pD-Lk for nemo@optimus.ietf.org; Tue, 11 Nov 2003 15:52: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 PAA21227 for ; Tue, 11 Nov 2003 15:51:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJfUZ-0001se-00 for nemo@ietf.org; Tue, 11 Nov 2003 15:52:03 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AJfUY-0001sa-00 for nemo@ietf.org; Tue, 11 Nov 2003 15:52:02 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hABKosfZ027236; Tue, 11 Nov 2003 13:50:55 -0700 (MST) Received: from motorola.com ([163.14.20.4]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id hABKotkl030313; Tue, 11 Nov 2003 14:51:00 -0600 Message-ID: <3FB14BAC.5070005@motorola.com> Date: Tue, 11 Nov 2003 21:50: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: vijayd@iprg.nokia.com, souhwanj@ssu.ac.kr, nemo@ietf.org Subject: Re: [nemo] commens on draft-jung-nemo-threat-analysis-01.txt References: <3FADC478.6080200@iprg.nokia.com> <12D4CC22.3000809@motorola.com> <20031111044052.5e3ab93a.ernst@sfc.wide.ad.jp> In-Reply-To: <20031111044052.5e3ab93a.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > However, while Vijay mentioned that some threats in > dtraft-jung-nemo-threat-analysis-01.txt are not specific to NEMO, I > still think it's useful to keep those in mind and the best way is a > written document. Right. > Alex, what you wrote below is very interesting. Why don't you write a > short I-D and get help from other people ? It's good to have a > starting document on the table. Here's a document you ask. I'm going to submit it formatted after the IETF meeting. So, I would like to ask help from other people to help with threat analysis. This document is really in its inceptive phase, I just tried to make it very specific to NEMO. Please remark on the presented threats, or suggest new ones. Or maybe you find the structure is not right, maybe one can change that too. Disclaimer to Souhwan: this is in no way competition, just my way of seeing the threats, thanks for understanding. Alex GBU Internet Draft A. Petrescu Document: draft-petrescu-nemo-threats-00.txt Motorola Expires: May 2004 November 2003 Threats for Basic Network Mobility Support (NEMO threats) Status of this Nemo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes security threats related to the network mobility base protocol (NEMO). It does not present threats of Mobile IPv6. The communication between MR and HA, as well as the forwarding information at HA and nested mobility configurations are considered to be the main sensitive points of the protocol. Existing tools of Mobile IPv6 protection between MN and HA (IPsec), dynamic routing protocol authentication, NEMO prefix table and ingress filtering checks at HA are presented as potential help defending against threats. Table of Contents Status of this Memo................................................i Abstract...........................................................i Conventions Used in this Document..................................1 1. Introduction and Overview.......................................1 X. Interactions between MR and HA.................................. X. Interactions between several MR's of same HA.................... X. MR and HA in different administrative domains................... X. Forwarding Information Updates at HA............................ X. Nested Mobility................................................. X. Other Threats................................................... Acknowledgements................................................... References......................................................... Changes............................................................ Intellectual Property Rights Considerations........................ Authors' Addresses................................................. Copyright Notice................................................... Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 []. X. Introduction and Overview The Network Mobility base protocol [] describes means for a Mobile Router using Mobile IPv6 [] to offer continuous connectivity for a set of hosts and routers inside a moving network, to the Internet. A moving network has a relatively stable internal IP structure and will usually not transit traffic. A Mobile Router implements most functionalities of a Mobile IPv6 Mobile Host with the notable additions of the BU R-bit management and NEMO-specific modes (implicit, explicit network , explicit prefix len). A NEMO Home Agent implements most functionalities of a Mobile IPv6 HA with the notable additions of BU R-bit management, the three previously mentioned modes and, additionally, interactions with its forwarding information (routing table) management. A new mobility behaviour introduced by NEMO with respect to Mobile IPv6 mobility is the "nested" configuration, in which two moving networks served by different Mobile Routers (each with its own Home Agent) attach one under the other. A simpler case of nested mobility appears when one Mobile Host visits a moving network (MH and MR having different Home Agents). While Route Optimization is currently an integral part of the Mobile IPv6 specification for Mobile Hosts, it is not a part of the behaviour of a Mobile Router or of that of a NEMO Home Agent. Thus, this document describes security threats that pertain to: (1) interactions between MR and its HA, (2) interactions between several MR's served by same HA, (3) interactions between MR and HA when they belong to different administrative domain, (4) threats relating to forwarding information updates at HA and, finally, (5) threats related to nested mobility. For the described threats, suggestions are given for possible tools. This document does not describe threats relating to Route Optimization for moving networks, nor threats relating to Mobile IPv6 for hosts, nor other mobility-related threats whose solutions are described by PANA, EAP, AAA and SEND Working Groups. For threats relating to Mobile IPv6 for Mobile Hosts, reader is kindly referred to [], []. For threats relating to access granting and control, or threats of IPv6 behaviour on same-link, please see the above mentioned Working Groups documents. A similar document attempting to describe threats in the NEMO context is []. The current network mobility base specification specifies that all signaling messages between the Mobile Router and the Home Agent MUST be authenticated by IPsec. The use of IPsec to protect Mobile IPv6 signaling messages is described in detail in the HA-MN IPsec specification. Using AH and/or ESP between MR and HA is of paramount importance in order to protect against a wide range of threats. However, other means of protecting communication between MR and HA might be useful in certain cases. A good overview of authentication mechanisms in the Internet can be found in []. X. Interactions between MR and HA Threat on switching between modes: MR sends BU in implicit mode to HA, HA replies back positively, using MNP from external means (not from BU). During this time, the attacker gained knowledge of the MR's Home Addres, sends BU to HA in explicit mode for the same Home Address but a MNP specified in the BU, different than what HA already has. HA replies back positively to MR and switches to explicit mode and a different MNP. Threat is DoS: tunneling data between MR and HA stops, MR is in implicit mode while HA in explicit mode. IPsec protects against this behaviour in that HA will drop the attacker's BU because can't decrypt the received ESP (attacker does not have the keys shared between MR and HA). Threat on location privacy: Location privacy is the desire of a Mobile Host to not reveal, or hide, its current association Care-of Address (its location) - Home Address (its permanent identifier) from an attacker listening on the path between MH and HA. It is not a desire to hide only one address, but the association. It is a problem in that attacker A may have visibility over the Home Address and the Care-of Address of a Binding Update or Binding Acknowledgement between MR and HA even if ESP is used (ESP does not cover the base IPv6 header of the BU whose src field contains the CoA, neither the DO1 header containing the Home Address). It is also a temporality problem for MH in that an attacker on the same visited link as MH may intercept the Binding Request Refresh messages from HA towards MH after the MH has left that visited link, thus deducing that that MH was "located" on that link at a certain point in time. This is not a location privacy problem for LFN behind MR, because all traffic from LFN is encapsulated inside the ESP tunnel between MR and HA; moreover, since LFN only has a Home Address (no CoA) there is actually no association to hide from wily attackers. Masquerading for Denial-of-Service: when attacker needs to send an unreasonably large amount of IP packets to a target without risk of his current address being identified, it could do so by two means. First, it would set the src address of the packets to another address, at random (thus "spoofing" a legitimate address, or "masquerading" as that address). However, the first-hop router might forbid forwarding packets whose source address are not topologically correct at that particular router (ingress filtering). Second, if ingress filtering at the access router is in place, the MH might first encapsulate towards HA, thus tricking the access router; HA decapsulates and "bombs" the actual target by using MH's Home Address as source address. However, the ingress filtering technique is used at the HA as well; Mobile IPv6 requires HA of MH to only forward those packets from MH if the src address of the outer header to match a Care-of Address entry in the BC and the src address in the inner header to match the home address field of the same entry. The NEMO spec goes further in the ingress filtering detail by requiring the Home Address to match a Mobile Network Prefix owned by the Mobile Router. Confidentiality threat: the payload of all IPv6 packets between LFN and CN is encapsulated inside the bidirectional tunnel between MR and HA. An attacker placed in the path between LFN and CN might have visibility over all this traffic. But, if the encapsulating tunnel uses ESP tunnel mode, payload is encrypted, thus hidden. In this respect, MR acts exactly as MH. Authentication threat: the same attacker might modify the payload of data between LFN and CN. But if AH is used, payload is authenticated, thus impossible to modify without LFN and CN noticing it. In this respect too, MR acts as MH. Using AH and/or ESP between MR and HA is of paramount importance in order to protect against a wide range of threats. X. Interactions between several MR's of same HA DoS threat on peer MR: consider a legitimate MR with prefix MNP and an attacker MR with a different prefix, both served by the same HA. Each MR shares a set of keys with HA, and SA's linking the respective Home Addresses and the HA address. The attacker MR could instruct the HA to to add MNP in the binding cache, relating it to its own Home Address (instead of to the legitimate MR's Home Address), thus effectively denying service to the legitimate MR and redirecting the entire traffic to MNP towards the attacker MR. Even if HA uses IPsec, it could not protect against attacker MR's claiming the legitimate MR's MNP. However, the prefix table specified by NEMO associates a MR's Home Address to the MNP that it owns, thus constituting a means for MR to check against attacker MR claiming a prefix it does not actually own. This particular threat applies equally well to Mobile IPv6 for hosts: an attacker MH may demand the HA (with which it holds an SA) to insert a BC entry of its CoA towards the Home Address of a legitimate MH, even if both MH's have respective SA's with that HA. If the threat is solved by Mobile IPv6 for hosts, the method specified by Mobile IPv6 should naturally be reused by NEMO base support too. X. MR and HA in different administrative domains [This is rather tough for me to understand.] It is possible that HA and MR belong to a same administrative domain. It is also possible that HA and MR belong to different administrative domains. In the latter case, there might be important security risks, and routing instability risks. For one, if MR advertises a prefix towards HA, HA accepts it and propagates it upper stream then an important instability in the Internet at large might appear (because MR's prefix is administratively assigned somewhere else, in MR's administrative domain). Second, if HA advertises prefixes towards the mobile network, then routing instability in the mobile network might appear. Because of those two reasons, it might be recommended for MR and HA to forbid the exchange of any routing information (other than Mobile IPv6) when MR and HA belong to different administrative domains. X. Forwarding Information Updates at HA How current routing protocols routers authentify each other, how they lack a concept of "prefix ownership" (see the "address ownership problem" []). How the prefix table might help with this. How routing protocols authentication could be interpreted to solve the potential "prefix ownership" problem. The current base NEMO specification reads: When the Mobile Router is running a dynamic routing protocol as described in section 7, it injects routing update messages into the Home Link. The Home Agent MUST verify that the Mobile Router is allowed to send routing updates before processing the messages and propagating the routing information. X. Nested Mobility DoS threat on TLMR due to too many nested networks: several moving networks may attach one under the other forming a nested aggregation of moving networks. Naturally, the top-level MR will forward traffic of all moving networks attached under it. When the number of levels is large, this may become an overload on the initial expectations of the capabilities of this Mobile Router, thus becoming a DoS attack. It is possible that a MR has a desire to limit the number of moving networks that nest under it; it could use the Tunnel Encapsulation option by setting a limit on the number of levels of mobile networks below it. X. Other Threats Other threats might exist. X. Acknowledgements Threats related to network mobility have been discussed on the NEMO list, whose members are acknowledged here. Particularly relevant threats woven in the threading of this document have been described by (in random order): V. Devarapalli, E. Nordmark, T. Ernst, S. Jung. Authentication mechanisms of routing protocols mentioned by S. M. Corson. More, etc. X. References [] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [] Devarapalli, V., Wakikawa, R., Petrescu, A. and Thubert, P., "Nemo Basic Support Protocol" (work in progress). Internet Draft, IETF. draft-ietf-nemo-basic-support-01.txt. September 2003. [] Johnson, D., Perkins, C. and Arkko, J., "Mobility Support in IPv6" (work in progress). Internet Draft, IETF. draft-ietf-mobileip-ipv6-24.txt. June 2003. [] Arkko, J., Devarapalli, V. and Dupont, F., "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents" (work in progress). Internet Draft, IETF. draft-ietf-mobileip-mipv6-ha-ipsec-06.txt. June 2003. [] Nikander, P., Harkins, D., Patil, B., Roberts, P., Nordmark, E. and Makin, A., "Threat Models introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6" (work in progress). Internet Draft, IETF. draft-team-mobileip-mipv6-sec-reqts-00.txt. December 2001. [] Jung, S., Zhao, F., Wu, F., Kim, H., Sohn, S., "Threat Analysis for NEMO" (work in progress). Internet Draft, IETF. draft-jung-nemo-threat-analysis-01.txt. October 2003. [] Rescorla, E., "A Survey of Authentication Mechanisms" (work in progress). Internet Draft, IETF. draft-rescorla-auth-mech-01.txt. March 2003. [] Nikander, P., "An Address Ownership Problem in IPv6" (work in progress). Internet Draft, IETF. draft-nikander-ipng-address-ownership-00.txt. February 2001. Changes November 2002: revision 00 submitted. Author's Addresses Alexandru Petrescu Motorola Labs Parc les Algorithmes St Aubin Gif-sur-Yvette 91193 France Phone: +33 1 69354827 Alexandru.Petrescu@motorola.com Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Funding for the RFC editor function is currently provided by the Internet Society. From exim@www1.ietf.org Tue Nov 11 15:53:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21406 for ; Tue, 11 Nov 2003 15:53: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 1AJfVb-0003qc-VY for nemo-archive@odin.ietf.org; Tue, 11 Nov 2003 15:53:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABKr7h5014786 for nemo-archive@odin.ietf.org; Tue, 11 Nov 2003 15:53:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfVb-0003qP-OR for nemo-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 15:53: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 PAA21321 for ; Tue, 11 Nov 2003 15:52:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJfVZ-0001ue-00 for nemo-web-archive@ietf.org; Tue, 11 Nov 2003 15:53:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJfVZ-0001ua-00 for nemo-web-archive@ietf.org; Tue, 11 Nov 2003 15:53:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfVV-0003ph-9k; Tue, 11 Nov 2003 15:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfUa-0003pD-Lk for nemo@optimus.ietf.org; Tue, 11 Nov 2003 15:52: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 PAA21227 for ; Tue, 11 Nov 2003 15:51:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJfUZ-0001se-00 for nemo@ietf.org; Tue, 11 Nov 2003 15:52:03 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AJfUY-0001sa-00 for nemo@ietf.org; Tue, 11 Nov 2003 15:52:02 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hABKosfZ027236; Tue, 11 Nov 2003 13:50:55 -0700 (MST) Received: from motorola.com ([163.14.20.4]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id hABKotkl030313; Tue, 11 Nov 2003 14:51:00 -0600 Message-ID: <3FB14BAC.5070005@motorola.com> Date: Tue, 11 Nov 2003 21:50: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: vijayd@iprg.nokia.com, souhwanj@ssu.ac.kr, nemo@ietf.org Subject: Re: [nemo] commens on draft-jung-nemo-threat-analysis-01.txt References: <3FADC478.6080200@iprg.nokia.com> <12D4CC22.3000809@motorola.com> <20031111044052.5e3ab93a.ernst@sfc.wide.ad.jp> In-Reply-To: <20031111044052.5e3ab93a.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > However, while Vijay mentioned that some threats in > dtraft-jung-nemo-threat-analysis-01.txt are not specific to NEMO, I > still think it's useful to keep those in mind and the best way is a > written document. Right. > Alex, what you wrote below is very interesting. Why don't you write a > short I-D and get help from other people ? It's good to have a > starting document on the table. Here's a document you ask. I'm going to submit it formatted after the IETF meeting. So, I would like to ask help from other people to help with threat analysis. This document is really in its inceptive phase, I just tried to make it very specific to NEMO. Please remark on the presented threats, or suggest new ones. Or maybe you find the structure is not right, maybe one can change that too. Disclaimer to Souhwan: this is in no way competition, just my way of seeing the threats, thanks for understanding. Alex GBU Internet Draft A. Petrescu Document: draft-petrescu-nemo-threats-00.txt Motorola Expires: May 2004 November 2003 Threats for Basic Network Mobility Support (NEMO threats) Status of this Nemo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes security threats related to the network mobility base protocol (NEMO). It does not present threats of Mobile IPv6. The communication between MR and HA, as well as the forwarding information at HA and nested mobility configurations are considered to be the main sensitive points of the protocol. Existing tools of Mobile IPv6 protection between MN and HA (IPsec), dynamic routing protocol authentication, NEMO prefix table and ingress filtering checks at HA are presented as potential help defending against threats. Table of Contents Status of this Memo................................................i Abstract...........................................................i Conventions Used in this Document..................................1 1. Introduction and Overview.......................................1 X. Interactions between MR and HA.................................. X. Interactions between several MR's of same HA.................... X. MR and HA in different administrative domains................... X. Forwarding Information Updates at HA............................ X. Nested Mobility................................................. X. Other Threats................................................... Acknowledgements................................................... References......................................................... Changes............................................................ Intellectual Property Rights Considerations........................ Authors' Addresses................................................. Copyright Notice................................................... Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 []. X. Introduction and Overview The Network Mobility base protocol [] describes means for a Mobile Router using Mobile IPv6 [] to offer continuous connectivity for a set of hosts and routers inside a moving network, to the Internet. A moving network has a relatively stable internal IP structure and will usually not transit traffic. A Mobile Router implements most functionalities of a Mobile IPv6 Mobile Host with the notable additions of the BU R-bit management and NEMO-specific modes (implicit, explicit network , explicit prefix len). A NEMO Home Agent implements most functionalities of a Mobile IPv6 HA with the notable additions of BU R-bit management, the three previously mentioned modes and, additionally, interactions with its forwarding information (routing table) management. A new mobility behaviour introduced by NEMO with respect to Mobile IPv6 mobility is the "nested" configuration, in which two moving networks served by different Mobile Routers (each with its own Home Agent) attach one under the other. A simpler case of nested mobility appears when one Mobile Host visits a moving network (MH and MR having different Home Agents). While Route Optimization is currently an integral part of the Mobile IPv6 specification for Mobile Hosts, it is not a part of the behaviour of a Mobile Router or of that of a NEMO Home Agent. Thus, this document describes security threats that pertain to: (1) interactions between MR and its HA, (2) interactions between several MR's served by same HA, (3) interactions between MR and HA when they belong to different administrative domain, (4) threats relating to forwarding information updates at HA and, finally, (5) threats related to nested mobility. For the described threats, suggestions are given for possible tools. This document does not describe threats relating to Route Optimization for moving networks, nor threats relating to Mobile IPv6 for hosts, nor other mobility-related threats whose solutions are described by PANA, EAP, AAA and SEND Working Groups. For threats relating to Mobile IPv6 for Mobile Hosts, reader is kindly referred to [], []. For threats relating to access granting and control, or threats of IPv6 behaviour on same-link, please see the above mentioned Working Groups documents. A similar document attempting to describe threats in the NEMO context is []. The current network mobility base specification specifies that all signaling messages between the Mobile Router and the Home Agent MUST be authenticated by IPsec. The use of IPsec to protect Mobile IPv6 signaling messages is described in detail in the HA-MN IPsec specification. Using AH and/or ESP between MR and HA is of paramount importance in order to protect against a wide range of threats. However, other means of protecting communication between MR and HA might be useful in certain cases. A good overview of authentication mechanisms in the Internet can be found in []. X. Interactions between MR and HA Threat on switching between modes: MR sends BU in implicit mode to HA, HA replies back positively, using MNP from external means (not from BU). During this time, the attacker gained knowledge of the MR's Home Addres, sends BU to HA in explicit mode for the same Home Address but a MNP specified in the BU, different than what HA already has. HA replies back positively to MR and switches to explicit mode and a different MNP. Threat is DoS: tunneling data between MR and HA stops, MR is in implicit mode while HA in explicit mode. IPsec protects against this behaviour in that HA will drop the attacker's BU because can't decrypt the received ESP (attacker does not have the keys shared between MR and HA). Threat on location privacy: Location privacy is the desire of a Mobile Host to not reveal, or hide, its current association Care-of Address (its location) - Home Address (its permanent identifier) from an attacker listening on the path between MH and HA. It is not a desire to hide only one address, but the association. It is a problem in that attacker A may have visibility over the Home Address and the Care-of Address of a Binding Update or Binding Acknowledgement between MR and HA even if ESP is used (ESP does not cover the base IPv6 header of the BU whose src field contains the CoA, neither the DO1 header containing the Home Address). It is also a temporality problem for MH in that an attacker on the same visited link as MH may intercept the Binding Request Refresh messages from HA towards MH after the MH has left that visited link, thus deducing that that MH was "located" on that link at a certain point in time. This is not a location privacy problem for LFN behind MR, because all traffic from LFN is encapsulated inside the ESP tunnel between MR and HA; moreover, since LFN only has a Home Address (no CoA) there is actually no association to hide from wily attackers. Masquerading for Denial-of-Service: when attacker needs to send an unreasonably large amount of IP packets to a target without risk of his current address being identified, it could do so by two means. First, it would set the src address of the packets to another address, at random (thus "spoofing" a legitimate address, or "masquerading" as that address). However, the first-hop router might forbid forwarding packets whose source address are not topologically correct at that particular router (ingress filtering). Second, if ingress filtering at the access router is in place, the MH might first encapsulate towards HA, thus tricking the access router; HA decapsulates and "bombs" the actual target by using MH's Home Address as source address. However, the ingress filtering technique is used at the HA as well; Mobile IPv6 requires HA of MH to only forward those packets from MH if the src address of the outer header to match a Care-of Address entry in the BC and the src address in the inner header to match the home address field of the same entry. The NEMO spec goes further in the ingress filtering detail by requiring the Home Address to match a Mobile Network Prefix owned by the Mobile Router. Confidentiality threat: the payload of all IPv6 packets between LFN and CN is encapsulated inside the bidirectional tunnel between MR and HA. An attacker placed in the path between LFN and CN might have visibility over all this traffic. But, if the encapsulating tunnel uses ESP tunnel mode, payload is encrypted, thus hidden. In this respect, MR acts exactly as MH. Authentication threat: the same attacker might modify the payload of data between LFN and CN. But if AH is used, payload is authenticated, thus impossible to modify without LFN and CN noticing it. In this respect too, MR acts as MH. Using AH and/or ESP between MR and HA is of paramount importance in order to protect against a wide range of threats. X. Interactions between several MR's of same HA DoS threat on peer MR: consider a legitimate MR with prefix MNP and an attacker MR with a different prefix, both served by the same HA. Each MR shares a set of keys with HA, and SA's linking the respective Home Addresses and the HA address. The attacker MR could instruct the HA to to add MNP in the binding cache, relating it to its own Home Address (instead of to the legitimate MR's Home Address), thus effectively denying service to the legitimate MR and redirecting the entire traffic to MNP towards the attacker MR. Even if HA uses IPsec, it could not protect against attacker MR's claiming the legitimate MR's MNP. However, the prefix table specified by NEMO associates a MR's Home Address to the MNP that it owns, thus constituting a means for MR to check against attacker MR claiming a prefix it does not actually own. This particular threat applies equally well to Mobile IPv6 for hosts: an attacker MH may demand the HA (with which it holds an SA) to insert a BC entry of its CoA towards the Home Address of a legitimate MH, even if both MH's have respective SA's with that HA. If the threat is solved by Mobile IPv6 for hosts, the method specified by Mobile IPv6 should naturally be reused by NEMO base support too. X. MR and HA in different administrative domains [This is rather tough for me to understand.] It is possible that HA and MR belong to a same administrative domain. It is also possible that HA and MR belong to different administrative domains. In the latter case, there might be important security risks, and routing instability risks. For one, if MR advertises a prefix towards HA, HA accepts it and propagates it upper stream then an important instability in the Internet at large might appear (because MR's prefix is administratively assigned somewhere else, in MR's administrative domain). Second, if HA advertises prefixes towards the mobile network, then routing instability in the mobile network might appear. Because of those two reasons, it might be recommended for MR and HA to forbid the exchange of any routing information (other than Mobile IPv6) when MR and HA belong to different administrative domains. X. Forwarding Information Updates at HA How current routing protocols routers authentify each other, how they lack a concept of "prefix ownership" (see the "address ownership problem" []). How the prefix table might help with this. How routing protocols authentication could be interpreted to solve the potential "prefix ownership" problem. The current base NEMO specification reads: When the Mobile Router is running a dynamic routing protocol as described in section 7, it injects routing update messages into the Home Link. The Home Agent MUST verify that the Mobile Router is allowed to send routing updates before processing the messages and propagating the routing information. X. Nested Mobility DoS threat on TLMR due to too many nested networks: several moving networks may attach one under the other forming a nested aggregation of moving networks. Naturally, the top-level MR will forward traffic of all moving networks attached under it. When the number of levels is large, this may become an overload on the initial expectations of the capabilities of this Mobile Router, thus becoming a DoS attack. It is possible that a MR has a desire to limit the number of moving networks that nest under it; it could use the Tunnel Encapsulation option by setting a limit on the number of levels of mobile networks below it. X. Other Threats Other threats might exist. X. Acknowledgements Threats related to network mobility have been discussed on the NEMO list, whose members are acknowledged here. Particularly relevant threats woven in the threading of this document have been described by (in random order): V. Devarapalli, E. Nordmark, T. Ernst, S. Jung. Authentication mechanisms of routing protocols mentioned by S. M. Corson. More, etc. X. References [] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [] Devarapalli, V., Wakikawa, R., Petrescu, A. and Thubert, P., "Nemo Basic Support Protocol" (work in progress). Internet Draft, IETF. draft-ietf-nemo-basic-support-01.txt. September 2003. [] Johnson, D., Perkins, C. and Arkko, J., "Mobility Support in IPv6" (work in progress). Internet Draft, IETF. draft-ietf-mobileip-ipv6-24.txt. June 2003. [] Arkko, J., Devarapalli, V. and Dupont, F., "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents" (work in progress). Internet Draft, IETF. draft-ietf-mobileip-mipv6-ha-ipsec-06.txt. June 2003. [] Nikander, P., Harkins, D., Patil, B., Roberts, P., Nordmark, E. and Makin, A., "Threat Models introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6" (work in progress). Internet Draft, IETF. draft-team-mobileip-mipv6-sec-reqts-00.txt. December 2001. [] Jung, S., Zhao, F., Wu, F., Kim, H., Sohn, S., "Threat Analysis for NEMO" (work in progress). Internet Draft, IETF. draft-jung-nemo-threat-analysis-01.txt. October 2003. [] Rescorla, E., "A Survey of Authentication Mechanisms" (work in progress). Internet Draft, IETF. draft-rescorla-auth-mech-01.txt. March 2003. [] Nikander, P., "An Address Ownership Problem in IPv6" (work in progress). Internet Draft, IETF. draft-nikander-ipng-address-ownership-00.txt. February 2001. Changes November 2002: revision 00 submitted. Author's Addresses Alexandru Petrescu Motorola Labs Parc les Algorithmes St Aubin Gif-sur-Yvette 91193 France Phone: +33 1 69354827 Alexandru.Petrescu@motorola.com Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Funding for the RFC editor function is currently provided by the Internet Society. From nemo-admin@ietf.org Tue Nov 11 16:10:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22264 for ; Tue, 11 Nov 2003 16:10: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 1AJfly-0005TM-Lw; Tue, 11 Nov 2003 16:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfli-0005SR-RJ for nemo@optimus.ietf.org; Tue, 11 Nov 2003 16:09:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22241 for ; Tue, 11 Nov 2003 16:09:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJflg-0002Dm-00 for nemo@ietf.org; Tue, 11 Nov 2003 16:09:45 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AJflg-0002Dg-00 for nemo@ietf.org; Tue, 11 Nov 2003 16:09:44 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hABL9dud001302; Tue, 11 Nov 2003 14:09:39 -0700 (MST) Received: from motorola.com ([163.14.20.4]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id hABL9Lkl014381; Tue, 11 Nov 2003 15:09:25 -0600 Message-ID: <3FB14FFF.2000309@motorola.com> Date: Tue, 11 Nov 2003 22:09:19 +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: William D Ivancic , Vijay Devarapalli , souhwanj@ssu.ac.kr, nemo@ietf.org, Hong-Yon Lach Subject: Re: [nemo] commens on draft-jung-nemo-threat-analysis-01.txt References: <5.1.1.5.2.20031111114635.0204be48@popserve.grc.nasa.gov> <3FB1475C.60707@kniveton.com> In-Reply-To: <3FB1475C.60707@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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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 document should demonstrate and document threats that are NEMO > Basic Support-specific. Any work categorizing IPv4 threats belongs > far outside this document, since we have not even had any work done > on IPv4 NEMO networks yet. > > As an aside, a few parties had made verbal commitments to work on > IPv4-based Mobile Router solutions within the NEMO group. No one has > submitted anything yet. Commitments to develop an IPv4-based Mobile Router solutions have been made and at least one has been fulfilled. Submitting a description to the IETF is subject to this WG's interest in having one and subject to committers' needs to satisfy other urgent emergencies. Alex GBU From exim@www1.ietf.org Tue Nov 11 16:10:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22282 for ; Tue, 11 Nov 2003 16:10: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 1AJfm1-0005Uu-FN for nemo-archive@odin.ietf.org; Tue, 11 Nov 2003 16:10:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABLA5ll021077 for nemo-archive@odin.ietf.org; Tue, 11 Nov 2003 16:10:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfm1-0005Ts-3l for nemo-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 16:10: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 QAA22253 for ; Tue, 11 Nov 2003 16:09:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJflz-0002ES-00 for nemo-web-archive@ietf.org; Tue, 11 Nov 2003 16:10:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJflz-0002EP-00 for nemo-web-archive@ietf.org; Tue, 11 Nov 2003 16:10:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfly-0005TM-Lw; Tue, 11 Nov 2003 16:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfli-0005SR-RJ for nemo@optimus.ietf.org; Tue, 11 Nov 2003 16:09:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22241 for ; Tue, 11 Nov 2003 16:09:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJflg-0002Dm-00 for nemo@ietf.org; Tue, 11 Nov 2003 16:09:45 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AJflg-0002Dg-00 for nemo@ietf.org; Tue, 11 Nov 2003 16:09:44 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hABL9dud001302; Tue, 11 Nov 2003 14:09:39 -0700 (MST) Received: from motorola.com ([163.14.20.4]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id hABL9Lkl014381; Tue, 11 Nov 2003 15:09:25 -0600 Message-ID: <3FB14FFF.2000309@motorola.com> Date: Tue, 11 Nov 2003 22:09:19 +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: William D Ivancic , Vijay Devarapalli , souhwanj@ssu.ac.kr, nemo@ietf.org, Hong-Yon Lach Subject: Re: [nemo] commens on draft-jung-nemo-threat-analysis-01.txt References: <5.1.1.5.2.20031111114635.0204be48@popserve.grc.nasa.gov> <3FB1475C.60707@kniveton.com> In-Reply-To: <3FB1475C.60707@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 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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 document should demonstrate and document threats that are NEMO > Basic Support-specific. Any work categorizing IPv4 threats belongs > far outside this document, since we have not even had any work done > on IPv4 NEMO networks yet. > > As an aside, a few parties had made verbal commitments to work on > IPv4-based Mobile Router solutions within the NEMO group. No one has > submitted anything yet. Commitments to develop an IPv4-based Mobile Router solutions have been made and at least one has been fulfilled. Submitting a description to the IETF is subject to this WG's interest in having one and subject to committers' needs to satisfy other urgent emergencies. Alex GBU From nemo-admin@ietf.org Tue Nov 11 22:12:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05649 for ; Tue, 11 Nov 2003 22: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 1AJlQG-0008Tu-T3; Tue, 11 Nov 2003 22:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJlPI-0008Sa-2t for nemo@optimus.ietf.org; Tue, 11 Nov 2003 22:11: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 WAA05604 for ; Tue, 11 Nov 2003 22:10:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJlPE-0007Qx-00 for nemo@ietf.org; Tue, 11 Nov 2003 22:10:56 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1AJlPE-0007Qu-00 for nemo@ietf.org; Tue, 11 Nov 2003 22:10:56 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id hAC3Ajha025133; Tue, 11 Nov 2003 19:10:45 -0800 (PST) Message-ID: <3FB1A4B4.7020306@cs.ucdavis.edu> Date: Tue, 11 Nov 2003 19:10:44 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli , ryuji@sfc.wide.ad.jp, Alexandru.Petrescu@motorola.com, pthubert@cisco.com CC: IETF NEMO WG , wu@cs.ucdavis.edu Subject: Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt References: <1068024404.6779.27.camel@localhost> <3FA93FF0.9060608@iprg.nokia.com> <1068094146.11301.127.camel@localhost> <3FAAC5E7.80205@iprg.nokia.com> In-Reply-To: <3FAAC5E7.80205@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 and others, I appologize for being late in offering comments (finally, got some time to read through the draft). I have one question here, which I hope that you can clarify: - ICMP error message processing within the IP-in-IP tunnel: In rfc2473, > 8. IPv6 Tunnel Error Processing and Reporting > > IPv6 Tunneling follows the general rule that an error detected > during the processing of an IPv6 packet is reported through an > ICMP message to the source of the packet. .... > An error detected by a node inside a tunnel is reported to the > source of the tunnel packet, that is, the tunnel entry-point node. > The ICMP message sent to the tunnel entry-point node has as ICMP > payload the tunnel IPv6 packet that has the original packet as > its payload. > > The cause of a packet error encountered inside a tunnel can be a > problem with: > > (a) the tunnel header, or > (b) the tunnel packet. > > Both tunnel header and tunnel packet problems are reported to the > tunnel entry-point node. > > If a tunnel packet problem is a consequence of a problem with the > original packet, which is the payload of the tunnel packet, then > the problem is also reported to the source of the original packet. > > To report a problem detected inside the tunnel to the source of an > original packet, the tunnel entry point node must relay the ICMP > message received from inside the tunnel to the source of that > original IPv6 packet. First, under NEMO, the MR, as the tunnel end point, might receive the ICMP error message for a IP-in-IP tunneled packet in its tunnel. According to rfc2473, there are a few cases that the MR indeed needs to relay this ICMP message to the MNN (the original source). (My clarification question here is "I assume that nemo inherently and strictly will follow rfc2473 in MR processing of ICMP messages, isn't it?) Second, according to rfc2463 (ICMP for IPv6), the ICMP message should include as much as possible the original packet. Since the ICMP packet is produced within the tunnel, this would mean that the tunnel header as well as the original packet header will both be sent to the MNN (if I read both rfc2473 and rfc2463 correctly). If this is true, then the MNN will have a way (by intentionally injecting a packet toward some CN and causing ICMP errors within the tunnel according rfc2473) to obtain information regarding both the care-of and the current HA addresses (two tunnel end-points). In MIPv6, this is NOT be an issue because MN knows this information already. But, in NEMO, should MNN be exposed (or allowed to expose) to such information? Some of the attacks we are constructing actually need this piece of information. Any comments will be highly appreciated. -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From exim@www1.ietf.org Tue Nov 11 22:12:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05667 for ; Tue, 11 Nov 2003 22:12: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 1AJlQK-0008Uu-Md for nemo-archive@odin.ietf.org; Tue, 11 Nov 2003 22:12:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAC3C4wu032660 for nemo-archive@odin.ietf.org; Tue, 11 Nov 2003 22:12:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJlQK-0008Uh-Gt for nemo-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 22: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 WAA05626 for ; Tue, 11 Nov 2003 22:11:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJlQH-0007RO-00 for nemo-web-archive@ietf.org; Tue, 11 Nov 2003 22:12:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJlQH-0007RL-00 for nemo-web-archive@ietf.org; Tue, 11 Nov 2003 22: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 1AJlQG-0008Tu-T3; Tue, 11 Nov 2003 22:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJlPI-0008Sa-2t for nemo@optimus.ietf.org; Tue, 11 Nov 2003 22:11: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 WAA05604 for ; Tue, 11 Nov 2003 22:10:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJlPE-0007Qx-00 for nemo@ietf.org; Tue, 11 Nov 2003 22:10:56 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1AJlPE-0007Qu-00 for nemo@ietf.org; Tue, 11 Nov 2003 22:10:56 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id hAC3Ajha025133; Tue, 11 Nov 2003 19:10:45 -0800 (PST) Message-ID: <3FB1A4B4.7020306@cs.ucdavis.edu> Date: Tue, 11 Nov 2003 19:10:44 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli , ryuji@sfc.wide.ad.jp, Alexandru.Petrescu@motorola.com, pthubert@cisco.com CC: IETF NEMO WG , wu@cs.ucdavis.edu Subject: Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt References: <1068024404.6779.27.camel@localhost> <3FA93FF0.9060608@iprg.nokia.com> <1068094146.11301.127.camel@localhost> <3FAAC5E7.80205@iprg.nokia.com> In-Reply-To: <3FAAC5E7.80205@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 and others, I appologize for being late in offering comments (finally, got some time to read through the draft). I have one question here, which I hope that you can clarify: - ICMP error message processing within the IP-in-IP tunnel: In rfc2473, > 8. IPv6 Tunnel Error Processing and Reporting > > IPv6 Tunneling follows the general rule that an error detected > during the processing of an IPv6 packet is reported through an > ICMP message to the source of the packet. .... > An error detected by a node inside a tunnel is reported to the > source of the tunnel packet, that is, the tunnel entry-point node. > The ICMP message sent to the tunnel entry-point node has as ICMP > payload the tunnel IPv6 packet that has the original packet as > its payload. > > The cause of a packet error encountered inside a tunnel can be a > problem with: > > (a) the tunnel header, or > (b) the tunnel packet. > > Both tunnel header and tunnel packet problems are reported to the > tunnel entry-point node. > > If a tunnel packet problem is a consequence of a problem with the > original packet, which is the payload of the tunnel packet, then > the problem is also reported to the source of the original packet. > > To report a problem detected inside the tunnel to the source of an > original packet, the tunnel entry point node must relay the ICMP > message received from inside the tunnel to the source of that > original IPv6 packet. First, under NEMO, the MR, as the tunnel end point, might receive the ICMP error message for a IP-in-IP tunneled packet in its tunnel. According to rfc2473, there are a few cases that the MR indeed needs to relay this ICMP message to the MNN (the original source). (My clarification question here is "I assume that nemo inherently and strictly will follow rfc2473 in MR processing of ICMP messages, isn't it?) Second, according to rfc2463 (ICMP for IPv6), the ICMP message should include as much as possible the original packet. Since the ICMP packet is produced within the tunnel, this would mean that the tunnel header as well as the original packet header will both be sent to the MNN (if I read both rfc2473 and rfc2463 correctly). If this is true, then the MNN will have a way (by intentionally injecting a packet toward some CN and causing ICMP errors within the tunnel according rfc2473) to obtain information regarding both the care-of and the current HA addresses (two tunnel end-points). In MIPv6, this is NOT be an issue because MN knows this information already. But, in NEMO, should MNN be exposed (or allowed to expose) to such information? Some of the attacks we are constructing actually need this piece of information. Any comments will be highly appreciated. -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From nemo-admin@ietf.org Wed Nov 12 11:34:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25867 for ; Wed, 12 Nov 2003 11: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 1AJxwP-0005U8-5V; Wed, 12 Nov 2003 11: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 1AJxvv-0005T6-1L for nemo@optimus.ietf.org; Wed, 12 Nov 2003 11:33: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 LAA25797 for ; Wed, 12 Nov 2003 11:33:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJxvt-0001j9-00 for nemo@ietf.org; Wed, 12 Nov 2003 11:33:29 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AJxvt-0001iF-00 for nemo@ietf.org; Wed, 12 Nov 2003 11:33:29 -0500 Received: from huez (dyn133-163.ietf58.ietf.org [130.129.133.163]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 1A9895D0A0 for ; Thu, 13 Nov 2003 01:32:54 +0900 (JST) Date: Thu, 13 Nov 2003 01:32:07 +0900 From: Thierry Ernst To: nemo Message-Id: <20031113013207.0c285774.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO Final Agenda Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit NEMO WG 58th Agenda * Agenda Bashing ............................................................ 5' * NEMO Status and Milestones: Chairs ........................................ 5' * IPR Status - TJ Kniveton................................................... 15' * NEMO Basic Support: Vijay Devarapalli...................................... 15' draft-ietf-nemo-basic-support-01.txt http://people.nokia.net/vijayd/nemo/issues.html * NEMO Basic Support Threat Analysis: Souhwan Jung........................... 15' draft-jung-nemo-threat-analysis-01.txt * NEMO Basic Support Usages: Pascal Thubert.................................. 15' draft-thubert-nemo-usages-00.txt * Inter Home Agents Protocol: Ryuji Wakikawa ................................ 10' draft-wakikawa-mip6-nemo-haha-00.txt * Multihoming: ChanWah ...................................................... 15' draft-ng-nemo-multihoming-issues-02.txt draft-charbon-nemo-multihoming-evaluation-0?.txt draft-paik-nemo-multihoming-problem-00.txt * Test Results from Vehicular Networks: Hon-Yon Lach ........................ 5' draft-lach-nemo-experiments-overdrive-01.txt * Conclusions and Next Steps ................................................ 5' From exim@www1.ietf.org Wed Nov 12 11:34:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25888 for ; Wed, 12 Nov 2003 11:34: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 1AJxwR-0005VR-L7 for nemo-archive@odin.ietf.org; Wed, 12 Nov 2003 11:34:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACGY3Si021161 for nemo-archive@odin.ietf.org; Wed, 12 Nov 2003 11: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 1AJxwR-0005VE-Ez for nemo-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 11:34: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 LAA25848 for ; Wed, 12 Nov 2003 11:33:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJxwQ-0001jq-00 for nemo-web-archive@ietf.org; Wed, 12 Nov 2003 11:34:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJxwQ-0001jn-00 for nemo-web-archive@ietf.org; Wed, 12 Nov 2003 11:34:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJxwP-0005U8-5V; Wed, 12 Nov 2003 11: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 1AJxvv-0005T6-1L for nemo@optimus.ietf.org; Wed, 12 Nov 2003 11:33: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 LAA25797 for ; Wed, 12 Nov 2003 11:33:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJxvt-0001j9-00 for nemo@ietf.org; Wed, 12 Nov 2003 11:33:29 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1AJxvt-0001iF-00 for nemo@ietf.org; Wed, 12 Nov 2003 11:33:29 -0500 Received: from huez (dyn133-163.ietf58.ietf.org [130.129.133.163]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 1A9895D0A0 for ; Thu, 13 Nov 2003 01:32:54 +0900 (JST) Date: Thu, 13 Nov 2003 01:32:07 +0900 From: Thierry Ernst To: nemo Message-Id: <20031113013207.0c285774.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO Final Agenda Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit NEMO WG 58th Agenda * Agenda Bashing ............................................................ 5' * NEMO Status and Milestones: Chairs ........................................ 5' * IPR Status - TJ Kniveton................................................... 15' * NEMO Basic Support: Vijay Devarapalli...................................... 15' draft-ietf-nemo-basic-support-01.txt http://people.nokia.net/vijayd/nemo/issues.html * NEMO Basic Support Threat Analysis: Souhwan Jung........................... 15' draft-jung-nemo-threat-analysis-01.txt * NEMO Basic Support Usages: Pascal Thubert.................................. 15' draft-thubert-nemo-usages-00.txt * Inter Home Agents Protocol: Ryuji Wakikawa ................................ 10' draft-wakikawa-mip6-nemo-haha-00.txt * Multihoming: ChanWah ...................................................... 15' draft-ng-nemo-multihoming-issues-02.txt draft-charbon-nemo-multihoming-evaluation-0?.txt draft-paik-nemo-multihoming-problem-00.txt * Test Results from Vehicular Networks: Hon-Yon Lach ........................ 5' draft-lach-nemo-experiments-overdrive-01.txt * Conclusions and Next Steps ................................................ 5' From nemo-admin@ietf.org Wed Nov 12 11:43:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26466 for ; Wed, 12 Nov 2003 11:43:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJy57-00075Y-9t; Wed, 12 Nov 2003 11: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 1AJy4S-00074F-F3 for nemo@optimus.ietf.org; Wed, 12 Nov 2003 11:42: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 LAA26353 for ; Wed, 12 Nov 2003 11:42:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJy4R-0001um-00 for nemo@ietf.org; Wed, 12 Nov 2003 11:42:19 -0500 Received: from dyn135-227.ietf58.ietf.org ([130.129.135.227] helo=squirrel.psl.com.sg) by ietf-mx with esmtp (Exim 4.12) id 1AJy4Q-0001uP-00 for nemo@ietf.org; Wed, 12 Nov 2003 11:42:18 -0500 Received: by squirrel.psl.com.sg (Postfix, from userid 1000) id 0490B1039904; Thu, 13 Nov 2003 00:41:11 +0800 (SGT) Subject: Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt From: Chan-Wah NG To: "S. Felix Wu" Cc: Vijay Devarapalli , ryuji@sfc.wide.ad.jp, Alexandru Petrescu , Pascal Thubert , IETF NEMO WG In-Reply-To: <3FB1A4B4.7020306@cs.ucdavis.edu> References: <1068024404.6779.27.camel@localhost> <3FA93FF0.9060608@iprg.nokia.com> <1068094146.11301.127.camel@localhost> <3FAAC5E7.80205@iprg.nokia.com> <3FB1A4B4.7020306@cs.ucdavis.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1068655263.1650.26.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 13 Nov 2003 00:41:04 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Felix, Interesting, in fact if I read the problem correctly, it is also a 'problem' (sort-of) in MIPv6 as well. Consider CN in non-optimized mode sending a ill-formed packet that will cause an ICMP error be generated within the HA-MN tunnel, and thus learn information about home-network of the mobile node. (Since according to the text you quoted, the HA must relay the ICMP error to the sender -- CN -- as well) However, having said that, in both cases (i.e. (i) CN is the sender and (ii) LMN/MN is the sender), it is questionable on how this can be achieved, since the 'ill-formed' packet must be constructed such that (a) from the sender to the tunnel entry point, an error will not be detected by forwarding nodes and thus no ICMP error messages will not be generated, and (b) a forwarding node within the path of the tunnel will actually trigger an error due to the inner packet. Like to hear others' view on this. /rgds /cwng On Wed, 2003-11-12 at 11:10, S. Felix Wu wrote: > Hi, Vijay and others, > > I appologize for being late in offering comments (finally, got > some time to read through the draft). I have one question here, > which I hope that you can clarify: > > - ICMP error message processing within the IP-in-IP tunnel: > > In rfc2473, > > > 8. IPv6 Tunnel Error Processing and Reporting > > > > IPv6 Tunneling follows the general rule that an error detected > > during the processing of an IPv6 packet is reported through an > > ICMP message to the source of the packet. > .... > > An error detected by a node inside a tunnel is reported to the > > source of the tunnel packet, that is, the tunnel entry-point node. > > The ICMP message sent to the tunnel entry-point node has as ICMP > > payload the tunnel IPv6 packet that has the original packet as > > its payload. > > > > The cause of a packet error encountered inside a tunnel can be a > > problem with: > > > > (a) the tunnel header, or > > (b) the tunnel packet. > > > > Both tunnel header and tunnel packet problems are reported to the > > tunnel entry-point node. > > > > If a tunnel packet problem is a consequence of a problem with the > > original packet, which is the payload of the tunnel packet, then > > the problem is also reported to the source of the original packet. > > > > To report a problem detected inside the tunnel to the source of an > > original packet, the tunnel entry point node must relay the ICMP > > message received from inside the tunnel to the source of that > > original IPv6 packet. > > First, under NEMO, the MR, as the tunnel end point, might receive the > ICMP error message for a IP-in-IP tunneled packet in its tunnel. > According to rfc2473, there are a few cases that the MR indeed needs > to relay this ICMP message to the MNN (the original source). (My > clarification question here is "I assume that nemo inherently and > strictly will follow rfc2473 in MR processing of ICMP messages, isn't > it?) > > Second, according to rfc2463 (ICMP for IPv6), the ICMP message should > include as much as possible the original packet. Since the ICMP packet > is produced within the tunnel, this would mean that the tunnel header > as well as the original packet header will both be sent to the MNN (if > I read both rfc2473 and rfc2463 correctly). > > If this is true, then the MNN will have a way (by intentionally > injecting a packet toward some CN and causing ICMP errors within the > tunnel according rfc2473) to obtain information regarding both the > care-of and the current HA addresses (two tunnel end-points). > > In MIPv6, this is NOT be an issue because MN knows this information > already. But, in NEMO, should MNN be exposed (or allowed to expose) to > such information? Some of the attacks we are constructing actually need > this piece of information. > > Any comments will be highly appreciated. > -Felix From exim@www1.ietf.org Wed Nov 12 11:43:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26484 for ; Wed, 12 Nov 2003 11:43: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 1AJy5F-00078m-IB for nemo-archive@odin.ietf.org; Wed, 12 Nov 2003 11:43:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACGh9c6027448 for nemo-archive@odin.ietf.org; Wed, 12 Nov 2003 11:43:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJy5F-00078d-Cx for nemo-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 11:43: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 LAA26430 for ; Wed, 12 Nov 2003 11:42:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJy5E-0001wH-00 for nemo-web-archive@ietf.org; Wed, 12 Nov 2003 11:43:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJy5D-0001wD-00 for nemo-web-archive@ietf.org; Wed, 12 Nov 2003 11:43:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJy57-00075Y-9t; Wed, 12 Nov 2003 11: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 1AJy4S-00074F-F3 for nemo@optimus.ietf.org; Wed, 12 Nov 2003 11:42: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 LAA26353 for ; Wed, 12 Nov 2003 11:42:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJy4R-0001um-00 for nemo@ietf.org; Wed, 12 Nov 2003 11:42:19 -0500 Received: from dyn135-227.ietf58.ietf.org ([130.129.135.227] helo=squirrel.psl.com.sg) by ietf-mx with esmtp (Exim 4.12) id 1AJy4Q-0001uP-00 for nemo@ietf.org; Wed, 12 Nov 2003 11:42:18 -0500 Received: by squirrel.psl.com.sg (Postfix, from userid 1000) id 0490B1039904; Thu, 13 Nov 2003 00:41:11 +0800 (SGT) Subject: Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt From: Chan-Wah NG To: "S. Felix Wu" Cc: Vijay Devarapalli , ryuji@sfc.wide.ad.jp, Alexandru Petrescu , Pascal Thubert , IETF NEMO WG In-Reply-To: <3FB1A4B4.7020306@cs.ucdavis.edu> References: <1068024404.6779.27.camel@localhost> <3FA93FF0.9060608@iprg.nokia.com> <1068094146.11301.127.camel@localhost> <3FAAC5E7.80205@iprg.nokia.com> <3FB1A4B4.7020306@cs.ucdavis.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1068655263.1650.26.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 13 Nov 2003 00:41:04 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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 Hello Felix, Interesting, in fact if I read the problem correctly, it is also a 'problem' (sort-of) in MIPv6 as well. Consider CN in non-optimized mode sending a ill-formed packet that will cause an ICMP error be generated within the HA-MN tunnel, and thus learn information about home-network of the mobile node. (Since according to the text you quoted, the HA must relay the ICMP error to the sender -- CN -- as well) However, having said that, in both cases (i.e. (i) CN is the sender and (ii) LMN/MN is the sender), it is questionable on how this can be achieved, since the 'ill-formed' packet must be constructed such that (a) from the sender to the tunnel entry point, an error will not be detected by forwarding nodes and thus no ICMP error messages will not be generated, and (b) a forwarding node within the path of the tunnel will actually trigger an error due to the inner packet. Like to hear others' view on this. /rgds /cwng On Wed, 2003-11-12 at 11:10, S. Felix Wu wrote: > Hi, Vijay and others, > > I appologize for being late in offering comments (finally, got > some time to read through the draft). I have one question here, > which I hope that you can clarify: > > - ICMP error message processing within the IP-in-IP tunnel: > > In rfc2473, > > > 8. IPv6 Tunnel Error Processing and Reporting > > > > IPv6 Tunneling follows the general rule that an error detected > > during the processing of an IPv6 packet is reported through an > > ICMP message to the source of the packet. > .... > > An error detected by a node inside a tunnel is reported to the > > source of the tunnel packet, that is, the tunnel entry-point node. > > The ICMP message sent to the tunnel entry-point node has as ICMP > > payload the tunnel IPv6 packet that has the original packet as > > its payload. > > > > The cause of a packet error encountered inside a tunnel can be a > > problem with: > > > > (a) the tunnel header, or > > (b) the tunnel packet. > > > > Both tunnel header and tunnel packet problems are reported to the > > tunnel entry-point node. > > > > If a tunnel packet problem is a consequence of a problem with the > > original packet, which is the payload of the tunnel packet, then > > the problem is also reported to the source of the original packet. > > > > To report a problem detected inside the tunnel to the source of an > > original packet, the tunnel entry point node must relay the ICMP > > message received from inside the tunnel to the source of that > > original IPv6 packet. > > First, under NEMO, the MR, as the tunnel end point, might receive the > ICMP error message for a IP-in-IP tunneled packet in its tunnel. > According to rfc2473, there are a few cases that the MR indeed needs > to relay this ICMP message to the MNN (the original source). (My > clarification question here is "I assume that nemo inherently and > strictly will follow rfc2473 in MR processing of ICMP messages, isn't > it?) > > Second, according to rfc2463 (ICMP for IPv6), the ICMP message should > include as much as possible the original packet. Since the ICMP packet > is produced within the tunnel, this would mean that the tunnel header > as well as the original packet header will both be sent to the MNN (if > I read both rfc2473 and rfc2463 correctly). > > If this is true, then the MNN will have a way (by intentionally > injecting a packet toward some CN and causing ICMP errors within the > tunnel according rfc2473) to obtain information regarding both the > care-of and the current HA addresses (two tunnel end-points). > > In MIPv6, this is NOT be an issue because MN knows this information > already. But, in NEMO, should MNN be exposed (or allowed to expose) to > such information? Some of the attacks we are constructing actually need > this piece of information. > > Any comments will be highly appreciated. > -Felix From nemo-admin@ietf.org Wed Nov 12 12:51:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29753 for ; Wed, 12 Nov 2003 12:51: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 1AJz8w-0004Ij-G7; Wed, 12 Nov 2003 12: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 1AJz7w-000453-IM for nemo@optimus.ietf.org; Wed, 12 Nov 2003 12:50: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 MAA29615 for ; Wed, 12 Nov 2003 12:49:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJz7u-00035Y-00 for nemo@ietf.org; Wed, 12 Nov 2003 12:49:58 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AJz7t-00035U-00 for nemo@ietf.org; Wed, 12 Nov 2003 12:49:57 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hACHmrfZ012559 for ; Wed, 12 Nov 2003 10:48:55 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hACHnm50007964 for ; Wed, 12 Nov 2003 11:49:49 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id ABAFC2EC95 for ; Wed, 12 Nov 2003 18:49:47 +0100 (CET) Message-ID: <3FB272BB.1010300@motorola.com> Date: Wed, 12 Nov 2003 18:49:47 +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 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:risk LFN sees MR CoA and HA address (was: Last call for draft-ietf-nemo-basic-support-01.txt) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Cwng: > Hello Felix, > > Interesting, in fact if I read the problem correctly, it is also a > 'problem' (sort-of) in MIPv6 as well. Consider CN in non-optimized > mode sending a ill-formed packet that will cause an ICMP error be > generated within the HA-MN tunnel, and thus learn information about > home-network of the mobile node. (Since according to the text you > quoted, the HA must relay the ICMP error to the sender -- CN -- as > well) > > However, having said that, in both cases (i.e. (i) CN is the sender > and (ii) LMN/MN is the sender), it is questionable on how this can be > achieved, since the 'ill-formed' packet must be constructed such > that (a) from the sender to the tunnel entry point, an error will not > be detected by forwarding nodes and thus no ICMP error messages will > not be generated, and (b) a forwarding node within the path of the > tunnel will actually trigger an error due to the inner packet. > > Like to hear others' view on this. If I understand the threat correctly, please correct me if I'm wrong. The attacker is LFN. The protected information is MR's CoA and HA address. The risk is that LFN may gain knowledge of those two addresses. So what? There are other simpler means for LFN to obtain those two addresses: traceroute is but one example, no need to generate badly formatted packets. Also, this is not a "location privacy" problem issue per se (I tried a definition of "location privacy" in the draft I've just sent on this thread). What are the other risks that LFN gaining access to MR's CoA and MR's HA address might involve? Also I think the protection against this risk might lie in AAA, PANA, EAP and even SEND might offer to MR (if MR is the target) to protect against malicious LFN's. I'm also thinking that chewing on this kind of threat might lead to a valuable description, so include it in a document; but also thinking that sending malformed packets to any destination and hoping for a reply back containing valuable information is a part of everything. Look, if an attacker MR could malform a packet, send it to a legitimate MR's HA, obtain in response that HA's secret keys it holds with the legitimate MR, (eventually as a result of attacker nesting under legitimate), then we really have a NEMO threat. Alex GBU From exim@www1.ietf.org Wed Nov 12 12:51:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29767 for ; Wed, 12 Nov 2003 12: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 1AJz8y-0004Jq-Dq for nemo-archive@odin.ietf.org; Wed, 12 Nov 2003 12:51:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACHp4VW016596 for nemo-archive@odin.ietf.org; Wed, 12 Nov 2003 12: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 1AJz8y-0004Jb-7K for nemo-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 12:51: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 MAA29677 for ; Wed, 12 Nov 2003 12:50:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJz8w-00036z-00 for nemo-web-archive@ietf.org; Wed, 12 Nov 2003 12:51:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJz8w-00036w-00 for nemo-web-archive@ietf.org; Wed, 12 Nov 2003 12: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 1AJz8w-0004Ij-G7; Wed, 12 Nov 2003 12: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 1AJz7w-000453-IM for nemo@optimus.ietf.org; Wed, 12 Nov 2003 12:50: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 MAA29615 for ; Wed, 12 Nov 2003 12:49:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJz7u-00035Y-00 for nemo@ietf.org; Wed, 12 Nov 2003 12:49:58 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AJz7t-00035U-00 for nemo@ietf.org; Wed, 12 Nov 2003 12:49:57 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hACHmrfZ012559 for ; Wed, 12 Nov 2003 10:48:55 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hACHnm50007964 for ; Wed, 12 Nov 2003 11:49:49 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id ABAFC2EC95 for ; Wed, 12 Nov 2003 18:49:47 +0100 (CET) Message-ID: <3FB272BB.1010300@motorola.com> Date: Wed, 12 Nov 2003 18:49:47 +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 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:risk LFN sees MR CoA and HA address (was: Last call for draft-ietf-nemo-basic-support-01.txt) Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cwng: > Hello Felix, > > Interesting, in fact if I read the problem correctly, it is also a > 'problem' (sort-of) in MIPv6 as well. Consider CN in non-optimized > mode sending a ill-formed packet that will cause an ICMP error be > generated within the HA-MN tunnel, and thus learn information about > home-network of the mobile node. (Since according to the text you > quoted, the HA must relay the ICMP error to the sender -- CN -- as > well) > > However, having said that, in both cases (i.e. (i) CN is the sender > and (ii) LMN/MN is the sender), it is questionable on how this can be > achieved, since the 'ill-formed' packet must be constructed such > that (a) from the sender to the tunnel entry point, an error will not > be detected by forwarding nodes and thus no ICMP error messages will > not be generated, and (b) a forwarding node within the path of the > tunnel will actually trigger an error due to the inner packet. > > Like to hear others' view on this. If I understand the threat correctly, please correct me if I'm wrong. The attacker is LFN. The protected information is MR's CoA and HA address. The risk is that LFN may gain knowledge of those two addresses. So what? There are other simpler means for LFN to obtain those two addresses: traceroute is but one example, no need to generate badly formatted packets. Also, this is not a "location privacy" problem issue per se (I tried a definition of "location privacy" in the draft I've just sent on this thread). What are the other risks that LFN gaining access to MR's CoA and MR's HA address might involve? Also I think the protection against this risk might lie in AAA, PANA, EAP and even SEND might offer to MR (if MR is the target) to protect against malicious LFN's. I'm also thinking that chewing on this kind of threat might lead to a valuable description, so include it in a document; but also thinking that sending malformed packets to any destination and hoping for a reply back containing valuable information is a part of everything. Look, if an attacker MR could malform a packet, send it to a legitimate MR's HA, obtain in response that HA's secret keys it holds with the legitimate MR, (eventually as a result of attacker nesting under legitimate), then we really have a NEMO threat. Alex GBU From nemo-admin@ietf.org Wed Nov 12 12:56:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29888 for ; Wed, 12 Nov 2003 12:56: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 1AJzDm-0004Tv-4s; Wed, 12 Nov 2003 12: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 1AJzDY-0004T9-R2 for nemo@optimus.ietf.org; Wed, 12 Nov 2003 12:55: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 MAA29857 for ; Wed, 12 Nov 2003 12:55:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJzDW-00039H-00 for nemo@ietf.org; Wed, 12 Nov 2003 12:55:46 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AJzDV-000399-00 for nemo@ietf.org; Wed, 12 Nov 2003 12:55:45 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hACHspE31787; Wed, 12 Nov 2003 09:54:51 -0800 X-mProtect: <200311121754> Nokia Silicon Valley Messaging Protection Received: from danira-pool05084.americas.nokia.com (10.241.50.84, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBm9jSb; Wed, 12 Nov 2003 09:54:50 PST Message-ID: <3FB273DE.5010206@iprg.nokia.com> Date: Wed, 12 Nov 2003 09:54:38 -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: "S. Felix Wu" CC: ryuji@sfc.wide.ad.jp, Alexandru.Petrescu@motorola.com, pthubert@cisco.com, IETF NEMO WG Subject: ICMP Tunnel error processing and reporting( was Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt) References: <1068024404.6779.27.camel@localhost> <3FA93FF0.9060608@iprg.nokia.com> <1068094146.11301.127.camel@localhost> <3FAAC5E7.80205@iprg.nokia.com> <3FB1A4B4.7020306@cs.ucdavis.edu> In-Reply-To: <3FB1A4B4.7020306@cs.ucdavis.edu> 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 good, this is the kind of detailed threat analysis I like to see. S. Felix Wu wrote: > In rfc2473, > > > 8. IPv6 Tunnel Error Processing and Reporting > > > > IPv6 Tunneling follows the general rule that an error detected > > during the processing of an IPv6 packet is reported through an > > ICMP message to the source of the packet. > .... > > An error detected by a node inside a tunnel is reported to the > > source of the tunnel packet, that is, the tunnel entry-point node. > > The ICMP message sent to the tunnel entry-point node has as ICMP > > payload the tunnel IPv6 packet that has the original packet as > > its payload. > > > > The cause of a packet error encountered inside a tunnel can be a > > problem with: > > > > (a) the tunnel header, or > > (b) the tunnel packet. > > > > Both tunnel header and tunnel packet problems are reported to the > > tunnel entry-point node. > > > > If a tunnel packet problem is a consequence of a problem with the > > original packet, which is the payload of the tunnel packet, then > > the problem is also reported to the source of the original packet. > > > > To report a problem detected inside the tunnel to the source of an > > original packet, the tunnel entry point node must relay the ICMP > > message received from inside the tunnel to the source of that > > original IPv6 packet. > > First, under NEMO, the MR, as the tunnel end point, might receive the > ICMP error message for a IP-in-IP tunneled packet in its tunnel. > According to rfc2473, there are a few cases that the MR indeed needs > to relay this ICMP message to the MNN (the original source). (My > clarification question here is "I assume that nemo inherently and > strictly will follow rfc2473 in MR processing of ICMP messages, isn't > it?) yes, of course. unless we see a problem. > > Second, according to rfc2463 (ICMP for IPv6), the ICMP message should > include as much as possible the original packet. Since the ICMP packet > is produced within the tunnel, this would mean that the tunnel header > as well as the original packet header will both be sent to the MNN (if > I read both rfc2473 and rfc2463 correctly). I am missing something here.... if there is a problem with the outer header, the response goes back to the MR. the MNN will not get the ICMP error. if there is a problem with the inner header, it means the Home Agent has already stripped the outer header and some node (could be the Home Agent also) is trying processing the inner packet. in this case, the nodes send the ICMP error back to the MNN. the Home Agent, when it tries to send the ICMP error back to the MNN, tunnels the error to the MR. the MR removes the outer tunnel headers and forwards the ICMP error alone to the MNN. the MNN will not get information about the tunnel between the MR and the HA. let me know what I am missing. Vijay > > If this is true, then the MNN will have a way (by intentionally > injecting a packet toward some CN and causing ICMP errors within the > tunnel according rfc2473) to obtain information regarding both the > care-of and the current HA addresses (two tunnel end-points). > > In MIPv6, this is NOT be an issue because MN knows this information > already. But, in NEMO, should MNN be exposed (or allowed to expose) to > such information? Some of the attacks we are constructing actually need > this piece of information. > > Any comments will be highly appreciated. > -Felix > From exim@www1.ietf.org Wed Nov 12 12:56:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29906 for ; Wed, 12 Nov 2003 12:56: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 1AJzDo-0004Uu-4I for nemo-archive@odin.ietf.org; Wed, 12 Nov 2003 12:56:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACHu4Tb017282 for nemo-archive@odin.ietf.org; Wed, 12 Nov 2003 12:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJzDn-0004Uf-V4 for nemo-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 12: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 MAA29867 for ; Wed, 12 Nov 2003 12:55:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJzDm-00039c-00 for nemo-web-archive@ietf.org; Wed, 12 Nov 2003 12:56:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJzDl-00039Z-00 for nemo-web-archive@ietf.org; Wed, 12 Nov 2003 12: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 1AJzDm-0004Tv-4s; Wed, 12 Nov 2003 12: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 1AJzDY-0004T9-R2 for nemo@optimus.ietf.org; Wed, 12 Nov 2003 12:55: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 MAA29857 for ; Wed, 12 Nov 2003 12:55:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJzDW-00039H-00 for nemo@ietf.org; Wed, 12 Nov 2003 12:55:46 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AJzDV-000399-00 for nemo@ietf.org; Wed, 12 Nov 2003 12:55:45 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hACHspE31787; Wed, 12 Nov 2003 09:54:51 -0800 X-mProtect: <200311121754> Nokia Silicon Valley Messaging Protection Received: from danira-pool05084.americas.nokia.com (10.241.50.84, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBm9jSb; Wed, 12 Nov 2003 09:54:50 PST Message-ID: <3FB273DE.5010206@iprg.nokia.com> Date: Wed, 12 Nov 2003 09:54:38 -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: "S. Felix Wu" CC: ryuji@sfc.wide.ad.jp, Alexandru.Petrescu@motorola.com, pthubert@cisco.com, IETF NEMO WG Subject: ICMP Tunnel error processing and reporting( was Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt) References: <1068024404.6779.27.camel@localhost> <3FA93FF0.9060608@iprg.nokia.com> <1068094146.11301.127.camel@localhost> <3FAAC5E7.80205@iprg.nokia.com> <3FB1A4B4.7020306@cs.ucdavis.edu> In-Reply-To: <3FB1A4B4.7020306@cs.ucdavis.edu> 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 good, this is the kind of detailed threat analysis I like to see. S. Felix Wu wrote: > In rfc2473, > > > 8. IPv6 Tunnel Error Processing and Reporting > > > > IPv6 Tunneling follows the general rule that an error detected > > during the processing of an IPv6 packet is reported through an > > ICMP message to the source of the packet. > .... > > An error detected by a node inside a tunnel is reported to the > > source of the tunnel packet, that is, the tunnel entry-point node. > > The ICMP message sent to the tunnel entry-point node has as ICMP > > payload the tunnel IPv6 packet that has the original packet as > > its payload. > > > > The cause of a packet error encountered inside a tunnel can be a > > problem with: > > > > (a) the tunnel header, or > > (b) the tunnel packet. > > > > Both tunnel header and tunnel packet problems are reported to the > > tunnel entry-point node. > > > > If a tunnel packet problem is a consequence of a problem with the > > original packet, which is the payload of the tunnel packet, then > > the problem is also reported to the source of the original packet. > > > > To report a problem detected inside the tunnel to the source of an > > original packet, the tunnel entry point node must relay the ICMP > > message received from inside the tunnel to the source of that > > original IPv6 packet. > > First, under NEMO, the MR, as the tunnel end point, might receive the > ICMP error message for a IP-in-IP tunneled packet in its tunnel. > According to rfc2473, there are a few cases that the MR indeed needs > to relay this ICMP message to the MNN (the original source). (My > clarification question here is "I assume that nemo inherently and > strictly will follow rfc2473 in MR processing of ICMP messages, isn't > it?) yes, of course. unless we see a problem. > > Second, according to rfc2463 (ICMP for IPv6), the ICMP message should > include as much as possible the original packet. Since the ICMP packet > is produced within the tunnel, this would mean that the tunnel header > as well as the original packet header will both be sent to the MNN (if > I read both rfc2473 and rfc2463 correctly). I am missing something here.... if there is a problem with the outer header, the response goes back to the MR. the MNN will not get the ICMP error. if there is a problem with the inner header, it means the Home Agent has already stripped the outer header and some node (could be the Home Agent also) is trying processing the inner packet. in this case, the nodes send the ICMP error back to the MNN. the Home Agent, when it tries to send the ICMP error back to the MNN, tunnels the error to the MR. the MR removes the outer tunnel headers and forwards the ICMP error alone to the MNN. the MNN will not get information about the tunnel between the MR and the HA. let me know what I am missing. Vijay > > If this is true, then the MNN will have a way (by intentionally > injecting a packet toward some CN and causing ICMP errors within the > tunnel according rfc2473) to obtain information regarding both the > care-of and the current HA addresses (two tunnel end-points). > > In MIPv6, this is NOT be an issue because MN knows this information > already. But, in NEMO, should MNN be exposed (or allowed to expose) to > such information? Some of the attacks we are constructing actually need > this piece of information. > > Any comments will be highly appreciated. > -Felix > From nemo-admin@ietf.org Wed Nov 12 13:02:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00090 for ; Wed, 12 Nov 2003 13:02:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJzJa-0004ic-W5; Wed, 12 Nov 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 1AJzJG-0004i5-Ff for nemo@optimus.ietf.org; Wed, 12 Nov 2003 13:01: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 NAA00064 for ; Wed, 12 Nov 2003 13:01:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJzJE-0003Es-00 for nemo@ietf.org; Wed, 12 Nov 2003 13:01:40 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1AJzJD-0003Ek-00 for nemo@ietf.org; Wed, 12 Nov 2003 13:01:39 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id hACHxfha027355; Wed, 12 Nov 2003 09:59:42 -0800 (PST) Message-ID: <3FB2750D.2030801@cs.ucdavis.edu> Date: Wed, 12 Nov 2003 09:59:41 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah NG CC: Vijay Devarapalli , ryuji@sfc.wide.ad.jp, Alexandru Petrescu , Pascal Thubert , IETF NEMO WG Subject: Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt References: <1068024404.6779.27.camel@localhost> <3FA93FF0.9060608@iprg.nokia.com> <1068094146.11301.127.camel@localhost> <3FAAC5E7.80205@iprg.nokia.com> <3FB1A4B4.7020306@cs.ucdavis.edu> <1068655263.1650.26.camel@squirrel> In-Reply-To: <1068655263.1650.26.camel@squirrel> 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, Chan-Wah and others, Thanks for the comments. I re-readed rfc2473 and found the following text: Fig.7 path #2 and Fig.8 (b) - The IPv6 tunnel error input decapsulates the tunnel IPv6 packet, which is the ICMPv6 message payload, obtaining the original packet, and thus the original headers and dispatches the "internal error code", the source address from the original packet header, and the original packet, down to the error report block of the protocol identified by the Next Header field in the tunnel header immediately preceding the original packet in the ICMP message payload. It looks to me at this point, according to the rfc, only the "original packet" part of the ICMP message should be relayed to the original source (which is MNN or CN, as you mentioned). So, we should not have any concerns in MIPv6 or NEMO if the implementation of rfc2473 is correct. Thanks. -Felix Chan-Wah NG wrote: > Hello Felix, > > Interesting, in fact if I read the problem correctly, it is also a > 'problem' (sort-of) in MIPv6 as well. Consider CN in non-optimized mode > sending a ill-formed packet that will cause an ICMP error be generated > within the HA-MN tunnel, and thus learn information about home-network > of the mobile node. (Since according to the text you quoted, the HA must > relay the ICMP error to the sender -- CN -- as well) > > However, having said that, in both cases (i.e. (i) CN is the sender and > (ii) LMN/MN is the sender), it is questionable on how this can be > achieved, since the 'ill-formed' packet must be constructed such that > (a) from the sender to the tunnel entry point, an error will not be > detected by forwarding nodes and thus no ICMP error messages will not be > generated, and (b) a forwarding node within the path of the tunnel will > actually trigger an error due to the inner packet. > > Like to hear others' view on this. > > /rgds > /cwng > > On Wed, 2003-11-12 at 11:10, S. Felix Wu wrote: > >>Hi, Vijay and others, >> >>I appologize for being late in offering comments (finally, got >>some time to read through the draft). I have one question here, >>which I hope that you can clarify: >> >>- ICMP error message processing within the IP-in-IP tunnel: >> >>In rfc2473, >> >> > 8. IPv6 Tunnel Error Processing and Reporting >> > >> > IPv6 Tunneling follows the general rule that an error detected >> > during the processing of an IPv6 packet is reported through an >> > ICMP message to the source of the packet. >>.... >> > An error detected by a node inside a tunnel is reported to the >> > source of the tunnel packet, that is, the tunnel entry-point node. >> > The ICMP message sent to the tunnel entry-point node has as ICMP >> > payload the tunnel IPv6 packet that has the original packet as >> > its payload. >> > >> > The cause of a packet error encountered inside a tunnel can be a >> > problem with: >> > >> > (a) the tunnel header, or >> > (b) the tunnel packet. >> > >> > Both tunnel header and tunnel packet problems are reported to the >> > tunnel entry-point node. >> > >> > If a tunnel packet problem is a consequence of a problem with the >> > original packet, which is the payload of the tunnel packet, then >> > the problem is also reported to the source of the original packet. >> > >> > To report a problem detected inside the tunnel to the source of an >> > original packet, the tunnel entry point node must relay the ICMP >> > message received from inside the tunnel to the source of that >> > original IPv6 packet. >> >>First, under NEMO, the MR, as the tunnel end point, might receive the >>ICMP error message for a IP-in-IP tunneled packet in its tunnel. >>According to rfc2473, there are a few cases that the MR indeed needs >>to relay this ICMP message to the MNN (the original source). (My >>clarification question here is "I assume that nemo inherently and >>strictly will follow rfc2473 in MR processing of ICMP messages, isn't >>it?) >> >>Second, according to rfc2463 (ICMP for IPv6), the ICMP message should >>include as much as possible the original packet. Since the ICMP packet >>is produced within the tunnel, this would mean that the tunnel header >>as well as the original packet header will both be sent to the MNN (if >>I read both rfc2473 and rfc2463 correctly). >> >>If this is true, then the MNN will have a way (by intentionally >>injecting a packet toward some CN and causing ICMP errors within the >>tunnel according rfc2473) to obtain information regarding both the >>care-of and the current HA addresses (two tunnel end-points). >> >>In MIPv6, this is NOT be an issue because MN knows this information >>already. But, in NEMO, should MNN be exposed (or allowed to expose) to >>such information? Some of the attacks we are constructing actually need >>this piece of information. >> >>Any comments will be highly appreciated. >>-Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From exim@www1.ietf.org Wed Nov 12 13:02:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00106 for ; Wed, 12 Nov 2003 13:02: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 1AJzJd-0004jV-Ru for nemo-archive@odin.ietf.org; Wed, 12 Nov 2003 13:02:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACI25qo018193 for nemo-archive@odin.ietf.org; Wed, 12 Nov 2003 13:02:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJzJd-0004jM-JH for nemo-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 13:02: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 NAA00080 for ; Wed, 12 Nov 2003 13:01:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJzJb-0003F6-00 for nemo-web-archive@ietf.org; Wed, 12 Nov 2003 13:02:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJzJb-0003F3-00 for nemo-web-archive@ietf.org; Wed, 12 Nov 2003 13:02:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJzJa-0004ic-W5; Wed, 12 Nov 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 1AJzJG-0004i5-Ff for nemo@optimus.ietf.org; Wed, 12 Nov 2003 13:01: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 NAA00064 for ; Wed, 12 Nov 2003 13:01:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJzJE-0003Es-00 for nemo@ietf.org; Wed, 12 Nov 2003 13:01:40 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1AJzJD-0003Ek-00 for nemo@ietf.org; Wed, 12 Nov 2003 13:01:39 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id hACHxfha027355; Wed, 12 Nov 2003 09:59:42 -0800 (PST) Message-ID: <3FB2750D.2030801@cs.ucdavis.edu> Date: Wed, 12 Nov 2003 09:59:41 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chan-Wah NG CC: Vijay Devarapalli , ryuji@sfc.wide.ad.jp, Alexandru Petrescu , Pascal Thubert , IETF NEMO WG Subject: Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt References: <1068024404.6779.27.camel@localhost> <3FA93FF0.9060608@iprg.nokia.com> <1068094146.11301.127.camel@localhost> <3FAAC5E7.80205@iprg.nokia.com> <3FB1A4B4.7020306@cs.ucdavis.edu> <1068655263.1650.26.camel@squirrel> In-Reply-To: <1068655263.1650.26.camel@squirrel> 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, Chan-Wah and others, Thanks for the comments. I re-readed rfc2473 and found the following text: Fig.7 path #2 and Fig.8 (b) - The IPv6 tunnel error input decapsulates the tunnel IPv6 packet, which is the ICMPv6 message payload, obtaining the original packet, and thus the original headers and dispatches the "internal error code", the source address from the original packet header, and the original packet, down to the error report block of the protocol identified by the Next Header field in the tunnel header immediately preceding the original packet in the ICMP message payload. It looks to me at this point, according to the rfc, only the "original packet" part of the ICMP message should be relayed to the original source (which is MNN or CN, as you mentioned). So, we should not have any concerns in MIPv6 or NEMO if the implementation of rfc2473 is correct. Thanks. -Felix Chan-Wah NG wrote: > Hello Felix, > > Interesting, in fact if I read the problem correctly, it is also a > 'problem' (sort-of) in MIPv6 as well. Consider CN in non-optimized mode > sending a ill-formed packet that will cause an ICMP error be generated > within the HA-MN tunnel, and thus learn information about home-network > of the mobile node. (Since according to the text you quoted, the HA must > relay the ICMP error to the sender -- CN -- as well) > > However, having said that, in both cases (i.e. (i) CN is the sender and > (ii) LMN/MN is the sender), it is questionable on how this can be > achieved, since the 'ill-formed' packet must be constructed such that > (a) from the sender to the tunnel entry point, an error will not be > detected by forwarding nodes and thus no ICMP error messages will not be > generated, and (b) a forwarding node within the path of the tunnel will > actually trigger an error due to the inner packet. > > Like to hear others' view on this. > > /rgds > /cwng > > On Wed, 2003-11-12 at 11:10, S. Felix Wu wrote: > >>Hi, Vijay and others, >> >>I appologize for being late in offering comments (finally, got >>some time to read through the draft). I have one question here, >>which I hope that you can clarify: >> >>- ICMP error message processing within the IP-in-IP tunnel: >> >>In rfc2473, >> >> > 8. IPv6 Tunnel Error Processing and Reporting >> > >> > IPv6 Tunneling follows the general rule that an error detected >> > during the processing of an IPv6 packet is reported through an >> > ICMP message to the source of the packet. >>.... >> > An error detected by a node inside a tunnel is reported to the >> > source of the tunnel packet, that is, the tunnel entry-point node. >> > The ICMP message sent to the tunnel entry-point node has as ICMP >> > payload the tunnel IPv6 packet that has the original packet as >> > its payload. >> > >> > The cause of a packet error encountered inside a tunnel can be a >> > problem with: >> > >> > (a) the tunnel header, or >> > (b) the tunnel packet. >> > >> > Both tunnel header and tunnel packet problems are reported to the >> > tunnel entry-point node. >> > >> > If a tunnel packet problem is a consequence of a problem with the >> > original packet, which is the payload of the tunnel packet, then >> > the problem is also reported to the source of the original packet. >> > >> > To report a problem detected inside the tunnel to the source of an >> > original packet, the tunnel entry point node must relay the ICMP >> > message received from inside the tunnel to the source of that >> > original IPv6 packet. >> >>First, under NEMO, the MR, as the tunnel end point, might receive the >>ICMP error message for a IP-in-IP tunneled packet in its tunnel. >>According to rfc2473, there are a few cases that the MR indeed needs >>to relay this ICMP message to the MNN (the original source). (My >>clarification question here is "I assume that nemo inherently and >>strictly will follow rfc2473 in MR processing of ICMP messages, isn't >>it?) >> >>Second, according to rfc2463 (ICMP for IPv6), the ICMP message should >>include as much as possible the original packet. Since the ICMP packet >>is produced within the tunnel, this would mean that the tunnel header >>as well as the original packet header will both be sent to the MNN (if >>I read both rfc2473 and rfc2463 correctly). >> >>If this is true, then the MNN will have a way (by intentionally >>injecting a packet toward some CN and causing ICMP errors within the >>tunnel according rfc2473) to obtain information regarding both the >>care-of and the current HA addresses (two tunnel end-points). >> >>In MIPv6, this is NOT be an issue because MN knows this information >>already. But, in NEMO, should MNN be exposed (or allowed to expose) to >>such information? Some of the attacks we are constructing actually need >>this piece of information. >> >>Any comments will be highly appreciated. >>-Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From nemo-admin@ietf.org Wed Nov 12 14:33:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03265 for ; Wed, 12 Nov 2003 14:33: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 1AK0jd-00017X-Ma; Wed, 12 Nov 2003 14:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK0j4-000174-O2 for nemo@optimus.ietf.org; Wed, 12 Nov 2003 14:32: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 OAA03186 for ; Wed, 12 Nov 2003 14:32:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK0j1-0004Mk-00 for nemo@ietf.org; Wed, 12 Nov 2003 14:32:23 -0500 Received: from dyn071-179.ietf58.ietf.org ([130.129.71.179] helo=squirrel.psl.com.sg) by ietf-mx with esmtp (Exim 4.12) id 1AK0j0-0004Mf-00 for nemo@ietf.org; Wed, 12 Nov 2003 14:32:22 -0500 Received: by squirrel.psl.com.sg (Postfix, from userid 1000) id 48B161039904; Thu, 13 Nov 2003 03:31:12 +0800 (SGT) Subject: Re: [nemo] Re:risk LFN sees MR CoA and HA address (was: Last call for draft-ietf-nemo-basic-support-01.txt) From: Chan-Wah NG To: Alexandru Petrescu Cc: IETF NEMO WG In-Reply-To: <3FB272BB.1010300@motorola.com> References: <3FB272BB.1010300@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1068665471.1630.19.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 13 Nov 2003 03:31:12 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Alex, well, there is no threat (or more appropriately 'problem' since nobody mentioned the word 'threat'). I think in the first read, we misinterpreted the "original packet" to include the outer packet as well. It turn out to be a mistake. Other random thoughts inline. /rgds /cwng On Thu, 2003-11-13 at 01:49, Alexandru Petrescu wrote: > If I understand the threat correctly, please correct me if I'm wrong. > > The attacker is LFN. The protected information is MR's CoA and HA > address. The risk is that LFN may gain knowledge of those two addresses. > So what? > I didn't foresee any harm in that, but it was something not intended, and as such, implications of unintended effects may not be very well thought of, and thus its good that Felix bring it to the discussion list. > There are other simpler means for LFN to obtain those two addresses: > traceroute is but one example, no need to generate badly formatted packets. > Pardon my ignorance, is there a traceroute mechanism in IPv6? > Also, this is not a "location privacy" problem issue per se (I tried a > definition of "location privacy" in the draft I've just sent on this > thread). > > What are the other risks that LFN gaining access to MR's CoA and MR's HA > address might involve? Also I think the protection against this risk > might lie in AAA, PANA, EAP and even SEND might offer to MR (if MR is > the target) to protect against malicious LFN's. > > I'm also thinking that chewing on this kind of threat might lead to > a valuable description, so include it in a document; Yup, exactly why I contributed my random thoughts in response to Felix's mail. Though it turn out to be a 'false alarm', it might generate useful materials for analysis. > but also thinking > that sending malformed packets to any destination and hoping for a reply > back containing valuable information is a part of everything. > > Look, if an attacker MR could malform a packet, send it to a legitimate > MR's HA, obtain in response that HA's secret keys it holds with the > legitimate MR, (eventually as a result of attacker nesting under > legitimate), then we really have a NEMO threat. > If an attacker can do so, we better had anticpated it and took meaures to prevent it! /rgds /cwng From exim@www1.ietf.org Wed Nov 12 14:33:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03289 for ; Wed, 12 Nov 2003 14:33: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 1AK0jk-0001CE-VP for nemo-archive@odin.ietf.org; Wed, 12 Nov 2003 14:33:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACJX8NT004589 for nemo-archive@odin.ietf.org; Wed, 12 Nov 2003 14:33:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK0jk-0001Bw-Oa for nemo-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 14:33: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 OAA03238 for ; Wed, 12 Nov 2003 14:32:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK0ji-0004NZ-00 for nemo-web-archive@ietf.org; Wed, 12 Nov 2003 14:33:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK0jh-0004NW-00 for nemo-web-archive@ietf.org; Wed, 12 Nov 2003 14:33:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK0jd-00017X-Ma; Wed, 12 Nov 2003 14:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK0j4-000174-O2 for nemo@optimus.ietf.org; Wed, 12 Nov 2003 14:32: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 OAA03186 for ; Wed, 12 Nov 2003 14:32:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK0j1-0004Mk-00 for nemo@ietf.org; Wed, 12 Nov 2003 14:32:23 -0500 Received: from dyn071-179.ietf58.ietf.org ([130.129.71.179] helo=squirrel.psl.com.sg) by ietf-mx with esmtp (Exim 4.12) id 1AK0j0-0004Mf-00 for nemo@ietf.org; Wed, 12 Nov 2003 14:32:22 -0500 Received: by squirrel.psl.com.sg (Postfix, from userid 1000) id 48B161039904; Thu, 13 Nov 2003 03:31:12 +0800 (SGT) Subject: Re: [nemo] Re:risk LFN sees MR CoA and HA address (was: Last call for draft-ietf-nemo-basic-support-01.txt) From: Chan-Wah NG To: Alexandru Petrescu Cc: IETF NEMO WG In-Reply-To: <3FB272BB.1010300@motorola.com> References: <3FB272BB.1010300@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1068665471.1630.19.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 13 Nov 2003 03:31:12 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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 Hello Alex, well, there is no threat (or more appropriately 'problem' since nobody mentioned the word 'threat'). I think in the first read, we misinterpreted the "original packet" to include the outer packet as well. It turn out to be a mistake. Other random thoughts inline. /rgds /cwng On Thu, 2003-11-13 at 01:49, Alexandru Petrescu wrote: > If I understand the threat correctly, please correct me if I'm wrong. > > The attacker is LFN. The protected information is MR's CoA and HA > address. The risk is that LFN may gain knowledge of those two addresses. > So what? > I didn't foresee any harm in that, but it was something not intended, and as such, implications of unintended effects may not be very well thought of, and thus its good that Felix bring it to the discussion list. > There are other simpler means for LFN to obtain those two addresses: > traceroute is but one example, no need to generate badly formatted packets. > Pardon my ignorance, is there a traceroute mechanism in IPv6? > Also, this is not a "location privacy" problem issue per se (I tried a > definition of "location privacy" in the draft I've just sent on this > thread). > > What are the other risks that LFN gaining access to MR's CoA and MR's HA > address might involve? Also I think the protection against this risk > might lie in AAA, PANA, EAP and even SEND might offer to MR (if MR is > the target) to protect against malicious LFN's. > > I'm also thinking that chewing on this kind of threat might lead to > a valuable description, so include it in a document; Yup, exactly why I contributed my random thoughts in response to Felix's mail. Though it turn out to be a 'false alarm', it might generate useful materials for analysis. > but also thinking > that sending malformed packets to any destination and hoping for a reply > back containing valuable information is a part of everything. > > Look, if an attacker MR could malform a packet, send it to a legitimate > MR's HA, obtain in response that HA's secret keys it holds with the > legitimate MR, (eventually as a result of attacker nesting under > legitimate), then we really have a NEMO threat. > If an attacker can do so, we better had anticpated it and took meaures to prevent it! /rgds /cwng From nemo-admin@ietf.org Wed Nov 12 17:00:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12254 for ; Wed, 12 Nov 2003 17:00: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 1AK31v-0002MT-Mp; Wed, 12 Nov 2003 17: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 1AK31T-00029M-89 for nemo@optimus.ietf.org; Wed, 12 Nov 2003 16:59:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12028 for ; Wed, 12 Nov 2003 16:59:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK31Q-0007CT-00 for nemo@ietf.org; Wed, 12 Nov 2003 16:59:33 -0500 Received: from soda.cs.ucdavis.edu ([169.237.6.187]) by ietf-mx with esmtp (Exim 4.12) id 1AK31P-0007CQ-00 for nemo@ietf.org; Wed, 12 Nov 2003 16:59:32 -0500 Received: from cs.ucdavis.edu (soda [169.237.6.187]) by soda.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id hACLwKha028398; Wed, 12 Nov 2003 13:58:22 -0800 (PST) Message-ID: <3FB2ACFD.3050507@cs.ucdavis.edu> Date: Wed, 12 Nov 2003 13:58:21 -0800 From: "S. Felix Wu" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: ryuji@sfc.wide.ad.jp, Alexandru.Petrescu@motorola.com, pthubert@cisco.com, IETF NEMO WG Subject: Re: ICMP Tunnel error processing and reporting( was Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt) References: <1068024404.6779.27.camel@localhost> <3FA93FF0.9060608@iprg.nokia.com> <1068094146.11301.127.camel@localhost> <3FAAC5E7.80205@iprg.nokia.com> <3FB1A4B4.7020306@cs.ucdavis.edu> <3FB273DE.5010206@iprg.nokia.com> In-Reply-To: <3FB273DE.5010206@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 Dear Vijay, Vijay Devarapalli wrote: > good, this is the kind of detailed threat analysis I like to see. Thanks. Yes, I agree that we should look for something more specific to the nemo itself. > I am missing something here.... > > if there is a problem with the outer header, the response goes back > to the MR. the MNN will not get the ICMP error. > > if there is a problem with the inner header, it means the Home Agent > has already stripped the outer header and some node (could be the > Home Agent also) is trying processing the inner packet. in this case, > the nodes send the ICMP error back to the MNN. the Home Agent, when it > tries to send the ICMP error back to the MNN, tunnels the error to the > MR. the MR removes the outer tunnel headers and forwards the ICMP error > alone to the MNN. the MNN will not get information about the tunnel > between the MR and the HA. according to the RFC, in some situations, the ICMP message should also be forwarded to the MNN. But, later (after I sent out my first email -- appologize for that), I also found that even under these cases (i.e., the MR needs to send/forward ICMP messages to MNN, the source of the original packet), the tunnel header information will be removed according to the same rfc. Thanks. -Felix -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From nemo-admin@ietf.org Wed Nov 12 19:33:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19504 for ; Wed, 12 Nov 2003 19:33: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 1AK5Py-0005yd-BK; Wed, 12 Nov 2003 19:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK5P0-0005mz-JH for nemo@optimus.ietf.org; Wed, 12 Nov 2003 19:32: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 TAA19384; Wed, 12 Nov 2003 19:31:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK5Ox-0001y3-00; Wed, 12 Nov 2003 19:31:59 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AK5Ow-0001xy-00; Wed, 12 Nov 2003 19:31:59 -0500 Message-ID: <00f601c3a97d$991aea70$85818182@dclkempt40> From: "James Kempf" To: , , , Date: Wed, 12 Nov 2003 16:32:17 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00EE_01C3A93A.899CD560" Subject: [nemo] Minutes of Multiple Link Flows BAR BOF Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C3A93A.899CD560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Folks, Attached are the minutes of the multiple link flows BAR BOF. jak ------=_NextPart_000_00EE_01C3A93A.899CD560 Content-Type: text/plain; name="multilink-flows-bof-writeup.txt" Content-Disposition: attachment; filename="multilink-flows-bof-writeup.txt" Content-Transfer-Encoding: quoted-printable Introduction=0A= ------------=0A= =0A= This note describes an informal meeting held at IETF 58 on Monday where = the general topic of utilizing multiple links was discussed. Wireless = last hop links were the primary focus, since market introduction of = consumer devices with multiple wireless interfaces is pending, and = people can get the same now with laptops that have multiple wireless = interface cards.=0A= =0A= Single Logical Flow over Separate Physical Links/IP Addresses=0A= -------------------------------------------------------------=0A= =0A= This topic area concerned splitting a single logical flow over multiple = IP addresses, presumably to match multiple physical interfaces on the = device. This technique had been proposed by SCTP orignally as a way of = load balancing, and in other contexts for transport striping to achieve = higher throughput. Randy Steward talked about why this was taken out of = SCTP. In summary, although the sending host may utilize multiple = addresses for the receiving host, and although the the receiving host = might have those multiple addresses configured on multiple separate = physical interfaces, the traffic between the two might run over the = exact same physical path, and consequently utilizing two addresses won't = really provide any load balancing as far as the intervening network is = concerned. Problems include out of order packets, false retransmissions, = problems with congestion control variables, and timeouts. Performing = retransmission on one address for congestion detected on the other might = have the perverse effect of causing worse congestion. As a result, SCTP = now supports multiple links only for purposes of fault tolerance, = failing over to a new link if the old one goes down, and not load = balancing.=0A= =0A= The University of Deleware has been doing research on this topic and has = published some papers. Below is a short bibliography:=0A= =0A= http://www.cis.udel.edu/~iyengar/publications/2003.hotnets.iyengar.pdf=0A= =0A= Describes the problems with concurrent multilink transfer and proposes = some algorithms to fix the problems.=0A= =0A= http://www.cis.udel.edu/~amer/PEL/poc/pdf/ICON03-caro.pdf=0A= =0A= Shows that retransmit policies which try to utilize multiple paths often = result in worse performance.=0A= =0A= Moving Flows Between Mobile IP Care of Addresses=0A= ------------------------------------------------=0A= =0A= The idea behind this proposal is to allow movement of multiple flows = between different Mobile IP care of addresses depending on the = characteristics of the wireless links on which those addresses are = configured. The proposal seems most interesting near term for the MIP4 = WG in order to accommodate multiple interface devices in existing MIP4 = deployments, and longer term in the MIP6 WG as well as for mobile = networks in NEMO. This technique would not be performing link = aggregation since the paths for logical flows would be uniform, not = split. From the point of view of the SCTP experience, this seemed as if = it would not be a problem since end to end congestion control is being = performed on logical flows that traverse one path. It would, however, = hide the flow movement from the correspondent node, i.e. the = corresponding end point would not be involved in the decision about = which care of address to use. This idea has motivated a draft in the = MIP4 WG, draft-nomad-mobileip-filters-05.txt, which recommends = installing "filters" at the home agent to perform the redirection. The = filters would allow traffic of various types to be redirected to care of = addresses whose corresponding physical interfaces had particular = bandwidth and latency characteristics, for example, running video over a = broadband WLAN interface. In addition, it would help preserve home = addresses in MIP4 since the MN would only have a single home address. = Clearly, there is a potential end to end issue in not notifying the = correspondent node about the flow switching, but since the home agent is = essentiall performing a routing function, the situation is not much = different than a QoS router that switches a flow to a different = interface due to flow state set up by RSVP signaling. There is, of = course, the same scaling issue in the home agent as for RSVP, since the = home agent must maintain per flow and per care of address state, but the = scaling issue is restricted to just the home agent.=0A= =0A= If this proposal is accepted, there is an issue about which signaling = protocol to use with the home agent to tell it how to move the flows. = Mobile IP itself was suggested, QoS signaling protocols such as RSVP and = NSIS, SNMP, and COPS. Lately, the trend has been to not add additional = functions into Mobile IP, to keep it simple and dedicated strictly to = mobility, thus, AAA was separated out of MIP6, so the MIP protocol = itself might not be the best choice for the signaling protocol.=0A= =0A= Simulations and prototypes in realistic networks would also be of = interest, to see if any unanticipated problems crop up.=0A= =0A= Two specific problems were discussed besides the general problem. One = was the usefulness of multiple care of addresses for mobile networks. = NEMO is still studying the issue, and hasn't as yet worked through the = problem. The other was using RFC 3401 address privacy for IPv6. In this = scenerio, the mobile node has multiple care of addresses assigned to a = single interface, and would like to use them for privacy between the = mobile node and home agent. =0A= =0A= Next Steps=0A= ----------=0A= =0A= There was no concensus in the group about whether the problem was = specifically an issue for the MIP groups or whether it required = participation from other WGs. Since there are some proposals before the = MIP4 & MIP6 WGs currently, the MIP groups are the logical place to = start. Thomas Narten suggested coming up with a clear problem statement, = and Carsten Borman volunteered to talk with the group at Universitaet = Bremen who authored draft-nomad-mobileip-filters-05.txt about authoring = a clear problem statement for the MIP care of address case.=0A= =0A= =0A= Terminology=0A= -----------=0A= =0A= After the meeting, Carsten Borman and I discussed how to designate this = topic area. The meeting was advertised as "multilink flows" but that = doesn't capture the problem since it also implies logical flows over = multiple IP addresses, something that the SCTP experience has indicated = is problematic from a congestion control standpoint. The term "QoS = routing" came up during the meeting but that drags along a lot of = baggage. "Flow handoff" seems to capture the topic best, since the = intent is to hand off individual flows to care of addresses that have = the best characteristics for handling the flows. ------=_NextPart_000_00EE_01C3A93A.899CD560-- From exim@www1.ietf.org Wed Nov 12 19:33:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19521 for ; Wed, 12 Nov 2003 19:33: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 1AK5Q4-00063t-Ao for nemo-archive@odin.ietf.org; Wed, 12 Nov 2003 19:33:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD0X887023295 for nemo-archive@odin.ietf.org; Wed, 12 Nov 2003 19:33:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK5Q4-00063e-5Z for nemo-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 19:33: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 TAA19458 for ; Wed, 12 Nov 2003 19:32:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK5Q2-0001yo-00 for nemo-web-archive@ietf.org; Wed, 12 Nov 2003 19:33:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK5Q2-0001yl-00 for nemo-web-archive@ietf.org; Wed, 12 Nov 2003 19:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK5Py-0005yd-BK; Wed, 12 Nov 2003 19:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK5P0-0005mz-JH for nemo@optimus.ietf.org; Wed, 12 Nov 2003 19:32: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 TAA19384; Wed, 12 Nov 2003 19:31:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK5Ox-0001y3-00; Wed, 12 Nov 2003 19:31:59 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AK5Ow-0001xy-00; Wed, 12 Nov 2003 19:31:59 -0500 Message-ID: <00f601c3a97d$991aea70$85818182@dclkempt40> From: "James Kempf" To: , , , Date: Wed, 12 Nov 2003 16:32:17 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00EE_01C3A93A.899CD560" Subject: [nemo] Minutes of Multiple Link Flows BAR BOF Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C3A93A.899CD560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Folks, Attached are the minutes of the multiple link flows BAR BOF. jak ------=_NextPart_000_00EE_01C3A93A.899CD560 Content-Type: text/plain; name="multilink-flows-bof-writeup.txt" Content-Disposition: attachment; filename="multilink-flows-bof-writeup.txt" Content-Transfer-Encoding: quoted-printable Introduction=0A= ------------=0A= =0A= This note describes an informal meeting held at IETF 58 on Monday where = the general topic of utilizing multiple links was discussed. Wireless = last hop links were the primary focus, since market introduction of = consumer devices with multiple wireless interfaces is pending, and = people can get the same now with laptops that have multiple wireless = interface cards.=0A= =0A= Single Logical Flow over Separate Physical Links/IP Addresses=0A= -------------------------------------------------------------=0A= =0A= This topic area concerned splitting a single logical flow over multiple = IP addresses, presumably to match multiple physical interfaces on the = device. This technique had been proposed by SCTP orignally as a way of = load balancing, and in other contexts for transport striping to achieve = higher throughput. Randy Steward talked about why this was taken out of = SCTP. In summary, although the sending host may utilize multiple = addresses for the receiving host, and although the the receiving host = might have those multiple addresses configured on multiple separate = physical interfaces, the traffic between the two might run over the = exact same physical path, and consequently utilizing two addresses won't = really provide any load balancing as far as the intervening network is = concerned. Problems include out of order packets, false retransmissions, = problems with congestion control variables, and timeouts. Performing = retransmission on one address for congestion detected on the other might = have the perverse effect of causing worse congestion. As a result, SCTP = now supports multiple links only for purposes of fault tolerance, = failing over to a new link if the old one goes down, and not load = balancing.=0A= =0A= The University of Deleware has been doing research on this topic and has = published some papers. Below is a short bibliography:=0A= =0A= http://www.cis.udel.edu/~iyengar/publications/2003.hotnets.iyengar.pdf=0A= =0A= Describes the problems with concurrent multilink transfer and proposes = some algorithms to fix the problems.=0A= =0A= http://www.cis.udel.edu/~amer/PEL/poc/pdf/ICON03-caro.pdf=0A= =0A= Shows that retransmit policies which try to utilize multiple paths often = result in worse performance.=0A= =0A= Moving Flows Between Mobile IP Care of Addresses=0A= ------------------------------------------------=0A= =0A= The idea behind this proposal is to allow movement of multiple flows = between different Mobile IP care of addresses depending on the = characteristics of the wireless links on which those addresses are = configured. The proposal seems most interesting near term for the MIP4 = WG in order to accommodate multiple interface devices in existing MIP4 = deployments, and longer term in the MIP6 WG as well as for mobile = networks in NEMO. This technique would not be performing link = aggregation since the paths for logical flows would be uniform, not = split. From the point of view of the SCTP experience, this seemed as if = it would not be a problem since end to end congestion control is being = performed on logical flows that traverse one path. It would, however, = hide the flow movement from the correspondent node, i.e. the = corresponding end point would not be involved in the decision about = which care of address to use. This idea has motivated a draft in the = MIP4 WG, draft-nomad-mobileip-filters-05.txt, which recommends = installing "filters" at the home agent to perform the redirection. The = filters would allow traffic of various types to be redirected to care of = addresses whose corresponding physical interfaces had particular = bandwidth and latency characteristics, for example, running video over a = broadband WLAN interface. In addition, it would help preserve home = addresses in MIP4 since the MN would only have a single home address. = Clearly, there is a potential end to end issue in not notifying the = correspondent node about the flow switching, but since the home agent is = essentiall performing a routing function, the situation is not much = different than a QoS router that switches a flow to a different = interface due to flow state set up by RSVP signaling. There is, of = course, the same scaling issue in the home agent as for RSVP, since the = home agent must maintain per flow and per care of address state, but the = scaling issue is restricted to just the home agent.=0A= =0A= If this proposal is accepted, there is an issue about which signaling = protocol to use with the home agent to tell it how to move the flows. = Mobile IP itself was suggested, QoS signaling protocols such as RSVP and = NSIS, SNMP, and COPS. Lately, the trend has been to not add additional = functions into Mobile IP, to keep it simple and dedicated strictly to = mobility, thus, AAA was separated out of MIP6, so the MIP protocol = itself might not be the best choice for the signaling protocol.=0A= =0A= Simulations and prototypes in realistic networks would also be of = interest, to see if any unanticipated problems crop up.=0A= =0A= Two specific problems were discussed besides the general problem. One = was the usefulness of multiple care of addresses for mobile networks. = NEMO is still studying the issue, and hasn't as yet worked through the = problem. The other was using RFC 3401 address privacy for IPv6. In this = scenerio, the mobile node has multiple care of addresses assigned to a = single interface, and would like to use them for privacy between the = mobile node and home agent. =0A= =0A= Next Steps=0A= ----------=0A= =0A= There was no concensus in the group about whether the problem was = specifically an issue for the MIP groups or whether it required = participation from other WGs. Since there are some proposals before the = MIP4 & MIP6 WGs currently, the MIP groups are the logical place to = start. Thomas Narten suggested coming up with a clear problem statement, = and Carsten Borman volunteered to talk with the group at Universitaet = Bremen who authored draft-nomad-mobileip-filters-05.txt about authoring = a clear problem statement for the MIP care of address case.=0A= =0A= =0A= Terminology=0A= -----------=0A= =0A= After the meeting, Carsten Borman and I discussed how to designate this = topic area. The meeting was advertised as "multilink flows" but that = doesn't capture the problem since it also implies logical flows over = multiple IP addresses, something that the SCTP experience has indicated = is problematic from a congestion control standpoint. The term "QoS = routing" came up during the meeting but that drags along a lot of = baggage. "Flow handoff" seems to capture the topic best, since the = intent is to hand off individual flows to care of addresses that have = the best characteristics for handling the flows. ------=_NextPart_000_00EE_01C3A93A.899CD560-- From nemo-admin@ietf.org Wed Nov 12 21:49:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23527 for ; Wed, 12 Nov 2003 21: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 1AK7XZ-0004f0-As; Wed, 12 Nov 2003 21: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 1AK7XU-0004eI-1S for nemo@optimus.ietf.org; Wed, 12 Nov 2003 21:48:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23490; Wed, 12 Nov 2003 21:48:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK7XQ-0003q9-00; Wed, 12 Nov 2003 21:48:52 -0500 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 1AK7XQ-0003pd-00; Wed, 12 Nov 2003 21:48:52 -0500 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id E062E6BA93; Wed, 12 Nov 2003 21:48:22 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id hAD2mMgG007916; Wed, 12 Nov 2003 21:48:22 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.10/8.12.10) with ESMTP id hAD2mF7J021288; Wed, 12 Nov 2003 21:48:20 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20031112213448.02839cc0@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 12 Nov 2003 21:47:15 -0500 To: Alexandru Petrescu From: William D Ivancic Cc: mip4@ietf.org, nemo@ietf.org In-Reply-To: References: <200310171934.PAA18267@ietf.org> <200310171934.PAA18267@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [nemo] Re: [Mip4] Questions on draft-kulkarni-mobileip-dynamic-assignment-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: , Hello Alex, MIP4 and nemo: Regarding dynamic HA assignments in IPv4 (draft-kulkarni-mobileip-dynamic-assignment-02.txt) and nemo/IPv6 (draft-wakikawa-mip6-nemo-haha-00). I find some similarities and find these concepts very useful. I have had to opportunity to work with the dynamic HA in IPv4. Some of the potential architectures that can take advantage of the tools provided by these proposed protocols are documented in a paper entitled "Use of Mobile-IP Priority Home Agents for Aeronautics, Space Operations and Military Applications." The draft paper is available at the following URL: http://roland.grc.nasa.gov/~ivancic/papers_presentations/PID1317.pdf Will At 08:21 PM 11/7/2003 +0100, Alexandru Petrescu wrote: > writes: > > Title : Mobile IPv4 Dynamic Home Agent Assignment Framework > > Author(s) : M. Kulkarni, A. Patel, K. Leung > > Filename : draft-kulkarni-mobileip-dynamic-assignment-02.txt > > Pages : 21 > > Date : 2003-10-17 > >Hi to MIP4 members, I've read this draft because it relates to a >similar draft for Mobile IPv6 with which I got familiar weeks ago. > >I was wondering if I can get IPv4-specific clarification for the >motivation behind this idea. From exim@www1.ietf.org Wed Nov 12 21:49:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23548 for ; Wed, 12 Nov 2003 21:49: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 1AK7Xd-0004ha-Le for nemo-archive@odin.ietf.org; Wed, 12 Nov 2003 21:49:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD2n5Hp018068 for nemo-archive@odin.ietf.org; Wed, 12 Nov 2003 21:49:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7Xd-0004hL-Hj for nemo-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 21:49: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 VAA23504 for ; Wed, 12 Nov 2003 21:48:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK7Xa-0003qd-00 for nemo-web-archive@ietf.org; Wed, 12 Nov 2003 21:49:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK7Xa-0003qa-00 for nemo-web-archive@ietf.org; Wed, 12 Nov 2003 21: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 1AK7XZ-0004f0-As; Wed, 12 Nov 2003 21: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 1AK7XU-0004eI-1S for nemo@optimus.ietf.org; Wed, 12 Nov 2003 21:48:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23490; Wed, 12 Nov 2003 21:48:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK7XQ-0003q9-00; Wed, 12 Nov 2003 21:48:52 -0500 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 1AK7XQ-0003pd-00; Wed, 12 Nov 2003 21:48:52 -0500 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id E062E6BA93; Wed, 12 Nov 2003 21:48:22 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id hAD2mMgG007916; Wed, 12 Nov 2003 21:48:22 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.10/8.12.10) with ESMTP id hAD2mF7J021288; Wed, 12 Nov 2003 21:48:20 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20031112213448.02839cc0@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 12 Nov 2003 21:47:15 -0500 To: Alexandru Petrescu From: William D Ivancic Cc: mip4@ietf.org, nemo@ietf.org In-Reply-To: References: <200310171934.PAA18267@ietf.org> <200310171934.PAA18267@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [nemo] Re: [Mip4] Questions on draft-kulkarni-mobileip-dynamic-assignment-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: , Hello Alex, MIP4 and nemo: Regarding dynamic HA assignments in IPv4 (draft-kulkarni-mobileip-dynamic-assignment-02.txt) and nemo/IPv6 (draft-wakikawa-mip6-nemo-haha-00). I find some similarities and find these concepts very useful. I have had to opportunity to work with the dynamic HA in IPv4. Some of the potential architectures that can take advantage of the tools provided by these proposed protocols are documented in a paper entitled "Use of Mobile-IP Priority Home Agents for Aeronautics, Space Operations and Military Applications." The draft paper is available at the following URL: http://roland.grc.nasa.gov/~ivancic/papers_presentations/PID1317.pdf Will At 08:21 PM 11/7/2003 +0100, Alexandru Petrescu wrote: > writes: > > Title : Mobile IPv4 Dynamic Home Agent Assignment Framework > > Author(s) : M. Kulkarni, A. Patel, K. Leung > > Filename : draft-kulkarni-mobileip-dynamic-assignment-02.txt > > Pages : 21 > > Date : 2003-10-17 > >Hi to MIP4 members, I've read this draft because it relates to a >similar draft for Mobile IPv6 with which I got familiar weeks ago. > >I was wondering if I can get IPv4-specific clarification for the >motivation behind this idea. From nemo-admin@ietf.org Thu Nov 13 10:50:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04186 for ; Thu, 13 Nov 2003 10:50: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 1AKJjN-00066R-E9; Thu, 13 Nov 2003 10: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 1AKJeG-0005eE-Ts for nemo@optimus.ietf.org; Thu, 13 Nov 2003 10:44: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 KAA03792 for ; Thu, 13 Nov 2003 10:44:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJeD-0007EL-00 for nemo@ietf.org; Thu, 13 Nov 2003 10:44:41 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx with smtp (Exim 4.12) id 1AKJeB-0007E9-00 for nemo@ietf.org; Thu, 13 Nov 2003 10:44:39 -0500 Received: (qmail 27636 invoked for bounce); 13 Nov 2003 15:44:48 -0000 Received: from unknown (HELO clarinet.u-strasbg.fr) (montavont@unknown) by unknown with RC4-MD5 encrypted SMTP; 13 Nov 2003 15:44:48 -0000 Message-ID: <3FB3A6E0.3050503@clarinet.u-strasbg.fr> Date: Thu, 13 Nov 2003 16:44:32 +0100 From: Nicolas Montavont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org References: <00f601c3a97d$991aea70$85818182@dclkempt40> In-Reply-To: <00f601c3a97d$991aea70$85818182@dclkempt40> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [nemo] Re: [Mip6] Minutes of Multiple Link Flows BAR BOF Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org 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, Thank you James for this good minutes of our meeting. It clearly=20 clarifies things and help to move forward. However, I have to raise a point. We (Ryuji, Thierry, Thomas and me)=20 began to write a problem statement draft in MIP6 WG=20 (draft-montavont-multihoming-pb-statement-00) and I think that it can be = the starting point of a pb statement document. Following the=20 presentation of this draft at the MIP6 meeting, and from some comments=20 in the mailing list, we receive valuable feedback for the evolution of=20 this draft. Also, the bar bof gives us other ideas to enhance this docume= nt. So I think that a new version of this draft can constitute the pb=20 statement currently required to move forward on the multihoming. It is=20 not necessary to duplicate the efforts. Nicolas James Kempf wrote: >Folks, > >Attached are the minutes of the multiple link flows BAR BOF. > > jak > >------------------------------------------------------------------------= > >Introduction >------------ > >This note describes an informal meeting held at IETF 58 on Monday where = the general topic of utilizing multiple links was discussed. Wireless las= t hop links were the primary focus, since market introduction of consumer= devices with multiple wireless interfaces is pending, and people can get= the same now with laptops that have multiple wireless interface cards. > >Single Logical Flow over Separate Physical Links/IP Addresses >------------------------------------------------------------- > >This topic area concerned splitting a single logical flow over multiple = IP addresses, presumably to match multiple physical interfaces on the dev= ice. This technique had been proposed by SCTP orignally as a way of load = balancing, and in other contexts for transport striping to achieve higher= throughput. Randy Steward talked about why this was taken out of SCTP. I= n summary, although the sending host may utilize multiple addresses for t= he receiving host, and although the the receiving host might have those m= ultiple addresses configured on multiple separate physical interfaces, th= e traffic between the two might run over the exact same physical path, an= d consequently utilizing two addresses won't really provide any load bala= ncing as far as the intervening network is concerned. Problems include ou= t of order packets, false retransmissions, problems with congestion contr= ol variables, and timeouts. Performing retransmission on one address for = congestion detected on the other might have the perverse effect of causin= g worse congestion. As a result, SCTP now supports multiple links only fo= r purposes of fault tolerance, failing over to a new link if the old one = goes down, and not load balancing. > >The University of Deleware has been doing research on this topic and has= published some papers. Below is a short bibliography: > >http://www.cis.udel.edu/~iyengar/publications/2003.hotnets.iyengar.pdf > >Describes the problems with concurrent multilink transfer and proposes s= ome algorithms to fix the problems. > >http://www.cis.udel.edu/~amer/PEL/poc/pdf/ICON03-caro.pdf > >Shows that retransmit policies which try to utilize multiple paths often= result in worse performance. > >Moving Flows Between Mobile IP Care of Addresses >------------------------------------------------ > >The idea behind this proposal is to allow movement of multiple flows bet= ween different Mobile IP care of addresses depending on the characteristi= cs of the wireless links on which those addresses are configured. The pro= posal seems most interesting near term for the MIP4 WG in order to accomm= odate multiple interface devices in existing MIP4 deployments, and longer= term in the MIP6 WG as well as for mobile networks in NEMO. This techniq= ue would not be performing link aggregation since the paths for logical f= lows would be uniform, not split. From the point of view of the SCTP expe= rience, this seemed as if it would not be a problem since end to end cong= estion control is being performed on logical flows that traverse one path= =2E It would, however, hide the flow movement from the correspondent node= , i.e. the corresponding end point would not be involved in the decision = about which care of address to use. This idea has motivated a draft in th= e MIP4 WG, draft-nomad-mobileip-filters-05.txt, which recommends installi= ng "filters" at the home agent to perform the redirection. The filters wo= uld allow traffic of various types to be redirected to care of addresses = whose corresponding physical interfaces had particular bandwidth and late= ncy characteristics, for example, running video over a broadband WLAN int= erface. In addition, it would help preserve home addresses in MIP4 since = the MN would only have a single home address. Clearly, there is a potenti= al end to end issue in not notifying the correspondent node about the flo= w switching, but since the home agent is essentiall performing a routing = function, the situation is not much different than a QoS router that swit= ches a flow to a different interface due to flow state set up by RSVP sig= naling. There is, of course, the same scaling issue in the home agent as = for RSVP, since the home agent must maintain per flow and per care of add= ress state, but the scaling issue is restricted to just the home agent. > >If this proposal is accepted, there is an issue about which signaling pr= otocol to use with the home agent to tell it how to move the flows. Mobil= e IP itself was suggested, QoS signaling protocols such as RSVP and NSIS,= SNMP, and COPS. Lately, the trend has been to not add additional functio= ns into Mobile IP, to keep it simple and dedicated strictly to mobility, = thus, AAA was separated out of MIP6, so the MIP protocol itself might not= be the best choice for the signaling protocol. > >Simulations and prototypes in realistic networks would also be of intere= st, to see if any unanticipated problems crop up. > >Two specific problems were discussed besides the general problem. One wa= s the usefulness of multiple care of addresses for mobile networks. NEMO = is still studying the issue, and hasn't as yet worked through the problem= =2E The other was using RFC 3401 address privacy for IPv6. In this scener= io, the mobile node has multiple care of addresses assigned to a single i= nterface, and would like to use them for privacy between the mobile node = and home agent.=20 > >Next Steps >---------- > >There was no concensus in the group about whether the problem was specif= ically an issue for the MIP groups or whether it required participation f= rom other WGs. Since there are some proposals before the MIP4 & MIP6 WGs = currently, the MIP groups are the logical place to start. Thomas Narten s= uggested coming up with a clear problem statement, and Carsten Borman vol= unteered to talk with the group at Universitaet Bremen who authored draft= -nomad-mobileip-filters-05.txt about authoring a clear problem statement = for the MIP care of address case. > > >Terminology >----------- > >After the meeting, Carsten Borman and I discussed how to designate this = topic area. The meeting was advertised as "multilink flows" but that does= n't capture the problem since it also implies logical flows over multiple= IP addresses, something that the SCTP experience has indicated is proble= matic from a congestion control standpoint. The term "QoS routing" came u= p during the meeting but that drags along a lot of baggage. "Flow handoff= " seems to capture the topic best, since the intent is to hand off indivi= dual flows to care of addresses that have the best characteristics for ha= ndling the flows. > From exim@www1.ietf.org Thu Nov 13 10:50:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04195 for ; Thu, 13 Nov 2003 10:50: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 1AKJjS-00067O-Tl for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 10:50:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADFo6W8023514 for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 10:50:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJjS-00067B-Pd for nemo-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 10:50: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 KAA04183 for ; Thu, 13 Nov 2003 10:49:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJjQ-0007Oo-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 10:50:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKJjQ-0007Ol-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 10:50:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJjN-00066R-E9; Thu, 13 Nov 2003 10: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 1AKJeG-0005eE-Ts for nemo@optimus.ietf.org; Thu, 13 Nov 2003 10:44: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 KAA03792 for ; Thu, 13 Nov 2003 10:44:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJeD-0007EL-00 for nemo@ietf.org; Thu, 13 Nov 2003 10:44:41 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx with smtp (Exim 4.12) id 1AKJeB-0007E9-00 for nemo@ietf.org; Thu, 13 Nov 2003 10:44:39 -0500 Received: (qmail 27636 invoked for bounce); 13 Nov 2003 15:44:48 -0000 Received: from unknown (HELO clarinet.u-strasbg.fr) (montavont@unknown) by unknown with RC4-MD5 encrypted SMTP; 13 Nov 2003 15:44:48 -0000 Message-ID: <3FB3A6E0.3050503@clarinet.u-strasbg.fr> Date: Thu, 13 Nov 2003 16:44:32 +0100 From: Nicolas Montavont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org References: <00f601c3a97d$991aea70$85818182@dclkempt40> In-Reply-To: <00f601c3a97d$991aea70$85818182@dclkempt40> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [nemo] Re: [Mip6] Minutes of Multiple Link Flows BAR BOF Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org 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, Thank you James for this good minutes of our meeting. It clearly=20 clarifies things and help to move forward. However, I have to raise a point. We (Ryuji, Thierry, Thomas and me)=20 began to write a problem statement draft in MIP6 WG=20 (draft-montavont-multihoming-pb-statement-00) and I think that it can be = the starting point of a pb statement document. Following the=20 presentation of this draft at the MIP6 meeting, and from some comments=20 in the mailing list, we receive valuable feedback for the evolution of=20 this draft. Also, the bar bof gives us other ideas to enhance this docume= nt. So I think that a new version of this draft can constitute the pb=20 statement currently required to move forward on the multihoming. It is=20 not necessary to duplicate the efforts. Nicolas James Kempf wrote: >Folks, > >Attached are the minutes of the multiple link flows BAR BOF. > > jak > >------------------------------------------------------------------------= > >Introduction >------------ > >This note describes an informal meeting held at IETF 58 on Monday where = the general topic of utilizing multiple links was discussed. Wireless las= t hop links were the primary focus, since market introduction of consumer= devices with multiple wireless interfaces is pending, and people can get= the same now with laptops that have multiple wireless interface cards. > >Single Logical Flow over Separate Physical Links/IP Addresses >------------------------------------------------------------- > >This topic area concerned splitting a single logical flow over multiple = IP addresses, presumably to match multiple physical interfaces on the dev= ice. This technique had been proposed by SCTP orignally as a way of load = balancing, and in other contexts for transport striping to achieve higher= throughput. Randy Steward talked about why this was taken out of SCTP. I= n summary, although the sending host may utilize multiple addresses for t= he receiving host, and although the the receiving host might have those m= ultiple addresses configured on multiple separate physical interfaces, th= e traffic between the two might run over the exact same physical path, an= d consequently utilizing two addresses won't really provide any load bala= ncing as far as the intervening network is concerned. Problems include ou= t of order packets, false retransmissions, problems with congestion contr= ol variables, and timeouts. Performing retransmission on one address for = congestion detected on the other might have the perverse effect of causin= g worse congestion. As a result, SCTP now supports multiple links only fo= r purposes of fault tolerance, failing over to a new link if the old one = goes down, and not load balancing. > >The University of Deleware has been doing research on this topic and has= published some papers. Below is a short bibliography: > >http://www.cis.udel.edu/~iyengar/publications/2003.hotnets.iyengar.pdf > >Describes the problems with concurrent multilink transfer and proposes s= ome algorithms to fix the problems. > >http://www.cis.udel.edu/~amer/PEL/poc/pdf/ICON03-caro.pdf > >Shows that retransmit policies which try to utilize multiple paths often= result in worse performance. > >Moving Flows Between Mobile IP Care of Addresses >------------------------------------------------ > >The idea behind this proposal is to allow movement of multiple flows bet= ween different Mobile IP care of addresses depending on the characteristi= cs of the wireless links on which those addresses are configured. The pro= posal seems most interesting near term for the MIP4 WG in order to accomm= odate multiple interface devices in existing MIP4 deployments, and longer= term in the MIP6 WG as well as for mobile networks in NEMO. This techniq= ue would not be performing link aggregation since the paths for logical f= lows would be uniform, not split. From the point of view of the SCTP expe= rience, this seemed as if it would not be a problem since end to end cong= estion control is being performed on logical flows that traverse one path= =2E It would, however, hide the flow movement from the correspondent node= , i.e. the corresponding end point would not be involved in the decision = about which care of address to use. This idea has motivated a draft in th= e MIP4 WG, draft-nomad-mobileip-filters-05.txt, which recommends installi= ng "filters" at the home agent to perform the redirection. The filters wo= uld allow traffic of various types to be redirected to care of addresses = whose corresponding physical interfaces had particular bandwidth and late= ncy characteristics, for example, running video over a broadband WLAN int= erface. In addition, it would help preserve home addresses in MIP4 since = the MN would only have a single home address. Clearly, there is a potenti= al end to end issue in not notifying the correspondent node about the flo= w switching, but since the home agent is essentiall performing a routing = function, the situation is not much different than a QoS router that swit= ches a flow to a different interface due to flow state set up by RSVP sig= naling. There is, of course, the same scaling issue in the home agent as = for RSVP, since the home agent must maintain per flow and per care of add= ress state, but the scaling issue is restricted to just the home agent. > >If this proposal is accepted, there is an issue about which signaling pr= otocol to use with the home agent to tell it how to move the flows. Mobil= e IP itself was suggested, QoS signaling protocols such as RSVP and NSIS,= SNMP, and COPS. Lately, the trend has been to not add additional functio= ns into Mobile IP, to keep it simple and dedicated strictly to mobility, = thus, AAA was separated out of MIP6, so the MIP protocol itself might not= be the best choice for the signaling protocol. > >Simulations and prototypes in realistic networks would also be of intere= st, to see if any unanticipated problems crop up. > >Two specific problems were discussed besides the general problem. One wa= s the usefulness of multiple care of addresses for mobile networks. NEMO = is still studying the issue, and hasn't as yet worked through the problem= =2E The other was using RFC 3401 address privacy for IPv6. In this scener= io, the mobile node has multiple care of addresses assigned to a single i= nterface, and would like to use them for privacy between the mobile node = and home agent.=20 > >Next Steps >---------- > >There was no concensus in the group about whether the problem was specif= ically an issue for the MIP groups or whether it required participation f= rom other WGs. Since there are some proposals before the MIP4 & MIP6 WGs = currently, the MIP groups are the logical place to start. Thomas Narten s= uggested coming up with a clear problem statement, and Carsten Borman vol= unteered to talk with the group at Universitaet Bremen who authored draft= -nomad-mobileip-filters-05.txt about authoring a clear problem statement = for the MIP care of address case. > > >Terminology >----------- > >After the meeting, Carsten Borman and I discussed how to designate this = topic area. The meeting was advertised as "multilink flows" but that does= n't capture the problem since it also implies logical flows over multiple= IP addresses, something that the SCTP experience has indicated is proble= matic from a congestion control standpoint. The term "QoS routing" came u= p during the meeting but that drags along a lot of baggage. "Flow handoff= " seems to capture the topic best, since the intent is to hand off indivi= dual flows to care of addresses that have the best characteristics for ha= ndling the flows. > From nemo-admin@ietf.org Thu Nov 13 14:27:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14202 for ; Thu, 13 Nov 2003 14: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 1AKN7N-0006eZ-7O; Thu, 13 Nov 2003 14: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 1AKN7J-0006eB-RX for nemo@optimus.ietf.org; Thu, 13 Nov 2003 14: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 OAA14159 for ; Thu, 13 Nov 2003 14:26:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKN7H-0003O8-00 for nemo@ietf.org; Thu, 13 Nov 2003 14:26:55 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKN7G-0003NP-00 for nemo@ietf.org; Thu, 13 Nov 2003 14:26:54 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hADJQLZ21902; Thu, 13 Nov 2003 11:26:21 -0800 X-mProtect: <200311131926> Nokia Silicon Valley Messaging Protection Received: from danira-pool0538.americas.nokia.com (10.241.53.8, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4p38Zf; Thu, 13 Nov 2003 11:26:19 PST Message-ID: <3FB3DAD1.9030607@iprg.nokia.com> Date: Thu, 13 Nov 2003 11:26:09 -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: nemo@ietf.org, Chan-Wah Ng Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Issue 17 - Resolution Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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, Chan-Wah had proposed relaxing the MUST requirement for protecting all tunneled routing protocol messages through ESP. I presented this at the WG meeting yesterday. nobody seemed to have an opinion on this. I am fine with relaxing the requirement to SHOULD. also, the issue also contained some comments from Chan-Wah to add a section on Binding Ack status values will be added to the IANA considerations section. that has also been accepted. Vijay From exim@www1.ietf.org Thu Nov 13 14:27:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14217 for ; Thu, 13 Nov 2003 14:27: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 1AKN7R-0006gZ-9t for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 14:27:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADJR5tH025693 for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 14:27:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKN7R-0006gK-3u for nemo-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 14:27: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 OAA14168 for ; Thu, 13 Nov 2003 14:26:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKN7O-0003OL-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 14:27:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKN7O-0003OI-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 14:27:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKN7N-0006eZ-7O; Thu, 13 Nov 2003 14: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 1AKN7J-0006eB-RX for nemo@optimus.ietf.org; Thu, 13 Nov 2003 14: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 OAA14159 for ; Thu, 13 Nov 2003 14:26:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKN7H-0003O8-00 for nemo@ietf.org; Thu, 13 Nov 2003 14:26:55 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKN7G-0003NP-00 for nemo@ietf.org; Thu, 13 Nov 2003 14:26:54 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hADJQLZ21902; Thu, 13 Nov 2003 11:26:21 -0800 X-mProtect: <200311131926> Nokia Silicon Valley Messaging Protection Received: from danira-pool0538.americas.nokia.com (10.241.53.8, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4p38Zf; Thu, 13 Nov 2003 11:26:19 PST Message-ID: <3FB3DAD1.9030607@iprg.nokia.com> Date: Thu, 13 Nov 2003 11:26:09 -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: nemo@ietf.org, Chan-Wah Ng Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Issue 17 - Resolution Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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, Chan-Wah had proposed relaxing the MUST requirement for protecting all tunneled routing protocol messages through ESP. I presented this at the WG meeting yesterday. nobody seemed to have an opinion on this. I am fine with relaxing the requirement to SHOULD. also, the issue also contained some comments from Chan-Wah to add a section on Binding Ack status values will be added to the IANA considerations section. that has also been accepted. Vijay From nemo-admin@ietf.org Thu Nov 13 15:00:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15750 for ; Thu, 13 Nov 2003 15:00: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 1AKNdK-0000XX-If; Thu, 13 Nov 2003 15: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 1AKNd3-0000WQ-Az for nemo@optimus.ietf.org; Thu, 13 Nov 2003 14:59: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 OAA15651 for ; Thu, 13 Nov 2003 14:59:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNd0-0003tv-00 for nemo@ietf.org; Thu, 13 Nov 2003 14:59:42 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKNcz-0003ta-00 for nemo@ietf.org; Thu, 13 Nov 2003 14:59:41 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hADJxAO18917; Thu, 13 Nov 2003 11:59:10 -0800 X-mProtect: <200311131959> Nokia Silicon Valley Messaging Protection Received: from danira-pool0538.americas.nokia.com (10.241.53.8, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdh8tz6h; Thu, 13 Nov 2003 11:59:08 PST Message-ID: <3FB3E282.60407@iprg.nokia.com> Date: Thu, 13 Nov 2003 11:58:58 -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: nemo@ietf.org CC: matsumoto.taisuke@jp.panasonic.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Closing Issue 19 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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, a new section has been added to section 6.2 to close this issue. - Mobile IPv6 specification [1] requires that the Home Address in the Binding Update should be configured from a prefix advertised on the home link. Otherwise the Binding Update is rejected with status value 132 [1]. This specifications relaxes this requirement so that the Home Agent rejects the Binding Update only if Home Address does not belong to the prefix that the Home Agent is configured to serve. the details are at http://people.nokia.net/vijayd/nemo/issue19.txt Vijay From exim@www1.ietf.org Thu Nov 13 15:00:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15768 for ; Thu, 13 Nov 2003 15:00: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 1AKNdO-0000a2-AK for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 15:00:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADK054n002221 for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 15:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNdN-0000Yk-4l for nemo-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 15:00:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15679 for ; Thu, 13 Nov 2003 14:59:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNdK-0003uU-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 15:00:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKNdJ-0003uR-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 15:00:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNdK-0000XX-If; Thu, 13 Nov 2003 15: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 1AKNd3-0000WQ-Az for nemo@optimus.ietf.org; Thu, 13 Nov 2003 14:59: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 OAA15651 for ; Thu, 13 Nov 2003 14:59:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNd0-0003tv-00 for nemo@ietf.org; Thu, 13 Nov 2003 14:59:42 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKNcz-0003ta-00 for nemo@ietf.org; Thu, 13 Nov 2003 14:59:41 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hADJxAO18917; Thu, 13 Nov 2003 11:59:10 -0800 X-mProtect: <200311131959> Nokia Silicon Valley Messaging Protection Received: from danira-pool0538.americas.nokia.com (10.241.53.8, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdh8tz6h; Thu, 13 Nov 2003 11:59:08 PST Message-ID: <3FB3E282.60407@iprg.nokia.com> Date: Thu, 13 Nov 2003 11:58:58 -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: nemo@ietf.org CC: matsumoto.taisuke@jp.panasonic.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Closing Issue 19 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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, a new section has been added to section 6.2 to close this issue. - Mobile IPv6 specification [1] requires that the Home Address in the Binding Update should be configured from a prefix advertised on the home link. Otherwise the Binding Update is rejected with status value 132 [1]. This specifications relaxes this requirement so that the Home Agent rejects the Binding Update only if Home Address does not belong to the prefix that the Home Agent is configured to serve. the details are at http://people.nokia.net/vijayd/nemo/issue19.txt Vijay From nemo-admin@ietf.org Thu Nov 13 17:36:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25222 for ; Thu, 13 Nov 2003 17:36: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 1AKQ4H-0004UL-Pa; Thu, 13 Nov 2003 17: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 1AKQ3o-0004Nu-Hm for nemo@optimus.ietf.org; Thu, 13 Nov 2003 17:35: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 RAA25048; Thu, 13 Nov 2003 17:35:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQ3l-0006tE-00; Thu, 13 Nov 2003 17:35:29 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AKQ3l-0006tB-00; Thu, 13 Nov 2003 17:35:29 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hADMZO5u025263; Thu, 13 Nov 2003 15:35:25 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hADMZKQ08048; Thu, 13 Nov 2003 23:35:20 +0100 (MET) Date: Thu, 13 Nov 2003 23:34:21 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark To: James Kempf Cc: nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org In-Reply-To: "Your message with ID" <00f601c3a97d$991aea70$85818182@dclkempt40> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Subject: [nemo] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , I didn't make it to the bar on Monday due to jetlag. One observation I have on the desire to send different flows over different paths/CoAs. Looking at possible multihoming solutions (take draft-nordmark-multi6-noid as an example one what a solution might look like) the result is that the stack would have a mapping from an ID (used by transport protocols) to a set of locators for the peer. This type of example shows that it might be useful to express sending different flows over different paths/locators even if mobility isn't used. Thus I don't think such a scheme, if we are going to define one, should be tied to mobility specific signalling. Erik From exim@www1.ietf.org Thu Nov 13 17:36:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25241 for ; Thu, 13 Nov 2003 17:36: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 1AKQ4R-0004dy-Dk for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 17:36:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADMaBpP017842 for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 17:36:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQ4R-0004dh-7H for nemo-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 17:36: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 RAA25155 for ; Thu, 13 Nov 2003 17:35:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQ4O-0006uD-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 17:36:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKQ4O-0006u9-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 17:36:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQ4H-0004UL-Pa; Thu, 13 Nov 2003 17: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 1AKQ3o-0004Nu-Hm for nemo@optimus.ietf.org; Thu, 13 Nov 2003 17:35: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 RAA25048; Thu, 13 Nov 2003 17:35:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQ3l-0006tE-00; Thu, 13 Nov 2003 17:35:29 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AKQ3l-0006tB-00; Thu, 13 Nov 2003 17:35:29 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hADMZO5u025263; Thu, 13 Nov 2003 15:35:25 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hADMZKQ08048; Thu, 13 Nov 2003 23:35:20 +0100 (MET) Date: Thu, 13 Nov 2003 23:34:21 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark To: James Kempf Cc: nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org In-Reply-To: "Your message with ID" <00f601c3a97d$991aea70$85818182@dclkempt40> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Subject: [nemo] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , I didn't make it to the bar on Monday due to jetlag. One observation I have on the desire to send different flows over different paths/CoAs. Looking at possible multihoming solutions (take draft-nordmark-multi6-noid as an example one what a solution might look like) the result is that the stack would have a mapping from an ID (used by transport protocols) to a set of locators for the peer. This type of example shows that it might be useful to express sending different flows over different paths/locators even if mobility isn't used. Thus I don't think such a scheme, if we are going to define one, should be tied to mobility specific signalling. Erik From nemo-admin@ietf.org Thu Nov 13 18:04:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26584 for ; Thu, 13 Nov 2003 18:04: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 1AKQVN-0006l3-LD; Thu, 13 Nov 2003 18:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQUy-0006jQ-3v for nemo@optimus.ietf.org; Thu, 13 Nov 2003 18: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 SAA26408; Thu, 13 Nov 2003 18:03:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQUu-0007Ky-00; Thu, 13 Nov 2003 18:03:32 -0500 Received: from imh.informatik.uni-bremen.de ([134.102.224.4]) by ietf-mx with esmtp (Exim 4.12) id 1AKQUt-0007Kv-00; Thu, 13 Nov 2003 18:03:31 -0500 Received: from tzi.org (imh.informatik.uni-bremen.de [134.102.224.4]) by imh.informatik.uni-bremen.de (8.12.10/8.12.9) with ESMTP id hADN3OEf011370; Fri, 14 Nov 2003 00:03:24 +0100 (MET) Date: Fri, 14 Nov 2003 00:03:30 +0100 Subject: Re: [nemo] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Carsten Bormann , James Kempf , nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org To: Erik Nordmark From: Carsten Bormann In-Reply-To: Message-Id: <98FF293E-162D-11D8-90E6-00039390397C@tzi.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > This type of example shows that it might be useful to express sending > different flows over different paths/locators even if mobility isn't > used. > > Thus I don't think such a scheme, if we are going to define one, > should be tied to mobility specific signalling. This is certainly good thinking, but the question is "express to whom"? When you have a HA, this is a good place to perform this flow handoff -- existing trust relationship, same administrative domain, existing and stable communication relationship. The MobileIP protocol is a good way to talk to the HA (and much of the signalling actually can be piggybacked). A more general approach (e.g., the closest willing router shared between the paths to the two interfaces) will need an on-path signalling protocol like NSIS, which is much more complex to use. Generality is not always cheap. (I'm willing to be convinced that it actually is, in this case.) Oh, and if there is no mobility, it is much easier to involve the CN (transport peer) from the outset -- no protocol needed in this (obvious) case. Gruesse, Carsten From exim@www1.ietf.org Thu Nov 13 18:55:13 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26600 for ; Thu, 13 Nov 2003 18:04: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 1AKQVR-0006pl-Oa for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 18:04:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADN458l026263 for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 18:04:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQVR-0006pW-Hn for nemo-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 18:04:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26480 for ; Thu, 13 Nov 2003 18:03:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQVO-0007M2-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 18:04:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKQVO-0007Ly-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 18:04:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQVN-0006l3-LD; Thu, 13 Nov 2003 18:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQUy-0006jQ-3v for nemo@optimus.ietf.org; Thu, 13 Nov 2003 18: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 SAA26408; Thu, 13 Nov 2003 18:03:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQUu-0007Ky-00; Thu, 13 Nov 2003 18:03:32 -0500 Received: from imh.informatik.uni-bremen.de ([134.102.224.4]) by ietf-mx with esmtp (Exim 4.12) id 1AKQUt-0007Kv-00; Thu, 13 Nov 2003 18:03:31 -0500 Received: from tzi.org (imh.informatik.uni-bremen.de [134.102.224.4]) by imh.informatik.uni-bremen.de (8.12.10/8.12.9) with ESMTP id hADN3OEf011370; Fri, 14 Nov 2003 00:03:24 +0100 (MET) Date: Fri, 14 Nov 2003 00:03:30 +0100 Subject: Re: [nemo] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Carsten Bormann , James Kempf , nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org To: Erik Nordmark From: Carsten Bormann In-Reply-To: Message-Id: <98FF293E-162D-11D8-90E6-00039390397C@tzi.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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 > This type of example shows that it might be useful to express sending > different flows over different paths/locators even if mobility isn't > used. > > Thus I don't think such a scheme, if we are going to define one, > should be tied to mobility specific signalling. This is certainly good thinking, but the question is "express to whom"? When you have a HA, this is a good place to perform this flow handoff -- existing trust relationship, same administrative domain, existing and stable communication relationship. The MobileIP protocol is a good way to talk to the HA (and much of the signalling actually can be piggybacked). A more general approach (e.g., the closest willing router shared between the paths to the two interfaces) will need an on-path signalling protocol like NSIS, which is much more complex to use. Generality is not always cheap. (I'm willing to be convinced that it actually is, in this case.) Oh, and if there is no mobility, it is much easier to involve the CN (transport peer) from the outset -- no protocol needed in this (obvious) case. Gruesse, Carsten From nemo-admin@ietf.org Thu Nov 13 19:26:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01247 for ; Thu, 13 Nov 2003 19:26: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 1AKRmj-0004hZ-BY; Thu, 13 Nov 2003 19:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKRmG-0004eH-H3 for nemo@optimus.ietf.org; Thu, 13 Nov 2003 19:25: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 TAA01159 for ; Thu, 13 Nov 2003 19:25:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKRmE-0000w7-00 for nemo@ietf.org; Thu, 13 Nov 2003 19:25:30 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1AKRmE-0000vz-00 for nemo@ietf.org; Thu, 13 Nov 2003 19:25:30 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id hAE0PS29013242; Thu, 13 Nov 2003 17:25:30 -0700 (MST) Received: from motorola.com ([163.14.20.22]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id hAE0P6kl001142; Thu, 13 Nov 2003 18:25:11 -0600 Message-ID: <3FB420E0.8010403@motorola.com> Date: Fri, 14 Nov 2003 01:25:04 +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, matsumoto.taisuke@jp.panasonic.com Subject: Re: [nemo] Closing Issue 19 References: <3FB3E282.60407@iprg.nokia.com> In-Reply-To: <3FB3E282.60407@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > hi, > > a new section has been added to section 6.2 to close this issue. > > - Mobile IPv6 specification [1] requires that the Home Address in > the Binding Update should be configured from a prefix advertised on > the home link. Otherwise the Binding Update is rejected with status > value 132 [1]. This specifications relaxes this requirement so that > the Home Agent rejects the Binding Update only if Home Address does > not belong to the prefix that the Home Agent is configured to serve. Looks reasonable. In the abssence of a precise definition of "serve", it makes me think that HA might "serve" only one prefix. Is this the intended meaning? Alex GBU From exim@www1.ietf.org Thu Nov 13 19:26:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01268 for ; Thu, 13 Nov 2003 19:26: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 1AKRmm-0004ip-M2 for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 19:26:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE0Q44i018150 for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 19:26:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKRmm-0004if-GC for nemo-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 19:26: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 TAA01185 for ; Thu, 13 Nov 2003 19:25:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKRmk-0000x0-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 19:26:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKRmk-0000wx-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 19:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKRmj-0004hZ-BY; Thu, 13 Nov 2003 19:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKRmG-0004eH-H3 for nemo@optimus.ietf.org; Thu, 13 Nov 2003 19:25: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 TAA01159 for ; Thu, 13 Nov 2003 19:25:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKRmE-0000w7-00 for nemo@ietf.org; Thu, 13 Nov 2003 19:25:30 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1AKRmE-0000vz-00 for nemo@ietf.org; Thu, 13 Nov 2003 19:25:30 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id hAE0PS29013242; Thu, 13 Nov 2003 17:25:30 -0700 (MST) Received: from motorola.com ([163.14.20.22]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id hAE0P6kl001142; Thu, 13 Nov 2003 18:25:11 -0600 Message-ID: <3FB420E0.8010403@motorola.com> Date: Fri, 14 Nov 2003 01:25:04 +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, matsumoto.taisuke@jp.panasonic.com Subject: Re: [nemo] Closing Issue 19 References: <3FB3E282.60407@iprg.nokia.com> In-Reply-To: <3FB3E282.60407@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > hi, > > a new section has been added to section 6.2 to close this issue. > > - Mobile IPv6 specification [1] requires that the Home Address in > the Binding Update should be configured from a prefix advertised on > the home link. Otherwise the Binding Update is rejected with status > value 132 [1]. This specifications relaxes this requirement so that > the Home Agent rejects the Binding Update only if Home Address does > not belong to the prefix that the Home Agent is configured to serve. Looks reasonable. In the abssence of a precise definition of "serve", it makes me think that HA might "serve" only one prefix. Is this the intended meaning? Alex GBU From nemo-admin@ietf.org Thu Nov 13 19:29:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01394 for ; Thu, 13 Nov 2003 19: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 1AKRpc-0004sc-Sk; Thu, 13 Nov 2003 19: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 1AKQnd-0008UU-L5 for nemo@optimus.ietf.org; Thu, 13 Nov 2003 18:22: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 SAA28751 for ; Thu, 13 Nov 2003 18:22:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQnZ-0007kq-00 for nemo@ietf.org; Thu, 13 Nov 2003 18:22:50 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx with smtp (Exim 4.12) id 1AKQnY-0007ke-00 for nemo@ietf.org; Thu, 13 Nov 2003 18:22:49 -0500 Received: (qmail 30510 invoked for bounce); 13 Nov 2003 23:22:48 -0000 Received: from unknown (HELO clarinet.u-strasbg.fr) (montavont@unknown) by unknown with RC4-MD5 encrypted SMTP; 13 Nov 2003 23:22:48 -0000 Message-ID: <3FB41243.7020502@clarinet.u-strasbg.fr> Date: Fri, 14 Nov 2003 00:22:43 +0100 From: Nicolas Montavont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: James Kempf , nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@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: [Mip6] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >I didn't make it to the bar on Monday due to jetlag. > >One observation I have on the desire to send different flows over >different paths/CoAs. > >Looking at possible multihoming solutions (take draft-nordmark-multi6-noid >as an example one what a solution might look like) the result >is that the stack would have a mapping from an ID (used by transport protocols) >to a set of locators for the peer. > >This type of example shows that it might be useful to express sending >different flows over different paths/locators even if mobility isn't used. > >Thus I don't think such a scheme, if we are going to define one, >should be tied to mobility specific signalling. > I totally agree with you that if we specify a MIPv6-tied solution for "general" multihoming, we may encounter difficulties with non-MNs. But I think that some points are to be clarified in MIPv6 when the MN is multihomed. That is what we are trying to show in draft-montavont-pb-statement. And I'd like to point out another aspect of multihoming, more linked to our draft on filtering (draft-montavont-mip6-ha-filtering). Assume that you have two interfaces, a WLAN interface and a GPRS interface and you currently use the WLAN interface through a reverse tunnel with your home agent. Assume that you receive several flows on your pda. One of them is a video streaming. Then you leave the hot spot zone and want to switch your flows on GPRS interface. To do so, you send a BU to your HA. In this case, it can be very useful to add some filters on what flows you want to be redirected and what flows you don't want on your GPRS interface. It seems to me that to use the BU in that case is a good solution, because you only need to send one message. This does not forbidd the use of other mechanisms to manage multihoming in different situations. Maybe the conclusion of that can be that different problems may lead to different solutions. A clear problem statement, from each WG may definitly help to clarify the situation. Nicolas > > Erik > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www.ietf.org/mailman/listinfo/mip6 > > From exim@www1.ietf.org Thu Nov 13 19:29:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01412 for ; Thu, 13 Nov 2003 19:29: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 1AKRpe-0004us-3r for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 19:29:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE0T2gl018892 for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 19:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKRpd-0004ud-Uq for nemo-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 19: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 TAA01379 for ; Thu, 13 Nov 2003 19:28:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKRpc-00012E-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 19:29:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKRpb-00012B-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 19: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 1AKRpc-0004sc-Sk; Thu, 13 Nov 2003 19: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 1AKQnd-0008UU-L5 for nemo@optimus.ietf.org; Thu, 13 Nov 2003 18:22: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 SAA28751 for ; Thu, 13 Nov 2003 18:22:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQnZ-0007kq-00 for nemo@ietf.org; Thu, 13 Nov 2003 18:22:50 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx with smtp (Exim 4.12) id 1AKQnY-0007ke-00 for nemo@ietf.org; Thu, 13 Nov 2003 18:22:49 -0500 Received: (qmail 30510 invoked for bounce); 13 Nov 2003 23:22:48 -0000 Received: from unknown (HELO clarinet.u-strasbg.fr) (montavont@unknown) by unknown with RC4-MD5 encrypted SMTP; 13 Nov 2003 23:22:48 -0000 Message-ID: <3FB41243.7020502@clarinet.u-strasbg.fr> Date: Fri, 14 Nov 2003 00:22:43 +0100 From: Nicolas Montavont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: James Kempf , nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@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: [Mip6] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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 Erik Nordmark wrote: >I didn't make it to the bar on Monday due to jetlag. > >One observation I have on the desire to send different flows over >different paths/CoAs. > >Looking at possible multihoming solutions (take draft-nordmark-multi6-noid >as an example one what a solution might look like) the result >is that the stack would have a mapping from an ID (used by transport protocols) >to a set of locators for the peer. > >This type of example shows that it might be useful to express sending >different flows over different paths/locators even if mobility isn't used. > >Thus I don't think such a scheme, if we are going to define one, >should be tied to mobility specific signalling. > I totally agree with you that if we specify a MIPv6-tied solution for "general" multihoming, we may encounter difficulties with non-MNs. But I think that some points are to be clarified in MIPv6 when the MN is multihomed. That is what we are trying to show in draft-montavont-pb-statement. And I'd like to point out another aspect of multihoming, more linked to our draft on filtering (draft-montavont-mip6-ha-filtering). Assume that you have two interfaces, a WLAN interface and a GPRS interface and you currently use the WLAN interface through a reverse tunnel with your home agent. Assume that you receive several flows on your pda. One of them is a video streaming. Then you leave the hot spot zone and want to switch your flows on GPRS interface. To do so, you send a BU to your HA. In this case, it can be very useful to add some filters on what flows you want to be redirected and what flows you don't want on your GPRS interface. It seems to me that to use the BU in that case is a good solution, because you only need to send one message. This does not forbidd the use of other mechanisms to manage multihoming in different situations. Maybe the conclusion of that can be that different problems may lead to different solutions. A clear problem statement, from each WG may definitly help to clarify the situation. Nicolas > > Erik > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www.ietf.org/mailman/listinfo/mip6 > > From nemo-admin@ietf.org Thu Nov 13 20:31:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03607 for ; Thu, 13 Nov 2003 20:31: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 1AKSnd-00010c-PW; Thu, 13 Nov 2003 20:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSnJ-00010A-RK for nemo@optimus.ietf.org; Thu, 13 Nov 2003 20:30:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03578 for ; Thu, 13 Nov 2003 20:30:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKSnH-00023s-00 for nemo@ietf.org; Thu, 13 Nov 2003 20:30:39 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKSnG-00023l-00 for nemo@ietf.org; Thu, 13 Nov 2003 20:30:39 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAE1U7e30233; Thu, 13 Nov 2003 17:30:07 -0800 X-mProtect: <200311140130> Nokia Silicon Valley Messaging Protection Received: from danira-pool055244.americas.nokia.com (10.241.55.244, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkCpTGw; Thu, 13 Nov 2003 17:30:05 PST Message-ID: <3FB43013.1020002@iprg.nokia.com> Date: Thu, 13 Nov 2003 17:29: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, matsumoto.taisuke@jp.panasonic.com Subject: Re: [nemo] Closing Issue 19 References: <3FB3E282.60407@iprg.nokia.com> <3FB420E0.8010403@motorola.com> In-Reply-To: <3FB420E0.8010403@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: > >> hi, >> >> a new section has been added to section 6.2 to close this issue. >> >> - Mobile IPv6 specification [1] requires that the Home Address in the >> Binding Update should be configured from a prefix advertised on the >> home link. Otherwise the Binding Update is rejected with status >> value 132 [1]. This specifications relaxes this requirement so that >> the Home Agent rejects the Binding Update only if Home Address does >> not belong to the prefix that the Home Agent is configured to serve. > > > > Looks reasonable. > > In the abssence of a precise definition of "serve", it makes me > think that HA might "serve" only one prefix. Is this the intended > meaning? "configured to serve", I think, is clear enough. Vijay From exim@www1.ietf.org Thu Nov 13 20:31:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03625 for ; Thu, 13 Nov 2003 20:31: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 1AKSng-00011v-LX for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 20:31:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE1V4At003953 for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 20:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSng-00011g-EU for nemo-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 20:31: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 UAA03588 for ; Thu, 13 Nov 2003 20:30:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKSne-00026H-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 20:31:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKSnd-00026E-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 20:31:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSnd-00010c-PW; Thu, 13 Nov 2003 20:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSnJ-00010A-RK for nemo@optimus.ietf.org; Thu, 13 Nov 2003 20:30:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03578 for ; Thu, 13 Nov 2003 20:30:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKSnH-00023s-00 for nemo@ietf.org; Thu, 13 Nov 2003 20:30:39 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKSnG-00023l-00 for nemo@ietf.org; Thu, 13 Nov 2003 20:30:39 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAE1U7e30233; Thu, 13 Nov 2003 17:30:07 -0800 X-mProtect: <200311140130> Nokia Silicon Valley Messaging Protection Received: from danira-pool055244.americas.nokia.com (10.241.55.244, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkCpTGw; Thu, 13 Nov 2003 17:30:05 PST Message-ID: <3FB43013.1020002@iprg.nokia.com> Date: Thu, 13 Nov 2003 17:29: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, matsumoto.taisuke@jp.panasonic.com Subject: Re: [nemo] Closing Issue 19 References: <3FB3E282.60407@iprg.nokia.com> <3FB420E0.8010403@motorola.com> In-Reply-To: <3FB420E0.8010403@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: > >> hi, >> >> a new section has been added to section 6.2 to close this issue. >> >> - Mobile IPv6 specification [1] requires that the Home Address in the >> Binding Update should be configured from a prefix advertised on the >> home link. Otherwise the Binding Update is rejected with status >> value 132 [1]. This specifications relaxes this requirement so that >> the Home Agent rejects the Binding Update only if Home Address does >> not belong to the prefix that the Home Agent is configured to serve. > > > > Looks reasonable. > > In the abssence of a precise definition of "serve", it makes me > think that HA might "serve" only one prefix. Is this the intended > meaning? "configured to serve", I think, is clear enough. Vijay From nemo-admin@ietf.org Thu Nov 13 21:13:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05374 for ; Thu, 13 Nov 2003 21:13: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 1AKTSI-0004Na-C0; Thu, 13 Nov 2003 21:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTRZ-0004Fl-BB for nemo@optimus.ietf.org; Thu, 13 Nov 2003 21:12: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 VAA05148; Thu, 13 Nov 2003 21:12:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKTRV-0002jO-00; Thu, 13 Nov 2003 21:12:13 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AKTRU-0002jC-00; Thu, 13 Nov 2003 21:12:13 -0500 Message-ID: <05a801c3aa54$c15258c0$85818182@dclkempt40> From: "James Kempf" To: "Erik Nordmark" , "Carsten Bormann" Cc: "Carsten Bormann" , , , , References: <98FF293E-162D-11D8-90E6-00039390397C@tzi.org> Subject: Re: [nemo] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF Date: Thu, 13 Nov 2003 18:12:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Carsten, > > This type of example shows that it might be useful to express sending > > different flows over different paths/locators even if mobility isn't > > used. > > > > Thus I don't think such a scheme, if we are going to define one, > > should be tied to mobility specific signalling. > > This is certainly good thinking, but the question is "express to whom"? > > When you have a HA, this is a good place to perform this flow handoff > -- existing trust relationship, same administrative domain, existing > and stable communication relationship. > The MobileIP protocol is a good way to talk to the HA (and much of the > signalling actually can be piggybacked). > A more general approach (e.g., the closest willing router shared > between the paths to the two interfaces) will need an on-path > signalling protocol like NSIS, which is much more complex to use. > NSIS is certanly more general, but seems like it is the right approach architecturally. The home agent is essentially a middlebox, and from the presentations I saw today in the NSIS group, NSIS is a solution primarily for signaling to middleboxes, not routers like RSVP is. > Generality is not always cheap. > (I'm willing to be convinced that it actually is, in this case.) > Not clear what the implementation and deployment cost of NSIS is at this point. In terms of dynamic performance, whether the MN sends a binding update or an NSIS message to the home agent, does it make such a differenc? > Oh, and if there is no mobility, it is much easier to involve the CN > (transport peer) from the outset -- no protocol needed in this > (obvious) case. > One could make an argument that it still might be useful to mask multihoming from the CN. jak From exim@www1.ietf.org Thu Nov 13 21:13:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05394 for ; Thu, 13 Nov 2003 21:13: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 1AKTSM-0004TE-Nq for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 21:13:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE2D64E017178 for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 21:13:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTSM-0004Sz-Iu for nemo-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 21:13: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 VAA05317 for ; Thu, 13 Nov 2003 21:12:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKTSJ-0002n1-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 21:13:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKTSJ-0002mv-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 21:13:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTSI-0004Na-C0; Thu, 13 Nov 2003 21:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTRZ-0004Fl-BB for nemo@optimus.ietf.org; Thu, 13 Nov 2003 21:12: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 VAA05148; Thu, 13 Nov 2003 21:12:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKTRV-0002jO-00; Thu, 13 Nov 2003 21:12:13 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AKTRU-0002jC-00; Thu, 13 Nov 2003 21:12:13 -0500 Message-ID: <05a801c3aa54$c15258c0$85818182@dclkempt40> From: "James Kempf" To: "Erik Nordmark" , "Carsten Bormann" Cc: "Carsten Bormann" , , , , References: <98FF293E-162D-11D8-90E6-00039390397C@tzi.org> Subject: Re: [nemo] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF Date: Thu, 13 Nov 2003 18:12:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Carsten, > > This type of example shows that it might be useful to express sending > > different flows over different paths/locators even if mobility isn't > > used. > > > > Thus I don't think such a scheme, if we are going to define one, > > should be tied to mobility specific signalling. > > This is certainly good thinking, but the question is "express to whom"? > > When you have a HA, this is a good place to perform this flow handoff > -- existing trust relationship, same administrative domain, existing > and stable communication relationship. > The MobileIP protocol is a good way to talk to the HA (and much of the > signalling actually can be piggybacked). > A more general approach (e.g., the closest willing router shared > between the paths to the two interfaces) will need an on-path > signalling protocol like NSIS, which is much more complex to use. > NSIS is certanly more general, but seems like it is the right approach architecturally. The home agent is essentially a middlebox, and from the presentations I saw today in the NSIS group, NSIS is a solution primarily for signaling to middleboxes, not routers like RSVP is. > Generality is not always cheap. > (I'm willing to be convinced that it actually is, in this case.) > Not clear what the implementation and deployment cost of NSIS is at this point. In terms of dynamic performance, whether the MN sends a binding update or an NSIS message to the home agent, does it make such a differenc? > Oh, and if there is no mobility, it is much easier to involve the CN > (transport peer) from the outset -- no protocol needed in this > (obvious) case. > One could make an argument that it still might be useful to mask multihoming from the CN. jak From nemo-admin@ietf.org Thu Nov 13 21:20:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05768 for ; Thu, 13 Nov 2003 21:20: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 1AKTZ4-0004pC-Iv; Thu, 13 Nov 2003 21:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTYO-0004mf-F3 for nemo@optimus.ietf.org; Thu, 13 Nov 2003 21:19: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 VAA05724; Thu, 13 Nov 2003 21:19:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKTYL-0002xv-00; Thu, 13 Nov 2003 21:19:17 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AKTYK-0002xs-00; Thu, 13 Nov 2003 21:19:17 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAE2JCPh015944; Thu, 13 Nov 2003 19:19:13 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAE2J9Q05946; Fri, 14 Nov 2003 03:19:09 +0100 (MET) Date: Fri, 14 Nov 2003 03:18:09 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF To: Carsten Bormann Cc: Erik Nordmark , James Kempf , nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org In-Reply-To: "Your message with ID" <98FF293E-162D-11D8-90E6-00039390397C@tzi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > This is certainly good thinking, but the question is "express to whom"? To the entity that has the ability to choose locators. In some multihoming proposals this is a shim layer above IP at the originating node. > When you have a HA, this is a good place to perform this flow handoff > -- existing trust relationship, same administrative domain, existing > and stable communication relationship. > The MobileIP protocol is a good way to talk to the HA (and much of the > signalling actually can be piggybacked). > A more general approach (e.g., the closest willing router shared > between the paths to the two interfaces) will need an on-path > signalling protocol like NSIS, which is much more complex to use. Yes, bolting solutions on existing protocols even though the problem is more general is a common approach; sometimes we pay deerly for this because - we might end up solving the general case as well - the general + specific solutions means that we know have two solutions for the same problem - the specific solution makes the exising protocol (MIP signalling in this case) more complex, less likely to interoperate, etc > Oh, and if there is no mobility, it is much easier to involve the CN > (transport peer) from the outset -- no protocol needed in this > (obvious) case. How can the peer know that I want the video part of the conference over the WLAN interface and the audio part over GPRS? One could declare this to be an application specific problem, but it would still require application specific signalling, right? Erik From exim@www1.ietf.org Thu Nov 13 21:20:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05789 for ; Thu, 13 Nov 2003 21:20: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 1AKTZ8-0004tQ-Hk for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 21:20:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE2K6IY018715 for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 21:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTZ7-0004rZ-DM for nemo-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 21:20: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 VAA05750 for ; Thu, 13 Nov 2003 21:19:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKTZ4-0002yA-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 21:20:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKTZ4-0002y1-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 21:20:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTZ4-0004pC-Iv; Thu, 13 Nov 2003 21:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTYO-0004mf-F3 for nemo@optimus.ietf.org; Thu, 13 Nov 2003 21:19: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 VAA05724; Thu, 13 Nov 2003 21:19:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKTYL-0002xv-00; Thu, 13 Nov 2003 21:19:17 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AKTYK-0002xs-00; Thu, 13 Nov 2003 21:19:17 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAE2JCPh015944; Thu, 13 Nov 2003 19:19:13 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAE2J9Q05946; Fri, 14 Nov 2003 03:19:09 +0100 (MET) Date: Fri, 14 Nov 2003 03:18:09 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF To: Carsten Bormann Cc: Erik Nordmark , James Kempf , nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org In-Reply-To: "Your message with ID" <98FF293E-162D-11D8-90E6-00039390397C@tzi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > This is certainly good thinking, but the question is "express to whom"? To the entity that has the ability to choose locators. In some multihoming proposals this is a shim layer above IP at the originating node. > When you have a HA, this is a good place to perform this flow handoff > -- existing trust relationship, same administrative domain, existing > and stable communication relationship. > The MobileIP protocol is a good way to talk to the HA (and much of the > signalling actually can be piggybacked). > A more general approach (e.g., the closest willing router shared > between the paths to the two interfaces) will need an on-path > signalling protocol like NSIS, which is much more complex to use. Yes, bolting solutions on existing protocols even though the problem is more general is a common approach; sometimes we pay deerly for this because - we might end up solving the general case as well - the general + specific solutions means that we know have two solutions for the same problem - the specific solution makes the exising protocol (MIP signalling in this case) more complex, less likely to interoperate, etc > Oh, and if there is no mobility, it is much easier to involve the CN > (transport peer) from the outset -- no protocol needed in this > (obvious) case. How can the peer know that I want the video part of the conference over the WLAN interface and the audio part over GPRS? One could declare this to be an application specific problem, but it would still require application specific signalling, right? Erik From nemo-admin@ietf.org Thu Nov 13 21:22:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05934 for ; Thu, 13 Nov 2003 21:22: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 1AKTb0-00056S-5L; Thu, 13 Nov 2003 21:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTad-00055T-Ft for nemo@optimus.ietf.org; Thu, 13 Nov 2003 21:21:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05895; Thu, 13 Nov 2003 21:21:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKTaa-00030H-00; Thu, 13 Nov 2003 21:21:36 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AKTaa-0002zs-00; Thu, 13 Nov 2003 21:21:36 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hAE2L0UP010808; Thu, 13 Nov 2003 18:21:01 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAE2KgQ06073; Fri, 14 Nov 2003 03:20:42 +0100 (MET) Date: Fri, 14 Nov 2003 03:19:36 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark To: Nicolas Montavont Cc: Erik Nordmark , James Kempf , nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org In-Reply-To: "Your message with ID" <3FB41243.7020502@clarinet.u-strasbg.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Subject: [nemo] Re: [Mip6] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > Then you leave the hot spot zone and want to switch your flows on GPRS > interface. To do so, you send a BU to your HA. In this case, it can be > very useful to add some filters on what flows you want to be redirected > and what flows you don't want on your GPRS interface. It seems to me > that to use the BU in that case is a good solution, because you only > need to send one message. This does not forbidd the use of other > mechanisms to manage multihoming in different situations. Yes, but this is just as useful even if I don't use MIP. Developping multiple solutions to the same problem shouldn't be a goal I think. Erik From exim@www1.ietf.org Thu Nov 13 21:22:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05952 for ; Thu, 13 Nov 2003 21:22: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 1AKTb3-0005FJ-6O for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 21:22:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE2M4ZS020023 for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 21:22:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTb1-000591-Ud for nemo-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 21:22: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 VAA05907 for ; Thu, 13 Nov 2003 21:21:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKTaz-00030m-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 21:22:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKTay-00030j-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 21:22:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTb0-00056S-5L; Thu, 13 Nov 2003 21:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKTad-00055T-Ft for nemo@optimus.ietf.org; Thu, 13 Nov 2003 21:21:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05895; Thu, 13 Nov 2003 21:21:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKTaa-00030H-00; Thu, 13 Nov 2003 21:21:36 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AKTaa-0002zs-00; Thu, 13 Nov 2003 21:21:36 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hAE2L0UP010808; Thu, 13 Nov 2003 18:21:01 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAE2KgQ06073; Fri, 14 Nov 2003 03:20:42 +0100 (MET) Date: Fri, 14 Nov 2003 03:19:36 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark To: Nicolas Montavont Cc: Erik Nordmark , James Kempf , nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org In-Reply-To: "Your message with ID" <3FB41243.7020502@clarinet.u-strasbg.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Subject: [nemo] Re: [Mip6] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > Then you leave the hot spot zone and want to switch your flows on GPRS > interface. To do so, you send a BU to your HA. In this case, it can be > very useful to add some filters on what flows you want to be redirected > and what flows you don't want on your GPRS interface. It seems to me > that to use the BU in that case is a good solution, because you only > need to send one message. This does not forbidd the use of other > mechanisms to manage multihoming in different situations. Yes, but this is just as useful even if I don't use MIP. Developping multiple solutions to the same problem shouldn't be a goal I think. Erik From nemo-admin@ietf.org Thu Nov 13 21:52:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07478 for ; Thu, 13 Nov 2003 21:52: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 1AKU42-00078U-EA; Thu, 13 Nov 2003 21:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKU3o-00075S-NM for nemo@optimus.ietf.org; Thu, 13 Nov 2003 21:51: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 VAA07335; Thu, 13 Nov 2003 21:51:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKU3l-0003c3-00; Thu, 13 Nov 2003 21:51:45 -0500 Received: from imh.informatik.uni-bremen.de ([134.102.224.4]) by ietf-mx with esmtp (Exim 4.12) id 1AKU3k-0003c0-00; Thu, 13 Nov 2003 21:51:44 -0500 Received: from tzi.org (imh.informatik.uni-bremen.de [134.102.224.4]) by imh.informatik.uni-bremen.de (8.12.10/8.12.9) with ESMTP id hAE2paCA008696; Fri, 14 Nov 2003 03:51:37 +0100 (MET) Date: Fri, 14 Nov 2003 03:51:43 +0100 Subject: Re: [nemo] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Carsten Bormann , James Kempf , nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org To: Erik Nordmark From: Carsten Bormann In-Reply-To: Message-Id: <7AD8D658-164D-11D8-90E6-00039390397C@tzi.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > How can the peer know that I want the video part of the conference over > the WLAN interface and the audio part over GPRS? > One could declare this to be an application specific problem, but it > would > still require application specific signalling, right? Yes, and both SIP/SDP(ng) and H.323 allow specifying the IP address of the destination for a media stream. You can even move those during a session (if the peer system implements this). Even FTP had third-party transfers, before these went out of fashion. With HTTP, you just use the right interface to make the request. On the other hand, if you always wanted to involve the CN in these handoffs, we wouldn't need MobileIP. (The interesting deviant case is a non-cooperating CN -- here you actually need a friend in the network even if you are not mobile.) Gruesse, Carsten From exim@www1.ietf.org Thu Nov 13 21:52:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07496 for ; Thu, 13 Nov 2003 21:52: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 1AKU49-0007Cf-H3 for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 21:52:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE2q9Sp027683 for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 21:52:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKU49-0007CQ-AF for nemo-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 21:52: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 VAA07383 for ; Thu, 13 Nov 2003 21:51:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKU46-0003d3-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 21:52:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKU45-0003d0-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 21:52:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKU42-00078U-EA; Thu, 13 Nov 2003 21:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKU3o-00075S-NM for nemo@optimus.ietf.org; Thu, 13 Nov 2003 21:51: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 VAA07335; Thu, 13 Nov 2003 21:51:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKU3l-0003c3-00; Thu, 13 Nov 2003 21:51:45 -0500 Received: from imh.informatik.uni-bremen.de ([134.102.224.4]) by ietf-mx with esmtp (Exim 4.12) id 1AKU3k-0003c0-00; Thu, 13 Nov 2003 21:51:44 -0500 Received: from tzi.org (imh.informatik.uni-bremen.de [134.102.224.4]) by imh.informatik.uni-bremen.de (8.12.10/8.12.9) with ESMTP id hAE2paCA008696; Fri, 14 Nov 2003 03:51:37 +0100 (MET) Date: Fri, 14 Nov 2003 03:51:43 +0100 Subject: Re: [nemo] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Carsten Bormann , James Kempf , nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org To: Erik Nordmark From: Carsten Bormann In-Reply-To: Message-Id: <7AD8D658-164D-11D8-90E6-00039390397C@tzi.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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 > How can the peer know that I want the video part of the conference over > the WLAN interface and the audio part over GPRS? > One could declare this to be an application specific problem, but it > would > still require application specific signalling, right? Yes, and both SIP/SDP(ng) and H.323 allow specifying the IP address of the destination for a media stream. You can even move those during a session (if the peer system implements this). Even FTP had third-party transfers, before these went out of fashion. With HTTP, you just use the right interface to make the request. On the other hand, if you always wanted to involve the CN in these handoffs, we wouldn't need MobileIP. (The interesting deviant case is a non-cooperating CN -- here you actually need a friend in the network even if you are not mobile.) Gruesse, Carsten From nemo-admin@ietf.org Thu Nov 13 22:59:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10314 for ; Thu, 13 Nov 2003 22:59: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 1AKV6r-00047M-MP; Thu, 13 Nov 2003 22: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 1AKV6h-00046G-Le for nemo@optimus.ietf.org; Thu, 13 Nov 2003 22:58: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 WAA10290 for ; Thu, 13 Nov 2003 22:58:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKV6e-0004rl-00 for nemo@ietf.org; Thu, 13 Nov 2003 22:58:48 -0500 Received: from smtp.mei.co.jp ([133.183.129.25] helo=jazz.mei.co.jp) by ietf-mx with esmtp (Exim 4.12) id 1AKV6d-0004qe-00 for nemo@ietf.org; Thu, 13 Nov 2003 22:58:47 -0500 Received: by jazz.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id hAE3wFqp003376; Fri, 14 Nov 2003 12:58:15 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id hAE3wFg26217; Fri, 14 Nov 2003 12:58:15 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id hAE3wEr28760; Fri, 14 Nov 2003 12:58:14 +0900 (JST) Received: from STRATOS (mie [202.214.244.67] (may be forged)) by mrit.mrit.mei.co.jp (8.12.6p2/3.7W-03060222) with SMTP id hAE3wA2t063545; Fri, 14 Nov 2003 12:58:13 +0900 (JST) Message-Id: <200311140358.hAE3wA2t063545@mrit.mrit.mei.co.jp> Date: Thu, 13 Nov 2003 21:58:17 -0600 From: MATSUMOTO Taisuke Subject: Re: [nemo] Closing Issue 19 To: "Vijay Devarapalli" Cc: "Alexandru Petrescu" , nemo@ietf.org Organization: Matsushita Electric Industrial Co., Ltd. In-Reply-To: <3FB43013.1020002@iprg.nokia.com> References: <3FB3E282.60407@iprg.nokia.com> <3FB420E0.8010403@motorola.com> <3FB43013.1020002@iprg.nokia.com> X-Mailer: Datula version 1.52.01 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Dear Vijay and all, At Thu, 13 Nov 2003 17:29:55 -0800, "Vijay Devarapalli" wrote : > > In the abssence of a precise definition of "serve", it makes me > > think that HA might "serve" only one prefix. Is this the intended > > meaning? > > "configured to serve", I think, is clear enough. Agree. And "How to configure" is an operational matter, isn't it? Taisuke From exim@www1.ietf.org Thu Nov 13 22:59:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10332 for ; Thu, 13 Nov 2003 22: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 1AKV6u-00048L-1i for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 22:59:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE3x4JN015883 for nemo-archive@odin.ietf.org; Thu, 13 Nov 2003 22:59:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKV6t-000486-RX for nemo-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 22:59: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 WAA10311 for ; Thu, 13 Nov 2003 22:58:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKV6q-0004s8-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 22:59:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKV6p-0004s5-00 for nemo-web-archive@ietf.org; Thu, 13 Nov 2003 22:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKV6r-00047M-MP; Thu, 13 Nov 2003 22: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 1AKV6h-00046G-Le for nemo@optimus.ietf.org; Thu, 13 Nov 2003 22:58: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 WAA10290 for ; Thu, 13 Nov 2003 22:58:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKV6e-0004rl-00 for nemo@ietf.org; Thu, 13 Nov 2003 22:58:48 -0500 Received: from smtp.mei.co.jp ([133.183.129.25] helo=jazz.mei.co.jp) by ietf-mx with esmtp (Exim 4.12) id 1AKV6d-0004qe-00 for nemo@ietf.org; Thu, 13 Nov 2003 22:58:47 -0500 Received: by jazz.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id hAE3wFqp003376; Fri, 14 Nov 2003 12:58:15 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id hAE3wFg26217; Fri, 14 Nov 2003 12:58:15 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id hAE3wEr28760; Fri, 14 Nov 2003 12:58:14 +0900 (JST) Received: from STRATOS (mie [202.214.244.67] (may be forged)) by mrit.mrit.mei.co.jp (8.12.6p2/3.7W-03060222) with SMTP id hAE3wA2t063545; Fri, 14 Nov 2003 12:58:13 +0900 (JST) Message-Id: <200311140358.hAE3wA2t063545@mrit.mrit.mei.co.jp> Date: Thu, 13 Nov 2003 21:58:17 -0600 From: MATSUMOTO Taisuke Subject: Re: [nemo] Closing Issue 19 To: "Vijay Devarapalli" Cc: "Alexandru Petrescu" , nemo@ietf.org Organization: Matsushita Electric Industrial Co., Ltd. In-Reply-To: <3FB43013.1020002@iprg.nokia.com> References: <3FB3E282.60407@iprg.nokia.com> <3FB420E0.8010403@motorola.com> <3FB43013.1020002@iprg.nokia.com> X-Mailer: Datula version 1.52.01 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Dear Vijay and all, At Thu, 13 Nov 2003 17:29:55 -0800, "Vijay Devarapalli" wrote : > > In the abssence of a precise definition of "serve", it makes me > > think that HA might "serve" only one prefix. Is this the intended > > meaning? > > "configured to serve", I think, is clear enough. Agree. And "How to configure" is an operational matter, isn't it? Taisuke From nemo-admin@ietf.org Fri Nov 14 05:32:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05187 for ; Fri, 14 Nov 2003 05: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 1AKbFA-0004Iz-5W; Fri, 14 Nov 2003 05: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 1AKbEJ-0004IE-Rk for nemo@optimus.ietf.org; Fri, 14 Nov 2003 05:31: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 FAA05141 for ; Fri, 14 Nov 2003 05:30:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKbEG-0002oX-00 for nemo@ietf.org; Fri, 14 Nov 2003 05:31:04 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AKbEF-0002mM-00 for nemo@ietf.org; Fri, 14 Nov 2003 05:31:03 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hAEATWYT012046; Fri, 14 Nov 2003 03:29:32 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id hAEAUTkl007035; Fri, 14 Nov 2003 04:30:30 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 02A072EC95; Fri, 14 Nov 2003 11:30:26 +0100 (CET) Message-ID: <3FB4AEC2.9020203@motorola.com> Date: Fri, 14 Nov 2003 11:30:26 +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: Alexandru Petrescu , nemo@ietf.org, matsumoto.taisuke@jp.panasonic.com Subject: Re: [nemo] Closing Issue 19 References: <3FB3E282.60407@iprg.nokia.com> <3FB420E0.8010403@motorola.com> <3FB43013.1020002@iprg.nokia.com> In-Reply-To: <3FB43013.1020002@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: >>> - Mobile IPv6 specification [1] requires that the Home Address in >>> the Binding Update should be configured from a prefix advertised on >>> the home link. Otherwise the Binding Update is rejected with status >>> value 132 [1]. This specifications relaxes this requirement so that >>> the Home Agent rejects the Binding Update only if Home Address does >>> not belong to the prefix that the Home Agent is configured to serve. >> >> Looks reasonable. >> >> In the abssence of a precise definition of "serve", it makes me >> think that HA might "serve" only one prefix. Is this the intended >> meaning? > > "configured to serve", I think, is clear enough. Ok, short texts are just fine. Alex From exim@www1.ietf.org Fri Nov 14 05:32:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05203 for ; Fri, 14 Nov 2003 05: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 1AKbFF-0004KA-I8 for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 05:32:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEAW5u2016616 for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 05:32:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKbFF-0004Jv-Cm for nemo-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 05:32: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 FAA05176 for ; Fri, 14 Nov 2003 05:31:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKbFB-0002p4-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 05:32:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKbFB-0002p1-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 05:32:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKbFA-0004Iz-5W; Fri, 14 Nov 2003 05: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 1AKbEJ-0004IE-Rk for nemo@optimus.ietf.org; Fri, 14 Nov 2003 05:31: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 FAA05141 for ; Fri, 14 Nov 2003 05:30:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKbEG-0002oX-00 for nemo@ietf.org; Fri, 14 Nov 2003 05:31:04 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AKbEF-0002mM-00 for nemo@ietf.org; Fri, 14 Nov 2003 05:31:03 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hAEATWYT012046; Fri, 14 Nov 2003 03:29:32 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id hAEAUTkl007035; Fri, 14 Nov 2003 04:30:30 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 02A072EC95; Fri, 14 Nov 2003 11:30:26 +0100 (CET) Message-ID: <3FB4AEC2.9020203@motorola.com> Date: Fri, 14 Nov 2003 11:30:26 +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: Alexandru Petrescu , nemo@ietf.org, matsumoto.taisuke@jp.panasonic.com Subject: Re: [nemo] Closing Issue 19 References: <3FB3E282.60407@iprg.nokia.com> <3FB420E0.8010403@motorola.com> <3FB43013.1020002@iprg.nokia.com> In-Reply-To: <3FB43013.1020002@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: >>> - Mobile IPv6 specification [1] requires that the Home Address in >>> the Binding Update should be configured from a prefix advertised on >>> the home link. Otherwise the Binding Update is rejected with status >>> value 132 [1]. This specifications relaxes this requirement so that >>> the Home Agent rejects the Binding Update only if Home Address does >>> not belong to the prefix that the Home Agent is configured to serve. >> >> Looks reasonable. >> >> In the abssence of a precise definition of "serve", it makes me >> think that HA might "serve" only one prefix. Is this the intended >> meaning? > > "configured to serve", I think, is clear enough. Ok, short texts are just fine. Alex From nemo-admin@ietf.org Fri Nov 14 08:02:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08651 for ; Fri, 14 Nov 2003 08:02: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 1AKdaL-0004Zi-Gj; Fri, 14 Nov 2003 08: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 1AKdZh-0004Wm-24 for nemo@optimus.ietf.org; Fri, 14 Nov 2003 08:01: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 IAA08623 for ; Fri, 14 Nov 2003 08:01:08 -0500 (EST) From: tim.leinmueller@daimlerchrysler.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKdZg-0004Zw-00 for nemo@ietf.org; Fri, 14 Nov 2003 08:01:20 -0500 Received: from pluto4.daimler-benz.com ([53.122.2.34] helo=daimler-benz.com) by ietf-mx with smtp (Exim 4.12) id 1AKdZf-0004Xk-00 for nemo@ietf.org; Fri, 14 Nov 2003 08:01:19 -0500 Received: by daimler-benz.com; id OAA18382; Fri, 14 Nov 2003 14:00:47 +0100 Received: from unknown(53.151.100.103) by pluto4.daimler-benz.com via smap (V5.0) id xmat13474; Fri, 14 Nov 03 13:51:08 +0100 Received: from sstrdg63.wk.dcx.com ([53.151.100.123]) by daimlerchrysler.com (iPlanet Messaging Server 5.2 HotFix 1.20 (built Aug 27 2003)) with ESMTP id <0HOC0075WECW2M@wksmtphubnew.wk.dcx.com> for nemo@ietf.org; Fri, 14 Nov 2003 13:50:56 +0100 (MET) Date: Fri, 14 Nov 2003 13:50:51 +0100 To: nemo@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [nemo] NEMO DHAAD instead of bit in BAck? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org 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 already talked about NEMO DHAAD with the authors of the basic support draft and Vijay asked me to post this to the list. So far according to the basic support draft, MR discovers HA's that have MR support, by receiving binding acks with with non-zero status code. This means MR has to cycle between HA's that have no MR support up to HA's that do have MR support. Being more specific during the HA discovery phase (DHAAD), could improve this situation. I'll attach a text I wrote some time ago, that contains the basic idea. Tim. --- NEMO DHAAD --- Additions to Dynamic Home Agent Address Discovery (DHAAD) Since mobile routers need home agents with support for network mobility, it is of use to extend the existing DHAAD mechanism, to enable mobile routers to discover home agents supporting mobile networks. The modification consists in adding the mobile router home agent bit M to the ICMP messages for home agent discovery (figures 2.24 and 2.25) and to the home agent information option (figure 2.26). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier |M| Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2.24: Extended ICMP Home Agent Address Discovery Request Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier |M| Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + . . . Home Agent Addresses . . . + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2.25: Extended ICMP Home Agent Address Discovery Reply Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |M| Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Preference | Home Agent Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2.26: Extended Home Agent Information Option Format Added to the ICMP home agent address discovery request message, the M bit serves to indicate, that a mobile router is searching for suitable home agents with mobile router support. If this request is received by a normal home agent, it will ignore the M bit and send an ICMP home agent information discovery reply message as specified in [1], without the M bit set. This reply includes all known home agents on the home network, regardless of the support for mobile routers. Otherwise, if the recipient is a mobile router supporting home agent, it will discover the M bit and send an extended ICMP home agent address discovery reply message as response (with the M bit set to one), containing only home agents with support for mobile networks. The M bit in the home agent information option is used to indicate to other home agents, whether the sending home agent is capable (and willing) to act as home agent for mobile routers. A home agent, that does not support the extension, ignores the M bit and adds the supplied information to its normal home agent list, while a home agent that does recognize the M bit, will add an entry to its mobile router supporting home agent list (this list is kept in addition to the standart home agent list). [1] David B. Johnson, Charles E. Perkins and Jari Arkko. Mobility Support in IPv6. Internet Draft draft-ietf-mobileip-ipv6-21.txt (Work in Progress), IETF, February 2003. --- NEMO DHAAD --- From exim@www1.ietf.org Fri Nov 14 08:02:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08669 for ; Fri, 14 Nov 2003 08:02: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 1AKdaQ-0004ai-9j for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 08:02:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAED26VT017649 for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 08:02:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKdaQ-0004aa-0g for nemo-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 08:02: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 IAA08642 for ; Fri, 14 Nov 2003 08:01:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKdaO-0004aL-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 08:02:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKdaO-0004aI-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 08:02:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKdaL-0004Zi-Gj; Fri, 14 Nov 2003 08: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 1AKdZh-0004Wm-24 for nemo@optimus.ietf.org; Fri, 14 Nov 2003 08:01: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 IAA08623 for ; Fri, 14 Nov 2003 08:01:08 -0500 (EST) From: tim.leinmueller@daimlerchrysler.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKdZg-0004Zw-00 for nemo@ietf.org; Fri, 14 Nov 2003 08:01:20 -0500 Received: from pluto4.daimler-benz.com ([53.122.2.34] helo=daimler-benz.com) by ietf-mx with smtp (Exim 4.12) id 1AKdZf-0004Xk-00 for nemo@ietf.org; Fri, 14 Nov 2003 08:01:19 -0500 Received: by daimler-benz.com; id OAA18382; Fri, 14 Nov 2003 14:00:47 +0100 Received: from unknown(53.151.100.103) by pluto4.daimler-benz.com via smap (V5.0) id xmat13474; Fri, 14 Nov 03 13:51:08 +0100 Received: from sstrdg63.wk.dcx.com ([53.151.100.123]) by daimlerchrysler.com (iPlanet Messaging Server 5.2 HotFix 1.20 (built Aug 27 2003)) with ESMTP id <0HOC0075WECW2M@wksmtphubnew.wk.dcx.com> for nemo@ietf.org; Fri, 14 Nov 2003 13:50:56 +0100 (MET) Date: Fri, 14 Nov 2003 13:50:51 +0100 To: nemo@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [nemo] NEMO DHAAD instead of bit in BAck? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org 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 all, I already talked about NEMO DHAAD with the authors of the basic support draft and Vijay asked me to post this to the list. So far according to the basic support draft, MR discovers HA's that have MR support, by receiving binding acks with with non-zero status code. This means MR has to cycle between HA's that have no MR support up to HA's that do have MR support. Being more specific during the HA discovery phase (DHAAD), could improve this situation. I'll attach a text I wrote some time ago, that contains the basic idea. Tim. --- NEMO DHAAD --- Additions to Dynamic Home Agent Address Discovery (DHAAD) Since mobile routers need home agents with support for network mobility, it is of use to extend the existing DHAAD mechanism, to enable mobile routers to discover home agents supporting mobile networks. The modification consists in adding the mobile router home agent bit M to the ICMP messages for home agent discovery (figures 2.24 and 2.25) and to the home agent information option (figure 2.26). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier |M| Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2.24: Extended ICMP Home Agent Address Discovery Request Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier |M| Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + . . . Home Agent Addresses . . . + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2.25: Extended ICMP Home Agent Address Discovery Reply Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |M| Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Preference | Home Agent Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2.26: Extended Home Agent Information Option Format Added to the ICMP home agent address discovery request message, the M bit serves to indicate, that a mobile router is searching for suitable home agents with mobile router support. If this request is received by a normal home agent, it will ignore the M bit and send an ICMP home agent information discovery reply message as specified in [1], without the M bit set. This reply includes all known home agents on the home network, regardless of the support for mobile routers. Otherwise, if the recipient is a mobile router supporting home agent, it will discover the M bit and send an extended ICMP home agent address discovery reply message as response (with the M bit set to one), containing only home agents with support for mobile networks. The M bit in the home agent information option is used to indicate to other home agents, whether the sending home agent is capable (and willing) to act as home agent for mobile routers. A home agent, that does not support the extension, ignores the M bit and adds the supplied information to its normal home agent list, while a home agent that does recognize the M bit, will add an entry to its mobile router supporting home agent list (this list is kept in addition to the standart home agent list). [1] David B. Johnson, Charles E. Perkins and Jari Arkko. Mobility Support in IPv6. Internet Draft draft-ietf-mobileip-ipv6-21.txt (Work in Progress), IETF, February 2003. --- NEMO DHAAD --- From nemo-admin@ietf.org Fri Nov 14 08:46:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10103 for ; Fri, 14 Nov 2003 08:46: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 1AKeGw-0007rJ-VK; Fri, 14 Nov 2003 08: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 1AKeGW-0007qR-GR for nemo@optimus.ietf.org; Fri, 14 Nov 2003 08:45: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 IAA10026 for ; Fri, 14 Nov 2003 08:45:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKeGU-0005Ey-00 for nemo@ietf.org; Fri, 14 Nov 2003 08:45:34 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1AKeGU-0005Ev-00 for nemo@ietf.org; Fri, 14 Nov 2003 08:45:34 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id hAEDjR29016461; Fri, 14 Nov 2003 06:45:30 -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 hAEDixKo011728; Fri, 14 Nov 2003 07:45:05 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 0BCB52EC98; Fri, 14 Nov 2003 14:44:59 +0100 (CET) Message-ID: <3FB4DC5A.7040608@motorola.com> Date: Fri, 14 Nov 2003 14:44:58 +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: tim.leinmueller@daimlerchrysler.com Cc: nemo@ietf.org Subject: Re: [nemo] NEMO DHAAD instead of bit in BAck? References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit tim.leinmueller@daimlerchrysler.com wrote: > Hi all, > > I already talked about NEMO DHAAD with the authors of the basic > support draft and Vijay asked me to post this to the list. > > So far according to the basic support draft, MR discovers HA's that > have MR support, by receiving binding acks with with non-zero status > code. With basic support, I think one could say that a side effect of error processing is to identify a HA that has MR support. The error processing was not designed with the specific goal to "find" the HA with MR support, but with the goal to try all possible HA's until one replies. > This means MR has to cycle between HA's that have no MR support up to > HA's that do have MR support. > Being more specific during the HA discovery phase (DHAAD), could > improve this situation. Absolutely, having a better nemo-oriented DHAAD may help improve the situation. Having a DHAAD separate document sounds to me like a good idea. Alex GBU From exim@www1.ietf.org Fri Nov 14 08:46:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10136 for ; Fri, 14 Nov 2003 08:46: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 1AKeH0-0007tf-OS for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 08:46:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEDk6Y3030349 for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 08: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 1AKeH0-0007tQ-IW for nemo-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 08: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 IAA10091 for ; Fri, 14 Nov 2003 08:45:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKeGy-0005Hf-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 08:46:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKeGy-0005Hc-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 08:46:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKeGw-0007rJ-VK; Fri, 14 Nov 2003 08: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 1AKeGW-0007qR-GR for nemo@optimus.ietf.org; Fri, 14 Nov 2003 08:45: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 IAA10026 for ; Fri, 14 Nov 2003 08:45:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKeGU-0005Ey-00 for nemo@ietf.org; Fri, 14 Nov 2003 08:45:34 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1AKeGU-0005Ev-00 for nemo@ietf.org; Fri, 14 Nov 2003 08:45:34 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id hAEDjR29016461; Fri, 14 Nov 2003 06:45:30 -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 hAEDixKo011728; Fri, 14 Nov 2003 07:45:05 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 0BCB52EC98; Fri, 14 Nov 2003 14:44:59 +0100 (CET) Message-ID: <3FB4DC5A.7040608@motorola.com> Date: Fri, 14 Nov 2003 14:44:58 +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: tim.leinmueller@daimlerchrysler.com Cc: nemo@ietf.org Subject: Re: [nemo] NEMO DHAAD instead of bit in BAck? References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit tim.leinmueller@daimlerchrysler.com wrote: > Hi all, > > I already talked about NEMO DHAAD with the authors of the basic > support draft and Vijay asked me to post this to the list. > > So far according to the basic support draft, MR discovers HA's that > have MR support, by receiving binding acks with with non-zero status > code. With basic support, I think one could say that a side effect of error processing is to identify a HA that has MR support. The error processing was not designed with the specific goal to "find" the HA with MR support, but with the goal to try all possible HA's until one replies. > This means MR has to cycle between HA's that have no MR support up to > HA's that do have MR support. > Being more specific during the HA discovery phase (DHAAD), could > improve this situation. Absolutely, having a better nemo-oriented DHAAD may help improve the situation. Having a DHAAD separate document sounds to me like a good idea. Alex GBU From nemo-admin@ietf.org Fri Nov 14 09:07:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10742 for ; Fri, 14 Nov 2003 09:07: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 1AKebF-0008Ty-Q7; Fri, 14 Nov 2003 09:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKeb6-0008TK-EO for nemo@optimus.ietf.org; Fri, 14 Nov 2003 09:06: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 JAA10707; Fri, 14 Nov 2003 09:06:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKeb2-0005YR-00; Fri, 14 Nov 2003 09:06:48 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AKeb2-0005XU-00; Fri, 14 Nov 2003 09:06:48 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAEE6CxA008351; Fri, 14 Nov 2003 06:06:13 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAEE67Q15529; Fri, 14 Nov 2003 15:06:07 +0100 (MET) Date: Fri, 14 Nov 2003 15:05:06 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF To: Carsten Bormann Cc: Erik Nordmark , James Kempf , nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org In-Reply-To: "Your message with ID" <7AD8D658-164D-11D8-90E6-00039390397C@tzi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > On the other hand, if you always wanted to involve the CN in these > handoffs, we wouldn't need MobileIP. You'd still need one (or more) rendez-vous points aka home agents to handle initial contact and both ends of communication moving at the same time. Erik From exim@www1.ietf.org Fri Nov 14 09:07:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10771 for ; Fri, 14 Nov 2003 09:07: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 1AKebK-000065-NU for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 09:07:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEE76QB000337 for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 09:07:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKebJ-0008WP-7h for nemo-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 09:07: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 JAA10711 for ; Fri, 14 Nov 2003 09:06:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKebH-0005YZ-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 09:07:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKebG-0005YU-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 09:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKebF-0008Ty-Q7; Fri, 14 Nov 2003 09:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKeb6-0008TK-EO for nemo@optimus.ietf.org; Fri, 14 Nov 2003 09:06: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 JAA10707; Fri, 14 Nov 2003 09:06:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKeb2-0005YR-00; Fri, 14 Nov 2003 09:06:48 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AKeb2-0005XU-00; Fri, 14 Nov 2003 09:06:48 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAEE6CxA008351; Fri, 14 Nov 2003 06:06:13 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAEE67Q15529; Fri, 14 Nov 2003 15:06:07 +0100 (MET) Date: Fri, 14 Nov 2003 15:05:06 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] Re: [Mipshop] Minutes of Multiple Link Flows BAR BOF To: Carsten Bormann Cc: Erik Nordmark , James Kempf , nemo@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org In-Reply-To: "Your message with ID" <7AD8D658-164D-11D8-90E6-00039390397C@tzi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , > On the other hand, if you always wanted to involve the CN in these > handoffs, we wouldn't need MobileIP. You'd still need one (or more) rendez-vous points aka home agents to handle initial contact and both ends of communication moving at the same time. Erik From nemo-admin@ietf.org Fri Nov 14 10:40:12 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16297 for ; Fri, 14 Nov 2003 10:40:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg1W-0007uC-KV; Fri, 14 Nov 2003 10:38:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfzo-0007k5-JR for nemo@optimus.ietf.org; Fri, 14 Nov 2003 10:36: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 KAA16128 for ; Fri, 14 Nov 2003 10:36:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKfzb-0007GF-00 for nemo@ietf.org; Fri, 14 Nov 2003 10:36:15 -0500 Received: from dyn135-227.ietf58.ietf.org ([130.129.135.227] helo=squirrel.psl.com.sg) by ietf-mx with esmtp (Exim 4.12) id 1AKfza-0007GA-00 for nemo@ietf.org; Fri, 14 Nov 2003 10:36:14 -0500 Received: by squirrel.psl.com.sg (Postfix, from userid 1000) id 90C2310BA2CF; Fri, 14 Nov 2003 23:31:31 +0800 (SGT) Subject: Re: [nemo] Issue 17 - Resolution From: Chan-Wah NG To: Vijay Devarapalli Cc: IETF NEMO WG In-Reply-To: <3FB3DAD1.9030607@iprg.nokia.com> References: <3FB3DAD1.9030607@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1068823890.1641.11.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 14 Nov 2003 23:31:31 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Fri, 2003-11-14 at 03:26, Vijay Devarapalli wrote: > hi all, > > Chan-Wah had proposed relaxing the MUST requirement for protecting > all tunneled routing protocol messages through ESP. I presented this > at the WG meeting yesterday. nobody seemed to have an opinion on > this. I am fine with relaxing the requirement to SHOULD. To be exact, I proposed "MUST support and SHOULD use ESP". This means they have a common baseline to use ESP security mechanism, but can opt to use other mechanisms. > > also, the issue also contained some comments from Chan-Wah to add a > section on Binding Ack status values will be added to the IANA > considerations section. that has also been accepted. > Great, so issue closed. Thanks for the work, Vivay, /rgds /cwng From exim@www1.ietf.org Fri Nov 14 10:40:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16312 for ; Fri, 14 Nov 2003 10:40: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 1AKg3D-00087J-CL for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 10:40:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEFdxan031195 for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 10:39:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg3C-00086z-9C for nemo-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 10:39: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 KAA16253 for ; Fri, 14 Nov 2003 10:39:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKg39-0007Lo-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 10:39:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKg39-0007Ll-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 10:39:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg1W-0007uC-KV; Fri, 14 Nov 2003 10:38:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfzo-0007k5-JR for nemo@optimus.ietf.org; Fri, 14 Nov 2003 10:36: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 KAA16128 for ; Fri, 14 Nov 2003 10:36:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKfzb-0007GF-00 for nemo@ietf.org; Fri, 14 Nov 2003 10:36:15 -0500 Received: from dyn135-227.ietf58.ietf.org ([130.129.135.227] helo=squirrel.psl.com.sg) by ietf-mx with esmtp (Exim 4.12) id 1AKfza-0007GA-00 for nemo@ietf.org; Fri, 14 Nov 2003 10:36:14 -0500 Received: by squirrel.psl.com.sg (Postfix, from userid 1000) id 90C2310BA2CF; Fri, 14 Nov 2003 23:31:31 +0800 (SGT) Subject: Re: [nemo] Issue 17 - Resolution From: Chan-Wah NG To: Vijay Devarapalli Cc: IETF NEMO WG In-Reply-To: <3FB3DAD1.9030607@iprg.nokia.com> References: <3FB3DAD1.9030607@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1068823890.1641.11.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 14 Nov 2003 23:31:31 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Fri, 2003-11-14 at 03:26, Vijay Devarapalli wrote: > hi all, > > Chan-Wah had proposed relaxing the MUST requirement for protecting > all tunneled routing protocol messages through ESP. I presented this > at the WG meeting yesterday. nobody seemed to have an opinion on > this. I am fine with relaxing the requirement to SHOULD. To be exact, I proposed "MUST support and SHOULD use ESP". This means they have a common baseline to use ESP security mechanism, but can opt to use other mechanisms. > > also, the issue also contained some comments from Chan-Wah to add a > section on Binding Ack status values will be added to the IANA > considerations section. that has also been accepted. > Great, so issue closed. Thanks for the work, Vivay, /rgds /cwng From nemo-admin@ietf.org Fri Nov 14 10:43:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16536 for ; Fri, 14 Nov 2003 10:43: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 1AKg6E-0008MS-Oh; Fri, 14 Nov 2003 10:43:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg5F-0008LQ-Or for nemo@optimus.ietf.org; Fri, 14 Nov 2003 10:42: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 KAA16468 for ; Fri, 14 Nov 2003 10:41:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKg5D-0007Oz-00 for nemo@ietf.org; Fri, 14 Nov 2003 10:42:03 -0500 Received: from dyn135-227.ietf58.ietf.org ([130.129.135.227] helo=squirrel.psl.com.sg) by ietf-mx with esmtp (Exim 4.12) id 1AKg5C-0007Ow-00 for nemo@ietf.org; Fri, 14 Nov 2003 10:42:02 -0500 Received: by squirrel.psl.com.sg (Postfix, from userid 1000) id AC0E410BA2CF; Fri, 14 Nov 2003 23:37:24 +0800 (SGT) Subject: Re: [nemo] Closing Issue 19 From: Chan-Wah NG To: Vijay Devarapalli Cc: IETF NEMO WG , matsumoto.taisuke@jp.panasonic.com In-Reply-To: <3FB3E282.60407@iprg.nokia.com> References: <3FB3E282.60407@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1068824244.1641.14.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 14 Nov 2003 23:37:24 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Vijay, Matsumoto-san, I feel more comfortable if the text specify that this relaxation is done only when the 'R' bit is set in the BU. /rgds /cwng On Fri, 2003-11-14 at 03:58, Vijay Devarapalli wrote: > hi, > > a new section has been added to section 6.2 to close this issue. > > - Mobile IPv6 specification [1] requires that the Home Address in > the Binding Update should be configured from a prefix advertised > on the home link. Otherwise the Binding Update is rejected > with status value 132 [1]. This specifications relaxes this > requirement so that the Home Agent rejects the Binding Update > only if Home Address does not belong to the prefix that the Home > Agent is configured to serve. > > the details are at http://people.nokia.net/vijayd/nemo/issue19.txt > > Vijay > > > > From exim@www1.ietf.org Fri Nov 14 10:43:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16566 for ; Fri, 14 Nov 2003 10:43: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 1AKg6T-0008PW-Le for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 10:43:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEFhLYU032326 for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 10:43:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg6T-0008Oz-Di for nemo-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 10:43: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 KAA16519 for ; Fri, 14 Nov 2003 10:43:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKg6R-0007Pe-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 10:43:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKg6Q-0007PZ-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 10:43:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg6E-0008MS-Oh; Fri, 14 Nov 2003 10:43:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg5F-0008LQ-Or for nemo@optimus.ietf.org; Fri, 14 Nov 2003 10:42: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 KAA16468 for ; Fri, 14 Nov 2003 10:41:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKg5D-0007Oz-00 for nemo@ietf.org; Fri, 14 Nov 2003 10:42:03 -0500 Received: from dyn135-227.ietf58.ietf.org ([130.129.135.227] helo=squirrel.psl.com.sg) by ietf-mx with esmtp (Exim 4.12) id 1AKg5C-0007Ow-00 for nemo@ietf.org; Fri, 14 Nov 2003 10:42:02 -0500 Received: by squirrel.psl.com.sg (Postfix, from userid 1000) id AC0E410BA2CF; Fri, 14 Nov 2003 23:37:24 +0800 (SGT) Subject: Re: [nemo] Closing Issue 19 From: Chan-Wah NG To: Vijay Devarapalli Cc: IETF NEMO WG , matsumoto.taisuke@jp.panasonic.com In-Reply-To: <3FB3E282.60407@iprg.nokia.com> References: <3FB3E282.60407@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1068824244.1641.14.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 14 Nov 2003 23:37:24 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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 Hello Vijay, Matsumoto-san, I feel more comfortable if the text specify that this relaxation is done only when the 'R' bit is set in the BU. /rgds /cwng On Fri, 2003-11-14 at 03:58, Vijay Devarapalli wrote: > hi, > > a new section has been added to section 6.2 to close this issue. > > - Mobile IPv6 specification [1] requires that the Home Address in > the Binding Update should be configured from a prefix advertised > on the home link. Otherwise the Binding Update is rejected > with status value 132 [1]. This specifications relaxes this > requirement so that the Home Agent rejects the Binding Update > only if Home Address does not belong to the prefix that the Home > Agent is configured to serve. > > the details are at http://people.nokia.net/vijayd/nemo/issue19.txt > > Vijay > > > > From nemo-admin@ietf.org Fri Nov 14 10:46:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16703 for ; Fri, 14 Nov 2003 10:46: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 1AKg93-00008f-Sv; Fri, 14 Nov 2003 10:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg8d-00007i-GU for nemo@optimus.ietf.org; Fri, 14 Nov 2003 10:45:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16663 for ; Fri, 14 Nov 2003 10:45:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKg8a-0007Rr-00 for nemo@ietf.org; Fri, 14 Nov 2003 10:45:32 -0500 Received: from dyn135-227.ietf58.ietf.org ([130.129.135.227] helo=squirrel.psl.com.sg) by ietf-mx with esmtp (Exim 4.12) id 1AKg8V-0007Ro-00 for nemo@ietf.org; Fri, 14 Nov 2003 10:45:32 -0500 Received: by squirrel.psl.com.sg (Postfix, from userid 1000) id 9E9E310BA2CF; Fri, 14 Nov 2003 23:40:44 +0800 (SGT) Subject: Re: [nemo] Closing Issue 19 From: Chan-Wah NG To: Alexandru Petrescu Cc: Vijay Devarapalli , IETF NEMO WG , matsumoto.taisuke@jp.panasonic.com In-Reply-To: <3FB4AEC2.9020203@motorola.com> References: <3FB3E282.60407@iprg.nokia.com> <3FB420E0.8010403@motorola.com> <3FB43013.1020002@iprg.nokia.com> <3FB4AEC2.9020203@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1068824444.1627.19.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 14 Nov 2003 23:40:44 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Vijay, Matsumoto-san, Alex, Perhaps "does not belong to one of the prefixes that the home agent is configured to serve" might clear ALex's initial question? (unless it really is intended that HA only serve one prefix, which then I WOULD have an issue ;)) /rgds /cwng On Fri, 2003-11-14 at 18:30, Alexandru Petrescu wrote: > Vijay Devarapalli wrote: > >>> - Mobile IPv6 specification [1] requires that the Home Address in > >>> the Binding Update should be configured from a prefix advertised on > >>> the home link. Otherwise the Binding Update is rejected with status > >>> value 132 [1]. This specifications relaxes this requirement so that > >>> the Home Agent rejects the Binding Update only if Home Address does > >>> not belong to the prefix that the Home Agent is configured to serve. > >> > >> Looks reasonable. > >> > >> In the abssence of a precise definition of "serve", it makes me > >> think that HA might "serve" only one prefix. Is this the intended > >> meaning? > > > > "configured to serve", I think, is clear enough. > > Ok, short texts are just fine. > > Alex > > > From exim@www1.ietf.org Fri Nov 14 10:46:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16721 for ; Fri, 14 Nov 2003 10:46: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 1AKg97-0000AT-7T for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 10:46:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEFk5Fv000639 for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 10:46:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg96-0000AE-Ti for nemo-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 10:46: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 KAA16695 for ; Fri, 14 Nov 2003 10:45:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKg94-0007Ue-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 10:46:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKg94-0007Ub-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 10:46:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg93-00008f-Sv; Fri, 14 Nov 2003 10:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg8d-00007i-GU for nemo@optimus.ietf.org; Fri, 14 Nov 2003 10:45:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16663 for ; Fri, 14 Nov 2003 10:45:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKg8a-0007Rr-00 for nemo@ietf.org; Fri, 14 Nov 2003 10:45:32 -0500 Received: from dyn135-227.ietf58.ietf.org ([130.129.135.227] helo=squirrel.psl.com.sg) by ietf-mx with esmtp (Exim 4.12) id 1AKg8V-0007Ro-00 for nemo@ietf.org; Fri, 14 Nov 2003 10:45:32 -0500 Received: by squirrel.psl.com.sg (Postfix, from userid 1000) id 9E9E310BA2CF; Fri, 14 Nov 2003 23:40:44 +0800 (SGT) Subject: Re: [nemo] Closing Issue 19 From: Chan-Wah NG To: Alexandru Petrescu Cc: Vijay Devarapalli , IETF NEMO WG , matsumoto.taisuke@jp.panasonic.com In-Reply-To: <3FB4AEC2.9020203@motorola.com> References: <3FB3E282.60407@iprg.nokia.com> <3FB420E0.8010403@motorola.com> <3FB43013.1020002@iprg.nokia.com> <3FB4AEC2.9020203@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1068824444.1627.19.camel@squirrel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 14 Nov 2003 23:40:44 +0800 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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 Hello Vijay, Matsumoto-san, Alex, Perhaps "does not belong to one of the prefixes that the home agent is configured to serve" might clear ALex's initial question? (unless it really is intended that HA only serve one prefix, which then I WOULD have an issue ;)) /rgds /cwng On Fri, 2003-11-14 at 18:30, Alexandru Petrescu wrote: > Vijay Devarapalli wrote: > >>> - Mobile IPv6 specification [1] requires that the Home Address in > >>> the Binding Update should be configured from a prefix advertised on > >>> the home link. Otherwise the Binding Update is rejected with status > >>> value 132 [1]. This specifications relaxes this requirement so that > >>> the Home Agent rejects the Binding Update only if Home Address does > >>> not belong to the prefix that the Home Agent is configured to serve. > >> > >> Looks reasonable. > >> > >> In the abssence of a precise definition of "serve", it makes me > >> think that HA might "serve" only one prefix. Is this the intended > >> meaning? > > > > "configured to serve", I think, is clear enough. > > Ok, short texts are just fine. > > Alex > > > From nemo-admin@ietf.org Fri Nov 14 10:56:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17030 for ; Fri, 14 Nov 2003 10:56: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 1AKgIi-0000k8-Op; Fri, 14 Nov 2003 10:56:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgI1-0000gJ-Ve for nemo@optimus.ietf.org; Fri, 14 Nov 2003 10:55: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 KAA16944 for ; Fri, 14 Nov 2003 10:55:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKgHz-0007Zl-00 for nemo@ietf.org; Fri, 14 Nov 2003 10:55:15 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AKgHy-0007Zg-00 for nemo@ietf.org; Fri, 14 Nov 2003 10:55:14 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hAEFt6ud003668; Fri, 14 Nov 2003 08:55:07 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hAEFt450028517; Fri, 14 Nov 2003 09:55:05 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id AEA992EC95; Fri, 14 Nov 2003 16:55:03 +0100 (CET) Message-ID: <3FB4FAD7.7060003@motorola.com> Date: Fri, 14 Nov 2003 16:55:03 +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: Chan-Wah NG Cc: Vijay Devarapalli , IETF NEMO WG Subject: Re: [nemo] Issue 17 - Resolution References: <3FB3DAD1.9030607@iprg.nokia.com> <1068823890.1641.11.camel@squirrel> In-Reply-To: <1068823890.1641.11.camel@squirrel> 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 Chan-Wah NG wrote: > On Fri, 2003-11-14 at 03:26, Vijay Devarapalli wrote: > >> hi all, >> >> Chan-Wah had proposed relaxing the MUST requirement for protecting >> all tunneled routing protocol messages through ESP. I presented >> this at the WG meeting yesterday. nobody seemed to have an opinion >> on this. I am fine with relaxing the requirement to SHOULD. > > > To be exact, I proposed "MUST support and SHOULD use ESP". This > means they have a common baseline to use ESP security mechanism, but > can opt to use other mechanisms. YEs, that is what I understand from your email too, Chan-Wah. You were proposing "MUST support _and_ SHOULD use ESP". Now that the slides are out, I did not understand very well from Vijay's slides the suggestion that, because AR link may be encrypted then ESP would be less necessary. I think that closing this issue should be done not only by replacing the MUST with a SHOULD, but also by stating that the ESP MUST be supported by both MR and HA. Currently, pre02 only does the former. Alex GBU From exim@www1.ietf.org Fri Nov 14 10:56:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17047 for ; Fri, 14 Nov 2003 10:56: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 1AKgIn-0000l6-1J for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 10:56:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEFu5Le002910 for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 10:56:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgIm-0000kr-R2 for nemo-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 10: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 KAA17013 for ; Fri, 14 Nov 2003 10:55:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKgIk-0007aM-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 10:56:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKgIk-0007aJ-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 10:56:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgIi-0000k8-Op; Fri, 14 Nov 2003 10:56:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgI1-0000gJ-Ve for nemo@optimus.ietf.org; Fri, 14 Nov 2003 10:55: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 KAA16944 for ; Fri, 14 Nov 2003 10:55:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKgHz-0007Zl-00 for nemo@ietf.org; Fri, 14 Nov 2003 10:55:15 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AKgHy-0007Zg-00 for nemo@ietf.org; Fri, 14 Nov 2003 10:55:14 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hAEFt6ud003668; Fri, 14 Nov 2003 08:55:07 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hAEFt450028517; Fri, 14 Nov 2003 09:55:05 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id AEA992EC95; Fri, 14 Nov 2003 16:55:03 +0100 (CET) Message-ID: <3FB4FAD7.7060003@motorola.com> Date: Fri, 14 Nov 2003 16:55:03 +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: Chan-Wah NG Cc: Vijay Devarapalli , IETF NEMO WG Subject: Re: [nemo] Issue 17 - Resolution References: <3FB3DAD1.9030607@iprg.nokia.com> <1068823890.1641.11.camel@squirrel> In-Reply-To: <1068823890.1641.11.camel@squirrel> 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 Chan-Wah NG wrote: > On Fri, 2003-11-14 at 03:26, Vijay Devarapalli wrote: > >> hi all, >> >> Chan-Wah had proposed relaxing the MUST requirement for protecting >> all tunneled routing protocol messages through ESP. I presented >> this at the WG meeting yesterday. nobody seemed to have an opinion >> on this. I am fine with relaxing the requirement to SHOULD. > > > To be exact, I proposed "MUST support and SHOULD use ESP". This > means they have a common baseline to use ESP security mechanism, but > can opt to use other mechanisms. YEs, that is what I understand from your email too, Chan-Wah. You were proposing "MUST support _and_ SHOULD use ESP". Now that the slides are out, I did not understand very well from Vijay's slides the suggestion that, because AR link may be encrypted then ESP would be less necessary. I think that closing this issue should be done not only by replacing the MUST with a SHOULD, but also by stating that the ESP MUST be supported by both MR and HA. Currently, pre02 only does the former. Alex GBU From nemo-admin@ietf.org Fri Nov 14 11:16:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18212 for ; Fri, 14 Nov 2003 11: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 1AKgc4-00036M-9r; Fri, 14 Nov 2003 11:16:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgbN-000354-Sp for nemo@optimus.ietf.org; Fri, 14 Nov 2003 11:15: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 LAA18136 for ; Fri, 14 Nov 2003 11:15:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKgbM-0000AT-00 for nemo@ietf.org; Fri, 14 Nov 2003 11:15:17 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AKgbM-0000AQ-00 for nemo@ietf.org; Fri, 14 Nov 2003 11:15:16 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hAEGEAYT015263; Fri, 14 Nov 2003 09:14:11 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id hAEGF9BJ009515; Fri, 14 Nov 2003 10:15:10 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 1EC242EC95; Fri, 14 Nov 2003 17:15:09 +0100 (CET) Message-ID: <3FB4FF8C.4080904@motorola.com> Date: Fri, 14 Nov 2003 17:15: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: Chan-Wah NG Cc: Alexandru Petrescu , Vijay Devarapalli , IETF NEMO WG , matsumoto.taisuke@jp.panasonic.com Subject: Re: [nemo] Closing Issue 19 References: <3FB3E282.60407@iprg.nokia.com> <3FB420E0.8010403@motorola.com> <3FB43013.1020002@iprg.nokia.com> <3FB4AEC2.9020203@motorola.com> <1068824444.1627.19.camel@squirrel> In-Reply-To: <1068824444.1627.19.camel@squirrel> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I'm replying _only_ if it does not involve additions of text to the basic spec. I don't like endless discussions that add large paragraphs of text to specs that are little help for implementors. Chan-Wah NG wrote: > Perhaps "does not belong to one of the prefixes that the home agent > is configured to serve" might clear ALex's initial question? Does not belong to at least one? Does not belong to only one? Does not belong to all of them? :-) (Checking that a full /128 address "belongs" to some set of prefixes is something that happens in the "forwarding" procedure and in that case it involves "longest prefix match".) In order for this check to be effective, maybe more detail is needed to explain how, in explicit prefix len mode, the HA checks the Home Address received in a MR's BU. Maybe this can be included in the home-network-usages document. > (unless it really is intended that HA only serve one prefix, which > then I WOULD have an issue ;)) Yes, exactly. Alex GBU From exim@www1.ietf.org Fri Nov 14 11:16:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18234 for ; Fri, 14 Nov 2003 11:16: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 1AKgcC-00037h-Vj for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 11:16:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEGG8i6011999 for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 11:16:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgcC-00037S-R1 for nemo-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 11:16: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 LAA18184 for ; Fri, 14 Nov 2003 11:15:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKgcB-0000DL-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 11:16:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKgcB-0000DI-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 11:16:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgc4-00036M-9r; Fri, 14 Nov 2003 11:16:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKgbN-000354-Sp for nemo@optimus.ietf.org; Fri, 14 Nov 2003 11:15: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 LAA18136 for ; Fri, 14 Nov 2003 11:15:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKgbM-0000AT-00 for nemo@ietf.org; Fri, 14 Nov 2003 11:15:17 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AKgbM-0000AQ-00 for nemo@ietf.org; Fri, 14 Nov 2003 11:15:16 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hAEGEAYT015263; Fri, 14 Nov 2003 09:14:11 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id hAEGF9BJ009515; Fri, 14 Nov 2003 10:15:10 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 1EC242EC95; Fri, 14 Nov 2003 17:15:09 +0100 (CET) Message-ID: <3FB4FF8C.4080904@motorola.com> Date: Fri, 14 Nov 2003 17:15: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: Chan-Wah NG Cc: Alexandru Petrescu , Vijay Devarapalli , IETF NEMO WG , matsumoto.taisuke@jp.panasonic.com Subject: Re: [nemo] Closing Issue 19 References: <3FB3E282.60407@iprg.nokia.com> <3FB420E0.8010403@motorola.com> <3FB43013.1020002@iprg.nokia.com> <3FB4AEC2.9020203@motorola.com> <1068824444.1627.19.camel@squirrel> In-Reply-To: <1068824444.1627.19.camel@squirrel> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I'm replying _only_ if it does not involve additions of text to the basic spec. I don't like endless discussions that add large paragraphs of text to specs that are little help for implementors. Chan-Wah NG wrote: > Perhaps "does not belong to one of the prefixes that the home agent > is configured to serve" might clear ALex's initial question? Does not belong to at least one? Does not belong to only one? Does not belong to all of them? :-) (Checking that a full /128 address "belongs" to some set of prefixes is something that happens in the "forwarding" procedure and in that case it involves "longest prefix match".) In order for this check to be effective, maybe more detail is needed to explain how, in explicit prefix len mode, the HA checks the Home Address received in a MR's BU. Maybe this can be included in the home-network-usages document. > (unless it really is intended that HA only serve one prefix, which > then I WOULD have an issue ;)) Yes, exactly. Alex GBU From nemo-admin@ietf.org Fri Nov 14 20:04:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07698 for ; Fri, 14 Nov 2003 20:04: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 1AKor3-0000Za-6V; Fri, 14 Nov 2003 20:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKoq4-0000Yb-16 for nemo@optimus.ietf.org; Fri, 14 Nov 2003 20:03: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 UAA07674 for ; Fri, 14 Nov 2003 20:02:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKoq1-0007Ty-00 for nemo@ietf.org; Fri, 14 Nov 2003 20:02:58 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKoq1-0007To-00 for nemo@ietf.org; Fri, 14 Nov 2003 20:02:57 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAF12II17743; Fri, 14 Nov 2003 17:02:18 -0800 X-mProtect: <200311150102> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdb3GsDQ; Fri, 14 Nov 2003 17:02:17 PST Message-ID: <3FB57C07.9020300@iprg.nokia.com> Date: Fri, 14 Nov 2003 17:06: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: Chan-Wah NG CC: IETF NEMO WG , matsumoto.taisuke@jp.panasonic.com Subject: Re: [nemo] Closing Issue 19 References: <3FB3E282.60407@iprg.nokia.com> <1068824244.1641.14.camel@squirrel> In-Reply-To: <1068824244.1641.14.camel@squirrel> 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 Chan-Wah NG wrote: > Hello Vijay, Matsumoto-san, > > I feel more comfortable if the text specify that this relaxation is done > only when the 'R' bit is set in the BU. see the entire section 6.2. the first paragraph says The Home Agent processes the Binding Update as described in section 10.3.1 of the Mobile IPv6 specification [1]. This section describes the processing of the Binding Update if the Mobile Router (R) flag is set. The Home Agent performs the following check in addition. Vijay > > /rgds > /cwng > > > On Fri, 2003-11-14 at 03:58, Vijay Devarapalli wrote: > >>hi, >> >>a new section has been added to section 6.2 to close this issue. >> >> - Mobile IPv6 specification [1] requires that the Home Address in >> the Binding Update should be configured from a prefix advertised >> on the home link. Otherwise the Binding Update is rejected >> with status value 132 [1]. This specifications relaxes this >> requirement so that the Home Agent rejects the Binding Update >> only if Home Address does not belong to the prefix that the Home >> Agent is configured to serve. >> >>the details are at http://people.nokia.net/vijayd/nemo/issue19.txt >> >>Vijay >> >> >> >> From exim@www1.ietf.org Fri Nov 14 20:04:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07719 for ; Fri, 14 Nov 2003 20:04: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 1AKor7-0000ac-NA for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 20:04:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAF145f7002262 for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 20:04:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKor7-0000aP-HF for nemo-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 20:04:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07691 for ; Fri, 14 Nov 2003 20:03:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKor5-0007UY-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 20:04:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKor5-0007UU-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 20:04:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKor3-0000Za-6V; Fri, 14 Nov 2003 20:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKoq4-0000Yb-16 for nemo@optimus.ietf.org; Fri, 14 Nov 2003 20:03: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 UAA07674 for ; Fri, 14 Nov 2003 20:02:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKoq1-0007Ty-00 for nemo@ietf.org; Fri, 14 Nov 2003 20:02:58 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKoq1-0007To-00 for nemo@ietf.org; Fri, 14 Nov 2003 20:02:57 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAF12II17743; Fri, 14 Nov 2003 17:02:18 -0800 X-mProtect: <200311150102> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdb3GsDQ; Fri, 14 Nov 2003 17:02:17 PST Message-ID: <3FB57C07.9020300@iprg.nokia.com> Date: Fri, 14 Nov 2003 17:06: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: Chan-Wah NG CC: IETF NEMO WG , matsumoto.taisuke@jp.panasonic.com Subject: Re: [nemo] Closing Issue 19 References: <3FB3E282.60407@iprg.nokia.com> <1068824244.1641.14.camel@squirrel> In-Reply-To: <1068824244.1641.14.camel@squirrel> 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 Chan-Wah NG wrote: > Hello Vijay, Matsumoto-san, > > I feel more comfortable if the text specify that this relaxation is done > only when the 'R' bit is set in the BU. see the entire section 6.2. the first paragraph says The Home Agent processes the Binding Update as described in section 10.3.1 of the Mobile IPv6 specification [1]. This section describes the processing of the Binding Update if the Mobile Router (R) flag is set. The Home Agent performs the following check in addition. Vijay > > /rgds > /cwng > > > On Fri, 2003-11-14 at 03:58, Vijay Devarapalli wrote: > >>hi, >> >>a new section has been added to section 6.2 to close this issue. >> >> - Mobile IPv6 specification [1] requires that the Home Address in >> the Binding Update should be configured from a prefix advertised >> on the home link. Otherwise the Binding Update is rejected >> with status value 132 [1]. This specifications relaxes this >> requirement so that the Home Agent rejects the Binding Update >> only if Home Address does not belong to the prefix that the Home >> Agent is configured to serve. >> >>the details are at http://people.nokia.net/vijayd/nemo/issue19.txt >> >>Vijay >> >> >> >> From nemo-admin@ietf.org Fri Nov 14 20:09:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07873 for ; Fri, 14 Nov 2003 20:09: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 1AKovt-0001IK-Fq; Fri, 14 Nov 2003 20: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 1AKovN-0001I4-VM for nemo@optimus.ietf.org; Fri, 14 Nov 2003 20:08: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 UAA07833 for ; Fri, 14 Nov 2003 20:08:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKovL-0007Xk-00 for nemo@ietf.org; Fri, 14 Nov 2003 20:08:27 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKovL-0007Wi-00 for nemo@ietf.org; Fri, 14 Nov 2003 20:08:27 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAF17s220091; Fri, 14 Nov 2003 17:07:54 -0800 X-mProtect: <200311150107> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkjHE3h; Fri, 14 Nov 2003 17:07:52 PST Message-ID: <3FB57D56.5070700@iprg.nokia.com> Date: Fri, 14 Nov 2003 17:11:50 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MATSUMOTO Taisuke CC: Alexandru Petrescu , nemo@ietf.org Subject: Re: [nemo] Closing Issue 19 References: <3FB3E282.60407@iprg.nokia.com> <3FB420E0.8010403@motorola.com> <3FB43013.1020002@iprg.nokia.com> <200311140358.hAE3wA2t063545@mrit.mrit.mei.co.jp> In-Reply-To: <200311140358.hAE3wA2t063545@mrit.mrit.mei.co.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 MATSUMOTO Taisuke wrote: > Dear Vijay and all, > > At Thu, 13 Nov 2003 17:29:55 -0800, "Vijay Devarapalli" wrote : > >>>In the abssence of a precise definition of "serve", it makes me >>>think that HA might "serve" only one prefix. Is this the intended >>>meaning? >> >>"configured to serve", I think, is clear enough. > > > Agree. > And "How to configure" is an operational matter, isn't it? right. Vijay From exim@www1.ietf.org Fri Nov 14 20:09:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07888 for ; Fri, 14 Nov 2003 20:09: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 1AKovu-0001KY-Pb for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 20:09:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAF192Lt005108 for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 20:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKovu-0001KJ-Jf for nemo-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 20:09: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 UAA07851 for ; Fri, 14 Nov 2003 20:08:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKovs-0007Xs-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 20:09:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKovs-0007Xp-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 20:09:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKovt-0001IK-Fq; Fri, 14 Nov 2003 20: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 1AKovN-0001I4-VM for nemo@optimus.ietf.org; Fri, 14 Nov 2003 20:08: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 UAA07833 for ; Fri, 14 Nov 2003 20:08:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKovL-0007Xk-00 for nemo@ietf.org; Fri, 14 Nov 2003 20:08:27 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKovL-0007Wi-00 for nemo@ietf.org; Fri, 14 Nov 2003 20:08:27 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAF17s220091; Fri, 14 Nov 2003 17:07:54 -0800 X-mProtect: <200311150107> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkjHE3h; Fri, 14 Nov 2003 17:07:52 PST Message-ID: <3FB57D56.5070700@iprg.nokia.com> Date: Fri, 14 Nov 2003 17:11:50 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MATSUMOTO Taisuke CC: Alexandru Petrescu , nemo@ietf.org Subject: Re: [nemo] Closing Issue 19 References: <3FB3E282.60407@iprg.nokia.com> <3FB420E0.8010403@motorola.com> <3FB43013.1020002@iprg.nokia.com> <200311140358.hAE3wA2t063545@mrit.mrit.mei.co.jp> In-Reply-To: <200311140358.hAE3wA2t063545@mrit.mrit.mei.co.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 MATSUMOTO Taisuke wrote: > Dear Vijay and all, > > At Thu, 13 Nov 2003 17:29:55 -0800, "Vijay Devarapalli" wrote : > >>>In the abssence of a precise definition of "serve", it makes me >>>think that HA might "serve" only one prefix. Is this the intended >>>meaning? >> >>"configured to serve", I think, is clear enough. > > > Agree. > And "How to configure" is an operational matter, isn't it? right. Vijay From nemo-admin@ietf.org Fri Nov 14 20:14:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08012 for ; Fri, 14 Nov 2003 20:14: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 1AKp0k-0001Ud-Od; Fri, 14 Nov 2003 20: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 1AKp0U-0001Tz-Gv for nemo@optimus.ietf.org; Fri, 14 Nov 2003 20: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 UAA07995 for ; Fri, 14 Nov 2003 20:13:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKp0S-0007ay-00 for nemo@ietf.org; Fri, 14 Nov 2003 20:13:44 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKp0R-0007ap-00 for nemo@ietf.org; Fri, 14 Nov 2003 20:13:43 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAF1D7k23188; Fri, 14 Nov 2003 17:13:07 -0800 X-mProtect: <200311150113> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdfsDO3p; Fri, 14 Nov 2003 17:13:05 PST Message-ID: <3FB57E8F.5040402@iprg.nokia.com> Date: Fri, 14 Nov 2003 17:17: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: Chan-Wah NG CC: IETF NEMO WG Subject: Re: [nemo] Issue 17 - Resolution References: <3FB3DAD1.9030607@iprg.nokia.com> <1068823890.1641.11.camel@squirrel> In-Reply-To: <1068823890.1641.11.camel@squirrel> 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 Chan-Wah NG wrote: > On Fri, 2003-11-14 at 03:26, Vijay Devarapalli wrote: > >>hi all, >> >>Chan-Wah had proposed relaxing the MUST requirement for protecting >>all tunneled routing protocol messages through ESP. I presented this >>at the WG meeting yesterday. nobody seemed to have an opinion on >>this. I am fine with relaxing the requirement to SHOULD. > > > To be exact, I proposed "MUST support and SHOULD use ESP". This means > they have a common baseline to use ESP security mechanism, but can opt > to use other mechanisms. changed it to "MUST support and SHOULD use". Vijay From exim@www1.ietf.org Fri Nov 14 20:14:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08039 for ; Fri, 14 Nov 2003 20:14: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 1AKp0m-0001XN-TL for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 20:14:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAF1E4f8005903 for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 20: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 1AKp0m-0001X1-M4 for nemo-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 20: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 UAA08000 for ; Fri, 14 Nov 2003 20:13:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKp0k-0007b4-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 20:14:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKp0k-0007b1-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 20:14:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKp0k-0001Ud-Od; Fri, 14 Nov 2003 20: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 1AKp0U-0001Tz-Gv for nemo@optimus.ietf.org; Fri, 14 Nov 2003 20: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 UAA07995 for ; Fri, 14 Nov 2003 20:13:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKp0S-0007ay-00 for nemo@ietf.org; Fri, 14 Nov 2003 20:13:44 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKp0R-0007ap-00 for nemo@ietf.org; Fri, 14 Nov 2003 20:13:43 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAF1D7k23188; Fri, 14 Nov 2003 17:13:07 -0800 X-mProtect: <200311150113> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdfsDO3p; Fri, 14 Nov 2003 17:13:05 PST Message-ID: <3FB57E8F.5040402@iprg.nokia.com> Date: Fri, 14 Nov 2003 17:17: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: Chan-Wah NG CC: IETF NEMO WG Subject: Re: [nemo] Issue 17 - Resolution References: <3FB3DAD1.9030607@iprg.nokia.com> <1068823890.1641.11.camel@squirrel> In-Reply-To: <1068823890.1641.11.camel@squirrel> 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 Chan-Wah NG wrote: > On Fri, 2003-11-14 at 03:26, Vijay Devarapalli wrote: > >>hi all, >> >>Chan-Wah had proposed relaxing the MUST requirement for protecting >>all tunneled routing protocol messages through ESP. I presented this >>at the WG meeting yesterday. nobody seemed to have an opinion on >>this. I am fine with relaxing the requirement to SHOULD. > > > To be exact, I proposed "MUST support and SHOULD use ESP". This means > they have a common baseline to use ESP security mechanism, but can opt > to use other mechanisms. changed it to "MUST support and SHOULD use". Vijay From nemo-admin@ietf.org Fri Nov 14 20:17:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08241 for ; Fri, 14 Nov 2003 20: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 1AKp3d-00022h-GY; Fri, 14 Nov 2003 20: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 1AKp3M-00022F-6r for nemo@optimus.ietf.org; Fri, 14 Nov 2003 20:16: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 UAA08204 for ; Fri, 14 Nov 2003 20:16:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKp3K-0007gy-00 for nemo@ietf.org; Fri, 14 Nov 2003 20:16:42 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKp3J-0007gF-00 for nemo@ietf.org; Fri, 14 Nov 2003 20:16:41 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAF1G9L25070; Fri, 14 Nov 2003 17:16:09 -0800 X-mProtect: <200311150116> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd1BM2i9; Fri, 14 Nov 2003 17:16:08 PST Message-ID: <3FB57F46.10202@iprg.nokia.com> Date: Fri, 14 Nov 2003 17:20:06 -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: tim.leinmueller@daimlerchrysler.com, nemo@ietf.org Subject: Re: [nemo] NEMO DHAAD instead of bit in BAck? References: <3FB4DC5A.7040608@motorola.com> In-Reply-To: <3FB4DC5A.7040608@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: > tim.leinmueller@daimlerchrysler.com wrote: > >> Hi all, >> >> I already talked about NEMO DHAAD with the authors of the basic >> support draft and Vijay asked me to post this to the list. >> >> So far according to the basic support draft, MR discovers HA's that >> have MR support, by receiving binding acks with with non-zero status >> code. > > > With basic support, I think one could say that a side effect of error > processing is to identify a HA that has MR support. The error > processing was not designed with the specific goal to "find" the HA with > MR support, but with the goal to try all possible HA's until one replies. > >> This means MR has to cycle between HA's that have no MR support up to >> HA's that do have MR support. > > >> Being more specific during the HA discovery phase (DHAAD), could >> improve this situation. > > > Absolutely, having a better nemo-oriented DHAAD may help improve the > situation. > > Having a DHAAD separate document sounds to me like a good idea. IMO, we should add the M flag to the DHAAD messages because interworking with MIPv6 home agents is essential for the Nemo Basic support spec. so the modifications Tim suggested should be added to the current draft. Vijay From exim@www1.ietf.org Fri Nov 14 20:17:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08256 for ; Fri, 14 Nov 2003 20: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 1AKp3e-00024t-LH for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 20:17:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAF1H2gM007981 for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 20:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKp3e-00024e-GK for nemo-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 20:17: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 UAA08211 for ; Fri, 14 Nov 2003 20:16:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKp3c-0007hD-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 20:17:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKp3c-0007hA-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 20: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 1AKp3d-00022h-GY; Fri, 14 Nov 2003 20: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 1AKp3M-00022F-6r for nemo@optimus.ietf.org; Fri, 14 Nov 2003 20:16: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 UAA08204 for ; Fri, 14 Nov 2003 20:16:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKp3K-0007gy-00 for nemo@ietf.org; Fri, 14 Nov 2003 20:16:42 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKp3J-0007gF-00 for nemo@ietf.org; Fri, 14 Nov 2003 20:16:41 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAF1G9L25070; Fri, 14 Nov 2003 17:16:09 -0800 X-mProtect: <200311150116> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd1BM2i9; Fri, 14 Nov 2003 17:16:08 PST Message-ID: <3FB57F46.10202@iprg.nokia.com> Date: Fri, 14 Nov 2003 17:20:06 -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: tim.leinmueller@daimlerchrysler.com, nemo@ietf.org Subject: Re: [nemo] NEMO DHAAD instead of bit in BAck? References: <3FB4DC5A.7040608@motorola.com> In-Reply-To: <3FB4DC5A.7040608@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: > tim.leinmueller@daimlerchrysler.com wrote: > >> Hi all, >> >> I already talked about NEMO DHAAD with the authors of the basic >> support draft and Vijay asked me to post this to the list. >> >> So far according to the basic support draft, MR discovers HA's that >> have MR support, by receiving binding acks with with non-zero status >> code. > > > With basic support, I think one could say that a side effect of error > processing is to identify a HA that has MR support. The error > processing was not designed with the specific goal to "find" the HA with > MR support, but with the goal to try all possible HA's until one replies. > >> This means MR has to cycle between HA's that have no MR support up to >> HA's that do have MR support. > > >> Being more specific during the HA discovery phase (DHAAD), could >> improve this situation. > > > Absolutely, having a better nemo-oriented DHAAD may help improve the > situation. > > Having a DHAAD separate document sounds to me like a good idea. IMO, we should add the M flag to the DHAAD messages because interworking with MIPv6 home agents is essential for the Nemo Basic support spec. so the modifications Tim suggested should be added to the current draft. Vijay From nemo-admin@ietf.org Fri Nov 14 21:59:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11089 for ; Fri, 14 Nov 2003 21:59: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 1AKqeL-0008Ih-Id; Fri, 14 Nov 2003 21: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 1AKqdf-0008Fh-1J for nemo@optimus.ietf.org; Fri, 14 Nov 2003 21:58: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 VAA11025 for ; Fri, 14 Nov 2003 21:58:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKqdc-00017C-00 for nemo@ietf.org; Fri, 14 Nov 2003 21:58:16 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKqdb-00016x-00 for nemo@ietf.org; Fri, 14 Nov 2003 21:58:15 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAF2vi807990; Fri, 14 Nov 2003 18:57:44 -0800 X-mProtect: <200311150257> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgERXcy; Fri, 14 Nov 2003 18:57:42 PST Message-ID: <3FB59714.8020805@iprg.nokia.com> Date: Fri, 14 Nov 2003 19:01:40 -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: tim.leinmueller@daimlerchrysler.com CC: nemo@ietf.org Subject: Re: [nemo] NEMO DHAAD instead of bit in BAck? 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 I agree with Tim here. to close this issue I suggest adding a new section on modifications to Dynamic Home Agent Dicovery messages to the draft. a version of the draft with these modifications is at http://people.nokia.net/vijayd/nemo/nemo_protocol_mod_dhaad.txt there is a new section 7. please comment. I also removed Binding Ack status 2. Vijay tim.leinmueller@daimlerchrysler.com wrote: > Hi all, > > I already talked about NEMO DHAAD with the authors of the basic > support draft and Vijay asked me to post this to the list. > > So far according to the basic support draft, MR discovers HA's that > have MR support, by receiving binding acks with with non-zero status > code. This means MR has to cycle between HA's that have no MR support > up to HA's that do have MR support. > > Being more specific during the HA discovery phase (DHAAD), could > improve this situation. > > I'll attach a text I wrote some time ago, that contains the basic > idea. > > Tim. > > --- NEMO DHAAD --- > Additions to Dynamic Home Agent Address Discovery (DHAAD) > > Since mobile routers need home agents with support for network > mobility, it is of use to extend the existing DHAAD mechanism, to > enable mobile routers to discover home agents supporting mobile > networks. > > The modification consists in adding the mobile router home agent bit M > to the ICMP messages for home agent discovery (figures 2.24 and 2.25) > and to the home agent information option (figure 2.26). > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Code | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Identifier |M| Reserved1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 2.24: Extended ICMP Home Agent Address Discovery Request > Message > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Code | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Identifier |M| Reserved1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > . . > . Home Agent Addresses . > . . > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 2.25: Extended ICMP Home Agent Address Discovery Reply Message > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length |M| Reserved1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Home Agent Preference | Home Agent Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 2.26: Extended Home Agent Information Option Format > > Added to the ICMP home agent address discovery request message, the M > bit serves to indicate, that a mobile router is searching for > suitable home agents with mobile router support. If this request is > received by a normal home agent, it will ignore the M bit and send an > ICMP home agent information discovery reply message as specified in > [1], without the M bit set. This reply includes all known home agents > on the home network, regardless of the support for mobile routers. > Otherwise, if the recipient is a mobile router supporting home agent, > it will discover the M bit and send an extended ICMP home agent > address discovery reply message as response (with the M bit set to > one), containing only home agents with support for mobile networks. > > The M bit in the home agent information option is used to indicate to > other home agents, whether the sending home agent is capable (and From exim@www1.ietf.org Fri Nov 14 21:59:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11107 for ; Fri, 14 Nov 2003 21:59: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 1AKqeP-0008Jg-0p for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 21:59:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAF2x46I031962 for nemo-archive@odin.ietf.org; Fri, 14 Nov 2003 21:59:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKqeO-0008JR-Sv for nemo-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 21:59: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 VAA11074 for ; Fri, 14 Nov 2003 21:58:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKqeL-000188-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 21:59:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKqeL-000185-00 for nemo-web-archive@ietf.org; Fri, 14 Nov 2003 21:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKqeL-0008Ih-Id; Fri, 14 Nov 2003 21: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 1AKqdf-0008Fh-1J for nemo@optimus.ietf.org; Fri, 14 Nov 2003 21:58: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 VAA11025 for ; Fri, 14 Nov 2003 21:58:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKqdc-00017C-00 for nemo@ietf.org; Fri, 14 Nov 2003 21:58:16 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKqdb-00016x-00 for nemo@ietf.org; Fri, 14 Nov 2003 21:58:15 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAF2vi807990; Fri, 14 Nov 2003 18:57:44 -0800 X-mProtect: <200311150257> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgERXcy; Fri, 14 Nov 2003 18:57:42 PST Message-ID: <3FB59714.8020805@iprg.nokia.com> Date: Fri, 14 Nov 2003 19:01:40 -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: tim.leinmueller@daimlerchrysler.com CC: nemo@ietf.org Subject: Re: [nemo] NEMO DHAAD instead of bit in BAck? 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 I agree with Tim here. to close this issue I suggest adding a new section on modifications to Dynamic Home Agent Dicovery messages to the draft. a version of the draft with these modifications is at http://people.nokia.net/vijayd/nemo/nemo_protocol_mod_dhaad.txt there is a new section 7. please comment. I also removed Binding Ack status 2. Vijay tim.leinmueller@daimlerchrysler.com wrote: > Hi all, > > I already talked about NEMO DHAAD with the authors of the basic > support draft and Vijay asked me to post this to the list. > > So far according to the basic support draft, MR discovers HA's that > have MR support, by receiving binding acks with with non-zero status > code. This means MR has to cycle between HA's that have no MR support > up to HA's that do have MR support. > > Being more specific during the HA discovery phase (DHAAD), could > improve this situation. > > I'll attach a text I wrote some time ago, that contains the basic > idea. > > Tim. > > --- NEMO DHAAD --- > Additions to Dynamic Home Agent Address Discovery (DHAAD) > > Since mobile routers need home agents with support for network > mobility, it is of use to extend the existing DHAAD mechanism, to > enable mobile routers to discover home agents supporting mobile > networks. > > The modification consists in adding the mobile router home agent bit M > to the ICMP messages for home agent discovery (figures 2.24 and 2.25) > and to the home agent information option (figure 2.26). > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Code | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Identifier |M| Reserved1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 2.24: Extended ICMP Home Agent Address Discovery Request > Message > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Code | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Identifier |M| Reserved1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > . . > . Home Agent Addresses . > . . > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 2.25: Extended ICMP Home Agent Address Discovery Reply Message > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length |M| Reserved1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Home Agent Preference | Home Agent Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 2.26: Extended Home Agent Information Option Format > > Added to the ICMP home agent address discovery request message, the M > bit serves to indicate, that a mobile router is searching for > suitable home agents with mobile router support. If this request is > received by a normal home agent, it will ignore the M bit and send an > ICMP home agent information discovery reply message as specified in > [1], without the M bit set. This reply includes all known home agents > on the home network, regardless of the support for mobile routers. > Otherwise, if the recipient is a mobile router supporting home agent, > it will discover the M bit and send an extended ICMP home agent > address discovery reply message as response (with the M bit set to > one), containing only home agents with support for mobile networks. > > The M bit in the home agent information option is used to indicate to > other home agents, whether the sending home agent is capable (and From nemo-admin@ietf.org Mon Nov 17 00:20:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19018 for ; Mon, 17 Nov 2003 00:20: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 1ALbnt-0005jh-Pb; Mon, 17 Nov 2003 00:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALbng-0005i8-21 for nemo@optimus.ietf.org; Mon, 17 Nov 2003 00:19: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 AAA19003 for ; Mon, 17 Nov 2003 00:19:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALbnd-00015z-00 for nemo@ietf.org; Mon, 17 Nov 2003 00:19:45 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1ALbnb-00015H-00 for nemo@ietf.org; Mon, 17 Nov 2003 00:19:44 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id hAH5BNqs001865; Mon, 17 Nov 2003 13:11:23 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 3404C10E95DA; Mon, 17 Nov 2003 13:19:07 +0800 (SGT) Subject: Re: [nemo] Closing Issue 19 From: Chan-Wah NG To: Vijay Devarapalli Cc: IETF NEMO WG , matsumoto.taisuke@jp.panasonic.com In-Reply-To: <3FB57C07.9020300@iprg.nokia.com> References: <3FB3E282.60407@iprg.nokia.com> <1068824244.1641.14.camel@squirrel> <3FB57C07.9020300@iprg.nokia.com> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1069046346.1987.0.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 17 Nov 2003 13:19:06 +0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ok. /rgds /cwng On Sat, 2003-11-15 at 09:06, Vijay Devarapalli wrote: > Chan-Wah NG wrote: > > Hello Vijay, Matsumoto-san, > > > > I feel more comfortable if the text specify that this relaxation is done > > only when the 'R' bit is set in the BU. > > see the entire section 6.2. the first paragraph says > > The Home Agent processes the Binding Update as described in section > 10.3.1 of the Mobile IPv6 specification [1]. This section describes > the processing of the Binding Update if the Mobile Router (R) flag is > set. The Home Agent performs the following check in addition. > > Vijay > > > > > /rgds > > /cwng > > > > > > On Fri, 2003-11-14 at 03:58, Vijay Devarapalli wrote: > > > >>hi, > >> > >>a new section has been added to section 6.2 to close this issue. > >> > >> - Mobile IPv6 specification [1] requires that the Home Address in > >> the Binding Update should be configured from a prefix advertised > >> on the home link. Otherwise the Binding Update is rejected > >> with status value 132 [1]. This specifications relaxes this > >> requirement so that the Home Agent rejects the Binding Update > >> only if Home Address does not belong to the prefix that the Home > >> Agent is configured to serve. > >> > >>the details are at http://people.nokia.net/vijayd/nemo/issue19.txt > >> > >>Vijay > >> > >> > >> > >> > > > > From exim@www1.ietf.org Mon Nov 17 00:20:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19040 for ; Mon, 17 Nov 2003 00:20: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 1ALbo0-0005m5-1c for nemo-archive@odin.ietf.org; Mon, 17 Nov 2003 00:20:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAH5K7Jc022191 for nemo-archive@odin.ietf.org; Mon, 17 Nov 2003 00:20:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALbnz-0005ka-9F for nemo-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 00:20: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 AAA19012 for ; Mon, 17 Nov 2003 00:19:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALbnw-00016I-00 for nemo-web-archive@ietf.org; Mon, 17 Nov 2003 00:20:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALbnw-00016E-00 for nemo-web-archive@ietf.org; Mon, 17 Nov 2003 00:20:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALbnt-0005jh-Pb; Mon, 17 Nov 2003 00:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALbng-0005i8-21 for nemo@optimus.ietf.org; Mon, 17 Nov 2003 00:19: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 AAA19003 for ; Mon, 17 Nov 2003 00:19:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALbnd-00015z-00 for nemo@ietf.org; Mon, 17 Nov 2003 00:19:45 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1ALbnb-00015H-00 for nemo@ietf.org; Mon, 17 Nov 2003 00:19:44 -0500 Received: from beethoven.psl.com.sg (beethoven.psl.com.sg [10.81.113.99]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with ESMTP id hAH5BNqs001865; Mon, 17 Nov 2003 13:11:23 +0800 (SGT) Received: from localhost (localhost [127.0.0.1]) by beethoven.psl.com.sg (Postfix) with ESMTP id 3404C10E95DA; Mon, 17 Nov 2003 13:19:07 +0800 (SGT) Subject: Re: [nemo] Closing Issue 19 From: Chan-Wah NG To: Vijay Devarapalli Cc: IETF NEMO WG , matsumoto.taisuke@jp.panasonic.com In-Reply-To: <3FB57C07.9020300@iprg.nokia.com> References: <3FB3E282.60407@iprg.nokia.com> <1068824244.1641.14.camel@squirrel> <3FB57C07.9020300@iprg.nokia.com> Content-Type: text/plain Organization: Panasonic Singapore Labs Message-Id: <1069046346.1987.0.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 17 Nov 2003 13:19:06 +0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ok. /rgds /cwng On Sat, 2003-11-15 at 09:06, Vijay Devarapalli wrote: > Chan-Wah NG wrote: > > Hello Vijay, Matsumoto-san, > > > > I feel more comfortable if the text specify that this relaxation is done > > only when the 'R' bit is set in the BU. > > see the entire section 6.2. the first paragraph says > > The Home Agent processes the Binding Update as described in section > 10.3.1 of the Mobile IPv6 specification [1]. This section describes > the processing of the Binding Update if the Mobile Router (R) flag is > set. The Home Agent performs the following check in addition. > > Vijay > > > > > /rgds > > /cwng > > > > > > On Fri, 2003-11-14 at 03:58, Vijay Devarapalli wrote: > > > >>hi, > >> > >>a new section has been added to section 6.2 to close this issue. > >> > >> - Mobile IPv6 specification [1] requires that the Home Address in > >> the Binding Update should be configured from a prefix advertised > >> on the home link. Otherwise the Binding Update is rejected > >> with status value 132 [1]. This specifications relaxes this > >> requirement so that the Home Agent rejects the Binding Update > >> only if Home Address does not belong to the prefix that the Home > >> Agent is configured to serve. > >> > >>the details are at http://people.nokia.net/vijayd/nemo/issue19.txt > >> > >>Vijay > >> > >> > >> > >> > > > > From nemo-admin@ietf.org Mon Nov 17 01:17:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19887 for ; Mon, 17 Nov 2003 01:17: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 1ALch3-0007U2-8b; Mon, 17 Nov 2003 01: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 1ALcg8-0007SN-V0 for nemo@optimus.ietf.org; Mon, 17 Nov 2003 01: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 BAA19857; Mon, 17 Nov 2003 01:15:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALcg5-0001wH-00; Mon, 17 Nov 2003 01:16:01 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1ALcg5-0001w1-00; Mon, 17 Nov 2003 01:16:01 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 5B67F5D13C; Mon, 17 Nov 2003 15:15:30 +0900 (JST) Date: Mon, 17 Nov 2003 15:10:01 +0900 From: Thierry Ernst To: "James Kempf" Cc: mip6@ietf.org, nemo Message-Id: <20031117151001.46c1b509.ernst@sfc.wide.ad.jp> In-Reply-To: <02f701c3aa03$07d095c0$85818182@dclkempt40> References: <00f601c3a97d$991aea70$85818182@dclkempt40> <3FB3A6E0.3050503@clarinet.u-strasbg.fr> <02f701c3aa03$07d095c0$85818182@dclkempt40> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: [Mip6] Minutes of Multiple Link Flows BAR BOF Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit James, Thanks for the quick post of minutes and see my comments inline. "James Kempf" wrote: > Hi Nicolas, > > However, I have to raise a point. We (Ryuji, Thierry, Thomas and me) > > began to write a problem statement draft in MIP6 WG > > (draft-montavont-multihoming-pb-statement-00) and I think that it can be > > the starting point of a pb statement document. Following the > > presentation of this draft at the MIP6 meeting, and from some comments > > in the mailing list, we receive valuable feedback for the evolution of > > this draft. Also, the bar bof gives us other ideas to enhance this > document. > > > > So I think that a new version of this draft can constitute the pb > > statement currently required to move forward on the multihoming. It is > > not necessary to duplicate the efforts. > > Sorry I missed this in the minutes. An update of your draft based on list > feedback and discussion at the BAR BOF would certainly be valuable. > > I think the U. Bremen folks are primarily interested in MIP4 as that is > where their prototype was done, and I believe the primary near term > deployment interest is there, due to the possiblity of multiinterface > laptops and pending release of multi-interface phones. > > However, I think it might make some sense for you and they to combine > efforts if you both agree there would be some common points in the problem > statement between MIP4 and MIP6. Since MIP4 has some immediate deployment > interest, it might be most approprate to work on a general problem statement > there first, with review from the MIP6 group, then later work on the MIP6 > specific issues in the MIP6 group. > > I'd suggest contacting the WG chairs of MIP4 and MIP6 about how to proceed, > and definitely talking with Carsten and U. Bremen folks about the > possibility of combining efforts. I think work on v4 and v6 should be split, the generic problem statement may be the same but not the details, and the same people are not involved in both. Besides this, I think that it's more important to work on v6 since it will replace v4. It's useful to work hard trying to get new features to v6 before it gets to its full deployment. We will quickly revise our problem statement drafts both in MIP6 and NEMO WG. Thierry. From exim@www1.ietf.org Mon Nov 17 01:17:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19905 for ; Mon, 17 Nov 2003 01:17: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 1ALch8-0007Vg-65 for nemo-archive@odin.ietf.org; Mon, 17 Nov 2003 01:17:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAH6H6h5028862 for nemo-archive@odin.ietf.org; Mon, 17 Nov 2003 01:17:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALch8-0007VR-1X for nemo-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 01:17: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 BAA19880 for ; Mon, 17 Nov 2003 01:16:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALch5-0001ye-00 for nemo-web-archive@ietf.org; Mon, 17 Nov 2003 01:17:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALch4-0001yb-00 for nemo-web-archive@ietf.org; Mon, 17 Nov 2003 01:17:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALch3-0007U2-8b; Mon, 17 Nov 2003 01: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 1ALcg8-0007SN-V0 for nemo@optimus.ietf.org; Mon, 17 Nov 2003 01: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 BAA19857; Mon, 17 Nov 2003 01:15:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALcg5-0001wH-00; Mon, 17 Nov 2003 01:16:01 -0500 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 1ALcg5-0001w1-00; Mon, 17 Nov 2003 01:16:01 -0500 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 5B67F5D13C; Mon, 17 Nov 2003 15:15:30 +0900 (JST) Date: Mon, 17 Nov 2003 15:10:01 +0900 From: Thierry Ernst To: "James Kempf" Cc: mip6@ietf.org, nemo Message-Id: <20031117151001.46c1b509.ernst@sfc.wide.ad.jp> In-Reply-To: <02f701c3aa03$07d095c0$85818182@dclkempt40> References: <00f601c3a97d$991aea70$85818182@dclkempt40> <3FB3A6E0.3050503@clarinet.u-strasbg.fr> <02f701c3aa03$07d095c0$85818182@dclkempt40> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: [Mip6] Minutes of Multiple Link Flows BAR BOF Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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 James, Thanks for the quick post of minutes and see my comments inline. "James Kempf" wrote: > Hi Nicolas, > > However, I have to raise a point. We (Ryuji, Thierry, Thomas and me) > > began to write a problem statement draft in MIP6 WG > > (draft-montavont-multihoming-pb-statement-00) and I think that it can be > > the starting point of a pb statement document. Following the > > presentation of this draft at the MIP6 meeting, and from some comments > > in the mailing list, we receive valuable feedback for the evolution of > > this draft. Also, the bar bof gives us other ideas to enhance this > document. > > > > So I think that a new version of this draft can constitute the pb > > statement currently required to move forward on the multihoming. It is > > not necessary to duplicate the efforts. > > Sorry I missed this in the minutes. An update of your draft based on list > feedback and discussion at the BAR BOF would certainly be valuable. > > I think the U. Bremen folks are primarily interested in MIP4 as that is > where their prototype was done, and I believe the primary near term > deployment interest is there, due to the possiblity of multiinterface > laptops and pending release of multi-interface phones. > > However, I think it might make some sense for you and they to combine > efforts if you both agree there would be some common points in the problem > statement between MIP4 and MIP6. Since MIP4 has some immediate deployment > interest, it might be most approprate to work on a general problem statement > there first, with review from the MIP6 group, then later work on the MIP6 > specific issues in the MIP6 group. > > I'd suggest contacting the WG chairs of MIP4 and MIP6 about how to proceed, > and definitely talking with Carsten and U. Bremen folks about the > possibility of combining efforts. I think work on v4 and v6 should be split, the generic problem statement may be the same but not the details, and the same people are not involved in both. Besides this, I think that it's more important to work on v6 since it will replace v4. It's useful to work hard trying to get new features to v6 before it gets to its full deployment. We will quickly revise our problem statement drafts both in MIP6 and NEMO WG. Thierry. From nemo-admin@ietf.org Mon Nov 17 02:35:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04358 for ; Mon, 17 Nov 2003 02:35: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 1ALdub-0003E9-0Q; Mon, 17 Nov 2003 02:35:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALdtc-0003Be-TI for nemo@optimus.ietf.org; Mon, 17 Nov 2003 02:34: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 CAA04304 for ; Mon, 17 Nov 2003 02:33:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALdtZ-0002rn-00 for nemo@ietf.org; Mon, 17 Nov 2003 02:34:01 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ALdtY-0002rZ-00 for nemo@ietf.org; Mon, 17 Nov 2003 02:34:00 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 17 Nov 2003 08:31:01 +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 hAH7XJxA001082; Mon, 17 Nov 2003 08:33:19 +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, 17 Nov 2003 07:33:29 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [nemo] NEMO DHAAD instead of bit in BAck? Date: Mon, 17 Nov 2003 07:33:28 -0000 Message-ID: Thread-Topic: [nemo] NEMO DHAAD instead of bit in BAck? Thread-Index: AcOrJJyPd14ka45sTSyEv21vE7BU3ABt898A From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , Cc: X-OriginalArrivalTime: 17 Nov 2003 07:33:29.0289 (UTC) FILETIME=[185B4390:01C3ACDD] 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 All: Just 2 comments: 1) I agree with the idea. But DHAAD is an option and I believe HA still must echo the R bit. 2) Since this is about the same functionality as the 'R' bit, why not naming it 'R' as well in DHAAD? Pascal > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Vijay Devarapalli > Sent: samedi 15 novembre 2003 04:02 > To: tim.leinmueller@daimlerchrysler.com > Cc: nemo@ietf.org > Subject: Re: [nemo] NEMO DHAAD instead of bit in BAck? >=20 > I agree with Tim here. to close this issue I suggest adding > a new section on modifications to Dynamic Home Agent Dicovery > messages to the draft. >=20 > a version of the draft with these modifications is at > http://people.nokia.net/vijayd/nemo/nemo_protocol_mod_dhaad.txt > there is a new section 7. please comment. >=20 > I also removed Binding Ack status 2. >=20 > Vijay >=20 > tim.leinmueller@daimlerchrysler.com wrote: > > Hi all, > > > > I already talked about NEMO DHAAD with the authors of the basic > > support draft and Vijay asked me to post this to the list. > > > > So far according to the basic support draft, MR discovers HA's that > > have MR support, by receiving binding acks with with non-zero status > > code. This means MR has to cycle between HA's that have no MR support > > up to HA's that do have MR support. > > > > Being more specific during the HA discovery phase (DHAAD), could > > improve this situation. > > > > I'll attach a text I wrote some time ago, that contains the basic > > idea. > > > > Tim. > > > > --- NEMO DHAAD --- > > Additions to Dynamic Home Agent Address Discovery (DHAAD) > > > > Since mobile routers need home agents with support for network > > mobility, it is of use to extend the existing DHAAD mechanism, to > > enable mobile routers to discover home agents supporting mobile > > networks. > > > > The modification consists in adding the mobile router home agent bit M > > to the ICMP messages for home agent discovery (figures 2.24 and 2.25) > > and to the home agent information option (figure 2.26). > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Code | Checksum | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Identifier |M| Reserved1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 2.24: Extended ICMP Home Agent Address Discovery Request > > Message > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Code | Checksum | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Identifier |M| Reserved1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > + + > > . . > > . Home Agent Addresses . > > . . > > + + > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 2.25: Extended ICMP Home Agent Address Discovery Reply Message > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Length |M| Reserved1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Home Agent Preference | Home Agent Lifetime | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 2.26: Extended Home Agent Information Option Format > > > > Added to the ICMP home agent address discovery request message, the M > > bit serves to indicate, that a mobile router is searching for > > suitable home agents with mobile router support. If this request is > > received by a normal home agent, it will ignore the M bit and send an > > ICMP home agent information discovery reply message as specified in > > [1], without the M bit set. This reply includes all known home agents > > on the home network, regardless of the support for mobile routers. > > Otherwise, if the recipient is a mobile router supporting home agent, > > it will discover the M bit and send an extended ICMP home agent > > address discovery reply message as response (with the M bit set to > > one), containing only home agents with support for mobile networks. > > > > The M bit in the home agent information option is used to indicate to > > other home agents, whether the sending home agent is capable (and >=20 >=20 From exim@www1.ietf.org Mon Nov 17 02:35:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04376 for ; Mon, 17 Nov 2003 02: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 1ALdum-0003FV-Ln for nemo-archive@odin.ietf.org; Mon, 17 Nov 2003 02:35:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAH7ZGNR012488 for nemo-archive@odin.ietf.org; Mon, 17 Nov 2003 02:35:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALdum-0003FL-2l for nemo-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 02:35: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 CAA04334 for ; Mon, 17 Nov 2003 02:35:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALdui-0002sJ-00 for nemo-web-archive@ietf.org; Mon, 17 Nov 2003 02:35:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALduh-0002sG-00 for nemo-web-archive@ietf.org; Mon, 17 Nov 2003 02:35:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALdub-0003E9-0Q; Mon, 17 Nov 2003 02:35:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALdtc-0003Be-TI for nemo@optimus.ietf.org; Mon, 17 Nov 2003 02:34: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 CAA04304 for ; Mon, 17 Nov 2003 02:33:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALdtZ-0002rn-00 for nemo@ietf.org; Mon, 17 Nov 2003 02:34:01 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ALdtY-0002rZ-00 for nemo@ietf.org; Mon, 17 Nov 2003 02:34:00 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 17 Nov 2003 08:31:01 +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 hAH7XJxA001082; Mon, 17 Nov 2003 08:33:19 +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, 17 Nov 2003 07:33:29 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [nemo] NEMO DHAAD instead of bit in BAck? Date: Mon, 17 Nov 2003 07:33:28 -0000 Message-ID: Thread-Topic: [nemo] NEMO DHAAD instead of bit in BAck? Thread-Index: AcOrJJyPd14ka45sTSyEv21vE7BU3ABt898A From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , Cc: X-OriginalArrivalTime: 17 Nov 2003 07:33:29.0289 (UTC) FILETIME=[185B4390:01C3ACDD] 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 All: Just 2 comments: 1) I agree with the idea. But DHAAD is an option and I believe HA still must echo the R bit. 2) Since this is about the same functionality as the 'R' bit, why not naming it 'R' as well in DHAAD? Pascal > -----Original Message----- > From: nemo-admin@ietf.org [mailto:nemo-admin@ietf.org] On Behalf Of Vijay Devarapalli > Sent: samedi 15 novembre 2003 04:02 > To: tim.leinmueller@daimlerchrysler.com > Cc: nemo@ietf.org > Subject: Re: [nemo] NEMO DHAAD instead of bit in BAck? >=20 > I agree with Tim here. to close this issue I suggest adding > a new section on modifications to Dynamic Home Agent Dicovery > messages to the draft. >=20 > a version of the draft with these modifications is at > http://people.nokia.net/vijayd/nemo/nemo_protocol_mod_dhaad.txt > there is a new section 7. please comment. >=20 > I also removed Binding Ack status 2. >=20 > Vijay >=20 > tim.leinmueller@daimlerchrysler.com wrote: > > Hi all, > > > > I already talked about NEMO DHAAD with the authors of the basic > > support draft and Vijay asked me to post this to the list. > > > > So far according to the basic support draft, MR discovers HA's that > > have MR support, by receiving binding acks with with non-zero status > > code. This means MR has to cycle between HA's that have no MR support > > up to HA's that do have MR support. > > > > Being more specific during the HA discovery phase (DHAAD), could > > improve this situation. > > > > I'll attach a text I wrote some time ago, that contains the basic > > idea. > > > > Tim. > > > > --- NEMO DHAAD --- > > Additions to Dynamic Home Agent Address Discovery (DHAAD) > > > > Since mobile routers need home agents with support for network > > mobility, it is of use to extend the existing DHAAD mechanism, to > > enable mobile routers to discover home agents supporting mobile > > networks. > > > > The modification consists in adding the mobile router home agent bit M > > to the ICMP messages for home agent discovery (figures 2.24 and 2.25) > > and to the home agent information option (figure 2.26). > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Code | Checksum | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Identifier |M| Reserved1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 2.24: Extended ICMP Home Agent Address Discovery Request > > Message > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Code | Checksum | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Identifier |M| Reserved1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > + + > > . . > > . Home Agent Addresses . > > . . > > + + > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 2.25: Extended ICMP Home Agent Address Discovery Reply Message > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Length |M| Reserved1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Home Agent Preference | Home Agent Lifetime | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 2.26: Extended Home Agent Information Option Format > > > > Added to the ICMP home agent address discovery request message, the M > > bit serves to indicate, that a mobile router is searching for > > suitable home agents with mobile router support. If this request is > > received by a normal home agent, it will ignore the M bit and send an > > ICMP home agent information discovery reply message as specified in > > [1], without the M bit set. This reply includes all known home agents > > on the home network, regardless of the support for mobile routers. > > Otherwise, if the recipient is a mobile router supporting home agent, > > it will discover the M bit and send an extended ICMP home agent > > address discovery reply message as response (with the M bit set to > > one), containing only home agents with support for mobile networks. > > > > The M bit in the home agent information option is used to indicate to > > other home agents, whether the sending home agent is capable (and >=20 >=20 From nemo-admin@ietf.org Mon Nov 17 04:36:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06535 for ; Mon, 17 Nov 2003 04: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 1ALfne-0007s1-Oq; Mon, 17 Nov 2003 04: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 1ALfnM-0007rh-3I for nemo@optimus.ietf.org; Mon, 17 Nov 2003 04: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 EAA06521 for ; Mon, 17 Nov 2003 04:35:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALfnI-0003zO-00 for nemo@ietf.org; Mon, 17 Nov 2003 04:35:41 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1ALfnI-0003zL-00 for nemo@ietf.org; Mon, 17 Nov 2003 04:35:40 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id hAH9Ys8e022001; Mon, 17 Nov 2003 02:34:54 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id hAH9YtBJ016735; Mon, 17 Nov 2003 03:34:56 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 12E632EC95; Mon, 17 Nov 2003 10:34:55 +0100 (CET) Message-ID: <3FB8963E.5030405@motorola.com> Date: Mon, 17 Nov 2003 10:34:54 +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: Vijay Devarapalli , tim.leinmueller@daimlerchrysler.com, nemo@ietf.org Subject: Re: [nemo] NEMO DHAAD instead of bit in BAck? References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > 2) Since this is about the same functionality as the 'R' bit, why not > naming it 'R' as well in DHAAD? I support naming this bit 'R' in DHAAD (and not 'M'). Alex GBU From exim@www1.ietf.org Mon Nov 17 04:36:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06550 for ; Mon, 17 Nov 2003 04:36: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 1ALfnl-0007sz-0l for nemo-archive@odin.ietf.org; Mon, 17 Nov 2003 04:36:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAH9a8UT030314 for nemo-archive@odin.ietf.org; Mon, 17 Nov 2003 04: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 1ALfnk-0007sr-Hb for nemo-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 04: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 EAA06525 for ; Mon, 17 Nov 2003 04:35:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALfnh-0003za-00 for nemo-web-archive@ietf.org; Mon, 17 Nov 2003 04:36:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALfnh-0003zX-00 for nemo-web-archive@ietf.org; Mon, 17 Nov 2003 04: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 1ALfne-0007s1-Oq; Mon, 17 Nov 2003 04: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 1ALfnM-0007rh-3I for nemo@optimus.ietf.org; Mon, 17 Nov 2003 04: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 EAA06521 for ; Mon, 17 Nov 2003 04:35:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALfnI-0003zO-00 for nemo@ietf.org; Mon, 17 Nov 2003 04:35:41 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1ALfnI-0003zL-00 for nemo@ietf.org; Mon, 17 Nov 2003 04:35:40 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id hAH9Ys8e022001; Mon, 17 Nov 2003 02:34:54 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id hAH9YtBJ016735; Mon, 17 Nov 2003 03:34:56 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 12E632EC95; Mon, 17 Nov 2003 10:34:55 +0100 (CET) Message-ID: <3FB8963E.5030405@motorola.com> Date: Mon, 17 Nov 2003 10:34:54 +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: Vijay Devarapalli , tim.leinmueller@daimlerchrysler.com, nemo@ietf.org Subject: Re: [nemo] NEMO DHAAD instead of bit in BAck? References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > 2) Since this is about the same functionality as the 'R' bit, why not > naming it 'R' as well in DHAAD? I support naming this bit 'R' in DHAAD (and not 'M'). Alex GBU From nemo-admin@ietf.org Mon Nov 17 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 MAA24091 for ; Mon, 17 Nov 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 1ALnL2-000364-8t; Mon, 17 Nov 2003 12: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 1ALnKE-00035Y-Sj for nemo@optimus.ietf.org; Mon, 17 Nov 2003 12:38: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 MAA24017 for ; Mon, 17 Nov 2003 12:37:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALnKD-0002oI-00 for nemo@ietf.org; Mon, 17 Nov 2003 12:38:09 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ALnKC-0002o4-00 for nemo@ietf.org; Mon, 17 Nov 2003 12:38:08 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAHHb2P03577; Mon, 17 Nov 2003 09:37:02 -0800 X-mProtect: <200311171737> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdp60SXM; Mon, 17 Nov 2003 09:37:00 PST Message-ID: <3FB90837.2010000@iprg.nokia.com> Date: Mon, 17 Nov 2003 09:41: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: "Pascal Thubert (pthubert)" CC: tim.leinmueller@daimlerchrysler.com, nemo@ietf.org Subject: Re: [nemo] NEMO DHAAD instead of bit in BAck? 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: > All: > > Just 2 comments: > > 1) I agree with the idea. But DHAAD is an option and I believe HA still > must echo the R bit. the only other way (apart from DHAAD) a Mobile Router acquires Home Agent information is through manual configuration. so why do we need a flag in the Binding Ack? the Mobile Router should not attempt registration with a Home Agent that does not support Mobile Routers. > 2) Since this is about the same functionality as the 'R' bit, why not > naming it 'R' as well in DHAAD? sure. Vijay From exim@www1.ietf.org Mon Nov 17 12:39:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24106 for ; Mon, 17 Nov 2003 12:39: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 1ALnL8-00037C-Gj for nemo-archive@odin.ietf.org; Mon, 17 Nov 2003 12:39:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHHd6pZ011968 for nemo-archive@odin.ietf.org; Mon, 17 Nov 2003 12: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 1ALnL8-00036x-AW for nemo-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 12: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 MAA24060 for ; Mon, 17 Nov 2003 12:38:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALnL6-0002pJ-00 for nemo-web-archive@ietf.org; Mon, 17 Nov 2003 12:39:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALnL6-0002pE-00 for nemo-web-archive@ietf.org; Mon, 17 Nov 2003 12:39:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALnL2-000364-8t; Mon, 17 Nov 2003 12: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 1ALnKE-00035Y-Sj for nemo@optimus.ietf.org; Mon, 17 Nov 2003 12:38: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 MAA24017 for ; Mon, 17 Nov 2003 12:37:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALnKD-0002oI-00 for nemo@ietf.org; Mon, 17 Nov 2003 12:38:09 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ALnKC-0002o4-00 for nemo@ietf.org; Mon, 17 Nov 2003 12:38:08 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAHHb2P03577; Mon, 17 Nov 2003 09:37:02 -0800 X-mProtect: <200311171737> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdp60SXM; Mon, 17 Nov 2003 09:37:00 PST Message-ID: <3FB90837.2010000@iprg.nokia.com> Date: Mon, 17 Nov 2003 09:41: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: "Pascal Thubert (pthubert)" CC: tim.leinmueller@daimlerchrysler.com, nemo@ietf.org Subject: Re: [nemo] NEMO DHAAD instead of bit in BAck? 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: > All: > > Just 2 comments: > > 1) I agree with the idea. But DHAAD is an option and I believe HA still > must echo the R bit. the only other way (apart from DHAAD) a Mobile Router acquires Home Agent information is through manual configuration. so why do we need a flag in the Binding Ack? the Mobile Router should not attempt registration with a Home Agent that does not support Mobile Routers. > 2) Since this is about the same functionality as the 'R' bit, why not > naming it 'R' as well in DHAAD? sure. Vijay From nemo-admin@ietf.org Tue Nov 18 05:14:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12798 for ; Tue, 18 Nov 2003 05:14: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 1AM2rz-0007gG-3i; Tue, 18 Nov 2003 05:14:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2rq-0007fr-Qa for nemo@optimus.ietf.org; Tue, 18 Nov 2003 05:13:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12777 for ; Tue, 18 Nov 2003 05:13:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM2rn-0001sj-00 for nemo@ietf.org; Tue, 18 Nov 2003 05:13:51 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AM2rm-0001rR-00 for nemo@ietf.org; Tue, 18 Nov 2003 05:13:51 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2003 11:10: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 hAIAD9UF000327; Tue, 18 Nov 2003 11:13:09 +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, 18 Nov 2003 10:13:19 +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] NEMO DHAAD instead of bit in BAck? Date: Tue, 18 Nov 2003 10:13:18 -0000 Message-ID: Thread-Topic: [nemo] NEMO DHAAD instead of bit in BAck? Thread-Index: AcOtMYP+6hJT6xmkSJKIdH6t3FuCnAAiffEA From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: , X-OriginalArrivalTime: 18 Nov 2003 10:13:19.0381 (UTC) FILETIME=[96E8EC50:01C3ADBC] 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 > > 1) I agree with the idea. But DHAAD is an option and I believe HA still > > must echo the R bit. >=20 > the only other way (apart from DHAAD) a Mobile Router acquires Home > Agent information is through manual configuration. so why do we need > a flag in the Binding Ack? the Mobile Router should not attempt > registration with a Home Agent that does not support Mobile Routers. >=20 I'd put it there for consistency, and to check for config errors. If you look at it, many error codes and operations we have actually detect invalid config and report that to the admin.=20 Eg: DAD on the Home Link. Since the Home Address is configured on the MR, it's as 'good' as any fixed address on any fixed node. In other words it's not autoconfigured. We're looking for an erroneous config (or change of config). This test is not really costly to implement, and then you're 100% sure that the 0 in the binding ack means OK for a basic Nemo registration. I'd say it 'nice to have' +=20 Pascal=20 From exim@www1.ietf.org Tue Nov 18 05:14:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12813 for ; Tue, 18 Nov 2003 05:14: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 1AM2s5-0007hC-0l for nemo-archive@odin.ietf.org; Tue, 18 Nov 2003 05:14:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIAE84R029581 for nemo-archive@odin.ietf.org; Tue, 18 Nov 2003 05:14:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2s3-0007gz-EP for nemo-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 05: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 FAA12789 for ; Tue, 18 Nov 2003 05:13:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM2rz-0001sx-00 for nemo-web-archive@ietf.org; Tue, 18 Nov 2003 05:14:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM2rz-0001ss-00 for nemo-web-archive@ietf.org; Tue, 18 Nov 2003 05:14:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2rz-0007gG-3i; Tue, 18 Nov 2003 05:14:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2rq-0007fr-Qa for nemo@optimus.ietf.org; Tue, 18 Nov 2003 05:13:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12777 for ; Tue, 18 Nov 2003 05:13:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM2rn-0001sj-00 for nemo@ietf.org; Tue, 18 Nov 2003 05:13:51 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AM2rm-0001rR-00 for nemo@ietf.org; Tue, 18 Nov 2003 05:13:51 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2003 11:10: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 hAIAD9UF000327; Tue, 18 Nov 2003 11:13:09 +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, 18 Nov 2003 10:13:19 +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] NEMO DHAAD instead of bit in BAck? Date: Tue, 18 Nov 2003 10:13:18 -0000 Message-ID: Thread-Topic: [nemo] NEMO DHAAD instead of bit in BAck? Thread-Index: AcOtMYP+6hJT6xmkSJKIdH6t3FuCnAAiffEA From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: , X-OriginalArrivalTime: 18 Nov 2003 10:13:19.0381 (UTC) FILETIME=[96E8EC50:01C3ADBC] 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 > > 1) I agree with the idea. But DHAAD is an option and I believe HA still > > must echo the R bit. >=20 > the only other way (apart from DHAAD) a Mobile Router acquires Home > Agent information is through manual configuration. so why do we need > a flag in the Binding Ack? the Mobile Router should not attempt > registration with a Home Agent that does not support Mobile Routers. >=20 I'd put it there for consistency, and to check for config errors. If you look at it, many error codes and operations we have actually detect invalid config and report that to the admin.=20 Eg: DAD on the Home Link. Since the Home Address is configured on the MR, it's as 'good' as any fixed address on any fixed node. In other words it's not autoconfigured. We're looking for an erroneous config (or change of config). This test is not really costly to implement, and then you're 100% sure that the 0 in the binding ack means OK for a basic Nemo registration. I'd say it 'nice to have' +=20 Pascal=20 From nemo-admin@ietf.org Tue Nov 18 05:33:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13429 for ; Tue, 18 Nov 2003 05:33: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 1AM3AL-0001Xw-S3; Tue, 18 Nov 2003 05:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3AE-0001Xb-FS for nemo@optimus.ietf.org; Tue, 18 Nov 2003 05:32: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 FAA13400 for ; Tue, 18 Nov 2003 05:32:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM3AA-0002FT-00 for nemo@ietf.org; Tue, 18 Nov 2003 05:32:50 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AM3AA-0002Es-00 for nemo@ietf.org; Tue, 18 Nov 2003 05:32:50 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2003 11:29: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 hAIAW9AQ005905; Tue, 18 Nov 2003 11:32:09 +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, 18 Nov 2003 10:32:19 +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, 18 Nov 2003 10:32:18 -0000 Message-ID: Thread-Topic: HA reliability draft Thread-Index: AcOtOG0PC22I0jHvTjq6KU79fmiDowAhD3TQ From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , , , Cc: X-OriginalArrivalTime: 18 Nov 2003 10:32:19.0483 (UTC) FILETIME=[3E76AEB0:01C3ADBF] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: HA reliability 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: quoted-printable Hi=20 I was not aware of that draft. It's a good start for the pb statement part of the HA (high availability) of the HAHA protocol. This discussion should definitely take place in the Nemo ML.=20 I believe that the problem statement should describe in more details the levels of quality of service that we can get: 0 < session loss, binding Time out (mip6) < loss of session, BREQ trigger < standby backup with lazy sync < standby backup with full sync < splitting < load balancing with the usual variations over the main themes. Like VRRP vs HSRP. And like, for the last 2, whether the split/balance is per group of MNs, per session, per packet, or what? Pascal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: lundi 17 novembre 2003 19:30 > To: jfaizan@smu.edu; rewini@engr.smu.edu; mkhalil@nortelnetworks > Cc: Ryuji Wakikawa; Pascal Thubert (pthubert); vijayd@iprg.nokia.com > Subject: HA reliability draft >=20 > hi, >=20 > I am not sure when draft-jfaizan-mipv6-ha-reliability-00.txt > was submitted. have you been following the MIPv6 and Nemo > lists recently? >=20 > there is a draft on HA reliability > http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-haha-00.txt > which talks about the problem and also proposes a solution. >=20 > also take a look at presentations on this at the Nemo > and MIP6 WG meetings last week's IETF meeting. there were > slides presented on the problem statement. at the IETF meeting > last week we concentrated explicitly on the problem statement. >=20 > some people commented that draft-wakikawa-mip6-nemo-haha-00.txt > is too solution specific and we need a generic problem > statement. your draft looks good for such a problem statement. >=20 > I have some specific comments on the draft which I will send > later. >=20 > Vijay >=20 From exim@www1.ietf.org Tue Nov 18 05:33:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13444 for ; Tue, 18 Nov 2003 05:33: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 1AM3AO-0001aE-Gk for nemo-archive@odin.ietf.org; Tue, 18 Nov 2003 05:33:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIAX4kD006085 for nemo-archive@odin.ietf.org; Tue, 18 Nov 2003 05:33:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3AO-0001a4-Aq for nemo-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 05:33: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 FAA13413 for ; Tue, 18 Nov 2003 05:32:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM3AK-0002Fq-00 for nemo-web-archive@ietf.org; Tue, 18 Nov 2003 05:33:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM3AK-0002Fn-00 for nemo-web-archive@ietf.org; Tue, 18 Nov 2003 05:33:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3AL-0001Xw-S3; Tue, 18 Nov 2003 05:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM3AE-0001Xb-FS for nemo@optimus.ietf.org; Tue, 18 Nov 2003 05:32: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 FAA13400 for ; Tue, 18 Nov 2003 05:32:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM3AA-0002FT-00 for nemo@ietf.org; Tue, 18 Nov 2003 05:32:50 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AM3AA-0002Es-00 for nemo@ietf.org; Tue, 18 Nov 2003 05:32:50 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2003 11:29: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 hAIAW9AQ005905; Tue, 18 Nov 2003 11:32:09 +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, 18 Nov 2003 10:32:19 +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, 18 Nov 2003 10:32:18 -0000 Message-ID: Thread-Topic: HA reliability draft Thread-Index: AcOtOG0PC22I0jHvTjq6KU79fmiDowAhD3TQ From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , , , Cc: X-OriginalArrivalTime: 18 Nov 2003 10:32:19.0483 (UTC) FILETIME=[3E76AEB0:01C3ADBF] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: HA reliability 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: quoted-printable Content-Transfer-Encoding: quoted-printable Hi=20 I was not aware of that draft. It's a good start for the pb statement part of the HA (high availability) of the HAHA protocol. This discussion should definitely take place in the Nemo ML.=20 I believe that the problem statement should describe in more details the levels of quality of service that we can get: 0 < session loss, binding Time out (mip6) < loss of session, BREQ trigger < standby backup with lazy sync < standby backup with full sync < splitting < load balancing with the usual variations over the main themes. Like VRRP vs HSRP. And like, for the last 2, whether the split/balance is per group of MNs, per session, per packet, or what? Pascal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: lundi 17 novembre 2003 19:30 > To: jfaizan@smu.edu; rewini@engr.smu.edu; mkhalil@nortelnetworks > Cc: Ryuji Wakikawa; Pascal Thubert (pthubert); vijayd@iprg.nokia.com > Subject: HA reliability draft >=20 > hi, >=20 > I am not sure when draft-jfaizan-mipv6-ha-reliability-00.txt > was submitted. have you been following the MIPv6 and Nemo > lists recently? >=20 > there is a draft on HA reliability > http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-haha-00.txt > which talks about the problem and also proposes a solution. >=20 > also take a look at presentations on this at the Nemo > and MIP6 WG meetings last week's IETF meeting. there were > slides presented on the problem statement. at the IETF meeting > last week we concentrated explicitly on the problem statement. >=20 > some people commented that draft-wakikawa-mip6-nemo-haha-00.txt > is too solution specific and we need a generic problem > statement. your draft looks good for such a problem statement. >=20 > I have some specific comments on the draft which I will send > later. >=20 > Vijay >=20 From nemo-admin@ietf.org Wed Nov 19 14:23:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05011 for ; Wed, 19 Nov 2003 14:23: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 1AMXun-00010d-79; Wed, 19 Nov 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 1AMXuH-0000xD-5E for nemo@optimus.ietf.org; Wed, 19 Nov 2003 14:22: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 OAA04975 for ; Wed, 19 Nov 2003 14:22:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMXuE-0007db-00 for nemo@ietf.org; Wed, 19 Nov 2003 14:22:26 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AMXuD-0007cp-00 for nemo@ietf.org; Wed, 19 Nov 2003 14:22:25 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAJJL2b10840; Wed, 19 Nov 2003 11:21:02 -0800 X-mProtect: <200311191921> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxHkVz8; Wed, 19 Nov 2003 11:21:01 PST Message-ID: <3FBBC3A3.4050604@iprg.nokia.com> Date: Wed, 19 Nov 2003 11:25:23 -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: tim.leinmueller@daimlerchrysler.com, nemo@ietf.org Subject: Re: [nemo] NEMO DHAAD instead of bit in BAck? 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 hi Pascal, I would like to avoid any extra specification and extra code if possible. I dont really see the need for adding a flag to the Binding Ack, now that we have modified to DHAAD for the Mobile Routers to discovery only Home Agents with mobile router support. does anybody else have an opinion? Vijay Pascal Thubert (pthubert) wrote: >>>1) I agree with the idea. But DHAAD is an option and I believe HA > > still > >>>must echo the R bit. >> >>the only other way (apart from DHAAD) a Mobile Router acquires Home >>Agent information is through manual configuration. so why do we need >>a flag in the Binding Ack? the Mobile Router should not attempt >>registration with a Home Agent that does not support Mobile Routers. >> > > > I'd put it there for consistency, and to check for config errors. If you > look at it, many error codes and operations we have actually detect > invalid config and report that to the admin. > > Eg: DAD on the Home Link. Since the Home Address is configured on the > MR, it's as 'good' as any fixed address on any fixed node. In other > words it's not autoconfigured. We're looking for an erroneous config (or > change of config). This test is not really costly to implement, and then > you're 100% sure that the 0 in the binding ack means OK for a basic Nemo > registration. > > I'd say it 'nice to have' + > > Pascal > From exim@www1.ietf.org Wed Nov 19 14:23:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05026 for ; Wed, 19 Nov 2003 14:23: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 1AMXuu-00011d-0Z for nemo-archive@odin.ietf.org; Wed, 19 Nov 2003 14:23:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJJN74n003935 for nemo-archive@odin.ietf.org; Wed, 19 Nov 2003 14:23:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMXut-00011O-SO for nemo-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 14:23: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 OAA04993 for ; Wed, 19 Nov 2003 14:22:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMXup-0007ed-00 for nemo-web-archive@ietf.org; Wed, 19 Nov 2003 14:23:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMXup-0007eZ-00 for nemo-web-archive@ietf.org; Wed, 19 Nov 2003 14:23:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMXun-00010d-79; Wed, 19 Nov 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 1AMXuH-0000xD-5E for nemo@optimus.ietf.org; Wed, 19 Nov 2003 14:22: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 OAA04975 for ; Wed, 19 Nov 2003 14:22:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMXuE-0007db-00 for nemo@ietf.org; Wed, 19 Nov 2003 14:22:26 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AMXuD-0007cp-00 for nemo@ietf.org; Wed, 19 Nov 2003 14:22:25 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAJJL2b10840; Wed, 19 Nov 2003 11:21:02 -0800 X-mProtect: <200311191921> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxHkVz8; Wed, 19 Nov 2003 11:21:01 PST Message-ID: <3FBBC3A3.4050604@iprg.nokia.com> Date: Wed, 19 Nov 2003 11:25:23 -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: tim.leinmueller@daimlerchrysler.com, nemo@ietf.org Subject: Re: [nemo] NEMO DHAAD instead of bit in BAck? 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 hi Pascal, I would like to avoid any extra specification and extra code if possible. I dont really see the need for adding a flag to the Binding Ack, now that we have modified to DHAAD for the Mobile Routers to discovery only Home Agents with mobile router support. does anybody else have an opinion? Vijay Pascal Thubert (pthubert) wrote: >>>1) I agree with the idea. But DHAAD is an option and I believe HA > > still > >>>must echo the R bit. >> >>the only other way (apart from DHAAD) a Mobile Router acquires Home >>Agent information is through manual configuration. so why do we need >>a flag in the Binding Ack? the Mobile Router should not attempt >>registration with a Home Agent that does not support Mobile Routers. >> > > > I'd put it there for consistency, and to check for config errors. If you > look at it, many error codes and operations we have actually detect > invalid config and report that to the admin. > > Eg: DAD on the Home Link. Since the Home Address is configured on the > MR, it's as 'good' as any fixed address on any fixed node. In other > words it's not autoconfigured. We're looking for an erroneous config (or > change of config). This test is not really costly to implement, and then > you're 100% sure that the 0 in the binding ack means OK for a basic Nemo > registration. > > I'd say it 'nice to have' + > > Pascal > From nemo-admin@ietf.org Wed Nov 19 15:02:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06812 for ; Wed, 19 Nov 2003 15:02: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 1AMYWY-0003Ds-0S; Wed, 19 Nov 2003 15: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 1AMYVd-0003DN-GI for nemo@optimus.ietf.org; Wed, 19 Nov 2003 15:01: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 PAA06781 for ; Wed, 19 Nov 2003 15:00:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMYVa-0000tl-00 for nemo@ietf.org; Wed, 19 Nov 2003 15:01:02 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AMYVZ-0000tA-00 for nemo@ietf.org; Wed, 19 Nov 2003 15:01:01 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAJK0Tl13362; Wed, 19 Nov 2003 12:00:29 -0800 X-mProtect: <200311192000> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDoMHvL; Wed, 19 Nov 2003 12:00:27 PST Message-ID: <3FBBCCE1.6080005@iprg.nokia.com> Date: Wed, 19 Nov 2003 12:04:49 -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: "James Kempf" CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Jim's comments on Basic Support Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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 Jim, I have filed your comments as Issues 20 and 21 at http://people.nokia.net/vijayd/nemo/issues.html. > When the Mobile Router is at home, it MAY be configured to send > Router Advertisements and reply to Router Solicitations on the > interface attached to the home link. The value of the Router > Lifetime field MUST be set to zero to prevent other nodes from > configuring the Mobile Router as the default router. > > jak> What happens if the Mobile Router advertises prefix A on the > home link, then moves and advertises prefix B? This could happen > if the Mobile Router was configured for a particular prefix on the > home link, then received a separate prefix when it moved away. the above text is for the egress interface (the interface with which the Mobile Router is attached to the home/visited link). if the Mobile Router is not at home, it must not send any router advertisements on its egress interface. when at home, it maybe be configured to send out router advertisements on its egress interface. as for as the ingress interface (the interface on the Mobile Network), the Mobile Router always sends router advertisements advertising the prefix that is currently delegated/configured for the Mobile Network. > A Mobile Router SHOULD NOT send unsolicited Router Advertisements > and SHOULD NOT reply to Router Solicitations on any egress interface > when that interface is attached to a visited link. However, the > Mobile Router SHOULD reply with Neighbor Advertisements to Neighbor > Solicitations received on the egress interface, for topologically > correct addresses. > > jak> What happens to hosts that are utilizing the router due to it > having sent unsolicted RAs on the egress interface on the home link > when the router moves away? that is why we recommend setting the router lifetime to zero so that these hosts do not pick the mobile router as the default router. they should pick some other router on the home link. > Wouldn't it be better just to prohibit > the Mobile Router from responding to RSs and sending unsolicited RAs > on its egress interface? sure we can prohibit. but should we? we can do without prohibiting it. maybe somebody will come up with something which might need these router advertisements. it is normal router behavior to send router advertisements on all its interfaces. > > 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. > > jak> In fact, it MUST utilize these as described in the base MIP6 > protocol for movement detection. okay. I will modify the text. > In order to be able to receive packets meant for the mobile network, > the Home Agent advertises reachability to the mobile network. If the > Home Link is configured with a prefix that is an aggregation and if > the Mobile Network Prefix is aggregated under that prefix, then the > routing updates advertising reachability to the mobile network are > sent only on the Home Link. If the Home Agent is the only default > router on the Home Link, routes to the Mobile Network Prefix get > aggregated naturally under the Home Agent and the Home Agent does not > have to do anything special. > > jak>>I'd suggest requiring the prefix to be an aggregation, or have you > carefully worked through a case where it isn't? IMO, that is a deployment issue. there is another draft, targeted at Informational, which talks about the home network. http://www.ietf.org/internet-drafts/draft-thubert-nemo-basic-usages-00.txt. we can add more text in this. the concensus at the WG meeting last was to make this a WG document. > > If the Mobile Router is not authorized to use this Home Address to > forward packets for one or more prefixes that are present in the > Binding Update, the Home Agent sets the status code in the Binding > Acknowledgement to '142' (Not Authorized for Prefix) in order to > indicate this. > > jak>> How, specifically, is authorization set up for a prefix between > the MR and HA? using the Prefix Table on the Home Agent. ofcourse there is the issue of filling up the Prefix Table. if the Mobile Router is manually configured with a Mobile Network Prefix (MNP), then you have to manually add entries to the Prefix Table. if the Mobile Router gets the MNP through DHCPv6 based prefix delegation, the Home Agent always acts as a DHCP relay. it is then easy for the Home Agent to figure out which Mobile Router was delegated which prefix. there is a draft by Raplh Droms on extending prefix delegation for NEMO. http://www.ietf.org/internet-drafts/draft-droms-nemo-dhcpv6-pd-00.txt Vijay From exim@www1.ietf.org Wed Nov 19 15:02:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06827 for ; Wed, 19 Nov 2003 15:02: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 1AMYWa-0003Es-DI for nemo-archive@odin.ietf.org; Wed, 19 Nov 2003 15:02:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJK24SW012444 for nemo-archive@odin.ietf.org; Wed, 19 Nov 2003 15: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 1AMYWa-0003Ed-7k for nemo-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 15: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 PAA06806 for ; Wed, 19 Nov 2003 15:01:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMYWX-0000xa-00 for nemo-web-archive@ietf.org; Wed, 19 Nov 2003 15:02:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMYWW-0000xU-00 for nemo-web-archive@ietf.org; Wed, 19 Nov 2003 15:02:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYWY-0003Ds-0S; Wed, 19 Nov 2003 15: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 1AMYVd-0003DN-GI for nemo@optimus.ietf.org; Wed, 19 Nov 2003 15:01: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 PAA06781 for ; Wed, 19 Nov 2003 15:00:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMYVa-0000tl-00 for nemo@ietf.org; Wed, 19 Nov 2003 15:01:02 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AMYVZ-0000tA-00 for nemo@ietf.org; Wed, 19 Nov 2003 15:01:01 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAJK0Tl13362; Wed, 19 Nov 2003 12:00:29 -0800 X-mProtect: <200311192000> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDoMHvL; Wed, 19 Nov 2003 12:00:27 PST Message-ID: <3FBBCCE1.6080005@iprg.nokia.com> Date: Wed, 19 Nov 2003 12:04:49 -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: "James Kempf" CC: nemo@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Jim's comments on Basic Support Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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 Jim, I have filed your comments as Issues 20 and 21 at http://people.nokia.net/vijayd/nemo/issues.html. > When the Mobile Router is at home, it MAY be configured to send > Router Advertisements and reply to Router Solicitations on the > interface attached to the home link. The value of the Router > Lifetime field MUST be set to zero to prevent other nodes from > configuring the Mobile Router as the default router. > > jak> What happens if the Mobile Router advertises prefix A on the > home link, then moves and advertises prefix B? This could happen > if the Mobile Router was configured for a particular prefix on the > home link, then received a separate prefix when it moved away. the above text is for the egress interface (the interface with which the Mobile Router is attached to the home/visited link). if the Mobile Router is not at home, it must not send any router advertisements on its egress interface. when at home, it maybe be configured to send out router advertisements on its egress interface. as for as the ingress interface (the interface on the Mobile Network), the Mobile Router always sends router advertisements advertising the prefix that is currently delegated/configured for the Mobile Network. > A Mobile Router SHOULD NOT send unsolicited Router Advertisements > and SHOULD NOT reply to Router Solicitations on any egress interface > when that interface is attached to a visited link. However, the > Mobile Router SHOULD reply with Neighbor Advertisements to Neighbor > Solicitations received on the egress interface, for topologically > correct addresses. > > jak> What happens to hosts that are utilizing the router due to it > having sent unsolicted RAs on the egress interface on the home link > when the router moves away? that is why we recommend setting the router lifetime to zero so that these hosts do not pick the mobile router as the default router. they should pick some other router on the home link. > Wouldn't it be better just to prohibit > the Mobile Router from responding to RSs and sending unsolicited RAs > on its egress interface? sure we can prohibit. but should we? we can do without prohibiting it. maybe somebody will come up with something which might need these router advertisements. it is normal router behavior to send router advertisements on all its interfaces. > > 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. > > jak> In fact, it MUST utilize these as described in the base MIP6 > protocol for movement detection. okay. I will modify the text. > In order to be able to receive packets meant for the mobile network, > the Home Agent advertises reachability to the mobile network. If the > Home Link is configured with a prefix that is an aggregation and if > the Mobile Network Prefix is aggregated under that prefix, then the > routing updates advertising reachability to the mobile network are > sent only on the Home Link. If the Home Agent is the only default > router on the Home Link, routes to the Mobile Network Prefix get > aggregated naturally under the Home Agent and the Home Agent does not > have to do anything special. > > jak>>I'd suggest requiring the prefix to be an aggregation, or have you > carefully worked through a case where it isn't? IMO, that is a deployment issue. there is another draft, targeted at Informational, which talks about the home network. http://www.ietf.org/internet-drafts/draft-thubert-nemo-basic-usages-00.txt. we can add more text in this. the concensus at the WG meeting last was to make this a WG document. > > If the Mobile Router is not authorized to use this Home Address to > forward packets for one or more prefixes that are present in the > Binding Update, the Home Agent sets the status code in the Binding > Acknowledgement to '142' (Not Authorized for Prefix) in order to > indicate this. > > jak>> How, specifically, is authorization set up for a prefix between > the MR and HA? using the Prefix Table on the Home Agent. ofcourse there is the issue of filling up the Prefix Table. if the Mobile Router is manually configured with a Mobile Network Prefix (MNP), then you have to manually add entries to the Prefix Table. if the Mobile Router gets the MNP through DHCPv6 based prefix delegation, the Home Agent always acts as a DHCP relay. it is then easy for the Home Agent to figure out which Mobile Router was delegated which prefix. there is a draft by Raplh Droms on extending prefix delegation for NEMO. http://www.ietf.org/internet-drafts/draft-droms-nemo-dhcpv6-pd-00.txt Vijay From nemo-admin@ietf.org Wed Nov 19 15:33:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10354 for ; Wed, 19 Nov 2003 15:33: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 1AMZ0W-0006Ze-Rl; Wed, 19 Nov 2003 15: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 1AMZ0I-0006Yt-8h for nemo@optimus.ietf.org; Wed, 19 Nov 2003 15:32: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 PAA10299 for ; Wed, 19 Nov 2003 15:32:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMZ0G-0001gU-00 for nemo@ietf.org; Wed, 19 Nov 2003 15:32:44 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AMZ0G-0001gR-00 for nemo@ietf.org; Wed, 19 Nov 2003 15:32:44 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hAJKWXkt026931; Wed, 19 Nov 2003 13:32:33 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hAJKWXXM025043; Wed, 19 Nov 2003 14:32:34 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 91D042EC95; Wed, 19 Nov 2003 21:32:32 +0100 (CET) Message-ID: <3FBBD360.50402@motorola.com> Date: Wed, 19 Nov 2003 21:32:32 +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: James Kempf , nemo@ietf.org Subject: Re: [nemo] Jim's comments on Basic Support References: <3FBBCCE1.6080005@iprg.nokia.com> In-Reply-To: <3FBBCCE1.6080005@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > hi Jim, > > I have filed your comments as Issues 20 and 21 at > http://people.nokia.net/vijayd/nemo/issues.html. > >> When the Mobile Router is at home, it MAY be configured to send >> Router Advertisements and reply to Router Solicitations on the >> interface attached to the home link. The value of the Router >> Lifetime field MUST be set to zero to prevent other nodes from >> configuring the Mobile Router as the default router. >> >> jak> What happens if the Mobile Router advertises prefix A on the >> home link, then moves and advertises prefix B? This could happen if >> the Mobile Router was configured for a particular prefix on the >> home link, then received a separate prefix when it moved away. I agree there might be a problem if MR is allowed to advertise _any_ prefix (send RA's) on the visited link (be it prefix A, or a dynamically acquired prefix B from HA). I think that's why spec says MR SHOULD NOT send RA's on the visited link. What could be discussed is whether this should be a "SHOULD NOT" or a "MUST NOT". I suggest to keep it "SHOULD NOT". >> A Mobile Router SHOULD NOT send unsolicited Router Advertisements >> and SHOULD NOT reply to Router Solicitations on any egress >> interface when that interface is attached to a visited link. >> However, the Mobile Router SHOULD reply with Neighbor >> Advertisements to Neighbor Solicitations received on the egress >> interface, for topologically correct addresses. >> >> jak> What happens to hosts that are utilizing the router due to it >> having sent unsolicted RAs on the egress interface on the home >> link when the router moves away? So are you suggesting making it "MUST NOT"? >> Wouldn't it be better just to prohibit the Mobile Router from >> responding to RSs and sending unsolicited RAs on its egress >> interface? Prohibit that, maybe yes, but only when MR is away from home. I suggest to keep it as SHOULD NOT, in order to allow for an extreme case that is this: MR attaches to AR. A new MH attaches to same AR. Fade AR disappear away. At this point, if MR does not send RA's on the visited link it has no way of talking to MH. This would be a limited case, and if MR could send RA's in the ether (when AR is dead) then MH autoconfigures an address and can talk directly to MR (of course, not using their home addresses, and MH can not talk to LFN's inside the moving network). I think this is the only reason that could be a "SHOULD NOT" instead of a "MUST NOT". >> 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. >> >> jak> In fact, it MUST utilize these as described in the base MIP6 >> protocol for movement detection. What the MIPv6 spec does not observe (even if the MN terminology suggests so) is that that MN could be an MR and send RA's natively. Thinking in a MIPv6 for hosts context exclusively does not make it obvious that that MH might be able to talk to another MH, when they're both under the same AR and when that AR disappears. Alex From nemo-admin@ietf.org Thu Nov 20 14:02:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18811 for ; Thu, 20 Nov 2003 14:02: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 1AMu41-0001Pl-Kq; Thu, 20 Nov 2003 14: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 1AMu36-0001Ot-OW for nemo@optimus.ietf.org; Thu, 20 Nov 2003 14: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 OAA18760 for ; Thu, 20 Nov 2003 14:00:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMu34-0000Qr-00 for nemo@ietf.org; Thu, 20 Nov 2003 14:01:02 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AMu33-0000QW-00 for nemo@ietf.org; Thu, 20 Nov 2003 14:01:01 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAKJ0Ts28697; Thu, 20 Nov 2003 11:00:29 -0800 X-mProtect: <200311201900> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2PVJLZ; Thu, 20 Nov 2003 11:00:27 PST Message-ID: <3FBD1056.3020903@iprg.nokia.com> Date: Thu, 20 Nov 2003 11:04:54 -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: "James Kempf" , 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: Another Comment on the Nemo Basic 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 hi Jim, > Another possible issue with the Nemo basic draft occured to me this weekend. > Suppose a mobile router is on its home link and there are nodes on the > egress interface that are using the mobile router directly in order to reach > the subnet. When the mobile router moves, these nodes will be left without > route service for some period of time until they discover that the mobile > router has moved. > > One way to fix this problem is to have the mobile router send Redirect > messages to any nodes in its neighbor cache, redirecting traffic from it to > the home agent. it will be hard for the mobile router to figure out that is moving and then send a redirect before moving. it could lose connection to the home link abruptly. it is also possible that at this point the mobile router does not yet have a list of Home Agents (i.e. it hasnt performed DHAAD yet). but here is another suggestion. how about the Home Agent sending a redirect for the Mobile Network Prefix when it receives a Binding Update from the mobile router? hosts on the home link would process the redirect and update the routes to point to the Home Agent. the redirect is not sent if the mobile router just refreshes an existing binding. for the period between the Mobile Router leaving the home link and sending a Binding Update to the Home Agent, the mobile router would be unreachable. this was discussed earlier in the design team. I dont remember why we didnt add any text. :) Vijay From exim@www1.ietf.org Thu Nov 20 14:02:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18828 for ; Thu, 20 Nov 2003 14:02: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 1AMu43-0001Qx-K6 for nemo-archive@odin.ietf.org; Thu, 20 Nov 2003 14:02:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKJ23Vb005505 for nemo-archive@odin.ietf.org; Thu, 20 Nov 2003 14:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMu43-0001Qi-Fu for nemo-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 14:02: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 OAA18798 for ; Thu, 20 Nov 2003 14:01:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMu41-0000Sr-00 for nemo-web-archive@ietf.org; Thu, 20 Nov 2003 14:02:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMu40-0000So-00 for nemo-web-archive@ietf.org; Thu, 20 Nov 2003 14:02:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMu41-0001Pl-Kq; Thu, 20 Nov 2003 14: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 1AMu36-0001Ot-OW for nemo@optimus.ietf.org; Thu, 20 Nov 2003 14: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 OAA18760 for ; Thu, 20 Nov 2003 14:00:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMu34-0000Qr-00 for nemo@ietf.org; Thu, 20 Nov 2003 14:01:02 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AMu33-0000QW-00 for nemo@ietf.org; Thu, 20 Nov 2003 14:01:01 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAKJ0Ts28697; Thu, 20 Nov 2003 11:00:29 -0800 X-mProtect: <200311201900> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2PVJLZ; Thu, 20 Nov 2003 11:00:27 PST Message-ID: <3FBD1056.3020903@iprg.nokia.com> Date: Thu, 20 Nov 2003 11:04:54 -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: "James Kempf" , 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: Another Comment on the Nemo Basic 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 Content-Transfer-Encoding: 7bit hi Jim, > Another possible issue with the Nemo basic draft occured to me this weekend. > Suppose a mobile router is on its home link and there are nodes on the > egress interface that are using the mobile router directly in order to reach > the subnet. When the mobile router moves, these nodes will be left without > route service for some period of time until they discover that the mobile > router has moved. > > One way to fix this problem is to have the mobile router send Redirect > messages to any nodes in its neighbor cache, redirecting traffic from it to > the home agent. it will be hard for the mobile router to figure out that is moving and then send a redirect before moving. it could lose connection to the home link abruptly. it is also possible that at this point the mobile router does not yet have a list of Home Agents (i.e. it hasnt performed DHAAD yet). but here is another suggestion. how about the Home Agent sending a redirect for the Mobile Network Prefix when it receives a Binding Update from the mobile router? hosts on the home link would process the redirect and update the routes to point to the Home Agent. the redirect is not sent if the mobile router just refreshes an existing binding. for the period between the Mobile Router leaving the home link and sending a Binding Update to the Home Agent, the mobile router would be unreachable. this was discussed earlier in the design team. I dont remember why we didnt add any text. :) Vijay From nemo-admin@ietf.org Thu Nov 20 14:08:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19012 for ; Thu, 20 Nov 2003 14:08: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 1AMu9s-0001wr-Aa; Thu, 20 Nov 2003 14:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMu9f-0001sT-91 for nemo@optimus.ietf.org; Thu, 20 Nov 2003 14:07: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 OAA18979 for ; Thu, 20 Nov 2003 14:07:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMu9c-0000Wu-00 for nemo@ietf.org; Thu, 20 Nov 2003 14:07:48 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AMu9c-0000Wq-00 for nemo@ietf.org; Thu, 20 Nov 2003 14:07:48 -0500 Message-ID: <0e7b01c3af99$a349dd90$956015ac@dclkempt40> From: "James Kempf" To: "Vijay Devarapalli" , References: <3FBD1056.3020903@iprg.nokia.com> Date: Thu, 20 Nov 2003 11:08:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Another Comment on the Nemo Basic 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 > but here is another suggestion. how about the Home Agent sending > a redirect for the Mobile Network Prefix when it receives a Binding > Update from the mobile router? hosts on the home link would process > the redirect and update the routes to point to the Home Agent. the > redirect is not sent if the mobile router just refreshes an existing > binding. > > for the period between the Mobile Router leaving the home link and > sending a Binding Update to the Home Agent, the mobile router would > be unreachable. > > this was discussed earlier in the design team. I dont remember why > we didnt add any text. :) > Rereading RFC 2461 Section 8, I now see that this isn't an issue because Redirects only apply to the first hop router. In the scenario I described, the mobile router is not the first hop router for a host, but rather is the ingress router for the mobile subnet. The first hop router would be another router on the subnet connecting the mobile router and the host, or possibly the home agent if it is a first hop router. Thus, such a host would send packets destined for the mobile subnet to the first hop router, which would forward them to the mobile router. Sorry for the confusion. jak From exim@www1.ietf.org Thu Nov 20 14:08:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19030 for ; Thu, 20 Nov 2003 14:08: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 1AMu9z-00020V-Oc for nemo-archive@odin.ietf.org; Thu, 20 Nov 2003 14:08:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKJ8BBi007579 for nemo-archive@odin.ietf.org; Thu, 20 Nov 2003 14:08:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMu9w-0001yA-RM for nemo-web-archive@optimus.ietf.org; Thu, 20 Nov 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 OAA18996 for ; Thu, 20 Nov 2003 14:07:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMu9u-0000XU-00 for nemo-web-archive@ietf.org; Thu, 20 Nov 2003 14:08:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMu9u-0000XR-00 for nemo-web-archive@ietf.org; Thu, 20 Nov 2003 14:08:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMu9s-0001wr-Aa; Thu, 20 Nov 2003 14:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMu9f-0001sT-91 for nemo@optimus.ietf.org; Thu, 20 Nov 2003 14:07: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 OAA18979 for ; Thu, 20 Nov 2003 14:07:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMu9c-0000Wu-00 for nemo@ietf.org; Thu, 20 Nov 2003 14:07:48 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AMu9c-0000Wq-00 for nemo@ietf.org; Thu, 20 Nov 2003 14:07:48 -0500 Message-ID: <0e7b01c3af99$a349dd90$956015ac@dclkempt40> From: "James Kempf" To: "Vijay Devarapalli" , References: <3FBD1056.3020903@iprg.nokia.com> Date: Thu, 20 Nov 2003 11:08:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Another Comment on the Nemo Basic 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 Content-Transfer-Encoding: 7bit > but here is another suggestion. how about the Home Agent sending > a redirect for the Mobile Network Prefix when it receives a Binding > Update from the mobile router? hosts on the home link would process > the redirect and update the routes to point to the Home Agent. the > redirect is not sent if the mobile router just refreshes an existing > binding. > > for the period between the Mobile Router leaving the home link and > sending a Binding Update to the Home Agent, the mobile router would > be unreachable. > > this was discussed earlier in the design team. I dont remember why > we didnt add any text. :) > Rereading RFC 2461 Section 8, I now see that this isn't an issue because Redirects only apply to the first hop router. In the scenario I described, the mobile router is not the first hop router for a host, but rather is the ingress router for the mobile subnet. The first hop router would be another router on the subnet connecting the mobile router and the host, or possibly the home agent if it is a first hop router. Thus, such a host would send packets destined for the mobile subnet to the first hop router, which would forward them to the mobile router. Sorry for the confusion. jak From nemo-admin@ietf.org Thu Nov 20 14:17:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19351 for ; Thu, 20 Nov 2003 14: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 1AMuIX-0002RH-Cp; Thu, 20 Nov 2003 14: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 1AMuIN-0002Qv-PN for nemo@optimus.ietf.org; Thu, 20 Nov 2003 14:16: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 OAA19333 for ; Thu, 20 Nov 2003 14:16:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMuIL-0000eu-00 for nemo@ietf.org; Thu, 20 Nov 2003 14:16:49 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AMuIK-0000er-00 for nemo@ietf.org; Thu, 20 Nov 2003 14:16:48 -0500 Message-ID: <0e8501c3af9a$e5ca7160$956015ac@dclkempt40> From: "James Kempf" To: "Alexandru Petrescu" , "Vijay Devarapalli" Cc: References: <3FBBCCE1.6080005@iprg.nokia.com> <3FBBD360.50402@motorola.com> Subject: Re: [nemo] Jim's comments on Basic Support Date: Thu, 20 Nov 2003 11:17:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > >> A Mobile Router SHOULD NOT send unsolicited Router Advertisements > >> and SHOULD NOT reply to Router Solicitations on any egress > >> interface when that interface is attached to a visited link. > >> However, the Mobile Router SHOULD reply with Neighbor > >> Advertisements to Neighbor Solicitations received on the egress > >> interface, for topologically correct addresses. > >> > >> jak> What happens to hosts that are utilizing the router due to it > >> having sent unsolicted RAs on the egress interface on the home > >> link when the router moves away? > > So are you suggesting making it "MUST NOT"? > In fact, the router won't do this anyway if it is RFC 2461 compliant if the mobile subnet is a stub subnet (as it is in the NEMO scenario), since the mobile router will only be the first hop router for nodes within the mobile subnet and not without ('cause the stub subnet doesn't lead to the Internet). I'd suggest perhaps adding wording to that effect, just to emphasize the fact. RFC 2461 only allows a router to advertise if it is a first hop router. A mobile router connected up to its home link or on a visited link is only a first hop router to nodes within its subnet, not on the egress side. So it should not be advertising there. > >> 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. > >> > >> jak> In fact, it MUST utilize these as described in the base MIP6 > >> protocol for movement detection. > > What the MIPv6 spec does not observe (even if the MN terminology > suggests so) is that that MN could be an MR and send RA's natively. > Thinking in a MIPv6 for hosts context exclusively does not make it > obvious that that MH might be able to talk to another MH, when they're > both under the same AR and when that AR disappears. > I'm not sure I follow. My point was only that at first pass, I don't see any reason why movement detection for routers should be any different than for hosts. So the MIPv6 movement detection rules should be the same. Probing more deeply, as the DNA BOF is doing, may turn up some corner cases, of course. jak From exim@www1.ietf.org Thu Nov 20 14:17:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19366 for ; Thu, 20 Nov 2003 14: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 1AMuIY-0002SK-Sj for nemo-archive@odin.ietf.org; Thu, 20 Nov 2003 14:17:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKJH231009434 for nemo-archive@odin.ietf.org; Thu, 20 Nov 2003 14:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuIY-0002S5-O7 for nemo-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 14:17: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 OAA19341 for ; Thu, 20 Nov 2003 14:16:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMuIW-0000f5-00 for nemo-web-archive@ietf.org; Thu, 20 Nov 2003 14:17:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMuIV-0000f2-00 for nemo-web-archive@ietf.org; Thu, 20 Nov 2003 14:16:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuIX-0002RH-Cp; Thu, 20 Nov 2003 14: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 1AMuIN-0002Qv-PN for nemo@optimus.ietf.org; Thu, 20 Nov 2003 14:16: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 OAA19333 for ; Thu, 20 Nov 2003 14:16:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMuIL-0000eu-00 for nemo@ietf.org; Thu, 20 Nov 2003 14:16:49 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AMuIK-0000er-00 for nemo@ietf.org; Thu, 20 Nov 2003 14:16:48 -0500 Message-ID: <0e8501c3af9a$e5ca7160$956015ac@dclkempt40> From: "James Kempf" To: "Alexandru Petrescu" , "Vijay Devarapalli" Cc: References: <3FBBCCE1.6080005@iprg.nokia.com> <3FBBD360.50402@motorola.com> Subject: Re: [nemo] Jim's comments on Basic Support Date: Thu, 20 Nov 2003 11:17:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > >> A Mobile Router SHOULD NOT send unsolicited Router Advertisements > >> and SHOULD NOT reply to Router Solicitations on any egress > >> interface when that interface is attached to a visited link. > >> However, the Mobile Router SHOULD reply with Neighbor > >> Advertisements to Neighbor Solicitations received on the egress > >> interface, for topologically correct addresses. > >> > >> jak> What happens to hosts that are utilizing the router due to it > >> having sent unsolicted RAs on the egress interface on the home > >> link when the router moves away? > > So are you suggesting making it "MUST NOT"? > In fact, the router won't do this anyway if it is RFC 2461 compliant if the mobile subnet is a stub subnet (as it is in the NEMO scenario), since the mobile router will only be the first hop router for nodes within the mobile subnet and not without ('cause the stub subnet doesn't lead to the Internet). I'd suggest perhaps adding wording to that effect, just to emphasize the fact. RFC 2461 only allows a router to advertise if it is a first hop router. A mobile router connected up to its home link or on a visited link is only a first hop router to nodes within its subnet, not on the egress side. So it should not be advertising there. > >> 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. > >> > >> jak> In fact, it MUST utilize these as described in the base MIP6 > >> protocol for movement detection. > > What the MIPv6 spec does not observe (even if the MN terminology > suggests so) is that that MN could be an MR and send RA's natively. > Thinking in a MIPv6 for hosts context exclusively does not make it > obvious that that MH might be able to talk to another MH, when they're > both under the same AR and when that AR disappears. > I'm not sure I follow. My point was only that at first pass, I don't see any reason why movement detection for routers should be any different than for hosts. So the MIPv6 movement detection rules should be the same. Probing more deeply, as the DNA BOF is doing, may turn up some corner cases, of course. jak From nemo-admin@ietf.org Thu Nov 20 14:50:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20811 for ; Thu, 20 Nov 2003 14: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 1AMuoT-0004N2-HV; Thu, 20 Nov 2003 14: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 1AMuo7-0004MN-Qd for nemo@optimus.ietf.org; Thu, 20 Nov 2003 14:49:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20773 for ; Thu, 20 Nov 2003 14:49:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMuo4-0001Bp-00 for nemo@ietf.org; Thu, 20 Nov 2003 14:49:37 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AMuo4-0001Bm-00 for nemo@ietf.org; Thu, 20 Nov 2003 14:49:36 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hAKJmK39017152; Thu, 20 Nov 2003 12:48:20 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hAKJhwXM010022; Thu, 20 Nov 2003 13:43:59 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 1FF742EC95; Thu, 20 Nov 2003 20:43:58 +0100 (CET) Message-ID: <3FBD197D.5050309@motorola.com> Date: Thu, 20 Nov 2003 20:43:57 +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: James Kempf Cc: Vijay Devarapalli , nemo@ietf.org Subject: Re: [nemo] Jim's comments on Basic Support References: <3FBBCCE1.6080005@iprg.nokia.com> <3FBBD360.50402@motorola.com> <0e8501c3af9a$e5ca7160$956015ac@dclkempt40> In-Reply-To: <0e8501c3af9a$e5ca7160$956015ac@dclkempt40> 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 James Kempf wrote: >>>> A Mobile Router SHOULD NOT send unsolicited Router >>>> Advertisements and SHOULD NOT reply to Router Solicitations on >>>> any egress interface when that interface is attached to a >>>> visited link. However, the Mobile Router SHOULD reply with >>>> Neighbor Advertisements to Neighbor Solicitations received on >>>> the egress interface, for topologically correct addresses. >>>> >>>> jak> What happens to hosts that are utilizing the router due to >>>> it having sent unsolicted RAs on the egress interface on the >>>> home link when the router moves away? >> >> So are you suggesting making it "MUST NOT"? >> > > > In fact, the router won't do this anyway if it is RFC 2461 compliant > if the mobile subnet is a stub subnet (as it is in the NEMO > scenario), since the mobile router will only be the first hop router > for nodes within the mobile subnet and not without ('cause the stub > subnet doesn't lead to the Internet). I'd suggest perhaps adding > wording to that effect, just to emphasize the fact. I think a short clarification adding that is writable and needed. > RFC 2461 only allows a router to advertise if it is a first hop > router. A mobile router connected up to its home link or on a visited > link is only a first hop router to nodes within its subnet, not on > the egress side. So it should not be advertising there. Seems logic, but. MR at home _will_ become a first-hop for hosts on the home link (towards hosts on the stub subnet) after FN receives an ICMP Redirect from the current first-hop router. (detailed scenario is this: host "FN" on the home link wants to talk to LFN on the stub subnet, sends packet to HA which is currently its first-hop, HA forwards packet to MR and simultaneously sends Redirect to FN, FN adds a new route towards LFN through MR, thus MR becomes a first-hop; at least that's the way I understand Redirects) >>>> 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. >>>> >>>> jak> In fact, it MUST utilize these as described in the base >>>> MIP6 protocol for movement detection. >> >> What the MIPv6 spec does not observe (even if the MN terminology >> suggests so) is that that MN could be an MR and send RA's natively. >> Thinking in a MIPv6 for hosts context exclusively does not make it >> obvious that that MH might be able to talk to another MH, when >> they're both under the same AR and when that AR disappears. >> > > > I'm not sure I follow. Err, yes, ok. Just wanted to say that MIPv6 spec does not consider very much that MN is a router too. Nevermind, not relevant. > My point was only that at first pass, I don't see any reason why > movement detection for routers should be any different than for > hosts. So the MIPv6 movement detection rules should be the same. > Probing more deeply, as the DNA BOF is doing, may turn up some corner > cases, of course. With respect to movement detection, I entirely agree with you. MR should movement detect exactly as MIPv6 spec says it, or as a potential DNA spec will say it. Maybe short specific text could be added saying MR movement detects as MIPv6 says it to do, it's safer. But I doubt that either the MIPv6 spec or the DNA spec will have anything in their movement detection that influences MN _sending_ RA's or _receiving_ RS's (I agree, it is based on _receiving_ RA's). Alex From exim@www1.ietf.org Thu Nov 20 14:50:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20826 for ; Thu, 20 Nov 2003 14:50: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 1AMuoX-0004Os-S5 for nemo-archive@odin.ietf.org; Thu, 20 Nov 2003 14:50:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKJo5IK016908 for nemo-archive@odin.ietf.org; Thu, 20 Nov 2003 14:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuoX-0004Od-Mg for nemo-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 14:50: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 OAA20788 for ; Thu, 20 Nov 2003 14:49:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMuoU-0001CQ-00 for nemo-web-archive@ietf.org; Thu, 20 Nov 2003 14:50:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMuoU-0001CL-00 for nemo-web-archive@ietf.org; Thu, 20 Nov 2003 14:50:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuoT-0004N2-HV; Thu, 20 Nov 2003 14: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 1AMuo7-0004MN-Qd for nemo@optimus.ietf.org; Thu, 20 Nov 2003 14:49:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20773 for ; Thu, 20 Nov 2003 14:49:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMuo4-0001Bp-00 for nemo@ietf.org; Thu, 20 Nov 2003 14:49:37 -0500 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AMuo4-0001Bm-00 for nemo@ietf.org; Thu, 20 Nov 2003 14:49:36 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hAKJmK39017152; Thu, 20 Nov 2003 12:48:20 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hAKJhwXM010022; Thu, 20 Nov 2003 13:43:59 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 1FF742EC95; Thu, 20 Nov 2003 20:43:58 +0100 (CET) Message-ID: <3FBD197D.5050309@motorola.com> Date: Thu, 20 Nov 2003 20:43:57 +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: James Kempf Cc: Vijay Devarapalli , nemo@ietf.org Subject: Re: [nemo] Jim's comments on Basic Support References: <3FBBCCE1.6080005@iprg.nokia.com> <3FBBD360.50402@motorola.com> <0e8501c3af9a$e5ca7160$956015ac@dclkempt40> In-Reply-To: <0e8501c3af9a$e5ca7160$956015ac@dclkempt40> 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 James Kempf wrote: >>>> A Mobile Router SHOULD NOT send unsolicited Router >>>> Advertisements and SHOULD NOT reply to Router Solicitations on >>>> any egress interface when that interface is attached to a >>>> visited link. However, the Mobile Router SHOULD reply with >>>> Neighbor Advertisements to Neighbor Solicitations received on >>>> the egress interface, for topologically correct addresses. >>>> >>>> jak> What happens to hosts that are utilizing the router due to >>>> it having sent unsolicted RAs on the egress interface on the >>>> home link when the router moves away? >> >> So are you suggesting making it "MUST NOT"? >> > > > In fact, the router won't do this anyway if it is RFC 2461 compliant > if the mobile subnet is a stub subnet (as it is in the NEMO > scenario), since the mobile router will only be the first hop router > for nodes within the mobile subnet and not without ('cause the stub > subnet doesn't lead to the Internet). I'd suggest perhaps adding > wording to that effect, just to emphasize the fact. I think a short clarification adding that is writable and needed. > RFC 2461 only allows a router to advertise if it is a first hop > router. A mobile router connected up to its home link or on a visited > link is only a first hop router to nodes within its subnet, not on > the egress side. So it should not be advertising there. Seems logic, but. MR at home _will_ become a first-hop for hosts on the home link (towards hosts on the stub subnet) after FN receives an ICMP Redirect from the current first-hop router. (detailed scenario is this: host "FN" on the home link wants to talk to LFN on the stub subnet, sends packet to HA which is currently its first-hop, HA forwards packet to MR and simultaneously sends Redirect to FN, FN adds a new route towards LFN through MR, thus MR becomes a first-hop; at least that's the way I understand Redirects) >>>> 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. >>>> >>>> jak> In fact, it MUST utilize these as described in the base >>>> MIP6 protocol for movement detection. >> >> What the MIPv6 spec does not observe (even if the MN terminology >> suggests so) is that that MN could be an MR and send RA's natively. >> Thinking in a MIPv6 for hosts context exclusively does not make it >> obvious that that MH might be able to talk to another MH, when >> they're both under the same AR and when that AR disappears. >> > > > I'm not sure I follow. Err, yes, ok. Just wanted to say that MIPv6 spec does not consider very much that MN is a router too. Nevermind, not relevant. > My point was only that at first pass, I don't see any reason why > movement detection for routers should be any different than for > hosts. So the MIPv6 movement detection rules should be the same. > Probing more deeply, as the DNA BOF is doing, may turn up some corner > cases, of course. With respect to movement detection, I entirely agree with you. MR should movement detect exactly as MIPv6 spec says it, or as a potential DNA spec will say it. Maybe short specific text could be added saying MR movement detects as MIPv6 says it to do, it's safer. But I doubt that either the MIPv6 spec or the DNA spec will have anything in their movement detection that influences MN _sending_ RA's or _receiving_ RS's (I agree, it is based on _receiving_ RA's). Alex From nemo-admin@ietf.org Thu Nov 20 14:54:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21099 for ; Thu, 20 Nov 2003 14:54: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 1AMusK-0005Ag-Sc; Thu, 20 Nov 2003 14:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMurc-00050N-PH for nemo@optimus.ietf.org; Thu, 20 Nov 2003 14:53: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 OAA20991 for ; Thu, 20 Nov 2003 14:53:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMurZ-0001FR-00 for nemo@ietf.org; Thu, 20 Nov 2003 14:53:13 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AMurZ-0001FL-00 for nemo@ietf.org; Thu, 20 Nov 2003 14:53:13 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id hAKJqu6b011541; Thu, 20 Nov 2003 12:52:58 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hAKJqhXM019172; Thu, 20 Nov 2003 13:52:44 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 0CA682EC95; Thu, 20 Nov 2003 20:52:43 +0100 (CET) Message-ID: <3FBD1B8A.4080509@motorola.com> Date: Thu, 20 Nov 2003 20:52:42 +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: James Kempf , nemo@ietf.org Subject: Re: [nemo] Re: Another Comment on the Nemo Basic Draft References: <3FBD1056.3020903@iprg.nokia.com> In-Reply-To: <3FBD1056.3020903@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > hi Jim, > >> Another possible issue with the Nemo basic draft occured to me this >> weekend. Suppose a mobile router is on its home link and there are >> nodes on the egress interface that are using the mobile router >> directly in order to reach the subnet. When the mobile router >> moves, these nodes will be left without route service for some >> period of time until they discover that the mobile router has >> moved. >> >> One way to fix this problem is to have the mobile router send >> Redirect messages to any nodes in its neighbor cache, redirecting >> traffic from it to the home agent > > > it will be hard for the mobile router to figure out that is moving > and then send a redirect before moving. it could lose connection to > the home link abruptly. it is also possible that at this point the > mobile router does not yet have a list of Home Agents (i.e. it hasnt > performed DHAAD yet). Yes. > but here is another suggestion. how about the Home Agent sending a > redirect for the Mobile Network Prefix when it receives a Binding > Update from the mobile router? Sounds good. This is especially useful if the FN's have already been redirected by HA in the first place towards MR (when MR was at home). > this was discussed earlier in the design team. I dont remember why we > didnt add any text. :) One issue with Redirects was that Redirects can be one of the "external" means by which HA will learn the routes towards MR in implicit mode, if the HA is not GW and needs to talk to MR and MR not at home (GW will Redirect and HA will thus learn a route). Alex From exim@www1.ietf.org Thu Nov 20 14:54:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21114 for ; Thu, 20 Nov 2003 14: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 1AMusP-0005Fv-HB for nemo-archive@odin.ietf.org; Thu, 20 Nov 2003 14:54:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKJs4tK020190 for nemo-archive@odin.ietf.org; Thu, 20 Nov 2003 14:54:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMusM-0005DZ-6E for nemo-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 14: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 OAA21033 for ; Thu, 20 Nov 2003 14:53:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMusJ-0001Gc-00 for nemo-web-archive@ietf.org; Thu, 20 Nov 2003 14:53:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMusI-0001GZ-00 for nemo-web-archive@ietf.org; Thu, 20 Nov 2003 14:53:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMusK-0005Ag-Sc; Thu, 20 Nov 2003 14:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMurc-00050N-PH for nemo@optimus.ietf.org; Thu, 20 Nov 2003 14:53: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 OAA20991 for ; Thu, 20 Nov 2003 14:53:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMurZ-0001FR-00 for nemo@ietf.org; Thu, 20 Nov 2003 14:53:13 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AMurZ-0001FL-00 for nemo@ietf.org; Thu, 20 Nov 2003 14:53:13 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id hAKJqu6b011541; Thu, 20 Nov 2003 12:52:58 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hAKJqhXM019172; Thu, 20 Nov 2003 13:52:44 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 0CA682EC95; Thu, 20 Nov 2003 20:52:43 +0100 (CET) Message-ID: <3FBD1B8A.4080509@motorola.com> Date: Thu, 20 Nov 2003 20:52:42 +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: James Kempf , nemo@ietf.org Subject: Re: [nemo] Re: Another Comment on the Nemo Basic Draft References: <3FBD1056.3020903@iprg.nokia.com> In-Reply-To: <3FBD1056.3020903@iprg.nokia.com> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > hi Jim, > >> Another possible issue with the Nemo basic draft occured to me this >> weekend. Suppose a mobile router is on its home link and there are >> nodes on the egress interface that are using the mobile router >> directly in order to reach the subnet. When the mobile router >> moves, these nodes will be left without route service for some >> period of time until they discover that the mobile router has >> moved. >> >> One way to fix this problem is to have the mobile router send >> Redirect messages to any nodes in its neighbor cache, redirecting >> traffic from it to the home agent > > > it will be hard for the mobile router to figure out that is moving > and then send a redirect before moving. it could lose connection to > the home link abruptly. it is also possible that at this point the > mobile router does not yet have a list of Home Agents (i.e. it hasnt > performed DHAAD yet). Yes. > but here is another suggestion. how about the Home Agent sending a > redirect for the Mobile Network Prefix when it receives a Binding > Update from the mobile router? Sounds good. This is especially useful if the FN's have already been redirected by HA in the first place towards MR (when MR was at home). > this was discussed earlier in the design team. I dont remember why we > didnt add any text. :) One issue with Redirects was that Redirects can be one of the "external" means by which HA will learn the routes towards MR in implicit mode, if the HA is not GW and needs to talk to MR and MR not at home (GW will Redirect and HA will thus learn a route). Alex From nemo-admin@ietf.org Thu Nov 20 18:36:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07994 for ; Thu, 20 Nov 2003 18: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 1AMyLC-0006ME-0B; Thu, 20 Nov 2003 18: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 1AMyL4-0006Lj-AN for nemo@optimus.ietf.org; Thu, 20 Nov 2003 18:35: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 SAA07928 for ; Thu, 20 Nov 2003 18:35:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMyL1-0006lv-00 for nemo@ietf.org; Thu, 20 Nov 2003 18:35:51 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AMyL0-0006lj-00 for nemo@ietf.org; Thu, 20 Nov 2003 18:35:50 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAKNZHx16988; Thu, 20 Nov 2003 15:35:17 -0800 X-mProtect: <200311202335> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdstSIKm; Thu, 20 Nov 2003 15:35:15 PST Message-ID: <3FBD50BE.5090202@iprg.nokia.com> Date: Thu, 20 Nov 2003 15:39: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: nemo@ietf.org CC: souhwanj@ssu.ac.kr, gab@sun.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] tunneling threats Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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, Souhwan Jung presented some possible threats related to tunneling and MNN spoofing addresses. his presentation is at http://www.mobilenetworks.org/nemo/ietf58/slides/nemo-ietf58-threat-analysis.ppt (there is a pdf file of these slides at http://people.nokia.net/vijayd/nemo/nemo-ietf58-threat-analysis.pdf) I am trying to see if anything needs to be fixed for the Basic Support protocol to prevent these threats. threat 1, slide 3 ----------------- a MNN uses the CoA of the mobile router and sends a BU to the Home Agent. when the MR receives the BU, it realizes it has to forward the packet to the HA. Souhwan claimed that the IPsec SA used for protecting the Binding Update between MR and HA will get applied to this packet. what is missing in this slide is that we dont know if the MNN included a Home Address Option or not and if it did, what the contents of the Home Address Option are. so there are three cases. a. MNN did not include a Home Address Option b. MNN included a Home Address Option with address set to MR_HoA c. MNN included a Home Address Option with address set to some other address (a) is not a valid Binding Update and will be dropped immediately. section 5.2.1 of http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-06.txt describes the SPD entries on the mobile node/mobile router for protecting Binding Updates. mobile node SPD OUT: - IF source = home_address_1 & destination = home_agent_1 & proto = MH THEN USE SA SA1 the source address on the IPv6 header is not the home address of the MR when the MR attempts to forward the packet received from the MNN. so the SA for protecting the BU between MR and HA will be not be selected for protecting the packet. infact there wont be any SPD entry for source=MR_CoA, dst=HA, protocol=mobility. so the BU is forwarded unprotected. the Home Agent drops unprotected binding updates. and then ofcourse there is ingress filtering. if the MR does ingress filtering, it should drop the packet when it realises that an MNN is sending the packet with MR's CoA as the source address. threat 2, slide 4 ----------------- in this scenario, the MNN sends a Binding Update using IP-in-IP tunneling. once the packet is decapsulated at the MR, it looks exactly like the packet in threat 1. there is no problem again, because there is no corresponding SPD entry. and then there is another check that the Mobile Router can perform. whenever it decapsulates a packet and forwards the inner packet, it *must* verify if the source address on the inner header is valid. the decapsulated packet will fail this check because the source address on the inner header is the CoA of the MR. such checks were done today when you decapsulate a packet and forward the inner packet. and the claim in the slide "At this point, MR cannot tell the fake BU from a BU from itself, and applies IPsec ESP" is not valid. threat 3, slide 6 ----------------- in this scenario, MNN generates an IP packet with the source address set to a spoofed IP address, which does not belong to the Mobile Network. section 8 of the Basic Support draft says > 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. this check at the HA should prevent this threat. also if the MR performs ingress filtering, the packet will get dropped at the MR itself. Souhwan, if I misunderstood the threats, let me know. if folks are interested, there is a very long discussion of something similar at http://users.piuha.net/jarkko/publications/mipv6/issues/issue319.txt comments? Vijay From exim@www1.ietf.org Thu Nov 20 18:36:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08017 for ; Thu, 20 Nov 2003 18:36: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 1AMyLG-0006OR-QM for nemo-archive@odin.ietf.org; Thu, 20 Nov 2003 18:36:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKNa6h9024571 for nemo-archive@odin.ietf.org; Thu, 20 Nov 2003 18:36:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMyLG-0006OE-Lx for nemo-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 18:36: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 SAA07963 for ; Thu, 20 Nov 2003 18:35:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMyLD-0006md-00 for nemo-web-archive@ietf.org; Thu, 20 Nov 2003 18:36:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMyLD-0006mZ-00 for nemo-web-archive@ietf.org; Thu, 20 Nov 2003 18:36:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMyLC-0006ME-0B; Thu, 20 Nov 2003 18: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 1AMyL4-0006Lj-AN for nemo@optimus.ietf.org; Thu, 20 Nov 2003 18:35: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 SAA07928 for ; Thu, 20 Nov 2003 18:35:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMyL1-0006lv-00 for nemo@ietf.org; Thu, 20 Nov 2003 18:35:51 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AMyL0-0006lj-00 for nemo@ietf.org; Thu, 20 Nov 2003 18:35:50 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAKNZHx16988; Thu, 20 Nov 2003 15:35:17 -0800 X-mProtect: <200311202335> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdstSIKm; Thu, 20 Nov 2003 15:35:15 PST Message-ID: <3FBD50BE.5090202@iprg.nokia.com> Date: Thu, 20 Nov 2003 15:39: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: nemo@ietf.org CC: souhwanj@ssu.ac.kr, gab@sun.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] tunneling threats Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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, Souhwan Jung presented some possible threats related to tunneling and MNN spoofing addresses. his presentation is at http://www.mobilenetworks.org/nemo/ietf58/slides/nemo-ietf58-threat-analysis.ppt (there is a pdf file of these slides at http://people.nokia.net/vijayd/nemo/nemo-ietf58-threat-analysis.pdf) I am trying to see if anything needs to be fixed for the Basic Support protocol to prevent these threats. threat 1, slide 3 ----------------- a MNN uses the CoA of the mobile router and sends a BU to the Home Agent. when the MR receives the BU, it realizes it has to forward the packet to the HA. Souhwan claimed that the IPsec SA used for protecting the Binding Update between MR and HA will get applied to this packet. what is missing in this slide is that we dont know if the MNN included a Home Address Option or not and if it did, what the contents of the Home Address Option are. so there are three cases. a. MNN did not include a Home Address Option b. MNN included a Home Address Option with address set to MR_HoA c. MNN included a Home Address Option with address set to some other address (a) is not a valid Binding Update and will be dropped immediately. section 5.2.1 of http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-06.txt describes the SPD entries on the mobile node/mobile router for protecting Binding Updates. mobile node SPD OUT: - IF source = home_address_1 & destination = home_agent_1 & proto = MH THEN USE SA SA1 the source address on the IPv6 header is not the home address of the MR when the MR attempts to forward the packet received from the MNN. so the SA for protecting the BU between MR and HA will be not be selected for protecting the packet. infact there wont be any SPD entry for source=MR_CoA, dst=HA, protocol=mobility. so the BU is forwarded unprotected. the Home Agent drops unprotected binding updates. and then ofcourse there is ingress filtering. if the MR does ingress filtering, it should drop the packet when it realises that an MNN is sending the packet with MR's CoA as the source address. threat 2, slide 4 ----------------- in this scenario, the MNN sends a Binding Update using IP-in-IP tunneling. once the packet is decapsulated at the MR, it looks exactly like the packet in threat 1. there is no problem again, because there is no corresponding SPD entry. and then there is another check that the Mobile Router can perform. whenever it decapsulates a packet and forwards the inner packet, it *must* verify if the source address on the inner header is valid. the decapsulated packet will fail this check because the source address on the inner header is the CoA of the MR. such checks were done today when you decapsulate a packet and forward the inner packet. and the claim in the slide "At this point, MR cannot tell the fake BU from a BU from itself, and applies IPsec ESP" is not valid. threat 3, slide 6 ----------------- in this scenario, MNN generates an IP packet with the source address set to a spoofed IP address, which does not belong to the Mobile Network. section 8 of the Basic Support draft says > 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. this check at the HA should prevent this threat. also if the MR performs ingress filtering, the packet will get dropped at the MR itself. Souhwan, if I misunderstood the threats, let me know. if folks are interested, there is a very long discussion of something similar at http://users.piuha.net/jarkko/publications/mipv6/issues/issue319.txt comments? Vijay From nemo-admin@ietf.org Fri Nov 21 12:16:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22924 for ; Fri, 21 Nov 2003 12:16: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 1ANEsz-0005ep-QC; Fri, 21 Nov 2003 12: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 1ANEsJ-0005ce-Ts for nemo@optimus.ietf.org; Fri, 21 Nov 2003 12:15: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 MAA22880 for ; Fri, 21 Nov 2003 12:15:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANEsI-0005Uf-00 for nemo@ietf.org; Fri, 21 Nov 2003 12:15:18 -0500 Received: from mailhost.owl.co.uk ([194.201.150.21] helo=gatekeeper.owl.co.uk) by ietf-mx with smtp (Exim 4.12) id 1ANEsH-0005U0-00 for nemo@ietf.org; Fri, 21 Nov 2003 12:15:17 -0500 Received: from mailhost.panasonic-owl.co.uk (unverified) by gatekeeper.owl.co.uk (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Fri, 21 Nov 2003 17:21:07 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B052.F6707C80" X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 21 Nov 2003 17:14:46 -0000 Message-ID: <46AC004B0D5292499E5C49C6597DCA480537AB@panaowl01.panasonic-owl.co.uk> Thread-Topic: Multiple mobile network prefixes Thread-Index: AcOwUvZhK+hQAmyYR/mca2H6YclBpg== From: "Matthew Wilkinson" To: Subject: [nemo] Multiple mobile network prefixes Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B052.F6707C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 Hopefully an easy query for you all :) =20 I have been wondering about the case when a mobile network has many prefixes. I'm happy to accept that an implementation of NEMO should be able to handle any number of prefixes, but I'd find it useful to be able to understand when it would actually happen that a mobile network would have many prefixes. Would it be when the MR has more than one ingress interface? Or in other configurations? =20 Many thanks in advance. =20 Regards, Matthew =20 ------------------------------------------------------------------------ ----- Matthew Wilkinson Software Engineer Panasonic Office Workstations Ltd. TEL: +44 (0)131 5611064 FAX: +44 (0)131 5556027 Web: www.panasonic-owl.co.uk =20 ------------------------------------------------------------------------ ----- =20 ***************************************************************************= ***** CONFIDENTIALITY NOTICE The information contained in this Email, and any attachment is intended for= the=20 named recipient(s) only. It may contain confidential and / or privileged information. If you are not the intended recipient, you must not copy, distribute, or take any action in reliance on it. Any views expressed do no= t necessarily reflect the views of the company. If you receive this Email b= y=20 mistake, please advise the sender by using the reply facility in your Email= software, and then delete it. ***************************************************************************= ***** ------_=_NextPart_001_01C3B052.F6707C80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi
 
Hopefully= an easy=20 query for you all :)
 
I have be= en=20 wondering about the case when a mobile network has many prefixes.  I'm= happy to accept that an implementation of NEMO should be able to handle an= y=20 number of prefixes, but I'd find it useful to be able to understand when it= would actually happen that a mobile network would have many prefixes. = ;=20 Would it be when the MR has more than one ingress interface?   Or= in=20 other configurations?
 
Many than= ks in=20 advance.
 
Regards,
Matthew
 
------------------------------------------------------------------= -----------
Matthew Wilkinson
Software Engineer
Panasonic Office Workstations= Ltd.
TEL: +44 (0)131 5611064 = FAX: +44=20 (0)131 5556027
Web: www.panasonic-owl.co.uk=
------------------------------------------------------------------= -----------
 


***************************************************************************= *****
CONFIDENTIALITY NOTICE
The information contained in this Email, and any attachment is intended for= the
named recipient(s) only. It may contain confidential and / or privileged
information. If you are not the intended recipient, you must not copy,
distribute, or take any action in reliance on it. Any views expressed do no= t necessarily reflect the views of the company. If you receive this Email b= y
mistake, please advise the sender by using the reply facility in your Email=
software, and then delete it.
***************************************************************************= *****
 =00 ------_=_NextPart_001_01C3B052.F6707C80-- From exim@www1.ietf.org Fri Nov 21 12:16:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22939 for ; Fri, 21 Nov 2003 12:16: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 1ANEt7-0005fy-Dj for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 12:16:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALHG9PR021812 for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 12:16:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEt7-0005ff-8v for nemo-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 12:16: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 MAA22899 for ; Fri, 21 Nov 2003 12:15:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANEt4-0005VK-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 12:16:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANEt3-0005VC-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 12:16:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEsz-0005ep-QC; Fri, 21 Nov 2003 12: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 1ANEsJ-0005ce-Ts for nemo@optimus.ietf.org; Fri, 21 Nov 2003 12:15: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 MAA22880 for ; Fri, 21 Nov 2003 12:15:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANEsI-0005Uf-00 for nemo@ietf.org; Fri, 21 Nov 2003 12:15:18 -0500 Received: from mailhost.owl.co.uk ([194.201.150.21] helo=gatekeeper.owl.co.uk) by ietf-mx with smtp (Exim 4.12) id 1ANEsH-0005U0-00 for nemo@ietf.org; Fri, 21 Nov 2003 12:15:17 -0500 Received: from mailhost.panasonic-owl.co.uk (unverified) by gatekeeper.owl.co.uk (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Fri, 21 Nov 2003 17:21:07 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B052.F6707C80" X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 21 Nov 2003 17:14:46 -0000 Message-ID: <46AC004B0D5292499E5C49C6597DCA480537AB@panaowl01.panasonic-owl.co.uk> Thread-Topic: Multiple mobile network prefixes Thread-Index: AcOwUvZhK+hQAmyYR/mca2H6YclBpg== From: "Matthew Wilkinson" To: Subject: [nemo] Multiple mobile network prefixes Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B052.F6707C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 Hopefully an easy query for you all :) =20 I have been wondering about the case when a mobile network has many prefixes. I'm happy to accept that an implementation of NEMO should be able to handle any number of prefixes, but I'd find it useful to be able to understand when it would actually happen that a mobile network would have many prefixes. Would it be when the MR has more than one ingress interface? Or in other configurations? =20 Many thanks in advance. =20 Regards, Matthew =20 ------------------------------------------------------------------------ ----- Matthew Wilkinson Software Engineer Panasonic Office Workstations Ltd. TEL: +44 (0)131 5611064 FAX: +44 (0)131 5556027 Web: www.panasonic-owl.co.uk =20 ------------------------------------------------------------------------ ----- =20 ***************************************************************************= ***** CONFIDENTIALITY NOTICE The information contained in this Email, and any attachment is intended for= the=20 named recipient(s) only. It may contain confidential and / or privileged information. If you are not the intended recipient, you must not copy, distribute, or take any action in reliance on it. Any views expressed do no= t necessarily reflect the views of the company. If you receive this Email b= y=20 mistake, please advise the sender by using the reply facility in your Email= software, and then delete it. ***************************************************************************= ***** ------_=_NextPart_001_01C3B052.F6707C80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi
 
Hopefully= an easy=20 query for you all :)
 
I have be= en=20 wondering about the case when a mobile network has many prefixes.  I'm= happy to accept that an implementation of NEMO should be able to handle an= y=20 number of prefixes, but I'd find it useful to be able to understand when it= would actually happen that a mobile network would have many prefixes. = ;=20 Would it be when the MR has more than one ingress interface?   Or= in=20 other configurations?
 
Many than= ks in=20 advance.
 
Regards,
Matthew
 
------------------------------------------------------------------= -----------
Matthew Wilkinson
Software Engineer
Panasonic Office Workstations= Ltd.
TEL: +44 (0)131 5611064 = FAX: +44=20 (0)131 5556027
Web: www.panasonic-owl.co.uk=
------------------------------------------------------------------= -----------
 


***************************************************************************= *****
CONFIDENTIALITY NOTICE
The information contained in this Email, and any attachment is intended for= the
named recipient(s) only. It may contain confidential and / or privileged
information. If you are not the intended recipient, you must not copy,
distribute, or take any action in reliance on it. Any views expressed do no= t necessarily reflect the views of the company. If you receive this Email b= y
mistake, please advise the sender by using the reply facility in your Email=
software, and then delete it.
***************************************************************************= *****
 =00 ------_=_NextPart_001_01C3B052.F6707C80-- From nemo-admin@ietf.org Fri Nov 21 12:50:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24293 for ; Fri, 21 Nov 2003 12:50: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 1ANFPu-0007w9-9f; Fri, 21 Nov 2003 12:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFPA-0007vJ-QY for nemo@optimus.ietf.org; Fri, 21 Nov 2003 12:49: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 MAA24253 for ; Fri, 21 Nov 2003 12:49:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANFP9-000650-00 for nemo@ietf.org; Fri, 21 Nov 2003 12:49:15 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ANFP8-00064R-00 for nemo@ietf.org; Fri, 21 Nov 2003 12:49:14 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hALHm1X08448; Fri, 21 Nov 2003 09:48:01 -0800 X-mProtect: <200311211748> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrvqyNx; Fri, 21 Nov 2003 09:48:00 PST Message-ID: <3FBE50DE.9010101@iprg.nokia.com> Date: Fri, 21 Nov 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: James Kempf CC: Alexandru Petrescu , nemo@ietf.org Subject: Re: [nemo] Jim's comments on Basic Support References: <3FBBCCE1.6080005@iprg.nokia.com> <3FBBD360.50402@motorola.com> <0e8501c3af9a$e5ca7160$956015ac@dclkempt40> In-Reply-To: <0e8501c3af9a$e5ca7160$956015ac@dclkempt40> 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 James Kempf wrote: >>>>A Mobile Router SHOULD NOT send unsolicited Router Advertisements >>>>and SHOULD NOT reply to Router Solicitations on any egress >>>>interface when that interface is attached to a visited link. >>>>However, the Mobile Router SHOULD reply with Neighbor >>>>Advertisements to Neighbor Solicitations received on the egress >>>>interface, for topologically correct addresses. >>>> >>>>jak> What happens to hosts that are utilizing the router due to it >>>> having sent unsolicted RAs on the egress interface on the home >>>>link when the router moves away? >> >>So are you suggesting making it "MUST NOT"? >> > > > In fact, the router won't do this anyway if it is RFC 2461 compliant if the > mobile subnet is a stub subnet (as it is in the NEMO scenario), since the > mobile router will only be the first hop router for nodes within the mobile > subnet and not without ('cause the stub subnet doesn't lead to the > Internet). Jim, can you point me to the text in RFC 2461 which says a router shouldnt sent a router advertisement if it is not a first-hop router for the nodes on a link? > I'd suggest perhaps adding wording to that effect, just to > emphasize the fact. currently, the NEMO spec says that the mobile router MAY be configured to send router advertisements on its egress interface when it is attached to the home link. and if the mobile router is sending router advertisements, it should set the router lifetime to 0, so that the hosts on the home link do not configure the mobile router as a default router. is this what you are suggesting? Since the Mobile Router is not a first hop router for nodes on the home link, it SHOULD NOT send any router advertisements on its egress interface when attached to the home link. but I dont see RFC 2461 prohibiting such a thing. Vijay From exim@www1.ietf.org Fri Nov 21 12:50:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24308 for ; Fri, 21 Nov 2003 12:50: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 1ANFPy-0007yN-3n for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 12:50:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALHo6Ak030636 for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 12:50:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFPx-0007ww-So for nemo-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 12:50: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 MAA24286 for ; Fri, 21 Nov 2003 12:49:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANFPw-00065i-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 12:50:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANFPv-00065f-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 12:50:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFPu-0007w9-9f; Fri, 21 Nov 2003 12:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANFPA-0007vJ-QY for nemo@optimus.ietf.org; Fri, 21 Nov 2003 12:49: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 MAA24253 for ; Fri, 21 Nov 2003 12:49:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANFP9-000650-00 for nemo@ietf.org; Fri, 21 Nov 2003 12:49:15 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ANFP8-00064R-00 for nemo@ietf.org; Fri, 21 Nov 2003 12:49:14 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hALHm1X08448; Fri, 21 Nov 2003 09:48:01 -0800 X-mProtect: <200311211748> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrvqyNx; Fri, 21 Nov 2003 09:48:00 PST Message-ID: <3FBE50DE.9010101@iprg.nokia.com> Date: Fri, 21 Nov 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: James Kempf CC: Alexandru Petrescu , nemo@ietf.org Subject: Re: [nemo] Jim's comments on Basic Support References: <3FBBCCE1.6080005@iprg.nokia.com> <3FBBD360.50402@motorola.com> <0e8501c3af9a$e5ca7160$956015ac@dclkempt40> In-Reply-To: <0e8501c3af9a$e5ca7160$956015ac@dclkempt40> 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 James Kempf wrote: >>>>A Mobile Router SHOULD NOT send unsolicited Router Advertisements >>>>and SHOULD NOT reply to Router Solicitations on any egress >>>>interface when that interface is attached to a visited link. >>>>However, the Mobile Router SHOULD reply with Neighbor >>>>Advertisements to Neighbor Solicitations received on the egress >>>>interface, for topologically correct addresses. >>>> >>>>jak> What happens to hosts that are utilizing the router due to it >>>> having sent unsolicted RAs on the egress interface on the home >>>>link when the router moves away? >> >>So are you suggesting making it "MUST NOT"? >> > > > In fact, the router won't do this anyway if it is RFC 2461 compliant if the > mobile subnet is a stub subnet (as it is in the NEMO scenario), since the > mobile router will only be the first hop router for nodes within the mobile > subnet and not without ('cause the stub subnet doesn't lead to the > Internet). Jim, can you point me to the text in RFC 2461 which says a router shouldnt sent a router advertisement if it is not a first-hop router for the nodes on a link? > I'd suggest perhaps adding wording to that effect, just to > emphasize the fact. currently, the NEMO spec says that the mobile router MAY be configured to send router advertisements on its egress interface when it is attached to the home link. and if the mobile router is sending router advertisements, it should set the router lifetime to 0, so that the hosts on the home link do not configure the mobile router as a default router. is this what you are suggesting? Since the Mobile Router is not a first hop router for nodes on the home link, it SHOULD NOT send any router advertisements on its egress interface when attached to the home link. but I dont see RFC 2461 prohibiting such a thing. Vijay From nemo-admin@ietf.org Fri Nov 21 13:43:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26221 for ; Fri, 21 Nov 2003 13: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 1ANGFB-0003TP-AG; Fri, 21 Nov 2003 13: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 1ANG3j-0002rW-2v for nemo@optimus.ietf.org; Fri, 21 Nov 2003 13:31: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 NAA25820 for ; Fri, 21 Nov 2003 13:30:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANG3g-0006ff-00 for nemo@ietf.org; Fri, 21 Nov 2003 13:31:08 -0500 Received: from zcamail04.zca.compaq.com ([161.114.32.104]) by ietf-mx with esmtp (Exim 4.12) id 1ANG3f-0006fQ-00 for nemo@ietf.org; Fri, 21 Nov 2003 13:31:08 -0500 Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 33EE259D3; Fri, 21 Nov 2003 10:30:37 -0800 (PST) Received: from kitche.zk3.dec.com (kitche1.zk3.dec.com [16.140.160.161]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id EAD111CAD; Fri, 21 Nov 2003 10:30:19 -0800 (PST) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id NAA0000894399; Fri, 21 Nov 2003 13:30:32 -0500 (EST) Message-ID: <3FBE59B6.2010402@hp.com> Date: Fri, 21 Nov 2003 13:30:14 -0500 From: Brian Haley Organization: Linux Open Source Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Wilkinson Cc: nemo@ietf.org Subject: Re: [nemo] Multiple mobile network prefixes References: <46AC004B0D5292499E5C49C6597DCA480537AB@panaowl01.panasonic-owl.co.uk> In-Reply-To: <46AC004B0D5292499E5C49C6597DCA480537AB@panaowl01.panasonic-owl.co.uk> 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 During a site re-numbering you would have more than one prefix being advertised. -Brian Matthew Wilkinson wrote: > Hi > > Hopefully an easy query for you all :) > > I have been wondering about the case when a mobile network has many > prefixes. I'm happy to accept that an implementation of NEMO should be > able to handle any number of prefixes, but I'd find it useful to be able > to understand when it would actually happen that a mobile network would > have many prefixes. Would it be when the MR has more than one ingress > interface? Or in other configurations? > > Many thanks in advance. > > Regards, > Matthew > > ----------------------------------------------------------------------------- > Matthew Wilkinson > Software Engineer > Panasonic Office Workstations Ltd. > TEL: +44 (0)131 5611064 FAX: +44 (0)131 5556027 > Web: www.panasonic-owl.co.uk > ----------------------------------------------------------------------------- > > > > ******************************************************************************** > CONFIDENTIALITY NOTICE > The information contained in this Email, and any attachment is intended > for the > named recipient(s) only. It may contain confidential and / or privileged > information. If you are not the intended recipient, you must not copy, > distribute, or take any action in reliance on it. Any views expressed do > not necessarily reflect the views of the company. If you receive this > Email by > mistake, please advise the sender by using the reply facility in your Email > software, and then delete it. > ******************************************************************************** From exim@www1.ietf.org Fri Nov 21 13:43:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26238 for ; Fri, 21 Nov 2003 13:43:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGFI-0003Vh-QY for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 13:43:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALIh8AM013487 for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 13: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 1ANGFI-0003VS-Eo for nemo-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 13: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 NAA26213 for ; Fri, 21 Nov 2003 13:42:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANGFG-0006qQ-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 13:43:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANGFF-0006qN-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 13:43:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANGFB-0003TP-AG; Fri, 21 Nov 2003 13: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 1ANG3j-0002rW-2v for nemo@optimus.ietf.org; Fri, 21 Nov 2003 13:31: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 NAA25820 for ; Fri, 21 Nov 2003 13:30:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANG3g-0006ff-00 for nemo@ietf.org; Fri, 21 Nov 2003 13:31:08 -0500 Received: from zcamail04.zca.compaq.com ([161.114.32.104]) by ietf-mx with esmtp (Exim 4.12) id 1ANG3f-0006fQ-00 for nemo@ietf.org; Fri, 21 Nov 2003 13:31:08 -0500 Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 33EE259D3; Fri, 21 Nov 2003 10:30:37 -0800 (PST) Received: from kitche.zk3.dec.com (kitche1.zk3.dec.com [16.140.160.161]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id EAD111CAD; Fri, 21 Nov 2003 10:30:19 -0800 (PST) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id NAA0000894399; Fri, 21 Nov 2003 13:30:32 -0500 (EST) Message-ID: <3FBE59B6.2010402@hp.com> Date: Fri, 21 Nov 2003 13:30:14 -0500 From: Brian Haley Organization: Linux Open Source Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Wilkinson Cc: nemo@ietf.org Subject: Re: [nemo] Multiple mobile network prefixes References: <46AC004B0D5292499E5C49C6597DCA480537AB@panaowl01.panasonic-owl.co.uk> In-Reply-To: <46AC004B0D5292499E5C49C6597DCA480537AB@panaowl01.panasonic-owl.co.uk> 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 During a site re-numbering you would have more than one prefix being advertised. -Brian Matthew Wilkinson wrote: > Hi > > Hopefully an easy query for you all :) > > I have been wondering about the case when a mobile network has many > prefixes. I'm happy to accept that an implementation of NEMO should be > able to handle any number of prefixes, but I'd find it useful to be able > to understand when it would actually happen that a mobile network would > have many prefixes. Would it be when the MR has more than one ingress > interface? Or in other configurations? > > Many thanks in advance. > > Regards, > Matthew > > ----------------------------------------------------------------------------- > Matthew Wilkinson > Software Engineer > Panasonic Office Workstations Ltd. > TEL: +44 (0)131 5611064 FAX: +44 (0)131 5556027 > Web: www.panasonic-owl.co.uk > ----------------------------------------------------------------------------- > > > > ******************************************************************************** > CONFIDENTIALITY NOTICE > The information contained in this Email, and any attachment is intended > for the > named recipient(s) only. It may contain confidential and / or privileged > information. If you are not the intended recipient, you must not copy, > distribute, or take any action in reliance on it. Any views expressed do > not necessarily reflect the views of the company. If you receive this > Email by > mistake, please advise the sender by using the reply facility in your Email > software, and then delete it. > ******************************************************************************** From nemo-admin@ietf.org Fri Nov 21 15:05:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29121 for ; Fri, 21 Nov 2003 15:05: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 1ANHWY-00005K-9Q; Fri, 21 Nov 2003 15:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANHVh-0008Te-9q for nemo@optimus.ietf.org; Fri, 21 Nov 2003 15:04: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 PAA28960 for ; Fri, 21 Nov 2003 15:03:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANHVe-0007n9-00 for nemo@ietf.org; Fri, 21 Nov 2003 15:04:06 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1ANHVd-0007n0-00 for nemo@ietf.org; Fri, 21 Nov 2003 15:04:05 -0500 Received: from www.kniveton.com (localhost [127.0.0.1]) by multihop.net (8.12.10/8.12.9) with SMTP id hALK3twk069562; Fri, 21 Nov 2003 12:03:55 -0800 (PST) (envelope-from tj@kniveton.com) Received: from 192.103.17.151 (SquirrelMail authenticated user tj) by www.kniveton.com with HTTP; Fri, 21 Nov 2003 12:03:56 -0800 (PST) Message-ID: <1794.192.103.17.151.1069445036.squirrel@www.kniveton.com> In-Reply-To: <46AC004B0D5292499E5C49C6597DCA480537AB@panaowl01.panasonic-owl.co.uk> References: <46AC004B0D5292499E5C49C6597DCA480537AB@panaowl01.panasonic-owl.co.uk> Date: Fri, 21 Nov 2003 12:03:56 -0800 (PST) Subject: Re: [nemo] Multiple mobile network prefixes From: "T.J. Kniveton" To: "Matthew Wilkinson" Cc: nemo@ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal 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 Yes, it is possible for the mobile network to include multiple prefixes. Consider a couple of cases: The mobile router has multiple interfaces, each with a separate prefix (you mentioned). It advertises each prefix on its respective link. The mobile router owns multiple prefixes and advertises them on all links. The mobile router routes to other routers in the mobile network, and the prefixes are advertised on links below the mobile router. The mobile router owns one prefix that is being renumbered; both prefixes are advertised. (mentioned by B Haley) (etc) Obviously, there are many possibilities where many prefixes are present on the mobile network. There may even be a routing protocol running in the mobile network if, e.g. there is a complex topology and other routers. The MR and HA have to negotiate, or have pre-configured, a list of all the prefixes present in the mobile network, and the HA has to set up routing entries for all of them when the BU is received, as described in the basic support spec. As you mentioned, it is very implementation specific, and the basic support solution tries to be as flexible as necessary to allow multiple prefixes. Matthew Wilkinson said: > Hi > > Hopefully an easy query for you all :) > > I have been wondering about the case when a mobile network has many > prefixes. I'm happy to accept that an implementation of NEMO should be > able to handle any number of prefixes, but I'd find it useful to be able > to understand when it would actually happen that a mobile network would > have many prefixes. Would it be when the MR has more than one ingress > interface? Or in other configurations? > > Many thanks in advance. > > Regards, > Matthew > > ------------------------------------------------------------------------ > ----- > Matthew Wilkinson > Software Engineer > Panasonic Office Workstations Ltd. > TEL: +44 (0)131 5611064 FAX: +44 (0)131 5556027 > Web: www.panasonic-owl.co.uk > ------------------------------------------------------------------------ > ----- > > > > ******************************************************************************** > CONFIDENTIALITY NOTICE > The information contained in this Email, and any attachment is intended > for the > named recipient(s) only. It may contain confidential and / or privileged > information. If you are not the intended recipient, you must not copy, > distribute, or take any action in reliance on it. Any views expressed do > not necessarily reflect the views of the company. If you receive this > Email by > mistake, please advise the sender by using the reply facility in your > Email software, and then delete it. > ******************************************************************************** > > From exim@www1.ietf.org Fri Nov 21 15:05:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29138 for ; Fri, 21 Nov 2003 15:05: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 1ANHWd-00006u-OF for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 15:05:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALK57Nq000420 for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 15:05:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANHWd-00006h-Hx for nemo-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 15:05: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 PAA29062 for ; Fri, 21 Nov 2003 15:04:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANHWa-00000Q-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 15:05:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANHWa-00000M-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 15:05:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANHWY-00005K-9Q; Fri, 21 Nov 2003 15:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANHVh-0008Te-9q for nemo@optimus.ietf.org; Fri, 21 Nov 2003 15:04: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 PAA28960 for ; Fri, 21 Nov 2003 15:03:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANHVe-0007n9-00 for nemo@ietf.org; Fri, 21 Nov 2003 15:04:06 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1ANHVd-0007n0-00 for nemo@ietf.org; Fri, 21 Nov 2003 15:04:05 -0500 Received: from www.kniveton.com (localhost [127.0.0.1]) by multihop.net (8.12.10/8.12.9) with SMTP id hALK3twk069562; Fri, 21 Nov 2003 12:03:55 -0800 (PST) (envelope-from tj@kniveton.com) Received: from 192.103.17.151 (SquirrelMail authenticated user tj) by www.kniveton.com with HTTP; Fri, 21 Nov 2003 12:03:56 -0800 (PST) Message-ID: <1794.192.103.17.151.1069445036.squirrel@www.kniveton.com> In-Reply-To: <46AC004B0D5292499E5C49C6597DCA480537AB@panaowl01.panasonic-owl.co.uk> References: <46AC004B0D5292499E5C49C6597DCA480537AB@panaowl01.panasonic-owl.co.uk> Date: Fri, 21 Nov 2003 12:03:56 -0800 (PST) Subject: Re: [nemo] Multiple mobile network prefixes From: "T.J. Kniveton" To: "Matthew Wilkinson" Cc: nemo@ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal 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 Yes, it is possible for the mobile network to include multiple prefixes. Consider a couple of cases: The mobile router has multiple interfaces, each with a separate prefix (you mentioned). It advertises each prefix on its respective link. The mobile router owns multiple prefixes and advertises them on all links. The mobile router routes to other routers in the mobile network, and the prefixes are advertised on links below the mobile router. The mobile router owns one prefix that is being renumbered; both prefixes are advertised. (mentioned by B Haley) (etc) Obviously, there are many possibilities where many prefixes are present on the mobile network. There may even be a routing protocol running in the mobile network if, e.g. there is a complex topology and other routers. The MR and HA have to negotiate, or have pre-configured, a list of all the prefixes present in the mobile network, and the HA has to set up routing entries for all of them when the BU is received, as described in the basic support spec. As you mentioned, it is very implementation specific, and the basic support solution tries to be as flexible as necessary to allow multiple prefixes. Matthew Wilkinson said: > Hi > > Hopefully an easy query for you all :) > > I have been wondering about the case when a mobile network has many > prefixes. I'm happy to accept that an implementation of NEMO should be > able to handle any number of prefixes, but I'd find it useful to be able > to understand when it would actually happen that a mobile network would > have many prefixes. Would it be when the MR has more than one ingress > interface? Or in other configurations? > > Many thanks in advance. > > Regards, > Matthew > > ------------------------------------------------------------------------ > ----- > Matthew Wilkinson > Software Engineer > Panasonic Office Workstations Ltd. > TEL: +44 (0)131 5611064 FAX: +44 (0)131 5556027 > Web: www.panasonic-owl.co.uk > ------------------------------------------------------------------------ > ----- > > > > ******************************************************************************** > CONFIDENTIALITY NOTICE > The information contained in this Email, and any attachment is intended > for the > named recipient(s) only. It may contain confidential and / or privileged > information. If you are not the intended recipient, you must not copy, > distribute, or take any action in reliance on it. Any views expressed do > not necessarily reflect the views of the company. If you receive this > Email by > mistake, please advise the sender by using the reply facility in your > Email software, and then delete it. > ******************************************************************************** > > From nemo-admin@ietf.org Fri Nov 21 16:22:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03371 for ; Fri, 21 Nov 2003 16:22: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 1ANIj2-0005Vf-N9; Fri, 21 Nov 2003 16:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANIiD-0005V2-W0 for nemo@optimus.ietf.org; Fri, 21 Nov 2003 16:21: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 QAA03359 for ; Fri, 21 Nov 2003 16:20:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANIiC-000158-00 for nemo@ietf.org; Fri, 21 Nov 2003 16:21:08 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1ANIiA-000155-00 for nemo@ietf.org; Fri, 21 Nov 2003 16:21:07 -0500 Message-ID: <025901c3b075$6c4f89c0$956015ac@dclkempt40> From: "James Kempf" To: "Vijay Devarapalli" Cc: "Alexandru Petrescu" , References: <3FBBCCE1.6080005@iprg.nokia.com> <3FBBD360.50402@motorola.com> <0e8501c3af9a$e5ca7160$956015ac@dclkempt40> <3FBE50DE.9010101@iprg.nokia.com> Subject: Re: [nemo] Jim's comments on Basic Support Date: Fri, 21 Nov 2003 13:21:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Jim, can you point me to the text in RFC 2461 which says a > router shouldnt sent a router advertisement if it is not a > first-hop router for the nodes on a link? > Well, there's this (Section 6, first paragraph): "...Routers send Router Advertisements that indicate whether the sender is willing to be a default router..." But then there's this (Section 6.2.3, page 45): "A router might want to send Router Advertisements without advertising itself as a default router. For instance, a router might advertise prefixes for address autoconfiguration while not wishing to forward packets. Such a router sets the Router Lifetime field in outgoing advertisements to zero." It is unclear to me from this whether or not a router can advertise itself even if it is willing to forward packets but not act as a default router (i.e. a gateway to a wider network, usually the Internet), rather than just prefixes. Would a lifetime of zero also be valid if the router wanted to do that? Typically, routing decisions after the first hop are made by the first hop router, and the host's routing decision is restricted just to selecting the first hop router, so I would say no, but the spec doesn't specifically say that (at least, as far as I can tell). So, I'd say 2461 is not particularly clear on this issue. Perhaps an issue for the ongoing discussion in the IPv6 group about updating 2461? However, 2461 is very clear about Redirects. This from Section 8, paragraph 2: "A router MUST be able to determine the link-local address for each of its neighboring routers in order to ensure that the target address in a Redirect message identifies the neighbor router by its link-local address..." and later, under a list of items to check before accepting a Redirect: "-The IP source address of the Redirect is the same as the current first-hop router for the specified ICMP Destination Address". so even if a host can utilize the mobile router to route directly to the stub mobile subnet rather than go through the default router, a Redirect can't be used to tell the host to move its routing if the mobile router moves, and it couldn't be used by the HA in any event to do a proxy redirect. > > I'd suggest perhaps adding wording to that effect, just to > > emphasize the fact. > > currently, the NEMO spec says that the mobile router MAY be > configured to send router advertisements on its egress > interface when it is attached to the home link. and if the > mobile router is sending router advertisements, it should > set the router lifetime to 0, so that the hosts on the home > link do not configure the mobile router as a default router. > > is this what you are suggesting? That is what 2461 suggests, but it is not clear from 2461 whether a host on the home link could actually use the advertisement for routing, at least, not to me. I think the wording is OK if one believes that a router should be able to use RAs to advertise itself to hosts as something other than a default router. > > Since the Mobile Router is not a first hop router for nodes > on the home link, it SHOULD NOT send any router > advertisements on its egress interface when attached to the > home link. > > but I dont see RFC 2461 prohibiting such a thing. > You're right. But it is also not clear to me whether it should be encouraged. I think this is an issue that needs to be clarified in the revision of 2461. I don't know what to suggest for the NEMO spec at this point, but I don't believe the current wording is out of compliance with what 2461 says. jak From exim@www1.ietf.org Fri Nov 21 16:22:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03386 for ; Fri, 21 Nov 2003 16:22: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 1ANIj5-0005Wf-N6 for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 16:22:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALLM3ep021235 for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 16:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANIj5-0005WQ-H4 for nemo-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 16:22: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 QAA03366 for ; Fri, 21 Nov 2003 16:21:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANIj3-00015P-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 16:22:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANIj3-00015M-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 16:22:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANIj2-0005Vf-N9; Fri, 21 Nov 2003 16:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANIiD-0005V2-W0 for nemo@optimus.ietf.org; Fri, 21 Nov 2003 16:21: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 QAA03359 for ; Fri, 21 Nov 2003 16:20:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANIiC-000158-00 for nemo@ietf.org; Fri, 21 Nov 2003 16:21:08 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1ANIiA-000155-00 for nemo@ietf.org; Fri, 21 Nov 2003 16:21:07 -0500 Message-ID: <025901c3b075$6c4f89c0$956015ac@dclkempt40> From: "James Kempf" To: "Vijay Devarapalli" Cc: "Alexandru Petrescu" , References: <3FBBCCE1.6080005@iprg.nokia.com> <3FBBD360.50402@motorola.com> <0e8501c3af9a$e5ca7160$956015ac@dclkempt40> <3FBE50DE.9010101@iprg.nokia.com> Subject: Re: [nemo] Jim's comments on Basic Support Date: Fri, 21 Nov 2003 13:21:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Jim, can you point me to the text in RFC 2461 which says a > router shouldnt sent a router advertisement if it is not a > first-hop router for the nodes on a link? > Well, there's this (Section 6, first paragraph): "...Routers send Router Advertisements that indicate whether the sender is willing to be a default router..." But then there's this (Section 6.2.3, page 45): "A router might want to send Router Advertisements without advertising itself as a default router. For instance, a router might advertise prefixes for address autoconfiguration while not wishing to forward packets. Such a router sets the Router Lifetime field in outgoing advertisements to zero." It is unclear to me from this whether or not a router can advertise itself even if it is willing to forward packets but not act as a default router (i.e. a gateway to a wider network, usually the Internet), rather than just prefixes. Would a lifetime of zero also be valid if the router wanted to do that? Typically, routing decisions after the first hop are made by the first hop router, and the host's routing decision is restricted just to selecting the first hop router, so I would say no, but the spec doesn't specifically say that (at least, as far as I can tell). So, I'd say 2461 is not particularly clear on this issue. Perhaps an issue for the ongoing discussion in the IPv6 group about updating 2461? However, 2461 is very clear about Redirects. This from Section 8, paragraph 2: "A router MUST be able to determine the link-local address for each of its neighboring routers in order to ensure that the target address in a Redirect message identifies the neighbor router by its link-local address..." and later, under a list of items to check before accepting a Redirect: "-The IP source address of the Redirect is the same as the current first-hop router for the specified ICMP Destination Address". so even if a host can utilize the mobile router to route directly to the stub mobile subnet rather than go through the default router, a Redirect can't be used to tell the host to move its routing if the mobile router moves, and it couldn't be used by the HA in any event to do a proxy redirect. > > I'd suggest perhaps adding wording to that effect, just to > > emphasize the fact. > > currently, the NEMO spec says that the mobile router MAY be > configured to send router advertisements on its egress > interface when it is attached to the home link. and if the > mobile router is sending router advertisements, it should > set the router lifetime to 0, so that the hosts on the home > link do not configure the mobile router as a default router. > > is this what you are suggesting? That is what 2461 suggests, but it is not clear from 2461 whether a host on the home link could actually use the advertisement for routing, at least, not to me. I think the wording is OK if one believes that a router should be able to use RAs to advertise itself to hosts as something other than a default router. > > Since the Mobile Router is not a first hop router for nodes > on the home link, it SHOULD NOT send any router > advertisements on its egress interface when attached to the > home link. > > but I dont see RFC 2461 prohibiting such a thing. > You're right. But it is also not clear to me whether it should be encouraged. I think this is an issue that needs to be clarified in the revision of 2461. I don't know what to suggest for the NEMO spec at this point, but I don't believe the current wording is out of compliance with what 2461 says. jak From nemo-admin@ietf.org Fri Nov 21 16:39:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04002 for ; Fri, 21 Nov 2003 16:39: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 1ANIzU-0006Ia-Ue; Fri, 21 Nov 2003 16: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 1ANIyn-0006Fo-Dc for nemo@optimus.ietf.org; Fri, 21 Nov 2003 16:38: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 QAA03973 for ; Fri, 21 Nov 2003 16:38:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANIyl-0001HC-00 for nemo@ietf.org; Fri, 21 Nov 2003 16:38:15 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ANIyk-0001Gr-00 for nemo@ietf.org; Fri, 21 Nov 2003 16:38:14 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hALLbBr13778; Fri, 21 Nov 2003 13:37:11 -0800 X-mProtect: <200311212137> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFt3n6c; Fri, 21 Nov 2003 13:37:10 PST Message-ID: <3FBE8696.6000403@iprg.nokia.com> Date: Fri, 21 Nov 2003 13:41: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: James Kempf CC: Alexandru Petrescu , nemo@ietf.org Subject: Re: [nemo] Jim's comments on Basic Support References: <3FBBCCE1.6080005@iprg.nokia.com> <3FBBD360.50402@motorola.com> <0e8501c3af9a$e5ca7160$956015ac@dclkempt40> <3FBE50DE.9010101@iprg.nokia.com> <025901c3b075$6c4f89c0$956015ac@dclkempt40> In-Reply-To: <025901c3b075$6c4f89c0$956015ac@dclkempt40> 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 James Kempf wrote: > > I think this is an issue that needs to be clarified in the revision of 2461. > I don't know what to suggest for the NEMO spec at this point, but I don't > believe the current wording is out of compliance with what 2461 says. cool. it might be a good idea to bring this up in 2461bis discussion. Vijay From exim@www1.ietf.org Fri Nov 21 16:39:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04017 for ; Fri, 21 Nov 2003 16:39: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 1ANIzX-0006Jl-EC for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 16:39:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALLd3Fn024279 for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 16:39:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANIzX-0006JW-8S for nemo-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 16:39: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 QAA03992 for ; Fri, 21 Nov 2003 16:38:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANIzV-0001Hp-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 16:39:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANIzV-0001Hm-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 16:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANIzU-0006Ia-Ue; Fri, 21 Nov 2003 16: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 1ANIyn-0006Fo-Dc for nemo@optimus.ietf.org; Fri, 21 Nov 2003 16:38: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 QAA03973 for ; Fri, 21 Nov 2003 16:38:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANIyl-0001HC-00 for nemo@ietf.org; Fri, 21 Nov 2003 16:38:15 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ANIyk-0001Gr-00 for nemo@ietf.org; Fri, 21 Nov 2003 16:38:14 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hALLbBr13778; Fri, 21 Nov 2003 13:37:11 -0800 X-mProtect: <200311212137> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFt3n6c; Fri, 21 Nov 2003 13:37:10 PST Message-ID: <3FBE8696.6000403@iprg.nokia.com> Date: Fri, 21 Nov 2003 13:41: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: James Kempf CC: Alexandru Petrescu , nemo@ietf.org Subject: Re: [nemo] Jim's comments on Basic Support References: <3FBBCCE1.6080005@iprg.nokia.com> <3FBBD360.50402@motorola.com> <0e8501c3af9a$e5ca7160$956015ac@dclkempt40> <3FBE50DE.9010101@iprg.nokia.com> <025901c3b075$6c4f89c0$956015ac@dclkempt40> In-Reply-To: <025901c3b075$6c4f89c0$956015ac@dclkempt40> 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 James Kempf wrote: > > I think this is an issue that needs to be clarified in the revision of 2461. > I don't know what to suggest for the NEMO spec at this point, but I don't > believe the current wording is out of compliance with what 2461 says. cool. it might be a good idea to bring this up in 2461bis discussion. Vijay From nemo-admin@ietf.org Fri Nov 21 18:35:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12202 for ; Fri, 21 Nov 2003 18: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 1ANKmo-0006wr-5j; Fri, 21 Nov 2003 18: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 1ANKmH-0006w2-W2 for nemo@optimus.ietf.org; Fri, 21 Nov 2003 18:33: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 SAA12131 for ; Fri, 21 Nov 2003 18:33:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANKmE-00042n-00 for nemo@ietf.org; Fri, 21 Nov 2003 18:33:26 -0500 Received: from pop17.ucdavis.edu ([169.237.105.27]) by ietf-mx with esmtp (Exim 4.12) id 1ANKmD-00042W-00 for nemo@ietf.org; Fri, 21 Nov 2003 18:33:25 -0500 Received: from SOUHWANSENSQ (nat6-181.cs.ucdavis.edu [169.237.6.181]) by pop17.ucdavis.edu (8.12.9/8.12.9/it-std-5.2.0) with SMTP id hALNXJDL023309; Fri, 21 Nov 2003 15:33:23 -0800 (PST) Message-ID: <004201c3b087$dad0b3d0$b601a8c0@SOUHWANSENSQ> From: "Souhwan Jung" To: "Vijay Devarapalli" , Cc: References: <3FBD50BE.5090202@iprg.nokia.com> Subject: Re: [nemo] tunneling threats Date: Sat, 22 Nov 2003 08:33:15 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGkgVmlqYXksDQoNCllvdSBhcmUgcmlnaHQuIEkgbWFkZSBhIG1pc3Rha2UgaW4gZGlzdGluZ3Vp c2hpbmcgdGhlIGZvcm1hdCBvZiB0aGUgaW5jb21pbmcgcGFja2V0IGludG8gTVIgZnJvbSB0aGUg Zm9ybWF0IG9mIG91dGdvaW5nIHBhY2tldCBmcm9tIE1SLiBCdXQsIHRoZSBhdHRhY2sgc3RpbGwg d29ya3MuIFBsZWFzZSBzZWUgdGhlIGlubGluZS4NCg0KPiBzZWN0aW9uIDUuMi4xIG9mIA0KPiBo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1vYmlsZWlwLW1p cHY2LWhhLWlwc2VjLTA2LnR4dA0KPiBkZXNjcmliZXMgdGhlIFNQRCBlbnRyaWVzIG9uIHRoZSBt b2JpbGUgbm9kZS9tb2JpbGUgcm91dGVyIGZvcg0KPiBwcm90ZWN0aW5nIEJpbmRpbmcgVXBkYXRl cy4NCj4gDQo+ICAgICAgIG1vYmlsZSBub2RlIFNQRCBPVVQ6DQo+ICAgICAgICAgLSBJRiBzb3Vy Y2UgPSBob21lX2FkZHJlc3NfMSAmIGRlc3RpbmF0aW9uID0gaG9tZV9hZ2VudF8xICYNCj4gICAg ICAgICAgICAgIHByb3RvID0gTUgNCj4gICAgICAgICAgIFRIRU4gVVNFIFNBIFNBMQ0KPiANCj4g dGhlIHNvdXJjZSBhZGRyZXNzIG9uIHRoZSBJUHY2IGhlYWRlciBpcyBub3QgdGhlIGhvbWUgYWRk cmVzcw0KPiBvZiB0aGUgTVIgd2hlbiB0aGUgTVIgYXR0ZW1wdHMgdG8gZm9yd2FyZCB0aGUgcGFj a2V0IHJlY2VpdmVkDQo+IGZyb20gdGhlIE1OTi4gc28gdGhlIFNBIGZvciBwcm90ZWN0aW5nIHRo ZSBCVSBiZXR3ZWVuIE1SIGFuZCBIQQ0KPiB3aWxsIGJlIG5vdCBiZSBzZWxlY3RlZCBmb3IgcHJv dGVjdGluZyB0aGUgcGFja2V0LiBpbmZhY3QgdGhlcmUNCj4gd29udCBiZSBhbnkgU1BEIGVudHJ5 IGZvciBzb3VyY2U9TVJfQ29BLCBkc3Q9SEEsIHByb3RvY29sPW1vYmlsaXR5Lg0KPiBzbyB0aGUg QlUgaXMgZm9yd2FyZGVkIHVucHJvdGVjdGVkLiB0aGUgSG9tZSBBZ2VudCBkcm9wcw0KPiB1bnBy b3RlY3RlZCBiaW5kaW5nIHVwZGF0ZXMuDQo+IA0KDQpJbiBmYWN0LCB0aGUgcGFja2V0IGZyb20g YXR0YWNrZXIgc2hvdWxkIGhhcyBhIHNyYz1Ib0Egb2YgTVIsIGFuZCBkc3Q9SEEuIA0KVGhlbiB0 aGUgcGFja2V0IGlzIG1hdGNoZWQgYWdhaW5zdCB0aGUgSVBzZWMgU1BEIE9VVCwgYW5kIE1SIHdp bGwgYXBwbHkgSVBzZWMuDQpGaW5hbGx5LCBNUiB3aWxsIGdlbmVyYXRlIHRoZSBwYWNrZXQgb2Yg c3JjPUNvQSwgZHN0PUhBLCBhbmQgaG9tZSBhZGRyZXNzIG9wdGlvbj1Ib0EuIFBsZWFzZSBzZWUg dGhlIHNlY3Rpb24gNi4xIG9mIHRoZSBzYW1lIGRyYWZ0IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbW9iaWxlaXAtbWlwdjYtaGEtaXBzZWMtMDYudHh0Lg0K DQo+IGFuZCB0aGVuIG9mIGNvdXJzZSB0aGVyZSBpcyBpbmdyZXNzIGZpbHRlcmluZy4gaWYgdGhl IE1SIGRvZXMgaW5ncmVzcw0KPiBmaWx0ZXJpbmcsIGl0IHNob3VsZCBkcm9wIHRoZSBwYWNrZXQg d2hlbiBpdCByZWFsaXNlcyB0aGF0IGFuIE1OTiBpcw0KPiBzZW5kaW5nIHRoZSBwYWNrZXQgd2l0 aCBNUidzIENvQSBhcyB0aGUgc291cmNlIGFkZHJlc3MuDQoNCkkgYWxyZWFkeSBwb2ludGVkIG91 dCB0aGlzIGluIHRoZSBzbGlkZS4NCg0KPiANCj4gdGhyZWF0IDIsIHNsaWRlIDQNCj4gLS0tLS0t LS0tLS0tLS0tLS0NCj4gDQo+IGluIHRoaXMgc2NlbmFyaW8sIHRoZSBNTk4gc2VuZHMgYSBCaW5k aW5nIFVwZGF0ZSB1c2luZyBJUC1pbi1JUA0KPiB0dW5uZWxpbmcuDQo+IA0KPiBvbmNlIHRoZSBw YWNrZXQgaXMgZGVjYXBzdWxhdGVkIGF0IHRoZSBNUiwgaXQgbG9va3MgZXhhY3RseSBsaWtlDQo+ IHRoZSBwYWNrZXQgaW4gdGhyZWF0IDEuIHRoZXJlIGlzIG5vIHByb2JsZW0gYWdhaW4sIGJlY2F1 c2UgdGhlcmUNCj4gaXMgbm8gY29ycmVzcG9uZGluZyBTUEQgZW50cnkuDQoNClRoZSBwYWNrZXQg ZnJvbSBhdHRhY2tlciBzaG91bGQgaW5jbHVkZSBpbm5lciBzcmM9SG9BIG9mIE1SLg0KVGhlbiB0 aGUgcmVzdCBwYXJ0IG9mIHRoZSBhdHRhY2sgc2NlbmFyaW8gd29ya3MgdGhlIHNhbWUgYXMgdGhl IHRocmVhdCAxLg0KDQoNCj4gDQo+IGFuZCB0aGVuIHRoZXJlIGlzIGFub3RoZXIgY2hlY2sgdGhh dCB0aGUgTW9iaWxlIFJvdXRlciBjYW4gcGVyZm9ybS4NCj4gd2hlbmV2ZXIgaXQgZGVjYXBzdWxh dGVzIGEgcGFja2V0IGFuZCBmb3J3YXJkcyB0aGUgaW5uZXIgcGFja2V0LA0KPiBpdCAqbXVzdCog dmVyaWZ5IGlmIHRoZSBzb3VyY2UgYWRkcmVzcyBvbiB0aGUgaW5uZXIgaGVhZGVyIGlzIHZhbGlk Lg0KPiB0aGUgZGVjYXBzdWxhdGVkIHBhY2tldCB3aWxsIGZhaWwgdGhpcyBjaGVjayBiZWNhdXNl IHRoZSBzb3VyY2UNCj4gYWRkcmVzcyBvbiB0aGUgaW5uZXIgaGVhZGVyIGlzIHRoZSBDb0Egb2Yg dGhlIE1SLiBzdWNoIGNoZWNrcyB3ZXJlDQo+IGRvbmUgdG9kYXkgd2hlbiB5b3UgZGVjYXBzdWxh dGUgYSBwYWNrZXQgYW5kIGZvcndhcmQgdGhlIGlubmVyDQo+IHBhY2tldC4NCg0KSSBhbHNvIHBv aW50ZWQgb3V0IHRoaXMgaW4gdGhlIHNsaWRlLiBUaGlzIHNob3VsZCBiZSB0aGUgcmlnaHQgd2F5 IG9mIGltcGxlbWVudGF0aW9uLCBhbmQgd2Ugd2FudGVkIHRvIHBvaW50IG91dCB0aGF0IHRoZSBy aWdodCBvcmRlciBvZiBkZWNhcHN1bGF0aW9uLWFuZC10aGVuLWluZ3Jlc3MgZmlsdGVyaW5nIGlz IGltcG9ydGFudCB0byBwcmV2ZW50IHRoaXMgdHlwZSBvZiBhdHRhY2suIFRoZSBpbXBsZW1lbnRh dGlvbiBvZiByZXZlcnNlZCBvcmRlciB3aWxsIGNhdXNlIHRoZSBwcm9ibGVtLg0KDQo+IHRocmVh dCAzLCBzbGlkZSA2DQo+IC0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBpbiB0aGlzIHNjZW5hcmlv LCBNTk4gZ2VuZXJhdGVzIGFuIElQIHBhY2tldCB3aXRoIHRoZSBzb3VyY2UNCj4gYWRkcmVzcyBz ZXQgdG8gYSBzcG9vZmVkIElQIGFkZHJlc3MsIHdoaWNoIGRvZXMgbm90IGJlbG9uZw0KPiB0byB0 aGUgTW9iaWxlIE5ldHdvcmsuDQo+IA0KPiBzZWN0aW9uIDggb2YgdGhlIEJhc2ljIFN1cHBvcnQg ZHJhZnQgc2F5cw0KPiANCj4gPiAgICBUaGUgSG9tZSBBZ2VudCBoYXMgdG8gdmVyaWZ5IHRoYXQg cGFja2V0cyByZWNlaXZlZCB0aHJvdWdoIHRoZQ0KPiA+ICAgIGJpLWRpcmVjdGlvbmFsIHR1bm5l bCBiZWxvbmcgdG8gdGhlIE1vYmlsZSBOZXR3b3JrLiAgVGhpcyBjaGVjayBpcw0KPiA+ICAgIG5l Y2Vzc2FyeSBpbiBvcmRlciB0byBwcmV2ZW50IG5vZGVzIGZyb20gdXNpbmcgdGhlIEhvbWUgQWdl bnQgdG8NCj4gPiAgICBsYXVuY2ggYXR0YWNrcyB0aGF0IHdvdWxkIGhhdmUgb3RoZXJ3aXNlIGJl ZW4gcHJldmVudGVkIGJ5IGluZ3Jlc3MNCj4gPiAgICBmaWx0ZXJpbmcuICBUaGUgc291cmNlIGFk ZHJlc3Mgb2YgdGhlIG91dGVyIElQdjYgaGVhZGVyIE1VU1QgYmUgc2V0DQo+ID4gICAgdG8gdGhl IE1vYmlsZSBSb3V0ZXIncyBjdXJyZW50IENhcmUtb2YgYWRkcmVzcy4gIFRoZSBzb3VyY2UgYWRk cmVzcw0KPiA+ICAgIG9mIHRoZSBpbm5lciBJUHY2IGhlYWRlciBNVVNUIGJlbG9uZyB0byB0aGUg TW9iaWxlIE5ldHdvcmsgUHJlZml4DQo+ID4gICAgb3duZWQgYnkgdGhlIE1vYmlsZSBSb3V0ZXIu DQo+IA0KPiB0aGlzIGNoZWNrIGF0IHRoZSBIQSBzaG91bGQgcHJldmVudCB0aGlzIHRocmVhdC4g YWxzbyBpZiB0aGUNCj4gTVIgcGVyZm9ybXMgaW5ncmVzcyBmaWx0ZXJpbmcsIHRoZSBwYWNrZXQg d2lsbCBnZXQgZHJvcHBlZA0KPiBhdCB0aGUgTVIgaXRzZWxmLg0KPiANCg0KSSBkb24ndCBiZWxp ZXZlIHRoZSBjaGVjayBhdCBIQSB3aWxsIHByZXZlbnQgdGhpcyBhdHRhY2suIFRoZSBzcG9vZmVk IElQIGFkZHJlc3MgY291bGQgYmUgb3V0IG9mIHRoZSBzYW1lIE1OUCBvd25lZCBieSBNUi4gVGhl biBpdCB3aWxsIGdldCB0aHJvdWdoIHRoZSBpbmdyZXNzIGZpbHRlcmluZyBhdCBNUi4gVGhlIGNo ZWNrIGF0IEhBIGFsc28gY2Fubm90IGZpbHRlciB0aGUgYXR0YWNrIHBhY2tldHMgYmVjYXVzZSB0 aGUgb3V0ZXIgYW5kIGlubmVyIHNyYyBhZGRyZXNzZXMgZXhhY3RseSBtYXRjaGUgdGhlIGNoZWNr IGNvbmRpdGlvbnMuIChvdXRlciBzcmM9Q29BIG9mIE1SLCBpbm5lciBzcmMgPSBvbmUgb2YgTU5Q IG93bmVkIGJ5IE1SKQ0KDQoNCkNvbW1lbnRzPw0KVGhhbmtzLg0KDQpTb3Vod2FuDQog From exim@www1.ietf.org Fri Nov 21 18:35:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12204 for ; Fri, 21 Nov 2003 18: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 1ANKmr-00070y-Tj for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 18:34:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALNY55c026958 for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 18: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 1ANKmr-00070j-Ji for nemo-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 18:34: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 SAA12158 for ; Fri, 21 Nov 2003 18:33:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANKmo-000436-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 18:34:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANKmo-000433-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 18:34:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANKmo-0006wr-5j; Fri, 21 Nov 2003 18: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 1ANKmH-0006w2-W2 for nemo@optimus.ietf.org; Fri, 21 Nov 2003 18:33: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 SAA12131 for ; Fri, 21 Nov 2003 18:33:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANKmE-00042n-00 for nemo@ietf.org; Fri, 21 Nov 2003 18:33:26 -0500 Received: from pop17.ucdavis.edu ([169.237.105.27]) by ietf-mx with esmtp (Exim 4.12) id 1ANKmD-00042W-00 for nemo@ietf.org; Fri, 21 Nov 2003 18:33:25 -0500 Received: from SOUHWANSENSQ (nat6-181.cs.ucdavis.edu [169.237.6.181]) by pop17.ucdavis.edu (8.12.9/8.12.9/it-std-5.2.0) with SMTP id hALNXJDL023309; Fri, 21 Nov 2003 15:33:23 -0800 (PST) Message-ID: <004201c3b087$dad0b3d0$b601a8c0@SOUHWANSENSQ> From: "Souhwan Jung" To: "Vijay Devarapalli" , Cc: References: <3FBD50BE.5090202@iprg.nokia.com> Subject: Re: [nemo] tunneling threats Date: Sat, 22 Nov 2003 08:33:15 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgVmlqYXksDQoNCllvdSBhcmUgcmlnaHQuIEkgbWFkZSBhIG1pc3Rha2UgaW4gZGlzdGluZ3Vp c2hpbmcgdGhlIGZvcm1hdCBvZiB0aGUgaW5jb21pbmcgcGFja2V0IGludG8gTVIgZnJvbSB0aGUg Zm9ybWF0IG9mIG91dGdvaW5nIHBhY2tldCBmcm9tIE1SLiBCdXQsIHRoZSBhdHRhY2sgc3RpbGwg d29ya3MuIFBsZWFzZSBzZWUgdGhlIGlubGluZS4NCg0KPiBzZWN0aW9uIDUuMi4xIG9mIA0KPiBo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1vYmlsZWlwLW1p cHY2LWhhLWlwc2VjLTA2LnR4dA0KPiBkZXNjcmliZXMgdGhlIFNQRCBlbnRyaWVzIG9uIHRoZSBt b2JpbGUgbm9kZS9tb2JpbGUgcm91dGVyIGZvcg0KPiBwcm90ZWN0aW5nIEJpbmRpbmcgVXBkYXRl cy4NCj4gDQo+ICAgICAgIG1vYmlsZSBub2RlIFNQRCBPVVQ6DQo+ICAgICAgICAgLSBJRiBzb3Vy Y2UgPSBob21lX2FkZHJlc3NfMSAmIGRlc3RpbmF0aW9uID0gaG9tZV9hZ2VudF8xICYNCj4gICAg ICAgICAgICAgIHByb3RvID0gTUgNCj4gICAgICAgICAgIFRIRU4gVVNFIFNBIFNBMQ0KPiANCj4g dGhlIHNvdXJjZSBhZGRyZXNzIG9uIHRoZSBJUHY2IGhlYWRlciBpcyBub3QgdGhlIGhvbWUgYWRk cmVzcw0KPiBvZiB0aGUgTVIgd2hlbiB0aGUgTVIgYXR0ZW1wdHMgdG8gZm9yd2FyZCB0aGUgcGFj a2V0IHJlY2VpdmVkDQo+IGZyb20gdGhlIE1OTi4gc28gdGhlIFNBIGZvciBwcm90ZWN0aW5nIHRo ZSBCVSBiZXR3ZWVuIE1SIGFuZCBIQQ0KPiB3aWxsIGJlIG5vdCBiZSBzZWxlY3RlZCBmb3IgcHJv dGVjdGluZyB0aGUgcGFja2V0LiBpbmZhY3QgdGhlcmUNCj4gd29udCBiZSBhbnkgU1BEIGVudHJ5 IGZvciBzb3VyY2U9TVJfQ29BLCBkc3Q9SEEsIHByb3RvY29sPW1vYmlsaXR5Lg0KPiBzbyB0aGUg QlUgaXMgZm9yd2FyZGVkIHVucHJvdGVjdGVkLiB0aGUgSG9tZSBBZ2VudCBkcm9wcw0KPiB1bnBy b3RlY3RlZCBiaW5kaW5nIHVwZGF0ZXMuDQo+IA0KDQpJbiBmYWN0LCB0aGUgcGFja2V0IGZyb20g YXR0YWNrZXIgc2hvdWxkIGhhcyBhIHNyYz1Ib0Egb2YgTVIsIGFuZCBkc3Q9SEEuIA0KVGhlbiB0 aGUgcGFja2V0IGlzIG1hdGNoZWQgYWdhaW5zdCB0aGUgSVBzZWMgU1BEIE9VVCwgYW5kIE1SIHdp bGwgYXBwbHkgSVBzZWMuDQpGaW5hbGx5LCBNUiB3aWxsIGdlbmVyYXRlIHRoZSBwYWNrZXQgb2Yg c3JjPUNvQSwgZHN0PUhBLCBhbmQgaG9tZSBhZGRyZXNzIG9wdGlvbj1Ib0EuIFBsZWFzZSBzZWUg dGhlIHNlY3Rpb24gNi4xIG9mIHRoZSBzYW1lIGRyYWZ0IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbW9iaWxlaXAtbWlwdjYtaGEtaXBzZWMtMDYudHh0Lg0K DQo+IGFuZCB0aGVuIG9mIGNvdXJzZSB0aGVyZSBpcyBpbmdyZXNzIGZpbHRlcmluZy4gaWYgdGhl IE1SIGRvZXMgaW5ncmVzcw0KPiBmaWx0ZXJpbmcsIGl0IHNob3VsZCBkcm9wIHRoZSBwYWNrZXQg d2hlbiBpdCByZWFsaXNlcyB0aGF0IGFuIE1OTiBpcw0KPiBzZW5kaW5nIHRoZSBwYWNrZXQgd2l0 aCBNUidzIENvQSBhcyB0aGUgc291cmNlIGFkZHJlc3MuDQoNCkkgYWxyZWFkeSBwb2ludGVkIG91 dCB0aGlzIGluIHRoZSBzbGlkZS4NCg0KPiANCj4gdGhyZWF0IDIsIHNsaWRlIDQNCj4gLS0tLS0t LS0tLS0tLS0tLS0NCj4gDQo+IGluIHRoaXMgc2NlbmFyaW8sIHRoZSBNTk4gc2VuZHMgYSBCaW5k aW5nIFVwZGF0ZSB1c2luZyBJUC1pbi1JUA0KPiB0dW5uZWxpbmcuDQo+IA0KPiBvbmNlIHRoZSBw YWNrZXQgaXMgZGVjYXBzdWxhdGVkIGF0IHRoZSBNUiwgaXQgbG9va3MgZXhhY3RseSBsaWtlDQo+ IHRoZSBwYWNrZXQgaW4gdGhyZWF0IDEuIHRoZXJlIGlzIG5vIHByb2JsZW0gYWdhaW4sIGJlY2F1 c2UgdGhlcmUNCj4gaXMgbm8gY29ycmVzcG9uZGluZyBTUEQgZW50cnkuDQoNClRoZSBwYWNrZXQg ZnJvbSBhdHRhY2tlciBzaG91bGQgaW5jbHVkZSBpbm5lciBzcmM9SG9BIG9mIE1SLg0KVGhlbiB0 aGUgcmVzdCBwYXJ0IG9mIHRoZSBhdHRhY2sgc2NlbmFyaW8gd29ya3MgdGhlIHNhbWUgYXMgdGhl IHRocmVhdCAxLg0KDQoNCj4gDQo+IGFuZCB0aGVuIHRoZXJlIGlzIGFub3RoZXIgY2hlY2sgdGhh dCB0aGUgTW9iaWxlIFJvdXRlciBjYW4gcGVyZm9ybS4NCj4gd2hlbmV2ZXIgaXQgZGVjYXBzdWxh dGVzIGEgcGFja2V0IGFuZCBmb3J3YXJkcyB0aGUgaW5uZXIgcGFja2V0LA0KPiBpdCAqbXVzdCog dmVyaWZ5IGlmIHRoZSBzb3VyY2UgYWRkcmVzcyBvbiB0aGUgaW5uZXIgaGVhZGVyIGlzIHZhbGlk Lg0KPiB0aGUgZGVjYXBzdWxhdGVkIHBhY2tldCB3aWxsIGZhaWwgdGhpcyBjaGVjayBiZWNhdXNl IHRoZSBzb3VyY2UNCj4gYWRkcmVzcyBvbiB0aGUgaW5uZXIgaGVhZGVyIGlzIHRoZSBDb0Egb2Yg dGhlIE1SLiBzdWNoIGNoZWNrcyB3ZXJlDQo+IGRvbmUgdG9kYXkgd2hlbiB5b3UgZGVjYXBzdWxh dGUgYSBwYWNrZXQgYW5kIGZvcndhcmQgdGhlIGlubmVyDQo+IHBhY2tldC4NCg0KSSBhbHNvIHBv aW50ZWQgb3V0IHRoaXMgaW4gdGhlIHNsaWRlLiBUaGlzIHNob3VsZCBiZSB0aGUgcmlnaHQgd2F5 IG9mIGltcGxlbWVudGF0aW9uLCBhbmQgd2Ugd2FudGVkIHRvIHBvaW50IG91dCB0aGF0IHRoZSBy aWdodCBvcmRlciBvZiBkZWNhcHN1bGF0aW9uLWFuZC10aGVuLWluZ3Jlc3MgZmlsdGVyaW5nIGlz IGltcG9ydGFudCB0byBwcmV2ZW50IHRoaXMgdHlwZSBvZiBhdHRhY2suIFRoZSBpbXBsZW1lbnRh dGlvbiBvZiByZXZlcnNlZCBvcmRlciB3aWxsIGNhdXNlIHRoZSBwcm9ibGVtLg0KDQo+IHRocmVh dCAzLCBzbGlkZSA2DQo+IC0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBpbiB0aGlzIHNjZW5hcmlv LCBNTk4gZ2VuZXJhdGVzIGFuIElQIHBhY2tldCB3aXRoIHRoZSBzb3VyY2UNCj4gYWRkcmVzcyBz ZXQgdG8gYSBzcG9vZmVkIElQIGFkZHJlc3MsIHdoaWNoIGRvZXMgbm90IGJlbG9uZw0KPiB0byB0 aGUgTW9iaWxlIE5ldHdvcmsuDQo+IA0KPiBzZWN0aW9uIDggb2YgdGhlIEJhc2ljIFN1cHBvcnQg ZHJhZnQgc2F5cw0KPiANCj4gPiAgICBUaGUgSG9tZSBBZ2VudCBoYXMgdG8gdmVyaWZ5IHRoYXQg cGFja2V0cyByZWNlaXZlZCB0aHJvdWdoIHRoZQ0KPiA+ICAgIGJpLWRpcmVjdGlvbmFsIHR1bm5l bCBiZWxvbmcgdG8gdGhlIE1vYmlsZSBOZXR3b3JrLiAgVGhpcyBjaGVjayBpcw0KPiA+ICAgIG5l Y2Vzc2FyeSBpbiBvcmRlciB0byBwcmV2ZW50IG5vZGVzIGZyb20gdXNpbmcgdGhlIEhvbWUgQWdl bnQgdG8NCj4gPiAgICBsYXVuY2ggYXR0YWNrcyB0aGF0IHdvdWxkIGhhdmUgb3RoZXJ3aXNlIGJl ZW4gcHJldmVudGVkIGJ5IGluZ3Jlc3MNCj4gPiAgICBmaWx0ZXJpbmcuICBUaGUgc291cmNlIGFk ZHJlc3Mgb2YgdGhlIG91dGVyIElQdjYgaGVhZGVyIE1VU1QgYmUgc2V0DQo+ID4gICAgdG8gdGhl IE1vYmlsZSBSb3V0ZXIncyBjdXJyZW50IENhcmUtb2YgYWRkcmVzcy4gIFRoZSBzb3VyY2UgYWRk cmVzcw0KPiA+ICAgIG9mIHRoZSBpbm5lciBJUHY2IGhlYWRlciBNVVNUIGJlbG9uZyB0byB0aGUg TW9iaWxlIE5ldHdvcmsgUHJlZml4DQo+ID4gICAgb3duZWQgYnkgdGhlIE1vYmlsZSBSb3V0ZXIu DQo+IA0KPiB0aGlzIGNoZWNrIGF0IHRoZSBIQSBzaG91bGQgcHJldmVudCB0aGlzIHRocmVhdC4g YWxzbyBpZiB0aGUNCj4gTVIgcGVyZm9ybXMgaW5ncmVzcyBmaWx0ZXJpbmcsIHRoZSBwYWNrZXQg d2lsbCBnZXQgZHJvcHBlZA0KPiBhdCB0aGUgTVIgaXRzZWxmLg0KPiANCg0KSSBkb24ndCBiZWxp ZXZlIHRoZSBjaGVjayBhdCBIQSB3aWxsIHByZXZlbnQgdGhpcyBhdHRhY2suIFRoZSBzcG9vZmVk IElQIGFkZHJlc3MgY291bGQgYmUgb3V0IG9mIHRoZSBzYW1lIE1OUCBvd25lZCBieSBNUi4gVGhl biBpdCB3aWxsIGdldCB0aHJvdWdoIHRoZSBpbmdyZXNzIGZpbHRlcmluZyBhdCBNUi4gVGhlIGNo ZWNrIGF0IEhBIGFsc28gY2Fubm90IGZpbHRlciB0aGUgYXR0YWNrIHBhY2tldHMgYmVjYXVzZSB0 aGUgb3V0ZXIgYW5kIGlubmVyIHNyYyBhZGRyZXNzZXMgZXhhY3RseSBtYXRjaGUgdGhlIGNoZWNr IGNvbmRpdGlvbnMuIChvdXRlciBzcmM9Q29BIG9mIE1SLCBpbm5lciBzcmMgPSBvbmUgb2YgTU5Q IG93bmVkIGJ5IE1SKQ0KDQoNCkNvbW1lbnRzPw0KVGhhbmtzLg0KDQpTb3Vod2FuDQog From nemo-admin@ietf.org Fri Nov 21 19:01:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12983 for ; Fri, 21 Nov 2003 19: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 1ANLCv-0000Iv-Dh; Fri, 21 Nov 2003 19: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 1ANLCR-0000IH-VQ for nemo@optimus.ietf.org; Fri, 21 Nov 2003 19:00: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 TAA12941 for ; Fri, 21 Nov 2003 19:00:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANLCL-0004MX-00 for nemo@ietf.org; Fri, 21 Nov 2003 19:00:25 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ANLCL-0004Lx-00 for nemo@ietf.org; Fri, 21 Nov 2003 19:00:25 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hALNxLe19908; Fri, 21 Nov 2003 15:59:21 -0800 X-mProtect: <200311212359> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdceZaAW; Fri, 21 Nov 2003 15:59:19 PST Message-ID: <3FBEA7E8.2030703@iprg.nokia.com> Date: Fri, 21 Nov 2003 16:03:52 -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 CC: nemo@ietf.org Subject: Re: [nemo] tunneling threats References: <3FBD50BE.5090202@iprg.nokia.com> <004201c3b087$dad0b3d0$b601a8c0@SOUHWANSENSQ> In-Reply-To: <004201c3b087$dad0b3d0$b601a8c0@SOUHWANSENSQ> 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 Souhwan Jung wrote: > Hi Vijay, > > You are right. I made a mistake in distinguishing the format of the > incoming packet into MR from the format of outgoing packet from MR. > But, the attack still works. Please see the inline. > > >>section 5.2.1 of >>http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-06.txt >>describes the SPD entries on the mobile node/mobile router for >>protecting Binding Updates. >> >> mobile node SPD OUT: >> - IF source = home_address_1 & destination = home_agent_1 & >> proto = MH >> THEN USE SA SA1 >> >>the source address on the IPv6 header is not the home address >>of the MR when the MR attempts to forward the packet received >>from the MNN. so the SA for protecting the BU between MR and HA >>will be not be selected for protecting the packet. infact there >>wont be any SPD entry for source=MR_CoA, dst=HA, protocol=mobility. >>so the BU is forwarded unprotected. the Home Agent drops >>unprotected binding updates. >> > > In fact, the packet from attacker should has a src=HoA of MR, and dst=HA. > Then the packet is matched against the IPsec SPD OUT, and MR will apply IPsec. > Finally, MR will generate the packet of src=CoA, dst=HA, and home address option=HoA. Please see the section 6.1 of the same draft http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-06.txt. right. >>and then of course there is ingress filtering. if the MR does ingress >>filtering, it should drop the packet when it realises that an MNN is >>sending the packet with MR's CoA as the source address. > > > I already pointed out this in the slide. right. ingress filtering at the MR is the only solution to this. infact the MR should make sure that the MNN is not using MR's HoA to send any packet. I will add some text to the Security Considerations section. >>threat 2, slide 4 >>----------------- >> >>in this scenario, the MNN sends a Binding Update using IP-in-IP >>tunneling. >> >>once the packet is decapsulated at the MR, it looks exactly like >>the packet in threat 1. there is no problem again, because there >>is no corresponding SPD entry. > > > The packet from attacker should include inner src=HoA of MR. > Then the rest part of the attack scenario works the same as the threat 1. > > > >>and then there is another check that the Mobile Router can perform. >>whenever it decapsulates a packet and forwards the inner packet, >>it *must* verify if the source address on the inner header is valid. >>the decapsulated packet will fail this check because the source >>address on the inner header is the CoA of the MR. such checks were >>done today when you decapsulate a packet and forward the inner >>packet. > > > I also pointed out this in the slide. This should be the right > way of implementation, and we wanted to point out that the right > order of decapsulation-and-then-ingress filtering is important to > prevent this type of attack. The implementation of reversed order > will cause the problem. okay. I will add some text warning against this threat. > > >>threat 3, slide 6 >>----------------- >> >>in this scenario, MNN generates an IP packet with the source >>address set to a spoofed IP address, which does not belong >>to the Mobile Network. >> >>section 8 of the Basic Support draft says >> >> >>> 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. >> >>this check at the HA should prevent this threat. also if the >>MR performs ingress filtering, the packet will get dropped >>at the MR itself. >> > > > I don't believe the check at HA will prevent this attack. The spoofed > IP address could be out of the same MNP owned by MR. if the address is from the MNP and the MNN is inside the Mobile Network, why would you call the address a spoofed address? it is a valid address as far as ingress filtering is concerned. also it is a topologically correct address with respect to the prefix being advertised in the Mobile Network. > Then it will get > through the ingress filtering at MR. The check at HA also cannot > filter the attack packets because the outer and inner src addresses > exactly matche the check conditions. (outer src=CoA of MR, inner src = > one of MNP owned by MR) so how this threat differnt from the current situation on the internet. I can launch DoS attacks today from a fixed ethernet. my default router does not have to be a mobile router. NEMO does not introduce this threat, right? Vijay From exim@www1.ietf.org Fri Nov 21 19:01:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12998 for ; Fri, 21 Nov 2003 19: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 1ANLCy-0000Js-9m for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 19:01:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAM014hp001228 for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 19: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 1ANLCy-0000Jj-3c for nemo-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 19: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 TAA12971 for ; Fri, 21 Nov 2003 19:00:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANLCu-0004Mo-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 19:01:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANLCu-0004Ml-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 19:01:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANLCv-0000Iv-Dh; Fri, 21 Nov 2003 19: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 1ANLCR-0000IH-VQ for nemo@optimus.ietf.org; Fri, 21 Nov 2003 19:00: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 TAA12941 for ; Fri, 21 Nov 2003 19:00:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANLCL-0004MX-00 for nemo@ietf.org; Fri, 21 Nov 2003 19:00:25 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ANLCL-0004Lx-00 for nemo@ietf.org; Fri, 21 Nov 2003 19:00:25 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hALNxLe19908; Fri, 21 Nov 2003 15:59:21 -0800 X-mProtect: <200311212359> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdceZaAW; Fri, 21 Nov 2003 15:59:19 PST Message-ID: <3FBEA7E8.2030703@iprg.nokia.com> Date: Fri, 21 Nov 2003 16:03:52 -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 CC: nemo@ietf.org Subject: Re: [nemo] tunneling threats References: <3FBD50BE.5090202@iprg.nokia.com> <004201c3b087$dad0b3d0$b601a8c0@SOUHWANSENSQ> In-Reply-To: <004201c3b087$dad0b3d0$b601a8c0@SOUHWANSENSQ> 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 Souhwan Jung wrote: > Hi Vijay, > > You are right. I made a mistake in distinguishing the format of the > incoming packet into MR from the format of outgoing packet from MR. > But, the attack still works. Please see the inline. > > >>section 5.2.1 of >>http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-06.txt >>describes the SPD entries on the mobile node/mobile router for >>protecting Binding Updates. >> >> mobile node SPD OUT: >> - IF source = home_address_1 & destination = home_agent_1 & >> proto = MH >> THEN USE SA SA1 >> >>the source address on the IPv6 header is not the home address >>of the MR when the MR attempts to forward the packet received >>from the MNN. so the SA for protecting the BU between MR and HA >>will be not be selected for protecting the packet. infact there >>wont be any SPD entry for source=MR_CoA, dst=HA, protocol=mobility. >>so the BU is forwarded unprotected. the Home Agent drops >>unprotected binding updates. >> > > In fact, the packet from attacker should has a src=HoA of MR, and dst=HA. > Then the packet is matched against the IPsec SPD OUT, and MR will apply IPsec. > Finally, MR will generate the packet of src=CoA, dst=HA, and home address option=HoA. Please see the section 6.1 of the same draft http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-06.txt. right. >>and then of course there is ingress filtering. if the MR does ingress >>filtering, it should drop the packet when it realises that an MNN is >>sending the packet with MR's CoA as the source address. > > > I already pointed out this in the slide. right. ingress filtering at the MR is the only solution to this. infact the MR should make sure that the MNN is not using MR's HoA to send any packet. I will add some text to the Security Considerations section. >>threat 2, slide 4 >>----------------- >> >>in this scenario, the MNN sends a Binding Update using IP-in-IP >>tunneling. >> >>once the packet is decapsulated at the MR, it looks exactly like >>the packet in threat 1. there is no problem again, because there >>is no corresponding SPD entry. > > > The packet from attacker should include inner src=HoA of MR. > Then the rest part of the attack scenario works the same as the threat 1. > > > >>and then there is another check that the Mobile Router can perform. >>whenever it decapsulates a packet and forwards the inner packet, >>it *must* verify if the source address on the inner header is valid. >>the decapsulated packet will fail this check because the source >>address on the inner header is the CoA of the MR. such checks were >>done today when you decapsulate a packet and forward the inner >>packet. > > > I also pointed out this in the slide. This should be the right > way of implementation, and we wanted to point out that the right > order of decapsulation-and-then-ingress filtering is important to > prevent this type of attack. The implementation of reversed order > will cause the problem. okay. I will add some text warning against this threat. > > >>threat 3, slide 6 >>----------------- >> >>in this scenario, MNN generates an IP packet with the source >>address set to a spoofed IP address, which does not belong >>to the Mobile Network. >> >>section 8 of the Basic Support draft says >> >> >>> 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. >> >>this check at the HA should prevent this threat. also if the >>MR performs ingress filtering, the packet will get dropped >>at the MR itself. >> > > > I don't believe the check at HA will prevent this attack. The spoofed > IP address could be out of the same MNP owned by MR. if the address is from the MNP and the MNN is inside the Mobile Network, why would you call the address a spoofed address? it is a valid address as far as ingress filtering is concerned. also it is a topologically correct address with respect to the prefix being advertised in the Mobile Network. > Then it will get > through the ingress filtering at MR. The check at HA also cannot > filter the attack packets because the outer and inner src addresses > exactly matche the check conditions. (outer src=CoA of MR, inner src = > one of MNP owned by MR) so how this threat differnt from the current situation on the internet. I can launch DoS attacks today from a fixed ethernet. my default router does not have to be a mobile router. NEMO does not introduce this threat, right? Vijay From nemo-admin@ietf.org Fri Nov 21 19:55:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14280 for ; Fri, 21 Nov 2003 19:55: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 1ANM3B-0003hR-UX; Fri, 21 Nov 2003 19:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANM2U-0003gr-77 for nemo@optimus.ietf.org; Fri, 21 Nov 2003 19:54: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 TAA14263 for ; Fri, 21 Nov 2003 19:54:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANM2S-0004yF-00 for nemo@ietf.org; Fri, 21 Nov 2003 19:54:16 -0500 Received: from pop17.ucdavis.edu ([169.237.105.27]) by ietf-mx with esmtp (Exim 4.12) id 1ANM2R-0004yC-00 for nemo@ietf.org; Fri, 21 Nov 2003 19:54:15 -0500 Received: from SOUHWANSENSQ (nat6-181.cs.ucdavis.edu [169.237.6.181]) by pop17.ucdavis.edu (8.12.9/8.12.9/it-std-5.2.0) with SMTP id hAM0sEZq026605; Fri, 21 Nov 2003 16:54:15 -0800 (PST) Message-ID: <001b01c3b093$271f9c50$b601a8c0@SOUHWANSENSQ> From: "Souhwan Jung" To: "Vijay Devarapalli" Cc: References: <3FBD50BE.5090202@iprg.nokia.com> <004201c3b087$dad0b3d0$b601a8c0@SOUHWANSENSQ> <3FBEA7E8.2030703@iprg.nokia.com> Subject: Re: [nemo] tunneling threats Date: Sat, 22 Nov 2003 09:54:10 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 PiBWaWpheSBEZXZhcmFwYWxsaSB3cm90ZToNCg0KPiBpZiB0aGUgYWRkcmVzcyBpcyBmcm9tIHRo ZSBNTlAgYW5kIHRoZSBNTk4gaXMgaW5zaWRlIHRoZSBNb2JpbGUNCj4gTmV0d29yaywgd2h5IHdv dWxkIHlvdSBjYWxsIHRoZSBhZGRyZXNzIGEgc3Bvb2ZlZCBhZGRyZXNzPyBpdA0KPiBpcyBhIHZh bGlkIGFkZHJlc3MgYXMgZmFyIGFzIGluZ3Jlc3MgZmlsdGVyaW5nIGlzIGNvbmNlcm5lZC4gYWxz bw0KPiBpdCBpcyBhIHRvcG9sb2dpY2FsbHkgY29ycmVjdCBhZGRyZXNzIHdpdGggcmVzcGVjdCB0 byB0aGUgcHJlZml4DQo+IGJlaW5nIGFkdmVydGlzZWQgaW4gdGhlIE1vYmlsZSBOZXR3b3JrLg0K DQpJdCBjb3VsZCBiZSBhIHNwb29mZWQgSVAgYWRkcmVzcyBpbiB0ZXJtcyB0aGF0IHRoZSBhdHRh Y2tlciBpcyB1c2luZyB0aGUgSVAgYWRkcmVzcyBvZiBhbm90aGVyIE1OTiBpbnNpZGUuDQoNCg0K PiBzbyBob3cgdGhpcyB0aHJlYXQgZGlmZmVybnQgZnJvbSB0aGUgY3VycmVudCBzaXR1YXRpb24g b24gdGhlDQo+IGludGVybmV0LiBJIGNhbiBsYXVuY2ggRG9TIGF0dGFja3MgdG9kYXkgZnJvbSBh IGZpeGVkIGV0aGVybmV0Lg0KPiBteSBkZWZhdWx0IHJvdXRlciBkb2VzIG5vdCBoYXZlIHRvIGJl IGEgbW9iaWxlIHJvdXRlci4gTkVNTyBkb2VzDQo+IG5vdCBpbnRyb2R1Y2UgdGhpcyB0aHJlYXQs IHJpZ2h0Pw0KDQpTdXJlLiBUaGUgaW5zaWRlIGF0dGFja2VyIGluIGN1cnJlbnQgSW50ZXJuZXQg Y2FuIGRvIGxhdW5jaCB0aGlzIGF0dGFjay4gDQpCdXQgdGhlIHByb2JsZW0gaXMgdGhhdCB0aGUg YXR0YWNrZXIgY2FuIGxhdW5jaCB0aGlzIGF0dGFjayBmcm9tIG91dHNpZGUsIHRvbyBpZiB0aGUg aW5ncmVzcyBmaWx0ZXJpbmcgYXQgdGhlIGFjY2VzcyByb3V0ZXIgb2YgdGhlIGF0dGFja2VyIGlz IG5vdCBhY3RpdmF0ZWQuIFRvIG15IGtub3dsZWRnZSwgbW9zdCByb3V0ZXJzIGp1c3QgdHVybiBv ZmYgdGhlIGluZ3Jlc3MgZmlsdGVyaW5nIGJlY2F1c2Ugb2YgdGhlaXIgY29uY2VybiBpbiBwZXJm b3JtYW5jZS4gVGhlbiwgdGhlIGhlYXZ5IHVzYWdlIG9mIElQLWluLUlQIHR1bm5lbCBpbiBNUiBh bmQgSEEgY2FuIG1ha2UgdGhpcyBwcm9ibGVtIHNlcmlvdXMsIGJlY2F1c2UgdGhlIGF0dGFja2Vy cyBmcm9tIG91dHNpZGUgY2FuIGdlbmVyYXRlIGEgYnVuY2ggb2YgSVAtaW4tSVAgcGFja2V0cyBh bmQgc2VuZCB0aGVtIHRvIEhBIGRpcmVjdGx5Lg0KSWYgSVAtaW4tSVAgdHVubmVsIHBhY2tldHMg YmV0d2VlbiBNUiBhbmQgSEEgYXJlIHNlY3VyZWQgdXNpbmcgSVBzZWMgRVNQLCB0aGVuIEhBIGNh biBqdXN0IGRyb3AgdGhlIHBhY2tldHMgZnJvbSBvdXRzaWRlLCBidXQgYXBwbHlpbmcgSVBzZWMg dG8gYWxsIHRoZSBwYWNrZXRzIHRocm91Z2ggdGhlIElQLWluLUlQIHR1bm5lbCBjb3VsZCBjYXVz ZSBhIGhlYXZ5IGxvYWQgdG8gdGhlIE1SLg0KIEkgYmVsaWV2ZSB0aGF0IGEgc2ltcGxlIGF1dGhl bnRpY2F0aW9uIG1lY2hhbmlzbSBmb3IgZmlsdGVyaW5nIHBhY2tldHMgYXQgTVIgYW5kIEhBIG1h eSBiZSByZWNvbW1lbmRlZC4NCg0KU291aHdhbg== From exim@www1.ietf.org Fri Nov 21 19:55:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14295 for ; Fri, 21 Nov 2003 19:55: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 1ANM3I-0003ii-Li for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 19:55:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAM0t8bd014299 for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 19:55:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANM3I-0003iY-GI for nemo-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 19:55: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 TAA14277 for ; Fri, 21 Nov 2003 19:54:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANM3G-0004yc-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 19:55:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANM3G-0004yZ-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 19:55:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANM3B-0003hR-UX; Fri, 21 Nov 2003 19:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANM2U-0003gr-77 for nemo@optimus.ietf.org; Fri, 21 Nov 2003 19:54: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 TAA14263 for ; Fri, 21 Nov 2003 19:54:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANM2S-0004yF-00 for nemo@ietf.org; Fri, 21 Nov 2003 19:54:16 -0500 Received: from pop17.ucdavis.edu ([169.237.105.27]) by ietf-mx with esmtp (Exim 4.12) id 1ANM2R-0004yC-00 for nemo@ietf.org; Fri, 21 Nov 2003 19:54:15 -0500 Received: from SOUHWANSENSQ (nat6-181.cs.ucdavis.edu [169.237.6.181]) by pop17.ucdavis.edu (8.12.9/8.12.9/it-std-5.2.0) with SMTP id hAM0sEZq026605; Fri, 21 Nov 2003 16:54:15 -0800 (PST) Message-ID: <001b01c3b093$271f9c50$b601a8c0@SOUHWANSENSQ> From: "Souhwan Jung" To: "Vijay Devarapalli" Cc: References: <3FBD50BE.5090202@iprg.nokia.com> <004201c3b087$dad0b3d0$b601a8c0@SOUHWANSENSQ> <3FBEA7E8.2030703@iprg.nokia.com> Subject: Re: [nemo] tunneling threats Date: Sat, 22 Nov 2003 09:54:10 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiBWaWpheSBEZXZhcmFwYWxsaSB3cm90ZToNCg0KPiBpZiB0aGUgYWRkcmVzcyBpcyBmcm9tIHRo ZSBNTlAgYW5kIHRoZSBNTk4gaXMgaW5zaWRlIHRoZSBNb2JpbGUNCj4gTmV0d29yaywgd2h5IHdv dWxkIHlvdSBjYWxsIHRoZSBhZGRyZXNzIGEgc3Bvb2ZlZCBhZGRyZXNzPyBpdA0KPiBpcyBhIHZh bGlkIGFkZHJlc3MgYXMgZmFyIGFzIGluZ3Jlc3MgZmlsdGVyaW5nIGlzIGNvbmNlcm5lZC4gYWxz bw0KPiBpdCBpcyBhIHRvcG9sb2dpY2FsbHkgY29ycmVjdCBhZGRyZXNzIHdpdGggcmVzcGVjdCB0 byB0aGUgcHJlZml4DQo+IGJlaW5nIGFkdmVydGlzZWQgaW4gdGhlIE1vYmlsZSBOZXR3b3JrLg0K DQpJdCBjb3VsZCBiZSBhIHNwb29mZWQgSVAgYWRkcmVzcyBpbiB0ZXJtcyB0aGF0IHRoZSBhdHRh Y2tlciBpcyB1c2luZyB0aGUgSVAgYWRkcmVzcyBvZiBhbm90aGVyIE1OTiBpbnNpZGUuDQoNCg0K PiBzbyBob3cgdGhpcyB0aHJlYXQgZGlmZmVybnQgZnJvbSB0aGUgY3VycmVudCBzaXR1YXRpb24g b24gdGhlDQo+IGludGVybmV0LiBJIGNhbiBsYXVuY2ggRG9TIGF0dGFja3MgdG9kYXkgZnJvbSBh IGZpeGVkIGV0aGVybmV0Lg0KPiBteSBkZWZhdWx0IHJvdXRlciBkb2VzIG5vdCBoYXZlIHRvIGJl IGEgbW9iaWxlIHJvdXRlci4gTkVNTyBkb2VzDQo+IG5vdCBpbnRyb2R1Y2UgdGhpcyB0aHJlYXQs IHJpZ2h0Pw0KDQpTdXJlLiBUaGUgaW5zaWRlIGF0dGFja2VyIGluIGN1cnJlbnQgSW50ZXJuZXQg Y2FuIGRvIGxhdW5jaCB0aGlzIGF0dGFjay4gDQpCdXQgdGhlIHByb2JsZW0gaXMgdGhhdCB0aGUg YXR0YWNrZXIgY2FuIGxhdW5jaCB0aGlzIGF0dGFjayBmcm9tIG91dHNpZGUsIHRvbyBpZiB0aGUg aW5ncmVzcyBmaWx0ZXJpbmcgYXQgdGhlIGFjY2VzcyByb3V0ZXIgb2YgdGhlIGF0dGFja2VyIGlz IG5vdCBhY3RpdmF0ZWQuIFRvIG15IGtub3dsZWRnZSwgbW9zdCByb3V0ZXJzIGp1c3QgdHVybiBv ZmYgdGhlIGluZ3Jlc3MgZmlsdGVyaW5nIGJlY2F1c2Ugb2YgdGhlaXIgY29uY2VybiBpbiBwZXJm b3JtYW5jZS4gVGhlbiwgdGhlIGhlYXZ5IHVzYWdlIG9mIElQLWluLUlQIHR1bm5lbCBpbiBNUiBh bmQgSEEgY2FuIG1ha2UgdGhpcyBwcm9ibGVtIHNlcmlvdXMsIGJlY2F1c2UgdGhlIGF0dGFja2Vy cyBmcm9tIG91dHNpZGUgY2FuIGdlbmVyYXRlIGEgYnVuY2ggb2YgSVAtaW4tSVAgcGFja2V0cyBh bmQgc2VuZCB0aGVtIHRvIEhBIGRpcmVjdGx5Lg0KSWYgSVAtaW4tSVAgdHVubmVsIHBhY2tldHMg YmV0d2VlbiBNUiBhbmQgSEEgYXJlIHNlY3VyZWQgdXNpbmcgSVBzZWMgRVNQLCB0aGVuIEhBIGNh biBqdXN0IGRyb3AgdGhlIHBhY2tldHMgZnJvbSBvdXRzaWRlLCBidXQgYXBwbHlpbmcgSVBzZWMg dG8gYWxsIHRoZSBwYWNrZXRzIHRocm91Z2ggdGhlIElQLWluLUlQIHR1bm5lbCBjb3VsZCBjYXVz ZSBhIGhlYXZ5IGxvYWQgdG8gdGhlIE1SLg0KIEkgYmVsaWV2ZSB0aGF0IGEgc2ltcGxlIGF1dGhl bnRpY2F0aW9uIG1lY2hhbmlzbSBmb3IgZmlsdGVyaW5nIHBhY2tldHMgYXQgTVIgYW5kIEhBIG1h eSBiZSByZWNvbW1lbmRlZC4NCg0KU291aHdhbg== From nemo-admin@ietf.org Fri Nov 21 20:12:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14696 for ; Fri, 21 Nov 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 1ANMJd-00055t-EY; Fri, 21 Nov 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 1ANMJE-00055T-De for nemo@optimus.ietf.org; Fri, 21 Nov 2003 20:11: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 UAA14674 for ; Fri, 21 Nov 2003 20:11:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANMJC-00059x-00 for nemo@ietf.org; Fri, 21 Nov 2003 20:11:34 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ANMJB-00059u-00 for nemo@ietf.org; Fri, 21 Nov 2003 20:11:33 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAM1AVG14555; Fri, 21 Nov 2003 17:10:31 -0800 X-mProtect: <200311220110> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4mUBLe; Fri, 21 Nov 2003 17:10:30 PST Message-ID: <3FBEB895.4090409@iprg.nokia.com> Date: Fri, 21 Nov 2003 17:15: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: Souhwan Jung CC: nemo@ietf.org Subject: Re: [nemo] tunneling threats References: <3FBD50BE.5090202@iprg.nokia.com> <004201c3b087$dad0b3d0$b601a8c0@SOUHWANSENSQ> <3FBEA7E8.2030703@iprg.nokia.com> <001b01c3b093$271f9c50$b601a8c0@SOUHWANSENSQ> In-Reply-To: <001b01c3b093$271f9c50$b601a8c0@SOUHWANSENSQ> 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 Souhwan Jung wrote: >>Vijay Devarapalli wrote: > > >>if the address is from the MNP and the MNN is inside the Mobile >>Network, why would you call the address a spoofed address? it >>is a valid address as far as ingress filtering is concerned. also >>it is a topologically correct address with respect to the prefix >>being advertised in the Mobile Network. > > > It could be a spoofed IP address in terms that the attacker is >using the IP address of another MNN inside. you cant prevent this. it is possible today on ethernet, WLAN. Secure Neighbor Discovery might be able to fix this. >>so how this threat differnt from the current situation on the >>internet. I can launch DoS attacks today from a fixed ethernet. >>my default router does not have to be a mobile router. NEMO does >>not introduce this threat, right? > > > Sure. The inside attacker in current Internet can do launch > this attack. But the problem is that the attacker can launch > this attack from outside, too if the ingress filtering at the > access router of the attacker is not activated. To my knowledge, > most routers just turn off the ingress filtering because of their > concern in performance. Then, the heavy usage of IP-in-IP tunnel > in MR and HA can make this problem serious, because the attackers > from outside can generate a bunch of IP-in-IP packets and send > them to HA directly. > If IP-in-IP tunnel packets between MR and HA are secured using > IPsec ESP, then HA can just drop the packets from outside, but > applying IPsec to all the packets through the IP-in-IP tunnel > could cause a heavy load to the MR. > I believe that a simple authentication mechanism for filtering > packets at MR and HA may be recommended. this threat comes mainly from not using ingress filtering. there isnt much we can do about it. requiring IPsec protection for all tunneled traffic between the MR and the HA however is not a solution, IMO. Vijay From exim@www1.ietf.org Fri Nov 21 20:12:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14711 for ; Fri, 21 Nov 2003 20: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 1ANMJf-00056t-VT for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 20:12:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAM1C3aH019637 for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 20:12:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANMJf-00056e-QU for nemo-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 20:12: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 UAA14683 for ; Fri, 21 Nov 2003 20:11:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANMJd-0005AG-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 20:12:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANMJd-0005AD-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 20: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 1ANMJd-00055t-EY; Fri, 21 Nov 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 1ANMJE-00055T-De for nemo@optimus.ietf.org; Fri, 21 Nov 2003 20:11: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 UAA14674 for ; Fri, 21 Nov 2003 20:11:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANMJC-00059x-00 for nemo@ietf.org; Fri, 21 Nov 2003 20:11:34 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1ANMJB-00059u-00 for nemo@ietf.org; Fri, 21 Nov 2003 20:11:33 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAM1AVG14555; Fri, 21 Nov 2003 17:10:31 -0800 X-mProtect: <200311220110> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4mUBLe; Fri, 21 Nov 2003 17:10:30 PST Message-ID: <3FBEB895.4090409@iprg.nokia.com> Date: Fri, 21 Nov 2003 17:15: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: Souhwan Jung CC: nemo@ietf.org Subject: Re: [nemo] tunneling threats References: <3FBD50BE.5090202@iprg.nokia.com> <004201c3b087$dad0b3d0$b601a8c0@SOUHWANSENSQ> <3FBEA7E8.2030703@iprg.nokia.com> <001b01c3b093$271f9c50$b601a8c0@SOUHWANSENSQ> In-Reply-To: <001b01c3b093$271f9c50$b601a8c0@SOUHWANSENSQ> 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 Souhwan Jung wrote: >>Vijay Devarapalli wrote: > > >>if the address is from the MNP and the MNN is inside the Mobile >>Network, why would you call the address a spoofed address? it >>is a valid address as far as ingress filtering is concerned. also >>it is a topologically correct address with respect to the prefix >>being advertised in the Mobile Network. > > > It could be a spoofed IP address in terms that the attacker is >using the IP address of another MNN inside. you cant prevent this. it is possible today on ethernet, WLAN. Secure Neighbor Discovery might be able to fix this. >>so how this threat differnt from the current situation on the >>internet. I can launch DoS attacks today from a fixed ethernet. >>my default router does not have to be a mobile router. NEMO does >>not introduce this threat, right? > > > Sure. The inside attacker in current Internet can do launch > this attack. But the problem is that the attacker can launch > this attack from outside, too if the ingress filtering at the > access router of the attacker is not activated. To my knowledge, > most routers just turn off the ingress filtering because of their > concern in performance. Then, the heavy usage of IP-in-IP tunnel > in MR and HA can make this problem serious, because the attackers > from outside can generate a bunch of IP-in-IP packets and send > them to HA directly. > If IP-in-IP tunnel packets between MR and HA are secured using > IPsec ESP, then HA can just drop the packets from outside, but > applying IPsec to all the packets through the IP-in-IP tunnel > could cause a heavy load to the MR. > I believe that a simple authentication mechanism for filtering > packets at MR and HA may be recommended. this threat comes mainly from not using ingress filtering. there isnt much we can do about it. requiring IPsec protection for all tunneled traffic between the MR and the HA however is not a solution, IMO. Vijay From nemo-admin@ietf.org Fri Nov 21 22:31:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17630 for ; Fri, 21 Nov 2003 22:31: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 1ANOU9-0004Oj-EA; Fri, 21 Nov 2003 22:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANOTP-0004JT-UH for nemo@optimus.ietf.org; Fri, 21 Nov 2003 22:30: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 WAA17612 for ; Fri, 21 Nov 2003 22:30:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANOTM-0006b1-00 for nemo@ietf.org; Fri, 21 Nov 2003 22:30:12 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1ANOTL-0006ay-00 for nemo@ietf.org; Fri, 21 Nov 2003 22:30:11 -0500 Received: from [64.36.73.245] (home5.kniveton.com [64.36.73.245]) by multihop.net (8.12.10/8.12.10) with ESMTP id hAM3UWGb071690; Fri, 21 Nov 2003 19:30:32 -0800 (PST) (envelope-from tj@kniveton.com) In-Reply-To: <001b01c3b093$271f9c50$b601a8c0@SOUHWANSENSQ> References: <3FBD50BE.5090202@iprg.nokia.com> <004201c3b087$dad0b3d0$b601a8c0@SOUHWANSENSQ> <3FBEA7E8.2030703@iprg.nokia.com> <001b01c3b093$271f9c50$b601a8c0@SOUHWANSENSQ> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-970287976; protocol="application/pkcs7-signature" Message-Id: <278DA20C-1C9C-11D8-B935-000A95DA08F2@kniveton.com> Cc: "" From: "T.J. Kniveton" Subject: Re: [nemo] tunneling threats Date: Fri, 21 Nov 2003 19:30:01 -0800 To: "Souhwan Jung" 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-970287976 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Nov 21, 2003, at 4:54 PM, Souhwan Jung wrote: >> so how this threat differnt from the current situation on the >> internet. I can launch DoS attacks today from a fixed ethernet. >> my default router does not have to be a mobile router. NEMO does >> not introduce this threat, right? > > Sure. The inside attacker in current Internet can do launch this > attack. > But the problem is that the attacker can launch this attack from > outside, too if the ingress filtering at the access router of the > attacker is not activated. To my knowledge, most routers just turn off > the ingress filtering because of their concern in performance. This is wrong implementation. If a router wants to boost performance by not checking anything in the packet header, it should keep its forwarding path separate from the packet generation path where it might apply IPsec SPD rules. If a router is applying IPsec policies to packets it is forwarding, that is its own fault, IMO. > Then, the heavy usage of IP-in-IP tunnel in MR and HA can make this > problem serious, because the attackers from outside can generate a > bunch of IP-in-IP packets and send them to HA directly. > Well as Vijay mentioned, this is easy to prevent -- you simply check whether a packet you are forwarding is using your own source address. Alternatively, when a packet comes on an ingress interface, you can mark the buffer with a bit, and then when you do your policy rule checking, if the bit is set, you do not apply any IPsec rules to the packet - just send it as-is. > If IP-in-IP tunnel packets between MR and HA are secured using IPsec > ESP, then HA can just drop the packets from outside, but applying > IPsec to all the packets through the IP-in-IP tunnel could cause a > heavy load to the MR. Well, when the packets are decapsulated, the MR doesn't necessarily know they came from a tunnel. But the above rule will still apply. > I believe that a simple authentication mechanism for filtering > packets at MR and HA may be recommended. > And what would the authentication mechanism be? Doesn't the authentication depend on how access control is administered at the MR's and HA's networks? TJ --Apple-Mail-4-970287976 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 ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTEyMjAzMzAw MVowIwYJKoZIhvcNAQkEMRYEFG24+LTzbMYGxXmaQoMDQ37r28gMMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgAbUpTybUYKQhBDp1fPBZaJryxvTQEoP0UshMjHGdBI5 rpogW09TxyKRaapTMPf0R6Jq3qIiz8iUKg9XnkcjfXAaGD6+qN186jDLCebGstwWtzzPv8J65BBo 8pyVyu/OrvEGzwgQdTrgGKzjqYLqQBPd6M5qIhhFZqxUfAmudQ5xAAAAAAAA --Apple-Mail-4-970287976-- From exim@www1.ietf.org Fri Nov 21 22:31:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17645 for ; Fri, 21 Nov 2003 22:31: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 1ANOUC-0004Pe-Mk for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 22:31:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAM3V4SY016961 for nemo-archive@odin.ietf.org; Fri, 21 Nov 2003 22:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANOUC-0004PU-Im for nemo-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 22:31: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 WAA17618 for ; Fri, 21 Nov 2003 22:30:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANOU9-0006b7-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 22:31:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANOU8-0006b4-00 for nemo-web-archive@ietf.org; Fri, 21 Nov 2003 22:31:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANOU9-0004Oj-EA; Fri, 21 Nov 2003 22:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANOTP-0004JT-UH for nemo@optimus.ietf.org; Fri, 21 Nov 2003 22:30: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 WAA17612 for ; Fri, 21 Nov 2003 22:30:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANOTM-0006b1-00 for nemo@ietf.org; Fri, 21 Nov 2003 22:30:12 -0500 Received: from [192.103.16.205] (helo=multihop.net) by ietf-mx with esmtp (Exim 4.12) id 1ANOTL-0006ay-00 for nemo@ietf.org; Fri, 21 Nov 2003 22:30:11 -0500 Received: from [64.36.73.245] (home5.kniveton.com [64.36.73.245]) by multihop.net (8.12.10/8.12.10) with ESMTP id hAM3UWGb071690; Fri, 21 Nov 2003 19:30:32 -0800 (PST) (envelope-from tj@kniveton.com) In-Reply-To: <001b01c3b093$271f9c50$b601a8c0@SOUHWANSENSQ> References: <3FBD50BE.5090202@iprg.nokia.com> <004201c3b087$dad0b3d0$b601a8c0@SOUHWANSENSQ> <3FBEA7E8.2030703@iprg.nokia.com> <001b01c3b093$271f9c50$b601a8c0@SOUHWANSENSQ> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-970287976; protocol="application/pkcs7-signature" Message-Id: <278DA20C-1C9C-11D8-B935-000A95DA08F2@kniveton.com> Cc: "" From: "T.J. Kniveton" Subject: Re: [nemo] tunneling threats Date: Fri, 21 Nov 2003 19:30:01 -0800 To: "Souhwan Jung" 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-970287976 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Nov 21, 2003, at 4:54 PM, Souhwan Jung wrote: >> so how this threat differnt from the current situation on the >> internet. I can launch DoS attacks today from a fixed ethernet. >> my default router does not have to be a mobile router. NEMO does >> not introduce this threat, right? > > Sure. The inside attacker in current Internet can do launch this > attack. > But the problem is that the attacker can launch this attack from > outside, too if the ingress filtering at the access router of the > attacker is not activated. To my knowledge, most routers just turn off > the ingress filtering because of their concern in performance. This is wrong implementation. If a router wants to boost performance by not checking anything in the packet header, it should keep its forwarding path separate from the packet generation path where it might apply IPsec SPD rules. If a router is applying IPsec policies to packets it is forwarding, that is its own fault, IMO. > Then, the heavy usage of IP-in-IP tunnel in MR and HA can make this > problem serious, because the attackers from outside can generate a > bunch of IP-in-IP packets and send them to HA directly. > Well as Vijay mentioned, this is easy to prevent -- you simply check whether a packet you are forwarding is using your own source address. Alternatively, when a packet comes on an ingress interface, you can mark the buffer with a bit, and then when you do your policy rule checking, if the bit is set, you do not apply any IPsec rules to the packet - just send it as-is. > If IP-in-IP tunnel packets between MR and HA are secured using IPsec > ESP, then HA can just drop the packets from outside, but applying > IPsec to all the packets through the IP-in-IP tunnel could cause a > heavy load to the MR. Well, when the packets are decapsulated, the MR doesn't necessarily know they came from a tunnel. But the above rule will still apply. > I believe that a simple authentication mechanism for filtering > packets at MR and HA may be recommended. > And what would the authentication mechanism be? Doesn't the authentication depend on how access control is administered at the MR's and HA's networks? TJ --Apple-Mail-4-970287976 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 ggIFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTEyMjAzMzAw MVowIwYJKoZIhvcNAQkEMRYEFG24+LTzbMYGxXmaQoMDQ37r28gMMIHQBgkrBgEEAYI3EAQxgcIw gb8wgbkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJh bmNpc2NvMRowGAYDVQQKExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5m cmFzdHJ1Y3R1cmUgR3JvdXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0B CQEWD2NhQG11bHRpaG9wLm5ldAIBCDCB0gYLKoZIhvcNAQkQAgsxgcKggb8wgbkxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRowGAYDVQQK ExFNdWx0aWhvcCBOZXR3b3JrczEmMCQGA1UECxMdU2VjdXJpdHkgSW5mcmFzdHJ1Y3R1cmUgR3Jv dXAxGTAXBgNVBAMTEGlpby5tdWx0aWhvcC5uZXQxHjAcBgkqhkiG9w0BCQEWD2NhQG11bHRpaG9w Lm5ldAIBCDANBgkqhkiG9w0BAQEFAASBgAbUpTybUYKQhBDp1fPBZaJryxvTQEoP0UshMjHGdBI5 rpogW09TxyKRaapTMPf0R6Jq3qIiz8iUKg9XnkcjfXAaGD6+qN186jDLCebGstwWtzzPv8J65BBo 8pyVyu/OrvEGzwgQdTrgGKzjqYLqQBPd6M5qIhhFZqxUfAmudQ5xAAAAAAAA --Apple-Mail-4-970287976-- From nemo-admin@ietf.org Mon Nov 24 05:07:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01989 for ; Mon, 24 Nov 2003 05:07:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AODcU-0006M9-35; Mon, 24 Nov 2003 05: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 1AODcS-0006LR-4a for nemo@optimus.ietf.org; Mon, 24 Nov 2003 05:07: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 FAA01969 for ; Mon, 24 Nov 2003 05:06:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AODcO-0001Wr-00 for nemo@ietf.org; Mon, 24 Nov 2003 05:06:56 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AODcO-0001Wn-00 for nemo@ietf.org; Mon, 24 Nov 2003 05:06:56 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 24 Nov 2003 11:03:50 +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 hAOA6E35023331; Mon, 24 Nov 2003 11:06: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); Mon, 24 Nov 2003 10:06: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] tunneling threats Date: Mon, 24 Nov 2003 10:06:17 -0000 Message-ID: Thread-Topic: [nemo] tunneling threats Thread-Index: AcOwqVUtgLiTUDRHSe+Eh2zpqKgGOgBxc4Ng From: "Pascal Thubert (pthubert)" To: "Souhwan Jung" Cc: X-OriginalArrivalTime: 24 Nov 2003 10:06:25.0945 (UTC) FILETIME=[9EF61890:01C3B272] 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: I have in mind that the RO in the nested structure can help on such problems. Maybe we can think of it at the time we write the problem statement? It seems important to be able to prevent untrusted (anonymous) visitors from sending packets over the reverse tunnel. For the Home security, for the privacy of the visitor, you name it. This means that visitors would have to manage their ROed mobility regardless of the mobility of their attachment router. An example of this is a mobile router with an interface that's open to anonymous visitors. On that interface, the MNP is not advertised. The advertised prefix is either a locally delegated prefix or a scoped prefix. Packets from that interface are not tunneled over the MRHA but can only be forwarded somehow to the TLMR. And RO provides the means for the TLMR to forward the packets back to that prefix. That model can for instance be applied easily to the source routing based RO used in RRH. MRs can forge and renew regularly the prefixes they expose on the open interfaces. Only the MR that stamps a RRH entry actually uses that information on the way back, so the advertised prefix is forged and used locally. Packets from anonymous visitors that have an RRH are naturally forwarded to the TLMR (this is plain RRH forwarding). Packets from anonymous visitors with no RRH are dropped by policy. Since the forged prefix can be crypto'ed, there's a way for the MR to check for RRH attacks. Renewing an advertised forged prefix is analogous to a movement for the anonymous visitors. Additionally, this protects the privacy of the visited router... Pascal From exim@www1.ietf.org Mon Nov 24 05:07:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02007 for ; Mon, 24 Nov 2003 05:07: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 1AODcd-0006RQ-TV for nemo-archive@odin.ietf.org; Mon, 24 Nov 2003 05:07:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOA7BVV024755 for nemo-archive@odin.ietf.org; Mon, 24 Nov 2003 05:07:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AODcc-0006RC-UA for nemo-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 05:07: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 FAA01986 for ; Mon, 24 Nov 2003 05:06:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AODcZ-0001XH-00 for nemo-web-archive@ietf.org; Mon, 24 Nov 2003 05:07:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AODcZ-0001XD-00 for nemo-web-archive@ietf.org; Mon, 24 Nov 2003 05:07:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AODcU-0006M9-35; Mon, 24 Nov 2003 05: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 1AODcS-0006LR-4a for nemo@optimus.ietf.org; Mon, 24 Nov 2003 05:07: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 FAA01969 for ; Mon, 24 Nov 2003 05:06:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AODcO-0001Wr-00 for nemo@ietf.org; Mon, 24 Nov 2003 05:06:56 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AODcO-0001Wn-00 for nemo@ietf.org; Mon, 24 Nov 2003 05:06:56 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 24 Nov 2003 11:03:50 +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 hAOA6E35023331; Mon, 24 Nov 2003 11:06: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); Mon, 24 Nov 2003 10:06: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] tunneling threats Date: Mon, 24 Nov 2003 10:06:17 -0000 Message-ID: Thread-Topic: [nemo] tunneling threats Thread-Index: AcOwqVUtgLiTUDRHSe+Eh2zpqKgGOgBxc4Ng From: "Pascal Thubert (pthubert)" To: "Souhwan Jung" Cc: X-OriginalArrivalTime: 24 Nov 2003 10:06:25.0945 (UTC) FILETIME=[9EF61890:01C3B272] 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: I have in mind that the RO in the nested structure can help on such problems. Maybe we can think of it at the time we write the problem statement? It seems important to be able to prevent untrusted (anonymous) visitors from sending packets over the reverse tunnel. For the Home security, for the privacy of the visitor, you name it. This means that visitors would have to manage their ROed mobility regardless of the mobility of their attachment router. An example of this is a mobile router with an interface that's open to anonymous visitors. On that interface, the MNP is not advertised. The advertised prefix is either a locally delegated prefix or a scoped prefix. Packets from that interface are not tunneled over the MRHA but can only be forwarded somehow to the TLMR. And RO provides the means for the TLMR to forward the packets back to that prefix. That model can for instance be applied easily to the source routing based RO used in RRH. MRs can forge and renew regularly the prefixes they expose on the open interfaces. Only the MR that stamps a RRH entry actually uses that information on the way back, so the advertised prefix is forged and used locally. Packets from anonymous visitors that have an RRH are naturally forwarded to the TLMR (this is plain RRH forwarding). Packets from anonymous visitors with no RRH are dropped by policy. Since the forged prefix can be crypto'ed, there's a way for the MR to check for RRH attacks. Renewing an advertised forged prefix is analogous to a movement for the anonymous visitors. Additionally, this protects the privacy of the visited router... Pascal From nemo-admin@ietf.org Mon Nov 24 11:49:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15516 for ; Mon, 24 Nov 2003 11: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 1AOJtV-0007MS-EW; Mon, 24 Nov 2003 11: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 1AOJt8-0007I8-QK for nemo@optimus.ietf.org; Mon, 24 Nov 2003 11:48: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 LAA15451 for ; Mon, 24 Nov 2003 11:48:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOJt7-0000An-00 for nemo@ietf.org; Mon, 24 Nov 2003 11:48:37 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AOJt7-0000AO-00 for nemo@ietf.org; Mon, 24 Nov 2003 11:48:37 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 24 Nov 2003 17:45:28 +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 hAOGlrRA000747; Mon, 24 Nov 2003 17:47:53 +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, 24 Nov 2003 16:48:05 +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: Mon, 24 Nov 2003 16:48:04 -0000 Message-ID: Thread-Topic: Explicit Prefix Length Option Thread-Index: AcOwYaUu3NCf9ptpRtmAUonn87QSeACRi75w From: "Pascal Thubert (pthubert)" To: Cc: X-OriginalArrivalTime: 24 Nov 2003 16:48:05.0492 (UTC) FILETIME=[BB692340:01C3B2AA] Content-Transfer-Encoding: quoted-printable Subject: [nemo] FW: Explicit Prefix Length Option Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org 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 Jim, We've had some discussions inside the DT over the explicit prefix length option. As far as we understand it, the explicit prefix does it all. It allows multiple bundled registrations of network prefixes, together with the registration of a home address. The downside of that power is a level of complexity to implement and to deploy (mostly the authorization part of it). On the other hand, the explicit prefix length is a simple thing. My view is that it could be useful to provide a simple deployment model. In that model, there's an implicit authorization for a mobile router to register for a given, length configurable, prefix around its home address (iff there exists an SA with its Home Agent). This limited use case allows for a very simple configuration and in particular a virtual Home Network and no specific authorization checking. I believe that this mode somehow extends the fact that in MIPv6, the Home Address that is registered is the SA end point, which is already implicitly an authorization model (the Home Address being registered is not part of the mobility header anymore that the prefix is present in explicit prefix length case). So in my view, there's value to the explicit prefix length option. Also, it does not cost much to implement. We could suggest that the implicit authorization model applies to explicit prefix length only, making the 2 paths in the explicit support code different. What do you think? Pascal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: vendredi 21 novembre 2003 19:59 > To: Pascal Thubert (pthubert) > Cc: Ryuji Wakikawa; Vijay Devarapalli > Subject: Re: Explicit Prefix Length Option >=20 >=20 >=20 > Pascal Thubert (pthubert) wrote: >=20 > >> > >>this is not correct. the HA has to still verify that the Mobile > >>Router is authorized for that prefix, because it could be just > >>a mobile node, which configured a home address from a prefix > >>belonging to a Mobile Router and attempting to register with > >>the Home Agent as a mobile router. the idea to is to prevent > >>misbehaving mobile nodes/mobile routers. > >> > > > > We do not communicate here. My view here is that the HA has a policy > > where it has SAs only for MRs which own the /64 around their home > > address. By policy. It's a limited subcase. When the HA is configured > > that way, your case is avoided, by definition. >=20 > >>the combination of IPsec SA for the Home Address, the fact that the > >>Home Address was configured from the MNP and the use of the Explicit > >>Prefix Length mode does not still give the Home Agent enough > >>confidence that the home address claimed in the Binding Update is > >>authorized to setup forwarding for a particular Mobile Network. > >> > > > > > > Not in general, but in a particular policy, yes. I think it's a config > > issue >=20 > aha, so there are separate IPsec policy entries for Mobile Routers > which configure their home address from thier MNPs. I am not sure I > like it. :( >=20 > >>>Vijay, you may want to copy James sometime? > >> > >>lets stop with this thread. you might want to write a mail to Jim > >>and the WG, justifying the Explicit Prefix Length mode. or you can > >>just disagree with James saying that the savings of 16 bytes is > >>worth it. that is fine with me too. > > > > Right, this entered the usage world. Do you agree to copy the list as > > comment on usage? >=20 > Pascal, can you post a short summary of this thread to the mailing > list and James Kempf? you should in short say why the Explicit > Prefix Length mode is required. and then lets take it from there. > I am not entirely convinced Explicit Prefix Length mode is needed. > but I will keep quiet. :) >=20 > Vijay From exim@www1.ietf.org Mon Nov 24 11:49:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15534 for ; Mon, 24 Nov 2003 11:49: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 1AOJtc-0007Nl-N9 for nemo-archive@odin.ietf.org; Mon, 24 Nov 2003 11:49:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOGn8h2028372 for nemo-archive@odin.ietf.org; Mon, 24 Nov 2003 11:49:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJtc-0007NX-1i for nemo-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 11: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 LAA15502 for ; Mon, 24 Nov 2003 11:48:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOJta-0000BQ-00 for nemo-web-archive@ietf.org; Mon, 24 Nov 2003 11:49:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOJta-0000BN-00 for nemo-web-archive@ietf.org; Mon, 24 Nov 2003 11:49:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJtV-0007MS-EW; Mon, 24 Nov 2003 11: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 1AOJt8-0007I8-QK for nemo@optimus.ietf.org; Mon, 24 Nov 2003 11:48: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 LAA15451 for ; Mon, 24 Nov 2003 11:48:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOJt7-0000An-00 for nemo@ietf.org; Mon, 24 Nov 2003 11:48:37 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AOJt7-0000AO-00 for nemo@ietf.org; Mon, 24 Nov 2003 11:48:37 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 24 Nov 2003 17:45:28 +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 hAOGlrRA000747; Mon, 24 Nov 2003 17:47:53 +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, 24 Nov 2003 16:48:05 +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: Mon, 24 Nov 2003 16:48:04 -0000 Message-ID: Thread-Topic: Explicit Prefix Length Option Thread-Index: AcOwYaUu3NCf9ptpRtmAUonn87QSeACRi75w From: "Pascal Thubert (pthubert)" To: Cc: X-OriginalArrivalTime: 24 Nov 2003 16:48:05.0492 (UTC) FILETIME=[BB692340:01C3B2AA] Content-Transfer-Encoding: quoted-printable Subject: [nemo] FW: Explicit Prefix Length Option Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org 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 Jim, We've had some discussions inside the DT over the explicit prefix length option. As far as we understand it, the explicit prefix does it all. It allows multiple bundled registrations of network prefixes, together with the registration of a home address. The downside of that power is a level of complexity to implement and to deploy (mostly the authorization part of it). On the other hand, the explicit prefix length is a simple thing. My view is that it could be useful to provide a simple deployment model. In that model, there's an implicit authorization for a mobile router to register for a given, length configurable, prefix around its home address (iff there exists an SA with its Home Agent). This limited use case allows for a very simple configuration and in particular a virtual Home Network and no specific authorization checking. I believe that this mode somehow extends the fact that in MIPv6, the Home Address that is registered is the SA end point, which is already implicitly an authorization model (the Home Address being registered is not part of the mobility header anymore that the prefix is present in explicit prefix length case). So in my view, there's value to the explicit prefix length option. Also, it does not cost much to implement. We could suggest that the implicit authorization model applies to explicit prefix length only, making the 2 paths in the explicit support code different. What do you think? Pascal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: vendredi 21 novembre 2003 19:59 > To: Pascal Thubert (pthubert) > Cc: Ryuji Wakikawa; Vijay Devarapalli > Subject: Re: Explicit Prefix Length Option >=20 >=20 >=20 > Pascal Thubert (pthubert) wrote: >=20 > >> > >>this is not correct. the HA has to still verify that the Mobile > >>Router is authorized for that prefix, because it could be just > >>a mobile node, which configured a home address from a prefix > >>belonging to a Mobile Router and attempting to register with > >>the Home Agent as a mobile router. the idea to is to prevent > >>misbehaving mobile nodes/mobile routers. > >> > > > > We do not communicate here. My view here is that the HA has a policy > > where it has SAs only for MRs which own the /64 around their home > > address. By policy. It's a limited subcase. When the HA is configured > > that way, your case is avoided, by definition. >=20 > >>the combination of IPsec SA for the Home Address, the fact that the > >>Home Address was configured from the MNP and the use of the Explicit > >>Prefix Length mode does not still give the Home Agent enough > >>confidence that the home address claimed in the Binding Update is > >>authorized to setup forwarding for a particular Mobile Network. > >> > > > > > > Not in general, but in a particular policy, yes. I think it's a config > > issue >=20 > aha, so there are separate IPsec policy entries for Mobile Routers > which configure their home address from thier MNPs. I am not sure I > like it. :( >=20 > >>>Vijay, you may want to copy James sometime? > >> > >>lets stop with this thread. you might want to write a mail to Jim > >>and the WG, justifying the Explicit Prefix Length mode. or you can > >>just disagree with James saying that the savings of 16 bytes is > >>worth it. that is fine with me too. > > > > Right, this entered the usage world. Do you agree to copy the list as > > comment on usage? >=20 > Pascal, can you post a short summary of this thread to the mailing > list and James Kempf? you should in short say why the Explicit > Prefix Length mode is required. and then lets take it from there. > I am not entirely convinced Explicit Prefix Length mode is needed. > but I will keep quiet. :) >=20 > Vijay From nemo-admin@ietf.org Mon Nov 24 12:37:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18113 for ; Mon, 24 Nov 2003 12:37:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKdz-0002sS-9f; Mon, 24 Nov 2003 12:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKdc-0002ri-AD for nemo@optimus.ietf.org; Mon, 24 Nov 2003 12:36:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18009 for ; Mon, 24 Nov 2003 12:36:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOKdY-00013x-00 for nemo@ietf.org; Mon, 24 Nov 2003 12:36:36 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AOKdY-00013s-00 for nemo@ietf.org; Mon, 24 Nov 2003 12:36:36 -0500 Message-ID: <01fe01c3b2b1$854da680$956015ac@dclkempt40> From: "James Kempf" To: "Pascal Thubert \(pthubert\)" Cc: References: Date: Mon, 24 Nov 2003 09:36:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Explicit Prefix Length Option Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > On the other hand, the explicit prefix length is a simple thing. My view > is that it could be useful to provide a simple deployment model. In that > model, there's an implicit authorization for a mobile router to register > for a given, length configurable, prefix around its home address (iff > there exists an SA with its Home Agent). This limited use case allows > for a very simple configuration and in particular a virtual Home Network > and no specific authorization checking. > I don't believe this is acceptible from a mobile service provider deployment standpoint. There needs to be some way for the home network to authenticate the identity of the mobile router to assure that the mobile router is authorized to register the prefixes. IKEv2 provides a way to use legacy authentication methods within the Phase 1 ISAKMP transaction, to authenticate the identity of a host, but nothing specifically for prefixes, so that would have to be arranged somehow. Another alternative is to use a certificate, for example, an identity certificate containing the new PKIX IP address range extension with the prefixes the mobile router is authorized to route. See draft-ietf-pkix-x509-ipaddr-as-extn-03.txt. SEND is using this extension to allow an access router to identify the prefixes it is allowed to route, and SBGP is using it to allow border routers to identify what address ranges they have been assigned by IANA. > I believe that this mode somehow extends the fact that in MIPv6, the > Home Address that is registered is the SA end point, which is already > implicitly an authorization model (the Home Address being registered is > not part of the mobility header anymore that the prefix is present in > explicit prefix length case). So in my view, there's value to the > explicit prefix length option. Also, it does not cost much to implement. > We could suggest that the implicit authorization model applies to > explicit prefix length only, making the 2 paths in the explicit support > code different. > There's an issue in MIPv6 with authorization as well, but because the host is required to have an IPsec SA with the HA, it's not as critical, since the host must prove its identity to either set that up (if its dynamic) or to use it (if its static). If the home address is dynamically assigned, however, there is a problem. This is part of the bootstrapping work item that is in the new MIP6 charter. jak From exim@www1.ietf.org Mon Nov 24 12:37:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18128 for ; Mon, 24 Nov 2003 12:37: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 1AOKe3-0002vY-Le for nemo-archive@odin.ietf.org; Mon, 24 Nov 2003 12:37:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOHb7o1011244 for nemo-archive@odin.ietf.org; Mon, 24 Nov 2003 12:37:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKe2-0002vH-U1 for nemo-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 12: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 MAA18072 for ; Mon, 24 Nov 2003 12:36:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOKe1-00014m-00 for nemo-web-archive@ietf.org; Mon, 24 Nov 2003 12:37:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOKe0-00014Y-00 for nemo-web-archive@ietf.org; Mon, 24 Nov 2003 12:37:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKdz-0002sS-9f; Mon, 24 Nov 2003 12:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKdc-0002ri-AD for nemo@optimus.ietf.org; Mon, 24 Nov 2003 12:36:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18009 for ; Mon, 24 Nov 2003 12:36:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOKdY-00013x-00 for nemo@ietf.org; Mon, 24 Nov 2003 12:36:36 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AOKdY-00013s-00 for nemo@ietf.org; Mon, 24 Nov 2003 12:36:36 -0500 Message-ID: <01fe01c3b2b1$854da680$956015ac@dclkempt40> From: "James Kempf" To: "Pascal Thubert \(pthubert\)" Cc: References: Date: Mon, 24 Nov 2003 09:36:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Explicit Prefix Length Option Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > On the other hand, the explicit prefix length is a simple thing. My view > is that it could be useful to provide a simple deployment model. In that > model, there's an implicit authorization for a mobile router to register > for a given, length configurable, prefix around its home address (iff > there exists an SA with its Home Agent). This limited use case allows > for a very simple configuration and in particular a virtual Home Network > and no specific authorization checking. > I don't believe this is acceptible from a mobile service provider deployment standpoint. There needs to be some way for the home network to authenticate the identity of the mobile router to assure that the mobile router is authorized to register the prefixes. IKEv2 provides a way to use legacy authentication methods within the Phase 1 ISAKMP transaction, to authenticate the identity of a host, but nothing specifically for prefixes, so that would have to be arranged somehow. Another alternative is to use a certificate, for example, an identity certificate containing the new PKIX IP address range extension with the prefixes the mobile router is authorized to route. See draft-ietf-pkix-x509-ipaddr-as-extn-03.txt. SEND is using this extension to allow an access router to identify the prefixes it is allowed to route, and SBGP is using it to allow border routers to identify what address ranges they have been assigned by IANA. > I believe that this mode somehow extends the fact that in MIPv6, the > Home Address that is registered is the SA end point, which is already > implicitly an authorization model (the Home Address being registered is > not part of the mobility header anymore that the prefix is present in > explicit prefix length case). So in my view, there's value to the > explicit prefix length option. Also, it does not cost much to implement. > We could suggest that the implicit authorization model applies to > explicit prefix length only, making the 2 paths in the explicit support > code different. > There's an issue in MIPv6 with authorization as well, but because the host is required to have an IPsec SA with the HA, it's not as critical, since the host must prove its identity to either set that up (if its dynamic) or to use it (if its static). If the home address is dynamically assigned, however, there is a problem. This is part of the bootstrapping work item that is in the new MIP6 charter. jak From nemo-admin@ietf.org Tue Nov 25 04:00:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09146 for ; Tue, 25 Nov 2003 04:00: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 1AOZ3C-0004q3-QV; Tue, 25 Nov 2003 04: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 1AOZ2f-0004of-VI for nemo@optimus.ietf.org; Tue, 25 Nov 2003 03:59: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 DAA09082 for ; Tue, 25 Nov 2003 03:59:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOZ2d-0000S9-00 for nemo@ietf.org; Tue, 25 Nov 2003 03:59:27 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AOZ2c-0000Re-00 for nemo@ietf.org; Tue, 25 Nov 2003 03:59:26 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Nov 2003 09:56:19 +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 hAP8wiNx011827; Tue, 25 Nov 2003 09:58:45 +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, 25 Nov 2003 08:58:56 +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, 25 Nov 2003 08:58:55 -0000 Message-ID: Thread-Topic: Explicit Prefix Length Option Thread-Index: AcOysYZ6GSeCZOvYS0WIXao8BSzDFwAf89mQ From: "Pascal Thubert (pthubert)" To: "James Kempf" Cc: X-OriginalArrivalTime: 25 Nov 2003 08:58:56.0225 (UTC) FILETIME=[5B8D9D10:01C3B332] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Explicit Prefix Length Option Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org 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: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: lundi 24 novembre 2003 18:37 > To: Pascal Thubert (pthubert) > Cc: nemo@ietf.org > Subject: Re: Explicit Prefix Length Option >=20 >=20 > > On the other hand, the explicit prefix length is a simple thing. My view > > is that it could be useful to provide a simple deployment model. In that > > model, there's an implicit authorization for a mobile router to register > > for a given, length configurable, prefix around its home address (iff > > there exists an SA with its Home Agent). This limited use case allows > > for a very simple configuration and in particular a virtual Home Network > > and no specific authorization checking. > > >=20 > I don't believe this is acceptible from a mobile service provider deployment > standpoint. There needs to be some way for the home network to authenticate > the identity of the mobile router to assure that the mobile router is > authorized to register the prefixes. >=20 It's not what I meant. See below: > IKEv2 provides a way to use legacy authentication methods within the Phase 1 > ISAKMP transaction, to authenticate the identity of a host, but nothing > specifically for prefixes, so that would have to be arranged somehow. > Another alternative is to use a certificate, for example, an identity > certificate containing the new PKIX IP address range extension with the > prefixes the mobile router is authorized to route. See > draft-ietf-pkix-x509-ipaddr-as-extn-03.txt. SEND is using this extension to > allow an access router to identify the prefixes it is allowed to route, and > SBGP is using it to allow border routers to identify what address ranges > they have been assigned by IANA. >=20 > > I believe that this mode somehow extends the fact that in MIPv6, the > > Home Address that is registered is the SA end point, which is already > > implicitly an authorization model (the Home Address being registered is > > not part of the mobility header anymore that the prefix is present in > > explicit prefix length case). So in my view, there's value to the > > explicit prefix length option. Also, it does not cost much to implement. > > We could suggest that the implicit authorization model applies to > > explicit prefix length only, making the 2 paths in the explicit support > > code different. > > >=20 > There's an issue in MIPv6 with authorization as well, but because the host > is required to have an IPsec SA with the HA, it's not as critical, since the > host must prove its identity to either set that up (if its dynamic) or to > use it (if its static). If the home address is dynamically assigned, > however, there is a problem. This is part of the bootstrapping work item > that is in the new MIP6 charter. >=20 This is what I was trying to say. Keep the MIPv6 model, and implicitly extend that authorization to a given prefix length around the static home address. You can configure that HA to accept the registration for a prefix around the home address, provided that the MR has proven its identity (the MIPv6 way), and with a minimum configured prefix length. The explicit prefix extends the implicit authorization in MIPv6. Pascal=20 From exim@www1.ietf.org Tue Nov 25 04:00:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09161 for ; Tue, 25 Nov 2003 04: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 1AOZ3P-0004s0-7L for nemo-archive@odin.ietf.org; Tue, 25 Nov 2003 04:00:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP90FtZ018720 for nemo-archive@odin.ietf.org; Tue, 25 Nov 2003 04:00:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZ3O-0004rr-Jt for nemo-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 04:00: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 EAA09132 for ; Tue, 25 Nov 2003 04:00:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOZ3L-0000Sf-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 04:00:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOZ3L-0000Sc-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 04:00:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZ3C-0004q3-QV; Tue, 25 Nov 2003 04: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 1AOZ2f-0004of-VI for nemo@optimus.ietf.org; Tue, 25 Nov 2003 03:59: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 DAA09082 for ; Tue, 25 Nov 2003 03:59:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOZ2d-0000S9-00 for nemo@ietf.org; Tue, 25 Nov 2003 03:59:27 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AOZ2c-0000Re-00 for nemo@ietf.org; Tue, 25 Nov 2003 03:59:26 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Nov 2003 09:56:19 +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 hAP8wiNx011827; Tue, 25 Nov 2003 09:58:45 +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, 25 Nov 2003 08:58:56 +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, 25 Nov 2003 08:58:55 -0000 Message-ID: Thread-Topic: Explicit Prefix Length Option Thread-Index: AcOysYZ6GSeCZOvYS0WIXao8BSzDFwAf89mQ From: "Pascal Thubert (pthubert)" To: "James Kempf" Cc: X-OriginalArrivalTime: 25 Nov 2003 08:58:56.0225 (UTC) FILETIME=[5B8D9D10:01C3B332] Content-Transfer-Encoding: quoted-printable Subject: [nemo] RE: Explicit Prefix Length Option Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org 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: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: lundi 24 novembre 2003 18:37 > To: Pascal Thubert (pthubert) > Cc: nemo@ietf.org > Subject: Re: Explicit Prefix Length Option >=20 >=20 > > On the other hand, the explicit prefix length is a simple thing. My view > > is that it could be useful to provide a simple deployment model. In that > > model, there's an implicit authorization for a mobile router to register > > for a given, length configurable, prefix around its home address (iff > > there exists an SA with its Home Agent). This limited use case allows > > for a very simple configuration and in particular a virtual Home Network > > and no specific authorization checking. > > >=20 > I don't believe this is acceptible from a mobile service provider deployment > standpoint. There needs to be some way for the home network to authenticate > the identity of the mobile router to assure that the mobile router is > authorized to register the prefixes. >=20 It's not what I meant. See below: > IKEv2 provides a way to use legacy authentication methods within the Phase 1 > ISAKMP transaction, to authenticate the identity of a host, but nothing > specifically for prefixes, so that would have to be arranged somehow. > Another alternative is to use a certificate, for example, an identity > certificate containing the new PKIX IP address range extension with the > prefixes the mobile router is authorized to route. See > draft-ietf-pkix-x509-ipaddr-as-extn-03.txt. SEND is using this extension to > allow an access router to identify the prefixes it is allowed to route, and > SBGP is using it to allow border routers to identify what address ranges > they have been assigned by IANA. >=20 > > I believe that this mode somehow extends the fact that in MIPv6, the > > Home Address that is registered is the SA end point, which is already > > implicitly an authorization model (the Home Address being registered is > > not part of the mobility header anymore that the prefix is present in > > explicit prefix length case). So in my view, there's value to the > > explicit prefix length option. Also, it does not cost much to implement. > > We could suggest that the implicit authorization model applies to > > explicit prefix length only, making the 2 paths in the explicit support > > code different. > > >=20 > There's an issue in MIPv6 with authorization as well, but because the host > is required to have an IPsec SA with the HA, it's not as critical, since the > host must prove its identity to either set that up (if its dynamic) or to > use it (if its static). If the home address is dynamically assigned, > however, there is a problem. This is part of the bootstrapping work item > that is in the new MIP6 charter. >=20 This is what I was trying to say. Keep the MIPv6 model, and implicitly extend that authorization to a given prefix length around the static home address. You can configure that HA to accept the registration for a prefix around the home address, provided that the MR has proven its identity (the MIPv6 way), and with a minimum configured prefix length. The explicit prefix extends the implicit authorization in MIPv6. Pascal=20 From nemo-admin@ietf.org Tue Nov 25 06:01:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12349 for ; Tue, 25 Nov 2003 06:01: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 1AOawG-0001Ob-O2; Tue, 25 Nov 2003 06:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOaw6-0001O9-OZ for nemo@optimus.ietf.org; Tue, 25 Nov 2003 06:00: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 GAA12301 for ; Tue, 25 Nov 2003 06:00:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOaw2-0001uj-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:00:47 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AOaw2-0001ue-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:00:46 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hAPB0ESC004511; Tue, 25 Nov 2003 04:00:18 -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 hAPB096u000713; Tue, 25 Nov 2003 05:00:15 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 541832EC95; Tue, 25 Nov 2003 12:00:09 +0100 (CET) Message-ID: <3FC33639.1040800@motorola.com> Date: Tue, 25 Nov 2003 12:00:09 +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: James Kempf , nemo@ietf.org Subject: Re: [nemo] RE: Explicit Prefix Length Option References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > This is what I was trying to say. Keep the MIPv6 model, and > implicitly extend that authorization to a given prefix length around > the static home address. You can configure that HA to accept the > registration for a prefix around the home address, provided that the > MR has proven its identity (the MIPv6 way), and with a minimum > configured prefix length. The explicit prefix extends the implicit > authorization in MIPv6. I think I understand what you're trying to say. Authorize the Home Address as MIPv6 does it, and add a model where the value of the prefix length is authorized too. But, an even _simpler_ method is to to authorize the Home Address as MIPv6 does it, and use the model of the Prefix Table where the prefix itself is authorized too. The Prefix Table is already described in the base nemo spec. > This is what I was trying to say. Keep the MIPv6 model, and > implicitly extend that authorization to a given prefix length around > the static home address. I'm not sure that the current nemo spec has the "extension" you propose. Or I don't understand the "implicitly"(?) Anyways, I'm not saying that that extension of the len authorization you're mentioning above should be described in the basic support either, based on the fact some advantages of the explicit prefix mode len itself (compared to implicit and explicit network modes) are yet to be unveiled, IMHO. Alex From exim@www1.ietf.org Tue Nov 25 06:01:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12364 for ; Tue, 25 Nov 2003 06: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 1AOawW-0001QC-Ok for nemo-archive@odin.ietf.org; Tue, 25 Nov 2003 06:01:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPB1G0V005460 for nemo-archive@odin.ietf.org; Tue, 25 Nov 2003 06:01:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOawW-0001Pz-Gx for nemo-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 06: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 GAA12316 for ; Tue, 25 Nov 2003 06:01:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOawS-0001uw-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 06:01:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOawS-0001us-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 06:01:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOawG-0001Ob-O2; Tue, 25 Nov 2003 06:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOaw6-0001O9-OZ for nemo@optimus.ietf.org; Tue, 25 Nov 2003 06:00: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 GAA12301 for ; Tue, 25 Nov 2003 06:00:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOaw2-0001uj-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:00:47 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AOaw2-0001ue-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:00:46 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hAPB0ESC004511; Tue, 25 Nov 2003 04:00:18 -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 hAPB096u000713; Tue, 25 Nov 2003 05:00:15 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 541832EC95; Tue, 25 Nov 2003 12:00:09 +0100 (CET) Message-ID: <3FC33639.1040800@motorola.com> Date: Tue, 25 Nov 2003 12:00:09 +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: James Kempf , nemo@ietf.org Subject: Re: [nemo] RE: Explicit Prefix Length Option References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > This is what I was trying to say. Keep the MIPv6 model, and > implicitly extend that authorization to a given prefix length around > the static home address. You can configure that HA to accept the > registration for a prefix around the home address, provided that the > MR has proven its identity (the MIPv6 way), and with a minimum > configured prefix length. The explicit prefix extends the implicit > authorization in MIPv6. I think I understand what you're trying to say. Authorize the Home Address as MIPv6 does it, and add a model where the value of the prefix length is authorized too. But, an even _simpler_ method is to to authorize the Home Address as MIPv6 does it, and use the model of the Prefix Table where the prefix itself is authorized too. The Prefix Table is already described in the base nemo spec. > This is what I was trying to say. Keep the MIPv6 model, and > implicitly extend that authorization to a given prefix length around > the static home address. I'm not sure that the current nemo spec has the "extension" you propose. Or I don't understand the "implicitly"(?) Anyways, I'm not saying that that extension of the len authorization you're mentioning above should be described in the basic support either, based on the fact some advantages of the explicit prefix mode len itself (compared to implicit and explicit network modes) are yet to be unveiled, IMHO. Alex From nemo-admin@ietf.org Tue Nov 25 06:23:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13016 for ; Tue, 25 Nov 2003 06:23: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 1AObHZ-0002RD-0v; Tue, 25 Nov 2003 06: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 1AObGr-0002QX-E8 for nemo@optimus.ietf.org; Tue, 25 Nov 2003 06:22: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 GAA12988 for ; Tue, 25 Nov 2003 06:22:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObGn-0002EX-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:22:13 -0500 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 1AObGm-0002ET-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:22:13 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id hAPBM0It025561; Tue, 25 Nov 2003 04:22:02 -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 hAPBLw6u024449; Tue, 25 Nov 2003 05:21:59 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 5F4702EC95; Tue, 25 Nov 2003 12:21:57 +0100 (CET) Message-ID: <3FC33B55.6080907@motorola.com> Date: Tue, 25 Nov 2003 12:21:57 +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: nemo@ietf.org Subject: Re: [nemo] Explicit Prefix Length Option References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > >>-----Original Message----- >>From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] >>Sent: mardi 25 novembre 2003 12:00 >>To: Pascal Thubert (pthubert) >>Cc: James Kempf; nemo@ietf.org >>Subject: Re: [nemo] RE: Explicit Prefix Length Option >> >>Pascal Thubert (pthubert) wrote: >> >>>This is what I was trying to say. Keep the MIPv6 model, and >>>implicitly extend that authorization to a given prefix length around >>> the static home address. You can configure that HA to accept the >>>registration for a prefix around the home address, provided that the >>> MR has proven its identity (the MIPv6 way), and with a minimum >>>configured prefix length. The explicit prefix extends the implicit >>>authorization in MIPv6. >> >>I think I understand what you're trying to say. Authorize the Home >>Address as MIPv6 does it, and add a model where the value of the > > prefix > >>length is authorized too. >> >>But, an even _simpler_ method is to to authorize the Home Address as >>MIPv6 does it, and use the model of the Prefix Table where the prefix >>itself is authorized too. The Prefix Table is already described in > > the > >>base nemo spec. >> >> >>>This is what I was trying to say. Keep the MIPv6 model, and >>>implicitly extend that authorization to a given prefix length around >>> the static home address. >> >>I'm not sure that the current nemo spec has the "extension" you > > propose. > >>Or I don't understand the "implicitly"(?) >> >>Anyways, I'm not saying that that extension of the len authorization >>you're mentioning above should be described in the basic support > > either, > >>based on the fact some advantages of the explicit prefix mode len >>itself (compared to implicit and explicit network modes) are yet to be >>unveiled, IMHO. >> >>Alex > > Agreed: this is for the usage draft So why not moving the prefix len option together with its yet-to-be written authorization entirely in the "usages" draft? Alex From exim@www1.ietf.org Tue Nov 25 06:23:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13031 for ; Tue, 25 Nov 2003 06:23: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 1AObHb-0002SE-Bx for nemo-archive@odin.ietf.org; Tue, 25 Nov 2003 06:23:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPBN3YF009428 for nemo-archive@odin.ietf.org; Tue, 25 Nov 2003 06:23:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObHb-0002Rz-7e for nemo-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 06:23: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 GAA13004 for ; Tue, 25 Nov 2003 06:22:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObHX-0002Ez-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 06:22:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AObHW-0002Ew-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 06:22:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObHZ-0002RD-0v; Tue, 25 Nov 2003 06: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 1AObGr-0002QX-E8 for nemo@optimus.ietf.org; Tue, 25 Nov 2003 06:22: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 GAA12988 for ; Tue, 25 Nov 2003 06:22:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObGn-0002EX-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:22:13 -0500 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 1AObGm-0002ET-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:22:13 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id hAPBM0It025561; Tue, 25 Nov 2003 04:22:02 -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 hAPBLw6u024449; Tue, 25 Nov 2003 05:21:59 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 5F4702EC95; Tue, 25 Nov 2003 12:21:57 +0100 (CET) Message-ID: <3FC33B55.6080907@motorola.com> Date: Tue, 25 Nov 2003 12:21:57 +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: nemo@ietf.org Subject: Re: [nemo] Explicit Prefix Length Option References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > >>-----Original Message----- >>From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] >>Sent: mardi 25 novembre 2003 12:00 >>To: Pascal Thubert (pthubert) >>Cc: James Kempf; nemo@ietf.org >>Subject: Re: [nemo] RE: Explicit Prefix Length Option >> >>Pascal Thubert (pthubert) wrote: >> >>>This is what I was trying to say. Keep the MIPv6 model, and >>>implicitly extend that authorization to a given prefix length around >>> the static home address. You can configure that HA to accept the >>>registration for a prefix around the home address, provided that the >>> MR has proven its identity (the MIPv6 way), and with a minimum >>>configured prefix length. The explicit prefix extends the implicit >>>authorization in MIPv6. >> >>I think I understand what you're trying to say. Authorize the Home >>Address as MIPv6 does it, and add a model where the value of the > > prefix > >>length is authorized too. >> >>But, an even _simpler_ method is to to authorize the Home Address as >>MIPv6 does it, and use the model of the Prefix Table where the prefix >>itself is authorized too. The Prefix Table is already described in > > the > >>base nemo spec. >> >> >>>This is what I was trying to say. Keep the MIPv6 model, and >>>implicitly extend that authorization to a given prefix length around >>> the static home address. >> >>I'm not sure that the current nemo spec has the "extension" you > > propose. > >>Or I don't understand the "implicitly"(?) >> >>Anyways, I'm not saying that that extension of the len authorization >>you're mentioning above should be described in the basic support > > either, > >>based on the fact some advantages of the explicit prefix mode len >>itself (compared to implicit and explicit network modes) are yet to be >>unveiled, IMHO. >> >>Alex > > Agreed: this is for the usage draft So why not moving the prefix len option together with its yet-to-be written authorization entirely in the "usages" draft? Alex From nemo-admin@ietf.org Tue Nov 25 06:40:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13653 for ; Tue, 25 Nov 2003 06:40: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 1AObY4-0003LU-D1; Tue, 25 Nov 2003 06:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObNP-0002fH-22 for nemo@optimus.ietf.org; Tue, 25 Nov 2003 06: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 GAA13206 for ; Tue, 25 Nov 2003 06:28:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObNK-0002JZ-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:28:59 -0500 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1AObNK-0002JQ-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:28:58 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate.mot.com (Motorola/Motgate) with ESMTP id hAPBSpZx029729; Tue, 25 Nov 2003 04:28:51 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hAPBSjXM031425; Tue, 25 Nov 2003 05:28:45 -0600 Received: from motorola.com (zfr01-0046.crm.mot.com [10.161.201.147]) by thorgal.crm.mot.com (Postfix) with ESMTP id 69AFD2EC95; Tue, 25 Nov 2003 12:28:44 +0100 (CET) Message-ID: <3FC33CEC.E57D3A2E@motorola.com> Date: Tue, 25 Nov 2003 12:28:44 +0100 From: Alexis Olivereau Organization: MOTOROLA LABS X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pascal Thubert Cc: "nemo@ietf.org" Subject: Re: [nemo] RE: Explicit Prefix Length Option References: <3FC33639.1040800@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Pascal Thubert (pthubert) wrote: > This is what I was trying to say. Keep the MIPv6 model, and > implicitly extend that authorization to a given prefix length around > the static home address. You can configure that HA to accept the > registration for a prefix around the home address, provided that the > MR has proven its identity (the MIPv6 way), and with a minimum > configured prefix length. The explicit prefix extends the implicit > authorization in MIPv6. > > This is what I was trying to say. Keep the MIPv6 model, and > implicitly extend that authorization to a given prefix length around > the static home address. I am not sure I understand what you are proposing here. Do you mean that a Mobile Router would be able to claim the ownership of any prefix above a certain length, provided that the prefix is based on its home address? Then I could imagine cases where two Mobile Routers could legitimately claim the ownership of the same prefix... Or we need to add more constraints on how the MRs' home addresses are assigned. From exim@www1.ietf.org Tue Nov 25 06:40:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13690 for ; Tue, 25 Nov 2003 06:40: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 1AObYe-0003Qk-NV for nemo-archive@odin.ietf.org; Tue, 25 Nov 2003 06:40:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPBeela013186 for nemo-archive@odin.ietf.org; Tue, 25 Nov 2003 06:40:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObYe-0003Qb-HN for nemo-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 06:40:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13673 for ; Tue, 25 Nov 2003 06:40:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObYa-0002Uq-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 06:40:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AObYa-0002UF-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 06:40:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObY4-0003LU-D1; Tue, 25 Nov 2003 06:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObNP-0002fH-22 for nemo@optimus.ietf.org; Tue, 25 Nov 2003 06: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 GAA13206 for ; Tue, 25 Nov 2003 06:28:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObNK-0002JZ-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:28:59 -0500 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1AObNK-0002JQ-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:28:58 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate.mot.com (Motorola/Motgate) with ESMTP id hAPBSpZx029729; Tue, 25 Nov 2003 04:28:51 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id hAPBSjXM031425; Tue, 25 Nov 2003 05:28:45 -0600 Received: from motorola.com (zfr01-0046.crm.mot.com [10.161.201.147]) by thorgal.crm.mot.com (Postfix) with ESMTP id 69AFD2EC95; Tue, 25 Nov 2003 12:28:44 +0100 (CET) Message-ID: <3FC33CEC.E57D3A2E@motorola.com> Date: Tue, 25 Nov 2003 12:28:44 +0100 From: Alexis Olivereau Organization: MOTOROLA LABS X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pascal Thubert Cc: "nemo@ietf.org" Subject: Re: [nemo] RE: Explicit Prefix Length Option References: <3FC33639.1040800@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Pascal Thubert (pthubert) wrote: > This is what I was trying to say. Keep the MIPv6 model, and > implicitly extend that authorization to a given prefix length around > the static home address. You can configure that HA to accept the > registration for a prefix around the home address, provided that the > MR has proven its identity (the MIPv6 way), and with a minimum > configured prefix length. The explicit prefix extends the implicit > authorization in MIPv6. > > This is what I was trying to say. Keep the MIPv6 model, and > implicitly extend that authorization to a given prefix length around > the static home address. I am not sure I understand what you are proposing here. Do you mean that a Mobile Router would be able to claim the ownership of any prefix above a certain length, provided that the prefix is based on its home address? Then I could imagine cases where two Mobile Routers could legitimately claim the ownership of the same prefix... Or we need to add more constraints on how the MRs' home addresses are assigned. From nemo-admin@ietf.org Tue Nov 25 06:42:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13746 for ; Tue, 25 Nov 2003 06:42: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 1AObZy-0003SS-9c; Tue, 25 Nov 2003 06:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObZh-0003Rz-6r for nemo@optimus.ietf.org; Tue, 25 Nov 2003 06:41: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 GAA13722 for ; Tue, 25 Nov 2003 06:41:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObZd-0002Vy-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:41:41 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AObZc-0002Va-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:41:40 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Nov 2003 12:38: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 hAPBevSg000102; Tue, 25 Nov 2003 12:40:59 +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, 25 Nov 2003 11:41:09 +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: Explicit Prefix Length Option Date: Tue, 25 Nov 2003 11:41:08 -0000 Message-ID: Thread-Topic: [nemo] RE: Explicit Prefix Length Option Thread-Index: AcOzR2/RULymXCNHT66LWA80vIndUgAAPLpA From: "Pascal Thubert (pthubert)" To: "Alexis Olivereau" Cc: X-OriginalArrivalTime: 25 Nov 2003 11:41:09.0796 (UTC) FILETIME=[0536AE40:01C3B349] 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: Alexis Olivereau [mailto:Alexis@motorola.com] > Sent: mardi 25 novembre 2003 12:29 > To: Pascal Thubert (pthubert) > Cc: nemo@ietf.org > Subject: Re: [nemo] RE: Explicit Prefix Length Option >=20 > > Pascal Thubert (pthubert) wrote: > > This is what I was trying to say. Keep the MIPv6 model, and > > implicitly extend that authorization to a given prefix length around > > the static home address. You can configure that HA to accept the > > registration for a prefix around the home address, provided that the > > MR has proven its identity (the MIPv6 way), and with a minimum > > configured prefix length. The explicit prefix extends the implicit > > authorization in MIPv6. > > > > This is what I was trying to say. Keep the MIPv6 model, and > > implicitly extend that authorization to a given prefix length around > > the static home address. >=20 > I am not sure I understand what you are proposing here. Do you mean that > a Mobile Router would be able to claim the ownership of any prefix above > a certain length, provided that the prefix is based on its home address? > Then I could imagine cases where two Mobile Routers could legitimately > claim the ownership of the same prefix... Or we need to add more > constraints on how the MRs' home addresses are assigned. This is entering the multihomeing discussion. In that case, yes, that would be possible. We do not have a test to check that multiple registration of a given MNP lead to a unique mobile link. With basic, we assume that the configuration is correct and that the authorization checks that there is no abuse. Pascal From exim@www1.ietf.org Tue Nov 25 06:42:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13761 for ; Tue, 25 Nov 2003 06:42: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 1AObZz-0003Up-Nz for nemo-archive@odin.ietf.org; Tue, 25 Nov 2003 06:42:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPBg3gp013433 for nemo-archive@odin.ietf.org; Tue, 25 Nov 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 1AObZz-0003Ua-Jq for nemo-web-archive@optimus.ietf.org; Tue, 25 Nov 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 GAA13735 for ; Tue, 25 Nov 2003 06:41:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObZv-0002WD-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 06:41:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AObZu-0002W6-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 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 1AObZy-0003SS-9c; Tue, 25 Nov 2003 06:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObZh-0003Rz-6r for nemo@optimus.ietf.org; Tue, 25 Nov 2003 06:41: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 GAA13722 for ; Tue, 25 Nov 2003 06:41:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObZd-0002Vy-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:41:41 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AObZc-0002Va-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:41:40 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Nov 2003 12:38: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 hAPBevSg000102; Tue, 25 Nov 2003 12:40:59 +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, 25 Nov 2003 11:41:09 +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: Explicit Prefix Length Option Date: Tue, 25 Nov 2003 11:41:08 -0000 Message-ID: Thread-Topic: [nemo] RE: Explicit Prefix Length Option Thread-Index: AcOzR2/RULymXCNHT66LWA80vIndUgAAPLpA From: "Pascal Thubert (pthubert)" To: "Alexis Olivereau" Cc: X-OriginalArrivalTime: 25 Nov 2003 11:41:09.0796 (UTC) FILETIME=[0536AE40:01C3B349] 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: Alexis Olivereau [mailto:Alexis@motorola.com] > Sent: mardi 25 novembre 2003 12:29 > To: Pascal Thubert (pthubert) > Cc: nemo@ietf.org > Subject: Re: [nemo] RE: Explicit Prefix Length Option >=20 > > Pascal Thubert (pthubert) wrote: > > This is what I was trying to say. Keep the MIPv6 model, and > > implicitly extend that authorization to a given prefix length around > > the static home address. You can configure that HA to accept the > > registration for a prefix around the home address, provided that the > > MR has proven its identity (the MIPv6 way), and with a minimum > > configured prefix length. The explicit prefix extends the implicit > > authorization in MIPv6. > > > > This is what I was trying to say. Keep the MIPv6 model, and > > implicitly extend that authorization to a given prefix length around > > the static home address. >=20 > I am not sure I understand what you are proposing here. Do you mean that > a Mobile Router would be able to claim the ownership of any prefix above > a certain length, provided that the prefix is based on its home address? > Then I could imagine cases where two Mobile Routers could legitimately > claim the ownership of the same prefix... Or we need to add more > constraints on how the MRs' home addresses are assigned. This is entering the multihomeing discussion. In that case, yes, that would be possible. We do not have a test to check that multiple registration of a given MNP lead to a unique mobile link. With basic, we assume that the configuration is correct and that the authorization checks that there is no abuse. Pascal From nemo-admin@ietf.org Tue Nov 25 06:46:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13917 for ; Tue, 25 Nov 2003 06:46: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 1AObdp-0003bS-OW; Tue, 25 Nov 2003 06:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObcw-0003ai-LU for nemo@optimus.ietf.org; Tue, 25 Nov 2003 06:45: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 GAA13831 for ; Tue, 25 Nov 2003 06:44:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObcs-0002ZL-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:45:02 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AObcr-0002Yu-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:45:02 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Nov 2003 12:41:54 +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 hAPBi5G1000828; Tue, 25 Nov 2003 12:44:20 +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, 25 Nov 2003 11:44: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Explicit Prefix Length Option Date: Tue, 25 Nov 2003 11:44:16 -0000 Message-ID: Thread-Topic: [nemo] Explicit Prefix Length Option Thread-Index: AcOzRnPFnkn02Z1EQgO6Gnlsn4+nYAAAkISQ From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" Cc: X-OriginalArrivalTime: 25 Nov 2003 11:44:17.0682 (UTC) FILETIME=[7533CF20:01C3B349] 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: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: mardi 25 novembre 2003 12:22 > To: Pascal Thubert (pthubert) > Cc: nemo@ietf.org > Subject: Re: [nemo] Explicit Prefix Length Option >=20 > Pascal Thubert (pthubert) wrote: > > > >>-----Original Message----- > >>From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > >>Sent: mardi 25 novembre 2003 12:00 > >>To: Pascal Thubert (pthubert) > >>Cc: James Kempf; nemo@ietf.org > >>Subject: Re: [nemo] RE: Explicit Prefix Length Option > >> > >>Pascal Thubert (pthubert) wrote: > >> > >>>This is what I was trying to say. Keep the MIPv6 model, and > >>>implicitly extend that authorization to a given prefix length around > >>> the static home address. You can configure that HA to accept the > >>>registration for a prefix around the home address, provided that the > >>> MR has proven its identity (the MIPv6 way), and with a minimum > >>>configured prefix length. The explicit prefix extends the implicit > >>>authorization in MIPv6. > >> > >>I think I understand what you're trying to say. Authorize the Home > >>Address as MIPv6 does it, and add a model where the value of the > > > > prefix > > > >>length is authorized too. > >> > >>But, an even _simpler_ method is to to authorize the Home Address as > >>MIPv6 does it, and use the model of the Prefix Table where the prefix > >>itself is authorized too. The Prefix Table is already described in > > > > the > > > >>base nemo spec. > >> > >> > >>>This is what I was trying to say. Keep the MIPv6 model, and > >>>implicitly extend that authorization to a given prefix length around > >>> the static home address. > >> > >>I'm not sure that the current nemo spec has the "extension" you > > > > propose. > > > >>Or I don't understand the "implicitly"(?) > >> > >>Anyways, I'm not saying that that extension of the len authorization > >>you're mentioning above should be described in the basic support > > > > either, > > > >>based on the fact some advantages of the explicit prefix mode len > >>itself (compared to implicit and explicit network modes) are yet to be > >>unveiled, IMHO. > >> > >>Alex > > > > Agreed: this is for the usage draft >=20 > So why not moving the prefix len option together with its yet-to-be > written authorization entirely in the "usages" draft? >=20 "Usages" is not normative. If we need to standardize something, it's not the right place.=20 Pascal From exim@www1.ietf.org Tue Nov 25 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 GAA13932 for ; Tue, 25 Nov 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 1AObdr-0003ck-6Y for nemo-archive@odin.ietf.org; Tue, 25 Nov 2003 06:46:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPBk3G0013924 for nemo-archive@odin.ietf.org; Tue, 25 Nov 2003 06:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObdq-0003cV-V9 for nemo-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 06:46: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 GAA13874 for ; Tue, 25 Nov 2003 06:45:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObdm-0002aT-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 06:45:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AObdm-0002aP-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 06:45:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObdp-0003bS-OW; Tue, 25 Nov 2003 06:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObcw-0003ai-LU for nemo@optimus.ietf.org; Tue, 25 Nov 2003 06:45: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 GAA13831 for ; Tue, 25 Nov 2003 06:44:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObcs-0002ZL-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:45:02 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AObcr-0002Yu-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:45:02 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Nov 2003 12:41:54 +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 hAPBi5G1000828; Tue, 25 Nov 2003 12:44:20 +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, 25 Nov 2003 11:44: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Explicit Prefix Length Option Date: Tue, 25 Nov 2003 11:44:16 -0000 Message-ID: Thread-Topic: [nemo] Explicit Prefix Length Option Thread-Index: AcOzRnPFnkn02Z1EQgO6Gnlsn4+nYAAAkISQ From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" Cc: X-OriginalArrivalTime: 25 Nov 2003 11:44:17.0682 (UTC) FILETIME=[7533CF20:01C3B349] 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: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: mardi 25 novembre 2003 12:22 > To: Pascal Thubert (pthubert) > Cc: nemo@ietf.org > Subject: Re: [nemo] Explicit Prefix Length Option >=20 > Pascal Thubert (pthubert) wrote: > > > >>-----Original Message----- > >>From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > >>Sent: mardi 25 novembre 2003 12:00 > >>To: Pascal Thubert (pthubert) > >>Cc: James Kempf; nemo@ietf.org > >>Subject: Re: [nemo] RE: Explicit Prefix Length Option > >> > >>Pascal Thubert (pthubert) wrote: > >> > >>>This is what I was trying to say. Keep the MIPv6 model, and > >>>implicitly extend that authorization to a given prefix length around > >>> the static home address. You can configure that HA to accept the > >>>registration for a prefix around the home address, provided that the > >>> MR has proven its identity (the MIPv6 way), and with a minimum > >>>configured prefix length. The explicit prefix extends the implicit > >>>authorization in MIPv6. > >> > >>I think I understand what you're trying to say. Authorize the Home > >>Address as MIPv6 does it, and add a model where the value of the > > > > prefix > > > >>length is authorized too. > >> > >>But, an even _simpler_ method is to to authorize the Home Address as > >>MIPv6 does it, and use the model of the Prefix Table where the prefix > >>itself is authorized too. The Prefix Table is already described in > > > > the > > > >>base nemo spec. > >> > >> > >>>This is what I was trying to say. Keep the MIPv6 model, and > >>>implicitly extend that authorization to a given prefix length around > >>> the static home address. > >> > >>I'm not sure that the current nemo spec has the "extension" you > > > > propose. > > > >>Or I don't understand the "implicitly"(?) > >> > >>Anyways, I'm not saying that that extension of the len authorization > >>you're mentioning above should be described in the basic support > > > > either, > > > >>based on the fact some advantages of the explicit prefix mode len > >>itself (compared to implicit and explicit network modes) are yet to be > >>unveiled, IMHO. > >> > >>Alex > > > > Agreed: this is for the usage draft >=20 > So why not moving the prefix len option together with its yet-to-be > written authorization entirely in the "usages" draft? >=20 "Usages" is not normative. If we need to standardize something, it's not the right place.=20 Pascal From nemo-admin@ietf.org Tue Nov 25 06:55:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14242 for ; Tue, 25 Nov 2003 06:55: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 1AObmY-00043g-KV; Tue, 25 Nov 2003 06:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObm0-00042z-Vs for nemo@optimus.ietf.org; Tue, 25 Nov 2003 06:54: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 GAA14193 for ; Tue, 25 Nov 2003 06:54:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOblw-0002o2-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:54:24 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AOblv-0002nz-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:54:24 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id hAPBs86b025888; Tue, 25 Nov 2003 04:54:08 -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 hAPBrw6u021255; Tue, 25 Nov 2003 05:53:59 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 2AEA82EC95; Tue, 25 Nov 2003 12:53:58 +0100 (CET) Message-ID: <3FC342D6.6010904@motorola.com> Date: Tue, 25 Nov 2003 12:53:58 +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: Alexandru Petrescu , nemo@ietf.org Subject: Re: [nemo] Explicit Prefix Length Option References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >>> Agreed: this is for the usage draft >> >> So why not moving the prefix len option together with its yet-to-be >> written authorization entirely in the "usages" draft? >> > "Usages" is not normative. If we need to standardize something, it's > not the right place. Yes, combine this with: if we need to standardize something it should be advantageous, secure and straightforward implementation. The only advantage of explicit prefix len mode up to now is savings in bit-space in the BU messages. Please analyze these savings for us. With respect to security: it is in no way more secure to use the prefix len mode rather than the implicit or the explicit network modes. It is less secure, see Alexis' post. Straightforward implementation: there is an implementation of the explicit prefix len mode. It is not straightforward in that it poses limits in the ways the Home Addresses are assigned to several mobile routers of same HA such that MNP's don't overlap. It is even less straightforward in that it requires an implementer to read the "usages" draft too. Alex From exim@www1.ietf.org Tue Nov 25 06:55:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14257 for ; Tue, 25 Nov 2003 06:55: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 1AObma-00044v-50 for nemo-archive@odin.ietf.org; Tue, 25 Nov 2003 06:55:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPBt3PW015667 for nemo-archive@odin.ietf.org; Tue, 25 Nov 2003 06: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 1AObmZ-00044b-SK for nemo-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 06:55: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 GAA14207 for ; Tue, 25 Nov 2003 06:54:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObmV-0002om-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 06:54:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AObmV-0002oj-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 06:54:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObmY-00043g-KV; Tue, 25 Nov 2003 06:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObm0-00042z-Vs for nemo@optimus.ietf.org; Tue, 25 Nov 2003 06:54: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 GAA14193 for ; Tue, 25 Nov 2003 06:54:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOblw-0002o2-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:54:24 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AOblv-0002nz-00 for nemo@ietf.org; Tue, 25 Nov 2003 06:54:24 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id hAPBs86b025888; Tue, 25 Nov 2003 04:54:08 -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 hAPBrw6u021255; Tue, 25 Nov 2003 05:53:59 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 2AEA82EC95; Tue, 25 Nov 2003 12:53:58 +0100 (CET) Message-ID: <3FC342D6.6010904@motorola.com> Date: Tue, 25 Nov 2003 12:53:58 +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: Alexandru Petrescu , nemo@ietf.org Subject: Re: [nemo] Explicit Prefix Length Option References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >>> Agreed: this is for the usage draft >> >> So why not moving the prefix len option together with its yet-to-be >> written authorization entirely in the "usages" draft? >> > "Usages" is not normative. If we need to standardize something, it's > not the right place. Yes, combine this with: if we need to standardize something it should be advantageous, secure and straightforward implementation. The only advantage of explicit prefix len mode up to now is savings in bit-space in the BU messages. Please analyze these savings for us. With respect to security: it is in no way more secure to use the prefix len mode rather than the implicit or the explicit network modes. It is less secure, see Alexis' post. Straightforward implementation: there is an implementation of the explicit prefix len mode. It is not straightforward in that it poses limits in the ways the Home Addresses are assigned to several mobile routers of same HA such that MNP's don't overlap. It is even less straightforward in that it requires an implementer to read the "usages" draft too. Alex From nemo-admin@ietf.org Tue Nov 25 08:22:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16673 for ; Tue, 25 Nov 2003 08:22: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 1AOd8i-0007v2-QH; Tue, 25 Nov 2003 08:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOd8K-0007uI-9k for nemo@optimus.ietf.org; Tue, 25 Nov 2003 08:21: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 IAA16636 for ; Tue, 25 Nov 2003 08:21:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOd8J-0004jk-00 for nemo@ietf.org; Tue, 25 Nov 2003 08:21:35 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AOd8I-0004ir-00 for nemo@ietf.org; Tue, 25 Nov 2003 08:21:34 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Nov 2003 14:18:25 +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 hAPDKo5s026690; Tue, 25 Nov 2003 14:20:51 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 25 Nov 2003 13:21:02 +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] Explicit Prefix Length Option Date: Tue, 25 Nov 2003 13:21:01 -0000 Message-ID: Thread-Topic: [nemo] Explicit Prefix Length Option Thread-Index: AcOzSupdxuXCQCaQS6GZvScQPnMy6AACs8Wg From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" Cc: X-OriginalArrivalTime: 25 Nov 2003 13:21:02.0253 (UTC) FILETIME=[F8FF0DD0:01C3B356] 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: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: mardi 25 novembre 2003 12:54 > To: Pascal Thubert (pthubert) > Cc: Alexandru Petrescu; nemo@ietf.org > Subject: Re: [nemo] Explicit Prefix Length Option >=20 > Pascal Thubert (pthubert) wrote: > >>> Agreed: this is for the usage draft > >> > >> So why not moving the prefix len option together with its yet-to-be > >> written authorization entirely in the "usages" draft? > >> > > "Usages" is not normative. If we need to standardize something, it's > > not the right place. >=20 > Yes, combine this with: if we need to standardize something it should be > advantageous, secure and straightforward implementation. >=20 Changing subject are you?=20 > The only advantage of explicit prefix len mode up to now is savings in > bit-space in the BU messages. Please analyze these savings for us. >=20 I was arguing the opposite. I was arguing that it can be used in a simple implicit authorization model, based on an adapted config/policy at the HA. > With respect to security: it is in no way more secure to use the prefix > len mode rather than the implicit or the explicit network modes. It is > less secure, see Alexis' post. >=20 I answered that but you assertion was certainly not my conclusion > Straightforward implementation: there is an implementation of the > explicit prefix len mode. It is not straightforward in that it poses > limits in the ways the Home Addresses are assigned to several mobile > routers of same HA such that MNP's don't overlap. It is even less > straightforward in that it requires an implementer to read the "usages" > draft too. ??? When mobile networks are not multihomed then obviously MNPs do not overlap. Seems you're confusing things up here. Pascal From exim@www1.ietf.org Tue Nov 25 08:22:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16688 for ; Tue, 25 Nov 2003 08:22: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 1AOd8s-0007w3-Sn for nemo-archive@odin.ietf.org; Tue, 25 Nov 2003 08:22:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPDMAVn030502 for nemo-archive@odin.ietf.org; Tue, 25 Nov 2003 08:22:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOd8s-0007vt-Nq for nemo-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 08:22: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 IAA16652 for ; Tue, 25 Nov 2003 08:21:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOd8r-0004kn-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 08:22:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOd8r-0004kg-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 08:22:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOd8i-0007v2-QH; Tue, 25 Nov 2003 08:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOd8K-0007uI-9k for nemo@optimus.ietf.org; Tue, 25 Nov 2003 08:21: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 IAA16636 for ; Tue, 25 Nov 2003 08:21:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOd8J-0004jk-00 for nemo@ietf.org; Tue, 25 Nov 2003 08:21:35 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AOd8I-0004ir-00 for nemo@ietf.org; Tue, 25 Nov 2003 08:21:34 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 25 Nov 2003 14:18:25 +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 hAPDKo5s026690; Tue, 25 Nov 2003 14:20:51 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 25 Nov 2003 13:21:02 +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] Explicit Prefix Length Option Date: Tue, 25 Nov 2003 13:21:01 -0000 Message-ID: Thread-Topic: [nemo] Explicit Prefix Length Option Thread-Index: AcOzSupdxuXCQCaQS6GZvScQPnMy6AACs8Wg From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" Cc: X-OriginalArrivalTime: 25 Nov 2003 13:21:02.0253 (UTC) FILETIME=[F8FF0DD0:01C3B356] 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: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: mardi 25 novembre 2003 12:54 > To: Pascal Thubert (pthubert) > Cc: Alexandru Petrescu; nemo@ietf.org > Subject: Re: [nemo] Explicit Prefix Length Option >=20 > Pascal Thubert (pthubert) wrote: > >>> Agreed: this is for the usage draft > >> > >> So why not moving the prefix len option together with its yet-to-be > >> written authorization entirely in the "usages" draft? > >> > > "Usages" is not normative. If we need to standardize something, it's > > not the right place. >=20 > Yes, combine this with: if we need to standardize something it should be > advantageous, secure and straightforward implementation. >=20 Changing subject are you?=20 > The only advantage of explicit prefix len mode up to now is savings in > bit-space in the BU messages. Please analyze these savings for us. >=20 I was arguing the opposite. I was arguing that it can be used in a simple implicit authorization model, based on an adapted config/policy at the HA. > With respect to security: it is in no way more secure to use the prefix > len mode rather than the implicit or the explicit network modes. It is > less secure, see Alexis' post. >=20 I answered that but you assertion was certainly not my conclusion > Straightforward implementation: there is an implementation of the > explicit prefix len mode. It is not straightforward in that it poses > limits in the ways the Home Addresses are assigned to several mobile > routers of same HA such that MNP's don't overlap. It is even less > straightforward in that it requires an implementer to read the "usages" > draft too. ??? When mobile networks are not multihomed then obviously MNPs do not overlap. Seems you're confusing things up here. Pascal From nemo-admin@ietf.org Tue Nov 25 09:52:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19653 for ; Tue, 25 Nov 2003 09:52: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 1AOeXp-0005YP-Cp; Tue, 25 Nov 2003 09:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOeWz-0005WR-QS for nemo@optimus.ietf.org; Tue, 25 Nov 2003 09:51: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 JAA19562 for ; Tue, 25 Nov 2003 09:50:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOeWx-00067e-00 for nemo@ietf.org; Tue, 25 Nov 2003 09:51:07 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AOeWw-00067a-00 for nemo@ietf.org; Tue, 25 Nov 2003 09:51:07 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hAPEoTSC003937; Tue, 25 Nov 2003 07:50:29 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id hAPEoaku013129; Tue, 25 Nov 2003 08:50:37 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id E06CE2EC95; Tue, 25 Nov 2003 15:50:35 +0100 (CET) Message-ID: <3FC36C3B.4060800@motorola.com> Date: Tue, 25 Nov 2003 15:50:35 +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: Alexandru Petrescu , nemo@ietf.org Subject: Re: [nemo] Explicit Prefix Length Option References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >>> "Usages" is not normative. If we need to standardize something, >>> it's not the right place. >> >> Yes, combine this with: if we need to standardize something it >> should be: advantageous, secure and straightforward implementation. >> > Changing subject are you? Showing that I can deviate as much as you do. What was that "if we need to standardize something"? >> The only advantage of explicit prefix len mode up to now is savings >> in bit-space in the BU messages. Please analyze these savings for >> us. >> > I was arguing the opposite. I was arguing that it can be used in a > simple implicit authorization model, based on an adapted > config/policy at the HA. I was arguing that both the implicit authorization model as well as the adapted config/policy at the HA are all, maybe simple, but surely not yet specified. I was trying to say the the advantages of the explicit prefix len mode are maybe good ideas but surely not yet specified. > ??? When mobile networks are not multihomed then obviously MNPs do > not overlap. Seems you're confusing things up here. I was not thinking multi-homing at all. It's not the MNP's that originally overlap, but the Home Addresses of the MR's might overlap up to a different length than what their BU-prefix-len's say. If these Home Addresses happen to overlap in that way, then there will surely be confusion at HA to deduce the right MNP. So I think you're right: I'm not quite sure in all this conversation, so I'll stop. Alex From exim@www1.ietf.org Tue Nov 25 09:52:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19669 for ; Tue, 25 Nov 2003 09:52: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 1AOeXr-0005ZK-Nc for nemo-archive@odin.ietf.org; Tue, 25 Nov 2003 09:52:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPEq3eQ021407 for nemo-archive@odin.ietf.org; Tue, 25 Nov 2003 09:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOeXr-0005ZC-Ae for nemo-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 09: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 JAA19631 for ; Tue, 25 Nov 2003 09:51:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOeXp-000693-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 09:52:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOeXp-000690-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 09: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 1AOeXp-0005YP-Cp; Tue, 25 Nov 2003 09:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOeWz-0005WR-QS for nemo@optimus.ietf.org; Tue, 25 Nov 2003 09:51: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 JAA19562 for ; Tue, 25 Nov 2003 09:50:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOeWx-00067e-00 for nemo@ietf.org; Tue, 25 Nov 2003 09:51:07 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AOeWw-00067a-00 for nemo@ietf.org; Tue, 25 Nov 2003 09:51:07 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hAPEoTSC003937; Tue, 25 Nov 2003 07:50:29 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id hAPEoaku013129; Tue, 25 Nov 2003 08:50:37 -0600 Received: from motorola.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id E06CE2EC95; Tue, 25 Nov 2003 15:50:35 +0100 (CET) Message-ID: <3FC36C3B.4060800@motorola.com> Date: Tue, 25 Nov 2003 15:50:35 +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: Alexandru Petrescu , nemo@ietf.org Subject: Re: [nemo] Explicit Prefix Length Option References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >>> "Usages" is not normative. If we need to standardize something, >>> it's not the right place. >> >> Yes, combine this with: if we need to standardize something it >> should be: advantageous, secure and straightforward implementation. >> > Changing subject are you? Showing that I can deviate as much as you do. What was that "if we need to standardize something"? >> The only advantage of explicit prefix len mode up to now is savings >> in bit-space in the BU messages. Please analyze these savings for >> us. >> > I was arguing the opposite. I was arguing that it can be used in a > simple implicit authorization model, based on an adapted > config/policy at the HA. I was arguing that both the implicit authorization model as well as the adapted config/policy at the HA are all, maybe simple, but surely not yet specified. I was trying to say the the advantages of the explicit prefix len mode are maybe good ideas but surely not yet specified. > ??? When mobile networks are not multihomed then obviously MNPs do > not overlap. Seems you're confusing things up here. I was not thinking multi-homing at all. It's not the MNP's that originally overlap, but the Home Addresses of the MR's might overlap up to a different length than what their BU-prefix-len's say. If these Home Addresses happen to overlap in that way, then there will surely be confusion at HA to deduce the right MNP. So I think you're right: I'm not quite sure in all this conversation, so I'll stop. Alex From nemo-admin@ietf.org Tue Nov 25 11:52:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26726 for ; Tue, 25 Nov 2003 11:52: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 1AOgPx-0007gu-HP; Tue, 25 Nov 2003 11:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgP4-0007fK-Pw for nemo@optimus.ietf.org; Tue, 25 Nov 2003 11:51: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 LAA26667 for ; Tue, 25 Nov 2003 11:50:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgP3-0000si-00 for nemo@ietf.org; Tue, 25 Nov 2003 11:51:05 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AOgP2-0000se-00 for nemo@ietf.org; Tue, 25 Nov 2003 11:51:04 -0500 Message-ID: <00a201c3b374$22b52160$956015ac@dclkempt40> From: "James Kempf" To: "Pascal Thubert \(pthubert\)" Cc: References: Date: Tue, 25 Nov 2003 08:49:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Explicit Prefix Length Option Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > This is what I was trying to say. Keep the MIPv6 model, and implicitly > extend that authorization to a given prefix length around the static > home address. You can configure that HA to accept the registration for a > prefix around the home address, provided that the MR has proven its > identity (the MIPv6 way), and with a minimum configured prefix length. > The explicit prefix extends the implicit authorization in MIPv6. > And, as I said in the original email, I don't believe that would be acceptable from a mobile service provider deployment standpoint, since it doesn't rule out a mobile router that isn't authorized to route a particular prefix from claiming that it is. jak From exim@www1.ietf.org Tue Nov 25 11:52:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26744 for ; Tue, 25 Nov 2003 11:52: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 1AOgQ3-0007j4-M9 for nemo-archive@odin.ietf.org; Tue, 25 Nov 2003 11:52:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPGq7bl029692 for nemo-archive@odin.ietf.org; Tue, 25 Nov 2003 11:52:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgQ3-0007il-Db for nemo-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 11:52: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 LAA26716 for ; Tue, 25 Nov 2003 11:51:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgQ2-0000tq-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 11:52:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOgQ1-0000tn-00 for nemo-web-archive@ietf.org; Tue, 25 Nov 2003 11:52:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgPx-0007gu-HP; Tue, 25 Nov 2003 11:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgP4-0007fK-Pw for nemo@optimus.ietf.org; Tue, 25 Nov 2003 11:51: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 LAA26667 for ; Tue, 25 Nov 2003 11:50:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgP3-0000si-00 for nemo@ietf.org; Tue, 25 Nov 2003 11:51:05 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AOgP2-0000se-00 for nemo@ietf.org; Tue, 25 Nov 2003 11:51:04 -0500 Message-ID: <00a201c3b374$22b52160$956015ac@dclkempt40> From: "James Kempf" To: "Pascal Thubert \(pthubert\)" Cc: References: Date: Tue, 25 Nov 2003 08:49:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Explicit Prefix Length Option Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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 > This is what I was trying to say. Keep the MIPv6 model, and implicitly > extend that authorization to a given prefix length around the static > home address. You can configure that HA to accept the registration for a > prefix around the home address, provided that the MR has proven its > identity (the MIPv6 way), and with a minimum configured prefix length. > The explicit prefix extends the implicit authorization in MIPv6. > And, as I said in the original email, I don't believe that would be acceptable from a mobile service provider deployment standpoint, since it doesn't rule out a mobile router that isn't authorized to route a particular prefix from claiming that it is. jak From nemo-admin@ietf.org Tue Nov 25 12:05:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27339 for ; Tue, 25 Nov 2003 12:05: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 1AOgcY-0000ad-D1; Tue, 25 Nov 2003 12:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgbp-0000RU-JY for nemo@optimus.ietf.org; Tue, 25 Nov 2003 12:04: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 MAA27254 for ; Tue, 25 Nov 2003 12:04:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgbo-000172-00 for nemo@ietf.org; Tue, 25 Nov 2003 12:04:16 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AOgbn-00016y-00 for nemo@ietf.org; Tue, 25 Nov 2003 12:04:15 -0500 Message-ID: <00dd01c3b375$fe05e2d0$956015ac@dclkempt40> From: "James Kempf" To: "Pascal Thubert \(pthubert\)" , "Alexis Olivereau" Cc: References: Subject: Re: [nemo] RE: Explicit Prefix Length Option Date: Tue, 25 Nov 2003 09:03:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pascall, I think what Alexis is trying to get at is the following. Suppose there are two mobile routers, both having IPsec SAs with the HA. One has IP address A and the other has IP address B. Router A is allowed to route prefix set X and router B is allowed to route prefix set Y. What prevents router A from sending a BU with Prefix Option having the prefixes in set Y, thereby hijacking B's traffic? This is the point I was trying to get at about service provider deployment security (sorry if I was a bit cryptic). jak ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Alexis Olivereau" Cc: Sent: Tuesday, November 25, 2003 3:41 AM Subject: RE: [nemo] RE: Explicit Prefix Length Option > > > > -----Original Message----- > > From: Alexis Olivereau [mailto:Alexis@motorola.com] > > Sent: mardi 25 novembre 2003 12:29 > > To: Pascal Thubert (pthubert) > > Cc: nemo@ietf.org > > Subject: Re: [nemo] RE: Explicit Prefix Length Option > > > > > Pascal Thubert (pthubert) wrote: > > > This is what I was trying to say. Keep the MIPv6 model, and > > > implicitly extend that authorization to a given prefix length around > > > the static home address. You can configure that HA to accept the > > > registration for a prefix around the home address, provided that the > > > MR has proven its identity (the MIPv6 way), and with a minimum > > > configured prefix length. The explicit prefix extends the implicit > > > authorization in MIPv6. > > > > > > This is what I was trying to say. Keep the MIPv6 model, and > > > implicitly extend that authorization to a given prefix length around > > > the static home address. > > > > I am not sure I understand what you are proposing here. Do you mean > that > > a Mobile Router would be able to claim the ownership of any prefix > above > > a certain length, provided that the prefix is based on its home > address? > > Then I could imagine cases where two Mobile Routers could legitimately > > claim the ownership of the same prefix... Or we need to add more > > constraints on how the MRs' home addresses are assigned. > > This is entering the multihomeing discussion. In that case, yes, that > would be possible. > We do not have a test to check that multiple registration of a given MNP > lead to a unique mobile link. With basic, we assume that the > configuration is correct and that the authorization checks that there is > no abuse. > > Pascal > > > From nemo-admin@ietf.org Wed Nov 26 08:18:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05856 for ; Wed, 26 Nov 2003 08: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 1AOzYP-0001B7-Aq; Wed, 26 Nov 2003 08: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 1AOzYJ-0001Ad-R4 for nemo@optimus.ietf.org; Wed, 26 Nov 2003 08:17: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 IAA05834 for ; Wed, 26 Nov 2003 08:17:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOzYI-0005Lx-00 for nemo@ietf.org; Wed, 26 Nov 2003 08:17:54 -0500 Received: from soleil.uvsq.fr ([193.51.24.1] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AOzYI-0005Lt-00 for nemo@ietf.org; Wed, 26 Nov 2003 08:17:54 -0500 Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) by soleil.uvsq.fr (8.12.8p2/jtpda-5.4) with ESMTP id hAQDHn9B010213 for ; Wed, 26 Nov 2003 14:17:49 +0100 (CET) Received: from perignon (haussman.prism.uvsq.fr [193.51.25.213]) by guillotin.prism.uvsq.fr (8.11.4/jtpda-5.3.2) with SMTP id hAQDHdI17422 for ; Wed, 26 Nov 2003 14:17:39 +0100 (MET) Message-ID: <027301c3b41f$c02b12a0$0201a8c0@perignon> From: "Daniel NEGRU" To: Date: Wed, 26 Nov 2003 14:18:15 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0270_01C3B428.218C24F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Antivirus: scanned by sophie at soleil.uvsq.fr Subject: [nemo] NEMO Multicast Issues Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0270_01C3B428.218C24F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I am a Ph.D student in CNRS-PRISM Laboratory at the University of = Versailles and I'm very interested in Network Mobility, especially = concerning multicast issues on mobile networks. I was wondering if it would be possible for a MR to join to any = multicast groups with its care-of-address when it is in a visited = network. I suppose yes but section 5.7 of the basic support made me have = a doubt. Thanks, Daniel. ------=_NextPart_000_0270_01C3B428.218C24F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I am a Ph.D student in CNRS-PRISM = Laboratory at the=20 University of Versailles and I'm very interested in Network Mobility, = especially=20 concerning multicast issues on mobile networks.
I was wondering if it would = be possible=20 for a MR to join to any multicast groups with its = care-of-address when it=20 is in a visited network. I suppose yes but section 5.7 of the basic = support made=20 me have a doubt.
 
Thanks,
Daniel.
------=_NextPart_000_0270_01C3B428.218C24F0-- From exim@www1.ietf.org Wed Nov 26 08:18:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05886 for ; Wed, 26 Nov 2003 08:18:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOzYY-0001GL-0h for nemo-archive@odin.ietf.org; Wed, 26 Nov 2003 08:18:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQDI9Qh004849 for nemo-archive@odin.ietf.org; Wed, 26 Nov 2003 08:18:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOzYW-0001FO-Ex for nemo-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 08: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 IAA05846 for ; Wed, 26 Nov 2003 08:17:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOzYU-0005MI-00 for nemo-web-archive@ietf.org; Wed, 26 Nov 2003 08:18:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOzYT-0005MD-00 for nemo-web-archive@ietf.org; Wed, 26 Nov 2003 08: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 1AOzYP-0001B7-Aq; Wed, 26 Nov 2003 08: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 1AOzYJ-0001Ad-R4 for nemo@optimus.ietf.org; Wed, 26 Nov 2003 08:17: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 IAA05834 for ; Wed, 26 Nov 2003 08:17:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOzYI-0005Lx-00 for nemo@ietf.org; Wed, 26 Nov 2003 08:17:54 -0500 Received: from soleil.uvsq.fr ([193.51.24.1] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AOzYI-0005Lt-00 for nemo@ietf.org; Wed, 26 Nov 2003 08:17:54 -0500 Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) by soleil.uvsq.fr (8.12.8p2/jtpda-5.4) with ESMTP id hAQDHn9B010213 for ; Wed, 26 Nov 2003 14:17:49 +0100 (CET) Received: from perignon (haussman.prism.uvsq.fr [193.51.25.213]) by guillotin.prism.uvsq.fr (8.11.4/jtpda-5.3.2) with SMTP id hAQDHdI17422 for ; Wed, 26 Nov 2003 14:17:39 +0100 (MET) Message-ID: <027301c3b41f$c02b12a0$0201a8c0@perignon> From: "Daniel NEGRU" To: Date: Wed, 26 Nov 2003 14:18:15 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0270_01C3B428.218C24F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Antivirus: scanned by sophie at soleil.uvsq.fr Subject: [nemo] NEMO Multicast Issues Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0270_01C3B428.218C24F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I am a Ph.D student in CNRS-PRISM Laboratory at the University of = Versailles and I'm very interested in Network Mobility, especially = concerning multicast issues on mobile networks. I was wondering if it would be possible for a MR to join to any = multicast groups with its care-of-address when it is in a visited = network. I suppose yes but section 5.7 of the basic support made me have = a doubt. Thanks, Daniel. ------=_NextPart_000_0270_01C3B428.218C24F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I am a Ph.D student in CNRS-PRISM = Laboratory at the=20 University of Versailles and I'm very interested in Network Mobility, = especially=20 concerning multicast issues on mobile networks.
I was wondering if it would = be possible=20 for a MR to join to any multicast groups with its = care-of-address when it=20 is in a visited network. I suppose yes but section 5.7 of the basic = support made=20 me have a doubt.
 
Thanks,
Daniel.
------=_NextPart_000_0270_01C3B428.218C24F0-- From nemo-admin@ietf.org Wed Nov 26 13:59:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21560 for ; Wed, 26 Nov 2003 13:59: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 1AP4sP-00009h-3Y; Wed, 26 Nov 2003 13: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 1AP4rw-00008O-M7 for nemo@optimus.ietf.org; Wed, 26 Nov 2003 13: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 NAA21542 for ; Wed, 26 Nov 2003 13:58:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP4ru-0002nF-00 for nemo@ietf.org; Wed, 26 Nov 2003 13:58:30 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AP4rt-0002ma-00 for nemo@ietf.org; Wed, 26 Nov 2003 13:58:29 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAQIvo105106; Wed, 26 Nov 2003 10:57:50 -0800 X-mProtect: <200311261857> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdUGDwsJ; Wed, 26 Nov 2003 10:57:49 PST Message-ID: <3FC4F8D4.1040608@iprg.nokia.com> Date: Wed, 26 Nov 2003 11:02:44 -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: Daniel NEGRU CC: nemo@ietf.org Subject: Re: [nemo] NEMO Multicast Issues References: <027301c3b41f$c02b12a0$0201a8c0@perignon> In-Reply-To: <027301c3b41f$c02b12a0$0201a8c0@perignon> 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 Daniel NEGRU wrote: > Hi all, > > I am a Ph.D student in CNRS-PRISM Laboratory at the University of Versailles > and I'm very interested in Network Mobility, especially concerning multicast > issues on mobile networks. > I was wondering if it would be possible for a MR to join to any multicast > groups with its care-of-address when it is in a visited network. I suppose > yes but section 5.7 of the basic support made me have a doubt. section 5.7 only restricts the Mobile Router when it comes to joining the All Routers Multicast group. it doesnt talk about any other multicast group. Vijay From exim@www1.ietf.org Wed Nov 26 13:59:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21586 for ; Wed, 26 Nov 2003 13:59: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 1AP4sU-0000C1-R1 for nemo-archive@odin.ietf.org; Wed, 26 Nov 2003 13:59:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQIx6fY000735 for nemo-archive@odin.ietf.org; Wed, 26 Nov 2003 13:59:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4sT-0000AT-8A for nemo-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 13:59: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 NAA21549 for ; Wed, 26 Nov 2003 13:58:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP4sQ-0002nX-00 for nemo-web-archive@ietf.org; Wed, 26 Nov 2003 13:59:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP4sQ-0002nU-00 for nemo-web-archive@ietf.org; Wed, 26 Nov 2003 13:59:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4sP-00009h-3Y; Wed, 26 Nov 2003 13: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 1AP4rw-00008O-M7 for nemo@optimus.ietf.org; Wed, 26 Nov 2003 13: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 NAA21542 for ; Wed, 26 Nov 2003 13:58:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP4ru-0002nF-00 for nemo@ietf.org; Wed, 26 Nov 2003 13:58:30 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AP4rt-0002ma-00 for nemo@ietf.org; Wed, 26 Nov 2003 13:58:29 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAQIvo105106; Wed, 26 Nov 2003 10:57:50 -0800 X-mProtect: <200311261857> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdUGDwsJ; Wed, 26 Nov 2003 10:57:49 PST Message-ID: <3FC4F8D4.1040608@iprg.nokia.com> Date: Wed, 26 Nov 2003 11:02:44 -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: Daniel NEGRU CC: nemo@ietf.org Subject: Re: [nemo] NEMO Multicast Issues References: <027301c3b41f$c02b12a0$0201a8c0@perignon> In-Reply-To: <027301c3b41f$c02b12a0$0201a8c0@perignon> 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 Daniel NEGRU wrote: > Hi all, > > I am a Ph.D student in CNRS-PRISM Laboratory at the University of Versailles > and I'm very interested in Network Mobility, especially concerning multicast > issues on mobile networks. > I was wondering if it would be possible for a MR to join to any multicast > groups with its care-of-address when it is in a visited network. I suppose > yes but section 5.7 of the basic support made me have a doubt. section 5.7 only restricts the Mobile Router when it comes to joining the All Routers Multicast group. it doesnt talk about any other multicast group. Vijay From nemo-admin@ietf.org Wed Nov 26 22:01:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09958 for ; Wed, 26 Nov 2003 22:01: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 1APCOs-0005zg-Nt; Wed, 26 Nov 2003 22:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APCOk-0005yk-Cy for nemo@optimus.ietf.org; Wed, 26 Nov 2003 22:00: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 WAA09921 for ; Wed, 26 Nov 2003 22:00:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APCOh-0001TV-00 for nemo@ietf.org; Wed, 26 Nov 2003 22:00:51 -0500 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx with esmtp (Exim 4.12) id 1APCOg-0001T9-00 for nemo@ietf.org; Wed, 26 Nov 2003 22:00:50 -0500 Received: from localhost ([130.194.13.83]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L3IXUYMCDY8ZST1X@vaxh.its.monash.edu.au> for nemo@ietf.org; Thu, 27 Nov 2003 12:07:50 +1100 Received: from splat.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 31F7823C003; Thu, 27 Nov 2003 12:07:50 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by splat.its.monash.edu.au (Postfix) with ESMTP id 1E8E1164004; Thu, 27 Nov 2003 12:07:50 +1100 (EST) Date: Thu, 27 Nov 2003 12:07:49 +1100 From: Greg Daley Subject: Re: [nemo] NEMO Multicast Issues To: Daniel NEGRU Cc: nemo@ietf.org, gopi Reply-to: greg.daley@eng.monash.edu.au Message-id: <3FC54E65.6090408@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <027301c3b41f$c02b12a0$0201a8c0@perignon> Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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 Daniel, At this stage, I'm not sure how much work has been done on this. The section 5.7 says that in the visited network the NEMO MR is treated as a host (not as a router). This is consistent with all of the other NEMO work. In order to get multicast data streams in the visited access network, it's certainly possible to do MLD/IGMP proxying as defined (for fixed routers in): http://www.ietf.org/internet-drafts/draft-ietf-magma-igmp-proxy-04.txt The primary issues (which also relate to NEMO) are topological. Proxying doesn't have a full tree view of the multicast routing state (there's a discontinuity at the MLD Proxy), and relies upon manual topology information to ensure this (determining upstream and downstream interfaces). Actually, NEMO would not require a strict tree topology above it (it needs only be a DAG), but the multicast subscription needs to be selectively performed so that only one copy of a packet arrives on a particular downstream interface. Since the topology information in NEMO comes for free (we know our ingress and egress interfaces, which correspond to the downstream and upstream interfaces), it is plausible to allow MLD proxying on MRs, without significant further work. Even the mobility is unlikely to cause issues, since an egress interface is still an interface (until we come home). Within the NEMO, amongst the routers it may be possible to run a routing protocol, with the MR providing RPF neighbor capability on it's ingress link. It can then arbitrate whether the actual reception comes from the visited network or over teh home tunnel. Of course this only works for multicast reception. Transmission is possibly a more diffcult thing due to the fact that the packets are unlikely to be topologically correct in the visited network (although there's been some work on that with Mobile sources). Tunneling multicast routing to the Home network is simple enough, but if multicast from the visited network is desirable and reliable, it's certainly possible with NEMO. The rest is policy decisions, which I'm not very good at. At this stage, I'm not not sure if others have written this up in a draft, though. Greg Daniel NEGRU wrote: > Hi all, > > I am a Ph.D student in CNRS-PRISM Laboratory at the University of > Versailles and I'm very interested in Network Mobility, especially > concerning multicast issues on mobile networks. > I was wondering if it would be possible for a MR to join to any > multicast groups with its care-of-address when it is in a visited > network. I suppose yes but section 5.7 of the basic support made me have > a doubt. > > Thanks, > Daniel. From exim@www1.ietf.org Wed Nov 26 22:01:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09976 for ; Wed, 26 Nov 2003 22: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 1APCP5-00061K-85 for nemo-archive@odin.ietf.org; Wed, 26 Nov 2003 22:01:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAR31FWV023143 for nemo-archive@odin.ietf.org; Wed, 26 Nov 2003 22:01:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APCP4-000617-TR for nemo-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 22:01: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 WAA09940 for ; Wed, 26 Nov 2003 22:00:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APCP1-0001UE-00 for nemo-web-archive@ietf.org; Wed, 26 Nov 2003 22:01:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APCOz-0001U5-00 for nemo-web-archive@ietf.org; Wed, 26 Nov 2003 22:01:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APCOs-0005zg-Nt; Wed, 26 Nov 2003 22:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APCOk-0005yk-Cy for nemo@optimus.ietf.org; Wed, 26 Nov 2003 22:00: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 WAA09921 for ; Wed, 26 Nov 2003 22:00:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APCOh-0001TV-00 for nemo@ietf.org; Wed, 26 Nov 2003 22:00:51 -0500 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx with esmtp (Exim 4.12) id 1APCOg-0001T9-00 for nemo@ietf.org; Wed, 26 Nov 2003 22:00:50 -0500 Received: from localhost ([130.194.13.83]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L3IXUYMCDY8ZST1X@vaxh.its.monash.edu.au> for nemo@ietf.org; Thu, 27 Nov 2003 12:07:50 +1100 Received: from splat.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 31F7823C003; Thu, 27 Nov 2003 12:07:50 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by splat.its.monash.edu.au (Postfix) with ESMTP id 1E8E1164004; Thu, 27 Nov 2003 12:07:50 +1100 (EST) Date: Thu, 27 Nov 2003 12:07:49 +1100 From: Greg Daley Subject: Re: [nemo] NEMO Multicast Issues To: Daniel NEGRU Cc: nemo@ietf.org, gopi Reply-to: greg.daley@eng.monash.edu.au Message-id: <3FC54E65.6090408@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <027301c3b41f$c02b12a0$0201a8c0@perignon> Content-Transfer-Encoding: 7BIT Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-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 Daniel, At this stage, I'm not sure how much work has been done on this. The section 5.7 says that in the visited network the NEMO MR is treated as a host (not as a router). This is consistent with all of the other NEMO work. In order to get multicast data streams in the visited access network, it's certainly possible to do MLD/IGMP proxying as defined (for fixed routers in): http://www.ietf.org/internet-drafts/draft-ietf-magma-igmp-proxy-04.txt The primary issues (which also relate to NEMO) are topological. Proxying doesn't have a full tree view of the multicast routing state (there's a discontinuity at the MLD Proxy), and relies upon manual topology information to ensure this (determining upstream and downstream interfaces). Actually, NEMO would not require a strict tree topology above it (it needs only be a DAG), but the multicast subscription needs to be selectively performed so that only one copy of a packet arrives on a particular downstream interface. Since the topology information in NEMO comes for free (we know our ingress and egress interfaces, which correspond to the downstream and upstream interfaces), it is plausible to allow MLD proxying on MRs, without significant further work. Even the mobility is unlikely to cause issues, since an egress interface is still an interface (until we come home). Within the NEMO, amongst the routers it may be possible to run a routing protocol, with the MR providing RPF neighbor capability on it's ingress link. It can then arbitrate whether the actual reception comes from the visited network or over teh home tunnel. Of course this only works for multicast reception. Transmission is possibly a more diffcult thing due to the fact that the packets are unlikely to be topologically correct in the visited network (although there's been some work on that with Mobile sources). Tunneling multicast routing to the Home network is simple enough, but if multicast from the visited network is desirable and reliable, it's certainly possible with NEMO. The rest is policy decisions, which I'm not very good at. At this stage, I'm not not sure if others have written this up in a draft, though. Greg Daniel NEGRU wrote: > Hi all, > > I am a Ph.D student in CNRS-PRISM Laboratory at the University of > Versailles and I'm very interested in Network Mobility, especially > concerning multicast issues on mobile networks. > I was wondering if it would be possible for a MR to join to any > multicast groups with its care-of-address when it is in a visited > network. I suppose yes but section 5.7 of the basic support made me have > a doubt. > > Thanks, > Daniel. From nemo-admin@ietf.org Thu Nov 27 04:30:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01481 for ; Thu, 27 Nov 2003 04:30: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 1APITJ-00089R-MG; Thu, 27 Nov 2003 04:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APIT9-00088m-OC for nemo@optimus.ietf.org; Thu, 27 Nov 2003 04:29: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 EAA01444 for ; Thu, 27 Nov 2003 04:29:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APIT6-0005eV-00 for nemo@ietf.org; Thu, 27 Nov 2003 04:29:48 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1APIT6-0005eN-00 for nemo@ietf.org; Thu, 27 Nov 2003 04:29:48 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id hAR9T8YX010616; Thu, 27 Nov 2003 02:29:08 -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 hAR9SjrO003103; Thu, 27 Nov 2003 03:28:47 -0600 Received: from motorola.com (zfr01-0108.crm.mot.com [10.161.201.135]) by thorgal.crm.mot.com (Postfix) with ESMTP id 911352EC95; Thu, 27 Nov 2003 10:28:44 +0100 (CET) Message-ID: <3FC5C3CB.AC0E37B9@motorola.com> Date: Thu, 27 Nov 2003 10:28:44 +0100 From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au Cc: Daniel NEGRU , nemo@ietf.org, gopi Subject: Re: [nemo] NEMO Multicast Issues References: <027301c3b41f$c02b12a0$0201a8c0@perignon> <3FC54E65.6090408@eng.monash.edu.au> 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 Daniel, Greg, Greg Daley wrote: > In order to get multicast data streams in the visited > access network, it's certainly possible to do MLD/IGMP > proxying as defined (for fixed routers in): > > http://www.ietf.org/internet-drafts/draft-ietf-magma-igmp-proxy-04.txt Exactly! We also have been working recently on the problem of delivering IP multicast to nodes in a moving network. "IGMP/MLD-based multicast forwarding" (referenced by Greg) is indeed an interesting approach that can be deployed within the moving network (including MR) in order to enable this capability. This allows the MR to collect group membership information from within the nemo and subscribe itself to those groups through the visited network. With this approach, the MR behaves like a Mobile Node from the visited network perspective, using "remote subscription" through its egress interface to support handover of multicast flows. As mentioned by Greg, this approach has some limitations (e.g. manual configuration of the tree-like topology) but has also many advantages IMHO. Here are few of them: o Enable "global mobility": MR is using MLD towards the visited network (as a Mobile Node), and not a multicast routing protocol. Thus avoiding interoperability issues when MR roams into a domain supporting a multicast routing protocol different from the one at home. o Optimal routing, even with nested MRs. o Per-flow handover possible, for MR equipped with multiple egress interfaces o Independent of the base NEMO support (unicast). o No need to run a multicast routing protocol within the moving network. o Easy to implement This makes the approach interesting for vehicular environments, where the intra-vehicular network topology is small to medium. We have been implementing and experimenting this approach as part of the OverDRiVE project (http://www.ist-overdrive.org) on top of the LIVSIX IPv6 stack (http://www.nal.motlabs.com). This is to be demonstrated next week during the HyWiN workshop in Turin (http://www.comnets.rwth-aachen.de/~o_drive/HyWiN2003/index.html). > Transmission is possibly a more diffcult thing due to the > fact that the packets are unlikely to be topologically > correct in the visited network (although there's been some > work on that with Mobile sources). The MLD-based Multicast Forwarding has some kind of support for sources in the Moving Network. It can route packets from a source located within the NEMO towards receivers also located in the same NEMO without problem. However, as mentioned by Greg, when it comes to reach receivers in the Internet, then tunnelling of the packets through the MR-HA is required to pass RPF checks. > At this stage, I'm not not sure if others have written this > up in a draft, though. We were planning to write a draft in the coming weeks, to share our experience of this approach with the working group (if any interest). Bye Christophe. From exim@www1.ietf.org Thu Nov 27 04:30:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01497 for ; Thu, 27 Nov 2003 04:30: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 1APITR-0008Ad-HH for nemo-archive@odin.ietf.org; Thu, 27 Nov 2003 04:30:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAR9U9Ia031408 for nemo-archive@odin.ietf.org; Thu, 27 Nov 2003 04:30:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APITQ-0008AV-FT for nemo-web-archive@optimus.ietf.org; Thu, 27 Nov 2003 04:30: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 EAA01455 for ; Thu, 27 Nov 2003 04:29:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APITN-0005ev-00 for nemo-web-archive@ietf.org; Thu, 27 Nov 2003 04:30:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APITN-0005eq-00 for nemo-web-archive@ietf.org; Thu, 27 Nov 2003 04:30:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APITJ-00089R-MG; Thu, 27 Nov 2003 04:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APIT9-00088m-OC for nemo@optimus.ietf.org; Thu, 27 Nov 2003 04:29: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 EAA01444 for ; Thu, 27 Nov 2003 04:29:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APIT6-0005eV-00 for nemo@ietf.org; Thu, 27 Nov 2003 04:29:48 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1APIT6-0005eN-00 for nemo@ietf.org; Thu, 27 Nov 2003 04:29:48 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id hAR9T8YX010616; Thu, 27 Nov 2003 02:29:08 -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 hAR9SjrO003103; Thu, 27 Nov 2003 03:28:47 -0600 Received: from motorola.com (zfr01-0108.crm.mot.com [10.161.201.135]) by thorgal.crm.mot.com (Postfix) with ESMTP id 911352EC95; Thu, 27 Nov 2003 10:28:44 +0100 (CET) Message-ID: <3FC5C3CB.AC0E37B9@motorola.com> Date: Thu, 27 Nov 2003 10:28:44 +0100 From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au Cc: Daniel NEGRU , nemo@ietf.org, gopi Subject: Re: [nemo] NEMO Multicast Issues References: <027301c3b41f$c02b12a0$0201a8c0@perignon> <3FC54E65.6090408@eng.monash.edu.au> 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 Daniel, Greg, Greg Daley wrote: > In order to get multicast data streams in the visited > access network, it's certainly possible to do MLD/IGMP > proxying as defined (for fixed routers in): > > http://www.ietf.org/internet-drafts/draft-ietf-magma-igmp-proxy-04.txt Exactly! We also have been working recently on the problem of delivering IP multicast to nodes in a moving network. "IGMP/MLD-based multicast forwarding" (referenced by Greg) is indeed an interesting approach that can be deployed within the moving network (including MR) in order to enable this capability. This allows the MR to collect group membership information from within the nemo and subscribe itself to those groups through the visited network. With this approach, the MR behaves like a Mobile Node from the visited network perspective, using "remote subscription" through its egress interface to support handover of multicast flows. As mentioned by Greg, this approach has some limitations (e.g. manual configuration of the tree-like topology) but has also many advantages IMHO. Here are few of them: o Enable "global mobility": MR is using MLD towards the visited network (as a Mobile Node), and not a multicast routing protocol. Thus avoiding interoperability issues when MR roams into a domain supporting a multicast routing protocol different from the one at home. o Optimal routing, even with nested MRs. o Per-flow handover possible, for MR equipped with multiple egress interfaces o Independent of the base NEMO support (unicast). o No need to run a multicast routing protocol within the moving network. o Easy to implement This makes the approach interesting for vehicular environments, where the intra-vehicular network topology is small to medium. We have been implementing and experimenting this approach as part of the OverDRiVE project (http://www.ist-overdrive.org) on top of the LIVSIX IPv6 stack (http://www.nal.motlabs.com). This is to be demonstrated next week during the HyWiN workshop in Turin (http://www.comnets.rwth-aachen.de/~o_drive/HyWiN2003/index.html). > Transmission is possibly a more diffcult thing due to the > fact that the packets are unlikely to be topologically > correct in the visited network (although there's been some > work on that with Mobile sources). The MLD-based Multicast Forwarding has some kind of support for sources in the Moving Network. It can route packets from a source located within the NEMO towards receivers also located in the same NEMO without problem. However, as mentioned by Greg, when it comes to reach receivers in the Internet, then tunnelling of the packets through the MR-HA is required to pass RPF checks. > At this stage, I'm not not sure if others have written this > up in a draft, though. We were planning to write a draft in the coming weeks, to share our experience of this approach with the working group (if any interest). Bye Christophe.