From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 1 00:06:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10047 for ; Fri, 1 Dec 2000 00:06:21 -0500 (EST) Received: from standards (47.234.32.16:3782) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDB61@standards.nortelnetworks.com>; Thu, 30 Nov 2000 23:47:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 150895 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Nov 2000 23:47:10 -0500 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDB5F@standards.nortelnetworks.com>; Thu, 30 Nov 2000 23:47:09 -0500 Received: from comet.columbia.edu (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id AAA05925; Fri, 1 Dec 2000 00:04:30 -0500 (EST) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: "Andrew T. Campbell" Message-ID: <3A275F9A.A0572D80@comet.columbia.edu> Date: Fri, 1 Dec 2000 00:21:46 -0800 Reply-To: campbell@comet.columbia.edu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Andrew T. Campbell" Organization: Center for Telecommunications Research Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location X-To: Ajoy Singh To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Ajoy Singh wrote: > I hate to talk about CDMA or any other link layer in Mobile/IP list, Reality check: IP isn't designed for Ethernet and Mobile IP not for CDMA. But Ethernet is THE link layer and CDMA (W or 2000) will likely be THE wireless link for 2.5G, 3G, 4G (whatever that is), WLAN (802.Xs), etc. Should we get real - or not? It would be nice to see MIP get deployed.....some day .. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 1 00:23:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19140 for ; Fri, 1 Dec 2000 00:23:10 -0500 (EST) Received: from standards (47.234.32.16:3782) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDBC5@standards.nortelnetworks.com>; Fri, 1 Dec 2000 0:04:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 151024 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Dec 2000 00:04:02 -0500 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDBC3@standards.nortelnetworks.com>; Fri, 1 Dec 2000 0:03:57 -0500 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id WAA22051 for ; Thu, 30 Nov 2000 22:21:19 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id WAA26037 for ; Thu, 30 Nov 2000 22:21:19 -0700 (MST)] Received: from ripcord756 (d50-497f.cig.mot.com [160.47.73.127]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id WQNKVHRK; Thu, 30 Nov 2000 23:21:12 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Approved-By: Ajoy Singh Message-ID: Date: Thu, 30 Nov 2000 23:31:02 -0600 Reply-To: Ajoy Singh Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ajoy Singh Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location X-To: campbell@comet.columbia.edu, Ajoy Singh To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <3A275F9A.A0572D80@comet.columbia.edu> Content-Transfer-Encoding: 7bit Hello Andrew, Just one clarification. By fast handoff, I was referring to Hesham's proposal. I know, the name is confusing as proactive and other solution also addresses fast handoff problem. But I would prefer a solution that does not impose hard real time constraint as imposed by Hesham's (fast handoff) proposal. BTW, I am very much interested to see mobile/IP deployed. Please dont get me wrong. regards, ajoy -----Original Message----- From: Andrew T. Campbell [mailto:campbell@comet.columbia.edu] Sent: Friday, December 01, 2000 2:22 AM To: Ajoy Singh Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; campbell@comet.columbia.edu Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location Ajoy Singh wrote: > I hate to talk about CDMA or any other link layer in Mobile/IP list, Reality check: IP isn't designed for Ethernet and Mobile IP not for CDMA. But Ethernet is THE link layer and CDMA (W or 2000) will likely be THE wireless link for 2.5G, 3G, 4G (whatever that is), WLAN (802.Xs), etc. Should we get real - or not? It would be nice to see MIP get deployed.....some day .. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 1 01:16:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20493 for ; Fri, 1 Dec 2000 01:16:37 -0500 (EST) Received: from standards (47.234.32.16:4987) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDC31@standards.nortelnetworks.com>; Fri, 1 Dec 2000 0:57:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 151163 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Dec 2000 00:57:18 -0500 Received: from ish7.ericsson.com.au (203.61.155.111:65201) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDC2F@standards.nortelnetworks.com>; Fri, 1 Dec 2000 0:57:17 -0500 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id RAA12286 for ; Fri, 1 Dec 2000 17:11:08 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA19580 for ; Fri, 1 Dec 2000 17:14:02 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 17:14:19 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Approved-By: "Hesham Soliman (EPA)" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613EE3@eaubrnt018.epa.ericsson.se> Date: Fri, 1 Dec 2000 17:14:17 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > By fast handoff, I was referring to Hesham's > proposal. > => Thanks for the credit, but I'm a bit uncomfortable about referring to draft-elmalki-mobileip .... as "Hesham's" draft. Regards, Hesham From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 1 01:47:37 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA11006 for ; Fri, 1 Dec 2000 01:47:35 -0500 (EST) Received: from standards (47.234.32.16:3574) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDC7C@standards.nortelnetworks.com>; Fri, 1 Dec 2000 1:28:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 151262 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Dec 2000 01:28:21 -0500 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDC7A@standards.nortelnetworks.com>; Fri, 1 Dec 2000 1:28:21 -0500 Received: from comet.columbia.edu (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id BAA08054; Fri, 1 Dec 2000 01:45:38 -0500 (EST) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4B6BC00CD15FD2119E5F0008C7A419A50C613EE3@eaubrnt018.epa.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: "Andrew T. Campbell" Message-ID: <3A27774E.ACEA1608@comet.columbia.edu> Date: Fri, 1 Dec 2000 02:02:54 -0800 Reply-To: campbell@comet.columbia.edu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Andrew T. Campbell" Organization: Center for Telecommunications Research Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location X-To: "Hesham Soliman (EPA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hesham: "Hesham Soliman (EPA)" wrote: > > > By fast handoff, I was referring to Hesham's > > proposal. > > I agree, that was a very bad choice of name for an ID. I would have opted for very fast handoff or something more modest such as not so slow handoff ;-). Of course its difficult to quantify the speed of handoff unless you get specific about the radio, signaling and traffic load conditions. Do you have implementation results to back up your claim of fast? (For CIP between 802.11 access points under lightly loaded conditions its 4 ms - that's fast!). I've a feeling CIP was booted out the WG because we might be too fast for MIP to keep up .... Andrew From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 1 04:37:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA22350 for ; Fri, 1 Dec 2000 04:37:47 -0500 (EST) Received: from standards (47.234.32.16:2879) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDCFB@standards.nortelnetworks.com>; Fri, 1 Dec 2000 4:18:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 151434 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Dec 2000 04:18:23 -0500 Received: from n13.sp.op.dlr.de (gw.sp.op.dlr.de) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDCF9@standards.nortelnetworks.com>; Fri, 1 Dec 2000 4:18:23 -0500 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) by n13.sp.op.dlr.de (8.10.1/8.10.1) with ESMTP id eB19ZjO44700 for ; Fri, 1 Dec 2000 10:35:45 +0100 Received: from zeus.nt.op.dlr.de (pcdn183_nt_op [129.247.173.183]) by zeus.nt.op.dlr.de (8.9.1b+Sun/8.9.1) with ESMTP id KAA20229 for ; Fri, 1 Dec 2000 10:35:44 +0100 (MET) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Matteo Berioli Message-ID: <3A277105.AF329901@zeus.nt.op.dlr.de> Date: Fri, 1 Dec 2000 10:36:05 +0100 Reply-To: mberio@libero.it Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Matteo Berioli Subject: [MOBILE-IP] CoA no more available To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hallo all, I don't know if my question concerns a too small detail... Here it is. Is there a message in Mobile IP's Registration Reply with which the Foreign Agent can say: "registration is denied because the Care-of Address requested is no more available"? For example by mean of the Code field in the Registration Reply messages. Thanks, Matteo From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 1 10:23:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20464 for ; Fri, 1 Dec 2000 10:23:52 -0500 (EST) Received: from standards (47.234.32.16:2918) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDEAE@standards.nortelnetworks.com>; Fri, 1 Dec 2000 10:04:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 151979 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Dec 2000 10:04:30 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDEAC@standards.nortelnetworks.com>; Fri, 1 Dec 2000 10:04:30 -0500 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23540; Fri, 1 Dec 2000 07:21:51 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA09016; Fri, 1 Dec 2000 07:21:51 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA03468; Fri, 1 Dec 2000 07:21:44 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Approved-By: Pat Calhoun Message-ID: Date: Fri, 1 Dec 2000 07:18:44 -0800 Reply-To: Pat Calhoun Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pat Calhoun Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location X-To: campbell@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <3A275F9A.A0572D80@comet.columbia.edu> > Ajoy Singh wrote: > > > I hate to talk about CDMA or any other link layer in Mobile/IP list, > > Reality check: > > IP isn't designed for Ethernet and Mobile IP not for CDMA. > But Ethernet is THE link layer and CDMA (W or 2000) will > likely be THE wireless link for 2.5G, 3G, 4G (whatever that > is), WLAN (802.Xs), etc. > > Should we get real - or not? Yes we should, and perhaps you misread Ajoy's e-mail. Hesham has been very consistent in pushing any of our arguments regarding the limitations of CDMA2000, and how the "fast handoff" proposal would not work in such environments. If Pete McCann or Tom Hiller is reading this, I would ask that he points to the same CDMA2000 spec that we discussed on the design team conference calls that make it clear that there is no time for mobiles to perform Mobile IP registration when a handoff occurs. > > It would be nice to see MIP get deployed.....some day .. Same here! PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 1 10:42:35 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22720 for ; Fri, 1 Dec 2000 10:42:35 -0500 (EST) Received: from standards (47.234.32.16:2918) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDEF4@standards.nortelnetworks.com>; Fri, 1 Dec 2000 10:23:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 152076 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Dec 2000 10:23:26 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDEF2@standards.nortelnetworks.com>; Fri, 1 Dec 2000 10:23:26 -0500 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA29924; Fri, 1 Dec 2000 07:40:46 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA11716; Fri, 1 Dec 2000 07:40:45 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA03922; Fri, 1 Dec 2000 07:40:39 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Approved-By: Pat Calhoun Message-ID: Date: Fri, 1 Dec 2000 07:37:39 -0800 Reply-To: Pat Calhoun Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pat Calhoun Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location X-To: "Hesham Soliman (EPA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <4B6BC00CD15FD2119E5F0008C7A419A50C613EDD@eaubrnt018.epa.ericsson.se> > > In these wireless networks, there is no additional time for > > Mobile IP registration. > > > => Which wireless links ? CDMA for example ? > As we mentioned during the meetings, we looked at these > handoff sequences and found that there is time and it is > certainly possible to support FH. CDMA is much more > flexible in terms of handoff times than other wireless > systems. No. During the last call, which you may have not attended, Pete McCann discussed one of the IS-95 specs, and how the mobile would NOt have time to perform Mobile IP registration. > > > However, you failed to address my comment where I stated that this > > co-location > > issue is NOT a pro-active problem, since the fast handoff proposal uses > > similar triggers. Both proposals require colocated AP/FAs. > > > => The FH model allows for both MN initiation and FA initiation. > Therefore > I don't see why it would need this colocation. MN initiation is RFC 2002, as I understand it. Therefore, there is nothing "fast" in RFC 2002. I listed both methods that the "fast handoff" proposal supports, one which allows for inter-fa communication, which is subject to the same limitations as pro-active in 802.11 environments, and the second being modification of link layers. For the latter, if link layers need to change, then A foreign Agent's IP address CAN easily be provided in the link layer as well. Or, rather, just get IAPP to be sent to Foreign Agents, as well, as a trigger mechanism. CDMA2000 is similar to the IAPP approach since the PDSN does not actually receive a trigger from the link layer, but rather receives a messages from the PCF indicating that a handoff is occuring. > You also didn't answer my comments on IAPP :) I thought I did. Could you please restate your question? PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 1 11:09:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01942 for ; Fri, 1 Dec 2000 11:09:20 -0500 (EST) Received: from standards (47.234.32.16:2918) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDF3F@standards.nortelnetworks.com>; Fri, 1 Dec 2000 10:50:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 152176 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Dec 2000 10:50:03 -0500 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDF3D@standards.nortelnetworks.com>; Fri, 1 Dec 2000 10:50:02 -0500 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA23710 for ; Fri, 1 Dec 2000 09:07:06 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id JAA21280 for ; Fri, 1 Dec 2000 09:07:05 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Fri, 1 Dec 2000 10:07:05 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Approved-By: Roberts Philip-qa3445 Message-ID: Date: Fri, 1 Dec 2000 10:07:04 -0600 Reply-To: Roberts Philip-qa3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Philip-qa3445 Subject: [MOBILE-IP] revised agenda To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Thursday 9-11:30 (150 minutes) Raj 10 Agenda bashing and wg document status Charlie Perkins 15 MIPv6 Update draft-ietf-mobileip-ipv6-13.txt Vijay Devarapali 5 MIPv6 ETSI Bake-off Report Alper Yegin 5 Connectathon announcement Mobile IP V4 fast handoff: Pat Calhoun 5 Proactive handoff draft-calhoun-mobileip-proactive-fa-02.txt Karim El-Malki 5 Fast handoff draft-elmalki-mobileip-fast-handoffs-03.txt McCann/El-malki 5 Summary of differences in v4 handoff WG 15 Discussion of fast handoff in v4 Mobile IP V6 fast handoff: Charlie Perkins 15 v6 fast handoff design team Hesham Soliman 10 Hierarchical MIP v6 draft-ietf-mobileip-hmipv6-01.txt Pat Calhoun 5 Mobile IP and GRE enhancements draft-calhoun-mobileip-gre-ext-00.txt Charlie Perkins 10 DIAMETER extensions for MIP draft-calhoun-diameter-mobileip-11.txt Charlie Perkins 10 AAAv6 for MIP draft-perkins-aaav6-01.txt Steve Glass 15 Registration Revocation for Mobile IP draft-glass-mobileip-reg-revok-00.txt Samita Chakrabarti 10 Private addressing draft-ietf-mobileip-rfc2344-bis-03.txt Friday 9-11:30 (150 minutes) Hemant Chaskar 10 A Framework for QoS Support in MIP v6 draft-chaskar-mobileip-qos-00.txt Glenn Morrow 15 Intercepting Location Updates draft-lmk-mobileip-intercepting-update-00.txt Hesham Soliman 10 Security association establishment for route optimization in v6 draft-soliman-mobileip-routeopt-mipv6-00.txt Charlie Pekins 10 IP v6 Regional Registration draft-malinen-mobileip-regreg6-00.txt SL Tsao 15 Introducing Mobile IP in IPv4/IPv6 Interconnected networks draft-tsao-mobileip-duelstack-model-00.txt Steve Glass 10 Use of DHCP in Mobile IP draft-glass-mobileip-agent-dhcp-proxy-00.txt Ernst Thierry 10 Mobile Network Support draft-ernst-mobileip-v6-network-00.txt Jari Malinen 5 GSM SIM authentication draft-haverinen-mobileip-gsmsim-00.txt Jiwoong Lee 6 SGM support in MIP draft-lee-sgm-support-mobileip-00.txt Pekka Nikander 10 Mobile IP v6 for the Homeless draft-nikander-mobileip-homelessv6-00.txt Behcet Sarikaya 5 Mobile IP v6 Regional Paging draft-sarikaya-mobileip-hmipv6rp-00 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 1 11:31:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09072 for ; Fri, 1 Dec 2000 11:31:28 -0500 (EST) Received: from standards (47.234.32.16:2918) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDF88@standards.nortelnetworks.com>; Fri, 1 Dec 2000 11:12:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 152275 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Dec 2000 11:12:15 -0500 Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDF86@standards.nortelnetworks.com>; Fri, 1 Dec 2000 11:12:15 -0500 Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id RAA20966 for ; Fri, 1 Dec 2000 17:29:38 +0100 (MET) Received: from inrialpes.fr (localhost [127.0.0.1]) by glandon.inrialpes.fr (8.8.7/8.8.5) with ESMTP id RAA07353 for ; Fri, 1 Dec 2000 17:29:38 +0100 (MET) X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Thierry.Ernst@INRIALPES.FR Message-ID: <3A27D1F1.FACDD8DF@inrialpes.fr> Date: Fri, 1 Dec 2000 17:29:38 +0100 Reply-To: Thierry Ernst Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thierry Ernst Organization: INRIA Rhone-Alpes Subject: Re: [MOBILE-IP] revised agenda - Mobile Networks To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, > Ernst Thierry 10 Mobile Network Support > draft-ernst-mobileip-v6-network-00.txt Although it has not yet been announced by IESG, I have issued a revision of my draft. My speak will therefore turn around draft-ernst-mobileip-v6-network-01.txt. You can get the draft from: http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network-01.txt I think that the problem was partly missunderstood at last IETF. The new version of the draft clarifies: - terminology - description of the problems - security issues. Moreover, I have included an experimentation conducted on FreeBSD which demonstates that the Mobile IPv6 specification does not allow the HA to redirect packets that are sent to a node located in the mobile network. People on this list might not agree on the solution proposed in my draft, but at least I hope that people would agree on the problem on the HA's side. Thierry. -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * PhD Student financed by MOTOROLA Labs Paris * http://www.inrialpes.fr/planete/people/ernst/Welcome.html From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 1 12:34:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27517 for ; Fri, 1 Dec 2000 12:34:24 -0500 (EST) Received: from standards (47.234.32.16:2918) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDFF3@standards.nortelnetworks.com>; Fri, 1 Dec 2000 12:14:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 152416 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Dec 2000 12:14:38 -0500 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDFF1@standards.nortelnetworks.com>; Fri, 1 Dec 2000 12:14:38 -0500 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Fri Dec 1 12:31:08 EST 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Fri Dec 1 12:31:03 EST 2000 Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP id 5594C5701F; Fri, 1 Dec 2000 11:31:02 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <4B6BC00CD15FD2119E5F0008C7A419A50C613EDD@eaubrnt018.epa.ericsson.se> X-Mailer: VM 6.33 under Emacs 19.34.2 Approved-By: Pete McCann Message-ID: <20001201173102.5594C5701F@king.research.bell-labs.com> Date: Fri, 1 Dec 2000 11:31:02 -0600 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location X-To: Pat Calhoun To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Hi, Two points: 1) Handoff Timing. For cdma2000, there is at most a couple of hundred milliseconds between the time that the BSC recognizes the need for a handoff and the time the handoff must take place. The reason for this deadline is that the radio channel to the current MN is fading quickly, but the final "handoff order" telling the MN to connect to the new BSC must be sent over the air before connectivity is lost. Putting over-the-air Mobile IP signaling on the critical path will almost certainly cause us to miss this deadline in some cases, resulting in lost calls. Remember it's not just the new messages but also operating system scheduling that we have to worry about. We are working to gather some more specific delay numbers/lost call probabilities and we can discuss in San Diego. 2) IAPP I don't know much about 802.11, but it occurred to me in Pittsburgh that you could probably deploy some kind of "smart bridge" between the two networks that would watch IAPP traffic on both of them, and by collating the results you would be able to figure out where a MN came from. This would enable you to send a pro-active trigger or even to start bridging the MN's traffic to/from the old network, obviating the need for any MIP messaging. The extra box might sound like a heavyweight solution but it would really be no more onerous than the handoff mechanisms currently in place between cellular coverage areas. FA addresses would of course need to be provisioned during the coverage planning stage and when forming handoff agreements with neighboring carriers. -Pete Pat Calhoun (PC) writes: >> > In these wireless networks, there is no additional time for >> > Mobile IP registration. >> > >> => Which wireless links ? CDMA for example ? >> As we mentioned during the meetings, we looked at these >> handoff sequences and found that there is time and it is >> certainly possible to support FH. CDMA is much more >> flexible in terms of handoff times than other wireless >> systems. PC> No. During the last call, which you may have not attended, Pete McCann PC> discussed one of the IS-95 specs, and how the mobile would NOt have time to PC> perform Mobile IP registration. >> > However, you failed to address my comment where I stated that this >> > co-location >> > issue is NOT a pro-active problem, since the fast handoff proposal uses >> > similar triggers. Both proposals require colocated AP/FAs. >> > >> => The FH model allows for both MN initiation and FA initiation. >> Therefore >> I don't see why it would need this colocation. PC> MN initiation is RFC 2002, as I understand it. Therefore, there is PC> nothing "fast" in RFC 2002. I listed both methods that the "fast PC> handoff" proposal supports, one which allows for inter-fa PC> communication, which is subject to the same limitations as PC> pro-active in 802.11 environments, and the second being PC> modification of link layers. For the latter, if link layers need PC> to change, then A foreign Agent's IP address CAN easily be PC> provided in the link layer as well. Or, rather, just get IAPP to PC> be sent to Foreign Agents, as well, as a trigger mechanism. PC> CDMA2000 is similar to the IAPP approach since the PDSN does not PC> actually receive a trigger from the link layer, but rather PC> receives a messages from the PCF indicating that a handoff is PC> occuring. >> You also didn't answer my comments on IAPP :) PC> I thought I did. Could you please restate your question? PC> PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 1 12:41:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29327 for ; Fri, 1 Dec 2000 12:41:38 -0500 (EST) Received: from standards (47.234.32.16:2918) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE019@standards.nortelnetworks.com>; Fri, 1 Dec 2000 12:18:02 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 152465 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Dec 2000 12:18:02 -0500 Received: from mgw-dax2.ext.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE017@standards.nortelnetworks.com>; Fri, 1 Dec 2000 12:18:02 -0500 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eB1HZn616718 for ; Fri, 1 Dec 2000 11:35:59 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Fri, 1 Dec 2000 11:35:15 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Fri, 1 Dec 2000 11:30:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Approved-By: Basavaraj.Patil@NOKIA.COM Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B02C9F6DF@daeis07nok> Date: Fri, 1 Dec 2000 11:31:16 -0600 Reply-To: Basavaraj.Patil@nokia.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location X-To: campbell@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > I've a feeling CIP was booted out the WG because > we might be too fast for MIP to keep up .... > > Andrew > Andrew, The scope of the mobile IP WG to begin with was quite wide. Anything related to mobility essentially ended up in the Mobile IP WG. Not that it's a bad thing, but the efficiency of the WG as whole in meeting the milestones and also in terms of keeping focus on the charter we decided to narrow the scope. I believe that the excellent work on micromobility (Cellular IP and others) has a much better opportunity in a focused group such as SeaMoby. I sense some disappointment from you when you say that CIP was booted out of the MIP WG, but really Andrew, I think it gives CIP a home in SeaMoby which is far more appropriate. -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 1 12:49:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01347 for ; Fri, 1 Dec 2000 12:49:46 -0500 (EST) Received: from standards (47.234.32.16:2918) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE071@standards.nortelnetworks.com>; Fri, 1 Dec 2000 12:30:30 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 152590 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Dec 2000 12:30:30 -0500 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE06F@standards.nortelnetworks.com>; Fri, 1 Dec 2000 12:30:29 -0500 Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id eB1HlrG05750 for ; Fri, 1 Dec 2000 18:47:53 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Dec 01 18:47:51 2000 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Fri, 1 Dec 2000 18:47:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Karim El-Malki (ERA)" Message-ID: <5F05C89FB2F8D211B6430008C791912707460314@esealnt190> Date: Fri, 1 Dec 2000 18:47:44 +0100 Reply-To: "Karim El-Malki (ERA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Karim El-Malki (ERA)" Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location X-To: Pat Calhoun To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Pat > Yes we should, and perhaps you misread Ajoy's e-mail. Hesham > has been very > consistent in pushing any of our arguments regarding the > limitations of > CDMA2000, and how the "fast handoff" proposal would not work in such > environments. If Pete McCann or Tom Hiller is reading this, I > would ask that > he points to the same CDMA2000 spec that we discussed on the > design team > conference calls that make it clear that there is no time for > mobiles to > perform Mobile IP registration when a handoff occurs. We're not 3GPP experts and there are people in the 3GPPs who can handle system-specific issues. For this reason I believe we decided to develop a generic spec, which should hopefully take into account inter-system mobility (e.g. WLAN to 3G). If you are saying that you want to add the above "no time to perform..." requirement to the handoffs work I would disagree and remind you of the discussions we've had about this during our phone conferences. You must be assuming that the L3 registration is done after a certain point during the L2 procedure after which there is no time. I can't see a reason why the MIP registration can't be started before that point in time. The L2 and L3 handoff procedures could almost proceed alongside in which case your argument would not be valid. In any case, for the reasons mentioned above, I would prefer not getting into the system-specific details. The fundamental issue is that Fast Handoffs supports the RFC2002 concept where the MN participates in the handoff and performs movement detection. That's different from Proactive Handoffs which involves a new FA-FA message to perform the handoff and does not provide MN control of the handoff. I think we agreed on this. Fast Handoffs doesn't involve a new protocol or a major change to the RFC2002 concept. Hesham and I sent out a more detailed list of differences previously and I attach it below for those who are interested. Regards, /Karim 1) The Fast Handoffs draft allows both the network and the MN to control L3 handoffs just as normal Mobile IP (RFC2002). The MN performs Mobile IP Registrations and is therefore in control as to when and with which agent it registers. The network is also in control since it may decide whether to send the MN an agent advertisement to trigger the MN's movement (without which the MN will not perform movement detection and MIP Registration). The network may also advertise but reject the MN's Registration and thus again exercise control. In Proactive handoffs the MN has no control over the handoff and may only react to the network-controlled handoff after it has obtained L2 connectivity to the new FA and starts receiving data from it. Thus the handoff is forced on the MN and the MN may only react if and when the new FA decides to advertise. 2) The Fast Handoffs draft allows the MN to register with the new FA (or GFA) before it moves and before it obtains L2 connectivity to that new FA, thus anticipating the MN's movement. By interacting with L2 it is possible for the FA to synchronize such a registration with the cellular network's mobility such that the new Registration is completed before the MN is instructed to perform a handoff at L2. Local HA functionality (GFA) is used to limit the RTT for the MN's registration. In this way we potentially eliminate the service disruption caused by L3 handoffs and limit the MN's service disruption period to that imposed by the specific L2. 3) The same amount of Registrations/Advertisement are sent/received by an active MN using Proactive or Fast Handoffs for the support of real-time services such as VoIP. The main difference is that in Fast Handoffs the Registration is performed by the MN before it performs a handoff to the new FA, while in Proactive handoffs this is done after the MN has performed a handoff to the new FA and once it is receiving traffic through the new FA. 4) It is not clear in the proactive approach how an intersystem handoff is handled. For example a handoff occuring between two different wireless technologies. If the proactive approach is to be used for handoffs, and if the MN has a choice of two different systems, it is not possible for the MN to choose which FA it wants to be connected to (until after the MN has been handed off to the new FA). Hence a handoff may result in connecting the MN to a less preferred FA. This is especially true if the FAs choose not to send agent advertisements for very long periods as suggested by the draft. This situation will not arise in Fast Handoffs. 5) The proactive draft states that a FA MAY choose to send an Agent Advertisement to the MN after the handoff has taken place. The length of time after which the advertisement is sent is unclear. If simultaneous bindings are used (which is suggested by the draft), this will result in long lifetimes for the simultaneous bindings and consequently an inefficient use of bandwidth since multiple copies of the same packet are transmitted to FAs. In Fast Handoffs simultaneous bindings will have short lifetimes in order to minimize bandwidth consumption. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 1 12:56:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03073 for ; Fri, 1 Dec 2000 12:56:39 -0500 (EST) Received: from standards (47.234.32.16:2918) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE0AC@standards.nortelnetworks.com>; Fri, 1 Dec 2000 12:36:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 152668 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Dec 2000 12:36:21 -0500 Received: from patan.sun.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE0AA@standards.nortelnetworks.com>; Fri, 1 Dec 2000 12:36:21 -0500 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02370; Fri, 1 Dec 2000 09:53:44 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA25424; Fri, 1 Dec 2000 09:53:43 -0800 (PST) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA07901; Fri, 1 Dec 2000 09:53:42 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NW0E/zN057c3sUj2KBX8BA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Approved-By: James Kempf Message-ID: <200012011753.JAA07901@nasnfs.eng.sun.com> Date: Fri, 1 Dec 2000 09:53:16 -0800 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location X-To: Hesham.Soliman@ericsson.com.au To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I'm not going to try to reply to the individual messages on this thread, but I wanted to give some more details in how IAPP might be used to allow remotely located FAs to perform pro-active handoff. To the extent that Hesham's fast handoff proposal requires modification or help from the link layer, these mechanisms could also be used with the fast handoff proposal as well. The IAPP protocol spec dated 1998 is pretty much set up for access points to exchange information between themselves. An access point multicasts an ANNOUNCE request to determine what other access points are up. The access points reply. The request is not restricted to a single subnet a priori, since IP multicast is used. When an IEEE 802.11 L2 reassociation occurs (at the mobile's request, as is always the case in 802.11, the network has little say in the matter), the access point sends a HANDOFF request message to the old access point *after* the link layer reassociation has occured. The link layer reassociation occurs immediately, that is, the access point does not wait on the old point's reply to perform the handover. The HANDOFF request message to the old point is primarily to allow the old point to release resources dedicated to the mobile. As was pointed out, in order for a remote FA to get involved, it would have to be forwarded the HANDOFF request message from the old point, or, alternatively, it would have to act as a broker between the old and new points. As a broker, the FA would respond to the ANNOUNCE request rather than the access point directly, and the new access point would send the HANDOFF message to the FA instead of the old access point. The FA would forward the message to the old access point, and would take appropriate action to perform pro-active handoff at the IP layer for the mobile. Naturally, having the FA co-located with the access point is likely to be much faster, since the IP layer signalling associated with IAPP would not be involved. The FA can take advantage of the link layer reassociation request from 802.11 to perform handoff much more quickly. I don't know what the current status of IAPP is in the IEEE, but I would not be suprised if it either has been dropped or has undergone significant modification in the two years since the spec I've got was published. So I think the upshot of this thread is that whether or not the FA is remote is really an implementation issue for 802.11. Pro-active handoff can be supported at a remote FA with the minimal modification to IAPP, and IAPP is not L2, so there is no need for modification in L2 to support pro-active handoff. To the extent that fast handoff requires L2 support, it too could benefit from having IAPP, since it would also allow remote FAs. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 1 17:07:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03618 for ; Fri, 1 Dec 2000 17:06:58 -0500 (EST) Received: from standards (47.234.32.16:3349) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE18F@standards.nortelnetworks.com>; Fri, 1 Dec 2000 16:45:26 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 152967 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Dec 2000 16:45:26 -0500 Received: from alemail1.firewall.lucent.com (alemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE18D@standards.nortelnetworks.com>; Fri, 1 Dec 2000 16:45:25 -0500 Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA07187 for ; Fri, 1 Dec 2000 15:45:53 -0500 (EST) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA07179 for ; Fri, 1 Dec 2000 15:45:53 -0500 (EST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 14:45:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Dolan, Michael F (Mike)" Message-ID: Date: Fri, 1 Dec 2000 14:45:35 -0600 Reply-To: "Dolan, Michael F (Mike)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Dolan, Michael F (Mike)" Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hesham, Pat, It seems that we need to put some specific bounds on handoff times that need to be accomodated. It is true that in many cases in CDMA systems, the Base Station will know several hundreds of milliseconds ahead of time that a handoff will occur. However, this cannot be guaranteed in all cases. In dense urban situations where there are tall buildings and lots of metal objects, handoff can be precipitated very quickly with very little advance time to set up for it, due to the abrupt radio effects that can exist. Let me propose a bound of 250 milliseconds (250ms) from the time that the need for a handoff is detected until the handoff must be completed. This is an arbitrary number, but it is about the amount of time it would take for a person to walk through some metal doors into a new radio environment. It is also very reasonable that there will be several possible new FAs available to a MN at one time. Example: a person using a MN (IP-based phone) walking in downtown New York connected to a CDMA system walks around a building corner. The MN detects both another CDMA Base Station and an 802.11b Base Station, while maintaining contact with its current CDMA Base Station. The person might walk into the entrance of the building (802.11b environment), or could continue to walk down the street. With which, if any, FA should the MN begin a new registration? In one proposed solution, the "old" CDMA Base Station would be sending the advertisement for other FAs. Should it send both advertisements? How should the MN choose which to initiate? What if it chooses incorrectly? What if it attempts new registrations on both, "just to be safe?" In another solution, the "old" CDMA Base Station gets radio level readings from the MN and chooses the system to receive the handoff (a second CDMA Base Station, or an 802.11b Base Station in the example above). In this solution, the "old" Base Station can react quickly to radio environment changes (including support of the MN returning to the "old" Base Station upon handoff failure). Interaction with other Base Stations at the Link Layer to coordinate the handoff can result in a smooth transition of the application stream. Coordination among those Base Stations and the FAs to continue the stream until a new MIP registration can be achieved can provide the support for the 250ms bound proposed. As has been discussed in several places already, tunneling between the FAs or between the Base Stations can support stream continuation. Other solutions? Thoughts? A different value than 250ms for a bound? Have a good day, Mike Dolan Lucent Technologies mfdolan@lucent.com Hesham Soliman wrote: > > => I agree that the two proposals are very similar. They both > > support > > simultaneous bindings and other similar concepts. > > Apart from the list of differences we discussed, I see a > difference > > in the dependancy on certain architectures. You might think that > > this is an implementation issue, but it's important to highlight > it. > > > > In some cases the changes required to support the assumed > > architecture may not be trivial. > > Correct, but the design choices made also allow the proposal to be used > with > even the strictest of link layers (ones that INFORM the mobile that a > handoff > is in process). > => These link layers are much more sophisticated than others because they know where the MN is going. I think that makes it easier to accomodate MIP since you're getting good hints. FH also supports that case by sending the proxy advertisement to the MN from the current FA. > In these wireless networks, there is no additional time for > Mobile IP registration. > => Which wireless links ? CDMA for example ? As we mentioned during the meetings, we looked at these handoff sequences and found that there is time and it is certainly possible to support FH. CDMA is much more flexible in terms of handoff times than other wireless systems. > However, you failed to address my comment where I stated that this > co-location > issue is NOT a pro-active problem, since the fast handoff proposal uses > similar triggers. Both proposals require colocated AP/FAs. > => The FH model allows for both MN initiation and FA initiation. Therefore I don't see why it would need this colocation. You also didn't answer my comments on IAPP :) Hesham From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 1 18:11:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23314 for ; Fri, 1 Dec 2000 18:11:35 -0500 (EST) Received: from standards (47.234.32.16:3929) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE245@standards.nortelnetworks.com>; Fri, 1 Dec 2000 17:52:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 153205 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Dec 2000 17:52:26 -0500 Received: from mailhub1.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE243@standards.nortelnetworks.com>; Fri, 1 Dec 2000 17:52:26 -0500 Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.16 #1) id 141zJO-0004xr-00; Fri, 01 Dec 2000 23:09:50 +0000 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 1 Dec 00 23:09:50 +0000 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 1 Dec 00 23:09:39 +0000 Received: from Mobile1 (143.167.59.139) by ridingwood.shef.ac.uk (Mercury 1.48); 1 Dec 00 23:09:37 +0000 References: <017301c05b04$23cda390$923ba78f@Mobile1> <3A280324.582B427F@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Approved-By: cnyap Message-ID: <00d601c05beb$5fe18030$923ba78f@Mobile1> Date: Fri, 1 Dec 2000 23:06:44 -0000 Reply-To: cnyap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cnyap Subject: Re: [MOBILE-IP] draft agenda (about Homeless draft) X-cc: Roberts Philip-qa3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all, About 6 months ago, IIP is being rejected in Mobile Working Group, as "IIP concept is out of the scope of the working group". Here goes: ----- Original Message ----- From: To: Cc: Sent: Thursday, July 06, 2000 1:34 PM Subject: RE: Timeslot requests > > Hi, > > I have a couple of concerns regarding your request for > timeslots at the Mobile IP WG sessions at IETF48. > > 1. The normal time allocated for any single topic for discussion > is about 10~20 minutes. You had asked for a total of an hour > for presenting two concepts (IIP and MVPN). > > 2. RFC2002, 2002bis and, Mobile IP for IPV6 are what has been well > accepted as the mechanisms for IP mobility. If you look at the > scope of the WG charter what we are essentially seeking is specific > solutions to make the MIP protocol suitable for deployment on a > large scale in the real world. What we are not seeking is a new > solution for doing mobility. As you mentioned IIP is yet another > solution for achieving IP mobility and this is outside the scope > of the charter. > > However I do not mean to discourage the work that is being done in IIP. > Because of the limited time that we have at the meetings (IETF48) we > will be prioritizing the presentation topics based on the scope of the > charter. At the present time we do not see a great deal of interest in > IIP. If there is a sufficient amount of interest in IIP, then we can > possibly include it on the agenda, but at the present time I doubt that. > It is up to you to generate interest in the IIP concept. > > The MVPN concept is something that is more applicable to the Mobile IP > WG. Hence we will try and schedule a 10~15 minute slot for MVPN. > We will be announcing the first draft agenda of the Mobile IP WG schedule > next week. > > If you have any questions or concerns, please do not hesitate to contact > me or Phil. > > Regards, > > -Basavaraj > last week, I was told that there is another draft has "IIP concept" and it is accepted to have a time slot in IETF meeting. Here goes: ----- Original Message ----- From: "Pekka Nikander" To: Cc: ; ; ; ; Sent: Tuesday, November 21, 2000 6:07 AM Subject: Possibly joining draft-cnyap-iip-01.txt and draft-nikander-mobileip-homelessv6-00.txt > We recently published the initial results of our work considering > Mobile IPv6 in ad hoc networks as an internet draft, > http://www.ietf.org/internet-drafts/draft-nikander-mobileip-homelessv6-00.tx t > > Now I have been looking at related work, and it seems to me that > your draft draft-cnyap-iip-01.txt is more or less based on the > same fundamental ideas, but attempts to solve the problem in > a different way. > > Now, my question is whether you are pursuing your work further, > and if so, would you see any benefits if we attempt to join > forces? > > Yours, > > --Pekka Nikander > Ericsson Research Nomadiclab What is scope of the charter now? Cheers Chern Nam Yap From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 1 19:09:45 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08969 for ; Fri, 1 Dec 2000 19:09:44 -0500 (EST) Received: from standards (47.234.32.16:2455) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE2A5@standards.nortelnetworks.com>; Fri, 1 Dec 2000 18:50:32 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 153336 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Dec 2000 18:50:32 -0500 Received: from mailhub1.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE2A3@standards.nortelnetworks.com>; Fri, 1 Dec 2000 18:50:31 -0500 Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.16 #1) id 1420Dc-0005Iw-00 for MOBILE-IP@standards.nortelnetworks.com; Sat, 02 Dec 2000 00:07:56 +0000 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 2 Dec 00 00:07:56 +0000 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 2 Dec 00 00:07:50 +0000 Received: from Mobile1 (143.167.59.139) by ridingwood.shef.ac.uk (Mercury 1.48); 2 Dec 00 00:07:50 +0000 References: <200012011753.JAA07901@nasnfs.eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Approved-By: cnyap Message-ID: <018f01c05bf3$8186ce90$923ba78f@Mobile1> Date: Sat, 2 Dec 2000 00:04:57 -0000 Reply-To: cnyap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cnyap Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all, Sorry to mention this again No matter how "pro-active" any method can be, In CDMA you would not be able transmit IP packet before the PPP session is set up. Correct if I am wrong. Cheers Chern Nam Yap MIEEE, MSc(Res), BSc(Hons) Research Associate Center for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield F132 Mappin Building Mappin Street Sheffield S1 3JD United Kingdom Tel:+44 (0) 114-222-5182 Mobile:+ 44(0) 7712804892 Web: www.mobile1.net E-mail: cny@ieee.org From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 1 19:48:05 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17166 for ; Fri, 1 Dec 2000 19:48:05 -0500 (EST) Received: from standards (47.234.32.16:2455) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE2FE@standards.nortelnetworks.com>; Fri, 1 Dec 2000 19:28:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 153457 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Dec 2000 19:28:53 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE2FC@standards.nortelnetworks.com>; Fri, 1 Dec 2000 19:28:52 -0500 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA09259; Fri, 1 Dec 2000 16:46:11 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA23640; Fri, 1 Dec 2000 16:46:11 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA19397; Fri, 1 Dec 2000 16:46:04 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Approved-By: Pat Calhoun Message-ID: Date: Fri, 1 Dec 2000 16:43:03 -0800 Reply-To: Pat Calhoun Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pat Calhoun Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location X-To: cnyap To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <018f01c05bf3$8186ce90$923ba78f@Mobile1> > Hi all, > > Sorry to mention this again > No matter how "pro-active" any method can be, > In CDMA you would not be able transmit IP packet > before the PPP session is set up. Correct, but PPP is supported for legacy reasons. I am not sure that it will perpetuate in future architecturessince its usefulness is dubious when new technologies, such as ROHC, are introduced. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Dec 2 10:17:20 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19630 for ; Sat, 2 Dec 2000 10:17:19 -0500 (EST) Received: from standards (47.234.32.16:2085) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE48D@standards.nortelnetworks.com>; Sat, 2 Dec 2000 9:57:52 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 154021 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 2 Dec 2000 09:57:51 -0500 Received: from maynard.mail.mindspring.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE48B@standards.nortelnetworks.com>; Sat, 2 Dec 2000 9:57:51 -0500 Received: from jewels (nyf-ny3-28.ix.netcom.com [198.211.16.156]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with SMTP id KAA07135; Sat, 2 Dec 2000 10:15:16 -0500 (EST) X-Sender: mscorson@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Approved-By: "M. Scott Corson" Message-ID: <3.0.6.32.20001202102209.009129d0@popd.ix.netcom.com> Date: Sat, 2 Dec 2000 10:22:09 -0500 Reply-To: "M. Scott Corson" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "M. Scott Corson" Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location X-To: campbell@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <3A275F9A.A0572D80@comet.columbia.edu> >Reality check: > >IP isn't designed for Ethernet and Mobile IP not for CDMA. >But Ethernet is THE link layer and CDMA (W or 2000) will >likely be THE wireless link for 2.5G, 3G, 4G (whatever that >is), WLAN (802.Xs), etc. > >Should we get real - or not? Reality? You can predict reality? For how long? Do you give stock advice as well? ;-) Seriously, probably not a good idea to assume/predict anything regarding air interface technology going forwards...let's leave the IP stuff wide open for all types of link layers in accordance with its basic architectural philosophy. In that spirit it's generally not a good idea to put a lot of bits over the old link during handoff, because it may be getting lousy which is why you are then handing off. Whether you can predict handoff in advance with high probability also depends on the technology. IP standards should remain wide open, flexible and designed to work well for the worst-case (poor old links, no prediction). The other cases are generally only easier and can be handled with appropriate implementations. Layer 3 messaging over the old link, to the extent that it is even useful in IPv4 (debatable), should at most be an option, but not a required part of fast handoff. On that basis I largely favor the pro-active draft. -Scott From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Dec 2 19:19:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29966 for ; Sat, 2 Dec 2000 19:19:37 -0500 (EST) Received: from standards (47.234.32.16:4207) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE5EF@standards.nortelnetworks.com>; Sat, 2 Dec 2000 19:00:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 154532 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 2 Dec 2000 19:00:04 -0500 Received: from mailbreak.com (216.207.225.170:1323) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE5ED@standards.nortelnetworks.com>; Sat, 2 Dec 2000 19:00:04 -0500 Received: from SOLID [166.84.159.26] by mailbreak.com [216.207.225.174] with SMTP (MDaemon.v3.5.0.R) for ; Sat, 02 Dec 2000 19:10:22 -0500 References: <3.0.6.32.20001202102209.009129d0@popd.ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MDRemoteIP: 166.84.159.26 X-Return-Path: eunsoo@ctr.columbia.edu X-MDaemon-Deliver-To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Approved-By: Eunsoo Shim Message-ID: <006001c05cbe$fe0e3720$6401a8c0@SOLID> Date: Sat, 2 Dec 2000 19:21:33 -0500 Reply-To: Eunsoo Shim Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Eunsoo Shim Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit > >Reality check: > > > >IP isn't designed for Ethernet and Mobile IP not for CDMA. > >But Ethernet is THE link layer and CDMA (W or 2000) will > >likely be THE wireless link for 2.5G, 3G, 4G (whatever that > >is), WLAN (802.Xs), etc. > > > >Should we get real - or not? > > Reality? You can predict reality? For how long? Do you give stock advice > as well? ;-) > > Seriously, probably not a good idea to assume/predict anything regarding > air interface technology going forwards...let's leave the IP stuff wide > open for all types of link layers in accordance with its basic > architectural philosophy. > Following this philosophy, I think soft handoff in link layers also should be considered as a special case even though it is available in the upcoming 3G wireless networks (WCDMA, CDMA2000) and the current 802.11 WLAN. Thus I am not sure it is a good assumption that the mobile node or the old FA can figure out the new FA's IP address exactly from the link layer information while the mobile node is attached to the old BS(or FA). I think the assumption is in both of the drafts (Proactive Handoff, Fast Handoff) on the table. Eunsoo > In that spirit it's generally not a good idea to put a lot of bits over the > old link during handoff, because it may be getting lousy which is why you > are then handing off. Whether you can predict handoff in advance with high > probability also depends on the technology. > > IP standards should remain wide open, flexible and designed to work well > for the worst-case (poor old links, no prediction). The other cases are > generally only easier and can be handled with appropriate implementations. > > Layer 3 messaging over the old link, to the extent that it is even useful > in IPv4 (debatable), should at most be an option, but not a required part > of fast handoff. > > On that basis I largely favor the pro-active draft. > > -Scott > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Dec 2 20:02:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04712 for ; Sat, 2 Dec 2000 20:02:00 -0500 (EST) Received: from standards (47.234.32.16:4207) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE666@standards.nortelnetworks.com>; Sat, 2 Dec 2000 19:42:46 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 154699 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 2 Dec 2000 19:42:46 -0500 Received: from ish7.ericsson.com.au (203.61.155.111:51247) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE664@standards.nortelnetworks.com>; Sat, 2 Dec 2000 19:42:45 -0500 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA14503 for ; Sun, 3 Dec 2000 11:56:41 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id LAA02403 for ; Sun, 3 Dec 2000 11:59:34 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Sun, 3 Dec 2000 11:59:52 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Approved-By: "Hesham Soliman (EPA)" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613EED@eaubrnt018.epa.ericsson.se> Date: Sun, 3 Dec 2000 11:59:50 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Pete, > Two points: > > 1) Handoff Timing. > > For cdma2000, there is at most a couple of hundred milliseconds between > the time that the BSC recognizes the need for a handoff and the time the > handoff must take place. The reason for this deadline is that the radio > channel to the current MN is fading quickly, but the final "handoff order" > telling the MN to connect to the new BSC must be sent over the air before > connectivity is lost. > > Putting over-the-air Mobile IP signaling on the critical path will almost > certainly cause us to miss this deadline in some cases, resulting in lost > calls. Remember it's not just the new messages but also operating system > scheduling that we have to worry about. > > We are working to gather some more specific delay numbers/lost call > probabilities and we can discuss in San Diego. > => Please refer to Krim's email on the timing issue. There is no need to assume that L3 handoff is the last step in the L2 handoff. > 2) IAPP > > I don't know much about 802.11, but it occurred to me in Pittsburgh > that you could probably deploy some kind of "smart bridge" between the > two networks that would watch IAPP traffic on both of them, and by > collating the results you would be able to figure out where a MN came > from. This would enable you to send a pro-active trigger or even to > start bridging the MN's traffic to/from the old network, obviating the > need for any MIP messaging. The extra box might sound like a > heavyweight solution but it would really be no more onerous than the > handoff mechanisms currently in place between cellular coverage areas. > FA addresses would of course need to be provisioned during the > coverage planning stage and when forming handoff agreements with > neighboring carriers. > => Exactly the answer to my earlier question. Thanks. Yes in this case the FA would know that the MN has moved provided it listens to IAPP messages. But it won't know that it's about to move. Hesham From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Dec 2 22:38:06 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24368 for ; Sat, 2 Dec 2000 22:38:05 -0500 (EST) Received: from standards (47.234.32.16:2503) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE6F0@standards.nortelnetworks.com>; Sat, 2 Dec 2000 22:18:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 154887 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 2 Dec 2000 22:18:43 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE6EE@standards.nortelnetworks.com>; Sat, 2 Dec 2000 22:18:43 -0500 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA22386; Sat, 2 Dec 2000 19:36:10 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA15835; Sat, 2 Dec 2000 19:36:09 -0800 (PST) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id TAA23626; Sat, 2 Dec 2000 19:36:07 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5kDmSGhxRu0eRk0m7bhWIg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Approved-By: James Kempf Message-ID: <200012030336.TAA23626@nasnfs.eng.sun.com> Date: Sat, 2 Dec 2000 19:35:44 -0800 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location X-To: eunsoo@ctr.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >Following this philosophy, I think soft handoff in link layers also should >be considered as a special case even though it is available in the upcoming >3G wireless networks (WCDMA, CDMA2000) and the current 802.11 WLAN. Not sure what you mean by "soft handoff" here, but my understanding of 802.11 is that it does "break before make" and that there are not multiple outstanding physical data streams corresponding to one logical data stream on the MN or CN. This is typically what's called soft handoff in CDMA. >Thus I >am not sure it is a good assumption that the mobile node or the old FA can >figure out the new FA's IP address exactly from the link layer information >while the mobile node is attached to the old BS(or FA). I think the >assumption is in both of the drafts (Proactive Handoff, Fast Handoff) on the >table. > jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Dec 2 23:06:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27505 for ; Sat, 2 Dec 2000 23:06:42 -0500 (EST) Received: from standards (47.234.32.16:2503) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE756@standards.nortelnetworks.com>; Sat, 2 Dec 2000 22:47:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 155021 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 2 Dec 2000 22:47:21 -0500 Received: from ish7.ericsson.com.au (203.61.155.111:52339) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE754@standards.nortelnetworks.com>; Sat, 2 Dec 2000 22:47:20 -0500 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id PAA15888 for ; Sun, 3 Dec 2000 15:01:17 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA07638 for ; Sun, 3 Dec 2000 15:04:10 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Sun, 3 Dec 2000 15:04:28 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Approved-By: "Hesham Soliman (EPA)" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613EF3@eaubrnt018.epa.ericsson.se> Date: Sun, 3 Dec 2000 15:04:26 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Seriously, probably not a good idea to assume/predict anything regarding > > air interface technology going forwards...let's leave the IP stuff wide > > open for all types of link layers in accordance with its basic > > architectural philosophy. > > > > Following this philosophy, I think soft handoff in link layers also should > be considered as a special case even though it is available in the > upcoming > 3G wireless networks (WCDMA, CDMA2000) and the current 802.11 WLAN. > => I'm not sure how this statement follows the earlier comment. Anyway why is soft handoff relevant here ? > Thus I > am not sure it is a good assumption that the mobile node or the old FA can > figure out the new FA's IP address exactly from the link layer information > while the mobile node is attached to the old BS(or FA). I think the > assumption is in both of the drafts (Proactive Handoff, Fast Handoff) on > the > table. > => Perhaps you could elaborate on how this conclusion is made based on your earlier statement. I can't follow the logic of your argument. I don't see why it would be difficult for an FA to map some system information (I'm not using L2 because as James mentioned earlier it's not exactly L2) to an IP address. Hesham From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Dec 2 23:32:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00698 for ; Sat, 2 Dec 2000 23:32:29 -0500 (EST) Received: from standards (47.234.32.16:3866) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE7AB@standards.nortelnetworks.com>; Sat, 2 Dec 2000 23:13:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 155137 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 2 Dec 2000 23:13:21 -0500 Received: from ish7.ericsson.com.au (203.61.155.111:52489) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE7A9@standards.nortelnetworks.com>; Sat, 2 Dec 2000 23:13:20 -0500 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id PAA16105 for ; Sun, 3 Dec 2000 15:27:16 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA08330 for ; Sun, 3 Dec 2000 15:30:10 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Sun, 3 Dec 2000 15:30:28 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Hesham Soliman (EPA)" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613EF6@eaubrnt018.epa.ericsson.se> Date: Sun, 3 Dec 2000 15:30:26 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Michael, Thanks for the analysis. Some comments below. A general comment, you're mentioning Base stations often and in different contexts which puzzles me about how you assume the role of a base station in the L3 handoff scenario. I prefer to talk about FAs instead. It is less presumptious and is relevant for the L3 handoffs. Regards, Hesham It seems that we need to put some specific bounds on handoff times that need to be accomodated. It is true that in many cases in CDMA systems, the Base Station will know several hundreds of milliseconds ahead of time that a handoff will occur. However, this cannot be guaranteed in all cases. In dense urban situations where there are tall buildings and lots of metal objects, handoff can be precipitated very quickly with very little advance time to set up for it, due to the abrupt radio effects that can exist. Let me propose a bound of 250 milliseconds (250ms) from the time that the need for a handoff is detected until the handoff must be completed. This is an arbitrary number, but it is about the amount of time it would take for a person to walk through some metal doors into a new radio environment. => The issue here is where in the handoff process these 250 ms fit. I'd like to refer you to Karim's earlier mail about this, in which he says "You must be assuming that the L3 registration is done after a certain point during the L2 procedure after which there is no time. I can't see a reason why the MIP registration can't be started before that point in time. The L2 and L3 handoff procedures could almost proceed alongside in which case your argument would not be valid". So putting time restrictions is certainly important and no one would disagree with you on that. However, assuming that L3 handoff will only take place at the last stage where certainly (as you mentioned) there might not be time in some cases, makes strong assumptions about how MIP should be used in other systems. None of the MIP specs or the Fast Handover draft make any assumption about where L3 handover should start, and whether this takes place on a bearer channel, common channel ...etc These are are extremely specific issues that we are not qualified to decide upon. Therefore it is best that we leave it up to the relevant system designers. It is also very reasonable that there will be several possible new FAs available to a MN at one time. Example: a person using a MN (IP-based phone) walking in downtown New York connected to a CDMA system walks around a building corner. The MN detects both another CDMA Base Station and an 802.11b Base Station, while maintaining contact with its current CDMA Base Station. The person might walk into the entrance of the building (802.11b environment), or could continue to walk down the street. With which, if any, FA should the MN begin a new registration? => Network planners should decide on the amount of overlap required. As to your question on which FA it should choose, well that depeneds of course on which direction that person will continue to walk on, but of course we can't be certain about that, so perhaps that person would choose to connect to both for some time until he/she is sure where they're going. In one proposed solution, the "old" CDMA Base Station would be sending the advertisement for other FAs. Should it send both advertisements? => Not necessarily, it can choose to send the one for the CDMA FA only, the other FA can send its own solicited or unsolicited advertisement. How should the MN choose which to initiate? => I would expect that users may have certain preferences based on the applications being used, the types of links available ...etc. So to answer your question, a user profile can help. What if it chooses incorrectly? What if it attempts new registrations on both, "just to be safe?" => Please see my comment above. In another solution, the "old" CDMA Base Station gets radio level readings from the MN and chooses the system to receive the handoff (a second CDMA Base Station, or an 802.11b Base Station in the example above). => Are you proposing that the L3 handoff has to be handled on Base station level ? Perhaps a clarification of this would help. In this solution, the "old" Base Station can react quickly to radio environment changes (including support of the MN returning to the "old" Base Station upon handoff failure). Interaction with other Base Stations at the Link Layer to coordinate the handoff can result in a smooth transition of the application stream. => So this solution expects interaction between those "CDMA" Base stations and 802.11 Base stations as well as FAs ? But wouldn't it be even quicker if we just coordinate on a base station level. If inter-radio technology interaction is expected anyway then why do we need MIP ? This is certainly another valid alternative. We could have convergence layers that allow different access technologies to handoff the MN to each other and there would be no need for MIP in this case. Of course the disadvantage is, we're handing off that user without his/her choice. So is that what we want ? My understanding is that RFC2002 mandates that user choice, by not allowing packets to be routed to another FA unless the user authorises that. Coordination among those Base Stations and the FAs to continue the stream until a new MIP registration can be achieved can provide the support for the 250ms bound proposed. As has been discussed in several places already, tunneling between the FAs or between the Base Stations can support stream continuation. => Sure you'll meet that 250 ms deadline which based on your assumption of how L2 and L3 should interact in a CDMA system. I would argue that this assumption is not needed and I refer you to Karim's statement above. The reason we shouldn't make these assumptions, is that while timing is crucial for a handoff, there are also other important considerations for a MIP handoff. Like looking into which types of access are possible and making a choice based on what the user needs. The generic nature of MIP needs to be maintained. Regards, Hesham From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Dec 2 23:41:06 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01720 for ; Sat, 2 Dec 2000 23:41:05 -0500 (EST) Received: from standards (47.234.32.16:3866) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE7F9@standards.nortelnetworks.com>; Sat, 2 Dec 2000 23:21:49 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 155244 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 2 Dec 2000 23:21:48 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE7F7@standards.nortelnetworks.com>; Sat, 2 Dec 2000 23:21:48 -0500 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA25896; Sat, 2 Dec 2000 20:39:16 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA18429; Sat, 2 Dec 2000 20:39:15 -0800 (PST) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id UAA24514; Sat, 2 Dec 2000 20:39:14 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: F+sk1suPnaSsI6ATJLQ4+g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Approved-By: James Kempf Message-ID: <200012030439.UAA24514@nasnfs.eng.sun.com> Date: Sat, 2 Dec 2000 20:38:50 -0800 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location X-To: Hesham.Soliman@ericsson.com.au To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hesham, > => The issue here is where in the handoff process these 250 ms > fit. I'd like to refer you to Karim's earlier mail about this, in >which > he says "You must be assuming that the L3 registration is done > after a certain point during the L2 procedure after which there is no >time. > I can't see a reason why the MIP registration can't be started before >that > point in time. The L2 and L3 handoff procedures could almost > proceed alongside in which case your argument would not be valid". The problem with starting the MIP registration before the L2 handoff is complete is that the mobile may undergo ping-ponging and may end up back on the subnet controlled by the original FA before the L2 registration completes. Or even on a third subnet. The pro-active handoff draft contains some specific design considerations to take this into account. I don't know how common ping-ponging is, but it apparently does occur in the real world and so needs to be accommondated. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Dec 2 23:48:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02572 for ; Sat, 2 Dec 2000 23:48:23 -0500 (EST) Received: from standards (47.234.32.16:3866) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE83C@standards.nortelnetworks.com>; Sat, 2 Dec 2000 23:26:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 155332 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 2 Dec 2000 23:26:58 -0500 Received: from ish7.ericsson.com.au (203.61.155.111:52555) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE83A@standards.nortelnetworks.com>; Sat, 2 Dec 2000 23:26:57 -0500 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id PAA16204 for ; Sun, 3 Dec 2000 15:40:54 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA08689 for ; Sun, 3 Dec 2000 15:43:47 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Sun, 3 Dec 2000 15:44:05 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Approved-By: "Hesham Soliman (EPA)" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613EF7@eaubrnt018.epa.ericsson.se> Date: Sun, 3 Dec 2000 15:44:03 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM James, > > => The issue here is where in the handoff process these 250 ms > > fit. I'd like to refer you to Karim's earlier mail about this, in > >which > > he says "You must be assuming that the L3 registration is done > > after a certain point during the L2 procedure after which there is > no > >time. > > I can't see a reason why the MIP registration can't be started > before > >that > > point in time. The L2 and L3 handoff procedures could almost > > proceed alongside in which case your argument would not be > valid". > > The problem with starting the MIP registration before the L2 handoff is > complete is that the mobile may undergo ping-ponging and may end up > back on the subnet controlled by the original FA before the L2 > registration > completes. Or even on a third subnet. The pro-active handoff draft > contains some > specific design considerations to take this into account. I don't know how > > common ping-ponging is, but it apparently does occur in the real world and > so needs to be accommondated. > => I beleive ping pong is supported by both proposals. In FH simultaneous bindings are used just like the proactive approach does. Hesham From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Dec 2 23:53:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03183 for ; Sat, 2 Dec 2000 23:53:52 -0500 (EST) Received: from standards (47.234.32.16:3866) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE89F@standards.nortelnetworks.com>; Sat, 2 Dec 2000 23:33:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 155469 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 2 Dec 2000 23:33:57 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE89D@standards.nortelnetworks.com>; Sat, 2 Dec 2000 23:33:57 -0500 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA26598; Sat, 2 Dec 2000 20:51:24 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA18840; Sat, 2 Dec 2000 20:51:24 -0800 (PST) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id UAA24696; Sat, 2 Dec 2000 20:51:16 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: OS0Pg7sBDalgAUZdr1kLxQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Approved-By: James Kempf Message-ID: <200012030451.UAA24696@nasnfs.eng.sun.com> Date: Sat, 2 Dec 2000 20:50:52 -0800 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location X-To: Hesham.Soliman@ericsson.com.au To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hesham, >James, > > >> > => The issue here is where in the handoff process these 250 ms >> > fit. I'd like to refer you to Karim's earlier mail about this, in >> >which >> > he says "You must be assuming that the L3 registration is done >> > after a certain point during the L2 procedure after which there is >> no >> >time. >> > I can't see a reason why the MIP registration can't be started >> before >> >that >> > point in time. The L2 and L3 handoff procedures could almost >> > proceed alongside in which case your argument would not be >> valid". >> >> The problem with starting the MIP registration before the L2 handoff is >> complete is that the mobile may undergo ping-ponging and may end up >> back on the subnet controlled by the original FA before the L2 >> registration >> completes. Or even on a third subnet. The pro-active handoff draft >> contains some >> specific design considerations to take this into account. I don't know how >> >> common ping-ponging is, but it apparently does occur in the real world and >> so needs to be accommondated. >> > => I beleive ping pong is supported by both proposals. In FH > simultaneous bindings are used just like the proactive approach > does. You didn't read my comment. I didn't say it wasn't supported in FH, I said that Karim's comment that one could start the MIP registration before the L2 handoff won't work in the real world. jak > Hesham From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Dec 3 16:25:59 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10029 for ; Sun, 3 Dec 2000 16:25:59 -0500 (EST) Received: from standards (47.234.32.16:3981) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBEB5C@standards.nortelnetworks.com>; 3 Dec 2000 16:06:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 156460 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 3 Dec 2000 16:06:43 -0500 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBEB5A@standards.nortelnetworks.com>; 3 Dec 2000 16:06:42 -0500 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eB3LO5430007; Sun, 3 Dec 2000 22:24:05 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id WAA18961; Sun, 3 Dec 2000 22:24:04 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id WAA27803; Sun, 3 Dec 2000 22:24:27 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Approved-By: Francis.Dupont@ENST-BRETAGNE.FR Message-ID: <200012032124.WAA27803@givry.rennes.enst-bretagne.fr> Date: Sun, 3 Dec 2000 22:24:27 +0100 Reply-To: Francis Dupont Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] WG Last Call: Mobile IP v6:draft-ietf-mobileip-ipv6-13.txt X-To: Roberts Philip-qa3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Tue, 21 Nov 2000 09:27:36 CST. The section 10.20 Returning Home is still wrong about neighbor discovery issue, it states that: If the mobile node does Neighbor Solicitation to learn the home agent's link-layer address, in this special case of the mobile node returning home, the mobile node MUST unicast the packet, and in addition set the Source Address of this Neighbor Solicitation to the unspecified address (0:0:0:0:0:0:0:0). Since the solicitation is unicast, the home agent will be able to distinguish from a similar packet that would only be used for DAD. The previous I-D doesn't mandate unicast (the change seems to be an answer to my concern with I-D 12) but this cannot work because the mobile node needs the home agent's link-layer in order to unicast a neighbor solicitation to the home agent... The mobile node MUST multicast the neighbor solicitation to the solicited-node multicast address of the home agent (this doesn't need to be in the next draft but changes should explain why multicast doesn't work). The problem is with the source address, if no address of the mobile node can be used then the mobile node MAY use the unspecified address (::)... (we should keep a MAY because even if the home agent should take it as a DAD for its own address it works, but it must be used only when there is no obvious solution, as using the link-local address when it is not registered/protected). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Dec 3 16:36:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13248 for ; Sun, 3 Dec 2000 16:36:15 -0500 (EST) Received: from standards (47.234.32.16:3981) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBEBC0@standards.nortelnetworks.com>; 3 Dec 2000 16:16:48 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 156593 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 3 Dec 2000 16:16:47 -0500 Received: from d248-38.pekka.nikander.com (194.241.248.38:4428) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBEBBE@standards.nortelnetworks.com>; 3 Dec 2000 16:16:46 -0500 Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.43]) by d248-38.pekka.nikander.com (8.9.3/8.9.3) with ESMTP id XAA79345; Sun, 3 Dec 2000 23:58:53 +0200 (EET) (envelope-from Pekka.Nikander@nomadiclab.com) User-Agent: Mozilla/5.0 (Macintosh; N; PPC; en-US; m18) Gecko/20001127 X-Accept-Language: en MIME-Version: 1.0 References: <017301c05b04$23cda390$923ba78f@Mobile1> <3A280324.582B427F@nomadiclab.com> <00d601c05beb$5fe18030$923ba78f@Mobile1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Pekka Nikander Message-ID: <3A2C0DD9.30009@nomadiclab.com> Date: Mon, 4 Dec 2000 23:34:17 +0200 Reply-To: Pekka Nikander Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pekka Nikander Subject: [MOBILE-IP] Homeless vs. IIP - differences and similarities (was Re: [MOBILE-IP] draft agenda (about Homeless draft)) X-cc: cnyap , Bengt Sahlin , janne.lundberg@hut.fi, catharina.candolin@hut.fi, tuomas.aura@hut.fi To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Chern Yan Nap has raised the point whether our "Homeless Mobile IPv6" draft is appropriate to be considered at the Mobile IP WG or not. Based on that both their IIP draft and our Homeless draft try to solve some of the same problems, though through a slightly different angle, I try to highlight the differences between the drafts. My aim is to keep this message solely on technical issues. APPARENT DIFFERENCES First, the superficial, immediately apparent differences: - Homeless is suggested to be experimental only (at least at this stage), IIP does not mention whether it aims to be on the standards track or not. - Homeless proposes an backward compatible extension to MIPv6. IIP proposes a completely new protocol. - Homeless is proposed for IPv6 only, IIP for both IPv4 and IPv6. F - Homeless is _primarily_ targeted for infrastructureless operations where there may not be any home agents, home location registers, foreign agents, or visitor location registers. On the other hand, it can utilize MIP home agents, Dynamic DNS, SIP, or other means as the initial discovery protocol. And it proposes that home agents are used to solve the double jump problem. IIP, on the other hand, still relies more-or-less centralized components, the base home register (BHR) and temporary visit register (TVR). However, it _does_ take the proposition that a TRV can be "upgraded" to act as a new BHR. - Homeless does not _need_ any new wire protocol, even though it does propose a couple new MIPv6 suboptions. IIP proposes that signalling is performed out-of-band, using UDP packets. KERNEL DATA STRUCTURE DIFFERENCES The deeper, and more interesting difference lies in the proposed kernel data structures. I'll first consider IIP, and then describe both what is proposed in Homeless, and the thinking behind it. The IIP Binding Cache is based on pairs. The home/visit address is always used as a key to search the cache when sending packets. IIP specifies that packets may be sent using the co-located address as the source address, but it is not very specific how the receiver would find the right socket. !The sockets contain, as usual, the home/visit addresses. In the Homeless draft, the Binding Cache is replaced with what we call "the Host Cache". In a way, the Host cache is a generalized data structure that more or less combines the MIPv6 Binding Cache and Binding Update List into a single, fully symmetric data structure. To make this point more apprarent, let me start from the standard MIPv6 Binding Cache. Let's consider three Mobile Nodes, all communicating with each other. Furthermore, MN2 has two interfaces and it currently uses different interface to talk to MN2 and to MN3, and therefore it has two different COA1, MN1 COA1 and MN1 COA2. The Binding Cache can be depicted as follows. +---------------------------+ +----------------------------+ ! MN1 ! ! MN2 ! ! ! ! ! !sock <-> MN2 HA -> MN2 COA ! !sock <-> MN1 HA -> MN1 COA1 ! ! ! ! ! !sock <-> MN3 HA -> MN3 COA ! !sock <-> MN3 HA -> MN3 COA ! ! ! ! ! +---------------------------+ +----------------------------+ +---------------------------+ ! MN3 ! ! ! !sock <-> MN1 HA -> MN1 COA2! ! ! !sock <-> MN2 HA -> MN2 COA ! ! ! +---------------------------+ As a revision of this, let us now consider a scheme where the Binding Cache could contain several COAs for a single host. The data structures would look like the following. +---------------------------+ +----------------------------+ ! MN1 ! ! MN2 ! ! ! ! ! !sock <-> MN2 HA -> MN2 COA ! !sock <-> MN1 HA -> MN1 COA1 ! ! ! ! MN1 COA2 ! !sock <-> MN3 HA -> MN3 COA ! !sock <-> MN3 HA -> MN3 COA ! ! ! ! ! +---------------------------+ +----------------------------+ +---------------------------+ ! MN3 ! ! ! !sock <-> MN1 HA -> MN1 COA1! ! MN1 COA2! !sock <-> MN2 HA -> MN2 COA ! ! ! +---------------------------+ The next step is the realization that if we change the algorithm that finds the right socket on the receiving end to look up the socket by using the COAs instead of the HA, we can get rid of the Home Address altogether. +---------------------------+ +---------------------------+ ! MN1 ! ! MN2 ! ! ! ! ! ! sock <----------> MN2 COA ! ! sock <---------> MN1 COA1 ! ! ! ! MN1 COA2 ! ! sock <----------> MN3 COA ! ! sock <---------> MN3 COA ! ! ! ! ! +---------------------------+ +---------------------------+ +---------------------------+ ! MN3 ! ! ! ! sock <---------> MN1 COA1 ! ! MN1 COA2 ! ! sock <---------> MN2 COA ! ! ! +---------------------------+ Now we have came to the Homeless draft's Host Cache. The only problem is that programs that do not adhere with RFC 1958 will break... (But we have some preliminary ideas how to fix it). SIMILARITIES Now, by my second reading of the IIP draft I must reconsider my proposal to the IIP draft about the possible similarities. What led me to believe that the drafts have similaries, are the following features: - In the introduction, IIP claims to support multi-homed operations. However, the draft does not specify how, though I think I can see how it could do it. (Homeless does support multi-homed operations, and clearly specifies how.) - And probably most importantly, IIP leaves the "orthodox" approarch that each MN has a home address; instead, home addresses are percieved as more or less temporary ones, and used for temporary packet forwarding to a large degree. The second point is what definitely makes some of the attitude behind the drafts similar - hence my view of "trying to solve some of the same problems". Othet than that, I don't think that the solutions are necessarily that similar at all. --Pekka Nikander From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Dec 4 00:30:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07646 for ; Mon, 4 Dec 2000 00:30:30 -0500 (EST) Received: from standards (47.234.32.16:1949) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBECBE@standards.nortelnetworks.com>; Mon, 4 Dec 2000 0:10:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 156927 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 00:10:52 -0500 Received: from mailhub1.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBECBC@standards.nortelnetworks.com>; Mon, 4 Dec 2000 0:10:52 -0500 Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.16 #1) id 142oAq-0002N6-00 for MOBILE-IP@standards.nortelnetworks.com; Mon, 04 Dec 2000 05:28:24 +0000 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 4 Dec 00 05:28:24 +0000 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 4 Dec 00 05:28:10 +0000 Received: from Mobile1 (143.167.59.139) by ridingwood.shef.ac.uk (Mercury 1.48); 4 Dec 00 05:28:06 +0000 References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Approved-By: cnyap Message-ID: <001801c05db2$9217a980$923ba78f@Mobile1> Date: Mon, 4 Dec 2000 05:25:10 -0000 Reply-To: cnyap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cnyap Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all, ----- Original Message ----- From: "Pat Calhoun" To: Sent: Saturday, December 02, 2000 12:43 AM Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location > > Hi all, > > > > Sorry to mention this again > > No matter how "pro-active" any method can be, > > In CDMA you would not be able transmit IP packet > > before the PPP session is set up. > > Correct, but PPP is supported for legacy reasons. I am not sure that it will > perpetuate in future architecturessince its usefulness is dubious when new > technologies, such as ROHC, are introduced. > > PatC I am doubtful about PPP not perpetuate in future. Why RFC 2794 in the first place then? Chern Nam Yap MIEEE, MSc(Res), BSc(Hons) Research Associate Center for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield F132 Mappin Building Mappin Street Sheffield S1 3JD United Kingdom Tel:+44 (0) 114-222-5182 Mobile:+ 44(0) 7712804892 Web: www.mobile1.net E-mail: cny@ieee.org From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Dec 4 04:06:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24467 for ; Mon, 4 Dec 2000 04:06:54 -0500 (EST) Received: from standards (47.234.32.16:1824) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBED71@standards.nortelnetworks.com>; Mon, 4 Dec 2000 3:47:26 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 157158 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 03:47:26 -0500 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBED6F@standards.nortelnetworks.com>; Mon, 4 Dec 2000 3:47:18 -0500 Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id eB494T427504 for ; Mon, 4 Dec 2000 10:04:29 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon Dec 04 10:04:28 2000 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Mon, 4 Dec 2000 10:02:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Karim El-Malki (ERA)" Message-ID: <5F05C89FB2F8D211B6430008C79191270746031B@esealnt190> Date: Mon, 4 Dec 2000 09:56:23 +0100 Reply-To: "Karim El-Malki (ERA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Karim El-Malki (ERA)" Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location X-To: James Kempf To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM James > > You didn't read my comment. I didn't say it wasn't supported in FH, > I said that Karim's comment that one could start the MIP registration > before the L2 handoff won't work in the real world. When did I say "before the L2 handoff"? /Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Dec 4 04:18:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28581 for ; Mon, 4 Dec 2000 04:18:02 -0500 (EST) Received: from standards (47.234.32.16:1824) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBEDC7@standards.nortelnetworks.com>; Mon, 4 Dec 2000 3:57:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 157276 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 03:57:06 -0500 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBEDC5@standards.nortelnetworks.com>; Mon, 4 Dec 2000 3:57:00 -0500 Received: from esealnt406.al.sw.ericsson.se (esealnt406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id eB49EFG05302 for ; Mon, 4 Dec 2000 10:14:15 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Dec 04 10:14:15 2000 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Mon, 4 Dec 2000 10:14:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Karim El-Malki (ERA)" Message-ID: <5F05C89FB2F8D211B6430008C79191270746031C@esealnt190> Date: Mon, 4 Dec 2000 10:14:14 +0100 Reply-To: "Karim El-Malki (ERA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Karim El-Malki (ERA)" Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location X-To: "Dolan, Michael F (Mike)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello Mike > > In one proposed solution, the "old" CDMA Base Station would be sending > the advertisement for other FAs. Should it send both advertisements? > How should the MN choose which to initiate? What if it chooses > incorrectly? What if it attempts new registrations on both, "just to > be safe?" As specified in our draft the MN is eager in registering and therefore establishes bindings with all FAs advertised. Only one binding will remain active once the MN stays in the coverage area of one FA for some time. > > In another solution, the "old" CDMA Base Station gets radio level > readings from the MN and chooses the system to receive the handoff (a > second CDMA Base Station, or an 802.11b Base Station in the example > above). In this solution, the "old" Base Station can react quickly > to radio environment changes (including support of the MN returning > to the "old" Base Station upon handoff failure). You seem to be assuming a FA in the BS and I don't think we should be tailoring our work to this case. However, if you put the above in terms of FA coverage areas then the concept works (as I explained above) since you maintain simultaneous bindings with the new and old FA. Interaction with > other Base Stations at the Link Layer to coordinate the handoff can > result in a smooth transition of the application stream. Coordination > among those Base Stations and the FAs to continue the stream until a > new MIP registration can be achieved can provide the support for the > 250ms bound proposed. As has been discussed in several > places already, > tunneling between the FAs or between the Base Stations can support > stream continuation. Why not coordinate the L2 and L3 in order to anticipate the MN's registration instead of having a network-initiated registration on behalf of the MN? MN control is the issue and that is supported in MIPv4 and MIPv6. The alternative I am talking about allows for network-based control of the handoffs but also MN control of the L3 handoff (just like RFC2002). Why should we opt for a solution which does not allow MN control of the handoff? Regards, Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Dec 4 08:48:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22018 for ; Mon, 4 Dec 2000 08:48:12 -0500 (EST) Received: from standards (47.234.32.16:3754) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBEF1E@standards.nortelnetworks.com>; Mon, 4 Dec 2000 8:28:48 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 157720 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 08:28:48 -0500 Received: from patan.sun.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBEF1C@standards.nortelnetworks.com>; Mon, 4 Dec 2000 8:28:47 -0500 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16227; Mon, 4 Dec 2000 05:46:17 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA14942; Mon, 4 Dec 2000 05:46:12 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id FAA25169; Mon, 4 Dec 2000 05:46:11 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Approved-By: Pat Calhoun Message-ID: Date: Mon, 4 Dec 2000 05:43:08 -0800 Reply-To: Pat Calhoun Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pat Calhoun Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location X-To: cnyap To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <001801c05db2$9217a980$923ba78f@Mobile1> > I am doubtful about PPP not perpetuate in future. > Why RFC 2794 in the first place then? RFC2794 is not used in CDMA 2000 networks. If you look at PPP, you have 1. LCP. Nothing is really negotiated during LCP. The only item of possible value is MTU, and that can be taken care of another method. 2. AUTH. Authentication phase is bypassed in favor of Mobile IP authentication. 3. IPCP. IPCP is run to set IP to the open state, but no address is negotiated. Again, of dubious value 4. CCP. Compression is the only real value in PPP in these networks. However, with the exception of Microsoft's compression protocol, they are all history based, and of no use to wireless networks. So, why bother using PPP, which imposes a 12 message overhead during message setup, by running 1, 3 and 4 above when a single round trip could be used to establish some compression parameters? Why perpetuate the concepts of circuit switched, when the whole purpose of 3G data is not move away from circuit switched? PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Dec 4 12:20:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01508 for ; Mon, 4 Dec 2000 12:20:49 -0500 (EST) Received: from standards (47.234.32.16:1485) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF0C1@standards.nortelnetworks.com>; Mon, 4 Dec 2000 12:01:23 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 158246 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 12:01:22 -0500 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF0BF@standards.nortelnetworks.com>; Mon, 4 Dec 2000 12:01:22 -0500 Received: from esealnt462.al.sw.ericsson.se (esealnt462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id eB4HIs419986 for ; Mon, 4 Dec 2000 18:18:54 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Dec 04 18:18:53 2000 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Mon, 4 Dec 2000 18:16:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Karim El-Malki (ERA)" Message-ID: <5F05C89FB2F8D211B6430008C791912707460329@esealnt190> Date: Mon, 4 Dec 2000 18:18:48 +0100 Reply-To: "Karim El-Malki (ERA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Karim El-Malki (ERA)" Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > >> You didn't read my comment. I didn't say it wasn't supported in FH, > >> I said that Karim's comment that one could start the MIP > registration > >> before the L2 handoff won't work in the real world. > > > >When did I say "before the L2 handoff"? > > I meant "before the L2 handoff was complete". OK, yes that's what I meant. > Possibly Hesham > misquoted you. > I have included the citation from Hesham's email in which he stated > that you earlier sent email stating that the L3 MIP registration > procedure could be started before the L2 procedure was complete. > No I think Hesham did address your point. We use simultaneous bindings so ping-pong is supported even when you start the L3 handoff procedure (i.e. advertisement, movement detection, registration) before the L2 handoff procedure has completed. If you end up on the same subnet the binding will not have expired and the MN can continue its communications. What is so unreal about starting the MIP registration after the L2 handoff procedure has been initiated and before it has completed? /K. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Dec 5 01:39:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16209 for ; Tue, 5 Dec 2000 01:39:22 -0500 (EST) Received: from standards (47.234.32.16:3209) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF3C6@standards.nortelnetworks.com>; Tue, 5 Dec 2000 1:19:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 159261 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 01:19:36 -0500 Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF3C4@standards.nortelnetworks.com>; Tue, 5 Dec 2000 1:19:36 -0500 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id BAA06488 for ; Tue, 5 Dec 2000 01:37:11 -0500 (EST) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id BAA06484 for ; Tue, 5 Dec 2000 01:37:10 -0500 (EST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 00:37:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Dolan, Michael F (Mike)" Message-ID: Date: Tue, 5 Dec 2000 00:37:09 -0600 Reply-To: "Dolan, Michael F (Mike)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Dolan, Michael F (Mike)" Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Karim, Sorry for being late in replying. I am traveling (again!) If a handoff occurs with active IP packet streams, and if the MN chooses to establish registrations with multiple FAs, how many simultaneous (S-bit) copies of each packet should the HA be expected to send out to these FAs? What could we expect in existing and new implementations of FAs? It seems that expecting a new and an old stream is reasonable, and any more would be unreasonable. So, I think that reasonable implementations of both MNs and HAs would only have an old and a new registration and one copy of each stream. I agree that coordination and cooperation between L2 and L3 is a good basis for expediting handoffs. In addition to tunnels at either L2 or L3, some communication between L2 and L3 both at the old and new FA area is also an obvious part of the solution. Some of the intricacies of radio interfaces make parallel but independent L2 and L3 protocols very complex. The best solutions I have heard all seem to revolve around the idea of moving the radio environment first using tunneling from the old to the new at either L2 or L3, and then doing a new MIP registration. This also allows the L2 protocol to handle other complexities of the particular L2 interface, such as "ping ponging." One good solution seems to be to delay the new MIP registration until the existing IP streams terminate - though this might not be the best solution if I am watching a 2 hour streaming video movie! :^) Have a good day, Mike Dolan Lucent Technologies - Bell Labs mfdolan@lucent.com -----Original Message----- From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] Sent: Monday, December 04, 2000 3:14 AM To: Dolan, Michael F (Mike); MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: RE: [MOBILE-IP] Pro-active Handoff and FA Location Hello Mike > > In one proposed solution, the "old" CDMA Base Station would be sending > the advertisement for other FAs. Should it send both advertisements? > How should the MN choose which to initiate? What if it chooses > incorrectly? What if it attempts new registrations on both, "just to > be safe?" As specified in our draft the MN is eager in registering and therefore establishes bindings with all FAs advertised. Only one binding will remain active once the MN stays in the coverage area of one FA for some time. > > In another solution, the "old" CDMA Base Station gets radio level > readings from the MN and chooses the system to receive the handoff (a > second CDMA Base Station, or an 802.11b Base Station in the example > above). In this solution, the "old" Base Station can react quickly > to radio environment changes (including support of the MN returning > to the "old" Base Station upon handoff failure). You seem to be assuming a FA in the BS and I don't think we should be tailoring our work to this case. However, if you put the above in terms of FA coverage areas then the concept works (as I explained above) since you maintain simultaneous bindings with the new and old FA. Interaction with > other Base Stations at the Link Layer to coordinate the handoff can > result in a smooth transition of the application stream. Coordination > among those Base Stations and the FAs to continue the stream until a > new MIP registration can be achieved can provide the support for the > 250ms bound proposed. As has been discussed in several > places already, > tunneling between the FAs or between the Base Stations can support > stream continuation. Why not coordinate the L2 and L3 in order to anticipate the MN's registration instead of having a network-initiated registration on behalf of the MN? MN control is the issue and that is supported in MIPv4 and MIPv6. The alternative I am talking about allows for network-based control of the handoffs but also MN control of the L3 handoff (just like RFC2002). Why should we opt for a solution which does not allow MN control of the handoff? Regards, Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Dec 5 08:51:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21509 for ; Tue, 5 Dec 2000 08:51:23 -0500 (EST) Received: from standards (47.234.32.16:3280) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF530@standards.nortelnetworks.com>; Tue, 5 Dec 2000 8:31:35 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 159725 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 08:31:34 -0500 Received: from mgw-dax2.ext.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF52E@standards.nortelnetworks.com>; Tue, 5 Dec 2000 8:31:34 -0500 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eB5Dnk601466 for ; Tue, 5 Dec 2000 07:49:47 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Tue, 5 Dec 2000 07:49:09 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 5 Dec 2000 07:44:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Approved-By: Basavaraj.Patil@NOKIA.COM Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E633@daeis07nok> Date: Tue, 5 Dec 2000 07:45:08 -0600 Reply-To: Basavaraj.Patil@nokia.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] draft agenda (about Homeless draft) X-To: cny@ieee.org To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >Hi all, > >About 6 months ago, IIP is being rejected in Mobile Working Group, >as "IIP concept is out of the scope of the working group". >Here goes: 8X----cut------ The number of requests that we get for timeslots at an IETF meeting far exceed the time available and we have to prioritize among the I-Ds based on criteria such as: is the I-D within the scope of the charter and also the interest by WG members in the I-D/concept. I-D draft-nikander-mobileip-homelessv6-00.txt has generated some level of interest and hence is on the agenda. -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Dec 5 10:26:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15334 for ; Tue, 5 Dec 2000 10:26:49 -0500 (EST) Received: from standards (47.234.32.16:2467) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF60E@standards.nortelnetworks.com>; Tue, 5 Dec 2000 10:08:59 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 160007 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 10:08:59 -0500 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF60C@standards.nortelnetworks.com>; Tue, 5 Dec 2000 10:08:58 -0500 Received: from esvir05nok.nokia.com (esvir05nok.nokia.com [131.228.20.77]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id eB5FPuK08152 for ; Tue, 5 Dec 2000 17:26:07 +0200 (EET) Received: from esebh02nok.ntc.nokia.com (unverified) by esvir05nok.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 5 Dec 2000 16:32:49 +0200 Received: by esebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 5 Dec 2000 16:32:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Approved-By: Timo.Alakoski@NOKIA.COM Message-ID: <593F7F3472A5D211B99B0008C7EAA08A053447E0@eseis02nok> Date: Tue, 5 Dec 2000 16:32:46 +0200 Reply-To: Timo.Alakoski@nokia.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Timo Alakoski Subject: [MOBILE-IP] Mobile IPv4/6 interworking draft To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi! In the draft-tsao-mobileip-dualstack-model-01.txt Tsao et al. suggests to use dual stack mobile nodes to allow it to roam in both IPv4 and IPv6 environment. There are two cases presented: 1. MN is visiting IPv6 network and wants to register to IPv4 HA 2. MN is visiting IPv4 network and wants to register to IPv6 HA In first case the MN sends MIPv4 messages in the payload of IPv6 datagrams and the border router of the IPv6 network translates the messages into IPv4. The same happens in the second case: MIPv6 messages are send in IPv4 packet and are translated into IPv6 datagrams. The document doesn't say anything about the authentication between MN and HA. Doesn't the use of translators break the authentication, at least in the second case? --Timo From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Dec 5 13:19:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28904 for ; Tue, 5 Dec 2000 13:19:10 -0500 (EST) Received: from standards (47.234.32.16:4005) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF744@standards.nortelnetworks.com>; Tue, 5 Dec 2000 12:59:30 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 160392 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 12:59:30 -0500 Received: from localhost.ipunplugged.com (195.42.212.161:23870) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF742@standards.nortelnetworks.com>; Tue, 5 Dec 2000 12:59:29 -0500 Received: from fredrikj ([192.168.4.228]) by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id TAA13750; Tue, 5 Dec 2000 19:17:46 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01C05EF0.4155ADF0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Approved-By: Fredrik Johansson Message-ID: Date: Tue, 5 Dec 2000 19:19:14 +0100 Reply-To: Fredrik Johansson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fredrik Johansson Subject: [MOBILE-IP] AAA key distribution for Mobile IP X-To: Diameter Listan , AAA Listan To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_004A_01C05EF0.4155ADF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Can anyone tell me how the temporary session keys generated by a Diameter server will be distributed. The "AAA Registration Keys for Mobile IP" has expired, is it still used, a new version coming soon? Or are there any new extensions that should be used instead? /Fredrik P.S. sorry for the cross posting ---------------------------------------------------------------------------- ------- Fredrik Johansson W: +46 (0)8 725 5916 Interactive People Unplugged M: +46 (0)70 786 5035 mailto:fredrik.johansson@ipunplugged.com http://www.ipunplugged.com ------=_NextPart_000_004A_01C05EF0.4155ADF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Can = anyone tell me=20 how the temporary session keys generated by a Diameter server will be=20 distributed. The "AAA Registration Keys for Mobile IP" has expired, is = it still=20 used, a new version coming soon? Or are there any new extensions that = should be=20 used instead?
 
/Fredrik
P.S. = sorry for the=20 cross posting
 
----------------------------------------------------------------= -------------------
Fredrik=20 Johansson          &nbs= p;         W:=20 +46 (0)8 725 5916
Interactive People=20 Unplugged     M: +46 (0)70 786 5035
mailto:fredrik.johansso= n@ipunplugged.com
http://www.ipunplugged.com
 
 
------=_NextPart_000_004A_01C05EF0.4155ADF0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Dec 5 17:22:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28000 for ; Tue, 5 Dec 2000 17:22:41 -0500 (EST) Received: from standards (47.234.32.16:3914) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF862@standards.nortelnetworks.com>; Tue, 5 Dec 2000 17:02:52 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 160771 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 17:02:52 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF860@standards.nortelnetworks.com>; Tue, 5 Dec 2000 17:02:46 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA18737; Tue, 5 Dec 2000 14:20:22 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eB5MKK508448; Tue, 5 Dec 2000 14:20:20 -0800 X-Virus-Scanned: Tue, 5 Dec 2000 14:20:20 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdWTZFd1; Tue, 05 Dec 2000 14:20:16 PST X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: charliep@IPRG.NOKIA.COM Message-ID: <3A2D6A22.A6CE9C30@iprg.nokia.com> Date: Tue, 5 Dec 2000 14:20:18 -0800 Reply-To: "Charles E. Perkins" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: [MOBILE-IP] New Reginoal Registration for IPv6 Internet Draft X-cc: "Jari T. Malinen" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, We missed the deadline for submission of our revised Internet Draft to the IETF directories. In order to repair that lack, I have posted the newly revised draft to my interim Web page, at the following URL: http://www.diameter.org/charliep/txt/regreg6/regreg6.txt The following appendix details the main points of difference: ======================================================================= B. Changes to the previous version This version introduces an anycast address to represent the visited domain as a distributed network endpoint. A one message-exchange multi-level signaling is efficient e.g. when the mobile node needs to communicate both with the access router and the gateway mobility agent (GMA). The other changes address all problems mentioned in working group minutes, in security and in providing uniqueness of the visited domain identity. - This version distributes the network endpoint of communication identifying it with an anycast address. A common security association per mobile node can be used in the visited domain when key material received (e.g., from AAAv6) is propagated to members of the anycast group, as described in Appendix A. This change also preserves the cost-efficiency of having a single message exchange with the deep hierarchy while now providing a fully specified security option. - The regional forwarding of route-optimized packets changes the regional CoA back to the source address of a data packet received in the mobile node. Then, all information for correct AH computation is present in a packet received by the mobile node. - The router advertisement now also uniquely identifies the visited domain with the special ``visited domain routers'' anycast address. This address is formed using prefix of the regional care-of-address and a host number 5 (TBD). Thus, no visited domain identifier is used in this version from the prefix information option. The same anycast address is used by the mobile node to send the regional binding update to the distributed endpoint, the destination IP address of the regional binding update. ======================================================================= Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Dec 5 20:06:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00118 for ; Tue, 5 Dec 2000 20:05:59 -0500 (EST) Received: from standards (47.234.32.16:4711) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF992@standards.nortelnetworks.com>; Tue, 5 Dec 2000 19:45:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 161194 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 19:45:50 -0500 Received: from mailhub1.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF990@standards.nortelnetworks.com>; Tue, 5 Dec 2000 19:45:49 -0500 Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.16 #1) id 143SzP-0003aX-00; Wed, 06 Dec 2000 01:03:19 +0000 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 6 Dec 00 01:03:20 +0000 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 6 Dec 00 01:03:19 +0000 Received: from Mobile1 (143.167.59.139) by ridingwood.shef.ac.uk (Mercury 1.48); 6 Dec 00 01:03:10 +0000 References: <13E2EF604DE5D111B2E50000F80824E8057A8989@zwdld001.ca.nortel.com> <3A2D7EA5.83C03A80@comet.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Approved-By: cnyap Message-ID: <000b01c05f1f$e2269c60$923ba78f@Mobile1> Date: Wed, 6 Dec 2000 00:59:26 -0000 Reply-To: cnyap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cnyap Subject: Re: [MOBILE-IP] [seamoby] Re: architecting wireless Internet X-To: campbell@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi "Mobile IP is a supra-IP" An Interesting concept by Gary. Is Celluar IP a supra-Mobile IP? Chern Nam Yap MIEEE, MSc(Res), BSc(Hons) Research Associate Center for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield F132 Mappin Building Mappin Street Sheffield S1 3JD United Kingdom Tel:+44 (0) 114-222-5182 Mobile:+ 44(0) 7712804892 Web: www.mobile1.net E-mail: cny@ieee.org From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Dec 5 20:12:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00975 for ; Tue, 5 Dec 2000 20:12:18 -0500 (EST) Received: from standards (47.234.32.16:4711) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF9D8@standards.nortelnetworks.com>; Tue, 5 Dec 2000 19:51:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 161290 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 19:51:18 -0500 Received: from artemis.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF9D6@standards.nortelnetworks.com>; Tue, 5 Dec 2000 19:51:18 -0500 Received: from [143.167.1.9] (helo=mailhub1.shef.ac.uk) by artemis.shef.ac.uk with esmtp (Exim 3.16 #1) id 143T4g-0007GW-00 for MOBILE-IP@standards.nortelnetworks.com; Wed, 06 Dec 2000 01:08:46 +0000 Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.16 #1) id 143T4g-0003c9-00 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 06 Dec 2000 01:08:46 +0000 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 6 Dec 00 01:08:47 +0000 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 6 Dec 00 01:08:42 +0000 Received: from Mobile1 (143.167.59.139) by ridingwood.shef.ac.uk (Mercury 1.48); 6 Dec 00 01:08:38 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C05F20.A5BEA1E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Scanner: exiscan@artemis *143T4g-0007GW-00* http://duncanthrax.net/exiscan/ Approved-By: cnyap Message-ID: <002001c05f20$a5d3fea0$923ba78f@Mobile1> Date: Wed, 6 Dec 2000 01:05:39 -0000 Reply-To: cnyap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cnyap Subject: [MOBILE-IP] MIP is not a requirement To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C05F20.A5BEA1E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi "Mobile IP interworking is required." False. A solution that allows a mobile node to run=20 IP-based heterogonous networks effectively. True. Chern Nam Yap MIEEE, MSc(Res), BSc(Hons) Research Associate Center for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield F132 Mappin Building Mappin Street Sheffield S1 3JD United Kingdom Tel:+44 (0) 114-222-5182 Mobile:+ 44(0) 7712804892 Web: www.mobile1.net E-mail: cny@ieee.org ------=_NextPart_000_001D_01C05F20.A5BEA1E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
"Mobile IP interworking is = required."
False.
 
A solution that allows a mobile = node to=20 run
IP-based heterogonous networks=20 effectively.
True.
 
Chern Nam Yap
MIEEE, MSc(Res),=20 BSc(Hons)
Research Associate
Center for Mobile Communication=20 Research
Department of Electronic and Electrical = Engineering
University of=20 Sheffield
F132 Mappin Building
Mappin Street
Sheffield S1 = 3JD
United=20 Kingdom
Tel:+44 (0) 114-222-5182
Mobile:+ 44(0) 7712804892
Web: = www.mobile1.net
E-mail: cny@ieee.org
------=_NextPart_000_001D_01C05F20.A5BEA1E0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Dec 5 20:20:48 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01946 for ; Tue, 5 Dec 2000 20:20:43 -0500 (EST) Received: from standards (47.234.32.16:4711) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBFA47@standards.nortelnetworks.com>; Tue, 5 Dec 2000 20:01:08 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 161445 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 20:01:07 -0500 Received: from artemis.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBFA45@standards.nortelnetworks.com>; Tue, 5 Dec 2000 20:01:07 -0500 Received: from [143.167.1.9] (helo=mailhub1.shef.ac.uk) by artemis.shef.ac.uk with esmtp (Exim 3.16 #1) id 143TEF-0007Mx-00 for MOBILE-IP@standards.nortelnetworks.com; Wed, 06 Dec 2000 01:18:39 +0000 Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.16 #1) id 143TEF-0003dR-00 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 06 Dec 2000 01:18:39 +0000 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 6 Dec 00 01:18:40 +0000 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 6 Dec 00 01:18:27 +0000 Received: from Mobile1 (143.167.59.139) by ridingwood.shef.ac.uk (Mercury 1.48); 6 Dec 00 01:18:19 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C05F21.FFD766C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Scanner: exiscan@artemis *143TEF-0007Mx-00* http://duncanthrax.net/exiscan/ Approved-By: cnyap Message-ID: <003d01c05f21$fff30510$923ba78f@Mobile1> Date: Wed, 6 Dec 2000 01:15:19 -0000 Reply-To: cnyap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cnyap Subject: Re: [MOBILE-IP] architecting wireless Internet To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C05F21.FFD766C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Maybe "most" Micromobility technique is Supra-Mobile IP. Chern Nam Yap MIEEE, MSc(Res), BSc(Hons) Research Associate Center for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield F132 Mappin Building Mappin Street Sheffield S1 3JD United Kingdom Tel:+44 (0) 114-222-5182 Mobile:+ 44(0) 7712804892 Web: www.mobile1.net E-mail: cny@ieee.org ------=_NextPart_000_003A_01C05F21.FFD766C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
Maybe "most" Micromobility technique is = Supra-Mobile IP.
 
Chern Nam Yap
MIEEE, MSc(Res),=20 BSc(Hons)
Research Associate
Center for Mobile Communication=20 Research
Department of Electronic and Electrical = Engineering
University of=20 Sheffield
F132 Mappin Building
Mappin Street
Sheffield S1 = 3JD
United=20 Kingdom
Tel:+44 (0) 114-222-5182
Mobile:+ 44(0) 7712804892
Web: = www.mobile1.net
E-mail: cny@ieee.org
 
 
 
 
 
 
 
------=_NextPart_000_003A_01C05F21.FFD766C0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Dec 5 20:51:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05620 for ; Tue, 5 Dec 2000 20:51:08 -0500 (EST) Received: from standards (47.234.32.16:1338) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBFA9D@standards.nortelnetworks.com>; Tue, 5 Dec 2000 20:31:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 161564 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 20:31:37 -0500 Received: from hopper.math.uwaterloo.ca by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBFA9B@standards.nortelnetworks.com>; Tue, 5 Dec 2000 20:31:36 -0500 Received: from localhost (mmcsween@localhost) by hopper.math.uwaterloo.ca (8.8.8/8.8.8) with ESMTP id UAA06713 for ; Tue, 5 Dec 2000 20:49:13 -0500 (EST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Martin McSweeney Message-ID: Date: Tue, 5 Dec 2000 20:49:13 -0500 Reply-To: Martin McSweeney Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Martin McSweeney Subject: [MOBILE-IP] Changing default routers To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I have a problem i've been staring at for awhile, so maybe someone here can help me: I have an implementation of Mobile IP for Linux. Consider the following scenerio: My mobile is connected to a FA, and the IP routing table on the mobile looks: 24.226.68.1 dev eth0 scope link 127.0.0.0/8 dev lo scope link default via 24.226.68.1 dev eth0 where 24.226.68.1 is the FA. The ARP cache looks like: 24.226.68.1 dev eth0 lladdr 00:90:ab:14:14:70 nud reachable Now, my mobile switches link-layer connectivity, and I decide to use a different foreign agent (because of a new advertisement). The foreign agent has an IP address of 24.226.90.1. Now, when I receive the new agent advertisement, and I decide to switch foreign agents, I *immediately* delete the arp cache entry for the old foreign agent and change my default route for the new foreign agent. Therefore, the IP routing table and my arp cache do not contain any entries for the old foreign agent (it does not show up via "ip" command). The new entries look like: 24.226.90.1 dev eth0 scope link 127.0.0.0/8 dev lo scope link default via 24.226.90.1 dev eth0 The ARP cache looks like: 24.226.68.1 dev eth0 lladdr 00:90:ab:14:4c:90 nud reachable The registration request gets to the foreign agent because IP looks in the routing table and matches the entry. BUT, anything that must go via default (ie. there is not a match in the IP table), the packets contain link-layer addresses of the old foreign agent. This continues for about 2 seconds, and then suddenly the packets contain the hardware address of the new foreign agent. As a result, all my traffic from the mobile is lost in those 2 seconds. This leads me to believe that Linux kernels keep a "cache" of the arp cache, and does not update it until the 2 seconds is up. RFC 1122 hints at this-- "a reroute timer for detecting dead default gateways), but I cannot find anything else anywhere on the web that documents this type of behaviour. And, I cannot find anything in Linux kernel source. Can anyone help me understand what is going on???? thanks, martin mmcsween@styx.uwaterloo.ca From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Dec 6 06:42:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14260 for ; Wed, 6 Dec 2000 06:42:27 -0500 (EST) Received: from standards (47.234.32.16:4989) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBFCC6@standards.nortelnetworks.com>; Wed, 6 Dec 2000 6:22:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 162295 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Dec 2000 06:22:39 -0500 Received: from artemis.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBFCC4@standards.nortelnetworks.com>; Wed, 6 Dec 2000 6:22:39 -0500 Received: from [143.167.1.9] (helo=mailhub1.shef.ac.uk) by artemis.shef.ac.uk with esmtp (Exim 3.16 #1) id 143cvc-000378-00 for MOBILE-IP@standards.nortelnetworks.com; Wed, 06 Dec 2000 11:40:04 +0000 Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.16 #1) id 143cvc-0002ws-00 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 06 Dec 2000 11:40:04 +0000 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 6 Dec 00 11:40:05 +0000 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 6 Dec 00 11:40:04 +0000 Received: from Mobile1 (143.167.59.139) by ridingwood.shef.ac.uk (Mercury 1.48); 6 Dec 00 11:39:59 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C05F78.D855CDB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Scanner: exiscan@artemis *143cvc-000378-00* http://duncanthrax.net/exiscan/ Approved-By: cnyap Message-ID: <002e01c05f78$d86fbe50$923ba78f@Mobile1> Date: Wed, 6 Dec 2000 11:36:59 -0000 Reply-To: cnyap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cnyap Subject: [MOBILE-IP] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C05F78.D855CDB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Oops! wrong mailiing list. Sorry the last two mail are suppose for semoby and not for MIP WG. ignore them Chern Nam Yap MIEEE, MSc(Res), BSc(Hons) Research Associate Center for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield F132 Mappin Building Mappin Street Sheffield S1 3JD United Kingdom Tel:+44 (0) 114-222-5182 Mobile:+ 44(0) 7712804892 Web: www.mobile1.net E-mail: cny@ieee.org ------=_NextPart_000_002B_01C05F78.D855CDB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Oops!
 
wrong mailiing list.
Sorry the last two mail are suppose for = semoby and=20 not for MIP WG.
ignore them
 
Chern Nam Yap
MIEEE, MSc(Res),=20 BSc(Hons)
Research Associate
Center for Mobile Communication=20 Research
Department of Electronic and Electrical = Engineering
University of=20 Sheffield
F132 Mappin Building
Mappin Street
Sheffield S1 = 3JD
United=20 Kingdom
Tel:+44 (0) 114-222-5182
Mobile:+ 44(0) 7712804892
Web: = www.mobile1.net
E-mail: cny@ieee.org
 
------=_NextPart_000_002B_01C05F78.D855CDB0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Dec 6 15:33:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10958 for ; Wed, 6 Dec 2000 15:32:59 -0500 (EST) Received: from standards (47.234.32.16:1656) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC001F@standards.nortelnetworks.com>; Wed, 6 Dec 2000 15:13:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 163372 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Dec 2000 15:13:04 -0500 Received: from mgw-dax2.ext.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC001D@standards.nortelnetworks.com>; Wed, 6 Dec 2000 15:13:04 -0500 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eB6KVJ618065 for ; Wed, 6 Dec 2000 14:31:19 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Wed, 6 Dec 2000 14:30:42 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Wed, 6 Dec 2000 14:26:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Approved-By: Basavaraj.Patil@NOKIA.COM Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E64B@daeis07nok> Date: Wed, 6 Dec 2000 14:26:38 -0600 Reply-To: Basavaraj.Patil@nokia.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: [MOBILE-IP] Final Agenda for IETF49 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Thursday 9-11:30 (150 minutes) ------------------------------ Basavaraj Patil 10 Agenda bashing and wg document status Charlie Perkins 15 MIPv6 Update draft-ietf-mobileip-ipv6-13.txt Vijay Devarapali 5 MIPv6 ETSI Bake-off Report Mobile IP V4 fast handoff: Pat Calhoun 5 Proactive handoff draft-calhoun-mobileip-proactive-fa-03.txt Hesham Soliman 5 Fast handoff draft-elmalki-mobileip-fast-handoffs-03.txt McCann/Soliman 5 Summary of differences in v4 handoff proposals WG 15 Discussion of fast handoff in v4 Mobile IP V6 fast handoff: Charlie Perkins 10 v6 fast handoff design team draft-perkins-mobileip-handover-00.txt WG 10 Discussion of fast handoff in v6 Hesham Soliman 10 Hierarchical MIP v6 draft-ietf-mobileip-hmipv6-01.txt Charlie Pekins 5 IP v6 Regional Registration draft-malinen-mobileip-regreg6-00.txt Charlie Perkins 10 DIAMETER extensions for MIP draft-calhoun-diameter-mobileip-11.txt Ernst Thierry 10 Mobile Network Support draft-ernst-mobileip-v6-network-00.txt Steve Glass 15 Registration Revocation for Mobile IP draft-glass-mobileip-reg-revok-00.txt Samita Chakrabarti 10 Private addressing draft-ietf-mobileip-rfc2344-bis-03.txt Friday 9-11:30 (150 minutes) --------------------------- Hemant Chaskar 10 A Framework for QoS Support in MIP v6 draft-chaskar-mobileip-qos-00.txt Alper Yegin 5 Mobile IPv4 and Mobile IPv6 interoperability testing at Connectathon 2001 Pekka Nikander 10 Mobile IP v6 for the Homeless draft-nikander-mobileip-homelessv6-00.txt Glenn Morrow 10 Intercepting Location Updates draft-lmk-mobileip-intercepting-update-01.txt SL Tsao 15 Introducing Mobile IP in IPv4/IPv6 Interconnected networks draft-tsao-mobileip-duelstack-model-00.txt Steve Glass 10 Use of DHCP in Mobile IP draft-glass-mobileip-agent-dhcp-proxy-00.txt Charlie Perkins 10 AAAv6 for MIP draft-perkins-aaav6-01.txt Jari Malinen 5 GSM SIM authentication draft-haverinen-mobileip-gsmsim-00.txt Jiwoong Lee 5 SGM support in MIP draft-lee-sgm-support-mobileip-00.txt Behcet Sarikaya 5 Mobile IP v6 Regional Paging draft-sarikaya-mobileip-hmipv6rp-00 Pat Calhoun 5 Mobile IP and GRE enhancements draft-calhoun-mobileip-gre-ext-00.txt Hesham Soliman 10 Security association establishment for route optimization in v6 draft-soliman-mobileip-routeopt-mipv6-00.txt Phil Roberts 10 Conclusions and future work discussion From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Dec 6 17:37:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18711 for ; Wed, 6 Dec 2000 17:37:51 -0500 (EST) Received: from standards (47.234.32.16:1234) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC00CB@standards.nortelnetworks.com>; Wed, 6 Dec 2000 17:18:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 163605 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Dec 2000 17:18:23 -0500 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC00C9@standards.nortelnetworks.com>; Wed, 6 Dec 2000 17:18:23 -0500 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Wed Dec 6 17:35:01 EST 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Wed Dec 6 17:35:00 EST 2000 Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP id 51F075701F; Wed, 6 Dec 2000 16:34:59 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <3.0.6.32.20001202102209.009129d0@popd.ix.netcom.com> <006001c05cbe$fe0e3720$6401a8c0@SOLID> X-Mailer: VM 6.33 under Emacs 19.34.2 Approved-By: Pete McCann Message-ID: <20001206223459.51F075701F@king.research.bell-labs.com> Date: Wed, 6 Dec 2000 16:34:59 -0600 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location X-To: Eunsoo Shim To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <006001c05cbe$fe0e3720$6401a8c0@SOLID> Content-Transfer-Encoding: 7bit Hi, Eunsoo, Eunsoo Shim (ES) writes: >> Seriously, probably not a good idea to assume/predict anything regarding >> air interface technology going forwards...let's leave the IP stuff wide >> open for all types of link layers in accordance with its basic >> architectural philosophy. ES> Following this philosophy, I think soft handoff in link layers also should ES> be considered as a special case even though it is available in the upcoming ES> 3G wireless networks (WCDMA, CDMA2000) and the current 802.11 WLAN. Thus I ES> am not sure it is a good assumption that the mobile node or the old FA can ES> figure out the new FA's IP address exactly from the link layer information ES> while the mobile node is attached to the old BS(or FA). I think the ES> assumption is in both of the drafts (Proactive Handoff, Fast Handoff) on the ES> table. ES> Eunsoo You are right that predicting the next FA is made much more difficult when there are multiple technologies involved, which is why I personally think that fast handoff (whether Proactive or Fast) is going to be confined (at least at first) to single-technology networks. (Mike Dolan and I have a difference of opinion on this, as you might be able to tell from his previous e-mail). However, given a single technology like cdma2000, I think it is perfectly reasonable for neighboring FAs (preferably co-located with BSCs, in my opinion) to get each other's IP addresses from link-layer triggers. This would be a very small addition to the provisioned information that must be in place to make hard handoff work (think about all the power measurements that are being made and signaled). Also, please don't get confused and think that we are addressing soft handoff: we most certainly are not trying to tackle that problem with either of these drafts. Soft handoff is a much more complicated ball of wax with all kinds of real-time requirements and logically runs well below the IP layer of the MN's IP stack. Both of these drafts address hard handoff between BSCs containing separate frame selectors, i.e., the frame selector after the handoff is not the same one as before the handoff. Even if Hesham disagrees with this he would argue that even more is being handed off: i.e., the FAs may contain multiple BSCs (or whatever the equivalent of a BSC in your technology of choice). However in this case the set of neighbors could grow to be quite large and the provisioning of neighbor IP addresses might begin to become problematic. -Pete From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Dec 6 19:32:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18913 for ; Wed, 6 Dec 2000 19:32:14 -0500 (EST) Received: from standards (47.234.32.16:1199) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0157@standards.nortelnetworks.com>; Wed, 6 Dec 2000 19:12:47 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 163794 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Dec 2000 19:12:47 -0500 Received: from ish7.ericsson.com.au (203.61.155.111:35804) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0155@standards.nortelnetworks.com>; Wed, 6 Dec 2000 19:12:46 -0500 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA09766 for ; Thu, 7 Dec 2000 11:26:52 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id LAA20291 for ; Thu, 7 Dec 2000 11:29:46 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Dec 2000 11:30:05 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Approved-By: "Hesham Soliman (EPA)" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613F04@eaubrnt018.epa.ericsson.se> Date: Thu, 7 Dec 2000 11:30:02 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Mobile IPv4/6 interworking draft To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, I don't believe there is a need for translators in either scenario below. Comments inline > In the draft-tsao-mobileip-dualstack-model-01.txt Tsao et al. suggests to > use dual stack mobile nodes to allow it to roam in both IPv4 and IPv6 > environment. There are two cases presented: > 1. MN is visiting IPv6 network and wants to register to IPv4 HA > 2. MN is visiting IPv4 network and wants to register to IPv6 HA > > In first case the MN sends MIPv4 messages in the payload of IPv6 datagrams > and the border router of the IPv6 network translates the messages into > IPv4. > => There is no need for translators in either case. For case (1) IPv4 can be tunnelled into IPv6 up to a Tunnell End Point (TEP) and then forwarded to the IPv4 network. Please refer to DSTM. In the second case 6 over 4 can be used to get connectivity to the V6 network. Translators are ONLY needed if single stacked MNs are used, therefore I don't see the need for translators in either case Regards, Hesham From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Dec 6 20:16:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28301 for ; Wed, 6 Dec 2000 20:16:45 -0500 (EST) Received: from standards (47.234.32.16:1199) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC01C0@standards.nortelnetworks.com>; Wed, 6 Dec 2000 19:57:23 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 163936 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Dec 2000 19:57:23 -0500 Received: from ish7.ericsson.com.au (203.61.155.111:37089) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC01BE@standards.nortelnetworks.com>; Wed, 6 Dec 2000 19:57:21 -0500 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id MAA13854 for ; Thu, 7 Dec 2000 12:11:27 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id MAA26589 for ; Thu, 7 Dec 2000 12:14:22 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Dec 2000 12:14:40 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Approved-By: "Hesham Soliman (EPA)" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613F07@eaubrnt018.epa.ericsson.se> Date: Thu, 7 Dec 2000 12:14:38 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Mobile IPv4/6 interworking draft To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello again, If people are interested in this area of work, we have a draft that was presented in Pittsburgh and will be presented again in San Diego in NGTRANS. http://www.ietf.org/internet-drafts/draft-soliman-siit-dstm-01.txt It addresses IPv6 <=> IPv4 communication in general and provides additional requirements for MIP. Comments are welcome. Regards, Hesham From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 7 08:47:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18838 for ; Thu, 7 Dec 2000 08:47:26 -0500 (EST) Received: from standards (47.234.32.16:3531) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0391@standards.nortelnetworks.com>; Thu, 7 Dec 2000 8:27:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 164532 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Dec 2000 08:27:42 -0500 Received: from mgw-x4.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC038F@standards.nortelnetworks.com>; Thu, 7 Dec 2000 8:27:42 -0500 Received: from esvir01nok.nokia.com (esvir01nok.nokia.com [131.228.20.73]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eB7DjNK12286 for ; Thu, 7 Dec 2000 15:45:23 +0200 (EET) Received: from esebh01nok.ntc.nokia.com (unverified) by esvir01nok.nokia.com (Content Technologies SMTPRS 4.1.2) with ESMTP id for ; Thu, 7 Dec 2000 15:45:22 +0200 Received: by esebh01nok with Internet Mail Service (5.5.2652.78) id ; Thu, 7 Dec 2000 15:40:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Approved-By: Timo.Alakoski@NOKIA.COM Message-ID: <593F7F3472A5D211B99B0008C7EAA08A053447E4@eseis02nok> Date: Thu, 7 Dec 2000 15:40:09 +0200 Reply-To: Timo.Alakoski@nokia.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Timo Alakoski Subject: Re: [MOBILE-IP] Mobile IPv4/6 interworking draft To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi! > If people are interested in this area of work, we have a draft > that was presented in Pittsburgh and will be presented > again in San Diego in NGTRANS. > > http://www.ietf.org/internet-drafts/draft-soliman-siit-dstm-01.txt > > It addresses IPv6 <=> IPv4 communication in general and provides > additional requirements for MIP. I believe the Tsao's draft was trying to solve the problem of the mobile node visiting both IPv4 and IPv6 networks. Therefore the MN should be a dual stack. siit-dstm is IPv4/6 translator with a nice solution for IPv6 MN to be able to communicate with IPv4 CNs (or MNs). > Comments are welcome. It was not clearly said in the draft how MN maintains the same IPv4 address when it moves to foreign network. Think the case where MNv6 has open connection to IPv4 CN (or MN) and has been assigned an IPv4 address by it's home AIIH server. Then it moves to a foreign IPv6 network (with siit-dst or some other translator). For outbound datagrams the MN must have the same IPv4 address as in home network so the solution would to have a static route 0::ffff/96 to MN's home SIIT router. Did I understand it correctly? In section 3 you are talking about IPv6-mapped and IPv6-translated addresses. Did I miss something or did you mean IPv4? :) --Timo From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 7 09:06:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21209 for ; Thu, 7 Dec 2000 09:06:22 -0500 (EST) Received: from standards (47.234.32.16:3531) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0401@standards.nortelnetworks.com>; Thu, 7 Dec 2000 8:45:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 164672 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Dec 2000 08:45:03 -0500 Received: from ish7.ericsson.com.au (203.61.155.111:49648) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC03FF@standards.nortelnetworks.com>; Thu, 7 Dec 2000 8:45:02 -0500 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id AAA19114; Fri, 8 Dec 2000 00:59:09 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id BAA26938; Fri, 8 Dec 2000 01:02:03 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Dec 2000 01:02:21 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C06056.5099BB00" Approved-By: "Hesham Soliman (EPA)" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613F09@eaubrnt018.epa.ericsson.se> Date: Fri, 8 Dec 2000 01:02:20 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Mobile IPv4/6 interworking draft X-To: Shiao-Li Charles Tsao To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C06056.5099BB00 Content-Type: text/plain; charset="big5" > Hello, > > I don't believe there is a need for translators in either scenario below. > Comments inline > > > > > > In the draft-tsao-mobileip-dualstack-model-01.txt Tsao et al. suggests to > > use dual stack mobile nodes to allow it to roam in both IPv4 and IPv6 > > environment. There are two cases presented: > > 1. MN is visiting IPv6 network and wants to register to IPv4 HA > > 2. MN is visiting IPv4 network and wants to register to IPv6 HA > > > > In first case the MN sends MIPv4 messages in the payload of IPv6 datagrams > > and the border router of the IPv6 network translates the messages into > > IPv4. > > > => There is no need for translators in either case. For case (1) > IPv4 can be tunnelled into IPv6 up to a Tunnell End Point (TEP) > and then forwarded to the IPv4 network. Please refer to DSTM. > > In the second case 6 over 4 can be used to get connectivity > to the V6 network. > > Translators are ONLY needed if single stacked MNs are used, therefore > I don't see the need for translators in either case Yes, I agree. However, I think the above two solutions have certain assumptions on the network infrastructure. For example, in the first case, DSTM and SIIT should be implemented in the visited networks. => No only DSTM is required. You only need translators if you have 2 incompatible stacks in the end hosts. As for the second case, 6over4 mechanism assumes at least one IPv6 router implementing 6over4 method must be connected to the IPv4 domain. How about a MN moves to an IPv4 domain without IPv6 router connectivity ? => If the visited domain doesn't support any migration mechanism at all, then yes communication is impossible. The proposed dual stack mobile IP interworking draft is basically a MN-based approach regardless of the underlaying infrastructure. That is why we suggest to send MIPv4 messages in the payload of IPv6 datagrams or vice versa. Then, these messages are translated by translators such as SIIT or NAT-PT and forwarded to the destinations. => I'll have to read your draft again because I seem to see a different approach in this statement above. SIIT and NAT-PT translate headers, not payloads. MIPv4 messages can not be seen by SIIT because they run on the application layer. Again, the terminology is unclear to me, translators => incompatible stacks in the end hosts. Are you assuming that the MN is for example V4 and the HA is V6 only ?? If you just want to encapsulate then you don't need translators. Hesham ------_=_NextPart_001_01C06056.5099BB00 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable RE: Re: [MOBILE-IP] Mobile IPv4/6 interworking draft

 
> Hello,
>
> I don't believe there is a need for translators = in either scenario
below.
> Comments inline
>
>
>
>
> > In the = draft-tsao-mobileip-dualstack-model-01.txt Tsao et al.
suggests to
> > use dual stack mobile nodes to allow it to = roam in both IPv4 and
IPv6
> > environment. There are two cases = presented:
> > 1. MN is visiting IPv6 network and wants = to register to IPv4 HA
> > 2. MN is visiting IPv4 network and wants = to register to IPv6 HA
> >
> > In first case the MN sends MIPv4 messages = in the payload of IPv6
datagrams
> > and the border router of the IPv6 network = translates the messages
into
> > IPv4.
> >
>         = =3D> There is no need for translators in either case. For = case
(1)
>         = IPv4 can be tunnelled into IPv6 up to a Tunnell End Point
(TEP)
>         = and then forwarded to the IPv4 network. Please refer to DSTM.
>
>         = In the second case 6 over 4 can be used to get connectivity
>         = to the V6 network.
>
>         = Translators are ONLY needed if single stacked MNs are used,
therefore
>         = I don't see the need for translators in either case

Yes, I agree.
However, I think the above two solutions have = certain assumptions on the
network infrastructure. For example, in the first = case, DSTM and SIIT
should be implemented in the visited = networks.

=3D> No only DSTM is required. You only need = translators if
you have 2 incompatible stacks in the end = hosts.

 As for the second case,
6over4 mechanism assumes at least one IPv6 router = implementing 6over4
method must be connected to the IPv4 domain. How = about a MN moves to an
IPv4 domain without IPv6 router connectivity ? =

=3D> If the visited domain doesn't support any =
migration mechanism at all, then yes = communication
is impossible.

The proposed dual stack mobile IP interworking draft = is basically a
MN-based approach regardless of the underlaying = infrastructure. That is
why we suggest to send MIPv4 messages in the payload = of IPv6 datagrams
or vice versa. Then, these messages are translated = by translators such
as SIIT or NAT-PT and forwarded to the = destinations.

=3D> I'll have to read your draft again because I =
seem to see a different approach in this = statement
above.
SIIT and NAT-PT translate headers, not payloads. =
MIPv4 messages can not be seen by SIIT = because
they run on the application layer. Again, the =
terminology is unclear to me, translators =3D> = incompatible
stacks in the end hosts. Are you assuming that =
the MN is for example V4 and the HA is V6 only = ??
If you just want to encapsulate then you don't = need
translators.

Hesham

 

------_=_NextPart_001_01C06056.5099BB00-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 7 10:55:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06795 for ; Thu, 7 Dec 2000 10:55:24 -0500 (EST) Received: from standards (47.234.32.16:2203) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC04B8@standards.nortelnetworks.com>; Thu, 7 Dec 2000 10:35:49 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 164905 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Dec 2000 10:35:48 -0500 Received: from ish7.ericsson.com.au (203.61.155.111:50903) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC04B6@standards.nortelnetworks.com>; Thu, 7 Dec 2000 10:35:47 -0500 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id CAA22573; Fri, 8 Dec 2000 02:49:55 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id CAA11916; Fri, 8 Dec 2000 02:52:49 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Dec 2000 02:53:06 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C06065.C9AC75A0" Approved-By: "Hesham Soliman (EPA)" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613F0D@eaubrnt018.epa.ericsson.se> Date: Fri, 8 Dec 2000 02:53:05 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Mobile IPv4/6 interworking draft X-To: Timo Alakoski To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C06065.C9AC75A0 Content-Type: text/plain; charset="iso-8859-1" > If people are interested in this area of work, we have a draft > that was presented in Pittsburgh and will be presented > again in San Diego in NGTRANS. > > http://www.ietf.org/internet-drafts/draft-soliman-siit-dstm-01.txt > > It addresses IPv6 <=> IPv4 communication in general and provides > additional requirements for MIP. I believe the Tsao's draft was trying to solve the problem of the mobile node visiting both IPv4 and IPv6 networks. Therefore the MN should be a dual stack. => Yes, that's a valid scenario, my point is you don't need translators for it. I hope this is a bit clearer. siit-dstm is IPv4/6 translator with a nice solution for IPv6 MN to be able to communicate with IPv4 CNs (or MNs). => Yes. > Comments are welcome. It was not clearly said in the draft how MN maintains the same IPv4 address when it moves to foreign network. Think the case where MNv6 has open connection to IPv4 CN (or MN) and has been assigned an IPv4 address by it's home AIIH server. Then it moves to a foreign IPv6 network (with siit-dst or some other translator). For outbound datagrams the MN must have the same IPv4 address as in home network so the solution would to have a static route 0::ffff/96 to MN's home SIIT router. Did I understand it correctly? => I'm not sure if I understand the question, but if the MN gets a V4 address from the home network, and moves to another foreign network that supports SIIT, then outbound packets will be translated as usual by the SIIT router. Inbound packets will of course be routed to the home domain (that owns the V4 address), intercepted by the SIIT router, and forwarded to the MN's COA (if a BU was received from the MN) or the Home Address (if no BU was received). In section 3 you are talking about IPv6-mapped and IPv6-translated addresses. Did I miss something or did you mean IPv4? :) => No you didn't miss anything, it's a typo. Thanks. Hesham ------_=_NextPart_001_01C06065.C9AC75A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] Mobile IPv4/6 interworking draft

> If people are interested in this area of work, = we have a draft
> that was presented in Pittsburgh and will be = presented
> again in San Diego in NGTRANS.
>
> http://www.ietf.org/internet-drafts/draft-soliman-siit= -dstm-01.txt
>
> It addresses IPv6 <=3D> IPv4 = communication in general and provides
> additional requirements for MIP.

I believe the Tsao's draft was trying to solve the = problem of the
mobile node visiting both IPv4 and IPv6 networks. = Therefore the MN
should be a dual stack.

=3D> Yes, that's a valid scenario, my point is = you
don't need translators for it. I hope this is =
a bit clearer.

siit-dstm is IPv4/6 translator with a nice
solution for IPv6 MN to be able to communicate with = IPv4 CNs (or MNs).

=3D> Yes.

> Comments are welcome.

It was not clearly said in the draft how MN maintains = the same
IPv4 address when it moves to foreign = network.

Think the case where MNv6 has open connection to IPv4 = CN (or MN) and
has been assigned an IPv4 address by it's home AIIH = server. Then it
moves to a foreign IPv6 network (with siit-dst or = some other
translator). For outbound datagrams the MN must have = the same IPv4
address as in home network so the solution would to = have a static
route 0::ffff/96 to MN's home SIIT router. Did I = understand it
correctly?

=3D> I'm not sure if I understand the question, = but
if the MN gets a V4 address from the home network, =
and moves to another foreign network that = supports
SIIT, then outbound packets will be = translated
as usual by the SIIT router. Inbound packets = will
of course be routed to the home domain (that owns =
the V4 address), intercepted by the SIIT router, =
and forwarded to the MN's COA (if a BU was = received
from the MN) or the Home Address (if no BU was =
received).

In section 3 you are talking about IPv6-mapped and = IPv6-translated
addresses. Did I miss something or did you mean = IPv4? :)

=3D> No you didn't miss anything, it's a typo. =
Thanks.


Hesham

------_=_NextPart_001_01C06065.C9AC75A0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 7 20:16:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21471 for ; Thu, 7 Dec 2000 20:16:42 -0500 (EST) Received: from standards (47.234.32.16:1368) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0767@standards.nortelnetworks.com>; Thu, 7 Dec 2000 19:56:51 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0391 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Dec 2000 19:56:50 -0500 Received: from boreas.isi.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0765@standards.nortelnetworks.com>; Thu, 7 Dec 2000 19:56:50 -0500 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA13885; Thu, 7 Dec 2000 17:14:31 -0800 (PST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Message-ID: <200012080114.RAA13885@boreas.isi.edu> Date: Thu, 7 Dec 2000 17:14:31 -0800 Reply-To: RFC Editor Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: RFC Editor Subject: [MOBILE-IP] RFC 3012 on Mobile IPv4 Challenge/Response To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3012 Title: Mobile IPv4 Challenge/Response Extensions Author(s): C. Perkins, P. Calhoun Status: Standards Track Date: November 2000 Mailbox: charliep@iprg.nokia.com, pcalhoun@eng.sun.com Pages: 17 Characters: 37005 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mobileip-challenge-13.txt URL: ftp://ftp.isi.edu/in-notes/rfc3012.txt Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, this extension does not provide ironclad replay protection for the foreign agent, and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. This document is a product of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <001207171217.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3012 --OtherAccess Content-Type: Message/External-body; name="rfc3012.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <001207171217.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 8 02:30:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23269 for ; Fri, 8 Dec 2000 02:30:07 -0500 (EST) Received: from standards (47.234.32.16:4930) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0934@standards.nortelnetworks.com>; Fri, 8 Dec 2000 2:10:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1023 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 02:10:27 -0500 Received: from m018.com (210.112.10.141:21226) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0932@standards.nortelnetworks.com>; Fri, 8 Dec 2000 2:10:26 -0500 Received: from ns ([211.113.87.7]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 8 Dec 2000 16:24:26 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Approved-By: "Lee, Jiwoong" Message-ID: <01fb01c060e8$7fe272c0$d012060a@hansol.co.kr> Date: Fri, 8 Dec 2000 16:28:44 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: [MOBILE-IP] Presentation at 49th meeting - SGM Support in Mobile IP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear All For the sake of some who are interested in "Small Group Multicast support in Mobile IP", I put the presentation file on the internet before the meeting. The URL is http://my.dreamwiz.com/musemaya/49th_IETF-SGM_Support_in_Mobile_IP-by_Jiwoon g_Lee.ppt I hope to hear many comments from all of you. Thank you, Jiwoong Lee From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 8 02:55:50 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28906 for ; Fri, 8 Dec 2000 02:55:50 -0500 (EST) Received: from standards (47.234.32.16:4930) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0993@standards.nortelnetworks.com>; Fri, 8 Dec 2000 2:36:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1154 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 02:36:22 -0500 Received: from csmail.cscoms.com (mail.cscoms.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0991@standards.nortelnetworks.com>; Fri, 8 Dec 2000 2:36:20 -0500 Received: from lfchost ([202.183.248.188]) by csmail.cscoms.com (8.10.2/8.10.2) with SMTP id eB87rsD28293 for ; Fri, 8 Dec 2000 14:53:55 +0700 (ICT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003E_01C06127.4F5408A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Approved-By: Naiyana Thamcheeveevong Message-ID: <004101c060ec$a3618700$0401010a@cscoms.net> Date: Fri, 8 Dec 2000 14:58:22 +0700 Reply-To: Naiyana Thamcheeveevong Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Naiyana Thamcheeveevong Subject: [MOBILE-IP] unsubscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_003E_01C06127.4F5408A0 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_003E_01C06127.4F5408A0 Content-Type: text/html; charset="windows-874" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_003E_01C06127.4F5408A0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 8 04:43:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14931 for ; Fri, 8 Dec 2000 04:43:02 -0500 (EST) Received: from standards (47.234.32.16:1558) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0A2B@standards.nortelnetworks.com>; Fri, 8 Dec 2000 4:23:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1349 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 04:23:34 -0500 Received: from mgw-x4.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0A29@standards.nortelnetworks.com>; Fri, 8 Dec 2000 4:23:32 -0500 Received: from esvir10nok.nokia.com (esvir10nok.nokia.com [131.228.20.82]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eB89f1K21747 for ; Fri, 8 Dec 2000 11:41:01 +0200 (EET) Received: from esebh02nok.ntc.nokia.com (unverified) by esvir10nok.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 8 Dec 2000 11:41:02 +0200 Received: by esebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 8 Dec 2000 11:41:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Approved-By: Timo.Alakoski@NOKIA.COM Message-ID: <593F7F3472A5D211B99B0008C7EAA08A053447EA@eseis02nok> Date: Fri, 8 Dec 2000 11:40:59 +0200 Reply-To: Timo.Alakoski@nokia.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Timo Alakoski Subject: Re: [MOBILE-IP] Mobile IPv4/6 interworking draft To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, > It was not clearly said in the draft how MN maintains the same > IPv4 address when it moves to foreign network. > Think the case where MNv6 has open connection to IPv4 CN (or MN) and > has been assigned an IPv4 address by it's home AIIH server. Then it > moves to a foreign IPv6 network (with siit-dst or some other > translator). For outbound datagrams the MN must have the same IPv4 > address as in home network so the solution would to have a static > route 0::ffff/96 to MN's home SIIT router. Did I understand it > correctly? > > => I'm not sure if I understand the question, but > if the MN gets a V4 address from the home network, > and moves to another foreign network that supports > SIIT, then outbound packets will be translated > as usual by the SIIT router. Inbound packets will > of course be routed to the home domain (that owns > the V4 address), intercepted by the SIIT router, > and forwarded to the MN's COA (if a BU was received > from the MN) or the Home Address (if no BU was > received). I was thinking the situation where those IPv6 SIIT networks are surrounded by ingress filters. When MN gets V4 address in the home network, the SIIT router can translate the packet and send it. But when the MN moves to a foreign network the translated datagrams will be discarded by the ingress filter because the source address of the IPv4 packets is not anymore topologically correct. The outbound IPv4 packets should originate from MN's home network. --Timo From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 8 06:42:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28231 for ; Fri, 8 Dec 2000 06:42:22 -0500 (EST) Received: from standards (47.234.32.16:2088) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0AF2@standards.nortelnetworks.com>; Fri, 8 Dec 2000 6:22:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1613 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 06:22:43 -0500 Received: from extmx.itri.org.tw by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0AF0@standards.nortelnetworks.com>; Fri, 8 Dec 2000 6:22:41 -0500 Received: from mail3.itri.org.tw (mail3.itri.org.tw [140.96.157.3]) by extmx.itri.org.tw (8.8.8/8.8.8) with ESMTP id TAA07783 for ; Fri, 8 Dec 2000 19:43:52 +0800 (CST) Received: from nti.itri.org.tw (nti.itri.org.tw [140.96.157.2]) by mail3.itri.org.tw (8.9.3+Sun/8.9.1) with ESMTP id TAA23192 for ; Fri, 8 Dec 2000 19:44:46 +0800 (CST) Received: from tsao (pc104125.ccl.itri.org.tw [140.96.104.125]) by nti.itri.org.tw (8.8.8/8.8.8) with SMTP id TAA13440 for ; Fri, 8 Dec 2000 19:40:52 +0800 (CST) References: <4B6BC00CD15FD2119E5F0008C7A419A50C613F04@eaubrnt018.epa.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Approved-By: Shiao-Li Charles Tsao Message-ID: <004e01c0610b$f04f7e90$7d68608c@tsao> Date: Fri, 8 Dec 2000 19:42:18 +0800 Reply-To: Shiao-Li Charles Tsao Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Shiao-Li Charles Tsao Subject: Re: [MOBILE-IP] Mobile IPv4/6 interworking draft To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear all, ----- Original Message ----- From: "Hesham Soliman (EPA)" To: Sent: Thursday, December 07, 2000 8:30 AM Subject: Re: [MOBILE-IP] Mobile IPv4/6 interworking draft > Hello, > > I don't believe there is a need for translators in either scenario below. > Comments inline > > > > > > In the draft-tsao-mobileip-dualstack-model-01.txt Tsao et al. suggests to > > use dual stack mobile nodes to allow it to roam in both IPv4 and IPv6 > > environment. There are two cases presented: > > 1. MN is visiting IPv6 network and wants to register to IPv4 HA > > 2. MN is visiting IPv4 network and wants to register to IPv6 HA > > > > In first case the MN sends MIPv4 messages in the payload of IPv6 datagrams > > and the border router of the IPv6 network translates the messages into > > IPv4. > > > => There is no need for translators in either case. For case (1) > IPv4 can be tunnelled into IPv6 up to a Tunnell End Point (TEP) > and then forwarded to the IPv4 network. Please refer to DSTM. > > In the second case 6 over 4 can be used to get connectivity > to the V6 network. > > Translators are ONLY needed if single stacked MNs are used, therefore > I don't see the need for translators in either case Yes, I agree. However, I think the above two solutions have certain assumptions on the network infrastructure. For example, in the first case, DSTM and SIIT should be implemented in the visited networks. As for the second case, 6over4 mechanism assumes at least one IPv6 router implementing 6over4 method must be connected to the IPv4 domain. How about a MN moves to an IPv4 domain without IPv6 router connectivity ? The proposed dual stack mobile IP interworking draft is basically a MN-based approach regardless of the underlaying infrastructure. That is why we suggest to send MIPv4 messages in the payload of IPv6 datagrams or vice versa. Then, these messages are translated by translators such as SIIT or NAT-PT and forwarded to the destinations. We haven't taken AAA issues into consideration in the current draft. But I think the proposed draft does not introduce new security issues beyond the security issues presented in mobile IP and translator mechanisms such as SIIT and NAT-PT. Comments are welcome !!! Shiao-Li Tsao From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 8 06:50:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29125 for ; Fri, 8 Dec 2000 06:50:18 -0500 (EST) Received: from standards (47.234.32.16:2088) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0B11@standards.nortelnetworks.com>; Fri, 8 Dec 2000 6:25:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1650 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 06:25:36 -0500 Received: from extmx.itri.org.tw by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0B0F@standards.nortelnetworks.com>; Fri, 8 Dec 2000 6:25:32 -0500 Received: from mail3.itri.org.tw (mail3.itri.org.tw [140.96.157.3]) by extmx.itri.org.tw (8.8.8/8.8.8) with ESMTP id TAA05231 for ; Fri, 8 Dec 2000 19:46:33 +0800 (CST) Received: from nti.itri.org.tw (nti.itri.org.tw [140.96.157.2]) by mail3.itri.org.tw (8.9.3+Sun/8.9.1) with ESMTP id TAA23262 for ; Fri, 8 Dec 2000 19:47:28 +0800 (CST) Received: from tsao (pc104125.ccl.itri.org.tw [140.96.104.125]) by nti.itri.org.tw (8.8.8/8.8.8) with ESMTP id TAA14271 for ; Fri, 8 Dec 2000 19:43:39 +0800 (CST) References: <4B6BC00CD15FD2119E5F0008C7A419A50C613F09@eaubrnt018.epa.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01C0614F.5EAFE3F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Approved-By: Shiao-Li Charles Tsao Message-ID: <006501c0610c$50a9c8e0$7d68608c@tsao> Date: Fri, 8 Dec 2000 19:45:08 +0800 Reply-To: Shiao-Li Charles Tsao Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Shiao-Li Charles Tsao Subject: Re: [MOBILE-IP] Mobile IPv4/6 interworking draft To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0062_01C0614F.5EAFE3F0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Fri, 8 Dec 2000 01:02:20 +1100, Hesham Soliman (EPA) wrote: > >> Hello, >> >> I don't believe there is a need for translators in either scenario >below. >> Comments inline >> > In the draft-tsao-mobileip-dualstack-model-01.txt Tsao et al. >suggests to >> > use dual stack mobile nodes to allow it to roam in both IPv4 and >IPv6 >> > environment. There are two cases presented: >> > 1. MN is visiting IPv6 network and wants to register to IPv4 HA >> > 2. MN is visiting IPv4 network and wants to register to IPv6 HA >> > >> > In first case the MN sends MIPv4 messages in the payload of IPv6 >datagrams >> > and the border router of the IPv6 network translates the messages >into >> > IPv4. >> > >> =3D> There is no need for translators in either case. For = case >(1) >> IPv4 can be tunnelled into IPv6 up to a Tunnell End Point >(TEP) >> and then forwarded to the IPv4 network. Please refer to DSTM. >> >> In the second case 6 over 4 can be used to get connectivity >> to the V6 network. >> >> Translators are ONLY needed if single stacked MNs are used, >therefore >> I don't see the need for translators in either case > >Yes, I agree. >However, I think the above two solutions have certain assumptions on = the >network infrastructure. For example, in the first case, DSTM and SIIT >should be implemented in the visited networks. > >=3D> No only DSTM is required. You only need translators if >you have 2 incompatible stacks in the end hosts. You are right. Translators are required if CN and MN have incompatible = stacks. In the dual stack interworking draft, I assume CN and MN might = have incompatible stacks. > > As for the second case, >6over4 mechanism assumes at least one IPv6 router implementing 6over4 >method must be connected to the IPv4 domain. How about a MN moves to an >IPv4 domain without IPv6 router connectivity ? > >=3D> If the visited domain doesn't support any >migration mechanism at all, then yes communication >is impossible. > >The proposed dual stack mobile IP interworking draft is basically a >MN-based approach regardless of the underlaying infrastructure. That is >why we suggest to send MIPv4 messages in the payload of IPv6 datagrams >or vice versa. Then, these messages are translated by translators such >as SIIT or NAT-PT and forwarded to the destinations. > >=3D> I'll have to read your draft again because I >seem to see a different approach in this statement >above. >SIIT and NAT-PT translate headers, not payloads. >MIPv4 messages can not be seen by SIIT because >they run on the application layer. Again, the >terminology is unclear to me, translators =3D> incompatible >stacks in the end hosts. Are you assuming that >the MN is for example V4 and the HA is V6 only ?? >If you just want to encapsulate then you don't need >translators. > Yes, SIIT and NAT-PT only translate headers. So, we suggest MNv4 to send = MIPv4 messages with an IPv6 header to HAv4 while it is in IPv6-only = network or vice versa. SIIT and NAT-PT can translate header (IPv6 header = to IPv4 header or vice versa) for us. Then, MIP messages can be = recognized by HAv4. In the draft, we assume MN and HA is in the same IP stack. But the CN = can be IPv6 or IPv4 and MN can migrate to IPv4 or IPv6 networks. If CN = is IPv4 and MNv4 wants to send MIPv4 messages such as Binding Update to = CNv4, the scenario is similar to HAv4 case. If CN is IPv6, CNv6 has to = communicate MNv4 using IPv4-mapped address or something like that. By the way, MIP messages such as Binding Update are incompatible in = MIPv4 and MIPv6. There is another problem if MNv4 wants to update = binding information in CNv6 or vice versa. We submitted another draft = about application level gateway which translates MIPv4 and MIPv6 = messages. http://search.ietf.org/internet-drafts/draft-tsao-mobileip-00.txt I will also present the draft in the Mobile IP WG and NGTRANS WG at San = Diego meeting. I do appreciate for your comments and suggestions. Shiao-Li Tsao ------=_NextPart_000_0062_01C0614F.5EAFE3F0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Fri, 8 Dec 2000 01:02:20 = +1100, Hesham=20 Soliman (EPA)
<Hesham.Soliman@ericsson.com.au> wrote:

>
>> = Hello,
>>
>> I=20 don't believe there is a need for translators in either=20 scenario
>below.
>> Comments inline

>> > = In the=20 draft-tsao-mobileip-dualstack-model-01.txt Tsao et al.
>suggests=20 to
>> > use dual stack mobile nodes to allow it to roam in = both IPv4=20 and
>IPv6
>> > environment. There are two cases=20 presented:
>> > 1. MN is visiting IPv6 network and wants to = register=20 to IPv4 HA
>> > 2. MN is visiting IPv4 network and wants to = register=20 to IPv6 HA
>> >
>> > In first case the MN sends = MIPv4=20 messages in the payload of IPv6
>datagrams
>> > and = the border=20 router of the IPv6 network translates the = messages
>into
>> >=20 IPv4.
>>=20 >
>>         =3D> = There is=20 no need for translators in either case. For=20 case
>(1)
>>       &nbs= p; IPv4=20 can be tunnelled into IPv6 up to a Tunnell End=20 Point
>(TEP)
>>       &= nbsp;=20 and then forwarded to the IPv4 network. Please refer to=20 DSTM.
>>
>>       &n= bsp; In=20 the second case 6 over 4 can be used to get=20 connectivity
>>         = to the=20 V6=20 network.
>>
>>       = ; =20 Translators are ONLY needed if single stacked MNs are=20 used,
>therefore
>>      &nb= sp; =20 I don't see the need for translators in either case
>
>Yes, = I=20 agree.
>However, I think the above two solutions have certain = assumptions=20 on the
>network infrastructure. For example, in the first case, = DSTM and=20 SIIT
>should be implemented in the visited = networks.
>
>=3D>=20 No only DSTM is required. You only need translators if
>you have 2 = incompatible stacks in the end hosts.

You are right. Translators = are=20 required if CN and MN have incompatible stacks. In the dual stack = interworking=20 draft, I assume CN and MN might have incompatible = stacks.

>
> As=20 for the second case,
>6over4 mechanism assumes at least one IPv6 = router=20 implementing 6over4
>method must be connected to the IPv4 domain. = How=20 about a MN moves to an
>IPv4 domain without IPv6 router = connectivity=20 ?
>
>=3D> If the visited domain doesn't support=20 any
>migration mechanism at all, then yes communication
>is=20 impossible.
>
>The proposed dual stack mobile IP = interworking draft=20 is basically a
>MN-based approach regardless of the underlaying=20 infrastructure. That is
>why we suggest to send MIPv4 messages in = the=20 payload of IPv6 datagrams
>or vice versa. Then, these messages are = translated by translators such
>as SIIT or NAT-PT and forwarded to = the=20 destinations.
>
>=3D> I'll have to read your draft again = because=20 I
>seem to see a different approach in this=20 statement
>above.
>SIIT and NAT-PT translate headers, not=20 payloads.
>MIPv4 messages can not be seen by SIIT = because
>they run=20 on the application layer. Again, the
>terminology is unclear to = me,=20 translators =3D> incompatible
>stacks in the end hosts. Are you = assuming=20 that
>the MN is for example V4 and the HA is V6 only ??
>If = you just=20 want to encapsulate then you don't = need
>translators.
>

Yes,=20 SIIT and NAT-PT only translate headers. So, we suggest MNv4 to send = MIPv4=20 messages with an IPv6 header to HAv4 while it is in IPv6-only network or = vice=20 versa. SIIT and NAT-PT can translate header (IPv6 header to IPv4 header = or vice=20 versa) for us. Then, MIP messages can be recognized by HAv4.

In = the=20 draft, we assume MN and HA is in the same IP stack. But the CN can be = IPv6 or=20 IPv4 and MN can migrate to IPv4 or IPv6 networks. If CN is IPv4 and MNv4 = wants=20 to send MIPv4 messages such as Binding Update to CNv4, the scenario is = similar=20 to HAv4 case. If CN is IPv6, CNv6 has to communicate MNv4 using = IPv4-mapped=20 address or something like that.

By the way, MIP messages such as = Binding=20 Update are incompatible in MIPv4 and MIPv6. There is another problem if = MNv4=20 wants to update binding information in CNv6 or vice versa. We submitted = another=20 draft about application level gateway which translates MIPv4 and MIPv6=20 messages.
http://search.ietf.org/internet-drafts/draft-tsao-mobileip-00.tx= t

I will also present the draft in the = Mobile IP WG and=20 NGTRANS WG at San Diego meeting. I do appreciate for your comments and=20 suggestions.


Shiao-Li Tsao ------=_NextPart_000_0062_01C0614F.5EAFE3F0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 8 07:20:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02633 for ; Fri, 8 Dec 2000 07:20:54 -0500 (EST) Received: from standards (47.234.32.16:1088) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0B84@standards.nortelnetworks.com>; Fri, 8 Dec 2000 7:01:28 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1808 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 07:01:27 -0500 Received: from ish7.ericsson.com.au (203.61.155.111:39864) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0B82@standards.nortelnetworks.com>; Fri, 8 Dec 2000 7:01:26 -0500 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id XAA23090 for ; Fri, 8 Dec 2000 23:15:37 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id XAA23858 for ; Fri, 8 Dec 2000 23:18:32 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Dec 2000 23:18:50 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Approved-By: "Hesham Soliman (EPA)" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613F1B@eaubrnt018.epa.ericsson.se> Date: Fri, 8 Dec 2000 23:18:49 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Mobile IPv4/6 interworking draft To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > > => I'm not sure if I understand the question, but > > if the MN gets a V4 address from the home network, > > and moves to another foreign network that supports > > SIIT, then outbound packets will be translated > > as usual by the SIIT router. Inbound packets will > > of course be routed to the home domain (that owns > > the V4 address), intercepted by the SIIT router, > > and forwarded to the MN's COA (if a BU was received > > from the MN) or the Home Address (if no BU was > > received). > > I was thinking the situation where those IPv6 SIIT networks are > surrounded by ingress filters. When MN gets V4 address in the home > network, the SIIT router can translate the packet and send it. But > when the MN moves to a foreign network the translated datagrams will > be discarded by the ingress filter because the source address of the > IPv4 packets is not anymore topologically correct. The outbound > IPv4 packets should originate from MN's home network. > => Ok, sorry I didn't understand what you meant before. Yes that is an issue that we were meant to address in this revision but unfortunately there was no time. Of course the easy way out of this is to assume that inter-domain handoff will not be supported. But I agree it still needs some further work. Hesham From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 8 16:25:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00066 for ; Fri, 8 Dec 2000 16:25:10 -0500 (EST) Received: from standards (47.234.32.16:2324) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0FD7@standards.nortelnetworks.com>; Fri, 8 Dec 2000 16:05:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3251 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 16:05:36 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0FD5@standards.nortelnetworks.com>; Fri, 8 Dec 2000 16:05:35 -0500 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA19499; Fri, 8 Dec 2000 13:23:18 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA08487; Fri, 8 Dec 2000 13:23:12 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA26987; Fri, 8 Dec 2000 13:23:10 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Approved-By: Pat Calhoun Message-ID: Date: Fri, 8 Dec 2000 13:20:05 -0800 Reply-To: Pat Calhoun Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pat Calhoun Subject: Re: [MOBILE-IP] [diameter] AAA key distribution for Mobile IP X-To: Fredrik Johansson X-cc: Diameter Listan , AAA Listan To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" > Hi, > > Can anyone tell me how the temporary session keys generated by a Diameter > server will be distributed. The "AAA Registration Keys for Mobile IP" has > expired, is it still used, a new version coming soon? Or are there any new > extensions that should be used instead? > hmmm.... I was not aware that it had expired. Last I hear, the general idea was to do a last call on the document, but I have not heard from the chairs on that particular I-D. Raj, Phil? I can re-submit another version, if need be. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 8 18:35:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04143 for ; Fri, 8 Dec 2000 18:35:34 -0500 (EST) Received: from standards (47.234.32.16:4652) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC10C5@standards.nortelnetworks.com>; Fri, 8 Dec 2000 18:15:59 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3579 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 18:15:59 -0500 Received: from mgw-dax2.ext.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC10C3@standards.nortelnetworks.com>; Fri, 8 Dec 2000 18:15:58 -0500 Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eB8MY5614654 for ; Fri, 8 Dec 2000 16:34:05 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Fri, 8 Dec 2000 16:33:25 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 8 Dec 2000 16:33:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Approved-By: Basavaraj.Patil@NOKIA.COM Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E67F@daeis07nok> Date: Fri, 8 Dec 2000 16:29:21 -0600 Reply-To: Basavaraj.Patil@nokia.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] [diameter] AAA key distribution for Mobile IP X-To: Pat.Calhoun@Eng.Sun.COM, fredrik.johansson@ipunplugged.com X-cc: diameter@diameter.org, aaa-wg@merit.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Pat, I have not really seen a clamoring for this I-D in the WG. So the fact that it has expired and not realy caused any concern makes me believe if there is sufficient WG interest in this I-D. However, please do submit a newer version and we will take it from there. -Basavaraj > > > Hi, > > > > Can anyone tell me how the temporary session keys generated > by a Diameter > > server will be distributed. The "AAA Registration Keys for > Mobile IP" has > > expired, is it still used, a new version coming soon? Or > are there any new > > extensions that should be used instead? > > > hmmm.... I was not aware that it had expired. Last I hear, > the general idea > was to do a last call on the document, but I have not heard > from the chairs on > that particular I-D. > > Raj, Phil? > > I can re-submit another version, if need be. > > PatC > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Dec 11 03:30:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10326 for ; Mon, 11 Dec 2000 03:30:10 -0500 (EST) Received: from standards (47.234.32.16:2253) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1965@standards.nortelnetworks.com>; Mon, 11 Dec 2000 3:10:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6548 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Dec 2000 03:10:16 -0500 Received: from smtp2.cluster.oleane.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1963@standards.nortelnetworks.com>; Mon, 11 Dec 2000 3:10:16 -0500 Received: from oleane (dyn-1-1-004.Vin.dialup.oleane.fr [195.25.4.4]) by smtp2.cluster.oleane.net with SMTP id eBB8S6c99118 for ; Mon, 11 Dec 2000 09:28:06 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_016B_01C06354.F6FC33A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Approved-By: Peter Lewis Message-ID: <016e01c0634c$96fcfb40$8001a8c0@oleane.com> Date: Mon, 11 Dec 2000 09:30:13 +0100 Reply-To: Peter Lewis Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Peter Lewis Subject: [MOBILE-IP] "Betond Sonet/SDH" Call for paper To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_016B_01C06354.F6FC33A0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Gigabit Ethernet Digital Wrapper Issues Implementation of newly defined functionalities: STM-64, STM-256 = (positioning beside N x 2.5 G or P x 10 G)=20 Tandem connection monitoring FEC WDM DWDM issues:=20 - Transitional step between SDH and OTN=20 - Terabit networks - WDM for metro networks=20 The call for paper for the "Betond Sonet/SDH" conference has been = extended to January 20. Please take a look on: http://www.upperside.fr/babeyondsdh.htm ------=_NextPart_000_016B_01C06354.F6FC33A0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Gigabit Ethernet
Digital Wrapper Issues
Implementation of newly defined functionalities: STM-64, STM-256=20 (positioning beside N x 2.5 G or P x 10 G)
Tandem connection = monitoring FEC=20 WDM DWDM issues:
- Transitional step between SDH and OTN
- = Terabit=20 networks
- WDM for metro networks
 
The call for paper for the "Betond Sonet/SDH" conference has been = extended=20 to January 20.
 
Please take a look on:
http://www.upperside.fr/= babeyondsdh.htm
------=_NextPart_000_016B_01C06354.F6FC33A0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Dec 11 07:02:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02549 for ; Mon, 11 Dec 2000 07:02:58 -0500 (EST) Received: from standards (47.234.32.16:4925) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1A92@standards.nortelnetworks.com>; Mon, 11 Dec 2000 6:43:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6955 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Dec 2000 06:43:12 -0500 Received: from mailgestao.intra.cet.pt (194.65.138.12:2728) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1A90@standards.nortelnetworks.com>; Mon, 11 Dec 2000 6:43:11 -0500 Received: by mailgestao.intra.cet.pt with Internet Mail Service (5.5.2448.0) id ; Mon, 11 Dec 2000 11:57:51 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Approved-By: "Carlos Parada (EST)" Message-ID: <25CCC6566D01D411885B00A024559FB7DA6C0A@EXCHANGE_GERAL> Date: Mon, 11 Dec 2000 12:16:12 -0000 Reply-To: "Carlos Parada (EST)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Carlos Parada (EST)" Subject: [MOBILE-IP] Starting in Mobile IP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, I'm starting in the study of the Mobile IP. Can anyone tell me when I can find a good documentation about ?? (I've started with the RFC2002, and some others sites) Thanks in advance. Carlos Parada. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Dec 12 05:39:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04827 for ; Tue, 12 Dec 2000 05:39:43 -0500 (EST) Received: from standards (47.234.32.16:3588) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1E5A@standards.nortelnetworks.com>; Tue, 12 Dec 2000 5:19:48 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8235 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Dec 2000 05:19:48 -0500 Received: from gigi.excite.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1E58@standards.nortelnetworks.com>; Tue, 12 Dec 2000 5:19:43 -0500 Received: from almond.excite.com ([199.172.148.82]) by gigi.excite.com (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP id <20001212103739.FXOQ26449.gigi.excite.com@almond.excite.com> for ; Tue, 12 Dec 2000 02:37:39 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Excite Inbox X-Sender-Ip: 161.142.100.80 Approved-By: Coulibaly Yahaya Message-ID: <2375795.976617459088.JavaMail.imail@almond.excite.com> Date: Tue, 12 Dec 2000 02:37:39 -0800 Reply-To: Coulibaly Yahaya Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Coulibaly Yahaya Subject: [MOBILE-IP] Research in 4G mobility To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all, I am up for a research in Mobility management in 4G as my master program at University Malaysia So any body can advise where to start. Cool. On Mon, 11 Dec 2000 12:16:12 -0000, Carlos Parada (EST) wrote: > Hi, > > I'm starting in the study of the Mobile IP. > Can anyone tell me when I can find a good documentation about ?? > (I've started with the RFC2002, and some others sites) > > Thanks in advance. > > > Carlos Parada. _______________________________________________________ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Dec 12 11:55:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22004 for ; Tue, 12 Dec 2000 11:55:23 -0500 (EST) Received: from standards (47.234.32.16:4453) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1FF0@standards.nortelnetworks.com>; Tue, 12 Dec 2000 11:35:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8790 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Dec 2000 11:35:33 -0500 Received: from web804.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1FEE@standards.nortelnetworks.com>; Tue, 12 Dec 2000 11:35:32 -0500 Received: (qmail 24400 invoked by uid 60001); 12 Dec 2000 16:53:29 -0000 Received: from [47.230.0.42] by web804.mail.yahoo.com; Tue, 12 Dec 2000 08:53:29 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Approved-By: Kory Keith Message-ID: <20001212165329.24399.qmail@web804.mail.yahoo.com> Date: Tue, 12 Dec 2000 08:53:29 -0800 Reply-To: Kory Keith Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Kory Keith Subject: [MOBILE-IP] Mobile IPv4 Challenge/Response Extensions To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Questions concerning the new RFC: Section 3.2: Concerning STALE_CHALLENGE, the language used suggests that the Foreign Agent should keep all Challenge extensions that the MN has previously used. Surely, the FA can't be expected to store all of these values for the lifetime of the Moblie's session. If so, the memory requirement for supports the FAC go off the chart for any reasonable amount of subscribers. If not, what then is the functional difference between STALE_CHALLENGE and UNKNOWN_CHALLENGE? Both are reported as errors, but I'm unsure of the handling by the MN for these two errors. Also, does the FA keep the last advertised Challenge as an "always acceptable" value, or once the FA sends a RRP with a valid new Challenge, the AA becomes stale? Thank you, Kory Keith ===== korykeith@yahoo.com __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Dec 12 20:06:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21355 for ; Tue, 12 Dec 2000 20:06:28 -0500 (EST) Received: from standards (47.234.32.16:2663) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC21B7@standards.nortelnetworks.com>; Tue, 12 Dec 2000 19:46:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9395 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Dec 2000 19:46:40 -0500 Received: from hbhs.buaa.edu.cn by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC21B5@standards.nortelnetworks.com>; Tue, 12 Dec 2000 19:46:40 -0500 Received: from kanzhigang ([202.112.131.35]) by hbhs.buaa.edu.cn (Netscape Messaging Server 3.62) with SMTP id 968 for ; Wed, 13 Dec 2000 09:11:51 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Approved-By: kan zhi Message-ID: <01a801c064a1$821c9f40$238370ca@buaa.edu.cn> Date: Wed, 13 Dec 2000 09:10:39 +0800 Reply-To: kan zhi Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: kan zhi Subject: [MOBILE-IP] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id UAA21355 Hi, all, Nice to meet you. I am a newer of this list. BR, KanZhigang From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Dec 13 11:06:59 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07407 for ; Wed, 13 Dec 2000 11:06:58 -0500 (EST) Received: from standards (47.234.32.16:3118) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2450@standards.nortelnetworks.com>; Wed, 13 Dec 2000 10:46:47 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10295 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Dec 2000 10:46:46 -0500 Received: from smtp2.cluster.oleane.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC244E@standards.nortelnetworks.com>; Wed, 13 Dec 2000 10:46:46 -0500 Received: from oleane (dyn-1-1-140.Vin.dialup.oleane.fr [195.25.4.140]) by smtp2.cluster.oleane.net with SMTP id eBDG4jM21403 for ; Wed, 13 Dec 2000 17:04:45 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0099_01C06527.15D3B5E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Approved-By: Peter Lewis Message-ID: <009c01c0651e$b4740320$8001a8c0@oleane.com> Date: Wed, 13 Dec 2000 17:06:51 +0100 Reply-To: Peter Lewis Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Peter Lewis Subject: [MOBILE-IP] IPCN 2001: Call for proposals To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0099_01C06527.15D3B5E0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Building and designing IP cellular networks is still a challenge and = drain a lot of research and developpement activities by industry and = academic research laboratories. The IP-Based Cellular Networks = conference (IPCN 2001) will provide a state of the art of the current = research and developpement progress and will present an overview of the = current IETF and 3GPP activities in this area.=20 A call for proposals is online at: http://www.upperside.fr/baipcn2001.htm ------=_NextPart_000_0099_01C06527.15D3B5E0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
Building and designing IP = cellular=20 networks is still a challenge and drain a lot of research and=20 developpement activities by industry and academic research laboratories. = The=20 IP-Based Cellular Networks conference (IPCN 2001) will = provide=20 a state of the art of the current research and developpement progress = and will=20 present an overview of the current IETF and 3GPP = activities in=20 this area.

A call for proposals is online at:
http://www.upperside.fr/b= aipcn2001.htm
 
------=_NextPart_000_0099_01C06527.15D3B5E0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Dec 13 11:23:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09427 for ; Wed, 13 Dec 2000 11:23:46 -0500 (EST) Received: from standards (47.234.32.16:3118) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC24C6@standards.nortelnetworks.com>; Wed, 13 Dec 2000 11:03:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10452 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Dec 2000 11:03:57 -0500 Received: from rajma.kniveton.com (adsl-63-197-0-77.dsl.snfc21.pacbell.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC24C4@standards.nortelnetworks.com>; Wed, 13 Dec 2000 11:03:57 -0500 Received: from Kniveton.com (nachos.kniveton.com [192.168.1.69]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id eBDGLno42199 for ; Wed, 13 Dec 2000 08:21:49 -0800 (PST) X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: TJ@KNIVETON.COM Message-ID: <3A37A221.40573534@Kniveton.com> Date: Wed, 13 Dec 2000 08:21:53 -0800 Reply-To: Timothy J Kniveton Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Timothy J Kniveton Subject: [MOBILE-IP] [Fwd: Thought.. when a CN should send Binding Request] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: Thought.. when a CN should send Binding Request Date: Tue, 12 Dec 2000 14:38:22 -0800 From: "T.J. Kniveton" To: Hi, I am curious whether anyone has opinions on how to formulate a policy for sending Binding Requests from a Correspondent Node in Mobile IPv6. The draft suggests that it be done whenever a Binding is about to expire, if there is active communication happening with that Mobile Node and it "has indications, such as an open TCP connection to the mobile node, that it will continue this communication in the future." Since it's possible that the two nodes are engaging in connectionless communication, looking at state such as an open TCP connection, is not really sufficient to gauge whether communications will continue in the future. One simple policy is to define a BR trigger value, such that when the Binding Cache Entry's timeout falls below this value, any packet sent to the Mobile will include a Binding Request. In this way, a BR is sent when there is active communication (regardless of whether it's stateful), but it is not sent if there is nothing traveling between the CN and the MN. The interval between the trigger value and the BCE timeout should be set large enough so it is sufficient to pick up active traffic. Any comments or suggestions? Thanks, -- TJ Kniveton NOKIA Research From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Dec 13 13:05:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22899 for ; Wed, 13 Dec 2000 13:05:28 -0500 (EST) Received: from standards (47.234.32.16:2654) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC25A9@standards.nortelnetworks.com>; Wed, 13 Dec 2000 12:45:26 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10762 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Dec 2000 12:45:26 -0500 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC25A7@standards.nortelnetworks.com>; Wed, 13 Dec 2000 12:45:25 -0500 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eBDI3D423809; Wed, 13 Dec 2000 19:03:14 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA27240; Wed, 13 Dec 2000 19:03:13 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA80904; Wed, 13 Dec 2000 19:04:31 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Approved-By: Francis.Dupont@ENST-BRETAGNE.FR Message-ID: <200012131804.TAA80904@givry.rennes.enst-bretagne.fr> Date: Wed, 13 Dec 2000 19:04:31 +0100 Reply-To: Francis Dupont Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] [Fwd: Thought.. when a CN should send Binding Request] X-To: Timothy J Kniveton To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Wed, 13 Dec 2000 08:21:53 PST. <3A37A221.40573534@Kniveton.com> I am curious whether anyone has opinions on how to formulate a policy for sending Binding Requests from a Correspondent Node in Mobile IPv6. The draft suggests that it be done whenever a Binding is about to expire, if there is active communication happening with that Mobile Node and it "has indications, such as an open TCP connection to the mobile node, that it will continue this communication in the future." => specs suggests this because this is very easy to implement but you can use what you want, for instance a real inactivity detection. It is not critical to send BRs because if a binding times out then the first packet on the unoptimized path will recreate it. This is just a trade-off between a proactive and a reactive way to refresh bindings... The MN can refresh bindings too (and should do it in some cases, for instance for home registrations). Since it's possible that the two nodes are engaging in connectionless communication, looking at state such as an open TCP connection, is not really sufficient to gauge whether communications will continue in the future. => I agree and you have the same issue for the IPsec security association (there should be one for BU). One simple policy is to define a BR trigger value, such that when the Binding Cache Entry's timeout falls below this value, any packet sent to the Mobile will include a Binding Request. => this is a possibility. It can be very easy or a bit expensive depending of your implementation (binding cache management) and/or context (for instance the number of bindings). Do what you'd like... and keep specs as simple as possible! Any comments or suggestions? => done! Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Dec 13 13:40:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28519 for ; Wed, 13 Dec 2000 13:40:52 -0500 (EST) Received: from standards (47.234.32.16:4930) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2654@standards.nortelnetworks.com>; Wed, 13 Dec 2000 13:20:47 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10986 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Dec 2000 13:20:47 -0500 Received: from mailhub1.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2652@standards.nortelnetworks.com>; Wed, 13 Dec 2000 13:20:46 -0500 Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.16 #1) id 146GnR-0005YF-00; Wed, 13 Dec 2000 18:38:33 +0000 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 13 Dec 00 18:38:33 +0000 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 13 Dec 00 18:38:29 +0000 Received: from Mobile1 (143.167.59.139) by ridingwood.shef.ac.uk (Mercury 1.48); 13 Dec 00 18:38:21 +0000 References: <2375795.976617459088.JavaMail.imail@almond.excite.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Approved-By: cnyap Message-ID: <00b901c06533$73460500$923ba78f@Mobile1> Date: Wed, 13 Dec 2000 18:35:21 -0000 Reply-To: cnyap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cnyap Subject: Re: [MOBILE-IP] Research in 4G mobility X-To: Coulibaly Yahaya To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Currently Royal Institute of Technology(KTH) and Chalmers University of Technology. and working on 4G. http://www.s3.kth.se/radio/4GW/ It seems like there have not been much activites recently. Another place you can look at is Software Define Radio Forum http://www.sdrforum.org Cheers Chern Nam Yap MIEEE, MSc(Res), BSc(Hons) Research Associate Center for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield F132 Mappin Building Mappin Street Sheffield S1 3JD United Kingdom Tel:+44 (0) 114-222-5182 Mobile:+ 44(0) 7712804892 Web: www.mobile1.net E-mail: cny@ieee.org ----- Original Message ----- From: "Coulibaly Yahaya" To: Sent: Tuesday, December 12, 2000 10:37 AM Subject: [MOBILE-IP] Research in 4G mobility > Hi all, > > > I am up for a research in Mobility management in 4G as my master program at > University Malaysia > So any body can advise where to start. > > > Cool. > > > > On Mon, 11 Dec 2000 12:16:12 -0000, Carlos Parada (EST) wrote: > > > Hi, > > > > I'm starting in the study of the Mobile IP. > > Can anyone tell me when I can find a good documentation about ?? > > (I've started with the RFC2002, and some others sites) > > > > Thanks in advance. > > > > > > Carlos Parada. > > > > > > _______________________________________________________ > Send a cool gift with your E-Card > http://www.bluemountain.com/giftcenter/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Dec 13 20:45:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16421 for ; Wed, 13 Dec 2000 20:45:43 -0500 (EST) Received: from standards (47.234.32.16:2549) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC28BA@standards.nortelnetworks.com>; Wed, 13 Dec 2000 20:25:51 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11813 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Dec 2000 20:25:50 -0500 Received: from dns1.catt.ac.cn (202.106.106.98:1882) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC28B8@standards.nortelnetworks.com>; Wed, 13 Dec 2000 20:25:49 -0500 Received: from liangxg (GATEWAY [202.106.106.126]) by dns1.catt.ac.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YF2NCYG2; Thu, 14 Dec 2000 09:37:28 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C065B2.457714F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Approved-By: Xingang Liang Message-ID: <000b01c0656f$39308430$75ce12ac@MCSD.local> Date: Thu, 14 Dec 2000 09:43:11 +0800 Reply-To: Xingang Liang Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Xingang Liang Subject: [MOBILE-IP] Can anyone give me an explanation? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C065B2.457714F0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBldmVyeSBvbmU6DQogICAgIEkgYW0gd29ya2luZyBvbiB0aGUgSVAgaXNzdWVzIGluIDNH UFAsYnV0IG5vdyBJIGhhdmUgYSBxdWVzdGlvbiB0byBhc2s6IA0KICAgICBXaGF0IGlzIHRoZSBk aWZmZXJlbmNlIG9mICJDZWxsdWxhciBJUCIgYW5kICJXaXJlbGVzcyBJUCI/DQogICAgIEluIG15 IG9waW5pb24sSSB0aGluayB0aGF0IHRoZSBmb3JtZXIgcmVmZXJzIHRvIHRoZSB3aG9sbHkgYXJj aGl0ZWN0dXJlIGZyb20gdGhlIG1vYmlsZSBob3N0IHRvIGdhdGV3YXksd2hpbGUgdGhlIGxhdHRl ciByZWZlcnMgdG8gSVAgYXBwbGljYXRpb24gYmV0d2VlbiBCVFMgYW5kIHdpcmVsZXNzIHBob25l KG9yIE5vZGVCIGFuZCB3cCksdGhhdCBpcyB0aGUgYWlyIGludGVyZmFjZSB3aWxsIHVzZSB0aGUg d2lyZWxlc3MgaXAuDQogICAgIEkgZG9uJ3Qga25vdyB3aGV0aGVyIHdoYXQgSSB0aGluayBpcyBy aWdodCxjYW4gYW55b25lIGdpdmUgbWUgc29tZSBhZGp1c3RtZW50IG9yIGFkdmljZSx0aGFua3Mg YXQgYWxsISEhDQoNCkJlc3QgUmVnYXJkcw0KWGluZ2FuZyBMaWFuZw0KU3RhbmRhcmQgRGVwYXJ0 bWVudCBvZiBNb2JpbGUgQ2VudGVyDQpDaGluYSBBY2FkZW15IG9mIFRlbGVjb21tdW5pY2F0aW9u IFRlY2hub2xvZ3kNCk5vLjQwLFh1ZXl1YW4gUm9hZCxIYWlkaWFuIERpc3RyaWN0DQpCZWlqaW5n LENoaW5hIDEwMDA4Mw0KVEVMOis4NjEwLTYyMzA0NDIyRVhUMjI1DQpGQVg6Kzg2MTAtNjIzMDMx MjcNCkVfTUFJTDpsaWFuZ3hnQGNhdHQuYWMuY24NCg0K ------=_NextPart_000_0008_01C065B2.457714F0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+PEJBU0UgDQpocmVmPSJmaWxlOi8vQzpcUHJv Z3JhbSBGaWxlc1xDb21tb24gRmlsZXNcTWljcm9zb2Z0IFNoYXJlZFxTdGF0aW9uZXJ5XCI+DQo8 U1RZTEU+Qk9EWSB7DQoJQkFDS0dST1VORC1QT1NJVElPTjogbGVmdCB0b3A7IEJBQ0tHUk9VTkQt UkVQRUFUOiBuby1yZXBlYXQ7IENPTE9SOiAjMDAwMDAwOyBGT05ULUZBTUlMWTogQ291cmllciBO ZXcgQ0U7IEZPTlQtU0laRTogMTBwdDsgTUFSR0lOLUxFRlQ6IDI1cHg7IE1BUkdJTi1UT1A6IDI1 cHgNCn0NCjwvU1RZTEU+DQoNCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA1LjAwLjI5MjAuMCIgbmFt ZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj5EZWFyIGV2 ZXJ5IG9uZTo8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgYW0gd29ya2lu ZyBvbiB0aGUgSVAgaXNzdWVzIGluIDNHUFAsYnV0IG5vdyBJIA0KaGF2ZSBhIHF1ZXN0aW9uIHRv IGFzazogPC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXaGF0IGlzIHRoZSBk aWZmZXJlbmNlIG9mICJDZWxsdWxhciBJUCIgYW5kIA0KIldpcmVsZXNzIElQIj88L0RJVj4NCjxE SVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluIG15IG9waW5pb24sSSB0aGluayB0aGF0IHRo ZSBmb3JtZXIgcmVmZXJzIHRvIA0KdGhlIHdob2xseSBhcmNoaXRlY3R1cmUgZnJvbSB0aGUgbW9i aWxlIGhvc3QgdG8gZ2F0ZXdheSx3aGlsZSB0aGUgbGF0dGVyIHJlZmVycyANCnRvIElQIGFwcGxp Y2F0aW9uIGJldHdlZW4gQlRTIGFuZCB3aXJlbGVzcyBwaG9uZShvciBOb2RlQiBhbmQgd3ApLHRo YXQgaXMgdGhlIA0KYWlyIGludGVyZmFjZSB3aWxsIHVzZSB0aGUgd2lyZWxlc3MgaXAuPC9ESVY+ DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJIGRvbid0IGtub3cgd2hldGhlciB3aGF0 IEkgdGhpbmsgaXMgcmlnaHQsY2FuIA0KYW55b25lIGdpdmUgbWUgc29tZSBhZGp1c3RtZW50IG9y IGFkdmljZSx0aGFua3MgYXQgYWxsISEhPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5C ZXN0IFJlZ2FyZHM8L0RJVj4NCjxESVY+WGluZ2FuZyBMaWFuZzxCUj5TdGFuZGFyZCBEZXBhcnRt ZW50IG9mIE1vYmlsZSBDZW50ZXI8QlI+Q2hpbmEgQWNhZGVteSBvZiANClRlbGVjb21tdW5pY2F0 aW9uIFRlY2hub2xvZ3k8QlI+Tm8uNDAsWHVleXVhbiBSb2FkLEhhaWRpYW4gDQpEaXN0cmljdDxC Uj5CZWlqaW5nLENoaW5hIA0KMTAwMDgzPEJSPlRFTDorODYxMC02MjMwNDQyMkVYVDIyNTxCUj5G QVg6Kzg2MTAtNjIzMDMxMjc8QlI+PEEgDQpocmVmPSJtYWlsdG86RV9NQUlMOmxpYW5neGdAY2F0 dC5hYy5jbiI+RV9NQUlMOmxpYW5neGdAY2F0dC5hYy5jbjwvQT48QlI+PC9ESVY+PC9CT0RZPjwv SFRNTD4NCg== ------=_NextPart_000_0008_01C065B2.457714F0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 07:16:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10733 for ; Thu, 14 Dec 2000 07:16:13 -0500 (EST) Received: from standards (47.234.32.16:3436) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2A5B@standards.nortelnetworks.com>; Thu, 14 Dec 2000 6:56:13 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12372 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 06:56:13 -0500 Received: from artemis.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2A59@standards.nortelnetworks.com>; Thu, 14 Dec 2000 6:56:13 -0500 Received: from [143.167.1.9] (helo=mailhub1.shef.ac.uk) by artemis.shef.ac.uk with esmtp (Exim 3.16 #2) id 146XGl-00010B-00; Thu, 14 Dec 2000 12:13:55 +0000 Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.16 #1) id 146XGl-0001Dj-00; Thu, 14 Dec 2000 12:13:55 +0000 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 14 Dec 00 12:13:56 +0000 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 14 Dec 00 12:13:49 +0000 Received: from Mobile1 (143.167.59.139) by ridingwood.shef.ac.uk (Mercury 1.48); 14 Dec 00 12:13:43 +0000 References: <000b01c0656f$39308430$75ce12ac@MCSD.local> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0078_01C065C6.E05AF040" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Scanner: exiscan@artemis *146XGl-00010B-00* http://duncanthrax.net/exiscan/ Approved-By: cnyap Message-ID: <007b01c065c6$e0d09570$923ba78f@Mobile1> Date: Thu, 14 Dec 2000 12:10:40 -0000 Reply-To: cnyap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cnyap Subject: Re: [MOBILE-IP] Can anyone give me an explanation? X-To: Xingang Liang To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0078_01C065C6.E05AF040 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Yes.=20 Cellular IP is an architecture built on top of Mobile IP. It can work without Mobile IP, but within the specific domain. Currently there is no formal definiton for Wireless IP. It just mean any IP application runs over Wireless Access Technology. The most formal definition currently available is in the following link. http://es53060.easystreet.com/wirelessipcase.htm Cheers Chern Nam Yap MIEEE, MSc(Res), BSc(Hons) Research Associate Center for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield F132 Mappin Building Mappin Street Sheffield S1 3JD United Kingdom Tel:+44 (0) 114-222-5182 Mobile:+ 44(0) 7712804892 Web: www.mobile1.net E-mail: cny@ieee.org ----- Original Message -----=20 From: Xingang Liang=20 To: MOBILE-IP@standards.nortelnetworks.com=20 Sent: Thursday, December 14, 2000 1:43 AM Subject: [MOBILE-IP] Can anyone give me an explanation? Dear every one: I am working on the IP issues in 3GPP,but now I have a question = to ask:=20 What is the difference of "Cellular IP" and "Wireless IP"? In my opinion,I think that the former refers to the wholly = architecture from the mobile host to gateway,while the latter refers to = IP application between BTS and wireless phone(or NodeB and wp),that is = the air interface will use the wireless ip. I don't know whether what I think is right,can anyone give me = some adjustment or advice,thanks at all!!! Best Regards Xingang Liang Standard Department of Mobile Center China Academy of Telecommunication Technology No.40,Xueyuan Road,Haidian District Beijing,China 100083 TEL:+8610-62304422EXT225 FAX:+8610-62303127 E_MAIL:liangxg@catt.ac.cn ------=_NextPart_000_0078_01C065C6.E05AF040 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi
 
Yes.
Cellular IP is an architecture built on top = of Mobile=20 IP.
It can work without Mobile IP, but within the = specific=20 domain.
 
Currently there is no formal definiton for = Wireless=20 IP.
It just mean any IP application runs over = Wireless Access=20 Technology.
The most formal definition currently available = is in the=20 following link.
http://es53060.= easystreet.com/wirelessipcase.htm
 
Cheers
Chern Nam Yap
MIEEE, MSc(Res), = BSc(Hons)
Research=20 Associate
Center for Mobile Communication Research
Department of=20 Electronic and Electrical Engineering
University of Sheffield
F132 = Mappin=20 Building
Mappin Street
Sheffield S1 3JD
United = Kingdom
Tel:+44 (0)=20 114-222-5182
Mobile:+ 44(0) 7712804892
Web: www.mobile1.net
E-mail: cny@ieee.org
 
 
 
 
 
----- Original Message -----
From:=20 Xingang Liang=20
To: MOBILE-IP@standard= s.nortelnetworks.com=20
Sent: Thursday, December 14, = 2000 1:43=20 AM
Subject: [MOBILE-IP] Can anyone = give me=20 an explanation?

Dear every one:
     I am working on the IP issues in = 3GPP,but now I=20 have a question to ask:
     What is the difference of "Cellular IP" = and=20 "Wireless IP"?
     In my opinion,I think that the former = refers to=20 the wholly architecture from the mobile host to gateway,while the = latter=20 refers to IP application between BTS and wireless phone(or NodeB and = wp),that=20 is the air interface will use the wireless ip.
     I don't know whether what I think is = right,can=20 anyone give me some adjustment or advice,thanks at all!!!
 
Best Regards
Xingang Liang
Standard Department of Mobile Center
China = Academy of=20 Telecommunication Technology
No.40,Xueyuan Road,Haidian=20 District
Beijing,China=20 100083
TEL:+8610-62304422EXT225
FAX:+8610-62303127
E_MAIL:liangxg@catt.ac.cn
------=_NextPart_000_0078_01C065C6.E05AF040-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 07:53:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14797 for ; Thu, 14 Dec 2000 07:53:14 -0500 (EST) Received: from standards (47.234.32.16:1567) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2AC8@standards.nortelnetworks.com>; Thu, 14 Dec 2000 7:33:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12517 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 07:33:18 -0500 Received: from mr.tuwien.ac.at by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2AC6@standards.nortelnetworks.com>; Thu, 14 Dec 2000 7:33:17 -0500 Received: from pop.tuwien.ac.at (phaeton.ikn.tuwien.ac.at [128.131.88.62]) by mr.tuwien.ac.at (8.11.1/8.11.1) with ESMTP id eBECpJN13663 for ; Thu, 14 Dec 2000 13:51:19 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4B6BC00CD15FD2119E5F0008C7A419A50C613F04@eaubrnt018.epa.ericsson.se> <004e01c0610b$f04f7e90$7d68608c@tsao> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Nam Hoang Nguyen Message-ID: <3A38CB0C.33478D7F@pop.tuwien.ac.at> Date: Thu, 14 Dec 2000 14:28:44 +0100 Reply-To: Hoang.Nguyen-Nam@tuwien.ac.at Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Nam Hoang Nguyen Subject: [MOBILE-IP] About Mobile IP experiment/prototype ! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear all ! I plan to build an experiment/prototype for Mobile IPv4/ or IPv6 and I am not sure about which equipments (hardware, software) are needed and how to start. Has anyone done such a similar thing ?? Where (website) should I look for ?? Please give me suggestions, any is highly appreciated. Many thanks in advance ! Regards Nam From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 11:04:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19472 for ; Thu, 14 Dec 2000 11:04:45 -0500 (EST) Received: from standards (47.234.32.16:2704) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2B73@standards.nortelnetworks.com>; Thu, 14 Dec 2000 10:44:14 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12744 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 10:44:13 -0500 Received: from mailhub1.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2B71@standards.nortelnetworks.com>; Thu, 14 Dec 2000 10:44:13 -0500 Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.16 #1) id 146apT-0001Cl-00; Thu, 14 Dec 2000 16:01:59 +0000 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 14 Dec 00 16:01:59 +0000 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 14 Dec 00 16:01:47 +0000 Received: from Mobile1 (143.167.59.139) by ridingwood.shef.ac.uk (Mercury 1.48); 14 Dec 00 16:01:37 +0000 References: <4B6BC00CD15FD2119E5F0008C7A419A50C613F04@eaubrnt018.epa.ericsson.se> <004e01c0610b$f04f7e90$7d68608c@tsao> <3A38CB0C.33478D7F@pop.tuwien.ac.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Approved-By: cnyap Message-ID: <01a401c065e6$b7bc0550$923ba78f@Mobile1> Date: Thu, 14 Dec 2000 15:58:36 -0000 Reply-To: cnyap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cnyap Subject: Re: [MOBILE-IP] About Mobile IP experiment/prototype ! X-To: Hoang.Nguyen-Nam@tuwien.ac.at To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi ----- Original Message ----- From: "Nam Hoang Nguyen" To: Sent: Thursday, December 14, 2000 1:28 PM Subject: [MOBILE-IP] About Mobile IP experiment/prototype ! > Dear all ! > > I plan to build an experiment/prototype for Mobile IPv4/ or IPv6 and I am not > sure about which equipments (hardware, software) are needed and how to start. > Has anyone done such a similar thing ?? > Where (website) should I look for ?? > It really depend on what you wanted to do. You would need probably at least 5 (PC) machines for MIPv4 There are several implementations I have some links to these implementations http://myhome.zaobao.com/home/m/mobione/mobile_links.htm One Router, One Home Agent One Foreign Agent One Mobile Node One Correspondent Node. Hence Router --------- Correspondent Node | -------------------------------- | | Home Agent Foreign Agent | | Mobile Node ------------->> Cheers Chern Nam Yap MIEEE, MSc(Res), BSc(Hons) Research Associate Center for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield F132 Mappin Building Mappin Street Sheffield S1 3JD United Kingdom Tel:+44 (0) 114-222-5182 Mobile:+ 44(0) 7712804892 Web: www.mobile1.net E-mail: cny@ieee.org > > Please give me suggestions, any is highly appreciated. > > Many thanks in advance ! > > Regards > > Nam From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 13:24:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11367 for ; Thu, 14 Dec 2000 13:24:48 -0500 (EST) Received: from standards (47.234.32.16:3811) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2D1B@standards.nortelnetworks.com>; Thu, 14 Dec 2000 13:03:48 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13290 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 13:03:48 -0500 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2D19@standards.nortelnetworks.com>; Thu, 14 Dec 2000 13:03:45 -0500 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eBEILj414290; Thu, 14 Dec 2000 19:21:45 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA10054; Thu, 14 Dec 2000 19:21:44 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA85554; Thu, 14 Dec 2000 19:23:09 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Approved-By: Francis.Dupont@ENST-BRETAGNE.FR Message-ID: <200012141823.TAA85554@givry.rennes.enst-bretagne.fr> Date: Thu, 14 Dec 2000 19:23:09 +0100 Reply-To: Francis Dupont Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: FROM field duplicated. Last occurrence was retained. From: Francis Dupont Subject: [MOBILE-IP] mobile IPv6 and IPsec ESP tunnels X-To: Richard Draves To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I'd like to write ASAP (id-editor should accept new I-D since yesterday?) a draft explaining how to use mobile IPv6 (and other mobility signaling) for IPsec ESP tunnels, ie. how to move one end of a bidirectional tunnel using ESP (a very common usage of IPsec). Richard, I should need your help for wording, this document will be for IPv6, mobile and IPsec communities which are not known for their colaboration (:-). Regards Francis.Dupont@enst-bretagne.fr PS: the raw idea is if you already have an ESP tunnel then mobility can be supported without any new overhead (you need typically 3 addresses and you can use 4). The issue is about the signaling, ie. how to update the address of one end (outer source or destination) after a movement. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 13:49:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14289 for ; Thu, 14 Dec 2000 13:49:02 -0500 (EST) Received: from standards (47.234.32.16:3029) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2D84@standards.nortelnetworks.com>; Thu, 14 Dec 2000 13:29:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13433 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 13:29:09 -0500 Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2D82@standards.nortelnetworks.com>; Thu, 14 Dec 2000 13:29:09 -0500 Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 14 Dec 2000 10:43:52 -0800 (Pacific Standard Time) Received: by inet-imc-03.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Thu, 14 Dec 2000 10:42:44 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Approved-By: Richard Draves Message-ID: <7695E2F6903F7A41961F8CF888D87EA801719956@red-msg-06.redmond.corp.microsoft.com> Date: Thu, 14 Dec 2000 10:42:38 -0800 Reply-To: Richard Draves Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Richard Draves Subject: [MOBILE-IP] authorization to issue a Binding Update for a Home Address X-To: Dave Johnson , "charliep@iprg.nokia.com" X-cc: Francis Dupont , Roberts Philip-qa3445 , Mohan Parthasarathy , "raj.patil@nokia.com" , "oran@cisco.com" , "jis@mit.edu" , William Dixon , Brian Zill , tytso@mit.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I'd like to suggest some text for one issue in draft-ietf-mobileip-ipv6-13.txt, which is the mobile node's authorization to issue a Binding Update for a Home Address. I think a new sentence or two in section 4.4 can make this more explicit. The new text requires authorization to use a Home Address, but it doesn't go into detail about what kind of certificate or other infrastructure might meaningfully provide this authorization. 4.4. IPsec Requirements for New Destination Options Any packet that includes a Binding Update or Binding Acknowledgement option MUST be protected by IPsec [13] to guard against malicious Binding Updates or Acknowledgements. Specifically, any packet that includes a Binding Update or Binding Acknowledgement option MUST utilize IPsec sender authentication, data integrity protection, and replay protection. *New:* The security association protecting a Binding Update MUST explictly authorize the mobile node to use the affected Home Address. Simply authenticating the mobile node to the correspondent node is not sufficient. Mobile IPv6 requires that this protection covering a Binding Update or Binding Acknowledgement MUST be provided by use of AH [11]. If another Security Association applied to the packet for other reasons requires use of ESP [12], for example to encrypt the transport layer data carried in the packet, this use of ESP is not sufficient to satisfy the authentication requirements of Mobile IPv6; instead, the packet MUST use both AH and ESP. Use of ESP for protecting the Binding Update or Binding Acknowledgement is not currently defined in this document, since ESP does not protect the portion of the packet above the ESP header itself [12]. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 13:56:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15819 for ; Thu, 14 Dec 2000 13:56:23 -0500 (EST) Received: from standards (47.234.32.16:3029) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2DB7@standards.nortelnetworks.com>; Thu, 14 Dec 2000 13:34:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13501 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 13:34:17 -0500 Received: from cs.rice.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2DB5@standards.nortelnetworks.com>; Thu, 14 Dec 2000 13:34:17 -0500 Received: from localhost (dbj@localhost) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id MAA09093; Thu, 14 Dec 2000 12:52:17 -0600 (CST) Approved-By: dbj@CS.RICE.EDU Message-ID: <9092.976819936@cs.rice.edu> Date: Thu, 14 Dec 2000 12:52:16 -0600 Reply-To: Dave Johnson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Dave Johnson Subject: Re: [MOBILE-IP] authorization to issue a Binding Update for a Home Address X-To: Richard Draves X-cc: "charliep@iprg.nokia.com" , Francis Dupont , Roberts Philip-qa3445 , Mohan Parthasarathy , "raj.patil@nokia.com" , "oran@cisco.com" , "jis@mit.edu" , William Dixon , Brian Zill , tytso@mit.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of "Thu, 14 Dec 2000 10:42:38 PST" <7695E2F6903F7A41961F8CF888D87EA801719956@red-msg-06.redmond.corp.microsoft.com> Rich, Thanks very much for the text. I think something like this certainly should (MUST? :-) be added. I would reword it slightly, though, as follows: However, simply authenticating the mobile node to the correspondent node is not sufficient; the security association protecting a Binding Update MUST explictly authorize the mobile node to use the affected Home Address. Dave >I'd like to suggest some text for one issue in >draft-ietf-mobileip-ipv6-13.txt, which is the mobile node's authorization to >issue a Binding Update for a Home Address. > >I think a new sentence or two in section 4.4 can make this more explicit. >The new text requires authorization to use a Home Address, but it doesn't go >into detail about what kind of certificate or other infrastructure might >meaningfully provide this authorization. > > >4.4. IPsec Requirements for New Destination Options > > Any packet that includes a Binding Update or Binding Acknowledgement > option MUST be protected by IPsec [13] to guard against malicious > Binding Updates or Acknowledgements. Specifically, any packet that > includes a Binding Update or Binding Acknowledgement option MUST > utilize IPsec sender authentication, data integrity protection, and > replay protection. *New:* The security association protecting a > Binding Update MUST explictly authorize the mobile node to use the >affected > Home Address. Simply authenticating the mobile node to the correspondent > node is not sufficient. > > Mobile IPv6 requires that this protection covering a Binding Update > or Binding Acknowledgement MUST be provided by use of AH [11]. If > another Security Association applied to the packet for other reasons > requires use of ESP [12], for example to encrypt the transport layer > data carried in the packet, this use of ESP is not sufficient to > satisfy the authentication requirements of Mobile IPv6; instead, > the packet MUST use both AH and ESP. Use of ESP for protecting the > Binding Update or Binding Acknowledgement is not currently defined in > this document, since ESP does not protect the portion of the packet > above the ESP header itself [12]. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 15:06:06 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01870 for ; Thu, 14 Dec 2000 15:06:06 -0500 (EST) Received: from standards (47.234.32.16:3941) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2E51@standards.nortelnetworks.com>; Thu, 14 Dec 2000 14:46:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13705 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 14:46:09 -0500 Received: from web1505.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2E4F@standards.nortelnetworks.com>; Thu, 14 Dec 2000 14:46:09 -0500 Received: (qmail 14794 invoked by uid 60001); 14 Dec 2000 20:04:12 -0000 Received: from [47.82.25.189] by web1505.mail.yahoo.com; Thu, 14 Dec 2000 12:04:12 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Approved-By: Praveen Muley Message-ID: <20001214200412.14793.qmail@web1505.mail.yahoo.com> Date: Thu, 14 Dec 2000 12:04:12 -0800 Reply-To: Praveen Muley Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Praveen Muley Subject: [MOBILE-IP] mobileip/mpls draft To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, Will appreciate if someone could give me pointer to the mobileip-mpls draft. Thanks, Praveen __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 15:46:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11806 for ; Thu, 14 Dec 2000 15:46:07 -0500 (EST) Received: from standards (47.234.32.16:2071) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2EB1@standards.nortelnetworks.com>; Thu, 14 Dec 2000 15:26:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13835 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 15:26:20 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2EAF@standards.nortelnetworks.com>; Thu, 14 Dec 2000 15:26:20 -0500 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA20915 for ; Thu, 14 Dec 2000 12:44:22 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA20266 for ; Thu, 14 Dec 2000 12:44:21 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id MAA08922 for ; Thu, 14 Dec 2000 12:44:14 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Approved-By: James Kempf Message-ID: <200012142044.MAA08922@nasnfs.eng.sun.com> Date: Thu, 14 Dec 2000 12:54:47 -0800 Reply-To: James.Kempf@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: [MOBILE-IP] Architectural v.s. Incremental Lession for Fast Handoff Discussion To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit For those of you who were at Randy Bush's talk on Wed. nite, one of the important points I took away is that DNS is in the mess it is in because the working group did not exercise enough design control. They chose incremental update as opposed to architectural update. I think there is a lession here for the fast handoff discussion. In particular, the two proposals for IPv4 represent the two choices. The proactive proposal essentially takes the architectural approach. It is saying that the current mobile IPv4 architecture needs modification in order to adequately support fast handoff. The Heshim and Karim proposal (I'll not call it "fast handoff" because that is confusing, both proposals support fast handoff) takes the incremental approach. As the authors have stated time and again, their proposal is an incremental update to the existing mobile IP architecture. If we merge the proposals, I wonder if, two years from now, one of our working group chairs won't be up on stage at the plenium giving exactly the same presentation as Randy did but for mobile IP. I'd therefore like to ask the working group to reconsider its hum for merging. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 15:54:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13665 for ; Thu, 14 Dec 2000 15:54:06 -0500 (EST) Received: from standards (47.234.32.16:2071) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2EFE@standards.nortelnetworks.com>; Thu, 14 Dec 2000 15:34:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13939 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 15:34:21 -0500 Received: from thalia.fm.intel.com (132.233.247.11:2384) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2EFC@standards.nortelnetworks.com>; Thu, 14 Dec 2000 15:34:21 -0500 Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id UAA19517; Thu, 14 Dec 2000 20:53:42 GMT Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 14 Dec 2000 20:52:22 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Dec 2000 12:52:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Approved-By: "Iyer, Prakash" Message-ID: <4148FEAAD879D311AC5700A0C969E890049A2624@orsmsx35.jf.intel.com> Date: Thu, 14 Dec 2000 12:52:12 -0800 Reply-To: "Iyer, Prakash" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Iyer, Prakash" Subject: Re: [MOBILE-IP] mobileip/mpls draft X-To: Praveen Muley To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM draft-zhong-mobile-ip-mpls-01.txt -----Original Message----- From: Praveen Muley [mailto:p_muley@yahoo.com] Sent: Thursday, December 14, 2000 12:04 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] mobileip/mpls draft Hi, Will appreciate if someone could give me pointer to the mobileip-mpls draft. Thanks, Praveen __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 16:00:50 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15091 for ; Thu, 14 Dec 2000 16:00:50 -0500 (EST) Received: from standards (47.234.32.16:2071) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2F47@standards.nortelnetworks.com>; Thu, 14 Dec 2000 15:40:44 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14039 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 15:40:44 -0500 Received: from mailhub1.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2F45@standards.nortelnetworks.com>; Thu, 14 Dec 2000 15:40:44 -0500 Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.16 #1) id 146fSf-0006m7-00; Thu, 14 Dec 2000 20:58:45 +0000 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 14 Dec 00 20:58:45 +0000 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 14 Dec 00 20:58:36 +0000 Received: from Mobile1 (143.167.59.139) by ridingwood.shef.ac.uk (Mercury 1.48); 14 Dec 00 20:58:28 +0000 References: <20001214200412.14793.qmail@web1505.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Approved-By: cnyap Message-ID: <004d01c06610$2f957dd0$923ba78f@Mobile1> Date: Thu, 14 Dec 2000 20:55:26 -0000 Reply-To: cnyap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cnyap Subject: Re: [MOBILE-IP] mobileip/mpls draft X-To: Praveen Muley To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, follow this link http://mip.ee.nus.edu.sg/paper/draft-zhong-mobile-ip-mpls-00.txt Cheers Chern Nam Yap MIEEE, MSc(Res), BSc(Hons) Research Associate Center for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield F132 Mappin Building Mappin Street Sheffield S1 3JD United Kingdom Tel:+44 (0) 114-222-5182 Mobile:+ 44(0) 7712804892 Web: www.mobile1.net E-mail: cny@ieee.org ----- Original Message ----- From: "Praveen Muley" To: Sent: Thursday, December 14, 2000 8:04 PM Subject: [MOBILE-IP] mobileip/mpls draft > Hi, > Will appreciate if someone could give me pointer > to the mobileip-mpls draft. > > Thanks, > Praveen > > __________________________________________________ > Do You Yahoo!? > Yahoo! Shopping - Thousands of Stores. Millions of Products. > http://shopping.yahoo.com/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 16:09:09 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16841 for ; Thu, 14 Dec 2000 16:09:08 -0500 (EST) Received: from standards (47.234.32.16:2071) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2F93@standards.nortelnetworks.com>; Thu, 14 Dec 2000 15:49:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14143 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 15:49:11 -0500 Received: from artemis.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2F91@standards.nortelnetworks.com>; Thu, 14 Dec 2000 15:49:11 -0500 Received: from [143.167.1.9] (helo=mailhub1.shef.ac.uk) by artemis.shef.ac.uk with esmtp (Exim 3.16 #2) id 146fao-0004Va-00; Thu, 14 Dec 2000 21:07:10 +0000 Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.16 #1) id 146fao-0006pt-00; Thu, 14 Dec 2000 21:07:10 +0000 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 14 Dec 00 21:07:10 +0000 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 14 Dec 00 21:07:04 +0000 Received: from Mobile1 (143.167.59.139) by ridingwood.shef.ac.uk (Mercury 1.48); 14 Dec 00 21:07:02 +0000 References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01C06611.62013F60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Scanner: exiscan@artemis *146fao-0004Va-00* http://duncanthrax.net/exiscan/ Approved-By: cnyap Message-ID: <005701c06611$62214a80$923ba78f@Mobile1> Date: Thu, 14 Dec 2000 21:04:01 -0000 Reply-To: cnyap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cnyap Subject: Re: [MOBILE-IP] Can anyone give me an explanation? X-To: =?gb2312?B?sK3H9rG5?= To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0054_01C06611.62013F60 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Yes, the place that created it. http://comet.columbia.edu/cellularip/ There is a few link in my web page on mobile networking http://myhome.zaobao.com/home/m/mobione/index.htm I am not sure will that be any help,=20 may be you would like to take a look. Moreover, you might want to review the following draft as well. http://search.ietf.org/internet-drafts/draft-cnyap-iip-01.txt Cheers Chern Nam Yap MIEEE, MSc(Res), BSc(Hons) Research Associate Center for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield F132 Mappin Building Mappin Street Sheffield S1 3JD United Kingdom Tel:+44 (0) 114-222-5182 Mobile:+ 44(0) 7712804892 Web: www.mobile1.net E-mail: cny@ieee.org ----- Original Message -----=20 From: =B0=AD=C7=F6=B1=B9=20 To: cnyap=20 Sent: Thursday, December 14, 2000 7:05 PM Subject: RE: [MOBILE-IP] Can anyone give me an explanation? Hi, First of all, thank you for your clarification..... I am good at Mobile IP....but not much on Cellular IP. If you have any site relating to C-IP like W-IP, please let me know.... Great many thanks!! -----Original Message----- From: IP Routing for Wireless/Mobile Hosts (mobile-ip) = [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of cnyap Sent: Thursday, December 14, 2000 9:11 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Can anyone give me an explanation? Hi Yes.=20 Cellular IP is an architecture built on top of Mobile IP. It can work without Mobile IP, but within the specific domain. Currently there is no formal definiton for Wireless IP. It just mean any IP application runs over Wireless Access = Technology. The most formal definition currently available is in the following = link. http://es53060.easystreet.com/wirelessipcase.htm Cheers Chern Nam Yap MIEEE, MSc(Res), BSc(Hons) Research Associate Center for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield F132 Mappin Building Mappin Street Sheffield S1 3JD United Kingdom Tel:+44 (0) 114-222-5182 Mobile:+ 44(0) 7712804892 Web: www.mobile1.net E-mail: cny@ieee.org ----- Original Message -----=20 From: Xingang Liang=20 To: MOBILE-IP@standards.nortelnetworks.com=20 Sent: Thursday, December 14, 2000 1:43 AM Subject: [MOBILE-IP] Can anyone give me an explanation? Dear every one: I am working on the IP issues in 3GPP,but now I have a = question to ask:=20 What is the difference of "Cellular IP" and "Wireless IP"? In my opinion,I think that the former refers to the wholly = architecture from the mobile host to gateway,while the latter refers to = IP application between BTS and wireless phone(or NodeB and wp),that is = the air interface will use the wireless ip. I don't know whether what I think is right,can anyone give me = some adjustment or advice,thanks at all!!! Best Regards Xingang Liang Standard Department of Mobile Center China Academy of Telecommunication Technology No.40,Xueyuan Road,Haidian District Beijing,China 100083 TEL:+8610-62304422EXT225 FAX:+8610-62303127 E_MAIL:liangxg@catt.ac.cn ------=_NextPart_000_0054_01C06611.62013F60 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi
 
Yes, the place that created it.
http://comet.columbia.edu/= cellularip/
 
There is a few link in my web page on mobile=20 networking
http://myhome.= zaobao.com/home/m/mobione/index.htm
I am not sure will that be any help, =
may be you would like to take a = look.
 
Moreover, you might want to review
the following draft as well.
ht= tp://search.ietf.org/internet-drafts/draft-cnyap-iip-01.txt
 
Cheers
Chern Nam Yap
MIEEE, MSc(Res), = BSc(Hons)
Research=20 Associate
Center for Mobile Communication Research
Department of=20 Electronic and Electrical Engineering
University of Sheffield
F132 = Mappin=20 Building
Mappin Street
Sheffield S1 3JD
United = Kingdom
Tel:+44 (0)=20 114-222-5182
Mobile:+ 44(0) 7712804892
Web: www.mobile1.net
E-mail: cny@ieee.org
 
 
 
 
 
 
----- Original Message -----
From:=20 =B0=AD=C7=F6=B1=B9=20
To: cnyap
Sent: Thursday, December 14, = 2000 7:05=20 PM
Subject: RE: [MOBILE-IP] Can = anyone give=20 me an explanation?

Hi,
First of all, thank you for your = clarification.....
 
I = am good at=20 Mobile IP....but not much on Cellular IP.
If = you have=20 any site relating to C-IP like W-IP,
please let me=20 know....
 
Great many=20 thanks!!
-----Original Message-----
From: IP Routing = for=20 Wireless/Mobile Hosts (mobile-ip)=20 [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of=20 cnyap
Sent: Thursday, December 14, 2000 9:11 = PM
To:=20 MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: = [MOBILE-IP]=20 Can anyone give me an explanation?

Hi
 
Yes.
Cellular IP is an architecture built on = top of=20 Mobile IP.
It can work without Mobile IP, but within = the specific=20 domain.
 
Currently there is no formal definiton = for=20 Wireless IP.
It just mean any IP application runs over = Wireless=20 Access Technology.
The most formal definition currently = available is in=20 the following link.
http://es53060.= easystreet.com/wirelessipcase.htm
 
Cheers
Chern Nam Yap
MIEEE, MSc(Res),=20 BSc(Hons)
Research Associate
Center for Mobile Communication=20 Research
Department of Electronic and Electrical=20 Engineering
University of Sheffield
F132 Mappin = Building
Mappin=20 Street
Sheffield S1 3JD
United Kingdom
Tel:+44 (0)=20 114-222-5182
Mobile:+ 44(0) 7712804892
Web: www.mobile1.net
E-mail: cny@ieee.org
 
 
 
 
 
----- Original Message ----- =
From:=20 Xingang=20 Liang
To: MOBILE-IP@standard= s.nortelnetworks.com=20
Sent: Thursday, December = 14, 2000=20 1:43 AM
Subject: [MOBILE-IP] Can = anyone give=20 me an explanation?

Dear every one:
     I am working on the IP issues in = 3GPP,but=20 now I have a question to ask:
     What is the difference of "Cellular = IP" and=20 "Wireless IP"?
     In my opinion,I think that the = former refers=20 to the wholly architecture from the mobile host to gateway,while = the=20 latter refers to IP application between BTS and wireless phone(or = NodeB=20 and wp),that is the air interface will use the wireless ip.
     I don't know whether what I think is = right,can anyone give me some adjustment or advice,thanks at = all!!!
 
Best Regards
Xingang Liang
Standard Department of Mobile = Center
China=20 Academy of Telecommunication Technology
No.40,Xueyuan = Road,Haidian=20 District
Beijing,China=20 100083
TEL:+8610-62304422EXT225
FAX:+8610-62303127
E_MAIL:liangxg@catt.ac.cn
------=_NextPart_000_0054_01C06611.62013F60-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 16:28:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22306 for ; Thu, 14 Dec 2000 16:28:14 -0500 (EST) Received: from standards (47.234.32.16:2071) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2FE8@standards.nortelnetworks.com>; Thu, 14 Dec 2000 16:08:29 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14259 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 16:08:29 -0500 Received: from mailhub1.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2FE6@standards.nortelnetworks.com>; Thu, 14 Dec 2000 16:08:28 -0500 Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.16 #1) id 146ftS-00070G-00; Thu, 14 Dec 2000 21:26:26 +0000 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 14 Dec 00 21:26:26 +0000 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 14 Dec 00 21:26:25 +0000 Received: from Mobile1 (143.167.59.139) by ridingwood.shef.ac.uk (Mercury 1.48); 14 Dec 00 21:26:18 +0000 References: <4148FEAAD879D311AC5700A0C969E890049A2624@orsmsx35.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Approved-By: cnyap Message-ID: <00f801c06614$1310c8a0$923ba78f@Mobile1> Date: Thu, 14 Dec 2000 21:23:17 -0000 Reply-To: cnyap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cnyap Subject: Re: [MOBILE-IP] mobileip/mpls draft X-To: "Iyer, Prakash" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi http://community.roxen.com/developers/idocs/drafts/draft-zhong-mobile-ip-mpl s-01.html Chern Nam Yap MIEEE, MSc(Res), BSc(Hons) Research Associate Center for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield F132 Mappin Building Mappin Street Sheffield S1 3JD United Kingdom Tel:+44 (0) 114-222-5182 Mobile:+ 44(0) 7712804892 Web: www.mobile1.net E-mail: cny@ieee.org ----- Original Message ----- From: "Iyer, Prakash" To: Sent: Thursday, December 14, 2000 8:52 PM Subject: Re: [MOBILE-IP] mobileip/mpls draft > draft-zhong-mobile-ip-mpls-01.txt > > -----Original Message----- > From: Praveen Muley [mailto:p_muley@yahoo.com] > Sent: Thursday, December 14, 2000 12:04 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] mobileip/mpls draft > > > Hi, > Will appreciate if someone could give me pointer > to the mobileip-mpls draft. > > Thanks, > Praveen > > __________________________________________________ > Do You Yahoo!? > Yahoo! Shopping - Thousands of Stores. Millions of Products. > http://shopping.yahoo.com/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 16:34:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24343 for ; Thu, 14 Dec 2000 16:34:41 -0500 (EST) Received: from standards (47.234.32.16:2071) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3028@standards.nortelnetworks.com>; Thu, 14 Dec 2000 16:13:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14347 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 16:13:53 -0500 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3026@standards.nortelnetworks.com>; Thu, 14 Dec 2000 16:13:52 -0500 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eBELVi419269; Thu, 14 Dec 2000 22:31:44 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id WAA16471; Thu, 14 Dec 2000 22:31:43 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id WAA86314; Thu, 14 Dec 2000 22:33:07 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Approved-By: Francis.Dupont@ENST-BRETAGNE.FR Message-ID: <200012142133.WAA86314@givry.rennes.enst-bretagne.fr> Date: Thu, 14 Dec 2000 22:33:07 +0100 Reply-To: Francis Dupont Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] authorization to issue a Binding Update for a Home Address X-To: Richard Draves X-cc: Dave Johnson , "charliep@iprg.nokia.com" , Roberts Philip-qa3445 , Mohan Parthasarathy , "raj.patil@nokia.com" , "oran@cisco.com" , "jis@mit.edu" , William Dixon , Brian Zill , tytso@mit.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Thu, 14 Dec 2000 10:42:38 PST. <7695E2F6903F7A41961F8CF888D87EA801719956@red-msg-06.redmond.corp.microsoft.com> In your previous mail you wrote: I'd like to suggest some text for one issue in draft-ietf-mobileip-ipv6-13.txt, which is the mobile node's authorization to issue a Binding Update for a Home Address. => I agree. I have talked with Christian Huitema about this and the key (missing) word is authorization. This is what I adviced to Thierry Ernst about mobile router draft... I think a new sentence or two in section 4.4 can make this more explicit. The new text requires authorization to use a Home Address, but it doesn't go into detail about what kind of certificate or other infrastructure might meaningfully provide this authorization. => yes, the specifications should not mandate a way to provide authorization. The best which can be done is to give some hints (like using certificate policies). Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 16:49:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27265 for ; Thu, 14 Dec 2000 16:49:25 -0500 (EST) Received: from standards (47.234.32.16:2071) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3084@standards.nortelnetworks.com>; Thu, 14 Dec 2000 16:29:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14473 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 16:29:37 -0500 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3082@standards.nortelnetworks.com>; Thu, 14 Dec 2000 16:29:36 -0500 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eBELlJ419246; Thu, 14 Dec 2000 22:47:20 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id WAA16941; Thu, 14 Dec 2000 22:47:19 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id WAA86388; Thu, 14 Dec 2000 22:48:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Approved-By: Francis.Dupont@ENST-BRETAGNE.FR Message-ID: <200012142148.WAA86388@givry.rennes.enst-bretagne.fr> Date: Thu, 14 Dec 2000 22:48:44 +0100 Reply-To: Francis Dupont Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] authorization to issue a Binding Update for a Home Address X-To: Dave Johnson X-cc: Richard Draves , "charliep@iprg.nokia.com" , Roberts Philip-qa3445 , Mohan Parthasarathy , "raj.patil@nokia.com" , "oran@cisco.com" , "jis@mit.edu" , William Dixon , Brian Zill , tytso@mit.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Thu, 14 Dec 2000 12:52:16 CST. <9092.976819936@cs.rice.edu> In your previous mail you wrote: I would reword it slightly, though, as follows: However, simply authenticating the mobile node to the correspondent node is not sufficient; the security association protecting a Binding Update MUST explictly authorize the mobile node to use the affected Home Address. => in fact the security association doesn't authorize something, its setup (ie. IKE) MUST verify the authorization... I propose (Richard should find a very good wording to express this) to add a statement/paragraph at the end of IKE considerations explaining the policy associated to the identity verified by the authentication function of the phase one of IKE MUST permit the use of this Home Address (both for BUs and the setup of SAs in phase two, BTW RFC 2409 explains a proxy Identity payload MUST be accepted only if the policy authorizes it: (whole paragraph from RFC 2409) The identities of the SAs negotiated in Quick Mode are implicitly assumed to be the IP addresses of the ISAKMP peers, without any implied constraints on the protocol or port numbers allowed, unless client identifiers are specified in Quick Mode. If ISAKMP is acting as a client negotiator on behalf of another party, the identities of the parties MUST be passed as IDci and then IDcr. Local policy will dictate whether the proposals are acceptable for the identities specified. If the client identities are not acceptable to the Quick Mode responder (due to policy or other reasons), a Notify payload with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent. Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 18:29:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13458 for ; Thu, 14 Dec 2000 18:29:09 -0500 (EST) Received: from standards (47.234.32.16:3697) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3125@standards.nortelnetworks.com>; Thu, 14 Dec 2000 18:09:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14688 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 18:09:24 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3123@standards.nortelnetworks.com>; Thu, 14 Dec 2000 18:09:23 -0500 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA19144; Thu, 14 Dec 2000 15:27:24 -0800 (PST) Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA13447; Thu, 14 Dec 2000 15:27:23 -0800 (PST) Received: (from mohanp@localhost) by locked.eng.sun.com (8.10.1+Sun/8.10.1) id eBENQDJ11095; Thu, 14 Dec 2000 15:26:13 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Approved-By: Mohan Parthasarathy Message-ID: <200012142326.eBENQDJ11095@locked.eng.sun.com> Date: Thu, 14 Dec 2000 15:26:13 -0800 Reply-To: Mohan Parthasarathy Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohan Parthasarathy Subject: Re: [MOBILE-IP] authorization to issue a Binding Update for a Home Address X-To: Richard Draves X-cc: Dave Johnson , "charliep@iprg.nokia.com" , Francis Dupont , Roberts Philip-qa3445 , "raj.patil@nokia.com" , "oran@cisco.com" , "jis@mit.edu" , William Dixon , Brian Zill , tytso@mit.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA801719956@red-msg-06.redmond.corp.microsoft.com> from Richard Draves at "Dec 14, 2000 10:42:38 am" Content-Transfer-Encoding: 7bit I suggest we should have an informational draft on mobility and IPsec interactions. I am ready to start one and would happy to join with anyone who is interested in this. This one sentence does not seem sufficient to me after yesterdays discussion. But if agree on a separate informational draft, we can put the details there. I would assume that the potential problem of using a wrong identity in phase II SA should be explained also. This will make sure that no new issues will be raised in the future hopefully. -mohan > I'd like to suggest some text for one issue in > draft-ietf-mobileip-ipv6-13.txt, which is the mobile node's authorization to > issue a Binding Update for a Home Address. > > I think a new sentence or two in section 4.4 can make this more explicit. > The new text requires authorization to use a Home Address, but it doesn't go > into detail about what kind of certificate or other infrastructure might > meaningfully provide this authorization. > > > 4.4. IPsec Requirements for New Destination Options > > Any packet that includes a Binding Update or Binding Acknowledgement > option MUST be protected by IPsec [13] to guard against malicious > Binding Updates or Acknowledgements. Specifically, any packet that > includes a Binding Update or Binding Acknowledgement option MUST > utilize IPsec sender authentication, data integrity protection, and > replay protection. *New:* The security association protecting a > Binding Update MUST explictly authorize the mobile node to use the > affected > Home Address. Simply authenticating the mobile node to the correspondent > node is not sufficient. > > Mobile IPv6 requires that this protection covering a Binding Update > or Binding Acknowledgement MUST be provided by use of AH [11]. If > another Security Association applied to the packet for other reasons > requires use of ESP [12], for example to encrypt the transport layer > data carried in the packet, this use of ESP is not sufficient to > satisfy the authentication requirements of Mobile IPv6; instead, > the packet MUST use both AH and ESP. Use of ESP for protecting the > Binding Update or Binding Acknowledgement is not currently defined in > this document, since ESP does not protect the portion of the packet > above the ESP header itself [12]. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 18:35:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15620 for ; Thu, 14 Dec 2000 18:35:52 -0500 (EST) Received: from standards (47.234.32.16:3697) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3165@standards.nortelnetworks.com>; Thu, 14 Dec 2000 18:14:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14772 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 18:14:02 -0500 Received: from irvmail2.bdi.gte.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3163@standards.nortelnetworks.com>; Thu, 14 Dec 2000 18:14:02 -0500 Received: from smtptpa.interwan.gte.com ([138.83.66.45]) by irvmail2.bdi.gte.com (8.9.3/8.9.3) with ESMTP id SAA19617 for ; Thu, 14 Dec 2000 18:32:05 -0500 (EST) Received: from smtptpa.interwan.gte.com (localhost [127.0.0.1]) by smtptpa.interwan.gte.com (8.9.3/8.9.3) with ESMTP id SAA13155 for ; Thu, 14 Dec 2000 18:32:04 -0500 (EST) Received: from imr01.bellatlantic.com (bagate.verizon.com [141.152.156.12]) by smtptpa.interwan.gte.com (8.9.3/8.9.3) with ESMTP id SAA13144 for ; Thu, 14 Dec 2000 18:32:04 -0500 (EST) Received: from fhsmtp03.bell-atl.com (is051952.bellatlantic.com [151.203.130.8]) by imr01.bellatlantic.com (8.8.8/8.8.5) with ESMTP id SAA23536 for ; Thu, 14 Dec 2000 18:32:03 -0500 (EST) X-MIMETrack: Serialize by Router on FHSMTP03/SMTP/Bell-Atl(Release 5.0.5 |September 22, 2000) at 12/14/2000 06:32:03 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Approved-By: james.j.lorman@VERIZON.COM Message-ID: Date: Thu, 14 Dec 2000 18:31:58 -0500 Reply-To: james.j.lorman@verizon.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jim Lorman Subject: [MOBILE-IP] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I will be out of the office from 12/14/2000 until 12/17/2000. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 18:40:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17315 for ; Thu, 14 Dec 2000 18:40:45 -0500 (EST) Received: from standards (47.234.32.16:3697) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC31B5@standards.nortelnetworks.com>; Thu, 14 Dec 2000 18:18:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14878 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 18:18:50 -0500 Received: from patan.sun.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC31B2@standards.nortelnetworks.com>; Thu, 14 Dec 2000 18:18:49 -0500 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13301; Thu, 14 Dec 2000 15:36:47 -0800 (PST) Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA16196; Thu, 14 Dec 2000 15:36:45 -0800 (PST) Received: (from mohanp@localhost) by locked.eng.sun.com (8.10.1+Sun/8.10.1) id eBENZZ011101; Thu, 14 Dec 2000 15:35:35 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Approved-By: Mohan Parthasarathy Message-ID: <200012142335.eBENZZ011101@locked.eng.sun.com> Date: Thu, 14 Dec 2000 15:35:35 -0800 Reply-To: Mohan Parthasarathy Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohan Parthasarathy Subject: Re: [MOBILE-IP] authorization to issue a Binding Update for a Home Address X-To: Francis Dupont X-cc: Dave Johnson , Richard Draves , "charliep@iprg.nokia.com" , Roberts Philip-qa3445 , "raj.patil@nokia.com" , "oran@cisco.com" , "jis@mit.edu" , William Dixon , Brian Zill , tytso@mit.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200012142148.WAA86388@givry.rennes.enst-bretagne.fr> from Francis Dupont at "Dec 14, 2000 10:48:44 pm" Content-Transfer-Encoding: 7bit > In your previous mail you wrote: > > I would reword it slightly, though, as follows: > > However, simply authenticating the mobile node to the correspondent > node is not sufficient; the security association protecting a Binding > Update MUST explictly authorize the mobile node to use the affected > Home Address. > > => in fact the security association doesn't authorize something, its setup > (ie. IKE) MUST verify the authorization... > I propose (Richard should find a very good wording to express this) to add > a statement/paragraph at the end of IKE considerations explaining the > policy associated to the identity verified by the authentication function > of the phase one of IKE MUST permit the use of this Home Address (both > for BUs and the setup of SAs in phase two, BTW RFC 2409 explains a proxy > Identity payload MUST be accepted only if the policy authorizes it: > (whole paragraph from RFC 2409) > Agreed. It will be good if we can say to the effect of : 1) Phase I SA should use certificate identities 2) Phase II SA should use client identifiers to specify the HOME address. This would establish a Phase II IPsec SA to use HOME address as the source selector. Other details about the potential problem of using somebody elses HOME address in Phase II can be specified in a separate document if it would help the implementors. I personally think it would help. -mohan > The identities of the SAs negotiated in Quick Mode are implicitly > assumed to be the IP addresses of the ISAKMP peers, without any > implied constraints on the protocol or port numbers allowed, unless > client identifiers are specified in Quick Mode. If ISAKMP is acting > as a client negotiator on behalf of another party, the identities of > the parties MUST be passed as IDci and then IDcr. Local policy will > dictate whether the proposals are acceptable for the identities > specified. If the client identities are not acceptable to the Quick > Mode responder (due to policy or other reasons), a Notify payload > with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent. > > Thanks > > Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 18:54:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21923 for ; Thu, 14 Dec 2000 18:54:22 -0500 (EST) Received: from standards (47.234.32.16:3697) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC321A@standards.nortelnetworks.com>; Thu, 14 Dec 2000 18:34:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15015 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 18:34:41 -0500 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3218@standards.nortelnetworks.com>; Thu, 14 Dec 2000 18:34:40 -0500 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eBENqL433059; Fri, 15 Dec 2000 00:52:22 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id AAA20759; Fri, 15 Dec 2000 00:52:21 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id AAA86942; Fri, 15 Dec 2000 00:53:46 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Approved-By: Francis.Dupont@ENST-BRETAGNE.FR Message-ID: <200012142353.AAA86942@givry.rennes.enst-bretagne.fr> Date: Fri, 15 Dec 2000 00:53:46 +0100 Reply-To: Francis Dupont Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] authorization to issue a Binding Update for a Home Address X-To: Richard Draves X-cc: Dave Johnson , "charliep@iprg.nokia.com" , Roberts Philip-qa3445 , Mohan Parthasarathy , "raj.patil@nokia.com" , "oran@cisco.com" , "jis@mit.edu" , William Dixon , Brian Zill , tytso@mit.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Thu, 14 Dec 2000 13:50:48 PST. <7695E2F6903F7A41961F8CF888D87EA80171999F@red-msg-06.redmond.corp.microsoft.com> In your previous mail you wrote: > => yes, the specifications should not mandate a way to > provide authorization. > The best which can be done is to give some hints (like using > certificate > policies). I agree on leaving this out of the draft, but it does need to be worked out before the route optimization aspect of Mobile IPv6 (which is really the point) can see any significant deployment. => I read this as an argument for a BCP. I agree but I don't know where to do it (IPsec, mobile IP, AAA, IPsra, IPSP, something else/new?) Thanks Francis.Dupont@enst-bretagne.fr PS: even the area is not clear (security, ops, routing)? From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 19:02:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24612 for ; Thu, 14 Dec 2000 19:02:45 -0500 (EST) Received: from standards (47.234.32.16:3697) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3276@standards.nortelnetworks.com>; Thu, 14 Dec 2000 18:42:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15141 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 18:42:55 -0500 Received: from mail5.microsoft.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3274@standards.nortelnetworks.com>; Thu, 14 Dec 2000 18:42:55 -0500 Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 14 Dec 2000 13:51:00 -0800 (Pacific Standard Time) Received: by inet-imc-05.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Thu, 14 Dec 2000 13:50:59 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Approved-By: Richard Draves Message-ID: <7695E2F6903F7A41961F8CF888D87EA80171999F@red-msg-06.redmond.corp.microsoft.com> Date: Thu, 14 Dec 2000 13:50:48 -0800 Reply-To: Richard Draves Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Richard Draves Subject: Re: [MOBILE-IP] authorization to issue a Binding Update for a Home Address X-To: Francis Dupont X-cc: Dave Johnson , "charliep@iprg.nokia.com" , Roberts Philip-qa3445 , Mohan Parthasarathy , "raj.patil@nokia.com" , "oran@cisco.com" , "jis@mit.edu" , William Dixon , Brian Zill , tytso@mit.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > I think a new sentence or two in section 4.4 can make this > more explicit. > The new text requires authorization to use a Home Address, > but it doesn't go > into detail about what kind of certificate or other > infrastructure might > meaningfully provide this authorization. > > => yes, the specifications should not mandate a way to > provide authorization. > The best which can be done is to give some hints (like using > certificate > policies). I agree on leaving this out of the draft, but it does need to be worked out before the route optimization aspect of Mobile IPv6 (which is really the point) can see any significant deployment. Rich From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 19:09:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26624 for ; Thu, 14 Dec 2000 19:09:17 -0500 (EST) Received: from standards (47.234.32.16:3697) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC32BB@standards.nortelnetworks.com>; Thu, 14 Dec 2000 18:47:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15233 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 18:47:41 -0500 Received: from audrey.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC32B9@standards.nortelnetworks.com>; Thu, 14 Dec 2000 18:47:41 -0500 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by audrey.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eBF055619686; Fri, 15 Dec 2000 01:05:05 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id BAA21072; Fri, 15 Dec 2000 01:03:44 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id BAA87023; Fri, 15 Dec 2000 01:05:09 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Approved-By: Francis.Dupont@ENST-BRETAGNE.FR Message-ID: <200012150005.BAA87023@givry.rennes.enst-bretagne.fr> Date: Fri, 15 Dec 2000 01:05:09 +0100 Reply-To: Francis Dupont Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] authorization to issue a Binding Update for a Home Address X-To: Mohan Parthasarathy X-cc: Dave Johnson , Richard Draves , "charliep@iprg.nokia.com" , Roberts Philip-qa3445 , "raj.patil@nokia.com" , "oran@cisco.com" , "jis@mit.edu" , William Dixon , Brian Zill , tytso@mit.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Thu, 14 Dec 2000 15:35:35 PST. <200012142335.eBENZZ011101@locked.eng.sun.com> In your previous mail you wrote: Agreed. It will be good if we can say to the effect of : 1) Phase I SA should use certificate identities => you mean name identifies (FQDN, user_FQDN (my favorite because it is compatible with NAI), ...) with authentication by signatures and X.509v3 certificates? This is the best (less worse :-) solution today IMHO. 2) Phase II SA should use client identifiers to specify the HOME address. This would establish a Phase II IPsec SA to use HOME address as the source selector. => address identity payload for the home address? Other details about the potential problem of using somebody elses HOME address in Phase II can be specified in a separate document if it would help the implementors. I personally think it would help. => this should not be necessary because the ID clearly specifies SAs MUST use the home address (a care-of address needs to rebuild SAs after each movement). I like the current text, only authorization should be added. Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 21:11:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04188 for ; Thu, 14 Dec 2000 21:11:52 -0500 (EST) Received: from standards (47.234.32.16:2442) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3392@standards.nortelnetworks.com>; Thu, 14 Dec 2000 20:52:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15530 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 20:52:05 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3390@standards.nortelnetworks.com>; Thu, 14 Dec 2000 20:52:05 -0500 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA04864; Thu, 14 Dec 2000 18:10:03 -0800 (PST) Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA09141; Thu, 14 Dec 2000 18:10:02 -0800 (PST) Received: (from mohanp@localhost) by locked.eng.sun.com (8.10.1+Sun/8.10.1) id eBF28qp11153; Thu, 14 Dec 2000 18:08:52 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Approved-By: Mohan Parthasarathy Message-ID: <200012150208.eBF28qp11153@locked.eng.sun.com> Date: Thu, 14 Dec 2000 18:08:52 -0800 Reply-To: Mohan Parthasarathy Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohan Parthasarathy Subject: Re: [MOBILE-IP] authorization to issue a Binding Update for a Home Address X-To: Francis Dupont X-cc: Dave Johnson , Richard Draves , "charliep@iprg.nokia.com" , Roberts Philip-qa3445 , "raj.patil@nokia.com" , "oran@cisco.com" , "jis@mit.edu" , William Dixon , Brian Zill , tytso@mit.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200012150005.BAA87023@givry.rennes.enst-bretagne.fr> from Francis Dupont at "Dec 15, 2000 01:05:09 am" Content-Transfer-Encoding: 7bit > In your previous mail you wrote: > > Agreed. It will be good if we can say to the effect of : > > 1) Phase I SA should use certificate identities > > => you mean name identifies (FQDN, user_FQDN (my favorite because > it is compatible with NAI), ...) with authentication by signatures > and X.509v3 certificates? This is the best (less worse :-) solution > today IMHO. > Agreed. > 2) Phase II SA should use client identifiers to specify the HOME address. > This would establish a Phase II IPsec SA to use HOME address as the > source selector. > > => address identity payload for the home address? > Yes. > Other details about the potential problem of using somebody elses HOME > address in Phase II can be specified in a separate document if it > would help the implementors. I personally think it would help. > > => this should not be necessary because the ID clearly specifies > SAs MUST use the home address (a care-of address needs to rebuild > SAs after each movement). > I like the current text, only authorization should be added. > But the question is how does one prevent the MN from using somebody else's home address during the phase II SA ? I agree that this is a difficult problem but it would be good to mention this somewhere. I really don't want to argue at this stage. But this is an important detail which should be recorded somewhere without which route optimization is questionable as was discussed yesterday. -mohan > Thanks > > Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 21:19:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06703 for ; Thu, 14 Dec 2000 21:19:33 -0500 (EST) Received: from standards (47.234.32.16:2442) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC33BD@standards.nortelnetworks.com>; Thu, 14 Dec 2000 20:55:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15583 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 20:55:11 -0500 Received: from ms.samsung.com (211.45.29.136:57719) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC33BB@standards.nortelnetworks.com>; Thu, 14 Dec 2000 20:55:10 -0500 Received: from keg ([203.241.48.20]) by ms.samsung.com (Netscape Messaging Server 4.15) with SMTP id G5L7FQ00.M2E for ; Fri, 15 Dec 2000 11:11:50 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Approved-By: Woo-June Kim Message-ID: <005f01c0663c$1bfcd800$88b2d5a5@keg.telecom.samsung.co.kr> Date: Fri, 15 Dec 2000 11:09:51 +0900 Reply-To: Woo-June Kim Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Woo-June Kim Subject: Re: [MOBILE-IP] Mobile IPv4 Challenge/Response Extensions To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA06703 Hi, Interesting point, I agree the wording is a bit unclear. Comments below... >Questions concerning the new RFC: >Section 3.2: >Concerning STALE_CHALLENGE, the language used suggests >that the Foreign Agent should keep all Challenge >extensions that the MN has previously used. Surely, >the FA can't be expected to store all of these values >for the lifetime of the Moblie's session. >If so, the memory requirement for supports the FAC go >off the chart for any reasonable amount of >subscribers. STALE_CHALLENGE should be sent if "it is a previously used" one. I thought that this meant that the mobile had previously sent a correct RRQ with MN_AAA, the PDSN had replied and sent back a RRP. The fact that the mobile again uses the same challenge value would seem to point to the possibility that the mobile had failed to received the RRP and was retransmitting... (A replay attack should be caught by the ID field) >If not, what then is the functional difference between >STALE_CHALLENGE and UNKNOWN_CHALLENGE? Both are >reported as errors, but I'm unsure of the handling by >the MN for these two errors. Seems there is a hole in section 3.1. It states what should be done by the MN if it receives an UNKNOWN_CHALLENGE, but nothing about STALE_CHALLENGE. (Based on my thinking above, it seems the mobile should just drop it.) >Also, does the FA keep the last advertised Challenge >as an "always acceptable" value, or once the FA sends >a RRP with a valid new Challenge, the AA becomes >stale? > According to Section 3.2 and 9, the FA should keep as acceptable challenge values the last challenge sent out in a successful RRP, or the last CHALLENGE_WINDOW number of Agent Advertisements. Don't think "Staleness" applies here, if the challenge is not among these, the UNKNOWN_CHALLENGE should be sent. cheers Woojune Kim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 14 23:53:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26397 for ; Thu, 14 Dec 2000 23:53:09 -0500 (EST) Received: from standards (47.234.32.16:3832) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3516@standards.nortelnetworks.com>; Thu, 14 Dec 2000 23:33:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16034 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 23:33:18 -0500 Received: from inet-tsb.toshiba.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3514@standards.nortelnetworks.com>; Thu, 14 Dec 2000 23:33:16 -0500 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id NAA05640 for ; Fri, 15 Dec 2000 13:51:14 +0900 (JST) Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id NAA03599; Fri, 15 Dec 2000 13:51:13 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id NAA27178; Fri, 15 Dec 2000 13:51:07 +0900 (JST) Received: from localhost (kddlos0103.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0G5L005X7ET063@tsbpo1.po.toshiba.co.jp> for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Dec 2000 13:51:03 +0900 (JST) MIME-version: 1.0 X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Capitol Reef) Content-type: Text/Plain; charset=us-ascii Content-transfer-encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 36 Approved-By: Yoshihiro Ohba Message-ID: <20001214225051A.yohba@tari.toshiba.com> Date: Thu, 14 Dec 2000 22:50:51 -0500 Reply-To: Yoshihiro Ohba Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yoshihiro Ohba Subject: [MOBILE-IP] comment on IKE in Mobile IPv6 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, I have a comment regarding IKE in MIPv6 environment. In section 10.2 of the MIPv6 draft it is stated that: -------------------------------------------------------------------- - The mobile node MUST use its care-of address as the Source Address of all packets it sends as part of the key management protocol (without use of Mobile IP for these packets, as suggested in Section 10.1). - In addition, for all security associations bound to the mobile node's home address, the mobile node MUST include an ISAKMP Identification Payload [14] in the IKE exchange, giving the mobile node's home address as the initiator of the Security Association [22]. -------------------------------------------------------------------- However, consider the case in which a mobile node is performing IKE with a correspondent node which is also a mobile node. If care-of address is used as the Source Address for packets carrying IKE messages without using Mobile IP, the packets may not be delivered if both nodes change their care-of addresses at the same time. So I think at least Mobile IP should be used for IKE between a mobile node and a correspondent node (and the mobile node and correspondent node should not perform IKE before the mobile node is successfully registered to its Home Agent.) Or am I missing something? Yoshihiro Ohba Toshiba America Research, Inc. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 15 00:49:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19886 for ; Fri, 15 Dec 2000 00:49:48 -0500 (EST) Received: from standards (47.234.32.16:2079) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC357D@standards.nortelnetworks.com>; Fri, 15 Dec 2000 0:30:02 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16168 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Dec 2000 00:30:01 -0500 Received: from cs.rice.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC357B@standards.nortelnetworks.com>; Fri, 15 Dec 2000 0:30:01 -0500 Received: from localhost (dbj@localhost) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id XAA07864; Thu, 14 Dec 2000 23:48:04 -0600 (CST) Approved-By: dbj@CS.RICE.EDU Message-ID: <7863.976859284@cs.rice.edu> Date: Thu, 14 Dec 2000 23:48:04 -0600 Reply-To: Dave Johnson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Dave Johnson Subject: Re: [MOBILE-IP] comment on IKE in Mobile IPv6 X-To: Yoshihiro Ohba To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of "Thu, 14 Dec 2000 22:50:51 EST" <20001214225051A.yohba@tari.toshiba.com> >Hi, > >I have a comment regarding IKE in MIPv6 environment. > >In section 10.2 of the MIPv6 draft it is stated that: > >-------------------------------------------------------------------- > - The mobile node MUST use its care-of address as the Source > Address of all packets it sends as part of the key management > protocol (without use of Mobile IP for these packets, as > suggested in Section 10.1). > > - In addition, for all security associations bound to the mobile > node's home address, the mobile node MUST include an ISAKMP > Identification Payload [14] in the IKE exchange, giving the > mobile node's home address as the initiator of the Security > Association [22]. >-------------------------------------------------------------------- > >However, consider the case in which a mobile node is performing IKE >with a correspondent node which is also a mobile node. > >If care-of address is used as the Source Address for packets carrying >IKE messages without using Mobile IP, the packets may not be delivered >if both nodes change their care-of addresses at the same time. > >So I think at least Mobile IP should be used for IKE between a mobile >node and a correspondent node (and the mobile node and correspondent >node should not perform IKE before the mobile node is successfully >registered to its Home Agent.) > >Or am I missing something? > >Yoshihiro Ohba >Toshiba America Research, Inc. This is not necessary, since in the worst case, a home agent in the mobile node's previously visited network would forward packets addressed to the mobile node's previous care-of address to the mobile node's new care-of address, after the mobile node moves. See Section 10.9 of the draft. Dave From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 15 07:56:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28198 for ; Fri, 15 Dec 2000 07:56:20 -0500 (EST) Received: from standards (47.234.32.16:2230) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC36D1@standards.nortelnetworks.com>; Fri, 15 Dec 2000 7:36:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16652 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Dec 2000 07:36:21 -0500 Received: from inet-tsb.toshiba.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC36CF@standards.nortelnetworks.com>; Fri, 15 Dec 2000 7:36:20 -0500 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id VAA26657; Fri, 15 Dec 2000 21:54:22 +0900 (JST) Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id VAA13754; Fri, 15 Dec 2000 21:54:21 +0900 (JST) Received: from tis10.tis.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id VAA22524; Fri, 15 Dec 2000 21:54:21 +0900 (JST) Received: from mailhost.csl.rdc.toshiba.co.jp (chappy.csl.rdc.toshiba.co.jp [133.196.71.13]) by tis10.tis.toshiba.co.jp (8.9.3+3.2W/3.7W) with ESMTP id VAA17205; Fri, 15 Dec 2000 21:54:17 +0900 (JST) Received: from localhost (ohba@kddlos0130.mobile.toshiba.co.jp [10.16.11.49]) by mailhost.csl.rdc.toshiba.co.jp (8.9.3/8.9.0) with ESMTP id VAA29238; Fri, 15 Dec 2000 21:54:16 +0900 (JST) References: <20001214225051A.yohba@tari.toshiba.com> <7863.976859284@cs.rice.edu> X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Capitol Reef) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 62 Approved-By: Yoshihiro Ohba Message-ID: <20001215065402B.yohba@tari.toshiba.com> Date: Fri, 15 Dec 2000 06:54:02 -0500 Reply-To: Yoshihiro Ohba Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yoshihiro Ohba Subject: Re: [MOBILE-IP] comment on IKE in Mobile IPv6 X-To: dbj@cs.rice.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <7863.976859284@cs.rice.edu> Content-Transfer-Encoding: 7bit From: Dave Johnson Subject: Re: [MOBILE-IP] comment on IKE in Mobile IPv6 Date: Thu, 14 Dec 2000 23:48:04 -0600 > >Hi, > > > >I have a comment regarding IKE in MIPv6 environment. > > > >In section 10.2 of the MIPv6 draft it is stated that: > > > >-------------------------------------------------------------------- > > - The mobile node MUST use its care-of address as the Source > > Address of all packets it sends as part of the key management > > protocol (without use of Mobile IP for these packets, as > > suggested in Section 10.1). > > > > - In addition, for all security associations bound to the mobile > > node's home address, the mobile node MUST include an ISAKMP > > Identification Payload [14] in the IKE exchange, giving the > > mobile node's home address as the initiator of the Security > > Association [22]. > >-------------------------------------------------------------------- > > > >However, consider the case in which a mobile node is performing IKE > >with a correspondent node which is also a mobile node. > > > >If care-of address is used as the Source Address for packets carrying > >IKE messages without using Mobile IP, the packets may not be delivered > >if both nodes change their care-of addresses at the same time. > > > >So I think at least Mobile IP should be used for IKE between a mobile > >node and a correspondent node (and the mobile node and correspondent > >node should not perform IKE before the mobile node is successfully > >registered to its Home Agent.) > > > >Or am I missing something? > > > >Yoshihiro Ohba > >Toshiba America Research, Inc. > > This is not necessary, since in the worst case, a home agent in > the mobile node's previously visited network would forward packets > addressed to the mobile node's previous care-of address to the > mobile node's new care-of address, after the mobile node moves. > See Section 10.9 of the draft. > > Dave Thank you for the response. It implies that in the worst case, a mobile node may need to perform IKE with the visiting network's home agent before doing IKE with a correspondent node. If such kind of IKE-for-IKE is not preferable, we could also consider to have an option to use Mobile IP (based on tunneling between a mobile node and its original(?) home agent) for IKE between a mobile node and a correspondent node, in order to improve the worst case behavior. Yoshihiro Ohba From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 15 12:58:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13990 for ; Fri, 15 Dec 2000 12:58:30 -0500 (EST) Received: from standards (47.234.32.16:2862) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC37BE@standards.nortelnetworks.com>; Fri, 15 Dec 2000 12:38:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16968 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Dec 2000 12:38:38 -0500 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC37BC@standards.nortelnetworks.com>; Fri, 15 Dec 2000 12:38:37 -0500 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eBFHu6420766; Fri, 15 Dec 2000 18:56:07 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA24450; Fri, 15 Dec 2000 18:56:05 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id SAA90103; Fri, 15 Dec 2000 18:57:35 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Approved-By: Francis.Dupont@ENST-BRETAGNE.FR Message-ID: <200012151757.SAA90103@givry.rennes.enst-bretagne.fr> Date: Fri, 15 Dec 2000 18:57:35 +0100 Reply-To: Francis Dupont Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] comment on IKE in Mobile IPv6 X-To: Yoshihiro Ohba To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Thu, 14 Dec 2000 22:50:51 EST. <20001214225051A.yohba@tari.toshiba.com> In your previous mail you wrote: However, consider the case in which a mobile node is performing IKE with a correspondent node which is also a mobile node. If care-of address is used as the Source Address for packets carrying IKE messages without using Mobile IP, the packets may not be delivered if both nodes change their care-of addresses at the same time. => this is the double movement problem, It is solved by the fallback mechanism to the unoptimized version of mobile IPv6: - packets are sent to the home address via a care-of address using a routing header - the care-of address is too old, ie. unreachable, so ICMP errors are returned back or some kind of timeout occurs - the sender discovered the binding cache entry is wrong, it flushes it and goes though the home agent. The only annoying event is to change the care-of address before IKE exchanges are finished. So I think at least Mobile IP should be used for IKE between a mobile node and a correspondent node (and the mobile node and correspondent node should not perform IKE before the mobile node is successfully registered to its Home Agent.) => it is critical to use the care-of address for the IKE with the Home Agent but not for other correspondents. If the mobile node uses its home address and the correspondent has already a binding (valid binding but expired SAs) then the correspondent must flush the binding as the first step. This is expensive too... There are some trade-offs but the current specification is simpler, perhaps we should change to a MUST for home agent and a SHOULD for other correspondents. I don't personally believe possible gains are enough for the complexity (ie. I'd like to apply the KISS principle :-). Or am I missing something? => one point is not clear: if the initiator mobile node uses its care-of address, it knows only the home address of its peer then the problem is not symmetrical (and you can get two independent IKEs in the same time then four SAs). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 15 13:47:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00975 for ; Fri, 15 Dec 2000 13:47:04 -0500 (EST) Received: from standards (47.234.32.16:4901) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3811@standards.nortelnetworks.com>; Fri, 15 Dec 2000 13:27:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17081 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Dec 2000 13:27:06 -0500 Received: from thalia.eecs.wsu.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC380F@standards.nortelnetworks.com>; Fri, 15 Dec 2000 13:27:05 -0500 Received: from carmel.eecs.wsu.edu (IDENT:root@carmel.eecs.wsu.edu [199.237.72.81]) by thalia.eecs.wsu.edu with ESMTP (8.9.3/) id KAA06949 for ; Fri, 15 Dec 2000 10:45:11 -0800 (PST) Received: (from dawn@localhost) by carmel.eecs.wsu.edu (8.9.3/) id KAA03891 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Dec 2000 10:45:10 -0800 X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: "DAWN Research Lab - Dr. Sivalingam" Message-ID: <200012151845.KAA03891@carmel.eecs.wsu.edu> Date: Fri, 15 Dec 2000 10:45:10 -0800 Reply-To: "DAWN Research Lab - Dr. Sivalingam" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "DAWN Research Lab - Dr. Sivalingam" Subject: [MOBILE-IP] CFP: Mobicom 2001 - Deadline Approaching To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Enclosed below please find a Preliminary Announcement and Call for Papers for the 7th Annual International Conference on Mobile Computing and Networking (MobiCom) to be held in Rome, Italy from July 16-21, 2001. As you might already know, MobiCom has an established reputation as the pre-eminent conference in this area owing to the exceptionally high quality of papers, excellent tutorials and workshops, and stimulating panels conducted by mobile computing illuminati of various stripes. For complete information about the upcoming conference, please visit: http://www.research.ibm.com/mobicom2001/ We apologize if you received multiple copies of this Call for Papers. Please feel free to distribute it to those who might be interested. Very truly yours, ACM SIGMOBILE MobiCom 2001 Organizing Committee *********************************************************************** Preliminary Announcement and Call for Papers *** ACM MobiCom 2001 *** The Seventh Annual International Conference on Mobile Computing and Networking July 16-21, Rome, Italy Sponsored by ACM SIGMOBILE http://www.research.ibm.com/mobicom2001/ http://www.acm.org/sigmobile/ Submission Deadline: January 12, 2001 *********************************************************************** PAPERS: Technical papers (maximum 15 pages) describing original, previously unpublished, completed research, not currently under review by another conference or journal, are solicited on the following topics: * Applications and computing services supporting mobile users * Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity * Database and data management issues in mobile computing * Performance of mobile/wireless networks and systems * Security and privacy of mobile/wireless systems * Interaction between different layers of mobile/wireless systems * Integration and interworking of wired and wireless networks * Adaptive applications and systems for mobile environments * Distributed-system aspects of mobile systems * Operating system support for mobility * Location-dependent applications * Wireless multimedia systems * Power management * Mobile agents * Pervasive computing * Wireless sensor networks * Wireless/mobile service management and delivery All papers will be refereed by the program committee. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Baltzer Wireless Networks (WINET) and Mobile Networks and Applications (MONET) journals. Note: Student Registrations will be provided at a discounted rate. CHALLENGES SESSION, PANELS, RESEARCH DEMOS, TUTORIALS: Short papers (maximum of 8 pages) that challenge the mobile computing community with new technologies or visionary applications are solicited. Such papers should provide stimulating ideas or visions that may open up exciting avenues of mobile computing research. Proposals are solicited for panels that examine innovative, controversial, or otherwise provocative issues of interest. Proposals for tutorials are solicited. Tutorial topics that encompass the systems aspects of mobile computing and/or practical experiences in building/deploying such systems are of particular interest. Informal proposals for research demos are solicited. Proposals should include: the focus area in mobility, the technologies involved, specific equipment used, demo layout, space required, etc. Please refer to the conference website for submission and other details. IMPORTANT DATES: * Technical Paper Submissions due: January 12, 2001 - Please refer to the website for submission instructions * Notification of acceptance: May 1, 2001 * Camera-ready version due: May 15, 2001 * Challenges Session Papers, Panel Proposals, Tutorial Proposals Submissions due: January 12, 2001 - Please refer to the website for submission instructions FOR MORE INFORMATION: Send email to mobicom2001@winlab.rutgers.edu with any questions or comments about the conference or for more information. ORGANIZING COMMITTEE: * General Chair: * Tutorials Co-Chairs: Christopher Rose Ravi Jain Rutgers University, WINLAB Telcordia Technologies * General Vice Chair: Chiara Petrioli Politecnico di Milano Sergio Palazzo Universita` di Catania * Panels Chair: * Program Co-Chairs: Ramesh Rao Univ. of California, San Diego Mahmoud Naghshineh IBM T.J. Watson Research Center * Local Arrangement Chair: Michele Zorzi Marco Listanti Universita` di Ferrara Universita` di Roma "La Sapienza" * Finance Chair: Chiara Petrioli Politecnico di Milano David B. Johnson Rice University * Registration Chair: * Exhibits/Sponsorships Chair: Irene Katzela Marco Ajmone Marsan Lucent Technologies Politecnico di Torino * Publicity Co-Chairs: * Research Demos Chair: Stefano Basagni Nigel Davies Univ. of Texas at Dallas Lancaster University Krishna Sivalingam * Steering Committee Chair: Washington State University Imrich Chlamtac Univ. of Texas at Dallas *********************************************************************** From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 15 21:54:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03790 for ; Fri, 15 Dec 2000 21:54:52 -0500 (EST) Received: from standards (47.234.32.16:2858) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3957@standards.nortelnetworks.com>; Fri, 15 Dec 2000 21:35:00 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17522 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Dec 2000 21:34:59 -0500 Received: from prserv.net (out2.prserv.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3955@standards.nortelnetworks.com>; Fri, 15 Dec 2000 21:34:59 -0500 Received: from attglobal.net ([32.101.252.201]) by prserv.net (out2) with SMTP id <2000121602530420200p7glde>; Sat, 16 Dec 2000 02:53:05 +0000 X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <200012142044.MAA08922@nasnfs.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Sebastian Thalanany Message-ID: <3A3AD7BB.4848695B@attglobal.net> Date: Fri, 15 Dec 2000 20:47:23 -0600 Reply-To: sebastn@attglobal.net Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sebastian Thalanany Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for FastHandoff Discussion To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I support Jim's proposition for the following reasons: 1. In the context of wireless mobility, the objective of a handoff scheme is to minimize both latency and signaling overhead. 2. An architectural approach, where Mobile IPv4 utilizes abstract triggers obtained from a wireless link, where the triggers are independent of any specific wireless link technology, is essential for an efficient wireless mobile handoff scheme. 3. In the proactive proposal the Mobile IPv4 signaling is used deterministically, since an abstract trigger, from the underlying wireless link, is effectively utilized. Regards, Sebastian James Kempf wrote: > For those of you who were at Randy Bush's talk on Wed. nite, one of the important points I > took away is that DNS is in the mess it is in because the working group did not > exercise enough design control. They chose incremental update as opposed to architectural > update. > > I think there is a lession here for the fast handoff discussion. In particular, the > two proposals for IPv4 represent the two choices. The proactive proposal essentially > takes the architectural approach. It is saying that the current mobile IPv4 architecture > needs modification in order to adequately support fast handoff. The Heshim and Karim > proposal (I'll not call it "fast handoff" because that is confusing, both proposals > support fast handoff) takes the incremental approach. As the authors have stated time > and again, their proposal is an incremental update to the existing mobile IP architecture. > > If we merge the proposals, I wonder if, two years from now, one of our working group chairs won't be > up on stage at the plenium giving exactly the same presentation as Randy did but for > mobile IP. > > I'd therefore like to ask the working group to reconsider its hum for merging. > > jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Dec 16 04:16:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07181 for ; Sat, 16 Dec 2000 04:16:57 -0500 (EST) Received: from standards (47.234.32.16:3819) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3A5F@standards.nortelnetworks.com>; Sat, 16 Dec 2000 3:57:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17877 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 16 Dec 2000 03:57:02 -0500 Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3A5D@standards.nortelnetworks.com>; Sat, 16 Dec 2000 3:57:02 -0500 Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 16 Dec 2000 01:12:35 -0800 (Pacific Standard Time) Received: by inet-imc-03.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Fri, 15 Dec 2000 16:24:38 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Approved-By: Richard Draves Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9BFA@red-msg-06.redmond.corp.microsoft.com> Date: Fri, 15 Dec 2000 14:31:15 -0800 Reply-To: Richard Draves Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Richard Draves Subject: Re: [MOBILE-IP] comment on IKE in Mobile IPv6 X-To: Yoshihiro Ohba To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > However, consider the case in which a mobile node is performing IKE > with a correspondent node which is also a mobile node. > > If care-of address is used as the Source Address for packets carrying > IKE messages without using Mobile IP, the packets may not be delivered > if both nodes change their care-of addresses at the same time. > > So I think at least Mobile IP should be used for IKE between a mobile > node and a correspondent node (and the mobile node and correspondent > node should not perform IKE before the mobile node is successfully > registered to its Home Agent.) I don't understand how your scenario would arise. Typically when mobile node A tries to contact mobile node B, it would do a lookup of some kind (say DNS) that would return mobile node B's home address. So the first IKE packet would be sent from A's care-of address to B's home address. Rich From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Dec 18 04:08:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06789 for ; Mon, 18 Dec 2000 04:08:41 -0500 (EST) Received: from standards (47.234.32.16:1721) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3D8B@standards.nortelnetworks.com>; Mon, 18 Dec 2000 3:48:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18970 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 18 Dec 2000 03:48:20 -0500 Received: from localhost.ipunplugged.com (195.42.212.161:22692) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3D89@standards.nortelnetworks.com>; Mon, 18 Dec 2000 3:48:20 -0500 Received: from fredrikj (c8.localhost.ipunplugged.com [192.168.4.207]) by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA16592 for ; Mon, 18 Dec 2000 10:07:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Approved-By: Fredrik Johansson Message-ID: Date: Mon, 18 Dec 2000 10:08:52 +0100 Reply-To: Fredrik Johansson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fredrik Johansson Subject: [MOBILE-IP] Challenge/Response To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, I have a couple of questions regarding the Challenge/Response RFC. 1) There seems to be some inconsistency in different sections of the RFC, see below for each section. and by the way what's the meaning of sending a new Challenge extension in a non successful registration reply if it can not be accepted by the foreign agent? Section 3.1 "A successful Registration Reply from the Foreign Agent MAY include a new Challenge value (see section 3.3). The Mobile Node MAY use either the value found in the latest Advertisement, or the one found in the last Registration Reply from the Foreign Agent. This approach enables the Mobile Node to make use of the challenge without having to wait for advertisements." Section 3.2 "The Foreign Agent MUST NOT accept any Challenge in the Registration Request unless it was offered in last successful Registration Reply issued to the Mobile Node, or else advertised as one of the last CHALLENGE_WINDOW (see section 9) Challenge values inserted into the immediately preceding Agent advertisements." Section 3.3 "The Foreign Agent MAY include a new Challenge extension in any Registration Reply, successful or not." 2) Say that a foreign agent allow for a Challenge window of 3, i.e. it will allow registrations to pass which contain one of the last three challenges that were sent out from the foreign agent. That means that the foreign agent need to save the last three challenges it sent on that interface. It also need to store the challenge it receives in registration request in order to prevent a mobile to use the same challenge twice. This means at least one/mobile that tries to register. If the foreign agent also chose to send a Challenge in the registration reply to a mobile, it has to store one extra Challenge / mobile it sends a reg reply to. Is it reasonable that a foreign agent should store and process that many challenges? /Fredrik ---------------------------------------------------------------------------- ------- Fredrik Johansson W: +46 (0)8 725 5916 Interactive People Unplugged M: +46 (0)709 684 376 mailto:fredrik.johansson@ipunplugged.com http://www.ipunplugged.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Dec 18 09:16:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08813 for ; Mon, 18 Dec 2000 09:16:36 -0500 (EST) Received: from standards (47.234.32.16:4246) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3E64@standards.nortelnetworks.com>; Mon, 18 Dec 2000 8:56:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19250 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 18 Dec 2000 08:56:04 -0500 Received: from web9901.mail.yahoo.com (216.136.129.36:3373) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3E62@standards.nortelnetworks.com>; Mon, 18 Dec 2000 8:56:04 -0500 Received: from [158.227.194.218] by web9901.mail.yahoo.com; Mon, 18 Dec 2000 15:14:19 CET MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Approved-By: =?iso-8859-1?q?Alfonso=20Garc=EDa?= Message-ID: <20001218141419.16154.qmail@web9901.mail.yahoo.com> Date: Mon, 18 Dec 2000 15:14:19 +0100 Reply-To: =?iso-8859-1?q?Alfonso=20Garc=EDa?= Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: =?iso-8859-1?q?Alfonso=20Garc=EDa?= Subject: [MOBILE-IP] unsubscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit _______________________________________________________________ Do You Yahoo!? Consiga gratis su dirección @yahoo.es en http://correo.yahoo.es From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Dec 18 11:30:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10563 for ; Mon, 18 Dec 2000 11:30:46 -0500 (EST) Received: from standards (47.234.32.16:2862) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3EE6@standards.nortelnetworks.com>; Mon, 18 Dec 2000 11:10:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19426 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 18 Dec 2000 11:10:41 -0500 Received: from web803.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3EE4@standards.nortelnetworks.com>; Mon, 18 Dec 2000 11:10:40 -0500 Received: (qmail 28615 invoked by uid 60001); 18 Dec 2000 16:28:55 -0000 Received: from [47.230.0.42] by web803.mail.yahoo.com; Mon, 18 Dec 2000 08:28:55 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Approved-By: Kory Keith Message-ID: <20001218162855.28614.qmail@web803.mail.yahoo.com> Date: Mon, 18 Dec 2000 08:28:55 -0800 Reply-To: Kory Keith Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Kory Keith Subject: Re: [MOBILE-IP] Challenge/Response To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I understand section 3.2 to say that the FA needs to store (CHALLENGE_WINDOW + 1) challenges to protect against unknown challenges, but it does not define how many to store to protect against STALE_CHALLENGE (sec. 3.2 previous paragraph). Kory Keith > Section 3.2 > "The Foreign Agent MUST NOT accept any Challenge in > the Registration > Request unless it was offered in last successful > Registration Reply > issued to the Mobile Node, or else advertised as > one of the last > CHALLENGE_WINDOW (see section 9) Challenge values > inserted into the > immediately preceding Agent advertisements." > 2) Say that a foreign agent allow for a Challenge > window of 3, i.e. it will > allow registrations to pass which contain one of the > last three challenges > that were sent out from the foreign agent. That > means that the foreign agent > need to save the last three challenges it sent on > that interface. It also > need to store the challenge it receives in > registration request in order to > prevent a mobile to use the same challenge twice. > This means at least > one/mobile that tries to register. If the foreign > agent also chose to send a > Challenge in the registration reply to a mobile, it > has to store one extra > Challenge / mobile it sends a reg reply to. Is it > reasonable that a foreign > agent should store and process that many challenges? > > /Fredrik > ---------------------------------------------------------------------------- > ------- > Fredrik Johansson W: +46 (0)8 725 > 5916 > Interactive People Unplugged M: +46 (0)709 684 > 376 > mailto:fredrik.johansson@ipunplugged.com > http://www.ipunplugged.com __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Dec 18 13:51:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13033 for ; Mon, 18 Dec 2000 13:51:23 -0500 (EST) Received: from standards (47.234.32.16:2520) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3FC8@standards.nortelnetworks.com>; Mon, 18 Dec 2000 13:31:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19733 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 18 Dec 2000 13:31:05 -0500 Received: from thumper.research.telcordia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3FC6@standards.nortelnetworks.com>; Mon, 18 Dec 2000 13:31:04 -0500 Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id eBIInDu07745; Mon, 18 Dec 2000 13:49:16 -0500 (EST) Received: from localhost (ohba@tari-dhcp-109.research.telcordia.com [207.3.232.109]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id NAA07747; Mon, 18 Dec 2000 13:50:08 -0500 (EST) References: <7695E2F6903F7A41961F8CF888D87EA81C9BFA@red-msg-06.redmond.corp.microsoft.com> X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Capitol Reef) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 46 Approved-By: Yoshihiro Ohba Message-ID: <20001218124857W.yohba@tari.toshiba.com> Date: Mon, 18 Dec 2000 12:48:57 -0500 Reply-To: Yoshihiro Ohba Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yoshihiro Ohba Subject: Re: [MOBILE-IP] comment on IKE in Mobile IPv6 X-To: richdr@microsoft.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA81C9BFA@red-msg-06.redmond.corp.microsoft.com> Content-Transfer-Encoding: 7bit From: Richard Draves Subject: RE: [MOBILE-IP] comment on IKE in Mobile IPv6 Date: Fri, 15 Dec 2000 14:31:15 -0800 > > However, consider the case in which a mobile node is performing IKE > > with a correspondent node which is also a mobile node. > > > > If care-of address is used as the Source Address for packets carrying > > IKE messages without using Mobile IP, the packets may not be delivered > > if both nodes change their care-of addresses at the same time. > > > > So I think at least Mobile IP should be used for IKE between a mobile > > node and a correspondent node (and the mobile node and correspondent > > node should not perform IKE before the mobile node is successfully > > registered to its Home Agent.) > > I don't understand how your scenario would arise. Typically when mobile node > A tries to contact mobile node B, it would do a lookup of some kind (say > DNS) that would return mobile node B's home address. So the first IKE packet > would be sent from A's care-of address to B's home address. > > Rich It seems that there is no problem with first IKE packet sent from A. But how about other IKE packets? When A receives an IKE response packet from B in response to the first packet, the source address of the received packet is B's care-of address, according to the current MIPv6 specification. Then, there are two choices on the destination address of the second or thereafter IKE packets sent from A to B: B's care-of address and B's home address. In the first choice, there is the double movement issue that I mentioned. In the second choice, there is no double movement issue, however, I don't think the use of B's care-of address (as the source address of the IKE response packet from B) makes sence, bacause A never uses it. This also makes me wonder why not using the home address as the source address (seen by the application level) of IKE packets between a mobile node and a correspondent node. Yoshihiro Ohba From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Dec 18 15:06:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14359 for ; Mon, 18 Dec 2000 15:06:09 -0500 (EST) Received: from standards (47.234.32.16:2520) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4077@standards.nortelnetworks.com>; Mon, 18 Dec 2000 14:45:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19972 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 18 Dec 2000 14:45:54 -0500 Received: from thumper.research.telcordia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4075@standards.nortelnetworks.com>; Mon, 18 Dec 2000 14:45:54 -0500 Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id eBIK3ou11086; Mon, 18 Dec 2000 15:03:53 -0500 (EST) Received: from localhost (ohba@tari-dhcp-109.research.telcordia.com [207.3.232.109]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id PAA07907; Mon, 18 Dec 2000 15:04:39 -0500 (EST) References: <"20001214225051A.yohba"@tari.toshiba.com> <200012151757.SAA90103@givry.rennes.enst-bretagne.fr> X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Capitol Reef) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 80 Approved-By: Yoshihiro Ohba Message-ID: <20001218140332K.yohba@tari.toshiba.com> Date: Mon, 18 Dec 2000 14:03:32 -0500 Reply-To: Yoshihiro Ohba Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yoshihiro Ohba Subject: Re: [MOBILE-IP] comment on IKE in Mobile IPv6 X-To: Francis.Dupont@enst-bretagne.fr To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200012151757.SAA90103@givry.rennes.enst-bretagne.fr> Content-Transfer-Encoding: 7bit From: Francis Dupont Subject: Re: [MOBILE-IP] comment on IKE in Mobile IPv6 Date: Fri, 15 Dec 2000 18:57:35 +0100 > In your previous mail you wrote: > > However, consider the case in which a mobile node is performing IKE > with a correspondent node which is also a mobile node. > > If care-of address is used as the Source Address for packets carrying > IKE messages without using Mobile IP, the packets may not be delivered > if both nodes change their care-of addresses at the same time. > > => this is the double movement problem, It is solved by the fallback > mechanism to the unoptimized version of mobile IPv6: > - packets are sent to the home address via a care-of address using > a routing header > - the care-of address is too old, ie. unreachable, so ICMP errors > are returned back or some kind of timeout occurs > - the sender discovered the binding cache entry is wrong, it flushes > it and goes though the home agent. Yes, I agree with this solution is valid for IKE packets sent from Initiator to Responder, since the Responders' home address can be used as the destination address for those packets. > The only annoying event is to change the care-of address before IKE > exchanges are finished. > Yes, this issue also should be solved. > So I think at least Mobile IP should be used for IKE between a mobile > node and a correspondent node (and the mobile node and correspondent > node should not perform IKE before the mobile node is successfully > registered to its Home Agent.) > > => it is critical to use the care-of address for the IKE with the Home > Agent but not for other correspondents. If the mobile node uses its Exactly speaking, it is mandatory to use the care-of address for the IKE with the Home Agent only when no security association yet exists between the mobile node and Home Agent, but not for other cases. In other words, if there is already a security association between the mobile node and Home Agent and IKE is performed between them for updating keys, then home address could be used. > home address and the correspondent has already a binding (valid binding > but expired SAs) then the correspondent must flush the binding as > the first step. This is expensive too... There are some trade-offs > but the current specification is simpler, perhaps we should change > to a MUST for home agent and a SHOULD for other correspondents. > I don't personally believe possible gains are enough for the > complexity (ie. I'd like to apply the KISS principle :-). I think more detailed description that focuses on IKE in MIPv6 and covers all possible scenarios is needed, and agree with Mohan Parthasarathy to have an informational draft. > > Or am I missing something? > > => one point is not clear: if the initiator mobile node uses > its care-of address, it knows only the home address of its peer > then the problem is not symmetrical (and you can get two independent > IKEs in the same time then four SAs). > Although I don't like the asymmetrical case, Cookie fields in ISAKMP header and/or Identification Payload in ISAKMP payload could be used to avoid creating the independent IKEs for such kind of asymmetric cases. > Regards > > Francis.Dupont@enst-bretagne.fr Regards, Yoshihiro Ohba From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Dec 18 15:14:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14457 for ; Mon, 18 Dec 2000 15:14:10 -0500 (EST) Received: from standards (47.234.32.16:2520) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4098@standards.nortelnetworks.com>; Mon, 18 Dec 2000 14:48:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20011 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 18 Dec 2000 14:48:40 -0500 Received: from mail5.microsoft.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4095@standards.nortelnetworks.com>; Mon, 18 Dec 2000 14:48:40 -0500 Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 18 Dec 2000 11:10:08 -0800 (Pacific Standard Time) Received: by inet-imc-05.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Mon, 18 Dec 2000 11:10:06 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Approved-By: Richard Draves Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9C00@red-msg-06.redmond.corp.microsoft.com> Date: Mon, 18 Dec 2000 11:09:56 -0800 Reply-To: Richard Draves Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Richard Draves Subject: Re: [MOBILE-IP] comment on IKE in Mobile IPv6 X-To: Yoshihiro Ohba To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > I don't understand how your scenario would arise. Typically > when mobile node > > A tries to contact mobile node B, it would do a lookup of > some kind (say > > DNS) that would return mobile node B's home address. So the > first IKE packet > > would be sent from A's care-of address to B's home address. > > It seems that there is no problem with first IKE packet sent from A. > But how about other IKE packets? > > When A receives an IKE response packet from B in response to the first > packet, the source address of the received packet is B's care-of > address, according to the current MIPv6 specification. I don't read section 10.2 of the specification that way. The spec talks about mobile node and correspondent node. In this scenario, B is the correspondent node and so the requirement to use a care-of source address does not apply to B. Once an IKE negotiation is started with a source/destination address pair, I think it would continue to completion using the same source/destination. > Then, there are two choices on the destination address of the second > or thereafter IKE packets sent from A to B: B's care-of address and > B's home address. > > In the first choice, there is the double movement issue that I > mentioned. > > In the second choice, there is no double movement issue, however, I > don't think the use of B's care-of address (as the source address of > the IKE response packet from B) makes sence, bacause A never uses it. > This also makes me wonder why not using the home address as the source > address (seen by the application level) of IKE packets between a > mobile node and a correspondent node. There is a strong desire for a mobile node to contact a correspondent node and communicate using the mobile's home address, without ever involving the home agent, if the correspondent node can accept a Binding Update. Once nodes A & B have established communication and sent each other Binding Updates, then there is a possibility that future IKE negotiations (for example when an SA times out and a new SA must be created) between the two could use their respective care-of addresses. To avoid the double movement problem, the node initiating the negotiation (eg, node A) should fall back to using a home address instead of a care-of address for the other party (eg, node B), if the negotation times out. Rich From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Dec 18 15:41:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15031 for ; Mon, 18 Dec 2000 15:41:38 -0500 (EST) Received: from standards (47.234.32.16:2520) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4116@standards.nortelnetworks.com>; Mon, 18 Dec 2000 15:21:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20188 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 18 Dec 2000 15:21:31 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4114@standards.nortelnetworks.com>; Mon, 18 Dec 2000 15:21:30 -0500 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA26797; Mon, 18 Dec 2000 12:39:37 -0800 (PST) Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA21494; Mon, 18 Dec 2000 12:39:08 -0800 (PST) Received: (from mohanp@localhost) by locked.eng.sun.com (8.10.1+Sun/8.10.1) id eBIKbmb11718; Mon, 18 Dec 2000 12:37:48 -0800 (PST) X-Sun-Charset: US-ASCII Approved-By: Mohan Parthasarathy Message-ID: <200012182037.eBIKbmb11718@locked.eng.sun.com> Date: Mon, 18 Dec 2000 12:37:48 -0800 Reply-To: Mohan Parthasarathy Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohan Parthasarathy Subject: Re: [MOBILE-IP] comment on IKE in Mobile IPv6 X-To: yohba@tari.toshiba.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > > > However, consider the case in which a mobile node is performing IKE > > > with a correspondent node which is also a mobile node. > > > > > > If care-of address is used as the Source Address for packets carrying > > > IKE messages without using Mobile IP, the packets may not be delivered > > > if both nodes change their care-of addresses at the same time. > > > > > > So I think at least Mobile IP should be used for IKE between a mobile > > > node and a correspondent node (and the mobile node and correspondent > > > node should not perform IKE before the mobile node is successfully > > > registered to its Home Agent.) > > > > I don't understand how your scenario would arise. Typically when mobile node > > A tries to contact mobile node B, it would do a lookup of some kind (say > > DNS) that would return mobile node B's home address. So the first IKE packet > > would be sent from A's care-of address to B's home address. > > > > Rich > > It seems that there is no problem with first IKE packet sent from A. > But how about other IKE packets? > Section 10.2 does not talk about what you use for the destination address in the IKE packets. So, it could be the Care of address of the CN. Thus, the first packets also have the same problem. -mohan > When A receives an IKE response packet from B in response to the first > packet, the source address of the received packet is B's care-of > address, according to the current MIPv6 specification. > > Then, there are two choices on the destination address of the second > or thereafter IKE packets sent from A to B: B's care-of address and > B's home address. > > In the first choice, there is the double movement issue that I > mentioned. > > In the second choice, there is no double movement issue, however, I > don't think the use of B's care-of address (as the source address of > the IKE response packet from B) makes sence, bacause A never uses it. > This also makes me wonder why not using the home address as the source > address (seen by the application level) of IKE packets between a > mobile node and a correspondent node. > > Yoshihiro Ohba > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Dec 18 20:04:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19222 for ; Mon, 18 Dec 2000 20:04:12 -0500 (EST) Received: from standards (47.234.32.16:2244) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC41DB@standards.nortelnetworks.com>; Mon, 18 Dec 2000 19:44:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20464 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 18 Dec 2000 19:44:10 -0500 Received: from ms.samsung.com (211.45.29.136:56986) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC41D9@standards.nortelnetworks.com>; Mon, 18 Dec 2000 19:44:09 -0500 Received: from keg ([203.241.48.20]) by ms.samsung.com (Netscape Messaging Server 4.15) with SMTP id G5SITO00.DSO for ; Tue, 19 Dec 2000 10:01:00 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Approved-By: Woo-June Kim Message-ID: <004e01c06956$dbd75480$88b2d5a5@keg.telecom.samsung.co.kr> Date: Tue, 19 Dec 2000 09:58:53 +0900 Reply-To: Woo-June Kim Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Woo-June Kim Subject: Re: [MOBILE-IP] Challenge/Response To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id UAA19222 Hi, Here's my 2 cents... >1) There seems to be some inconsistency in different sections of the RFC, >see below for each section. > and by the way what's the meaning of sending a new Challenge extension >in a non successful registration reply if it can not be accepted by the >foreign agent? > One case that I can think of, would be for cases such as when the user gets a STALE_CHALLENGE reply. The user should be notified of a new challenge value to use, that sending it as an extension would be one way. Other cases would be the MISSING_CHALLENGE case and the UNKNOWN_CHALLENGE case. I am not sure about what you mean by the inconsistency below. Could you elaborate ? (I agree the wording seems to be a bit ambiguous in places.) >Section 3.1 >"A successful Registration Reply from the Foreign Agent MAY include > a new Challenge value (see section 3.3). The Mobile Node MAY use > either the value found in the latest Advertisement, or the one found > in the last Registration Reply from the Foreign Agent. This approach > enables the Mobile Node to make use of the challenge without having > to wait for advertisements." > >Section 3.2 >"The Foreign Agent MUST NOT accept any Challenge in the Registration > Request unless it was offered in last successful Registration Reply > issued to the Mobile Node, or else advertised as one of the last > CHALLENGE_WINDOW (see section 9) Challenge values inserted into the > immediately preceding Agent advertisements." > >Section 3.3 >"The Foreign Agent MAY include a new Challenge extension in any > Registration Reply, successful or not." > >2) Say that a foreign agent allow for a Challenge window of 3, i.e. it will >allow registrations to pass which contain one of the last three challenges >that were sent out from the foreign agent. That means that the foreign agent >need to save the last three challenges it sent on that interface. It also >need to store the challenge it receives in registration request in order to >prevent a mobile to use the same challenge twice. This means at least >one/mobile that tries to register. If the foreign agent also chose to send a >Challenge in the registration reply to a mobile, it has to store one extra >Challenge / mobile it sends a reg reply to. Is it reasonable that a foreign >agent should store and process that many challenges? > I think it depends on how you understand the above statement. The FA has to keep the challenge values that had been sent out in the previous CHALLENGE_WINDOW agent advertisements. The FA has to keep N_stale challenge / mobile, containing the previous challenge that had been used by the mobile in its last N_stale successful RRQ . The number N_stale will depend on how the STALE_CHALLENGE will be configured. My understanding is that N_stale = 1 should be enough. (All other cases can be taken care of as UNKNOWN_CHALLENGE) The FA has to keep the last challenge sent out in the RRP to the MN.While it is possible to use separate challenges for each user, I do not think the RFC requires that this must be the case. i.e. The FA may use a single challenge for all MNs. In such a case this would most likely result in one more challenge value that has to be kept globally in the FA. I think this is more in keeping with the original philosophy of using the (multicast) Agent Advertisements for the initial challenge value announcement. So to wrap up, it seems the FA needs to keep CHALLENGE_WINDOW + 1 challenge values globally, and N_stale (probably 1) challenge per MN (which can be kept with the visitor list database). This is probably what Kory Keith meant below in his short reply. Sorry for my verbous explanation if you already understood from Kory's message. Kory Keith's reply : ".... I understand section 3.2 to say that the FA needs to store (CHALLENGE_WINDOW + 1) challenges to protect against unknown challenges, but it does not define how many to store to protect against STALE_CHALLENGE (sec. 3.2 previous paragraph). ..." cheers Woojune Kim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Dec 19 04:36:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10100 for ; Tue, 19 Dec 2000 04:36:16 -0500 (EST) Received: from standards (47.234.32.16:1288) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC433F@standards.nortelnetworks.com>; Tue, 19 Dec 2000 4:16:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20939 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Dec 2000 04:16:06 -0500 Received: from localhost.ipunplugged.com (195.42.212.161:23223) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC433D@standards.nortelnetworks.com>; Tue, 19 Dec 2000 4:16:05 -0500 Received: from fredrikj (c8.localhost.ipunplugged.com [192.168.4.207]) by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA25504; Tue, 19 Dec 2000 10:34:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Approved-By: Fredrik Johansson Message-ID: Date: Tue, 19 Dec 2000 10:36:36 +0100 Reply-To: Fredrik Johansson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fredrik Johansson Subject: Re: [MOBILE-IP] Challenge/Response X-To: Woo-June Kim To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <004e01c06956$dbd75480$88b2d5a5@keg.telecom.samsung.co.kr> Content-Transfer-Encoding: 7bit Hi, thanks for the reply. What I mean by inconsistency is that, in paragraph 3.1 it is stated that "A successful Registration Reply from the Foreign Agent MAY include a new Challenge value ..." in paragraph 3.2 it is stated that "The Foreign Agent MUST NOT accept any Challenge in the Registration Request unless it was offered in last successful Registration Reply..." and in paragraph 3.3 it is stated that "The Foreign Agent MAY include a new Challenge extension in any Registration Reply, successful or not." I.e. A FA may send a new Challenge in any registration reply, but it will only accept registrations containing challenges sent in successful registration replies. So what is the meaning of sending new Challenges in unsuccessful registration replies? Another problem that is caused by this is that when a MN register for the first time, its timestamp will most likley be wrong, so the HA will deny the registration. Now the MN has to wait for it to receive another challenge before it can register again. Regarding the number of challenges you need to keep, I believe that it will be more than CHALLENGE_WINDOW + 1 since you have to keep the challenge sent in a registration reply until the time for the registration expires or a new registration reply is sent. I agree that sending the same challenge to all MNs might reduce the number of challenges that are necessary to save. However, it is still more than CHALLENGE_WINDOW + 1. Say that you your CHALLENGE_WINDOW = 3 you send Challenge C1, C2 and C3 as broadcast in advertisments you also have a Challenge C4 that are sent to mobiles in registration replies MN_A and MN_B both register and receive C4 in the RRP, now you have stored C1, C2, C3 and C4 after a while MN_B re-register using C4, in the RRP you now send a new challenge C5. You now have to save C1, C2, C3, C4, C5 since MN_A can still use C4. Thus, I don't agree that CHALLENGE_WINDOW + 1 is enough. This number will increase for every MN that re-register. C4 can not be removed until all MNs that have recieved it in a RRP has re-registed or their registration has expired. /Fredrik > >Hi, > >Here's my 2 cents... > > >>1) There seems to be some inconsistency in different sections of the RFC, >>see below for each section. >> and by the way what's the meaning of sending a new Challenge extension >>in a non successful registration reply if it can not be accepted by the >>foreign agent? >> > >One case that I can think of, would be for cases such as when the >user gets a STALE_CHALLENGE reply. The user should be notified of >a new challenge value to use, that sending it as an extension >would be one way. > >Other cases would be the MISSING_CHALLENGE case and the >UNKNOWN_CHALLENGE case. > >I am not sure about what you mean by the inconsistency below. >Could you elaborate ? (I agree the wording seems to be a bit >ambiguous in places.) > >>Section 3.1 >>"A successful Registration Reply from the Foreign Agent MAY include >> a new Challenge value (see section 3.3). The Mobile Node MAY use >> either the value found in the latest Advertisement, or the one found >> in the last Registration Reply from the Foreign Agent. This approach >> enables the Mobile Node to make use of the challenge without having >> to wait for advertisements." >> >>Section 3.2 >>"The Foreign Agent MUST NOT accept any Challenge in the Registration >> Request unless it was offered in last successful Registration Reply >> issued to the Mobile Node, or else advertised as one of the last >> CHALLENGE_WINDOW (see section 9) Challenge values inserted into the >> immediately preceding Agent advertisements." >> >>Section 3.3 >>"The Foreign Agent MAY include a new Challenge extension in any >> Registration Reply, successful or not." >> >>2) Say that a foreign agent allow for a Challenge window of 3, >i.e. it will >>allow registrations to pass which contain one of the last three challenges >>that were sent out from the foreign agent. That means that the >foreign agent >>need to save the last three challenges it sent on that interface. It also >>need to store the challenge it receives in registration request >in order to >>prevent a mobile to use the same challenge twice. This means at least >>one/mobile that tries to register. If the foreign agent also >chose to send a >>Challenge in the registration reply to a mobile, it has to store one extra >>Challenge / mobile it sends a reg reply to. Is it reasonable that >a foreign >>agent should store and process that many challenges? >> > > >I think it depends on how you understand the above statement. > >The FA has to keep the challenge values that had been sent out in >the previous CHALLENGE_WINDOW agent advertisements. > >The FA has to keep N_stale challenge / mobile, containing the >previous challenge that had been used by the mobile in its last >N_stale successful RRQ . The number N_stale will depend on how the >STALE_CHALLENGE will be configured. My understanding is that >N_stale = 1 should be enough. (All other cases can be taken care >of as UNKNOWN_CHALLENGE) > >The FA has to keep the last challenge sent out in the RRP to the >MN.While it is possible to use separate challenges for each user, >I do not think the RFC requires that this must be the case. i.e. >The FA may use a single challenge for all MNs. In such a case this >would most likely result in one more challenge value that has to >be kept globally in the FA. > >I think this is more in keeping with the original philosophy of >using the (multicast) Agent Advertisements for the initial >challenge value announcement. > >So to wrap up, it seems the FA needs to keep CHALLENGE_WINDOW + 1 >challenge values globally, and N_stale (probably 1) challenge per >MN (which can be kept with the visitor list database). > >This is probably what Kory Keith meant below in his short reply. >Sorry for my verbous explanation if you already understood from >Kory's message. > >Kory Keith's reply : >".... >I understand section 3.2 to say that the FA needs to >store (CHALLENGE_WINDOW + 1) challenges to protect >against unknown challenges, but it does not define how >many to store to protect against STALE_CHALLENGE (sec. >3.2 previous paragraph). >..." > >cheers > >Woojune Kim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Dec 19 11:56:12 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18176 for ; Tue, 19 Dec 2000 11:56:11 -0500 (EST) Received: from standards (47.234.32.16:1146) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC44E6@standards.nortelnetworks.com>; Tue, 19 Dec 2000 11:35:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21492 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Dec 2000 11:35:38 -0500 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC44E4@standards.nortelnetworks.com>; Tue, 19 Dec 2000 11:35:37 -0500 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eBJGrJ417907; Tue, 19 Dec 2000 17:53:19 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA05484; Tue, 19 Dec 2000 17:53:19 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id RAA17638; Tue, 19 Dec 2000 17:55:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Approved-By: Francis.Dupont@ENST-BRETAGNE.FR Message-ID: <200012191655.RAA17638@givry.rennes.enst-bretagne.fr> Date: Tue, 19 Dec 2000 17:55:10 +0100 Reply-To: Francis Dupont Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] comment on IKE in Mobile IPv6 X-To: Yoshihiro Ohba To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Mon, 18 Dec 2000 12:48:57 EST. <20001218124857W.yohba@tari.toshiba.com> In your previous mail you wrote: It seems that there is no problem with first IKE packet sent from A. But how about other IKE packets? => there is no difference for other packets. When A receives an IKE response packet from B in response to the first packet, the source address of the received packet is B's care-of address, according to the current MIPv6 specification. => no, B uses the same address than in A first packet. Only the initiator can use its care-of address, the responder will use its home address. Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Dec 19 15:45:35 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24318 for ; Tue, 19 Dec 2000 15:45:34 -0500 (EST) Received: from standards (47.234.32.16:2845) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4626@standards.nortelnetworks.com>; Tue, 19 Dec 2000 15:25:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21941 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Dec 2000 15:25:03 -0500 Received: from thumper.research.telcordia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4624@standards.nortelnetworks.com>; Tue, 19 Dec 2000 15:25:02 -0500 Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id eBJKhDu10912; Tue, 19 Dec 2000 15:43:21 -0500 (EST) Received: from localhost (ohba@tari-dhcp-109.research.telcordia.com [207.3.232.109]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id PAA09608; Tue, 19 Dec 2000 15:44:10 -0500 (EST) References: <20001218124857W.yohba@tari.toshiba.com> <200012191655.RAA17638@givry.rennes.enst-bretagne.fr> X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Capitol Reef) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 32 Approved-By: Yoshihiro Ohba Message-ID: <20001219144301K.yohba@tari.toshiba.com> Date: Tue, 19 Dec 2000 14:43:01 -0500 Reply-To: Yoshihiro Ohba Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yoshihiro Ohba Subject: Re: [MOBILE-IP] comment on IKE in Mobile IPv6 X-To: Francis.Dupont@enst-bretagne.fr To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200012191655.RAA17638@givry.rennes.enst-bretagne.fr> Content-Transfer-Encoding: 7bit From: Francis Dupont Subject: Re: [MOBILE-IP] comment on IKE in Mobile IPv6 Date: Tue, 19 Dec 2000 17:55:10 +0100 > In your previous mail you wrote: > > It seems that there is no problem with first IKE packet sent from A. > But how about other IKE packets? > > => there is no difference for other packets. > > When A receives an IKE response packet from B in response to the first > packet, the source address of the received packet is B's care-of > address, according to the current MIPv6 specification. > > => no, B uses the same address than in A first packet. Only the initiator > can use its care-of address, the responder will use its home address. > > Francis.Dupont@enst-bretagne.fr How about if the responder is also a mobile node? I could not read the section 10.2 as allowing the use of home address for IKE packets sent from the mobile responder. - The mobile node MUST use its care-of address as the Source Address of all packets it sends as part of the key management protocol (without use of Mobile IP for these packets, as suggested in Section 10.1). Yoshihiro Ohba From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Dec 19 15:53:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24520 for ; Tue, 19 Dec 2000 15:53:14 -0500 (EST) Received: from standards (47.234.32.16:2845) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4647@standards.nortelnetworks.com>; Tue, 19 Dec 2000 15:28:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21983 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Dec 2000 15:28:12 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4645@standards.nortelnetworks.com>; Tue, 19 Dec 2000 15:28:11 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA08580 for ; Tue, 19 Dec 2000 12:46:29 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id MAA29286 for ; Tue, 19 Dec 2000 12:46:29 -0800 (PST) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with SMTP id eBJKkSm273385; Tue, 19 Dec 2000 12:46:28 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 6P46D8MVchUyRoC/qoD0Og== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Approved-By: Alper Yegin Message-ID: <200012192046.eBJKkSm273385@jurassic.eng.sun.com> Date: Tue, 19 Dec 2000 12:45:25 -0800 Reply-To: Alper Yegin Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Alper Yegin Subject: [MOBILE-IP] MobileIP testing at Connectathon 2001 X-cc: aey@jurassic.Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, I've made a presentation on Connectathon 2001 MobileIP testing at the San Diego IETF. For those who missed it, here's the information you need to know... - We'll be testing Mobile IPv4, Mobile IPv6, and DIAMETER (see below for other technologies tested). - Testing will take place March 5th-8th, San Jose, California. - *** Registration deadline is February 7th, early bird special before December 31st *** - Testing will include: - UNH MIPv6 conformance test suite and interoperability testing - Sun MIPv4 conformance and interoperability test suite - DIAMETER conformance and interoperability test suite ... and also we'll be doing lots of ad-hoc testing - These are the drafts and RFCs we are planning to test at Connectathon: - draft-ietf-mobileip-ipv6-13.txt IPv6 Mobility Support - draft-ietf-mobileip-hmipv6-01.txt Hierarchical MIPv6 - RFC2002bis IPv4 Mobility Support - RFC2003 IP Encapsulation within IP - RFC2004 Minimal Encapsulation within IP - RFC2344bis Reverse Tunneling for Mobile IP - RFC2794 MIP NAI Extensions - RFC3012 MIP Challenge/Response - draft-ietf-mobileip-optim-10.txt Route Optimization for MIP - draft-ietf-mobileip-reg-tunnel-03.txt Regional Registrations - draft-ietf-mobileip-vendor-ext-11.txt Vendor Specific Extensions - draft-ietf-mobileip-gnaie-01.txt Generalized NAI Extension - draft-calhoun-diameter-mobileip-11.txt DIAMETER MobileIP Extensions - draft-calhoun-diameter-17.txt DIAMETER Base Protocol * The official AAA WG versions of above drafts will be tested. - Contact information: - www.cthon.org General Connectathon website - cthon@sun.com General Connectathon questions - mip-cthon@sunroof.eng.sun.com Majordomo mailing list for MIP testing - Alper.Yegin@sun.com (MIPv6, MIPv4) - Carl.Williams@sun.com (MIPv6, MIPv4) - Bill.Lenharth@unh.edu (MIPv6) - Pat.Calhoun@sun.com (DIAMETER) What is Connectathon ? In 1986, Sun Microsystems sponsored the first ConnectathonTM event, a unique forum for testing software and hardware interoperability. Connectathon is a network proving ground allowing vendors to test their interoperability solutions, with special emphasis on NFSTM and Internet protocols. Over the years, the vendor-neutral Connectathon has attracted a large number of development engineers from all major computer systems companies and a wide variety of software vendors. All have the common goal of making heterogeneous multivendor networking a reality. Now plans are being drawn to celebrate Connectathon's 14th year. Connectathon is an excellent opportunity for vendors to verify that their distributed computing software interoperates with a wide range of client/server implementations on different operating systems. Everything from laptops to supercomputers can be linked together under one roof, encouraging interaction among vendors, engineers and developers in a confidential atmosphere. Implementations are tested and debugged at Connectathon. There are panel discussions as well as open sessions on the latest developments in technologies and solutions by Connectathon participants. Connectathon is a place where engineers can gather without marketing hype and can exchange ideas and information. These are the technologies and protocols we'll be testing: NFS v2, v3, v4 IPv6 NFS over TCP IPsec WebNFS NDMP Lock Manager DHCPv6 NIS/NIS+ CIFS Kerberos Mobile IPv6 Automounter Mobile IPv4 Gigabit Ethernet DIAMETER SCTP From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Dec 20 03:47:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18925 for ; Wed, 20 Dec 2000 03:47:29 -0500 (EST) Received: from standards (47.234.32.16:2625) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC49EC@standards.nortelnetworks.com>; Wed, 20 Dec 2000 3:25:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23266 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Dec 2000 03:25:36 -0500 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC49EA@standards.nortelnetworks.com>; Wed, 20 Dec 2000 3:25:36 -0500 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eBK8hN434378; Wed, 20 Dec 2000 09:43:24 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id JAA01025; Wed, 20 Dec 2000 09:43:23 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id JAA22347; Wed, 20 Dec 2000 09:45:17 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Approved-By: Francis.Dupont@ENST-BRETAGNE.FR Message-ID: <200012200845.JAA22347@givry.rennes.enst-bretagne.fr> Date: Wed, 20 Dec 2000 09:45:17 +0100 Reply-To: Francis Dupont Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] comment on IKE in Mobile IPv6 X-To: Yoshihiro Ohba To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Tue, 19 Dec 2000 14:43:01 EST. <20001219144301K.yohba@tari.toshiba.com> In your previous mail you wrote: How about if the responder is also a mobile node? I could not read the section 10.2 as allowing the use of home address for IKE packets sent from the mobile responder. - The mobile node MUST use its care-of address as the Source Address of all packets it sends as part of the key management protocol (without use of Mobile IP for these packets, as suggested in Section 10.1). => this is for the case the mobile node has the choice of its source address, ie. when it is the initiator. When you are the responder, you must use the same address than the destination of the first packet. IKE is not different from other applications... Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Dec 20 13:16:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08328 for ; Wed, 20 Dec 2000 13:16:29 -0500 (EST) Received: from standards (47.234.32.16:3376) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4D26@standards.nortelnetworks.com>; Wed, 20 Dec 2000 12:56:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24330 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Dec 2000 12:56:09 -0500 Received: from patan.sun.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4D24@standards.nortelnetworks.com>; Wed, 20 Dec 2000 12:56:09 -0500 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18548; Wed, 20 Dec 2000 10:14:27 -0800 (PST) Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA21894; Wed, 20 Dec 2000 10:14:27 -0800 (PST) Received: (from mohanp@localhost) by locked.eng.sun.com (8.10.1+Sun/8.10.1) id eBKIDGt12722; Wed, 20 Dec 2000 10:13:17 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Approved-By: Mohan Parthasarathy Message-ID: <200012201813.eBKIDGt12722@locked.eng.sun.com> Date: Wed, 20 Dec 2000 10:13:16 -0800 Reply-To: Mohan Parthasarathy Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohan Parthasarathy Subject: Re: [MOBILE-IP] comment on IKE in Mobile IPv6 X-To: Francis Dupont To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200012200845.JAA22347@givry.rennes.enst-bretagne.fr> from Francis Dupont at "Dec 20, 2000 09:45:17 am" Content-Transfer-Encoding: 7bit > In your previous mail you wrote: > > How about if the responder is also a mobile node? > > I could not read the section 10.2 as allowing the use of home address > for IKE packets sent from the mobile responder. > > - The mobile node MUST use its care-of address as the Source > Address of all packets it sends as part of the key management > protocol (without use of Mobile IP for these packets, as > suggested in Section 10.1). > > => this is for the case the mobile node has the choice of its source address, > ie. when it is the initiator. When you are the responder, you must use > the same address than the destination of the first packet. IKE is not > different from other applications... > Yes, it is no different. But what mandates the destination address to be the Home address always ? For example, MN's SA expire, bindings are valid and while neogotiating the SA, it could be the Care of address of the CN if it is mobile. -mohan > Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Dec 20 13:29:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08985 for ; Wed, 20 Dec 2000 13:29:23 -0500 (EST) Received: from standards (47.234.32.16:3376) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4D72@standards.nortelnetworks.com>; Wed, 20 Dec 2000 13:09:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24432 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Dec 2000 13:09:14 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4D70@standards.nortelnetworks.com>; Wed, 20 Dec 2000 13:09:14 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29799; Wed, 20 Dec 2000 10:27:34 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id KAA06027; Wed, 20 Dec 2000 10:27:31 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with SMTP id eBKIRRL188603; Wed, 20 Dec 2000 10:27:28 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: jN8UY+T+PYt1wI5kn8ifOw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Approved-By: Samita Chakrabarti Message-ID: <200012201827.eBKIRRL188603@jurassic.eng.sun.com> Date: Wed, 20 Dec 2000 10:28:08 -0800 Reply-To: Samita Chakrabarti Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Samita Chakrabarti Subject: [MOBILE-IP] Reverse Tunneling rfc and Limited Private address support X-cc: samita@jurassic.Eng.Sun.COM, gab@eng.sun.com, Basavaraj.Patil@nokia.com, qa3445@email.mot.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM A few IETFs ago, it was decided by the working group (as I was told) to include limited private address support along with reverse tunnel support. That means a foreign agent with advertising "T" will support private addressed mobile nodes in a limited way. It was felt that extensive private address solution is not quite necessary when the industry is moving to adopt mobile IPv6. Now there are some important requirements and some other guidance went into draft-ietf-mobileip-rfc2344-bis-03.txt which is currently in the RFC editor's queue. The requirements actually are in the appendix section A.4. The basic requirements for LPAS are: Mobile IP MUST set the 'T' bit and employ reverse tunneling. Foreign agents MUST support reverse tunneling in order to support private addressed mobile nodes. If a foreign agent supports reverse tunneling, then it MUST support the simple scenario of private address support described in this section. All advertising interfaces of the foreign agent MUST have publicly routable care-of address Any home agent address used by mobile nodes in registration request MUST be a publicly routable address. Now according to the rules, Appendix section *cannot* mandate any requirements and since the reverse tunneling draft is now about to become the RFC, I'd like to propose to have another draft (either extension to reverse tunnel rfc or another form) for these requirements. I'll be happy to produce/initiate such draft by next IETF. At the San Diego IETF I was told by some ISP representatives that these information is useful for them. BTW, Sun's mobileip implementation supports LPAS scenario and we will be happy to test/interoperate with any other such implementation at Connectathon, 2001. Comments ? Thanks, -Samita Chakrabarti From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Dec 20 13:39:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09517 for ; Wed, 20 Dec 2000 13:39:28 -0500 (EST) Received: from standards (47.234.32.16:3376) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4DC4@standards.nortelnetworks.com>; Wed, 20 Dec 2000 13:18:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24544 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Dec 2000 13:18:05 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4DC2@standards.nortelnetworks.com>; Wed, 20 Dec 2000 13:18:05 -0500 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04141 for ; Wed, 20 Dec 2000 10:36:26 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA11145; Wed, 20 Dec 2000 10:36:24 -0800 (PST) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA26607; Wed, 20 Dec 2000 10:36:23 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SkFvcj5cf6jFWd149zwewQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Approved-By: James Kempf Message-ID: <200012201836.KAA26607@nasnfs.eng.sun.com> Date: Wed, 20 Dec 2000 10:36:20 -0800 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Reverse Tunneling rfc and Limited Private address support X-To: Samita.Chakrabarti@eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM If the IETF rules don't allow appendicies to be binding and there is need for some additional standards action on these, then I'd say a draft is needed. jak >MIME-Version: 1.0 >Content-MD5: jN8UY+T+PYt1wI5kn8ifOw== >Approved-By: Samita Chakrabarti >Date: Wed, 20 Dec 2000 10:28:08 -0800 >From: Samita Chakrabarti >Subject: [MOBILE-IP] Reverse Tunneling rfc and Limited Private address support >X-cc: samita@jurassic.Eng.Sun.COM, gab@eng.sun.com, Basavaraj.Patil@nokia.com, qa3445@email.mot.com >To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > >A few IETFs ago, it was decided by the working group (as I was told) >to include limited private address support along with reverse tunnel >support. That means a foreign agent with advertising "T" will support >private addressed mobile nodes in a limited way. > >It was felt that extensive private address solution is not quite >necessary when the industry is moving to adopt mobile IPv6. > >Now there are some important requirements and some other guidance >went into draft-ietf-mobileip-rfc2344-bis-03.txt which is currently >in the RFC editor's queue. The requirements actually are in the >appendix section A.4. > >The basic requirements for LPAS are: > Mobile IP MUST set the 'T' bit and employ reverse tunneling. > > Foreign agents MUST support reverse tunneling in order to > support private addressed mobile nodes. If a foreign agent supports > reverse tunneling, then it MUST support the simple scenario of private > address support described in this section. > All advertising interfaces of the foreign agent MUST have > publicly routable care-of address > > Any home agent address used by mobile nodes in > registration request MUST be a publicly routable address. > >Now according to the rules, Appendix section *cannot* mandate >any requirements and since the reverse tunneling draft is now >about to become the RFC, I'd like to propose to have another >draft (either extension to reverse tunnel rfc or another form) >for these requirements. I'll be happy to produce/initiate such >draft by next IETF. > >At the San Diego IETF I was told by some ISP representatives that >these information is useful for them. > > >BTW, Sun's mobileip implementation supports LPAS scenario and we will >be happy to test/interoperate with any other such implementation >at Connectathon, 2001. > >Comments ? > > >Thanks, >-Samita Chakrabarti From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Dec 20 15:32:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13869 for ; Wed, 20 Dec 2000 15:32:33 -0500 (EST) Received: from standards (47.234.32.16:2112) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4E9A@standards.nortelnetworks.com>; Wed, 20 Dec 2000 15:12:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24836 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Dec 2000 15:12:24 -0500 Received: from gate.internaut.com (64.38.134.108:2913) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4E98@standards.nortelnetworks.com>; Wed, 20 Dec 2000 15:12:23 -0500 Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id eBKKTMC07245; Wed, 20 Dec 2000 12:29:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Approved-By: Bernard Aboba Message-ID: Date: Wed, 20 Dec 2000 12:19:47 -0800 Reply-To: Bernard Aboba Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Bernard Aboba Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for Fast Handoff Discussion X-To: James.Kempf@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200012142044.MAA08922@nasnfs.eng.sun.com> Content-Transfer-Encoding: 7bit >If we merge the proposals, I wonder if, two years from now, one of our working group chairs won't be >up on stage at the plenium giving exactly the same presentation as Randy did but for >mobile IP. >I'd therefore like to ask the working group to reconsider its hum for merging. If there's anything I've learned over the last few years in the IETF, it is that merging two proposals for the sake of "consensus" is often a very bad idea. Too frequently we end up with the worst aspects of both proposals, an outcome which is often worse than choosing one or the other. It is often better to choose one architecturally clean proposal, even if all of the "features" that are desired can't be shoehorned into it. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Dec 20 15:50:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14436 for ; Wed, 20 Dec 2000 15:50:00 -0500 (EST) Received: from standards (47.234.32.16:2112) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4EDC@standards.nortelnetworks.com>; Wed, 20 Dec 2000 15:29:52 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24927 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Dec 2000 15:29:51 -0500 Received: from gate.internaut.com (64.38.134.108:2944) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4EDA@standards.nortelnetworks.com>; Wed, 20 Dec 2000 15:29:51 -0500 Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id eBKKkoC08271; Wed, 20 Dec 2000 12:46:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Approved-By: Bernard Aboba Message-ID: Date: Wed, 20 Dec 2000 12:37:08 -0800 Reply-To: Bernard Aboba Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Bernard Aboba Subject: Re: [MOBILE-IP] authorization to issue a Binding Update for a Home Address X-To: Mohan Parthasarathy X-cc: wdixon@microsoft.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200012150208.eBF28qp11153@locked.eng.sun.com> Content-Transfer-Encoding: 7bit > 1) Phase I SA should use certificate identities > > => you mean name identifies (FQDN, user_FQDN (my favorite because > it is compatible with NAI), ...) with authentication by signatures > and X.509v3 certificates? This is the best (less worse :-) solution > today IMHO. Just a note. Most IPSEC implementations today can only handle machine authentication, not user authentication. So User_FQDN probably can only be a MAY. Also, if you use FQDN you need a way to bind the FQDN securely to an IP address of some sort (could be the home address). > 2) Phase II SA should use client identifiers to specify the HOME address. > This would establish a Phase II IPsec SA to use HOME address as the > source selector. > If you do this, you need a way of binding the home address to the identity used in IKE MM. >But the question is how does one prevent the MN from using somebody >else's home address during the phase II SA ? I agree that this >is a difficult problem but it would be good to mention this somewhere. I think you need to think this through now. It's not as simple as you might think. There are a number of security vulnerabilities that have resulted in the need to sanity check the source IP address, not just use the SPI and destination IP address. To my mind, the proposal isn't really complete -- IPSEC doesn't provide the necessary bindings by itself, and you haven't specified how they are accomplished. For example, think about the following issues: a) How is the FQDN/User_FQDN securely bound to the home address? Merely convincing someone that I'm fred.bigco.com doesn't tell them anything about what home address I'm allowed to use. Are we going to require DNSSEC to provide the binding? And is it possible to bind fred@bigco.com to a home address? Here DNSSEC won't even necessarily help you. b) If you can't accomplish this binding, what use is using the home address as the identifier in QM? Any user able to authentication in MM can then send in a bogus binding update for another authenticated user. c) How do the IPSEC correspondents sanity check the source IP addresses? To be able to do this it seems that you'd need to be able to validate the binding between FQDN/USER_FQDN and home address. By the way, if you can do this, I don't see the difference between AH and ESP in terms of security. If you can't, then neither is really secure. Can someone provide a counter example of an attack that could succeed against one and not the other? d) How is "authorization" performed? I think that this is a code name for FQDN/User_FQDN - home agent binding, but I'm not sure. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Dec 20 16:35:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16144 for ; Wed, 20 Dec 2000 16:35:07 -0500 (EST) Received: from standards (47.234.32.16:2718) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4F38@standards.nortelnetworks.com>; Wed, 20 Dec 2000 16:15:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25055 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Dec 2000 16:15:00 -0500 Received: from RRMAIL01.RADIOROUTER_NT (63.103.94.23:4445) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4F36@standards.nortelnetworks.com>; Wed, 20 Dec 2000 16:14:59 -0500 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Dec 2000 16:33:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Approved-By: George Tsirtsis Message-ID: Date: Wed, 20 Dec 2000 16:33:18 -0500 Reply-To: Bernard Aboba Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: George Tsirtsis Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for Fast H andoff Discussion To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM -----Original Message----- From: Bernard Aboba To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sent: 12/20/00 3:19 PM Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for Fast Handoff Discussion >If we merge the proposals, I wonder if, two years from now, one of our working group chairs won't be >up on stage at the plenium giving exactly the same presentation as Randy did but for >mobile IP. >I'd therefore like to ask the working group to reconsider its hum for merging. If there's anything I've learned over the last few years in the IETF, it is that merging two proposals for the sake of "consensus" is often a very bad idea. Too frequently we end up with the worst aspects of both proposals, an outcome which is often worse than choosing one or the other. It is often better to choose one architecturally clean proposal, even if all of the "features" that are desired can't be shoehorned into it. GT> True! but not if the proposals in question happen to cover different scenarios...in which case non of the two is architecturaly 'clean'. Instead a superset framework may do the trick...Even if this is not possible maybe slight extensions to one proposal may be enough to gain the main (not necessarely all) features of the other... I think this can be done in this case. George From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 21 04:22:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13878 for ; Thu, 21 Dec 2000 04:22:23 -0500 (EST) Received: from standards (47.234.32.16:4994) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC516D@standards.nortelnetworks.com>; Thu, 21 Dec 2000 4:02:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25821 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 04:02:09 -0500 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC516B@standards.nortelnetworks.com>; Thu, 21 Dec 2000 4:02:09 -0500 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eBL9KT420132; Thu, 21 Dec 2000 10:20:29 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA16252; Thu, 21 Dec 2000 10:20:28 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA27906; Thu, 21 Dec 2000 10:22:30 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Approved-By: Francis.Dupont@ENST-BRETAGNE.FR Message-ID: <200012210922.KAA27906@givry.rennes.enst-bretagne.fr> Date: Thu, 21 Dec 2000 10:22:29 +0100 Reply-To: Francis Dupont Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] comment on IKE in Mobile IPv6 X-To: Mohan Parthasarathy To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Wed, 20 Dec 2000 10:13:16 PST. <200012201813.eBKIDGt12722@locked.eng.sun.com> In your previous mail you wrote: > IKE is not different from other applications... Yes, it is no different. But what mandates the destination address to be the Home address always ? => nothing but the binding cache is transparent for any common applications so the home address will always be used. For example, MN's SA expire, bindings are valid and while neogotiating the SA, it could be the Care of address of the CN if it is mobile. => it will be the home address from the IKE point of view (and the packet will be sent with a routing header via the care-of address). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 21 05:29:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14364 for ; Thu, 21 Dec 2000 05:29:43 -0500 (EST) Received: from standards (47.234.32.16:4609) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC51D1@standards.nortelnetworks.com>; Thu, 21 Dec 2000 5:03:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25962 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 05:03:01 -0500 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC51CF@standards.nortelnetworks.com>; Thu, 21 Dec 2000 5:03:00 -0500 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eBLAJg412187; Thu, 21 Dec 2000 11:19:42 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA18159; Thu, 21 Dec 2000 11:19:42 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id LAA28156; Thu, 21 Dec 2000 11:21:43 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Approved-By: Francis.Dupont@ENST-BRETAGNE.FR Message-ID: <200012211021.LAA28156@givry.rennes.enst-bretagne.fr> Date: Thu, 21 Dec 2000 11:21:43 +0100 Reply-To: Francis Dupont Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] authorization to issue a Binding Update for a Home Address X-To: Bernard Aboba To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Wed, 20 Dec 2000 12:37:08 PST. In your previous mail you wrote: > 1) Phase I SA should use certificate identities > > => you mean name identifies (FQDN, user_FQDN (my favorite because > it is compatible with NAI), ...) with authentication by signatures > and X.509v3 certificates? This is the best (less worse :-) solution > today IMHO. Just a note. Most IPSEC implementations today can only handle machine authentication, not user authentication. => Mobile IPv6 needs only the node authentication which is provided by IPsec (user authentication and AAA is another issue). The user_FQDN is my favorite because it is in fact a NAI, ie. something which is common to mobile IP, PPP extended authentication, AAA, IPsec, ... This does not imply that we should to authenticate the user in place of the node, it is only an open door between user and node levels. So User_FQDN probably can only be a MAY. => hum, there is no list of legal identities (identity payload types) for phase 1 and 2... We are very far from a SHOULD. Also, if you use FQDN you need a way to bind the FQDN securely to an IP address of some sort (could be the home address). => this is again the authorization problem. I don't understand why this is so hard for mobile IPv6 when the problem exists for VPN too (a security gateway will give a subnet identity in phase two, this should be accepted only if the peer is authorized to be a security gateway for this subnet. The text in RFC 2409 is (near) clear about this: The identities of the SAs negotiated in Quick Mode are implicitly assumed to be the IP addresses of the ISAKMP peers, without any implied constraints on the protocol or port numbers allowed, unless client identifiers are specified in Quick Mode. If ISAKMP is acting as a client negotiator on behalf of another party, the identities of the parties MUST be passed as IDci and then IDcr. Local policy will dictate whether the proposals are acceptable for the identities specified. If the client identities are not acceptable to the Quick Mode responder (due to policy or other reasons), a Notify payload with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent. Then if the IDci or IDcr are not the address identities of the peers then local policy must authorize or not authorize them.) I can't see a real difference between mobility (different address) and VPNs (subnet), both need authorization. BTW I'd like to know how this is implemented in current IKEs (ask IPsec people?) > 2) Phase II SA should use client identifiers to specify the HOME address. > This would establish a Phase II IPsec SA to use HOME address as the > source selector. > If you do this, you need a way of binding the home address to the identity used in IKE MM. => I believe we need a bit more than a binding: an authorization. The good thing here is that we have a higher level identity and the static well-known address (ie. it will be far harder to "bind" the identity with a random care-of address). >But the question is how does one prevent the MN from using somebody >else's home address during the phase II SA ? I agree that this >is a difficult problem but it would be good to mention this somewhere. I think you need to think this through now. It's not as simple as you might think. There are a number of security vulnerabilities that have resulted in the need to sanity check the source IP address, not just use the SPI and destination IP address. => I agree, IPsec specifies the protected traffic MUST be between the negociated (in phase two) entities and mandates a check for the source address (which one and when to do the check is unfortunately implementation dependent, most implementations are compliant, many are not interoperable). To my mind, the proposal isn't really complete -- IPSEC doesn't provide the necessary bindings by itself, and you haven't specified how they are accomplished. => I agree. IPsec provides only the strong authentication, not the authorization itself. What are the IETF WGs in charge of the authorization? AAA can do it but AAA is for users, not nodes, and we wouldn't like to restrict mobility to mono-user nodes only, even this case is very common. For example, think about the following issues: a) How is the FQDN/User_FQDN securely bound to the home address? Merely convincing someone that I'm fred.bigco.com doesn't tell them anything about what home address I'm allowed to use. Are we going to require DNSSEC to provide the binding? And is it possible to bind fred@bigco.com to a home address? Here DNSSEC won't even necessarily help you. => DNSSEC and AAA are two obvious answers but none is a complete answer, ie. they can work in some (important) cases but not in all cases. They are not deployed/usable today too... (but you can answer mobility will be a good reason to deploy them quicky :-). b) If you can't accomplish this binding, what use is using the home address as the identifier in QM? Any user able to authentication in MM can then send in a bogus binding update for another authenticated user. => we already agree about the need to add authorization. c) How do the IPSEC correspondents sanity check the source IP addresses? => the mobile node source address is the care-of address and is nearly random. The only available sanity checks are trivial (for instance the mobile node should not use one of my addresses, should use an address with the proper scope, ...). To be able to do this it seems that you'd need to be able to validate the binding between FQDN/USER_FQDN and home address. By the way, if you can do this, I don't see the difference between AH and ESP in terms of security. => you need to protect both the care-of and the home addresses. If you do that with an ESP it is more expensive (you have to repeat the care-of in an alternate care-of suboption) and the source address check will fail if you have not hacked your implementation in order to support this particular case. There is a common situation where you'd like to use an ESP: you already have an ESP tunnel between the mobile node and the correspondent. I am writing a draft with Richard Draves about this important case. If you can't, then neither is really secure. Can someone provide a counter example of an attack that could succeed against one and not the other? => the choice between AH and ESP was not done according to security requirements (both can provide authentication, integrity check and anti-replay for the critical elements) but because AH is simpler (just because it was designed for this kind of applications :-) and has no known issue with compliant IPsec implementations. d) How is "authorization" performed? I think that this is a code name for FQDN/User_FQDN - home agent binding, but I'm not sure. => this is a bit more, in (poor) English this is something like "a node with this (proved) identity can use mobility with this home address". Of course the authorization between the mobile node and its home agent is critical (and easier to do, a (unscalable) static configuration works, DNSSEC or AAA or ... are simpler to setup too in this case). Thanks Francis.Dupont@enst-bretagne.fr PS: if nobody explains how to provide authorization before the end of the year I'll put a message about the issu in the IPsec mailing list. VPN is an enough important market to get a detailed answer, isn't it? From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 21 07:10:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15453 for ; Thu, 21 Dec 2000 07:10:30 -0500 (EST) Received: from standards (47.234.32.16:1442) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5253@standards.nortelnetworks.com>; Thu, 21 Dec 2000 6:50:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26131 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 06:50:22 -0500 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5251@standards.nortelnetworks.com>; Thu, 21 Dec 2000 6:50:21 -0500 Received: from esealnt406.al.sw.ericsson.se (esealnt406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id eBLC8iG04938 for ; Thu, 21 Dec 2000 13:08:44 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Dec 21 13:08:32 2000 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Thu, 21 Dec 2000 13:08:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" Approved-By: "Karim El-Malki (ERA)" Message-ID: <5F05C89FB2F8D211B6430008C79191270746033A@esealnt190> Date: Thu, 21 Dec 2000 13:08:27 +0100 Reply-To: "Karim El-Malki (ERA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Karim El-Malki (ERA)" Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for Fast H andoff Discussion To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > -----Original Message----- > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > Sent: den 20 december 2000 22:33 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Architectural v.s. Incremental > Lession for Fast > H andoff Discussion > > > -----Original Message----- > From: Bernard Aboba > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Sent: 12/20/00 3:19 PM > Subject: Re: [MOBILE-IP] Architectural v.s. Incremental > Lession for Fast > Handoff Discussion > > >If we merge the proposals, I wonder if, two years from now, > one of our > working group chairs won't be > >up on stage at the plenium giving exactly the same presentation as > Randy > did but for > >mobile IP. > > >I'd therefore like to ask the working group to reconsider its hum for > merging. > > If there's anything I've learned over the last few years in > the IETF, it > is that merging two proposals for the sake of "consensus" is > often a very > bad idea. > Too frequently we end up with the worst aspects of both proposals, an > outcome which is often worse than choosing one or the other. > It is often > better to choose one architecturally clean proposal, even if > all of the > "features" that are desired can't be shoehorned into it. > > > GT> True! but not if the proposals in question happen to > cover different > scenarios...in which case non of the two is architecturaly > 'clean'. Instead > a superset framework may do the trick...Even if this is not > possible maybe > slight extensions to one proposal may be enough to gain the main (not > necessarely all) features of the other... I think this can be > done in this > case. I don't believe such extensions are possible. There are differences between the two approaches presented at the last mtg. which prevent them from being used together (i.e. at the same time). However, I also think that the two approaches cover a wide range of scenarios. This is confirmed by the v6 handoffs work which is involving solutions equivalent to the proactive and fast h'off drafts. So a merger which involves mixing functionality from the proactive and fast drafts does not make technical sense to me. After all it seems to be clear that one approach cannot do for all situations, so the two methods of improving L3 handoffs should be maintained. Slight extensions to one of the two won't do the same. Rgds, /Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 21 09:45:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20888 for ; Thu, 21 Dec 2000 09:44:58 -0500 (EST) Received: from standards (47.234.32.16:2351) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC531B@standards.nortelnetworks.com>; Thu, 21 Dec 2000 9:24:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26394 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 09:24:42 -0500 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5319@standards.nortelnetworks.com>; Thu, 21 Dec 2000 9:24:41 -0500 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id HAA13198 for ; Thu, 21 Dec 2000 07:43:05 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id HAA13495 for ; Thu, 21 Dec 2000 07:43:04 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Thu, 21 Dec 2000 08:43:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Approved-By: Roberts Philip-qa3445 Message-ID: Date: Thu, 21 Dec 2000 08:43:02 -0600 Reply-To: Roberts Philip-qa3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Philip-qa3445 Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for Fast Handoff Discussion X-To: Bernard Aboba To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > ---------- > From: Bernard Aboba > Reply To: Bernard Aboba > Sent: Thursday, December 21, 2000 4:19 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for Fast Handoff Discussion > > >If we merge the proposals, I wonder if, two years from now, one of our > working group chairs won't be > >up on stage at the plenium giving exactly the same presentation as Randy > did but for > >mobile IP. > > >I'd therefore like to ask the working group to reconsider its hum for > merging. > > If there's anything I've learned over the last few years in the IETF, it is > that > merging two proposals for the sake of "consensus" is often a very bad idea. > Too > frequently we end up with the worst aspects of both proposals, an outcome > which > is often worse than choosing one or the other. It is often better to choose > one > architecturally clean proposal, even if all of the "features" that are > desired > can't be shoehorned into it. > > I agree with your sentiment here. I'd like to hear more discussion from the working group on a particular course of action. The design team went round on this a couple of times also. I expect to get some guidance from our AD soon and will share that with the list. In the meantime perhaps we could get some feedback on the following possibilities: 1) we've heard a few sentiments on not combining for a couple of different reasons 2) combining the two drafts seemed to have significant support within the room at San Diego 3) a third possibility that has been suggested is trying to reuse the work of the v6 design team to come up with a v4 proposal This is a good time to hear the thoughts of the working group. Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 21 10:12:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21573 for ; Thu, 21 Dec 2000 10:12:51 -0500 (EST) Received: from standards (47.234.32.16:3100) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC535D@standards.nortelnetworks.com>; Thu, 21 Dec 2000 9:52:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26484 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 09:52:38 -0500 Received: from ish7.ericsson.com.au (203.61.155.111:63015) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC535B@standards.nortelnetworks.com>; Thu, 21 Dec 2000 9:52:37 -0500 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id CAA02892 for ; Fri, 22 Dec 2000 02:07:36 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id CAA17747 for ; Fri, 22 Dec 2000 02:10:35 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Dec 2000 02:10:58 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Approved-By: "Hesham Soliman (EPA)" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613F25@eaubrnt018.epa.ericsson.se> Date: Fri, 22 Dec 2000 02:10:56 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for Fast H andoff Discussion To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello Phil and all, Generally speaking I do think that merging two solutions to simply achieve consensus is not the best way to go. In addition, the two drafts in question are based on different assumptions. However, as you said below it was expressed during the meeting that there maybe scenarios where one approach may work better than the other. Therefore, eliminating one draft completely may not be a good idea. Unless we know which assumptions will prevail in the long term we can't eliminate one of the approaches. I recall a comment about using a clairvoyant ! So I feel that we're in no position to eliminate one approach or simply mix them together. However it would be good to have both approaches in the same document and detailing the assumptions behind each one (that is if we can -I hope- agree on the assumptions). This work must be done by the authors as they know the approaches best. As to using the IPv6 outcome, I'm not sure that will be useful, I believe the IPv6 draft includes both approaches already with modifications to accomodate MIPv6. The V4 drafts are much more stable and will be required by systems sooner. The IPv6 draft will need a bit more time to get stable and will be used (on a large scale) at a later time. Regards, Hesham > I agree with your sentiment here. I'd like to hear more discussion from > the working group on a particular course of action. The design team went > round on this a couple of times also. > > I expect to get some guidance from our AD soon and will share that with > the list. > > In the meantime perhaps we could get some feedback on the following > possibilities: > 1) we've heard a few sentiments on not combining for a couple of different > reasons > 2) combining the two drafts seemed to have significant support within the > room at San Diego > 3) a third possibility that has been suggested is trying to reuse the work > of the v6 design team to come up with a v4 proposal > > This is a good time to hear the thoughts of the working group. > > Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 21 10:45:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22577 for ; Thu, 21 Dec 2000 10:45:57 -0500 (EST) Received: from standards (47.234.32.16:3100) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC53BE@standards.nortelnetworks.com>; Thu, 21 Dec 2000 10:25:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26615 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 10:25:40 -0500 Received: from RRMAIL01.RADIOROUTER_NT (63.103.94.23:1532) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC53BC@standards.nortelnetworks.com>; Thu, 21 Dec 2000 10:25:39 -0500 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Dec 2000 10:44:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Approved-By: George Tsirtsis Message-ID: Date: Thu, 21 Dec 2000 10:44:01 -0500 Reply-To: Roberts Philip-qa3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: George Tsirtsis Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for Fast H andoff Discussion X-To: Roberts Philip-qa3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Phil, I think another approach would be to take one of the proposals and see if it can be extended...rather than trying to fully combine the two. In particular, I think that the FA assisted proposal can be made more widely applicable if you allow the source and destination triggers to be IP layer messages when the Link Layer does not provide this functionality. This BTW would give this proposal one of the main features of the other one...i.e.: indepedence from link layers.... George -----Original Message----- From: Roberts Philip-qa3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sent: 12/21/00 9:43 AM Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for Fast Handoff Discussion ... I expect to get some guidance from our AD soon and will share that with the list. In the meantime perhaps we could get some feedback on the following possibilities: 1) we've heard a few sentiments on not combining for a couple of different reasons 2) combining the two drafts seemed to have significant support within the room at San Diego 3) a third possibility that has been suggested is trying to reuse the work of the v6 design team to come up with a v4 proposal This is a good time to hear the thoughts of the working group. Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 21 11:32:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23545 for ; Thu, 21 Dec 2000 11:32:55 -0500 (EST) Received: from standards (47.234.32.16:3100) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5458@standards.nortelnetworks.com>; Thu, 21 Dec 2000 11:12:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26812 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 11:12:37 -0500 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5456@standards.nortelnetworks.com>; Thu, 21 Dec 2000 11:12:36 -0500 Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id eBLGV0426417 for ; Thu, 21 Dec 2000 17:31:00 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Dec 21 17:30:59 2000 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 21 Dec 2000 17:28:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Karim El-Malki (ERA)" Message-ID: <5F05C89FB2F8D211B6430008C791912707460340@esealnt190> Date: Thu, 21 Dec 2000 17:30:51 +0100 Reply-To: "Karim El-Malki (ERA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Karim El-Malki (ERA)" Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for Fast H andoff Discussion To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi George > I think another approach would be to take one of the > proposals and see if it > can be extended...rather than trying to fully combine the two. > > In particular, I think that the FA assisted proposal can be > made more widely > applicable if you allow the source and destination triggers > to be IP layer > messages when the Link Layer does not provide this > functionality. This BTW > would give this proposal one of the main features of the > other one...i.e.: > indepedence from link layers.... The two solutions can't work together as you are saying. You can either use the Mobile IP Registration from the MN in Fast Handoffs or the inter-FA messaging in Proactive Handoffs so I can't see a reason for having both at the same time. However a document describing the two alternatives would be a good solution. In any case I think we decided that the authors of the two proposals would get together and talk about this again following the feedback from the WG. Rgds, /Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 21 11:40:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23783 for ; Thu, 21 Dec 2000 11:40:53 -0500 (EST) Received: from standards (47.234.32.16:3100) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5494@standards.nortelnetworks.com>; Thu, 21 Dec 2000 11:17:57 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26893 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 11:17:56 -0500 Received: from mgw-dax2.ext.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5492@standards.nortelnetworks.com>; Thu, 21 Dec 2000 11:17:56 -0500 Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eBLGb6603888 for ; Thu, 21 Dec 2000 10:37:06 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 21 Dec 2000 10:36:16 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Thu, 21 Dec 2000 10:36:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Approved-By: Basavaraj.Patil@NOKIA.COM Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E6D1@daeis07nok> Date: Thu, 21 Dec 2000 10:32:03 -0600 Reply-To: Basavaraj.Patil@nokia.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for Fast H andoff Discussion To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM The possibilities suggested for the v4 handoff design work: >In the meantime perhaps we could get some feedback on the following >possibilities: >1) we've heard a few sentiments on not combining for a couple of >different reasons Just combining the I-Ds may not provide the desired solution for handoffs. What really needs to be done is to evaluate the scenarios (current and possible future) and apply the handoff solutions currently being proposed to these and determine if there are gaps and shortcomings. >2) combining the two drafts seemed to have significant support within >the room at San Diego The idea here was to combine the two proposals by the design team as a start. Revision 0 would then be made available to the WG as a whole and hopefully have WG members evaluate, critic and contribute to the I-D to make it applicable to other scenarios. Subsequent revisions of the I-D should produce a WG document that has consensus and includes a complete solution. However I am still not sure if this approach will get the results we hope for in the short term. >3) a third possibility that has been suggested is trying to reuse the >work of the v6 design team to come up with a v4 proposal Rather than just reusing the v6 design team proposal, the intent should be for the v4 and v6 design teams to ensure that both proposals are tackling all handoff cases and scenarios and are working from the same set of requirements and assumptions. -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 21 11:47:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23947 for ; Thu, 21 Dec 2000 11:47:31 -0500 (EST) Received: from standards (47.234.32.16:3100) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC54C6@standards.nortelnetworks.com>; Thu, 21 Dec 2000 11:23:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26963 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 11:23:19 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC54C4@standards.nortelnetworks.com>; Thu, 21 Dec 2000 11:23:19 -0500 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA17941; Thu, 21 Dec 2000 08:41:43 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA19936; Thu, 21 Dec 2000 08:41:42 -0800 (PST) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA29422; Thu, 21 Dec 2000 08:41:41 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: HiWr0U97meMRc23p+N9cOg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Approved-By: James Kempf Message-ID: <200012211641.IAA29422@nasnfs.eng.sun.com> Date: Thu, 21 Dec 2000 08:41:39 -0800 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for Fast H andoff Discussion X-To: Karim.El-Malki@era.ericsson.se To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >> GT> True! but not if the proposals in question happen to >> cover different >> scenarios...in which case non of the two is architecturaly >> 'clean'. Instead >> a superset framework may do the trick...Even if this is not >> possible maybe >> slight extensions to one proposal may be enough to gain the main (not >> necessarely all) features of the other... I think this can be >> done in this >> case. > >I don't believe such extensions are possible. There are differences >between the two approaches presented at the last mtg. which prevent >them from being used together (i.e. at the same time). However, I also >think that the two approaches cover a wide range of scenarios. This is >confirmed by the v6 handoffs work which is involving solutions equivalent >to the proactive and fast h'off drafts. So a merger which involves mixing >functionality from the proactive and fast drafts does not make technical >sense to me. After all it seems to be clear that one approach cannot do >for all situations, so the two methods of improving L3 handoffs should be >maintained. Slight extensions to one of the two won't do the same. > > I agree with Karim here, but rather advocate that the working group should decide, not split the difference. The fundamental difference between the two proposals are that the proactive draft makes no assumptions about packet delivery after L2 at the old FA has decided to do handoff and before L2 at the new FA has completed handoff, whereas the Hesham/Karim draft does. In realistic deployment, I don't think such assumptions can be made. One could, I suppose, argue that the Hesham/Karim draft could be used when there is no L2 support for informing the FA that a handoff is about to take place, but, in such situations, I think that standard mobile IP is the best one can do. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 21 11:51:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24140 for ; Thu, 21 Dec 2000 11:51:49 -0500 (EST) Received: from standards (47.234.32.16:3100) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC551E@standards.nortelnetworks.com>; Thu, 21 Dec 2000 11:30:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27086 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 11:30:36 -0500 Received: from patan.sun.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC551C@standards.nortelnetworks.com>; Thu, 21 Dec 2000 11:30:36 -0500 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21738; Thu, 21 Dec 2000 08:49:00 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA21262; Thu, 21 Dec 2000 08:48:59 -0800 (PST) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA29649; Thu, 21 Dec 2000 08:48:58 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: FEf3Nggb9e8ukZB/6/KNzg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Approved-By: James Kempf Message-ID: <200012211648.IAA29649@nasnfs.eng.sun.com> Date: Thu, 21 Dec 2000 08:48:56 -0800 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for Fast Handoff Discussion X-To: Philip_Roberts-qa3445@email.mot.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Phil, >In the meantime perhaps we could get some feedback on the following possibilities: >1) we've heard a few sentiments on not combining for a couple of different reasons` >2) combining the two drafts seemed to have significant support within the room at San Diego >3) a third possibility that has been suggested is trying to reuse the work of the v6 design team to come up with a v4 proposal > There were some significant technical objections to some of the the proposed IPv6 extensions raised during the meeting. In particular, the need for a binding update and binding reply over the old link after L2 at the old mobility router has detected the need for a handoff and started one is problematic. I do not believe one can guarantee L2 connectivity after L2 has decided a handoff is necessary. I would actually rather propose the opposite, that the IPv6 take a hard look and winnow down their proposals to ones that have a realistic chance of working, rather than trying to split the difference for purposes of concensus. In the final analysis, the *real* test in all this is "running code." If the Hesham/Karim proposal and the IPv6 proposal for signalling over L2 during handoff works, then lets include it in the drafts. If not, then lets drop them. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 21 11:51:50 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24143 for ; Thu, 21 Dec 2000 11:51:49 -0500 (EST) Received: from standards (47.234.32.16:3100) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5538@standards.nortelnetworks.com>; Thu, 21 Dec 2000 11:32:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27122 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 11:32:33 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5536@standards.nortelnetworks.com>; Thu, 21 Dec 2000 11:32:33 -0500 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA20844; Thu, 21 Dec 2000 08:50:57 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA21595; Thu, 21 Dec 2000 08:50:56 -0800 (PST) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA29708; Thu, 21 Dec 2000 08:50:51 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: UBJWPFSYSuGRrqF9U7mAww== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Approved-By: James Kempf Message-ID: <200012211650.IAA29708@nasnfs.eng.sun.com> Date: Thu, 21 Dec 2000 08:50:49 -0800 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for Fast H andoff Discussion X-To: Philip_Roberts-qa3445@email.mot.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM George, >I think another approach would be to take one of the proposals and see if it >can be extended...rather than trying to fully combine the two. > >In particular, I think that the FA assisted proposal can be made more widely >applicable if you allow the source and destination triggers to be IP layer >messages when the Link Layer does not provide this functionality. This BTW >would give this proposal one of the main features of the other one...i.e.: >indepedence from link layers.... > In fact, the discussion about using the 802.11 IPP prior to the San Diego meeting would do precisely that. However, IPP may need some extensions (if these are not already in the protocol, the spec I have is 2 years old). jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 21 12:00:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24442 for ; Thu, 21 Dec 2000 12:00:39 -0500 (EST) Received: from standards (47.234.32.16:3100) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5558@standards.nortelnetworks.com>; Thu, 21 Dec 2000 11:35:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27165 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 11:35:05 -0500 Received: from ish7.ericsson.com.au (203.61.155.111:64082) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5556@standards.nortelnetworks.com>; Thu, 21 Dec 2000 11:35:04 -0500 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id DAA04914 for ; Fri, 22 Dec 2000 03:49:47 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id DAA22547 for ; Fri, 22 Dec 2000 03:52:47 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Dec 2000 03:53:09 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Approved-By: "Hesham Soliman (EPA)" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613F26@eaubrnt018.epa.ericsson.se> Date: Fri, 22 Dec 2000 03:53:08 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for Fast H andoff Discussion To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > I agree with Karim here, but rather advocate that the working group should > decide, not split the difference. > => Agreed. I also think we should state the assumptions and possible use scenarios in one document that mentions both solutions. > The fundamental difference between the two proposals are that the > proactive > draft makes no assumptions about packet delivery after L2 at the old FA > has decided to do handoff and before L2 at the new FA has completed > handoff, > whereas the Hesham/Karim draft does. In realistic deployment, I don't > think > such assumptions can be made. > => I'm actually a bit tired of saying the same think all over again, so excuse me if I don't answer that. But let me just say that the Fast Handoffs draft makes no assumptions about how MIP signalling can be mapped onto radio channells in a partcular cellular system. If you read that statement carefully you'll se how specific and short lived an assumption like that is. There are ways of mapping MIP signlling in an efficient manner on these channells. > One could, I suppose, argue that the Hesham/Karim > draft could be used when there is no L2 support for informing the FA that > => True, the Fast Handoffs draft can be used in this case also. > a handoff is about to take place, but, in such situations, I think that > standard mobile IP is the best one can do. > => The Fast Handoffs draft _IS_ standard MIP with some behavioural optimisations and without changing the protocol. The anticipation combined with simultaneuos bindings is just a behavioural optimisation of RFC2002. Hesham From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 21 12:05:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24627 for ; Thu, 21 Dec 2000 12:05:27 -0500 (EST) Received: from standards (47.234.32.16:3100) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC55E0@standards.nortelnetworks.com>; Thu, 21 Dec 2000 11:45:08 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27357 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 11:45:08 -0500 Received: from cisco.com (shako.cisco.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC55DE@standards.nortelnetworks.com>; Thu, 21 Dec 2000 11:45:07 -0500 Received: (from msubbara@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA01155 for mobile-ip@standards.nortelnetworks.com; Thu, 21 Dec 2000 12:03:21 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Approved-By: Madhavi Subbarao Message-ID: <20001221120321.A961@cisco.com> Date: Thu, 21 Dec 2000 12:03:21 -0500 Reply-To: Madhavi Subbarao Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Madhavi Subbarao Subject: [MOBILE-IP] NAI and MN-HA authentication To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM HI All, We are proposing a Binding ID as a way to obtain multiple dynamic IP addresses with a single NAI (draft should be announced soon.) In looking at the behavior of the FA in RFC 2794 (MIP NAI ext), it seems that MN-HA authentication is dubious in some scenarios. Under certain circumstances, the FA is changing the error code of the Registration Reply before forwarding it to the MN. But, now authentication will fail at the MN. Since the MN will attempt to re-register, all is not lost except that the MN will continually try with the same HA. Is this behavior intentional? -Madhavi From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 21 13:29:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26701 for ; Thu, 21 Dec 2000 13:29:16 -0500 (EST) Received: from standards (47.234.32.16:4614) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5688@standards.nortelnetworks.com>; Thu, 21 Dec 2000 13:08:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27586 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 13:08:39 -0500 Received: from patan.sun.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5686@standards.nortelnetworks.com>; Thu, 21 Dec 2000 13:08:39 -0500 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01247; Thu, 21 Dec 2000 10:26:55 -0800 (PST) Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA17160; Thu, 21 Dec 2000 10:26:54 -0800 (PST) Received: (from mohanp@localhost) by locked.eng.sun.com (8.10.1+Sun/8.10.1) id eBLIPiQ13150; Thu, 21 Dec 2000 10:25:44 -0800 (PST) X-Sun-Charset: US-ASCII Approved-By: Mohan Parthasarathy Message-ID: <200012211825.eBLIPiQ13150@locked.eng.sun.com> Date: Thu, 21 Dec 2000 10:25:44 -0800 Reply-To: Mohan Parthasarathy Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohan Parthasarathy Subject: Re: [MOBILE-IP] authorization to issue a Binding Update for a Home Address X-To: aboba@internaut.com X-cc: wdixon@microsoft.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > > 2) Phase II SA should use client identifiers to specify the HOME > address. > > This would establish a Phase II IPsec SA to use HOME address as the > > source selector. > > > > If you do this, you need a way of binding the home address to the identity > used in IKE MM. > Yes. If i had a policy that says "Phase II identity should be 10.1.1.2 for X@example.com in Phase I", what prevents IKE from verifying that Phase I and Phase II matches the above policy ? The question of how this policy is obtained by any arbitrary CN is a separate and important problem i guess. Even the IPsec architecture document does not describe authorization well. If a Security gateway is representing some set of hosts H1, H2 etc how does any other host verify that the security gateway is authorized to represent H1. Refer to section 4.6.3 in RFC 2401. > >But the question is how does one prevent the MN from using somebody > >else's home address during the phase II SA ? I agree that this > >is a difficult problem but it would be good to mention this somewhere. > > I think you need to think this through now. It's not as simple as you > might think. There are a number of security vulnerabilities that have > resulted in the need to sanity check the source IP address, not just use > the SPI and destination IP address. To my mind, the proposal isn't really > complete -- IPSEC doesn't provide the necessary > bindings by itself, and you haven't specified how they are accomplished. > > For example, think about the following issues: > > a) How is the FQDN/User_FQDN securely bound to the home address? Merely > convincing someone that I'm fred.bigco.com doesn't tell them anything about > what home address I'm allowed to use. Are we going to require DNSSEC to > provide the binding? And is it possible to bind fred@bigco.com to a > home address? Here DNSSEC won't even necessarily help you. > > b) If you can't accomplish this binding, what use is using the home > address as the identifier in QM? Any user able to authentication in MM > can then send in a bogus binding update for another authenticated user. > > c) How do the IPSEC correspondents sanity check the source IP addresses? > > To be able to do this it seems that you'd need to be able to validate > the binding between FQDN/USER_FQDN and home address. By the way, if you > can do this, I don't see the difference between AH and ESP in terms of > security. If you can't, then neither is really secure. Can someone provide > a counter example of an attack that could succeed against one and not the > other? > > d) How is "authorization" performed? > > I think that this is a code name for FQDN/User_FQDN - home agent binding, > but I'm not sure. > All your problems are valid, may be we should include the IPsec folks in the discussion. -mohan From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 21 14:17:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27971 for ; Thu, 21 Dec 2000 14:17:44 -0500 (EST) Received: from standards (47.234.32.16:4614) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC571A@standards.nortelnetworks.com>; Thu, 21 Dec 2000 13:57:32 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27789 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 13:57:31 -0500 Received: from mailhost.iprg.nokia.com (205.226.5.12:49710) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5718@standards.nortelnetworks.com>; Thu, 21 Dec 2000 13:57:31 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA20174; Thu, 21 Dec 2000 11:15:55 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id eBLJFrk06913; Thu, 21 Dec 2000 11:15:53 -0800 X-Virus-Scanned: Thu, 21 Dec 2000 11:15:53 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from maxdialin2.iprg.nokia.com (205.226.20.232, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdk4ikmK; Thu, 21 Dec 2000 11:15:46 PST X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <200012211648.IAA29649@nasnfs.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Charlie Perkins Message-ID: <3A42567C.2AFFFE1B@iprg.nokia.com> Date: Thu, 21 Dec 2000 11:14:04 -0800 Reply-To: Charlie Perkins Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Charlie Perkins Organization: Nokia Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for FastHandoff Discussion X-To: James Kempf To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Jim, > There were some significant technical objections to some of the the proposed IPv6 > extensions raised during the meeting. In particular, the need for a binding > update and binding reply over the old link after L2 at the old mobility > router has detected the need for a handoff and started one is problematic. > I do not believe one can guarantee L2 connectivity after L2 has decided a > handoff is necessary. Then this results from a misunderstanding. We allow but do not require these messages. If they are supplied, then in some scenarios the handoff can be faster. If the network initiates the handover, these messages are not needed to initiate the fast handover. I believe that everyone in the IPv6 design team would quite agree with your assessment about whether L2 can be relied upon for the delivery of the messages. > I would actually rather propose the opposite, that the IPv6 take a hard look > and winnow down their proposals to ones that have a realistic chance of working, > rather than trying to split the difference for purposes of concensus. We did not split the difference. We decided which scenarios needed work, and designed messages to support those scenarios. Generally, the same messages are used in the different scenarios, but perhaps applied in different orders. > In the final analysis, the *real* test in all this is "running code." If the > Hesham/Karim proposal and the IPv6 proposal for signalling over L2 during > handoff works, then lets include it in the drafts. If not, then lets drop them. There is running code, to within a certain degree of imprecision caused by changes from the design team. I think that we should have one solution per problem. Different ways of applying layer-2 triggers result in different problems. We cannot expect that layer-2 triggers will be applied in the same way in all future systems, so it is very prudent to determine which problems need solving, and look for as many common denominators as we can find. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 21 14:52:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28707 for ; Thu, 21 Dec 2000 14:52:15 -0500 (EST) Received: from standards (47.234.32.16:4614) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC57A3@standards.nortelnetworks.com>; Thu, 21 Dec 2000 14:32:08 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27983 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 14:32:07 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC57A1@standards.nortelnetworks.com>; Thu, 21 Dec 2000 14:32:07 -0500 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA18067; Thu, 21 Dec 2000 11:50:28 -0800 (PST) Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA12945; Thu, 21 Dec 2000 11:50:27 -0800 (PST) Received: (from mohanp@localhost) by locked.eng.sun.com (8.10.1+Sun/8.10.1) id eBLJnHB13710; Thu, 21 Dec 2000 11:49:17 -0800 (PST) X-Sun-Charset: US-ASCII Approved-By: Mohan Parthasarathy Message-ID: <200012211949.eBLJnHB13710@locked.eng.sun.com> Date: Thu, 21 Dec 2000 11:49:17 -0800 Reply-To: Mohan Parthasarathy Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohan Parthasarathy Subject: Re: [MOBILE-IP] authorization to issue a Binding Update for a Home Address X-To: Francis.Dupont@enst-bretagne.fr To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Also, if you use FQDN you need a way to bind the FQDN securely > to an IP address of some sort (could be the home address). > > => this is again the authorization problem. I don't understand why > this is so hard for mobile IPv6 when the problem exists for VPN too > (a security gateway will give a subnet identity in phase two, this > should be accepted only if the peer is authorized to be a security > gateway for this subnet. The text in RFC 2409 is (near) clear about this: > > The identities of the SAs negotiated in Quick Mode are implicitly > assumed to be the IP addresses of the ISAKMP peers, without any > implied constraints on the protocol or port numbers allowed, unless > client identifiers are specified in Quick Mode. If ISAKMP is acting > as a client negotiator on behalf of another party, the identities of > the parties MUST be passed as IDci and then IDcr. Local policy will > dictate whether the proposals are acceptable for the identities > specified. If the client identities are not acceptable to the Quick > Mode responder (due to policy or other reasons), a Notify payload > with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent. > > Then if the IDci or IDcr are not the address identities of the peers > then local policy must authorize or not authorize them.) > I can't see a real difference between mobility (different address) and > VPNs (subnet), both need authorization. BTW I'd like to know how > this is implemented in current IKEs (ask IPsec people?) > There is no difference. But unless there is a rich policy semantics which says "Accept Phase II identity as X for phase I identity as Y", it is difficult to do the binding. Moreover, how does the CN get this policy information ? > > 2) Phase II SA should use client identifiers to specify the HOME > address. > > This would establish a Phase II IPsec SA to use HOME address as the > > source selector. > > > > If you do this, you need a way of binding the home address to the identity > used in IKE MM. > > => I believe we need a bit more than a binding: an authorization. > The good thing here is that we have a higher level identity and the > static well-known address (ie. it will be far harder to "bind" the > identity with a random care-of address). > How does one get to this information database ? -mohan From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 21 15:39:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29997 for ; Thu, 21 Dec 2000 15:39:28 -0500 (EST) Received: from standards (47.234.32.16:4614) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5831@standards.nortelnetworks.com>; Thu, 21 Dec 2000 15:19:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28174 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 15:19:05 -0500 Received: from RRMAIL01.RADIOROUTER_NT (63.103.94.23:2113) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC582F@standards.nortelnetworks.com>; Thu, 21 Dec 2000 15:19:05 -0500 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Dec 2000 15:37:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Approved-By: George Tsirtsis Message-ID: Date: Thu, 21 Dec 2000 15:37:26 -0500 Reply-To: Charlie Perkins Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: George Tsirtsis Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for FastHa ndoff Discussion To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM May I just second Charlie's comments and remind the obvious...we create technologies for the Internet not for a specific L2... George -----Original Message----- From: Charlie Perkins To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sent: 12/21/00 2:14 PM Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for FastHandoff Discussion Hello Jim, > There were some significant technical objections to some of the the proposed IPv6 > extensions raised during the meeting. In particular, the need for a binding > update and binding reply over the old link after L2 at the old mobility > router has detected the need for a handoff and started one is problematic. > I do not believe one can guarantee L2 connectivity after L2 has decided a > handoff is necessary. Then this results from a misunderstanding. We allow but do not require these messages. If they are supplied, then in some scenarios the handoff can be faster. If the network initiates the handover, these messages are not needed to initiate the fast handover. I believe that everyone in the IPv6 design team would quite agree with your assessment about whether L2 can be relied upon for the delivery of the messages. > I would actually rather propose the opposite, that the IPv6 take a hard look > and winnow down their proposals to ones that have a realistic chance of working, > rather than trying to split the difference for purposes of concensus. We did not split the difference. We decided which scenarios needed work, and designed messages to support those scenarios. Generally, the same messages are used in the different scenarios, but perhaps applied in different orders. > In the final analysis, the *real* test in all this is "running code." If the > Hesham/Karim proposal and the IPv6 proposal for signalling over L2 during > handoff works, then lets include it in the drafts. If not, then lets drop them. There is running code, to within a certain degree of imprecision caused by changes from the design team. I think that we should have one solution per problem. Different ways of applying layer-2 triggers result in different problems. We cannot expect that layer-2 triggers will be applied in the same way in all future systems, so it is very prudent to determine which problems need solving, and look for as many common denominators as we can find. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 21 15:51:50 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00438 for ; Thu, 21 Dec 2000 15:51:50 -0500 (EST) Received: from standards (47.234.32.16:4614) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5889@standards.nortelnetworks.com>; Thu, 21 Dec 2000 15:31:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28295 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 15:31:31 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5887@standards.nortelnetworks.com>; Thu, 21 Dec 2000 15:31:31 -0500 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA02504; Thu, 21 Dec 2000 12:49:54 -0800 (PST) Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA08939; Thu, 21 Dec 2000 12:49:52 -0800 (PST) Received: (from mohanp@localhost) by locked.eng.sun.com (8.10.1+Sun/8.10.1) id eBLKmhJ13734; Thu, 21 Dec 2000 12:48:43 -0800 (PST) X-Sun-Charset: US-ASCII Approved-By: Mohan Parthasarathy Message-ID: <200012212048.eBLKmhJ13734@locked.eng.sun.com> Date: Thu, 21 Dec 2000 12:48:43 -0800 Reply-To: Mohan Parthasarathy Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohan Parthasarathy Subject: Re: [MOBILE-IP] authorization to issue a Binding Update for a Home Address X-To: Francis.Dupont@enst-bretagne.fr To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > => this is again the authorization problem. I don't understand why > this is so hard for mobile IPv6 when the problem exists for VPN too > (a security gateway will give a subnet identity in phase two, this > should be accepted only if the peer is authorized to be a security > gateway for this subnet. The text in RFC 2409 is (near) clear about this: > > The identities of the SAs negotiated in Quick Mode are implicitly > assumed to be the IP addresses of the ISAKMP peers, without any > implied constraints on the protocol or port numbers allowed, unless > client identifiers are specified in Quick Mode. If ISAKMP is acting > as a client negotiator on behalf of another party, the identities of > the parties MUST be passed as IDci and then IDcr. Local policy will > dictate whether the proposals are acceptable for the identities > specified. If the client identities are not acceptable to the Quick > Mode responder (due to policy or other reasons), a Notify payload > with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent. > > Then if the IDci or IDcr are not the address identities of the peers > then local policy must authorize or not authorize them.) > I can't see a real difference between mobility (different address) and > VPNs (subnet), both need authorization. BTW I'd like to know how > this is implemented in current IKEs (ask IPsec people?) > At least the trust model is different here. If you trust SG's identity in Phase I, you trust its Phase II identity also. I have heard that some people just use wildcards and accept any phase II identity. In the mobile IP case, it is very different. -mohan > > 2) Phase II SA should use client identifiers to specify the HOME > address. > > This would establish a Phase II IPsec SA to use HOME address as the > > source selector. > > > > If you do this, you need a way of binding the home address to the identity > used in IKE MM. > > => I believe we need a bit more than a binding: an authorization. > The good thing here is that we have a higher level identity and the > static well-known address (ie. it will be far harder to "bind" the > identity with a random care-of address). > > >But the question is how does one prevent the MN from using somebody > >else's home address during the phase II SA ? I agree that this > >is a difficult problem but it would be good to mention this somewhere. > > I think you need to think this through now. It's not as simple as you > might think. There are a number of security vulnerabilities that have > resulted in the need to sanity check the source IP address, not just use > the SPI and destination IP address. > > => I agree, IPsec specifies the protected traffic MUST be between the > negociated (in phase two) entities and mandates a check for the source > address (which one and when to do the check is unfortunately implementation > dependent, most implementations are compliant, many are not interoperable). > > To my mind, the proposal isn't really complete -- IPSEC doesn't provide > the necessary bindings by itself, and you haven't specified how > they are accomplished. > > => I agree. IPsec provides only the strong authentication, not the > authorization itself. What are the IETF WGs in charge of the authorization? > AAA can do it but AAA is for users, not nodes, and we wouldn't like > to restrict mobility to mono-user nodes only, even this case is very common. > > For example, think about the following issues: > > a) How is the FQDN/User_FQDN securely bound to the home address? Merely > convincing someone that I'm fred.bigco.com doesn't tell them anything about > what home address I'm allowed to use. Are we going to require DNSSEC to > provide the binding? And is it possible to bind fred@bigco.com to a > home address? Here DNSSEC won't even necessarily help you. > > => DNSSEC and AAA are two obvious answers but none is a complete answer, > ie. they can work in some (important) cases but not in all cases. > They are not deployed/usable today too... (but you can answer mobility > will be a good reason to deploy them quicky :-). > > b) If you can't accomplish this binding, what use is using the home > address as the identifier in QM? Any user able to authentication in MM > can then send in a bogus binding update for another authenticated user. > > => we already agree about the need to add authorization. > > c) How do the IPSEC correspondents sanity check the source IP addresses? > > => the mobile node source address is the care-of address and is nearly > random. The only available sanity checks are trivial (for instance the > mobile node should not use one of my addresses, should use an address > with the proper scope, ...). > > To be able to do this it seems that you'd need to be able to validate > the binding between FQDN/USER_FQDN and home address. By the way, if you > can do this, I don't see the difference between AH and ESP in terms of > security. > > => you need to protect both the care-of and the home addresses. If you do > that with an ESP it is more expensive (you have to repeat the care-of in > an alternate care-of suboption) and the source address check will fail > if you have not hacked your implementation in order to support this > particular case. > There is a common situation where you'd like to use an ESP: you already > have an ESP tunnel between the mobile node and the correspondent. > I am writing a draft with Richard Draves about this important case. > > If you can't, then neither is really secure. Can someone provide > a counter example of an attack that could succeed against one and not the > other? > > => the choice between AH and ESP was not done according to security > requirements (both can provide authentication, integrity check and > anti-replay for the critical elements) but because AH is simpler > (just because it was designed for this kind of applications :-) > and has no known issue with compliant IPsec implementations. > > d) How is "authorization" performed? > > I think that this is a code name for FQDN/User_FQDN - home agent binding, > but I'm not sure. > > => this is a bit more, in (poor) English this is something like > "a node with this (proved) identity can use mobility with this home address". > Of course the authorization between the mobile node and its home agent > is critical (and easier to do, a (unscalable) static configuration works, > DNSSEC or AAA or ... are simpler to setup too in this case). > > Thanks > > Francis.Dupont@enst-bretagne.fr > > PS: if nobody explains how to provide authorization before the end of the year > I'll put a message about the issu in the IPsec mailing list. VPN is an > enough important market to get a detailed answer, isn't it? > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 21 16:09:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00896 for ; Thu, 21 Dec 2000 16:09:15 -0500 (EST) Received: from standards (47.234.32.16:4614) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC58F3@standards.nortelnetworks.com>; Thu, 21 Dec 2000 15:49:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28443 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 15:49:03 -0500 Received: from patan.sun.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC58F1@standards.nortelnetworks.com>; Thu, 21 Dec 2000 15:49:03 -0500 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07625; Thu, 21 Dec 2000 13:07:27 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA23211; Thu, 21 Dec 2000 13:07:26 -0800 (PST) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA08627; Thu, 21 Dec 2000 13:07:25 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: sWMShXg/ypH/G5rtflAOyw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Approved-By: James Kempf Message-ID: <200012212107.NAA08627@nasnfs.eng.sun.com> Date: Thu, 21 Dec 2000 13:07:24 -0800 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for FastHandoff Discussion X-To: charliep@IPRG.nokia.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Charlie, >> In the final analysis, the *real* test in all this is "running code." If the >> Hesham/Karim proposal and the IPv6 proposal for signalling over L2 during >> handoff works, then lets include it in the drafts. If not, then lets drop them. > >There is running code, to within a certain degree of imprecision caused >by changes from the design team. I think that we should have one solution >per problem. Different ways of applying layer-2 triggers result in different >problems. We cannot expect that layer-2 triggers will be applied in the >same way in all future systems, so it is very prudent to determine which >problems need solving, and look for as many common denominators as >we can find. > Are you speaking for Hesham and Karim here or yourself? If for yourself, then would it be possible to get some information the implementations? Like which MIPv6 proposals were implemented on which L2s, what the probability of droppage for IPv6 signalling is for the IPv6 proposals that involve L3 signalling during a handoff (i.e. after L2 at the old point of connectivity has decided a handoff is necessary) and what L2s these probabilities correspond to? Also, what is the amount of time needed to perform the handoff? W.r.t. the latter, a proposal before 3GPP2 at the Kauai meeting cites 80 ms as the amount of time required for existing CDMA hard handoff. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 22 06:14:45 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28248 for ; Fri, 22 Dec 2000 06:14:44 -0500 (EST) Received: from standards (47.234.32.16:4390) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5B91@standards.nortelnetworks.com>; Fri, 22 Dec 2000 5:54:29 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29319 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Dec 2000 05:54:28 -0500 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5B8F@standards.nortelnetworks.com>; Fri, 22 Dec 2000 5:54:28 -0500 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eBMBCq425368; Fri, 22 Dec 2000 12:12:52 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA06205; Fri, 22 Dec 2000 12:12:51 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id MAA33268; Fri, 22 Dec 2000 12:14:58 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Approved-By: Francis.Dupont@ENST-BRETAGNE.FR Message-ID: <200012221114.MAA33268@givry.rennes.enst-bretagne.fr> Date: Fri, 22 Dec 2000 12:14:58 +0100 Reply-To: Francis Dupont Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] authorization to issue a Binding Update for a Home Address X-To: Mohan Parthasarathy To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Thu, 21 Dec 2000 11:49:17 PST. <200012211949.eBLJnHB13710@locked.eng.sun.com> In your previous mail you wrote: There is no difference. But unless there is a rich policy semantics which says "Accept Phase II identity as X for phase I identity as Y", it is difficult to do the binding. Moreover, how does the CN get this policy information ? => I believe the best way to do this is to put this in the certificate (ie. a certificate policy saying "for mobility" and the home address in another subject alternative name). But this is just an idea, there is no accurate specifications (yet) nor a beginning of deployment. I'd like to know how this is done in VPNs... Perhaps there is a simpler solution already in use? Thanks Francis.Dupont@enst-bretagne.fr PS: this is a IPsec topic, no more a mobile IP one. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 22 06:26:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28398 for ; Fri, 22 Dec 2000 06:26:55 -0500 (EST) Received: from standards (47.234.32.16:4390) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5BEE@standards.nortelnetworks.com>; Fri, 22 Dec 2000 6:06:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29446 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Dec 2000 06:06:38 -0500 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5BEC@standards.nortelnetworks.com>; Fri, 22 Dec 2000 6:06:37 -0500 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id eBMBP1419968; Fri, 22 Dec 2000 12:25:01 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA06483; Fri, 22 Dec 2000 12:25:01 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id MAA33361; Fri, 22 Dec 2000 12:27:08 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Approved-By: Francis.Dupont@ENST-BRETAGNE.FR Message-ID: <200012221127.MAA33361@givry.rennes.enst-bretagne.fr> Date: Fri, 22 Dec 2000 12:27:08 +0100 Reply-To: Francis Dupont Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] authorization to issue a Binding Update for a Home Address X-To: Mohan Parthasarathy To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Thu, 21 Dec 2000 12:48:43 PST. <200012212048.eBLKmhJ13734@locked.eng.sun.com> In your previous mail you wrote: > Then if the IDci or IDcr are not the address identities of the peers > then local policy must authorize or not authorize them.) > I can't see a real difference between mobility (different address) and > VPNs (subnet), both need authorization. BTW I'd like to know how > this is implemented in current IKEs (ask IPsec people?) > At least the trust model is different here. If you trust SG's identity in Phase I, you trust its Phase II identity also. => this can be true only if all peers provide the same security service (same level, same domain). In other cases (different levels and/or different domains) a peer can get some priviledges dedicated to another peer (ie. there is a big hole in security). I have heard that some people just use wildcards and accept any phase II identity. => I believe they don't accept any peer, ie. they give the same security to a well known (and small) set of peers, and reject other peers. In the mobile IP case, it is very different. => you can configure the same kind of policy, ie. accept a small set of mobile nodes without protection between them (ie. one can impersonate another one). This can be acceptable on the home agent (this is what I use in tests) but this doesn't scale for correspondents (ie. routing optimizations will be lost). I believe VPN people have (better) solutions... Regards Francis.Dupont@enst-bretagne.fr PS: please move to IPsec mailing list. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Dec 23 14:16:37 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06120 for ; Sat, 23 Dec 2000 14:16:36 -0500 (EST) Received: from standards (47.234.32.16:1476) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC601F@standards.nortelnetworks.com>; Sat, 23 Dec 2000 13:56:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30723 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 23 Dec 2000 13:56:04 -0500 Received: from cs.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC601D@standards.nortelnetworks.com>; Sat, 23 Dec 2000 13:55:58 -0500 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA07864 for ; Sat, 23 Dec 2000 14:14:28 -0500 (EST) X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------3EDB08F6227094BA7F2BF67B" Approved-By: hgs@CS.COLUMBIA.EDU Message-ID: <3A44F995.8457A7AF@cs.columbia.edu> Date: Sat, 23 Dec 2000 14:14:29 -0500 Reply-To: "Henning G. Schulzrinne" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University Subject: [MOBILE-IP] CFP: 2nd IP Telephony Workshop To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------3EDB08F6227094BA7F2BF67B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs --------------3EDB08F6227094BA7F2BF67B Content-Type: text/plain; charset=iso-8859-1; name="cfp.txt" Content-Disposition: inline; filename="cfp.txt" Content-Transfer-Encoding: 8bit Call for Papers 2nd IP Telephony Workshop April 2-3, 2001 - Columbia University, New York City http://www.fokus.gmd.de/events/iptel2001/ Objectives ---------- Internet telephony is rapidly evolving from research to design and deployment. The objectives of the IP Telephony Workshop are to bring together researchers, developers, vendors and service providers active in this area and stimulate discussion on innovation, research, implementation, deployment experiences and future directions. Scope & Topics -------------- Original technical articles related to IP telephony are solicited. Only papers with significant technical content, not "white papers" or tutorials, will be considered for publication: - Research papers (unique ideas, novel algorithms, architectures, measurements, theoretical and/or analytical contributions) - Surveys, state-of-the-art studies, technology comparisons - Implementation and deployment reports - Standardization reports Particular areas of interest include, but are not limited to, the following: - Integration with Internet services (e.g., web, instant messaging, games) - Added-value services (e.g., call centers, conferencing) - Mobility and 3rd generation wireless - Authentication, authorization, accounting, charging, settlement - QoS support - Security (e.g., privacy, authentication, certification authorities, firewall traversal) - Call signaling & processing - Feature creation - Supporting services (e.g., call routing, lookup services) - Audio & video encoding and transmission - Management and provisioning - Interworking with the PSTN - Design and deployment considerations (e.g., performance, scalability, reliability) Important Dates --------------- Full paper due February 10th, 2001 Notification of acceptance March 15th, 2001 Final version due March 25th, 2001 Program published and March 15th, 2001 registration opens Workshop April 2nd-3rd, 2001 iptel2001 Organizing Committee ------------------------------ Program Chair H. Schulzrinne Columbia University Program Committee M. Arango Sun Microsystems F. Baker Cisco W. Bauerfeld T-Nova G. Bond AT&T Research S. Bradner Harvard University G. Carle GMD FOKUS J. Crowcroft UCL C. Huitema Microsoft G. S. Kuo National Central University, Taiwan J. Kuthan GMD Fokus T. Magedanz IKV++ GmbH W. Marshall AT&T Research D. Medhi University of Missouri-Kansas City D. Oran Cisco J. Ott University of Bremen T. La Porta Bell Labs B. Rosen Marconi J. Rosenberg dynamicsoft H. Sinnreich MCI WorldCom R. Steinmetz Technical University of Darmstadt H. St?ttgen NEC CCRLE W. Wimmreuter Siemens L. Wolf University of Karlsruhe A. Wolisz Technical University of Berlin M. Zitterbart Technical University of Braunschweig Submission Instructions ----------------------- Authors are invited to submit full papers written in English before February 10, 2001. The submissions will be reviewed, and accepted papers will be included in the program. Notifications of acceptance will be sent out on January 12th, 2000. Deadline for submission of camera-ready copies is January 31st, 2001. Authors of accepted papers will need to sign a Copyright Transfer Form and submit a Netbib entry. Papers must be submitted electronically using the Web site at http://www.cs.columbia.edu/iptel Submissions must be in PDF or Postscript; any other documents cannot be accepted. Postscript papers must use only standard PostScript fonts: Times Roman, Courier, Symbol, and Helvetica. Papers must be formatted according to the IEEE Transactions format except for the font size, which MUST be 11pt. Templates are available at the Web site http://www.fokus.gmd.de/events/iptel2001/cfp/ Because of the size limitation on the final manuscript, and to ensure that the reviewed paper and the final version have a similar size, papers with more than 11 pages cannot be reviewed. Submissions must include: title, authors, affiliation, abstract, list of keywords, and contact information. One of the authors of each accepted paper must present the paper at iptel'2001. Contact Address --------------- Please, send all your inquiries regarding iptel2001 to iptel2001@egroups.com. --------------3EDB08F6227094BA7F2BF67B-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Dec 24 09:38:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07973 for ; Sun, 24 Dec 2000 09:38:17 -0500 (EST) Received: from standards (47.234.32.16:2368) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC61AF@standards.nortelnetworks.com>; 24 Dec 2000 9:17:47 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31186 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 24 Dec 2000 09:17:47 -0500 Received: from public2.bta.net.cn by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC61AD@standards.nortelnetworks.com>; 24 Dec 2000 9:17:46 -0500 Received: from gaolan ([202.106.42.102]) by public2.bta.net.cn (8.9.3/8.9.91) with SMTP id WAA20418 for ; Sun, 24 Dec 2000 22:36:14 +0800 (GMT) References: <200012221127.MAA33361@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Approved-By: Gao Lan Message-ID: <000d01c06db7$6aa7d2c0$160a060a@atmdomain> Date: Sun, 24 Dec 2000 22:37:04 +0800 Reply-To: Gao Lan Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gao Lan Subject: [MOBILE-IP] unsubscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA07973 unsubscribe From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Dec 26 07:14:46 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18478 for ; Tue, 26 Dec 2000 07:14:46 -0500 (EST) Received: from standards (47.234.32.16:1978) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC658A@standards.nortelnetworks.com>; Tue, 26 Dec 2000 6:54:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32394 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Dec 2000 06:54:06 -0500 Received: from hotmail.com (f22.law10.hotmail.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC6588@standards.nortelnetworks.com>; Tue, 26 Dec 2000 6:54:06 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Dec 2000 04:12:44 -0800 Received: from 128.125.229.11 by lw10fd.law10.hotmail.msn.com with HTTP; Tue, 26 Dec 2000 12:12:44 GMT X-Originating-IP: [128.125.229.11] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 26 Dec 2000 12:12:44.0650 (UTC) FILETIME=[271C74A0:01C06F35] Approved-By: Saumitra Buragohain Message-ID: Date: Tue, 26 Dec 2000 04:12:44 -0800 Reply-To: saumitra_bg@yahoo.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Saumitra Buragohain Subject: [MOBILE-IP] unsubscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM unsunscribe _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 28 01:56:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07574 for ; Thu, 28 Dec 2000 01:55:59 -0500 (EST) Received: from standards (47.234.32.16:1287) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC6A46@standards.nortelnetworks.com>; Thu, 28 Dec 2000 1:35:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34048 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Dec 2000 01:35:15 -0500 Received: from stsl.siemens.com.tw (192.72.45.189:58218) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC6A44@standards.nortelnetworks.com>; Thu, 28 Dec 2000 1:35:14 -0500 Received: from stslex.siemens.com.tw (stslex [192.72.45.13]) by stsl.siemens.com.tw (8.9.1/8.9.1) with ESMTP id PAA25985 for ; Thu, 28 Dec 2000 15:02:43 +0800 (CST) Received: by stslex.siemens.com.tw with Internet Mail Service (5.5.2448.0) id ; Thu, 28 Dec 2000 14:55:37 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0709B.2EC2A988" Approved-By: Moter Du Message-ID: Date: Thu, 28 Dec 2000 14:55:33 +0800 Reply-To: Moter Du Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Moter Du Subject: [MOBILE-IP] MIPv6 (issue 13): Rate Limiting for Sending Binding Updates To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0709B.2EC2A988 Content-Type: text/plain; charset="BIG5" Section 10.10 specifies a MN should use a value for the initial retransmission timer that is at least 1.5 times longer than (RetransTimer * DupAddrDetectTransmits), that is 1.5s for initial retransmission timer. The retransmission must use an exponential back-off process, in which the timeout period is doubled upon each retransmission. Therefore, for the first time home registration, the sequence of retransmission timer will be 1.5s, 3s, 6s, 12s, 24s, ..., 256s. However, section 10.11 specifies after sending MAX_FAST_UPDATES consecutive BU to a particular node with the same CoA, the MN should reduce its rate of sending BU, to the rate of SLOW_UPDATE_RATE per second. It looks to me these 2 sections make a new but confusing requirment. Assume a MN sends BU for the first time home registration but somehow does not receive BAck, the sequence of retransmission timer will be 1.5s, 3s, 6s, 12s, 10s, 10s, .... Doesn't this look confusing? Or did I miss anything? Appreciate any advice. Sincerely Moter Du ============================================================ Moter Du D410, Siemens STSL phone +886 2 25186011 Fax +886 2 25053866 mailto:moter_du@stsl.siemens.com.tw ============================================================ ------_=_NextPart_001_01C0709B.2EC2A988 Content-Type: text/html; charset="BIG5" Content-Transfer-Encoding: quoted-printable MIPv6 (issue 13): Rate Limiting for Sending Binding = Updates

Section 10.10 specifies a MN should use a value for = the initial retransmission timer that is at least 1.5 times longer than = (RetransTimer * DupAddrDetectTransmits), that is 1.5s for initial = retransmission timer.  The retransmission must use an exponential = back-off process, in which the timeout period is doubled upon each = retransmission.  Therefore, for the first time home registration, = the sequence of retransmission timer will be 1.5s, 3s, 6s, 12s, 24s, = ..., 256s.

However, section 10.11 specifies after sending = MAX_FAST_UPDATES consecutive BU to a particular node with the same CoA, = the MN should reduce its rate of sending BU, to the rate of = SLOW_UPDATE_RATE per second.

It looks to me these 2 sections make a new but = confusing requirment.  Assume a MN sends BU for the first time = home registration but somehow does not receive BAck, the sequence of = retransmission timer will be 1.5s, 3s, 6s, 12s, 10s, 10s, ....  = Doesn't this look confusing? Or did I miss anything?

Appreciate any advice.

        Sincerely =
        Moter = Du
 
        = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
        Moter = Du           &nbs= p;           &nbs= p;          D410, Siemens = STSL
        = phone   +886 2 25186011
        = Fax     +886 2 25053866
        mailto:moter_du@stsl.siemen= s.com.tw
        =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=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------_=_NextPart_001_01C0709B.2EC2A988-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Dec 28 21:22:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21349 for ; Thu, 28 Dec 2000 21:22:37 -0500 (EST) Received: from standards (47.234.32.16:3660) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC6B48@standards.nortelnetworks.com>; Thu, 28 Dec 2000 21:02:00 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34374 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Dec 2000 21:01:59 -0500 Received: from ms.samsung.com (211.45.29.136:49883) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC6B46@standards.nortelnetworks.com>; Thu, 28 Dec 2000 21:01:59 -0500 Received: from keg ([203.241.48.20]) by ms.samsung.com (Netscape Messaging Server 4.15) with SMTP id G6B54100.DBB for ; Fri, 29 Dec 2000 11:19:13 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Approved-By: Woo-June Kim Message-ID: <002601c0713d$6d5366e0$88b2d5a5@keg.telecom.samsung.co.kr> Date: Fri, 29 Dec 2000 11:17:00 +0900 Reply-To: Woo-June Kim Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Woo-June Kim Subject: Re: [MOBILE-IP] NAI and MN-HA authentication To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA21349 Hi, Until I see the draft, not much to say, but... >We are proposing a Binding ID as a way to obtain multiple dynamic IP addresses with a single NAI (draft >should be announced soon.) In looking at the behavior of the FA in RFC 2794 (MIP NAI ext), it seems that >MN-HA authentication is dubious in some scenarios. Under certain circumstances, the FA is changing >the error code of the Registration Reply before forwarding it to the MN. But, now authentication >will fail at the MN. If the FA denies the registration, the MN_HA authentication should not be checked by the MN. (cf. RFC2002-bis) > Since the MN will attempt to re-register, all is not lost except that the MN >will continually try with the same HA. > I guess the point you are making is that if there is a problem with the HA, such that it does 1) not include the NAi ext, 2) not include nonzero HA address, or 3) not include nonzero Mobile's home address the end user will continuously go to the same HA. Repeating history ! But this really can't be helped can it ? It's a problem with the HA implementation... Of the 4 error codes that are possible except for NONZERO_HOMEADDR_REQD, the other 3 (MISSING_NAI, MISSING_HOME_AGENT, MISSING_HOMEADDR) could only of occured if the HA messed up. So the mobile should intelligently handle this case by trying to connect with another HA. (Or more exactly maybe it should be the FA ?) cheers Woojune Kim Samsung Electronics e-mail : wjkim@samsung.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 29 02:28:29 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07144 for ; Fri, 29 Dec 2000 02:28:29 -0500 (EST) Received: from standards (47.234.32.16:4689) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC6C16@standards.nortelnetworks.com>; Fri, 29 Dec 2000 2:07:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34617 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 29 Dec 2000 02:07:40 -0500 Received: from stsl.siemens.com.tw (192.72.45.189:50470) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC6C14@standards.nortelnetworks.com>; Fri, 29 Dec 2000 2:07:25 -0500 Received: from stslex.siemens.com.tw (stslex [192.72.45.13]) by stsl.siemens.com.tw (8.9.1/8.9.1) with ESMTP id PAA11415 for ; Fri, 29 Dec 2000 15:35:03 +0800 (CST) Received: by stslex.siemens.com.tw with Internet Mail Service (5.5.2448.0) id ; Fri, 29 Dec 2000 15:27:55 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07168.DC4FBE88" Approved-By: Moter Du Message-ID: Date: Fri, 29 Dec 2000 15:27:53 +0800 Reply-To: Moter Du Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Moter Du Subject: [MOBILE-IP] Mobile Node multicast group membership control messages To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C07168.DC4FBE88 Content-Type: text/plain; charset="BIG5" Could anyone please instruct me where I can find references for "multicast group membership control messages" mentioned in MIPv6 specification? Thanks. Sincerely Moter Du ============================================================ Moter Du D410, Siemens STSL phone +886 2 25186011 Fax +886 2 25053866 mailto:moter_du@stsl.siemens.com.tw ============================================================ ------_=_NextPart_001_01C07168.DC4FBE88 Content-Type: text/html; charset="BIG5" Content-Transfer-Encoding: quoted-printable MIPv6 (issue 13): Rate Limiting for Sending Binding = Updates
Could anyone please instruct me where = I can find=20 references for "multicast group membership control messages" mentioned = in MIPv6=20 specification?  Thanks.

      Sincerely=20
      Moter=20 Du

      =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=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
      Moter=20 = Du           &nbs= p;           &nbs= p;         =20 D410, Siemens STSL
      phone   +886 2 25186011
      Fax     +886 2 = 25053866=20
      mailto:moter_du@stsl.siemen= s.com.tw=20
      =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=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20

 

------_=_NextPart_001_01C07168.DC4FBE88-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Dec 29 09:23:28 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09447 for ; Fri, 29 Dec 2000 09:23:27 -0500 (EST) Received: from standards (47.234.32.16:2239) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC6C8A@standards.nortelnetworks.com>; Fri, 29 Dec 2000 9:02:51 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34765 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 29 Dec 2000 09:02:51 -0500 Received: from localhost.ipunplugged.com (195.42.212.161:22162) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC6C88@standards.nortelnetworks.com>; Fri, 29 Dec 2000 9:02:50 -0500 Received: from fredrikj (c8.localhost.ipunplugged.com [192.168.4.207]) by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id PAA25256 for ; Fri, 29 Dec 2000 15:21:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Approved-By: Fredrik Johansson Message-ID: Date: Fri, 29 Dec 2000 15:24:01 +0100 Reply-To: Fredrik Johansson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fredrik Johansson Subject: [MOBILE-IP] AAA Registration Keys for MIP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, Just a question and a reminder about the AAA key distribution for MIP. draft-ietf-mobileip-aaa-key-01.txt has expired and a new one need to be turned in before the interop. If I'm not misstaken, Pat has allready taken care of this, or it is in the pipe. However, I have a question that migth cause some modification (or explanation). The draft enables keys to be distributed for use between a mobile node and a home agent, but what will the MN use in its first registration. MN-HA Auth is mandatory? But the MN does not have any key (maybe not even a HA). The draft does not say anything about it, should a "dummy" value be used, if so, the home agent has to know not to process it. Or should it be that the MN-HA Auth is not mandatory when the MN is authenticated using MN-AAA. In this case, will the HA will trust the AAA since it receives a MN-HA key which is encrypted with a shared secret between the HA and the AAA server? Happy New Year /Fredrik ---------------------------------------------------------------------------- ------- Fredrik Johansson W: +46 (0)8 725 5916 Interactive People Unplugged M: +46 (0)70 786 5035 mailto:fredrik.johansson@ipunplugged.com http://www.ipunplugged.com