From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 06:13:44 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10980 for ; Tue, 1 Feb 2000 06:13:43 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0FB7E370@standards.nortelnetworks.com>; Tue, 1 Feb 2000 6:10:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17230 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 06:08:44 -0500 Received: from ecbull20.frec.bull.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6599E3D0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 5:58:44 -0500 Received: from isatis.frec.bull.fr (isatis.frec.bull.fr [129.183.144.1]) by ecbull20.frec.bull.fr (8.9.2/8.9.1) with ESMTP id MAA62136; Tue, 1 Feb 2000 12:00:44 +0100 Received: from bull.net (localhost [127.0.0.1]) by isatis.frec.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id MAA84624; Tue, 1 Feb 2000 12:00:44 +0100 (NFT) X-Mailer: Mozilla 4.06 [en] (X11; I; AIX 4.2) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3896BCDB.AA355852@bull.net> Date: Tue, 1 Feb 2000 12:00:43 +0100 Reply-To: Aime.Le-Rouzic@BULL.NET Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: AIme Le-Rouzic Organization: Bull Subject: [MOBILE-IP] draft-ietf-mobileip-ipv6-09 comments about HA or COA for SA establishment X-To: dbj@cs.cmu.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, Dave In a common project with INRIA (Francis Dupont's code), France Telecom and Bull we are experimenting Mobile IPv6 and IPSEC. We have a problem to configure / establish the security associations(SA). The issue was raised by Itojun and Francis Dupont but is not yet fixed in the I-D (draft-ietf-mobileip-ipv6-09.txt). (Do we have to use care-of-address (COA) or home address (HA) as SA selectors?) If we do with the COA address, every time the mobile moves a new SA will have to be established. If we do with the HA address, it will not work if the destination with the HA option header is placed behind of the ESP if both authentication and encryption are used. Could the next I-D precise to put the HA destination option in front of the security header like the routing header is. In transport mode, which is the mode the mobile host uses, the user will be able to protect data by encryption. What is the difficulty with that? In that case, we will be able to access the HA address when ESP is used in transport mode. The HA header could still be authenticated (useful for integrity). It will simplify the Mobile IPv6 implementation and useability. The HA address will be available for Firewalls and other configuration mechanisms. It should help Mobile IPv6 to be more successful by helping the user to securize his data what it will want to do when outside his home network. Best regards. PS: Dave, I let you forward this mail to other lists if necessary(ipsec, ipng). -- ________________________Aime LEROUZIC____________________________ BULL S.A ECHIROLLES FRANCE mailto:Aime.Lerouzic@frec.bull.fr http://www-frec.bull.com tel: +33 (0)4 76 29 75 51 Communications TCPIP http://intranet/lerouzic From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 11:38:14 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24436 for ; Tue, 1 Feb 2000 11:38:13 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.676597C0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 11:35:13 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17606 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 11:33:52 -0500 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.36EE5DC0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 11:33:52 -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 LAA16936 for ; Tue, 1 Feb 2000 11:35:55 -0500 (EST) 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 Message-ID: <389738AF.DA146B3C@comet.columbia.edu> Date: Tue, 1 Feb 2000 11:49:03 -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: [MOBILE-IP] Mobile Wireless Internet Forum To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I thought this might be of interested to the group since I have not come across this before: http://www.mwif.org/ Their mission, to drive an open internet-based architecture that enables seamless integration of mobile telephony and IP-based services (voice, data, video, web, etc.) for the mobile wireless networks and is independent of the air interface. But I thought we have that: Mobile IP! Even though this is an operator initiated forum a certain vendor close to our IP hearts seems to be a driving force. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 16:12:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03828 for ; Tue, 1 Feb 2000 16:12:34 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C01D4630@standards.nortelnetworks.com>; Tue, 1 Feb 2000 16:09:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17931 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 16:08:34 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.31442BF0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 15:58:34 -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 NAA16215; Tue, 1 Feb 2000 13:00:20 -0800 (PST) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.95.34]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id NAA23430; Tue, 1 Feb 2000 13:00:15 -0800 (PST) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA01593; Tue, 1 Feb 2000 13:00:14 -0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 1 Feb 2000 13:00:14 -0800 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum X-To: campbell@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <389738AF.DA146B3C@comet.columbia.edu> Their goal is not protocol design. Their goal is to come up with an architecture that will be used for 3rd generation cellular networks, and some of us are making sure that Mobile IP is the mobility protocol used. PatC > I thought this might be of interested to the > group since I have not come across this > before: > > http://www.mwif.org/ > > Their mission, > > to drive an open internet-based > architecture that enables seamless integration > of mobile telephony and IP-based services (voice, > data, video, web, etc.) for the mobile wireless > networks and is independent of the air interface. > > But I thought we have that: Mobile IP! > > Even though this is an operator initiated forum > a certain vendor close to our IP hearts > seems to be a driving force. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 1 18:44:20 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09868 for ; Tue, 1 Feb 2000 18:44:19 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FA1A3220@standards.nortelnetworks.com>; Tue, 1 Feb 2000 18:41:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18209 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 1 Feb 2000 18:40:16 -0500 Received: from paul-milea-jr (38.26.155.106) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.621BC8E0@standards.nortelnetworks.com>; Tue, 1 Feb 2000 18:30:15 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 1 Feb 2000 18:40:16 -0500 Reply-To: "Paul J.Milea jr." Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Paul J.Milea jr." Subject: [MOBILE-IP] WANTED .....quantity of Cellular Telephones ! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM If this email has reached you by error please forgive the intrusion. Type "remove" in the subject line and hit send and I will promptlty remove you from any future mailings .Please accept my sincerest apology.I am sorry if I have inconvenienced you in any way. Dear Sir(s),Ms.,Mrs., I have a client looking for a large quantity of Ericcson M/N 688 Cellular Telephones. They must not be locked,white box,in English ,extra battery and charger. Please contact me immediateley if you can provide these or similar or know of any one who can .If you are able to provide please send best price on this quantity,FOB point,type of packaging,what is included (type charger,type battery,etc.),send email or fax 315 463 4337 in the USA. Also I am interested in any TDMA or other types of cellular phones in quantity ,with prices you may have . Brand & Model Number Quantities Motorola V3688 5,000 Nokia Model # 6110 5,000 Nokia Model # 3210 5,000 Nokia Model # 5110 5,000 Nokia Model # 6150 5,000 Nokia Model # 8810 5,000 Thank You,Paul J. Milea Jr. 1 (315) 374-1560 fax 1 (315) 463-4337 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 00:20:41 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16510 for ; Wed, 2 Feb 2000 00:20:41 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F7DFEE30@standards.nortelnetworks.com>; Wed, 2 Feb 2000 0:18:02 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18427 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 00:17:38 -0500 Received: from zmamail02.zma.compaq.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.83AE67E0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 0:07:38 -0500 Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 53137287; Wed, 2 Feb 2000 00:09:43 -0500 (EST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 0494D268; Wed, 2 Feb 2000 00:09:42 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id AAA0000020030; Wed, 2 Feb 2000 00:09:42 -0500 (EST) X-Mts: smtp Message-ID: <200002020509.AAA0000020030@quarry.zk3.dec.com> Date: Wed, 2 Feb 2000 00:09:41 -0500 Reply-To: Jim Bound Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jim Bound Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of "Tue, 01 Feb 2000 13:00:14 PST." >Their goal is not protocol design. Their goal is to come up with an >architecture that will be used for 3rd generation cellular networks, and some >of us are making sure that Mobile IP is the mobility protocol used. Good glad to hear it. We need some common sense here. TCP/IP should be the vehicle to bring us to the next generation of distributed computing ergo mobility not non-ietf fixes. Of course I think you should do it with IPv6 and just bypass IPv4 completely. IPv6 mobility is far superior in its capabilities. thx /jim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 01:11:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17746 for ; Wed, 2 Feb 2000 01:11:58 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1AFD7A20@standards.nortelnetworks.com>; Wed, 2 Feb 2000 1:09:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18550 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 01:07:12 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D5C17A60@standards.nortelnetworks.com>; Wed, 2 Feb 2000 1:07:11 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id WAA21660; Tue, 1 Feb 2000 22:09:16 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id WAA12423; Tue, 1 Feb 2000 22:09:12 -0800 X-Virus-Scanned: Tue, 1 Feb 2000 22:09:12 -0800 Nokia Silicon Valley AntiVirus Appliance Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma012340; Tue, 1 Feb 00 22:09:09 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3897CA05.AB047534@iprg.nokia.com> Date: Tue, 1 Feb 2000 22:09:09 -0800 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: [MOBILE-IP] Length of Challenge data X-cc: Pat Calhoun , Phil Roberts , Basavaraj Patil To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, The current Challenge draft states that the length of the Challenge data MUST be at least 16 bytes. As it turns out, this extension is useful for purposes that do not require such long challenge data. Thus, I would like to adjust this language to allow shorter data. I hope this does not amount to a significant change, so that we can continue the existing Last Call. I do not remember that anyone ever made a case for this one way or another, and the strong language in the current draft appeared there without any real discussion to support it. I would just make the appropriate changes to the IANA considerations that have already been suggested, and make this change also, as the draft goes under consideration at the IESG. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 07:05:27 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03560 for ; Wed, 2 Feb 2000 07:05:26 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.72491470@standards.nortelnetworks.com>; Wed, 2 Feb 2000 7:02:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18672 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 07:00:43 -0500 Received: from ingate.uk.neceur.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D2DC0CE0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 6:50:42 -0500 Received: from internal-mail.uk.neceur.com by ingate.uk.neceur.com id ghP00WV6OYZZj1; Wed, 2 Feb 2000 11:50:16 GMT Received: from tokyo.ttd.neceur.com by internal-mail.uk.neceur.com id B3e30OV6OY3g11; Wed, 2 Feb 2000 11:50:15 GMT from tokyo.ttd.neceur.com (localhost [127.0.0.1]) id B3e30OV6OY3g11 (3.3.2/3.1.31); Wed, 2 Feb 2000 11:50:15 GMT Received: by tokyo.ttd.neceur.com with Internet Mail Service (5.5.1960.3) id ; Wed, 2 Feb 2000 11:49:39 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Message-ID: <3B9AA5E712DCD011AAD500609770A0E9203879@tokyo.ttd.neceur.com> Date: Wed, 2 Feb 2000 11:49:34 -0000 Reply-To: "BINAR, Simon" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "BINAR, Simon" Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum X-To: Jim Bound To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM | >Their goal is not protocol design. Their goal is to come up with an | >architecture that will be used for 3rd generation cellular | networks, and some | >of us are making sure that Mobile IP is the mobility protocol used. | | Good glad to hear it. We need some common sense here. | TCP/IP should be | the vehicle to bring us to the next generation of distributed | computing | ergo mobility not non-ietf fixes. | | Of course I think you should do it with IPv6 and just bypass IPv4 | completely. IPv6 mobility is far superior in its capabilities. Questions: - Many mobile operators will already have some form of IPv4 networks. How do you evolve these networks towards IPv6, ensuring that mobility can consistently be supported over both IPv4 and IPv6 platforms? Or do you support mobility only over the small IPv6 portion, and gradually increase "mobility coverage" as the IPv4 platform is being replaced by the IPv6 one? Would this second approach be satisfactory to operators and users alike? - How do you support "legacy" IPv4 terminals in a MIPv6 cellular network? (I don't think requiring the terminals to upgrade will be acceptable in every case) - Should terminals roaming between legacy IPv4 and next-generation IPv6 mobile networks be required to implement both the IPv4 and IPv6, and MIPv4 and MIPv6 protocol stacks? What impact would such a requirement have on those terminals (e.g., handheld devices) that by definition have a limited amount of processing capabilities and memory? - How do you suppport non-MIP terminals (e.g., both 2G and "first generation" 3G terminals)? I also think that MIPv6 is a nice thing to have, but do we have answers to these questions? I think answers would be quite important, otherwise, it might be difficult to convince operators to go straight away for MIPv6... Or are these issues not important to operators?? Simon | | thx | /jim | From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 10:17:49 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12024 for ; Wed, 2 Feb 2000 10:17:47 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.53662C80@standards.nortelnetworks.com>; Wed, 2 Feb 2000 10:14:44 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18933 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 10:13:12 -0500 Received: from smtpgw1.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1C549420@standards.nortelnetworks.com>; Wed, 2 Feb 2000 10:13:11 -0500 Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw1.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id JAA10133 for ; Wed, 2 Feb 2000 09:15:17 -0600 (CST) Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 Feb 2000 09:15:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 2 Feb 2000 09:15:13 -0600 Reply-To: "Lipford, Mark" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lipford, Mark" Subject: Re: [MOBILE-IP] Length of Challenge data To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Charlie, I am not aware of an issue (from my perspective) with making this change, my concern is keeping the I-D on last call as you have indicated. TR45.6 has a need to get this I-D into RFC state soon. Regards. -----Original Message----- From: Charles E. Perkins [mailto:charliep@IPRG.NOKIA.COM] Sent: Wednesday, February 02, 2000 12:09 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] Length of Challenge data Hello, The current Challenge draft states that the length of the Challenge data MUST be at least 16 bytes. As it turns out, this extension is useful for purposes that do not require such long challenge data. Thus, I would like to adjust this language to allow shorter data. I hope this does not amount to a significant change, so that we can continue the existing Last Call. I do not remember that anyone ever made a case for this one way or another, and the strong language in the current draft appeared there without any real discussion to support it. I would just make the appropriate changes to the IANA considerations that have already been suggested, and make this change also, as the draft goes under consideration at the IESG. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 17:41:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23062 for ; Wed, 2 Feb 2000 17:41:54 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.62C1B7B0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 17:38:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19775 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 17:37:10 -0500 Received: from zmamail01.zma.compaq.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.21C9A330@standards.nortelnetworks.com>; Wed, 2 Feb 2000 17:37:09 -0500 Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 56AA81EB; Wed, 2 Feb 2000 17:39:13 -0500 (EST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 183AA1F0; Wed, 2 Feb 2000 17:39:13 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id RAA0000005835; Wed, 2 Feb 2000 17:39:12 -0500 (EST) X-Mts: smtp Message-ID: <200002022239.RAA0000005835@quarry.zk3.dec.com> Date: Wed, 2 Feb 2000 17:39:12 -0500 Reply-To: Jim Bound Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jim Bound Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum X-To: "BINAR, Simon" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of "Wed, 02 Feb 2000 11:49:34 GMT." <3B9AA5E712DCD011AAD500609770A0E9203879@tokyo.ttd.neceur.com> | Of course I think you should do it with IPv6 and just bypass IPv4 | completely. IPv6 mobility is far superior in its capabilities. Note above I stated really don't even to IPv4 for 3GPP. So I am assuming with my answers below IPv4 is legacy pre 3GPP for this discussion. >Questions: >- Many mobile operators will already have some form of IPv4 networks. Agreed. >How do you evolve these networks towards IPv6, ensuring that mobility >can consistently be supported over both IPv4 and IPv6 platforms? Or do >you support mobility only over the small IPv6 portion, and gradually >increase "mobility coverage" as the IPv4 platform is being replaced by >the IPv6 one? Would this second approach be satisfactory to operators >and users alike? I can't speak for operators OK I can only speak as an engineer who builds products. But there will be a transition set of problems for legacy equipment but I would hope that if 3GPP moves to IPv6 then it would treat the IPv4 legacy environment as a place to tunnel thru. We should identify that equipment that will exist at the point 3GPP begins deployment? What I am suggesting is that the various forums assume IPv6 for the addresses for all 3GPP mobile nodes first of all. When mobile hits the Internet pipe from the Celluar world it will run into IPv4 and that is where tunnels and other v6 trans mechanisms would be used to get to the recipient (e.g. home agent, hlr, CN, mobile web servers). But within the Celluar infrastructure IPv6 is assumed. So 3GPP would be deployed gradually as it became available along side the pre-3GPP infrastructure until it replaced the IPv4 old parts. Celluar mobility has the advantage that we don't have for existing non-mobile Internet users and that is, it is not widely deployed ( I am speaking here of MNs that have the capability to access data (content) via 3GPP). So after all that yes the idea is to replace Ipv4 equipment with Ipv6 equipment. The business benefits must support this for sure and that is not my forte, and I plead ignorance in this space. >- How do you support "legacy" IPv4 terminals in a MIPv6 cellular >network? (I don't think requiring the terminals to upgrade will be >acceptable in every case) If they cannot be upgraded with an IPv6 they have to be replaced. I personally will not advocate to any customer to use a NAT with IPv4 equipment for Mobility. They loose all the benefits of IPv6 without an IPv6 stack. But I think we may be talking new parts with 3GPP anyway. >- Should terminals roaming between legacy IPv4 and next-generation IPv6 >mobile networks be required to implement both the IPv4 and IPv6, and >MIPv4 and MIPv6 protocol stacks? What impact would such a requirement >have on those terminals (e.g., handheld devices) that by definition have >a limited amount of processing capabilities and memory? No only the new ones. When they roam and begin execution in the IPv4 network they use IPv4. >- How do you suppport non-MIP terminals (e.g., both 2G and "first >generation" 3G terminals)? If they cannot upgrade to MIP6 then they don't participate in MIPv6. >I also think that MIPv6 is a nice thing to have, but do we have answers >to these questions? I think answers would be quite important, otherwise, >it might be difficult to convince operators to go straight away for >MIPv6... Or are these issues not important to operators?? I think also are these answers important to the vendors in their markets but clearly we need to have more discussion. I will tell you one thing. If a department deploys IPv6 servers in their network and IPv6 clients and an ISV upgrades their application to take advantage of Ipv6 parts the legacy IPv4 nodes can't take advantage of the new features of IPv6 apps unless they can upgrade to IPv6 too. This is a hard line and reality with most new technology. regards, /jim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 19:16:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23990 for ; Wed, 2 Feb 2000 19:16:59 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AFCFBF90@standards.nortelnetworks.com>; Wed, 2 Feb 2000 19:14:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19924 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 19:13:26 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.94FFBC10@standards.nortelnetworks.com>; Wed, 2 Feb 2000 19:13: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 QAA20642 for ; Wed, 2 Feb 2000 16:15:28 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs-201.Eng.Sun.COM [129.146.201.28]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA16257 for ; Wed, 2 Feb 2000 16:15:26 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp2.Central.Sun.COM [129.147.36.137]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id QAA12474 for ; Wed, 2 Feb 2000 16:15:22 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-ID: <200002030015.QAA12474@nasnfs.eng.sun.com> Date: Wed, 2 Feb 2000 16:13:43 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: [MOBILE-IP] Issues with draft-ietf-mobileip-3gwireless-ext-02.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit All, I was looking at this draft today and noticed that it makes use of the Key field in the GRE header. I was recently informed that the new GRE I-D targetted to replace the Informational RFC, is in last call, and no longer contains the Key field. The Key field is required for the Mobile-IP draft, and therefore will not be able to support the standards track version of the GRE protocol (draft-meyer-gre-update-03.txt). I would urge anyone that cares about this draft to make your issues known to the IESG before the GRE last call expires. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 20:55:42 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24789 for ; Wed, 2 Feb 2000 20:55:42 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C602DB00@standards.nortelnetworks.com>; Wed, 2 Feb 2000 19:36:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19999 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 19:34:42 -0500 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8D2E8400@standards.nortelnetworks.com>; Wed, 2 Feb 2000 19:34:41 -0500 Received: (from gdommety@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA16789; Wed, 2 Feb 2000 16:36:47 -0800 (PST) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200002030036.QAA16789@omega.cisco.com> Date: Wed, 2 Feb 2000 16:36:47 -0800 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: Re: [MOBILE-IP] Issues with draft-ietf-mobileip-3gwireless-ext-02.txt X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200002030015.QAA12474@nasnfs.eng.sun.com> from "Patrice Calhoun" at Feb 02, 2000 04:13:43 PM Content-Transfer-Encoding: 7bit Thanks Pat. We need to look into this. -Gopal > > All, > > I was looking at this draft today and noticed that it makes use of the > Key field in the GRE header. I was recently informed that the new GRE > I-D targetted to replace the Informational RFC, is in last call, and > no longer contains the Key field. The Key field is required for the > Mobile-IP draft, and therefore will not be able to support the > standards track version of the GRE protocol (draft-meyer-gre-update-03.txt). > > I would urge anyone that cares about this draft to make your issues > known to the IESG before the GRE last call expires. > > PatC > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 20:55:43 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24801 for ; Wed, 2 Feb 2000 20:55:43 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.59E84750@standards.nortelnetworks.com>; Wed, 2 Feb 2000 20:23:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20062 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 20:22:01 -0500 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.29A7D4C0@standards.nortelnetworks.com>; Wed, 2 Feb 2000 20:22:01 -0500 Received: (from gdommety@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA24888; Wed, 2 Feb 2000 17:23:20 -0800 (PST) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200002030123.RAA24888@omega.cisco.com> Date: Wed, 2 Feb 2000 17:23:20 -0800 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: Re: [MOBILE-IP] Issues with draft-ietf-mobileip-3gwireless-ext-02.txt (fwd) X-To: "Kent K. Leung" X-cc: David Meyer , tunnel-coders@cisco.com, mobileip-coders@cisco.com, dino@procket.com, tony1@home.com, stan_hanks@enron.net, pst@juniper.net To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200002030046.QAA28105@sigma.cisco.com> from "Kent K. Leung" at Feb 02, 2000 04:46:32 PM Content-Transfer-Encoding: 7bit Hello David et al: This is regarding the new GRE draft. We are currently using the Key field (RFC1701) in an Interface referred to as RP that is used in 3rd generation wireless networks. This interface enables a large part of the wireless network to be IP based. This interface currently uses the Key field of GRE. The new GRE draft talks about deprecating the Key field. Would like to know your thoughts on having the key field in the new GRE draft. This change will make the RP interface complient with the new GRE draft/RFC. Thanks Gopal > > Hi David. I'm trying to understand the implications of > draft-meyer-gre-update-03.txt for our GRE tunnels. Since > we have multipoint GRE tunnel using NHRP (based on the key > field), will this draft make mGRE unsupportable. I know > of other vendors as well as Cisco's RP interface (based > on draft-ietf-mobileip-3gwireless-ext-02.txt) for Mobile IP > that relies on the Key field. > > I guess why are certain fields deprecated? The draft did > not seem to provide reasons. Can you explain? > > -- Kent -- > > Forwarded message: > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 16:22:35 2000 > > X-Mailer: Sun NetMail 2.3 > > MIME-Version: 1.0 > > Content-Type: text/plain; charset="US-ASCII" > > Content-Transfer-Encoding: 7bit > > Message-ID: <200002030015.QAA12474@nasnfs.eng.sun.com> > > Date: Wed, 2 Feb 2000 16:13:43 -0800 > > Reply-To: pcalhoun@Eng.Sun.COM > > Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" > > > > From: Patrice Calhoun > > Subject: [MOBILE-IP] Issues with draft-ietf-mobileip-3gwireless-ext-02.txt > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > X-SMTP-HELO: standards.nortelnetworks.com > > X-SMTP-MAIL-FROM: owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM > > X-SMAP-Received-From: outside > > X-SMTP-PEER-INFO: standards.nortelnetworks.com [137.118.21.16] > > Content-Length: 552 > > > > All, > > > > I was looking at this draft today and noticed that it makes use of the > > Key field in the GRE header. I was recently informed that the new GRE > > I-D targetted to replace the Informational RFC, is in last call, and > > no longer contains the Key field. The Key field is required for the > > Mobile-IP draft, and therefore will not be able to support the > > standards track version of the GRE protocol (draft-meyer-gre-update-03.txt). > > > > I would urge anyone that cares about this draft to make your issues > > known to the IESG before the GRE last call expires. > > > > PatC > > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 2 23:27:47 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28102 for ; Wed, 2 Feb 2000 23:27:46 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AFACE060@standards.nortelnetworks.com>; Wed, 2 Feb 2000 23:24:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20329 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 2 Feb 2000 23:24:35 -0500 Received: from mail0.u-aizu.ac.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AA224450@standards.nortelnetworks.com>; Wed, 2 Feb 2000 23:24:34 -0500 Received: from pross114.u-aizu.ac.jp (pross114 [163.143.180.102]) by mail0.u-aizu.ac.jp (8.9.3+3.1W/3.7Winternet-gw) with ESMTP id NAA11898; Thu, 3 Feb 2000 13:26:29 +0900 (JST) Received: from u-aizu.ac.jp (localhost [127.0.0.1]) by pross114.u-aizu.ac.jp (8.9.3+3.1W/3.7Wistcmx+kanji) with ESMTP id NAA23500; Thu, 3 Feb 2000 13:26:29 +0900 (JST) X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: multipart/alternative; boundary="------------D51A70C95CFDAF799CEE4404" Message-ID: <38990374.2DFE6C7D@u-aizu.ac.jp> Date: Thu, 3 Feb 2000 13:26:29 +0900 Reply-To: sarikaya@U-AIZU.AC.JP Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Behcet Sarikaya Organization: University of Aizu Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --------------D51A70C95CFDAF799CEE4404 Content-Type: text/plain; charset=iso-8859-9 Content-Transfer-Encoding: 7bit You mean Mobile IP but not Cellular IP? Behcet -- Behcet Sarikaya Computer Communications Lab. The University of Aizu Tsuruga, Ikki-machi, Aizu-wakamatsu City Fukushima, 965-8580 Japan Tel. +81-242-37-2559 Fax. +81-242-37-2742 Home page: http://www.u-aizu.ac.jp/~sarikaya/ email: sarikaya@u-aizu.ac.jp --------------D51A70C95CFDAF799CEE4404 Content-Type: text/html; charset=iso-8859-9 Content-Transfer-Encoding: 7bit You mean Mobile IP but not Cellular IP?

Behcet 

-- 
Behcet Sarikaya
Computer Communications Lab.
The University of Aizu
Tsuruga, Ikki-machi, Aizu-wakamatsu City
Fukushima, 965-8580 Japan
Tel. +81-242-37-2559 Fax. +81-242-37-2742 
Home page:  http://www.u-aizu.ac.jp/~sarikaya/
email: sarikaya@u-aizu.ac.jp
  --------------D51A70C95CFDAF799CEE4404-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 01:22:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00701 for ; Thu, 3 Feb 2000 01:22:59 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C74E45F0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 1:19:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20476 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 01:18:42 -0500 Received: from mail.rdc1.sfba.home.com (24.0.0.66) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.35F892F0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 1:08:42 -0500 Received: from home.net ([24.5.203.21]) by mail.rdc1.sfba.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000203061046.YRMB12979.mail.rdc1.sfba.home.com@home.net>; Wed, 2 Feb 2000 22:10:46 -0800 X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 References: <200002030123.RAA24888@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38991BE6.40E9F775@home.net> Date: Wed, 2 Feb 2000 22:10:46 -0800 Reply-To: Tony Li Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Tony Li Organization: Li Consulting Subject: Re: [MOBILE-IP] Issues with draft-ietf-mobileip-3gwireless-ext-02.txt (fwd) X-To: Gopal Dommety X-cc: "Kent K. Leung" , David Meyer , tunnel-coders@cisco.com, mobileip-coders@cisco.com, dino@procket.com, tony1@home.com, stan_hanks@enron.net, pst@juniper.net To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Gopal, > This is regarding the new GRE draft. We are currently using > the Key field (RFC1701) in an Interface referred to as RP that is used > in 3rd generation wireless networks. This interface enables a large > part of the wireless network to be IP based. This interface currently > uses the Key field of GRE. > > The new GRE draft talks about deprecating the Key field. Would > like to know your thoughts on having the key field in the new GRE > draft. This change will make the RP interface complient with the new > GRE draft/RFC. You should notice that while this field is deprecated, there is nothing that says that you can't continue to use it. Your usage would simply be compliant with the existing RFCs, not with the proposed standard. Regards, Tony From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 10:26:44 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20409 for ; Thu, 3 Feb 2000 10:26:43 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C0EF5860@standards.nortelnetworks.com>; Thu, 3 Feb 2000 10:23:46 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21009 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 10:22:15 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8A906E30@standards.nortelnetworks.com>; Thu, 3 Feb 2000 10:22:15 -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 HAA08252; Thu, 3 Feb 2000 07:24:23 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs-201.Eng.Sun.COM [129.146.201.28]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA12832; Thu, 3 Feb 2000 07:24:22 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp2.Central.Sun.COM [129.147.36.137]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id HAA27478; Thu, 3 Feb 2000 07:24:15 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-ID: <200002031524.HAA27478@nasnfs.eng.sun.com> Date: Thu, 3 Feb 2000 07:22:31 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] Issues with draft-ietf-mobileip-3gwireless-ext-02.txt (fwd) X-To: Tony Li To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Tony, My understanding was that the Key field was deprecated due to a lack of usage. Since we can now provide applications for the key field, can we request that the IESG allow the field back in the proposed standard? (btw, for what it's worth, PPTP also uses the key field). PatC >Gopal, > > >> This is regarding the new GRE draft. We are currently using >> the Key field (RFC1701) in an Interface referred to as RP that is used >> in 3rd generation wireless networks. This interface enables a large >> part of the wireless network to be IP based. This interface currently >> uses the Key field of GRE. >> >> The new GRE draft talks about deprecating the Key field. Would >> like to know your thoughts on having the key field in the new GRE >> draft. This change will make the RP interface complient with the new >> GRE draft/RFC. > >You should notice that while this field is deprecated, there is nothing that >says that >you can't continue to use it. Your usage would simply be compliant with the >existing >RFCs, not with the proposed standard. > >Regards, >Tony From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 10:30:50 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20550 for ; Thu, 3 Feb 2000 10:30:50 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.095F8110@standards.nortelnetworks.com>; Thu, 3 Feb 2000 10:25:47 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21026 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 10:25:24 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FAEFFA60@standards.nortelnetworks.com>; Thu, 3 Feb 2000 10:25: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 HAA09561; Thu, 3 Feb 2000 07:27:30 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs-201.Eng.Sun.COM [129.146.201.28]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA13759; Thu, 3 Feb 2000 07:27:29 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp2.Central.Sun.COM [129.147.36.137]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id HAA27532; Thu, 3 Feb 2000 07:27:20 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-ID: <200002031527.HAA27532@nasnfs.eng.sun.com> Date: Thu, 3 Feb 2000 07:25:38 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum X-To: Behcet Sarikaya , "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit well, given that you aren't providing me with any context, I will simply assume that you are asking me whether I meant Mobile IP and not Cellular IP being driven in MWIF, and the answer is yes (Mobile IP, not Cellular IP). PatC >You mean Mobile IP but not Cellular IP? > >Behcet > >-- >Behcet Sarikaya >Computer Communications Lab. >The University of Aizu >Tsuruga, Ikki-machi, Aizu-wakamatsu City >Fukushima, 965-8580 Japan >Tel. +81-242-37-2559 Fax. +81-242-37-2742 >Home page: http://www.u-aizu.ac.jp/~sarikaya/ >email: sarikaya@u-aizu.ac.jp > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 11:50:16 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22537 for ; Thu, 3 Feb 2000 11:50:12 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.68103910@standards.nortelnetworks.com>; Thu, 3 Feb 2000 11:47:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21299 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 11:45:13 -0500 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.21EF5790@standards.nortelnetworks.com>; Thu, 3 Feb 2000 11:45:13 -0500 Received: (from gdommety@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA03463; Thu, 3 Feb 2000 08:45:51 -0800 (PST) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200002031645.IAA03463@omega.cisco.com> Date: Thu, 3 Feb 2000 08:45:51 -0800 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: Re: [MOBILE-IP] Issues with draft-ietf-mobileip-3gwireless-ext-02.txt X-To: Tony Li X-cc: "Kent K. Leung" , David Meyer , tunnel-coders@cisco.com, mobileip-coders@cisco.com, dino@procket.com, tony1@home.com, stan_hanks@enron.net, pst@juniper.net To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <38991BE6.40E9F775@home.net> from "Tony Li" at Feb 02, 2000 10:10:46 PM Content-Transfer-Encoding: 7bit Tony, > > The new GRE draft talks about deprecating the Key field. Would > > like to know your thoughts on having the key field in the new GRE > > draft. This change will make the RP interface complient with the new > > GRE draft/RFC. > > You should notice that while this field is deprecated, there is nothing that says that > you can't continue to use it. Your usage would simply be compliant with the existing > RFCs, not with the proposed standard. I relized that we can use the key field and be complient with RFC1701 but not with the new proposed standard. The main motivation behind this email is to see how we can be complient with the new standard (Since RFC1701 is an informational RFC, some of the wireless standards bodies would not like to reference it). Would appreciate if you give some insight into why the Key field was deprecated and what is needed to de-deprecate:) it? Regards, Gopal > > Regards, > Tony > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 14:06:45 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27028 for ; Thu, 3 Feb 2000 14:06:43 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.703D71D0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 14:03:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21465 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 14:01:26 -0500 Received: from quartz.airtouch.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2937AE90@standards.nortelnetworks.com>; Thu, 3 Feb 2000 14:01:26 -0500 Received: from Notes.airtouch.com (ath-irv-gwy3.it.cl.airtouch.com [153.114.106.136]) by quartz.airtouch.com (8.8.8+Sun/8.8.8) with SMTP id LAA05297; Thu, 3 Feb 2000 11:09:40 -0800 (PST) Received: by Notes.airtouch.com(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 8825687A.0068BC7D ; Thu, 3 Feb 2000 11:03:59 -0800 X-Lotus-FromDomain: AIRTOUCH Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <8825687A.0068B7C3.00@Notes.airtouch.com> Date: Thu, 3 Feb 2000 10:52:02 -0800 Reply-To: Charles.Lo@NOTES.AIRTOUCH.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Charles Lo Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM We need to be careful to distinguish between mobility protocols favored by specific companies for MWIF adoption, vs. actual agreed-to position or direction in MWIF. For the former, I agree with Pat that a number of companies prefer Mobile IP, especially given fairly broad global wireless industry support. Mobile IP is specified in the 3GPP2 packet data standard (3GPP2 represents industry players behind the cdma2000 radio technology of 3G), as well as will be supported by 3GPP (the W-CDMA 3G industry) in their R'00 standard. Re. the latter, in future work the MWIF technical committee will consider different IP mobility protocols in a contribution-driven manner, and then make decisions on which protocol(s) to adopt. No such decision has been made to-date. Charles Patrice Calhoun on 02/03/2000 07:25:38 AM Please respond to pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Charles Lo/Corporate/AirTouch) Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum well, given that you aren't providing me with any context, I will simply assume that you are asking me whether I meant Mobile IP and not Cellular IP being driven in MWIF, and the answer is yes (Mobile IP, not Cellular IP). PatC >You mean Mobile IP but not Cellular IP? > >Behcet > >-- >Behcet Sarikaya >Computer Communications Lab. >The University of Aizu >Tsuruga, Ikki-machi, Aizu-wakamatsu City >Fukushima, 965-8580 Japan >Tel. +81-242-37-2559 Fax. +81-242-37-2742 >Home page: http://www.u-aizu.ac.jp/~sarikaya/ >email: sarikaya@u-aizu.ac.jp > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 14:13:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27232 for ; Thu, 3 Feb 2000 14:13:23 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6D050DB0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 14:10:29 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21520 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 14:10:19 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.66F9CFF0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 14:10: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 LAA07636; Thu, 3 Feb 2000 11:11:55 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs-201.Eng.Sun.COM [129.146.201.28]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA17781; Thu, 3 Feb 2000 11:11:02 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp2.Central.Sun.COM [129.147.36.137]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id LAA03637; Thu, 3 Feb 2000 11:10:55 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-ID: <200002031910.LAA03637@nasnfs.eng.sun.com> Date: Thu, 3 Feb 2000 11:09:10 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum X-To: Charles.Lo@Notes.airtouch.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit If you had read my note, that unfortunately wasn't included in the response that caused this whole thread, I stated that *I* was trying to make sure that Mobile-IP was being adopted. I never stated that I was speaking for MWIF, or any other standards body. PatC > >We need to be careful to distinguish between mobility protocols favored by >specific companies for MWIF adoption, vs. actual agreed-to position or >direction >in MWIF. For the former, I agree with Pat that a number of companies prefer >Mobile IP, especially given fairly broad global wireless industry support. >Mobile IP is specified in the 3GPP2 packet data standard (3GPP2 represents >industry players behind the cdma2000 radio technology of 3G), as well as will >be >supported by 3GPP (the W-CDMA 3G industry) in their R'00 standard. Re. the >latter, in future work the MWIF technical committee will consider different IP >mobility protocols in a contribution-driven manner, and then make decisions on >which protocol(s) to adopt. No such decision has been made to-date. > >Charles > > > > >Patrice Calhoun on 02/03/2000 07:25:38 AM > >Please respond to pcalhoun@Eng.Sun.COM > > > >To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >cc: (bcc: Charles Lo/Corporate/AirTouch) >Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum > > > >well, given that you aren't providing me with any context, I will simply >assume that you are asking me whether I meant Mobile IP and not Cellular IP >being driven in MWIF, and the answer is yes (Mobile IP, not Cellular IP). > >PatC >>You mean Mobile IP but not Cellular IP? >> >>Behcet >> >>-- >>Behcet Sarikaya >>Computer Communications Lab. >>The University of Aizu >>Tsuruga, Ikki-machi, Aizu-wakamatsu City >>Fukushima, 965-8580 Japan >>Tel. +81-242-37-2559 Fax. +81-242-37-2742 >>Home page: http://www.u-aizu.ac.jp/~sarikaya/ >>email: sarikaya@u-aizu.ac.jp >> >> > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 18:00:35 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01659 for ; Thu, 3 Feb 2000 18:00:34 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1C182480@standards.nortelnetworks.com>; Thu, 3 Feb 2000 17:57:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22048 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 17:55:18 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6EFA7970@standards.nortelnetworks.com>; Thu, 3 Feb 2000 17:45:17 -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 OAA04531 for ; Thu, 3 Feb 2000 14:47:22 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs-201.Eng.Sun.COM [129.146.201.28]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA07556; Thu, 3 Feb 2000 14:47:21 -0800 (PST) Received: from cali (cali [129.146.122.121]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA09597; Thu, 3 Feb 2000 14:47:20 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Thu, 3 Feb 2000 14:47:20 -0800 Reply-To: Gabriel Montenegro Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gabriel Montenegro Subject: Re: [MOBILE-IP] Private addressing reference in rfc2002-bis ? X-To: Samita Chakrabarti To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <200002021957.LAA12079@jurassic.eng.sun.com> > It may make sense to update rfc2344 the tunnel routing > issues for private addresses, by the way, i've submitted the rfc2344-bis draft. if you want to get it before the announcement comes out, you can get it at: http://playground.sun.com/~gab/papers/tunnel.txt (the only changes are new section 6.3 and an appendix). > but I still think that > mipagent (FA) somehow needs to inform the mobile nodes > that it can handle private addresses-- that means having > 'T' bit in the agent advertisement field is not sufficient > to provide support for private addresses. agreed, but please note that any of this is not in scope for the update to rfc2344 at this time. now, going forward (as a separate task), we could overload the 'T' bit to also imply support for private addresses as specified in the revision of 2344. if this is not agreeable to everyone, then, yes, perhaps a new 'P' bit makes sense. > It seems logical to me that 'P' bit with agent advertisement > can let the privately addressed mobile node choose the right FA > -- but it may have other implications--any particular reasons > against it ? but the 'P' bit (or overloaded 'T' bit) does not answer this question: what COA should the MN used for registration? notice that the COA may very well be a function of the MN's home address: for MN's within the FA's domain the COA is probably an 'inside' address of the FA. for MN's with home addresses outside the FA's domain, perhaps an 'external' COA makes more sense. how are these two different coa's advertised and kept apart? perhaps a new private addr extension could carry pairs along these lines: nai, coa or dns authority, coa given the first element of the pair, an mn would be in a position to select the right coa it needs to use. the private addr extension need not be included in all advertisements. upon hearing a 'P' bit, the mn could solicit with a special code, say in order to obtain the priv addr extension. this is just wondering out loud what to do, as i said, the revision to rfc2344 does not go into this and is very limited in scope. this last stuff is for later discussion. -gabriel From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 18:10:07 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01835 for ; Thu, 3 Feb 2000 18:10:07 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.866A81B0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 18:07:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22100 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 18:06:06 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F1566720@standards.nortelnetworks.com>; Thu, 3 Feb 2000 17:56:05 -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 OAA11518; Thu, 3 Feb 2000 14:58:04 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs-201.Eng.Sun.COM [129.146.201.28]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA10339; Thu, 3 Feb 2000 14:58:00 -0800 (PST) Received: from cali (cali [129.146.122.121]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA09986; Thu, 3 Feb 2000 14:57:59 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Thu, 3 Feb 2000 14:58:00 -0800 Reply-To: Gabriel Montenegro Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gabriel Montenegro Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum X-To: Jim Bound To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <200002022239.RAA0000005835@quarry.zk3.dec.com> > What I am suggesting is that the various forums assume IPv6 for the > addresses for all 3GPP mobile nodes first of all. When mobile hits the > Internet pipe from the Celluar world it will run into IPv4 and that is > where tunnels and other v6 trans mechanisms would be used to get to the > recipient (e.g. home agent, hlr, CN, mobile web servers). But within the > Celluar infrastructure IPv6 is assumed. So 3GPP would be deployed gradually > as it became available along side the pre-3GPP infrastructure until it > replaced the IPv4 old parts. Celluar mobility has the advantage that we > don't have for existing non-mobile Internet users and that is, it is not > widely deployed ( I am speaking here of MNs that have the capability to > access data (content) via 3GPP). i agree, wireless is a natural for v6 cuz most of the time deployment is already planning on having some sort of proxy or intermediate system between the wireless cloud and the general internet. i'm not talking about laptops that happen to connect wirelessly, i'm talking about the much more numerous phone-like devices. imposing a proxy may have other architectural consequences, but it does provide a natural location for the v6/v4 interface function. certainly worth exploring. -gabriel From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 18:25:11 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01661 for ; Thu, 3 Feb 2000 18:00:35 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1C267C60@standards.nortelnetworks.com>; Thu, 3 Feb 2000 17:57:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22097 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 17:55:37 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E0121590@standards.nortelnetworks.com>; Thu, 3 Feb 2000 17:55:36 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id OAA04233; Thu, 3 Feb 2000 14:57:46 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id OAA31438; Thu, 3 Feb 2000 14:57:45 -0800 X-Virus-Scanned: Thu, 3 Feb 2000 14:57:45 -0800 Nokia Silicon Valley AntiVirus Appliance Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma030492; Thu, 3 Feb 00 14:57:27 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <200002030123.RAA24888@omega.cisco.com> <38991BE6.40E9F775@home.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <389A07D7.DA4A5F06@iprg.nokia.com> Date: Thu, 3 Feb 2000 14:57:27 -0800 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] Issues withdraft-ietf-mobileip-3gwireless-ext-02.txt (fwd) X-To: Tony Li To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Tony, Unfortunately, it isn't sufficient for Mobile IP to cite a standard that is only Informational. We have to have something better in order to go to Draft Standard -- later this year if possible. Or, should the working group define its own encapsulation that already includes a session identifier? That is the main thing that people want from GRE, it seems, aside from compliance with existing equipment. I wonder how the latter will interact with changing GRE itself... Regards, Charlie P. Tony Li wrote: >> The new GRE draft talks about deprecating the Key field. Would >> like to know your thoughts on having the key field in the new GRE >> draft. This change will make the RP interface complient with the new >> GRE draft/RFC. > > You should notice that while this field is deprecated, there is nothing > that says that you can't continue to use it. Your usage would simply be > compliant with the existing RFCs, not with the proposed standard. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 3 20:21:48 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03134 for ; Thu, 3 Feb 2000 20:21:47 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DFE54920@standards.nortelnetworks.com>; Thu, 3 Feb 2000 20:18:46 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22462 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 3 Feb 2000 20:16:47 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.987DB6D0@standards.nortelnetworks.com>; Thu, 3 Feb 2000 20:16:46 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id RAA19460; Thu, 3 Feb 2000 17:18:57 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id RAA30818; Thu, 3 Feb 2000 17:18:56 -0800 X-Virus-Scanned: Thu, 3 Feb 2000 17:18:56 -0800 Nokia Silicon Valley AntiVirus Appliance Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma030734; Thu, 3 Feb 00 17:18:52 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <389A28FC.5C31027B@iprg.nokia.com> Date: Thu, 3 Feb 2000 17:18:52 -0800 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: [MOBILE-IP] RFC2002bis new sections X-cc: Basavaraj Patil , Phil Roberts To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, I have written up two new appendices for RFC 2002bis. I'm ready to send it out after I find out whether the working group approves of the inclusion of these sections. Note that there is a collision for extension type 107. I've included the bibliography for easy reference. The section types (e.g., 2.1.3) refer to sections in RFC2002bis itself. I can post the revised draft later, but first I wanted to get a sense of whether people liked or hated these appendices. Regards, Charlie P. ================================================================================= G. Number Assignments The information about assignment of numbers, given by IANA at http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers from the various Mobile IP number spaces is out of date. It should be reorganized according to the recipe given in section 6. The current values are as given in the following subsections. All bracketed references are given in the bibliography. Unbracketed numbers refer to sections of this document. G.1. New Mobile IP Message Types Mobile IP messages are defined to be those that are sent to a message recipient at port 434 (UDP or TCP). Type Name Reference ---- -------------------------------------------- --------- 1 Registration Request [22] 3 Registration Reply [22] G.2. Extensions to RFC 1256 Router Advertisement Type Name Reference ---- -------------------------------------------- --------- 0 One-byte Padding 2.1.3 16 Mobility Agent Advertisement 2.1.1 19 Prefix-Lengths 2.1.2 G.3. Extensions to Mobile IP Registration Messages Type Name Reference ---- -------------------------------------------- --------- 0 One-byte Padding 32 Mobile-Home Authentication 3.5.2 33 Mobile-Foreign Authentication 3.5.3 34 Foreign-Home Authentication 3.5.4 129 Traversal Extension [19] 130 Encapsulating Delivery Style Extension [20] 131 The Mobile Node NAI Extension [5] G.4. Code Values for Mobile IP Registration Reply Messages The Code values in this section are divided in several major groups: 0-8 Success Codes 64-128 Error Codes from the Foreign Agent 128-192 Error Codes from the Home Agent Type Description Reference ---- -------------------------------------------- --------- 0 registration accepted 1 registration accepted without simultaneous bindings 64 reason unspecified 65 administratively prohibited 66 insufficient resources 67 mobile node failed authentication 68 home agent failed authentication 69 requested Lifetime too long 70 poorly formed Request 71 poorly formed Reply 72 requested encapsulation unavailable 73 requested Van Jacobson compression unavailable 74 requested reverse tunnel unavailable [19] 75 reverse tunnel is mandatory and 'T' bit not set [19] 76 mobile node too distant [19] 77 invalid care-of address 78 registration timeout 80 home network unreachable (ICMP error received) 81 home agent host unreachable (ICMP error received) 82 home agent port unreachable (ICMP error received) 88 home agent unreachable (other ICMP error received) 96 nonzero homeaddr required [5] 97 missing NAI [5] 98 missing home agent [5] 99 missing home address [5] 128 reason unspecified 129 administratively prohibited 130 insufficient resources 131 mobile node failed authentication 132 foreign agent failed authentication 133 registration Identification mismatch 134 poorly formed Request 135 too many simultaneous mobility bindings 136 unknown home agent address 137 requested reverse tunnel unavailable [19] 138 reverse tunnel is mandatory and 'T' bit not set [19] 139 requested encapsulation unavailable [19] H. Proposed Number Assignments Several Internet Drafts are under consideration by the mobile-ip working group. In this section, the numbers that are suggested for use in those working group documents are listed. H.1. Proposed Extensions to RFC 1256 Router Advertisement The numbers in this section are enumerated only as a courtesy to future writers of Internet Drafts. Authors of new Internet Drafts MAY, of course, use the numbers listed here, as deemed appropriate by the then-current members of the working group. Citations included in this section are NOT to be considered normative references. Type Name Reference ---- -------------------------------------------- --------- 24 Challenge [4] H.2. Proposed New Mobile IP Message Types The following new messages types are proposed to be recognized by Mobile IP entities that receive them at port 434. Type Name Reference ---- -------------------------------------------- --------- 16 Binding Warning message [26] 17 Binding Request message [26] 18 Binding Update message [26] 19 Binding Acknowledge message [26] H.3. Proposed Extensions to Mobile IP Registration Messages Type Name Reference ---- -------------------------------------------- --------- 16 Binding Warning message [26] 36 Generalized Mobile IP Authentication [4] 38 Critical Vendor/Organization Specific [9] 40 Generalized Registration Key Request [25] 42 Generalized Mobile IP MN-HA Key Reply [24] 96 Previous Foreign Agent Notification [26] 132 MN-FA Challenge [4] 134 Normal Vendor/Organization Specific [9] H.4. Proposed Code Values for Mobile IP Registration Reply Messages Type Description Reference ---- -------------------------------------------- --------- 104 Unknown Challenge [4] 105 Missing Challenge [4] 106 Stale Challenge [4] 107 Missing MN-FA Authentication [24] 107 MN-FA Unsupported Vendor Ext [9] 108 HA-FA Unsupported Vendor Ext [9] 141 MN-HA Unsupported Vendor Ext [9] 142 HA-MN Unsupported Vendor Ext [9] H.5. Proposed SPI Values for the Mobile IP Reserved SPIs Type Description Reference ---- -------------------------------------------- --------- 2 CHAP [4, 33] 3 MD5/prefix+suffix [24, 22] 4 HMAC MD5 [24, 15] I. Example Messages I.1. Example ICMP Agent Advertisement Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Addrs |Addr Entry Size| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Address[1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference Level[1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Address[2] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference Level[2] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 16 | Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registration Lifetime |R|B|H|F|M|G|V|T| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address[1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address[2] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Optional Extensions : : .... ...... ...... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I.2. Example Registration Request Message Format The UDP header is followed by the Mobile IP fields shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 |S|B|D|M|G|V|T| | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Non-Auth Extensions for HA ... | | ( variable length ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =32 | Length | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI (cont..) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : MN-HA Authenticator ( variable length ) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Optional Non-Auth Extensions for FA ......... : Optional MN-FA Authentication Extension... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I.3. Example Registration Reply Message Format The UDP header is followed by the Mobile IP fields shown below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional HA Non-Auth Extensions ... | | ( variable length ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =32 | Length | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI (cont...) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : MN-HA Authenticator ( variable length ) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Optional Extensions used by FA......... : Optional MN-FA Authentication Extension... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ References [1] R. Atkinson. IP Authentication Header. Request for Comments (Proposed Standard) 1826, Internet Engineering Task Force, August 1995. [2] S. M. Bellovin. Security Problems in the TCP/IP Protocol Suite. ACM Computer Communications Review, 19(2), March 1989. [3] Ramon Caceres and Liviu Iftode. Improving the Performance of Reliable Transport Protocols in Mobile Computing Environments. IEEE Journal on Selected Areas in Communications, 13(5):850--857, June 1995. [4] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent Challenge/Response Extension. draft-ietf-mobileip-challenge-08.txt, January 2000. (work in progress). [5] Pat R. Calhoun and Charles E. Perkins. Mobile IP Network Address Identifier Extension. draft-ietf-mobileip-mn-nai-07.txt, January 2000. (work in progress). [6] D. Cong, M. Hamlen, and C. Perkins. The Definitions of Managed Objects for IP Mobility Support using SMIv2. Request for Comments (Proposed Standard) 2006, Internet Engineering Task Force, October 1996. [7] S. Deering. ICMP Router Discovery Messages. Request for Comments (Proposed Standard) 1256, Internet Engineering Task Force, September 1991. [8] S. E. Deering. Host extensions for IP multicasting. Request for Comments (Standard) 1112, Internet Engineering Task Force, August 1989. [9] Gopal Dommety and Kent Leung. Mobile IP Vendor/Organization-Specific Extensions. draft-ietf-mobileip-vendor-ext-09.txt, November 1999. (work in progress). [10] R. Droms. Dynamic Host Configuration Protocol. Request for Comments (Draft Standard) 2131, Internet Engineering Task Force, March 1997. [11] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness Recommendations for Security. Request for Comments (Informational) 1750, Internet Engineering Task Force, December 1994. [12] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing Encapsulation (GRE). Request for Comments (Informational) 1701, Internet Engineering Task Force, October 1994. [13] V. Jacobson. Compressing TCP/IP headers for low-speed serial links. Request for Comments (Proposed Standard) 1144, Internet Engineering Task Force, February 1990. [14] Van Jacobson. Congestion Avoidance and Control. In Proceedings, SIGCOMM '88 Workshop, pages 314--329. ACM Press, August 1988. Stanford, CA. [15] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for Message Authentication. Request for Comments (Informational) 2104, Internet Engineering Task Force, February 1997. [16] K. McCloghrie and F. Kastenholz. Evolution of the Interfaces Group of MIB-II. Request for Comments (Proposed Standard) 1573, Internet Engineering Task Force, January 1994. [17] G. McGregor. The PPP Internet Protocol Control Protocol (IPCP). Request for Comments (Proposed Standard) 1332, Internet Engineering Task Force, May 1992. [18] David L. Mills. Network Time Protocol (Version 3) Specification, Implementation. Request for Comments (Draft Standard) 1305, Internet Engineering Task Force, March 1992. [19] G. Montenegro. Reverse Tunneling for Mobile IP. Request for Comments (Proposed Standard) 2344, Internet Engineering Task Force, May 1998. [20] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for Mobile IP. Request for Comments (Informational) 2356, Internet Engineering Task Force, June 1998. [21] C. Perkins. IP Encapsulation within IP. Request for Comments (Proposed Standard) 2003, Internet Engineering Task Force, October 1996. [22] C. Perkins. IP Mobility Support. Request for Comments (Proposed Standard) 2002, Internet Engineering Task Force, October 1996. [23] C. Perkins. Minimal Encapsulation within IP. Request for Comments (Proposed Standard) 2004, Internet Engineering Task Force, October 1996. [24] C. E. Perkins and P. Calhoun. AAA Registration Keys for Mobile IP. draft-ietf-mobileip-aaa-key-01.txt, January 2000. (work in progress). [25] C. E. Perkins and D. Johnson. Registration Keys for Route Optimization. draft-ietf-mobileip-regkey-01.txt, January 2000. (work in progress). [26] C. E. Perkins and D. Johnson. Route Optimization in Mobile IP. draft-ietf-mobileip-optim-09.txt, January 2000. (work in progress). [27] D. C. Plummer. Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware. Request for Comments (Standard) 826, Internet Engineering Task Force, November 1982. [28] J. Postel. User Datagram Protocol. Request for Comments (Standard) 768, Internet Engineering Task Force, August 1980. [29] J. Postel. Internet Protocol. Request for Comments (Standard) 791, Internet Engineering Task Force, September 1981. [30] J. Postel. Multi-LAN address resolution. Request for Comments 925, Internet Engineering Task Force, October 1984. [31] J. Reynolds and J. Postel. Assigned Numbers. Request for Comments (Standard) 1700, Internet Engineering Task Force, October 1994. [32] R. Rivest. The MD5 Message-Digest Algorithm. Request for Comments (Informational) 1321, Internet Engineering Task Force, April 1992. [33] W. Simpson. PPP Challenge Handshake Authentication Protocol (CHAP). Request for Comments (Draft Standard) 1994, Internet Engineering Task Force, August 1996. [34] W. Simpson and Editor. The Point-to-Point Protocol (PPP). Request for Comments (Standard) 1661, Internet Engineering Task Force, July 1994. [35] J. Solomon. Applicability Statement for IP Mobility Support. Request for Comments (Proposed Standard) 2005, Internet Engineering Task Force, October 1996. [36] W. Richard Stevens. TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley, Reading, Massachusetts, 1994. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 03:40:37 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20880 for ; Fri, 4 Feb 2000 03:40:37 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.097095A0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 3:36:35 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23018 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 03:35:36 -0500 Received: from mail.rdc1.sfba.home.com (24.0.0.66) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.80377430@standards.nortelnetworks.com>; Fri, 4 Feb 2000 3:25:35 -0500 Received: from home.net ([24.5.203.21]) by mail.rdc1.sfba.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000204082746.BNQU12979.mail.rdc1.sfba.home.com@home.net>; Fri, 4 Feb 2000 00:27:46 -0800 X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 References: <200002031645.IAA03463@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <389A8D82.24F3A2EE@home.net> Date: Fri, 4 Feb 2000 00:27:46 -0800 Reply-To: Tony Li Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Tony Li Organization: Li Consulting Subject: Re: [MOBILE-IP] Issues with draft-ietf-mobileip-3gwireless-ext-02.txt X-To: Gopal Dommety X-cc: "Kent K. Leung" , David Meyer , tunnel-coders@cisco.com, mobileip-coders@cisco.com, dino@procket.com, tony1@home.com, stan_hanks@enron.net, pst@juniper.net To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Gopal, MOBILE-IP folks, et. al., > I relized that we can use the key field and be complient with RFC1701 > but not with the new proposed standard. The main motivation behind > this email is to see how we can be complient with the new standard > (Since RFC1701 is an informational RFC, some of the wireless standards > bodies would not like to reference it). > > Would appreciate if you give some insight into why the Key field was > deprecated and what is needed to de-deprecate:) it? The Key field was deprecated mostly becuase there is no good semantics for it within GRE itself. As to what's necessary to have it included in the Proposed Standard version, I would say that you would need to: - Contact Dave Meyer as he's the one driving this advancement, not me. - Deliver to him a clear semantics for the Key field that is completely independent of MOBILE-IP and is somehow essential for GRE. - Get buy-in from all of the authors of this draft and then get it pushed through the IESG again. Good luck. Yer gonna need it. Tony From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 03:45:48 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20903 for ; Fri, 4 Feb 2000 03:45:48 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BD8EA950@standards.nortelnetworks.com>; Fri, 4 Feb 2000 3:41:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23026 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 03:39:50 -0500 Received: from fs1.northstream.se (62.20.120.194) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.17A3F320@standards.nortelnetworks.com>; Fri, 4 Feb 2000 3:29:49 -0500 MIME-version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: TFS Secure Messaging /320000000/320101050/320101051/320200319/ Message-ID: Date: Fri, 4 Feb 2000 09:28:31 +0100 Reply-To: Guilhem Ensuque Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Guilhem Ensuque Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum X-To: Charles.Lo@NOTES.AIRTOUCH.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA20903 Hi all, Here are my two-penny worth lines on this thread: In response to Charles Lo's email, unless I haven't understood his text corerctly, I want to introduce some clarifications: > a number of companies prefer > Mobile IP, especially given fairly broad global wireless > industry support I am sure you know Mobile IP is not broadly supported by the wireless industry, I would rather say that MAP or ANSI-41 are, as far as mobility management is concerned and more recently GTP for tunnelling. > Mobile IP is specified in the 3GPP2 packet data standard I thought it was specified here, by the mobile IP working group of the IETF :) > as well as will be > supported by 3GPP (the W-CDMA 3G industry) in their R'00 standard As far as I know, R'00 only specifies an architecture for the transfer of existing signalling protocols for call control, IN, location registration... from the SS7 to the IP domain, using IP telephony protocols such as e.g. megaco, sigtran, sip (or even H.323)... A feasibility study has indeed been carried out by the 3GPP MIP adhoc group -in which a number of participants of this list have been involved- to investigate the possibility of introduction of MIP to the 3G core network. However, I do not think it is an agreed part of the standard yet. > in future work the MWIF technical committee will consider different IP > mobility protocols in a contribution-driven manner, and then make > decisions on which protocol(s) to adopt. No such decision has been > made to-date. However, I had not heard of the MWIF before, and Charles Lo seems to know quite well what's going on there... what 'different IP mobility protocols' are you thinking of? There are not so many around, are there? Guilhem Ensuque | guilhem.ensuque@northstream.se | +33 6 15 74 53 90 Northstream AB | Sophia-Antipolis, France | www.northstream.se -----Original Message----- From: IP Routing for Wireless/Mobile Hosts (mobile-ip) [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Charles Lo Sent: Thursday, February 03, 2000 7:52 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum We need to be careful to distinguish between mobility protocols favored by specific companies for MWIF adoption, vs. actual agreed-to position or direction in MWIF. For the former, I agree with Pat that a number of companies prefer Mobile IP, especially given fairly broad global wireless industry support. Mobile IP is specified in the 3GPP2 packet data standard (3GPP2 represents industry players behind the cdma2000 radio technology of 3G), as well as will be supported by 3GPP (the W-CDMA 3G industry) in their R'00 standard. Re. the latter, in future work the MWIF technical committee will consider different IP mobility protocols in a contribution-driven manner, and then make decisions on which protocol(s) to adopt. No such decision has been made to-date. Charles From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 04:17:50 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21084 for ; Fri, 4 Feb 2000 04:17:50 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3939EA20@standards.nortelnetworks.com>; Fri, 4 Feb 2000 4:13:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23155 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 04:12:32 -0500 Received: from tokyo.ccrle.nec.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A9025150@standards.nortelnetworks.com>; Fri, 4 Feb 2000 4:02:31 -0500 Received: from wallace.heidelberg.ccrle.nec.de (Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.8.7/3.6W980303HK) with ESMTP id KAA14950 for ; Fri, 4 Feb 2000 10:07:33 +0100 (CET) Received: from ccrle.nec.de (Arthur.heidelberg.ccrle.nec.de [192.168.102.69]) by wallace.heidelberg.ccrle.nec.de (8.8.7/3.6W980203HK) with ESMTP id KAA14403 for ; Fri, 4 Feb 2000 10:12:14 +0100 (CET) X-Mailer: Mozilla 4.6 [de] (WinNT; I) X-Accept-Language: de MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <389A9635.CCA42959@ccrle.nec.de> Date: Fri, 4 Feb 2000 09:04:53 +0000 Reply-To: Hannes Hartenstein Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Hannes Hartenstein Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Guilhem, Guilhem Ensuque wrote: > A feasibility study has indeed been carried out by the 3GPP MIP adhoc > group -in which a number of participants of this list have been involved- to > investigate the possibility of introduction of MIP to the 3G core network. > However, I do not think it is an agreed part of the standard yet. what are the results of the study? And where do we find documents of this study and of the 3GPP MIP ad hoc group in general? Thanks, Hannes -- Dr Hannes Hartenstein Hannes.Hartenstein@ccrle.nec.de Research Staff Member Tel.: +49 6221 905 11 15 C&C Research Laboratories Fax.: +49 6221 905 11 55 NEC Europe Ltd. Adenauerplatz 6 69115 Heidelberg, Germany http://www.ccrle.nec.de/heidelberg/index.html From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 05:43:17 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21556 for ; Fri, 4 Feb 2000 05:43:17 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1F1DD6E0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 5:38:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23292 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 05:37:51 -0500 Received: from hoemail2.firewall.lucent.com (192.11.226.163) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FA37BBC0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 5:37:51 -0500 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA22899 for ; Fri, 4 Feb 2000 05:40:03 -0500 (EST) Received: from uk0006exch001p.wins.lucent.com (h135-86-160-146.lucent.com [135.86.160.146]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA22785 for ; Fri, 4 Feb 2000 05:39:47 -0500 (EST) Received: by uk0006exch001p.uk.lucent.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Feb 2000 10:39:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04876937@en0060exch001u.uk.lucent.com> Date: Fri, 4 Feb 2000 10:39:44 -0000 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum X-To: Gabriel Montenegro To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > i agree, wireless is a natural for v6 cuz most of the time deployment > is already planning on having some sort of proxy or intermediate system > between the wireless cloud and the general internet. i'm not talking about > laptops that happen to connect wirelessly, i'm talking about the much > more numerous phone-like devices. imposing a proxy may > have other architectural consequences, but it does provide a natural > location for the v6/v4 interface function. certainly worth exploring. > > Well, if we use proxy, then why not using private addresses. If so we don't need IPv6. Thinking Loudly. alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 06:48:33 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22111 for ; Fri, 4 Feb 2000 06:48:32 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.36D16910@standards.nortelnetworks.com>; Fri, 4 Feb 2000 6:43:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23367 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 06:42:17 -0500 Received: from hoemlsrv.firewall.lucent.com (192.11.226.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FAA50D70@standards.nortelnetworks.com>; Fri, 4 Feb 2000 6:42:17 -0500 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA15894 for ; Fri, 4 Feb 2000 06:44:29 -0500 (EST) Received: from uk0006exch001p.wins.lucent.com (h135-86-160-146.lucent.com [135.86.160.146]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA15853 for ; Fri, 4 Feb 2000 06:44:23 -0500 (EST) Received: by uk0006exch001p.uk.lucent.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Feb 2000 11:44:22 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C0487693A@en0060exch001u.uk.lucent.com> Date: Fri, 4 Feb 2000 11:44:20 -0000 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum X-To: Thomas Eklund To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Thomas, We all concur on the good things IPv6 provides. We all have to check reality as well. The thing is 3G deployment is to start 2002, with some folks starting earlier,some later. 2G1/2 is supposed to have commercial start in early 2001 (somebody shoots earlier than that). Can anybody predict widespread use of IPV6 in corporations or internet websites by that time? If no corporation is after IPv6, I want to be able to offer corporate net access. We need IPv4 support in 21/2 and 3G. > And if you have private addresses how will you be able to roam? > It is not possible to roam with your private ipaddress. > Well, GPRS and Mobile IP allow for roaming with private addresses. I don't see how to provide access to corporate nets, otherwise. > Having a proxy implies that you must tunnel out from the proxy to the > mobile... in other word to the mobile's private address - it does not > matter > if you have a l2 or l3 tunnel you still must tunnel out to the mobile. > Well, I've never seen an IP packet over the air, without at least radio physical and link layers. There are ways not to use a L3 tunnel to the mobile, as per MIPv4 and GPRS/UMTS PS domain. > Why should the mobile trust the proxy? Which it must when you have private > addresses.... > well, this would have to happen for the worth exploring solution for 4 to 6 transition Gabriel mentions. > The most natural scenario would be to use ipv6 internal in your cellular > networks and translate to v4 in the edges and give every cellular phone an > ipv6 address. > How does that translation impact IPSEC? Which is the trust model you have in mind? alessio > /Thomas > > > -----Original Message----- > > From: Casati, Alessio (Alessio) [mailto:acasati@LUCENT.COM] > > Sent: Friday, February 04, 2000 11:40 AM > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum > > > > > > > i agree, wireless is a natural for v6 cuz most of the time > > deployment > > > is already planning on having some sort of proxy or > > intermediate system > > > between the wireless cloud and the general internet. i'm > > not talking about > > > laptops that happen to connect wirelessly, i'm talking > > about the much > > > more numerous phone-like devices. imposing a proxy may > > > have other architectural consequences, but it does provide a natural > > > location for the v6/v4 interface function. certainly worth > > exploring. > > > > > > > > Well, if we use proxy, then why not using private addresses. > > If so we don't need IPv6. Thinking Loudly. > > > > alessio > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 06:54:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22206 for ; Fri, 4 Feb 2000 06:54:21 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0F35D570@standards.nortelnetworks.com>; Fri, 4 Feb 2000 6:50:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23360 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 06:49:23 -0500 Received: from fs1.northstream.se (62.20.120.194) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9253E200@standards.nortelnetworks.com>; Fri, 4 Feb 2000 6:39:22 -0500 MIME-version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: TFS Secure Messaging /320000000/320101050/320101051/320200319/ Message-ID: Date: Fri, 4 Feb 2000 12:38:07 +0100 Reply-To: Guilhem Ensuque Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Guilhem Ensuque Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum X-To: Hannes.Hartenstein@CCRLE.NEC.DE To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA22206 Hi Hannes, Hi all, The result of the study was an incremental deployment scenario for Mobile IP in UMTS involving ultimately a new node, the IGSN, that collapses the functions of GGSN, SGSN and FA if I understand everything correctly. All 3GPP documents are free and public and can be found at www.3gpp.org The document in questions are: 23.922 Architecture for an all-IP network (v3.0.0 - dec 99) 23.923 Combined GSM and Mobile IP mobility handling in UMTS IP CN (v3.0.0 - dec 99 as well) To find the documents, follow the links to 'Technical Specification Group' from the main page. Then for the MIP ad-hoc documents follow: ftp://ftp.3gpp.org/TSG_SA/WG2_Arch/S2MobileIp/ The authors of these document are on this list so I am sure you can ask more info. Regards Guilhem -----Original Message----- From: IP Routing for Wireless/Mobile Hosts (mobile-ip) [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM] On Behalf Of Hannes Hartenstein Sent: Friday, February 04, 2000 10:05 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum Hi Guilhem, Guilhem Ensuque wrote: > A feasibility study has indeed been carried out by the 3GPP MIP adhoc > group -in which a number of participants of this list have been involved- to > investigate the possibility of introduction of MIP to the 3G core network. > However, I do not think it is an agreed part of the standard yet. what are the results of the study? And where do we find documents of this study and of the 3GPP MIP ad hoc group in general? Thanks, Hannes -- Dr Hannes Hartenstein Hannes.Hartenstein@ccrle.nec.de Research Staff Member Tel.: +49 6221 905 11 15 C&C Research Laboratories Fax.: +49 6221 905 11 55 NEC Europe Ltd. Adenauerplatz 6 69115 Heidelberg, Germany http://www.ccrle.nec.de/heidelberg/index.html From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 08:05:40 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24892 for ; Fri, 4 Feb 2000 08:05:40 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DE8F1B70@standards.nortelnetworks.com>; Fri, 4 Feb 2000 8:00:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23553 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 08:00:10 -0500 Received: from monza.broadswitch.com (195.178.164.73) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.75D47540@standards.nortelnetworks.com>; Fri, 4 Feb 2000 7:50:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD15AE46@monza.broadswitch.com> Date: Fri, 4 Feb 2000 12:05:49 +0100 Reply-To: Thomas Eklund Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thomas Eklund Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM If we stick in the private address lane that some people support then we will NEVER see the wireless Internet boom that everyone is waiting for - IPv6 is a natural catalyst for making evrything always connected - not semi-connected as in these private address/NAT based solutions. IPv6 will give you end-to-end semantic which a ipv4 based solution will not give you. IPv6 is far superior when it comes to scaling because of its hierarchal address-architecture. And in huge cellular backbone it makes a real difference. And if you have private addresses how will you be able to roam? It is not possible to roam with your private ipaddress. Having a proxy implies that you must tunnel out from the proxy to the mobile... in other word to the mobile's private address - it does not matter if you have a l2 or l3 tunnel you still must tunnel out to the mobile. Why should the mobile trust the proxy? Which it must when you have private addresses.... This definatly breakes the e-2-e security. The most natural scenario would be to use ipv6 internal in your cellular networks and translate to v4 in the edges and give every cellular phone an ipv6 address. /Thomas > -----Original Message----- > From: Casati, Alessio (Alessio) [mailto:acasati@LUCENT.COM] > Sent: Friday, February 04, 2000 11:40 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum > > > > i agree, wireless is a natural for v6 cuz most of the time > deployment > > is already planning on having some sort of proxy or > intermediate system > > between the wireless cloud and the general internet. i'm > not talking about > > laptops that happen to connect wirelessly, i'm talking > about the much > > more numerous phone-like devices. imposing a proxy may > > have other architectural consequences, but it does provide a natural > > location for the v6/v4 interface function. certainly worth > exploring. > > > > > Well, if we use proxy, then why not using private addresses. > If so we don't need IPv6. Thinking Loudly. > > alessio > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 10:02:28 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29254 for ; Fri, 4 Feb 2000 10:02:17 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.40874400@standards.nortelnetworks.com>; Fri, 4 Feb 2000 9:57:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23765 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 09:56:12 -0500 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.114CF6D0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 9:56:12 -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 JAA11486; Fri, 4 Feb 2000 09:57:51 -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 Message-ID: <389B1644.478B2D9C@comet.columbia.edu> Date: Fri, 4 Feb 2000 10:11:16 -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] Mobile Wireless Internet Forum X-To: Guilhem Ensuque X-cc: cellularip@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Guilhem: Thanks for the clarification. Since I started this thread let me add fuel to the fire: > A feasibility study has indeed been carried out by the 3GPP MIP adhoc > group -in which a number of participants of this list have been involved- to > investigate the possibility of introduction of MIP to the 3G core network. > However, I do not think it is an agreed part of the standard yet. It seems to me that all 3G** forums (and now MWIF) are a healthy indication that the old world IMT-2000 view of circuits in the core (BTW, ATM and WATM are dead ideas for wireless broadband access) and at the RAN is phasing out quickly. In the end the ITU 3G networks will be all IP datagrams in the core and across the air - connectionless all the way to the terminal. That should not be a radical thought anymore - even for the celcos and vendors. That is not to say there are significant technical challenges to pull that vision off. There are and we know what they are. But in the immortal words of another Charlie (Parker) "Now is the time" - everything else, is intellectual legacy (particularly ATM). > > > in future work the MWIF technical committee will consider different IP > > mobility protocols in a contribution-driven manner, and then make > > decisions on which protocol(s) to adopt. No such decision has been > > made to-date. > > However, I had not heard of the MWIF before, and Charles Lo seems to know > quite well what's going on there... what 'different IP mobility protocols' > are you thinking of? There are not so many around, are there? > I have know real information on MWIF but: MWIF have an architecture group. The operators will probably take the best output from all the 3Gs (and IETF?) I believe. But who knows. You know how these Forum operate: before long we may have MWIF MIP and RAN. Like W-CDMA and cdma2000. My feeling is that all these Forums (many people on this list are active in them) are pushing their ideas in the MIP working group. But is anyone strongly pushing MIP in 3GPP, 3GPP2, 3GIP and MWIF. Are there strong advocates there? I hope so. In the end we can leave it to Cisco to direct MWIF to do the right thing ;-) Read "democracy of the market". From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 10:07:48 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29439 for ; Fri, 4 Feb 2000 10:07:48 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3CA0C590@standards.nortelnetworks.com>; Fri, 4 Feb 2000 10:04:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23802 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 10:02:43 -0500 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FA4A3280@standards.nortelnetworks.com>; Fri, 4 Feb 2000 10:02:42 -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 KAA11756; Fri, 4 Feb 2000 10:04:54 -0500 (EST) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <45AFD48D077ED211BB4700A0C9DCE8FD15AE46@monza.broadswitch.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <389B17EB.FA93441@comet.columbia.edu> Date: Fri, 4 Feb 2000 10:18:19 -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] Mobile Wireless Internet Forum To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Thomas: Seems I got out of bed the wrong side this morning: > > If we stick in the private address lane that some people support then we > will NEVER see the wireless Internet boom that everyone is waiting for - > IPv6 is a natural catalyst for making evrything always connected - not > semi-connected as in these private address/NAT based solutions. I predict that IPv6 will never (read for the next 20 years if ever) be deployed making MIP v6 a dead duck? From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 10:25:00 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29946 for ; Fri, 4 Feb 2000 10:24:38 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7D7F9AD0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 10:20:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23863 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 10:19:55 -0500 Received: from monza.broadswitch.com (195.178.164.73) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FBCF5670@standards.nortelnetworks.com>; Fri, 4 Feb 2000 10:09:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD15AE49@monza.broadswitch.com> Date: Fri, 4 Feb 2000 16:11:49 +0100 Reply-To: Thomas Eklund Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thomas Eklund Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum X-To: "campbell@comet.columbia.edu" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM If you stick to that catchy easy discussion without any technical anylysis then I'm the wrong person to talk to. I simply dont these cheap slogans wich is based on misunderstandings (or lack of competence) /Thomas > -----Original Message----- > From: Andrew T. Campbell [mailto:campbell@COMET.COLUMBIA.EDU] > Sent: Friday, February 04, 2000 7:18 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum > > > Thomas: > > Seems I got out of bed the wrong side this morning: > > > > > If we stick in the private address lane that some people > support then we > > will NEVER see the wireless Internet boom that everyone is > waiting for - > > IPv6 is a natural catalyst for making evrything always > connected - not > > semi-connected as in these private address/NAT based solutions. > > I predict that IPv6 will never (read for the next 20 years if ever) > be deployed making MIP v6 a dead duck? > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 10:36:06 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00319 for ; Fri, 4 Feb 2000 10:36:05 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2D1C4FA0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 10:32:46 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23950 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 10:30:58 -0500 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EC708660@standards.nortelnetworks.com>; Fri, 4 Feb 2000 10:30:57 -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 KAA13227; Fri, 4 Feb 2000 10:32:57 -0500 (EST) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <45AFD48D077ED211BB4700A0C9DCE8FD15AE49@monza.broadswitch.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <389B1E7E.EF12BD5C@comet.columbia.edu> Date: Fri, 4 Feb 2000 10:46:22 -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] Mobile Wireless Internet Forum X-To: Thomas Eklund To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Thomas: OK. I deserved that response. And I agree it is a sound bite for sure, but it is not necessarily a technical argument here or for that matter a cheap slogan (BTW, that is cheap) - it is a reality of the market today. I would like to be wrong but only time will tell... Andrew Thomas Eklund wrote: > > If you stick to that catchy easy discussion without any technical anylysis > then I'm the wrong person to talk to. > I simply dont these cheap slogans wich is based on misunderstandings (or > lack of competence) > > /Thomas > > > -----Original Message----- > > From: Andrew T. Campbell [mailto:campbell@COMET.COLUMBIA.EDU] > > Sent: Friday, February 04, 2000 7:18 PM > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum > > > > > > Thomas: > > > > Seems I got out of bed the wrong side this morning: > > > > > > > > If we stick in the private address lane that some people > > support then we > > > will NEVER see the wireless Internet boom that everyone is > > waiting for - > > > IPv6 is a natural catalyst for making evrything always > > connected - not > > > semi-connected as in these private address/NAT based solutions. > > > > I predict that IPv6 will never (read for the next 20 years if ever) > > be deployed making MIP v6 a dead duck? > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 10:58:48 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00956 for ; Fri, 4 Feb 2000 10:58:48 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.680F6090@standards.nortelnetworks.com>; Fri, 4 Feb 2000 10:55:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24049 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 10:54:45 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3F2A5270@standards.nortelnetworks.com>; Fri, 4 Feb 2000 10:54:45 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id HAA12330; Fri, 4 Feb 2000 07:56:25 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id HAA09611; Fri, 4 Feb 2000 07:56:25 -0800 X-Virus-Scanned: Fri, 4 Feb 2000 07:56:25 -0800 Nokia Silicon Valley AntiVirus Appliance Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma009529; Fri, 4 Feb 00 07:56:22 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <45AFD48D077ED211BB4700A0C9DCE8FD15AE49@monza.broadswitch.com> <389B1E7E.EF12BD5C@comet.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <389AF6A6.E6DD6A9F@iprg.nokia.com> Date: Fri, 4 Feb 2000 07:56:22 -0800 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum X-To: "Andrew T. Campbell" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Andrew, Certain deadlines staring me in the face do not permit a long response, but I'd like at least to make a short one. A lot of people seem interested in providing a IPv6 solution for cellular mobility, judging from the response to my presentation at the last IETF. My belief is that IPv6 resides along the best technical path towards the goal of universal wireless access (interactive as well as embedded). I also believe that it will take the earnest and dedicated efforts of quite a few people to reach that goal. You can count me in that camp. Other people may prefer to work on NAT solutions, or non-IP solutions to the problem. Some of these alternates may have more marketing muscle than IPv6 does at the moment. But, hey, them's the breaks. I persist in my belief that technical merit, and the end-to-end programming model for network applications, do matter. That belief has prevented me from making heaps of money in the stock market, but I am really stubborn in it nonetheless. Regards, Charlie P. "Andrew T. Campbell" wrote: > > Thomas: > > OK. I deserved that response. > > And I agree it is a sound bite for sure, but it is not necessarily > a technical argument here or for that matter a cheap slogan > (BTW, that is cheap) - it is a reality of the market today. > > I would like to be wrong but only time will tell... > > Andrew > > Thomas Eklund wrote: > > > > If you stick to that catchy easy discussion without any technical anylysis > > then I'm the wrong person to talk to. > > I simply dont these cheap slogans wich is based on misunderstandings (or > > lack of competence) > > > > /Thomas > > > > > -----Original Message----- > > > From: Andrew T. Campbell [mailto:campbell@COMET.COLUMBIA.EDU] > > > Sent: Friday, February 04, 2000 7:18 PM > > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum > > > > > > > > > Thomas: > > > > > > Seems I got out of bed the wrong side this morning: > > > > > > > > > > > If we stick in the private address lane that some people > > > support then we > > > > will NEVER see the wireless Internet boom that everyone is > > > waiting for - > > > > IPv6 is a natural catalyst for making evrything always > > > connected - not > > > > semi-connected as in these private address/NAT based solutions. > > > > > > I predict that IPv6 will never (read for the next 20 years if ever) > > > be deployed making MIP v6 a dead duck? > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 11:15:44 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01406 for ; Fri, 4 Feb 2000 11:15:28 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.856D9E20@standards.nortelnetworks.com>; Fri, 4 Feb 2000 11:11:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24156 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 11:09:53 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5C674C60@standards.nortelnetworks.com>; Fri, 4 Feb 2000 11:09:53 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id IAA13385; Fri, 4 Feb 2000 08:10:04 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id IAA18996; Fri, 4 Feb 2000 08:09:49 -0800 X-Virus-Scanned: Fri, 4 Feb 2000 08:09:49 -0800 Nokia Silicon Valley AntiVirus Appliance Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma018896; Fri, 4 Feb 00 08:09:46 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <389AF9CA.9FE9B413@iprg.nokia.com> Date: Fri, 4 Feb 2000 08:09:46 -0800 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: [MOBILE-IP] Hello, am I on the list any more? X-cc: Carey Becker To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello folks, I wonder if my notes to the mailing list have been seen by anyone on this list. If anyone sees this, I would appreciate it if you could send me a confirmation. Thanks, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 11:33:27 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01889 for ; Fri, 4 Feb 2000 11:33:12 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0D3CD9E0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 11:29:08 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24241 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 11:27:35 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D5C70170@standards.nortelnetworks.com>; Fri, 4 Feb 2000 11:27:35 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id IAA15179; Fri, 4 Feb 2000 08:29:47 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id IAA32102; Fri, 4 Feb 2000 08:29:47 -0800 X-Virus-Scanned: Fri, 4 Feb 2000 08:29:47 -0800 Nokia Silicon Valley AntiVirus Appliance Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma032001; Fri, 4 Feb 00 08:29:44 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <389AFE78.2A0EA6C0@iprg.nokia.com> Date: Fri, 4 Feb 2000 08:29:44 -0800 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: [MOBILE-IP] Registration Keys draft and D-H key exchanges X-cc: Dave Johnson , Pat Calhoun To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello folks, I'm still involved with revisions to the Registration Keys draft. Currently, the draft requires a foreign agent supporting smooth handoffs to implement Diffie-Hellman key exchange based on the modular exponentiation group. This facilitates the establishment of keys when there is not any other security association available with that particular foreign agent. However, it turns out that using an elliptic curve group instead is much faster computationally. The algorithms for Diffie-Hellman key exchanges based on the elliptic curve groups are becoming more well known. Standards exist, and in order to speed up smooth handoffs when such key exchanges are needed I think it is prudent to make an elliptic curve algorithm to be the default, instead of the way it is now with exponentiation. I propose to make another basic change. Right now, the key exchange occurs between the foreign agent and the mobile node. This, however, requires passing a lot of data over the air. It is possible, instead, to have the foreign agent exchange a key with the home agent, and then the home agent can send the key to the mobile node using the security association between the mobile node and the home agent -- just as the home agent already is specified to do in some other cases. There are two points about this rearrangement. First, it becomes more important for the mobile node to be protected against the man-in-the-middle attack that can interfere with some Diffie-Hellman designs. This can be done by having the foreign agent include a short digest of its Diffie-Hellman computed value along with the Agent Advertisement. That will prevent (with high probability) any interloper from getting in the way. Secondly, this method allows the home agent to know about the key between the mobile node and the foreign agent. That is a non-issue, however, for several reasons: - This is already true for proposed key establishments initiated by the AAA server in the home domain - The home agent can't reasonably do anything with the key except shorten the registration lifetime of the mobile node at that foreign agent - The foreign agent doesn't need to use the key for any other purpose except managing a smooth handover. In other words, the fact that the home agent knows this key does not represent any security threat to the foreign agent. Besides this business with D-H, I am making some minor revisions to the current Registration Keys draft to take into account Pat Calhoun's recent proposal for having the mobile node supply the registration key to the new foreign agent. That method for establishing the key depends upon a pre-existing security relationship between the foreign agents, and it will be listed as a subtype of the Generalized Key Reply extension defined in the Registration Keys draft. To summarize: - I propose to make the Diffie-Hellman work by elliptic curve groups in the default case - I propose to have the key established by an exchange between the foreign agent and home agent, to relieve computational and bandwidth requirements on the mobile node - I propose a new extension to Agent Advertisements containing a 32-bit digest for the D-H computed value to be used. - I propose to add support for the recent proposal for passing opaque key data from the mobile node to the new foreign agent. Comments will be appreciated! Regards, Charlie P. PS. Elliptic curve computations are not as intuitive as exponentiation. I will certainly supply references for good reading materials, and I will endeavor to supply a self-contained appendix showing how to implement the algorithms. It's not the easiest thing to understand, but the effort is worthwhile. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 11:39:48 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02128 for ; Fri, 4 Feb 2000 11:39:47 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7953BFE0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 11:32:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24259 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 11:30:57 -0500 Received: from mailext12.compaq.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4DE3E830@standards.nortelnetworks.com>; Fri, 4 Feb 2000 11:30:57 -0500 Received: by mailext12.compaq.com (Postfix, from userid 12345) id C89F057980; Fri, 4 Feb 2000 10:32:35 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id C3BBC54601; Fri, 4 Feb 2000 10:32:35 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id AF80BBC4DB; Fri, 4 Feb 2000 10:32:28 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 40990B2A42; Fri, 4 Feb 2000 10:32:28 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000012685; Fri, 4 Feb 2000 11:32:34 -0500 (EST) X-Mts: smtp Message-ID: <200002041632.LAA0000012685@quarry.zk3.dec.com> Date: Fri, 4 Feb 2000 11:32:34 -0500 Reply-To: Jim Bound Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jim Bound Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of "Fri, 04 Feb 2000 10:39:44 GMT." <976F7C55E3B2D111A0720008C728549C04876937@en0060exch001u.uk.lucent.com> >> i agree, wireless is a natural for v6 cuz most of the time deployment >> is already planning on having some sort of proxy or intermediate system >> between the wireless cloud and the general internet. i'm not talking about >> laptops that happen to connect wirelessly, i'm talking about the much >> more numerous phone-like devices. imposing a proxy may >> have other architectural consequences, but it does provide a natural >> location for the v6/v4 interface function. certainly worth exploring. >> >> >Well, if we use proxy, then why not using private addresses. >If so we don't need IPv6. Thinking Loudly. I am not a fan of private addresses in IPv4 or IPv6 (site or org local addresses) but it appears some like them (not all customers either and most I know want GLOBALLY ROUTABLE ADDRESSES and feel its one of their unalienable rights on the Internet :---). But if one must then using IPv6 site local addresses (FEC0::,,,,,,,,) will work for the private address mind-set and still permit the advantages the user gets with Ipv6 Mobility over IPv4 Mobility. So private addresses are not a valid argument against using IPv6 for 3GPP. regards, /jim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 11:47:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02432 for ; Fri, 4 Feb 2000 11:47:21 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2B71C860@standards.nortelnetworks.com>; Fri, 4 Feb 2000 11:44:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24360 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 11:44:11 -0500 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.27008B90@standards.nortelnetworks.com>; Fri, 4 Feb 2000 11:44:10 -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 LAA17017; Fri, 4 Feb 2000 11:46:20 -0500 (EST) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <45AFD48D077ED211BB4700A0C9DCE8FD15AE49@monza.broadswitch.com> <389B1E7E.EF12BD5C@comet.columbia.edu> <389AF6A6.E6DD6A9F@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <389B2FB1.25F9453F@comet.columbia.edu> Date: Fri, 4 Feb 2000 11:59:45 -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] Mobile Wireless Internet Forum X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Charles: Fully agree. Andrew "Charles E. Perkins" wrote: > > Hello Andrew, > > Certain deadlines staring me in the face do not permit a long > response, but I'd like at least to make a short one. > > A lot of people seem interested in providing a IPv6 solution for > cellular mobility, judging from the response to my presentation > at the last IETF. My belief is that IPv6 resides along the best > technical path towards the goal of universal wireless access > (interactive as well as embedded). I also believe that it will > take the earnest and dedicated efforts of quite a few people to > reach that goal. You can count me in that camp. Other people > may prefer to work on NAT solutions, or non-IP solutions to the > problem. Some of these alternates may have more marketing muscle > than IPv6 does at the moment. But, hey, them's the breaks. > I persist in my belief that technical merit, and the end-to-end > programming model for network applications, do matter. That > belief has prevented me from making heaps of money in the stock > market, but I am really stubborn in it nonetheless. > > Regards, > Charlie P. > > "Andrew T. Campbell" wrote: > > > > Thomas: > > > > OK. I deserved that response. > > > > And I agree it is a sound bite for sure, but it is not necessarily > > a technical argument here or for that matter a cheap slogan > > (BTW, that is cheap) - it is a reality of the market today. > > > > I would like to be wrong but only time will tell... > > > > Andrew > > > > Thomas Eklund wrote: > > > > > > If you stick to that catchy easy discussion without any technical anylysis > > > then I'm the wrong person to talk to. > > > I simply dont these cheap slogans wich is based on misunderstandings (or > > > lack of competence) > > > > > > /Thomas > > > > > > > -----Original Message----- > > > > From: Andrew T. Campbell [mailto:campbell@COMET.COLUMBIA.EDU] > > > > Sent: Friday, February 04, 2000 7:18 PM > > > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum > > > > > > > > > > > > Thomas: > > > > > > > > Seems I got out of bed the wrong side this morning: > > > > > > > > > > > > > > If we stick in the private address lane that some people > > > > support then we > > > > > will NEVER see the wireless Internet boom that everyone is > > > > waiting for - > > > > > IPv6 is a natural catalyst for making evrything always > > > > connected - not > > > > > semi-connected as in these private address/NAT based solutions. > > > > > > > > I predict that IPv6 will never (read for the next 20 years if ever) > > > > be deployed making MIP v6 a dead duck? > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 13:12:29 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05334 for ; Fri, 4 Feb 2000 13:12:28 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D6F0D310@standards.nortelnetworks.com>; Fri, 4 Feb 2000 13:07:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24684 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 13:07:32 -0500 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CBCAF920@standards.nortelnetworks.com>; Fri, 4 Feb 2000 13:07:31 -0500 Received: (from gdommety@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA14563; Fri, 4 Feb 2000 10:09:13 -0800 (PST) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200002041809.KAA14563@omega.cisco.com> Date: Fri, 4 Feb 2000 10:09:13 -0800 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: Re: [MOBILE-IP] Hello, am I on the list any more? X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <389AF9CA.9FE9B413@iprg.nokia.com> from "Charles E. Perkins" at Feb 04, 2000 08:09:46 AM Content-Transfer-Encoding: 7bit Charlie, here is the Confirmation. I think the self notification has been turned off. Could the appropriate person turn it on, so that one can receive one's own posts too. -Gopal > > Hello folks, > > I wonder if my notes to the mailing list have been seen by anyone > on this list. If anyone sees this, I would appreciate it if you > could send me a confirmation. > > Thanks, > Charlie P. > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 14:04:39 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06554 for ; Fri, 4 Feb 2000 14:04:39 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FEBD8F30@standards.nortelnetworks.com>; Fri, 4 Feb 2000 13:59:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24840 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 13:57:32 -0500 Received: from qhars001.nortel.com (192.100.101.18) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C7EC5B30@standards.nortelnetworks.com>; Fri, 4 Feb 2000 13:57:31 -0500 Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com; Fri, 4 Feb 2000 18:58:26 +0000 Received: from zmers013 by smtprch1.nortel.com; Fri, 4 Feb 2000 12:58:13 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Fri, 4 Feb 2000 13:57:57 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1D5QDMGX>; Fri, 4 Feb 2000 12:57:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6F41.BF2EE182" Message-ID: Date: Fri, 4 Feb 2000 12:57:50 -0600 Reply-To: Ron Young Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ron Young Subject: [MOBILE-IP] FW: [MOBILE-IP] Hello, am I on the list any more? 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_01BF6F41.BF2EE182 Content-Type: text/plain; charset="ISO-8859-1" It's done... not to whine or anything but I asked about whether anyone wanted to see their own posts several months ago but no one answered. Okay, maybe I'm whining a little bit. ------------------------------------------------------------------------ Ron Young ronyoung@nortelnetworks.com http://www.nortelnetworks.com/ You can't spell Nortel without Ron; of course, you can't spell moron without Ron either. -----Original Message----- From: Gopal Dommety [mailto:gdommety@CISCO.COM] Sent: Friday, February 04, 2000 12:09 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Hello, am I on the list any more? Charlie, here is the Confirmation. I think the self notification has been turned off. Could the appropriate person turn it on, so that one can receive one's own posts too. -Gopal > > Hello folks, > > I wonder if my notes to the mailing list have been seen by anyone > on this list. If anyone sees this, I would appreciate it if you > could send me a confirmation. > > Thanks, > Charlie P. > > ------_=_NextPart_001_01BF6F41.BF2EE182 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable FW: [MOBILE-IP] Hello, am I on the list any more?

It's done... not to whine or anything but I asked = about whether anyone wanted to see their own posts several months ago = but no one answered.  Okay, maybe I'm whining a little = bit.

---------------------------------------------------------------= ---------
Ron Young   = ronyoung@nortelnetworks.com   http://www.nortelnetworks.com/
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;          
  You can't spell Nortel without Ron; of = course, you can't spell moron
          &nb= sp;           &nb= sp;    without Ron either.
 

-----Original Message-----
From: Gopal Dommety [mailto:gdommety@CISCO.COM]=
Sent: Friday, February 04, 2000 12:09 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] Hello, am I on the list any = more?


Charlie, here is the Confirmation.

I think the self notification has been turned off. = Could the
appropriate person turn it on, so that one can = receive one's own posts
too.

-Gopal


>
> Hello folks,
>
> I wonder if my notes to the mailing list have = been seen by anyone
> on this list.  If anyone sees this, I = would appreciate it if you
> could send me a confirmation.
>
> Thanks,
> Charlie P.
>
>

------_=_NextPart_001_01BF6F41.BF2EE182-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 14:27:33 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07095 for ; Fri, 4 Feb 2000 14:27:27 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.84287FB0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 14:24:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24990 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 14:23:25 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.65C9B020@standards.nortelnetworks.com>; Fri, 4 Feb 2000 14:23:25 -0500 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA15819; Fri, 4 Feb 2000 12:25:31 -0700 (MST) Received: from nasnfs.eng.sun.com (nasnfs-201.Eng.Sun.COM [129.146.201.28]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA09305; Fri, 4 Feb 2000 11:25:30 -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 LAA06840; Fri, 4 Feb 2000 11:25:09 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-ID: <200002041925.LAA06840@nasnfs.eng.sun.com> Date: Fri, 4 Feb 2000 11:36:46 -0800 Reply-To: gab@sun.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gabriel Montenegro Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit >Well, if we use proxy, then why not using private addresses. >If so we don't need IPv6. Thinking Loudly. others have responded, but here's a short theme to think about: talking about semi-isolated wireless clouds going through a gateway/proxy. yes, the cloud can run v4 private addresses, or v6. the former gets you locked into an isolation you won't be able to move out of. ever. v6 at least gives you a future in which you *could* go e2e as v6 starts appearing in the internet. you have a future. even the present has something which is very valuable: a universally significant identifier (unlike v4+private). -gabriel From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 14:59:04 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07874 for ; Fri, 4 Feb 2000 14:59:04 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DF57B640@standards.nortelnetworks.com>; Fri, 4 Feb 2000 14:55:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25123 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 14:54:21 -0500 Received: from crufty.research.bell-labs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B7CEDCC0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 14:54:20 -0500 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Fri Feb 4 14:54:44 EST 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Fri Feb 4 14:54:43 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 29F7257042; Fri, 4 Feb 2000 13:54:43 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200002021957.LAA12079@jurassic.eng.sun.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000204195443.29F7257042@king.research.bell-labs.com> Date: Fri, 4 Feb 2000 13:54:43 -0600 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] Private addressing reference in rfc2002-bis ? X-To: Gabriel Montenegro To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Hi, Gabriel, Gabriel Montenegro (GM) writes: GM> but the 'P' bit (or overloaded 'T' bit) does not answer this question: GM> what COA should the MN used for registration? GM> notice that the COA may very well be a function of the MN's home GM> address: for MN's within the FA's domain the COA is probably GM> an 'inside' address of the FA. for MN's with home addresses outside GM> the FA's domain, perhaps an 'external' COA makes more sense. In the scenarios we considered in 3GPP2, the advertised COA was always the externally visible, public address of the FA. In these scenarios the FA and HA always have one publicly visible address. If you assume that an FA is there to provide services to visiting mobile nodes in the form of tunnels back to an HA, it doesn't make much sense to allow them to register with a private COA. I would prefer that this internal address is normally hidden completely from the MN. In 3GPP2 this is perfectly reasonable because you are connected to the FA over the R-P interface on a point-to-point link; you don't ever need to know the internal address of the tunnel endpoint. Other deployment cases may have other requirements but I want to make sure this is kept as an option. If we assume that FAs are somehow deployed *within* a private network then that is a different scenario. If an FA is intended to serve only internal customers than it can certainly advertise its internal address (indeed it may have only an internal address). If an FA is intended to serve both internal and external customers, then I think we need solutions like the one you talked about (giving additional domain information along with each advertised COA). Otherwise there are some questions that need to be resolved with respect to address space collisions. A MN might be fooled into thinking it is at home (by seeing an advertised private COA) even when it is not, and might try to use an internal HA even when no such HA exists (or at least the MIP SA won't work even if there is an HA at that address). I remember once someone was talking about putting an NAI in agent advertisements, but this doesn't seem to be allowed by the current NAI draft. Does anyone know if this is still being contemplated? Maybe simply placing the NAI somewhere in the advertisement would be enough for the MN to determine if it is inside or outside its home network, even if the NAI is not associated with any address as you suggested. Alternatively, we could just describe a new response code that says "you're at home, bozo" whenever an at-home mobile tries to register (note that this may or may not be a rejection of a request, depending on the address allocation strategy in use - a few of us are working on a draft that describes this sort of behavior). -Pete From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 15:48:42 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09937 for ; Fri, 4 Feb 2000 15:48:41 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C8047940@standards.nortelnetworks.com>; Fri, 4 Feb 2000 15:44:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25352 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 15:44:07 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.46305930@standards.nortelnetworks.com>; Fri, 4 Feb 2000 15:34:07 -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 MAA25548; Fri, 4 Feb 2000 12:36:16 -0800 (PST) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.65.34]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id MAA09322; Fri, 4 Feb 2000 12:36:15 -0800 (PST) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA20434; Fri, 4 Feb 2000 12:36:07 -0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Fri, 4 Feb 2000 12:36:07 -0800 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Private addressing reference in rfc2002-bis ? X-To: Pete McCann To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <20000204195443.29F7257042@king.research.bell-labs.com> > Hi, Gabriel, > > Gabriel Montenegro (GM) writes: > > GM> but the 'P' bit (or overloaded 'T' bit) does not answer this question: > > GM> what COA should the MN used for registration? > > GM> notice that the COA may very well be a function of the MN's home > GM> address: for MN's within the FA's domain the COA is probably > GM> an 'inside' address of the FA. for MN's with home addresses outside > GM> the FA's domain, perhaps an 'external' COA makes more sense. > > In the scenarios we considered in 3GPP2, the advertised COA was always > the externally visible, public address of the FA. In these scenarios > the FA and HA always have one publicly visible address. > > If you assume that an FA is there to provide services to visiting > mobile nodes in the form of tunnels back to an HA, it doesn't make > much sense to allow them to register with a private COA. I would > prefer that this internal address is normally hidden completely from > the MN. In 3GPP2 this is perfectly reasonable because you are connected > to the FA over the R-P interface on a point-to-point link; you don't > ever need to know the internal address of the tunnel endpoint. > Other deployment cases may have other requirements but I want to make > sure this is kept as an option. > > If we assume that FAs are somehow deployed *within* a private network > then that is a different scenario. If an FA is intended to serve only > internal customers than it can certainly advertise its internal > address (indeed it may have only an internal address). If an FA is > intended to serve both internal and external customers, then I think > we need solutions like the one you talked about (giving additional > domain information along with each advertised COA). Otherwise there > are some questions that need to be resolved with respect to address > space collisions. A MN might be fooled into thinking it is at home > (by seeing an advertised private COA) even when it is not, and might > try to use an internal HA even when no such HA exists (or at least the > MIP SA won't work even if there is an HA at that address). > > I remember once someone was talking about putting an NAI in agent > advertisements, but this doesn't seem to be allowed by the current NAI > draft. Does anyone know if this is still being contemplated? Maybe > simply placing the NAI somewhere in the advertisement would be enough > for the MN to determine if it is inside or outside its home network, > even if the NAI is not associated with any address as you suggested. > Alternatively, we could just describe a new response code that says > "you're at home, bozo" whenever an at-home mobile tries to register > (note that this may or may not be a rejection of a request, depending > on the address allocation strategy in use - a few of us are working on > a draft that describes this sort of behavior). > I would welcome this change (and I wouldn't have to change my implementation :) PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 20:03:44 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14348 for ; Fri, 4 Feb 2000 20:03:44 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8CA1CBE0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 20:00:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26255 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 19:59:53 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0127BB20@standards.nortelnetworks.com>; Fri, 4 Feb 2000 19:49:53 -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 QAA03621; Fri, 4 Feb 2000 16:52:03 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs-201.Eng.Sun.COM [129.146.201.28]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA29756; Fri, 4 Feb 2000 16:52:03 -0800 (PST) Received: from cali (cali [129.146.122.121]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA19934; Fri, 4 Feb 2000 16:52:01 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Fri, 4 Feb 2000 16:52:01 -0800 Reply-To: Gabriel Montenegro Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gabriel Montenegro Subject: Re: [MOBILE-IP] Darwinian evolution of proxy tunnelling... X-To: Pete McCann To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <19990824163137.6160457036@king.research.bell-labs.com> > Hi, Guilhem, > > "G. Ensuque" (GE) writes: > > GE> Hi all > > GE> This is just to test my understanding: could the insiders correct i was finally reading some *very* old messages before the weekend. just wanted to add something here... > GE> Am I right to assume the following Darwinian evolution path for the idea > of GE> having 'daisy-chained' tunnels through proxies? > > GE> Hierarchical FA --> TEP --> regionalized tunnel mgt --> THEMA > > I'm not sure I would draw the picture quite that way. THEMA definitely > derives from TEP and is a form of hierarchical FAs, but I would say > that the recent "Regionalized Tunnel" draft is on a separate branch. > The key distinguishing feature is that of transparency. yes, i agree that thema-style tunnels are more transparent. even before TEP, they appear in TSP (now expired, fetch it from): http://playground.sun.com/~gab/papers/tsp-draft.txt there these were called compound tunnels. notice that TSP and TEP (rev0) merged into what was also called TEP (rev1): http://playground.sun.com/~gab/papers/draft-ietf-mobileip-calhoun-tep-01.txt so i'd draw the diagram like this: Hierarchical FA regionalized tunnel mgt \ / TEP / \ ??? --> TSP THEMA > > THEMA was originally conceived to solve a techno-political problem of > separation of the cellular link-layer termination point from foreign > agent functionality. It provides a nice interface to FAs that is > independent of the link layer used to access the network. ... in tsp it was also seen as a way to do remote access and (optionally, by chaining another tunnel) mobility -gabriel From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 4 23:10:10 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18072 for ; Fri, 4 Feb 2000 23:10:10 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.95390CE0@standards.nortelnetworks.com>; Fri, 4 Feb 2000 23:07:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26551 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 4 Feb 2000 23:05:50 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.611B3910@standards.nortelnetworks.com>; Fri, 4 Feb 2000 23:05:50 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA03267 for ; Fri, 4 Feb 2000 21:08:03 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.144]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id UAA26981 for ; Fri, 4 Feb 2000 20:08:04 -0800 (PST) Received: from krsna (krsna.Eng.Sun.COM [129.146.86.245]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA04103 for ; Fri, 4 Feb 2000 20:08:02 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: T7mvUY0Sc+9yOA3adIYf3Q== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Message-ID: <200002050408.UAA04103@jurassic.eng.sun.com> Date: Fri, 4 Feb 2000 20:07:13 -0800 Reply-To: Ashish Mehta Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ashish Mehta Subject: [MOBILE-IP] R-P agent should listen on port 434? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM draft-ietf-mobileip-3gwireless-ext-02.txt alludes to R-P registration messages being sent to UDP port 434. Does this imply that the mobile IP agent (processing the MobileIP registrations) and the R-P agent (processing the R-P registrations) are one and the same daemon/process? It certianly appears so, since UDP would not be able to distinguish between two unicast listeners on the same port. Would'nt this be a problem for vendors who want to productize only a mobile IP solution and use a third party solution for the R-P agent? Pardon me if this has already been discussed on the mailing list, but I am curious if this has been given any thought. ashish From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Feb 5 08:19:48 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04091 for ; Sat, 5 Feb 2000 08:19:47 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5F5DA390@standards.nortelnetworks.com>; Sat, 5 Feb 2000 8:16:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26868 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 5 Feb 2000 08:15:17 -0500 Received: from alemail1.firewall.lucent.com (192.11.221.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2308D860@standards.nortelnetworks.com>; Sat, 5 Feb 2000 8:15:17 -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 IAA20356 for ; Sat, 5 Feb 2000 08:17:32 -0500 (EST) Received: from uk0006exch001p.wins.lucent.com (h135-86-160-146.lucent.com [135.86.160.146]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA20352 for ; Sat, 5 Feb 2000 08:17:31 -0500 (EST) Received: by uk0006exch001p.uk.lucent.com with Internet Mail Service (5.5.2448.0) id ; Sat, 5 Feb 2000 13:17:31 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04876944@en0060exch001u.uk.lucent.com> Date: Sat, 5 Feb 2000 13:17:28 -0000 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum X-To: "gab@sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > ---------- > From: Gabriel Montenegro[SMTP:Gabriel.Montenegro@Eng.Sun.COM] > Reply To: gab@sun.com > Sent: 04 February 2000 19:36 > To: Casati, Alessio (Alessio); MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum > > > >Well, if we use proxy, then why not using private addresses. > >If so we don't need IPv6. Thinking Loudly. > > others have responded, but here's a short theme to think about: > talking about semi-isolated wireless clouds going through a > gateway/proxy. yes, the cloud can run v4 private addresses, > or v6. the former gets you locked into an isolation you won't > be able to move out of. ever. v6 at least gives you a future in which > you *could* go e2e as v6 starts appearing in the internet. > you have a future. even the present has something which is > very valuable: a universally significant identifier (unlike > v4+private). > > My considerations apply to proxy based wireless services, which was the topic of dicussion. It's not the case of services requiring e2e seamless connectivity. On the universally significant ID, I'm not sure that this should be defined at the network layer. Anyway there are different options. alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Feb 5 14:53:21 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07078 for ; Sat, 5 Feb 2000 14:53:21 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.51A95190@standards.nortelnetworks.com>; Sat, 5 Feb 2000 14:50:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27136 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 5 Feb 2000 14:48:36 -0500 Received: from hotmail.com (209.185.240.117) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AF18C2E0@standards.nortelnetworks.com>; Sat, 5 Feb 2000 14:38:36 -0500 Received: (qmail 36771 invoked by uid 65534); 5 Feb 2000 19:40:51 -0000 X-Originating-IP: [209.254.216.35] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01BF6FDE.B9D79740" 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 Message-ID: <20000205194051.36770.qmail@hotmail.com> Date: Sat, 5 Feb 2000 13:41:37 -0600 Reply-To: Amar Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Amar Subject: [MOBILE-IP] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BF6FDE.B9D79740 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I want to do a project on Mobile IP. For this I am looking at the = Mobile IP implementation in Linux. Please give me ideas as to what I can = do. I am willing to do a real time project or a simulation. Any help = would be appreciated. Thanks, Amar. ------=_NextPart_000_0005_01BF6FDE.B9D79740 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
     I want to do a = project on=20 Mobile IP. For this I am looking at the Mobile IP implementation in = Linux.=20 Please give me ideas as to what I can do. I am willing to do a real time = project=20 or a simulation. Any help would be appreciated.
 
Thanks,
Amar.
------=_NextPart_000_0005_01BF6FDE.B9D79740-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Feb 5 18:00:18 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08142 for ; Sat, 5 Feb 2000 18:00:18 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.752F8FC0@standards.nortelnetworks.com>; Sat, 5 Feb 2000 17:57:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27228 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 5 Feb 2000 17:55:27 -0500 Received: from quartz.airtouch.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2EFB9B70@standards.nortelnetworks.com>; Sat, 5 Feb 2000 17:55:27 -0500 Received: from Notes.airtouch.com (ath-irv-gwy3.it.cl.airtouch.com [153.114.106.136]) by quartz.airtouch.com (8.8.8+Sun/8.8.8) with SMTP id PAA27362; Sat, 5 Feb 2000 15:03:41 -0800 (PST) Received: by Notes.airtouch.com(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 8825687C.007E2ABB ; Sat, 5 Feb 2000 14:58:04 -0800 X-Lotus-FromDomain: AIRTOUCH Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <8825687C.007E29DB.00@Notes.airtouch.com> Date: Sat, 5 Feb 2000 14:55:13 -0800 Reply-To: Charles.Lo@NOTES.AIRTOUCH.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Charles Lo Subject: Re: [MOBILE-IP] Mobile Wireless Internet Forum X-To: campbell@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > in future work the MWIF technical committee will consider different IP > > mobility protocols in a contribution-driven manner, and then make > > decisions on which protocol(s) to adopt. No such decision has been > > made to-date. > > However, I had not heard of the MWIF before, and Charles Lo seems to know > quite well what's going on there... what 'different IP mobility protocols' > are you thinking of? There are not so many around, are there? Briefly MWIF, as an operator-driven industry forum is intended to influence and align worldwide 3G standardization and commercial development of the next-generation wireless network. Its scope covers both the radio access and the core networks - everything in the wireless network beyond the radio interface. It promotes ubiquitous adoption of IP technologies and leveraging as much as possible IETF standards. It will also drive and facilitate product interoperability as the traditional, monolithic and closed wireless infrastructure evolves to becoming open and multi-vendor sourced. It will NOT be a standards development organization such as 3GPP or 3GPP2. What I mean by different IP mobility protocols include those at IP layer - Mobile IP (both v4 and v6) and DHCP-based methods. Also, some people are touting SIP based terminal mobility, at the application level. I think all these will be considered by MWIF. Charles +++++++ Charles Lo Vodafone AirTouch 925-210-3460 charles.lo@airtouch.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Feb 6 05:10:46 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07047 for ; Sun, 6 Feb 2000 05:10:45 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.14FEFDD0@standards.nortelnetworks.com>; 6 Feb 2000 5:07:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27374 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 6 Feb 2000 05:05:45 -0500 Received: from smtpgw1.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D2F72700@standards.nortelnetworks.com>; 6 Feb 2000 5:05:45 -0500 Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw1.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id EAA17431 for ; Sun, 6 Feb 2000 04:08:02 -0600 (CST) Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id ; Sun, 6 Feb 2000 04:08:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Sun, 6 Feb 2000 04:08:01 -0600 Reply-To: "Lipford, Mark" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lipford, Mark" Subject: Re: [MOBILE-IP] Issues with draft-ietf-mobileip-3gwireless-ext-02 .txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM As one of the wireless carriers that are hoping to utilize this, and worked to define out internal standards (TIA TR45.4 and 3GPP2 TSG-A), we are hoping to utilize IETF "standards" in our deployment of our packet data services. ---------- From: Gopal Dommety [SMTP:gdommety@CISCO.COM] Sent: Thursday, February 03, 2000 10:46 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Issues with draft-ietf-mobileip-3gwireless-ext-02.txt Tony, > > The new GRE draft talks about deprecating the Key field. Would > > like to know your thoughts on having the key field in the new GRE > > draft. This change will make the RP interface complient with the new > > GRE draft/RFC. > > You should notice that while this field is deprecated, there is nothing that says that > you can't continue to use it. Your usage would simply be compliant with the existing > RFCs, not with the proposed standard. I relized that we can use the key field and be complient with RFC1701 but not with the new proposed standard. The main motivation behind this email is to see how we can be complient with the new standard (Since RFC1701 is an informational RFC, some of the wireless standards bodies would not like to reference it). Would appreciate if you give some insight into why the Key field was deprecated and what is needed to de-deprecate:) it? Regards, Gopal > > Regards, > Tony > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Feb 6 11:36:47 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10322 for ; Sun, 6 Feb 2000 11:36:47 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0994B850@standards.nortelnetworks.com>; 6 Feb 2000 11:33:49 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27559 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 6 Feb 2000 11:31:53 -0500 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5E1A8410@standards.nortelnetworks.com>; 6 Feb 2000 11:21:52 -0500 Received: from gull.prod.itd.earthlink.net (gull.prod.itd.earthlink.net [207.217.121.85]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id KAA08791; Sun, 6 Feb 2000 10:24:09 -0600 (CST) Received: from mail.earthlink.net (sdn-ar-002flmiamP132.dialsprint.net [168.191.77.196]) by gull.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id IAA20283; Sun, 6 Feb 2000 08:22:36 -0800 (PST) Message-ID: <200002061622.IAA20283@gull.prod.itd.earthlink.net> Date: Sun, 6 Feb 2000 08:22:36 -0800 Reply-To: kingfrank2000@hotmail.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: kingfrank2000@hotmail.com Subject: [MOBILE-IP] Stock JBRD merges,Wall Street Music and E-Commerce for big profits To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Wall-Street’s J-Bird Music Group Ltd. (symbol JBRD -OTCBB) has teamed up with Blockbuster, AT&T, CD-Now and Microsoft to revolutionize the music industry in E-commerce. Record sales are expected to take a quantum leap in year 2000. You’re invited to see how J-Bird will capitalize on its expanding catalog of artists and music. Learn More Click Below www.sflainvestments.com/jbird1.html Your were sent this message because your address is in our subscriber data base. If you wish to be removed please reply with the subject "Remove" we will removed from our subscriber list. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Feb 6 12:05:51 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10458 for ; Sun, 6 Feb 2000 12:05:51 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1A12AFD0@standards.nortelnetworks.com>; 6 Feb 2000 12:02:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27633 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 6 Feb 2000 12:01:28 -0500 Received: from hotmail.com (209.185.241.18) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.804A8310@standards.nortelnetworks.com>; 6 Feb 2000 11:51:27 -0500 Received: (qmail 28080 invoked by uid 0); 6 Feb 2000 16:53:35 -0000 Received: from 216.47.93.170 by www.hotmail.com with HTTP; Sun, 06 Feb 2000 08:53:35 PST X-Originating-IP: [216.47.93.170] Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: <20000206165335.28079.qmail@hotmail.com> Date: Sun, 6 Feb 2000 22:23:35 IST Reply-To: Jitendra Yadav Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jitendra Yadav Subject: [MOBILE-IP] Remove To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Feb 6 20:55:16 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14215 for ; Sun, 6 Feb 2000 20:55:16 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0D458EE0@standards.nortelnetworks.com>; 6 Feb 2000 20:52:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27913 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 6 Feb 2000 20:50:20 -0500 Received: from hare.net.au (203.63.221.2) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6145FE00@standards.nortelnetworks.com>; 6 Feb 2000 20:40:18 -0500 Received: from kllklk (PPPa22-ResaleRhodeIsland1-4R1163.saturn.bbn.com [4.48.66.177]) by hare.net.au (8.8.7/8.8.5) with ESMTP id LAA12576; Mon, 7 Feb 2000 11:44:21 +1100 X-Mailer: Mozilla 4.70 [en] (Win95; I) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <200002070044.LAA12576@hare.net.au> Date: Sun, 6 Feb 2000 19:50:02 -0500 Reply-To: Kline Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Kline Subject: [MOBILE-IP] You Sure Can X-To: doit03k@hare.net.au To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA14215 WE MAKE IT EASY & AFFORDABLE TO ACCEPT CREDIT CARDS FOR YOUR BUSINESS ! INTERNET (Auction Vendors & Online Mall Stores Too!) STOREFRONT OR MAIL ORDER MERCHANTS WE SPECIALIZE IN APPROVING YOU! APPLY TODAY AND START FOR JUST $9.95! FREE APPLICATION!! FREE PROGRAMMING!! DON'T LOSE ANOTHER SALE! APPLY TO ACCEPT CREDIT CARDS AND CALL (888) 264-9272 DON'T FORGET TO ASK ABOUT OUR WEB DESIGN AND HOSTING PACKAGE !!! ********************************************************************* **** If you receive this message and have never joined one of our email lists you can be removed by replying to: mailto:ghmx@yahoo.com?subject=remove ********************************************************************* **** From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Feb 6 23:42:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17328 for ; Sun, 6 Feb 2000 23:42:24 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.667418D0@standards.nortelnetworks.com>; 6 Feb 2000 23:39:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28019 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 6 Feb 2000 23:38:09 -0500 Received: from grumpy.usu.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D3760D00@standards.nortelnetworks.com>; 6 Feb 2000 23:28:08 -0500 Received: from cc.usu.edu by cc.usu.edu (PMDF V5.2-32 #39375) id <01JLLOGAZ7Q89EE3AX@cc.usu.edu> for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 6 Feb 2000 21:30:23 MDT MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Sun, 6 Feb 2000 21:30:22 -0600 Reply-To: sl531@CC.USU.EDU Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: sl531@CC.USU.EDU Subject: [MOBILE-IP] draft-ietf-mobileip-ipv6-09 X-To: itojun@iijlab.net X-cc: Aaron Griggs , ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <17191.932383872@coconut.itojun.org> Hi, I know very little about IPv6 mobility and security issues so correct me if am wrong. Please UNICAST me your expert advice. 1> Draft mention that while transmitting packet if corresponding node's Binding cache has valid care_of_address entry for mobile node's home address then it replaces later by former and append routing header with later as last hop. Do the firewall entertain source routing ?? 2> Also encapsulated packets from home agent can invade foreign network's firewall. Is that acceptable ?? 3> While registering primary care_of_address with its home agent mobile node sends either an AH [9] or ESP [10] header providing sender authentication, data integrity protection, and replay protection, via Foreign Agent. Isn't that surrendering your secured data to foreign n/w ?? Thanks. Rajeeb Mishra From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Feb 6 23:58:24 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17469 for ; Sun, 6 Feb 2000 23:58:24 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A560BB00@standards.nortelnetworks.com>; 6 Feb 2000 23:55:29 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28072 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 6 Feb 2000 23:54:27 -0500 Received: from coconut.itojun.org (210.160.95.97) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1A997F80@standards.nortelnetworks.com>; 6 Feb 2000 23:44:27 -0500 Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id NAA04588; Mon, 7 Feb 2000 13:46:30 +0900 (JST) X-Template-Reply-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Message-ID: <4586.949898790@coconut.itojun.org> Date: Mon, 7 Feb 2000 13:46:30 +0900 Reply-To: itojun@IIJLAB.NET Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: itojun@IIJLAB.NET Subject: Re: [MOBILE-IP] draft-ietf-mobileip-ipv6-09 X-To: sl531@cc.usu.edu X-cc: Aaron Griggs To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: sl531's message of Sun, 06 Feb 2000 21:30:22 CST. >I know very little about IPv6 mobility and security issues so correct me >if am wrong. Please UNICAST me your expert advice. cc: limited to mobile-ip list. >1> Draft mention that while transmitting packet if corresponding node's >Binding cache has valid care_of_address entry for mobile node's home >address then it replaces later by former and append routing header with >later as last hop. Do the firewall entertain source routing ?? >2> Also encapsulated packets from home agent can invade foreign network's >firewall. Is that acceptable ?? mobile-ip6 spec talks almost nothing about firewalls so I assumed that there's no firewall in the picture. I myself am not sure about it. >3> While registering primary care_of_address with its home agent mobile >node sends either an AH [9] or ESP [10] header providing sender >authentication, data integrity protection, and replay protection, via >Foreign Agent. Isn't that surrendering your secured data to foreign n/w ?? I believe there's no foreign agent in mobile-ip6 (page 4 first paragraph). itojun From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 01:35:54 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20168 for ; Mon, 7 Feb 2000 01:35:54 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3995F0D0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 1:32:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28225 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 01:31:02 -0500 Received: from tsbgw.wide.toshiba.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FB409AB0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 1:30:56 -0500 Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id PAA16710; Mon, 7 Feb 2000 15:32:32 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id PAA11105; Mon, 7 Feb 2000 15:32:32 +0900 (JST) Received: from tanuki (tanuki.isl.rdc.toshiba.co.jp [133.196.16.162]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with SMTP id PAA17536; Mon, 7 Feb 2000 15:32:31 +0900 (JST) References: <389AFE78.2A0EA6C0@iprg.nokia.com> X-Mailer: Datula version 1.21.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200002070632.PAA17536@isl.rdc.toshiba.co.jp> Date: Mon, 7 Feb 2000 15:42:56 +0900 Reply-To: Yoshiyuki Tsuda Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yoshiyuki Tsuda Organization: Corporate R&D Center, Toshiba Corporation Subject: Re: [MOBILE-IP] Registration Keys draft and D-H key exchanges X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <389AFE78.2A0EA6C0@iprg.nokia.com> Hello, Charlie, My comment to the 4th method is embedde in the following: On Fri, 4 Feb 2000 08:29:44 -0800, Charles E. Perkins wrote: >> Hello folks, >> >> I'm still involved with revisions to the Registration Keys draft. >> Currently, the draft requires a foreign agent supporting smooth >> handoffs to implement Diffie-Hellman key exchange based on the >> modular exponentiation group. This facilitates the establishment >> of keys when there is not any other security association available >> with that particular foreign agent. However, it turns out that >> using an elliptic curve group instead is much faster computationally. >> The algorithms for Diffie-Hellman key exchanges based on the elliptic >> curve groups are becoming more well known. Standards exist, and >> in order to speed up smooth handoffs when such key exchanges are >> needed I think it is prudent to make an elliptic curve algorithm >> to be the default, instead of the way it is now with exponentiation. >> >> I propose to make another basic change. Right now, the key exchange >> occurs between the foreign agent and the mobile node. This, however, >> requires passing a lot of data over the air. It is possible, instead, >> to have the foreign agent exchange a key with the home agent, and then >> the home agent can send the key to the mobile node using the security >> association between the mobile node and the home agent -- just as the >> home agent already is specified to do in some other cases. >> >> There are two points about this rearrangement. First, it becomes >> more important for the mobile node to be protected against the >> man-in-the-middle attack that can interfere with some Diffie-Hellman >> designs. This can be done by having the foreign agent include a >> short digest of its Diffie-Hellman computed value along with the >> Agent Advertisement. That will prevent (with high probability) >> any interloper from getting in the way. Secondly, this method >> allows the home agent to know about the key between the mobile >> node and the foreign agent. That is a non-issue, however, for >> several reasons: >> - This is already true for proposed key establishments initiated by >> the AAA server in the home domain >> - The home agent can't reasonably do anything with the key except >> shorten the registration lifetime of the mobile node at that >> foreign agent >> - The foreign agent doesn't need to use the key for any other purpose >> except managing a smooth handover. In other words, the fact that >> the home agent knows this key does not represent any security threat >> to the foreign agent. >> >> Besides this business with D-H, I am making some minor revisions to the >> current Registration Keys draft to take into account Pat Calhoun's >> recent proposal for having the mobile node supply the registration key >> to the new foreign agent. That method for establishing the key >> depends upon a pre-existing security relationship between the >> foreign agents, and it will be listed as a subtype of the Generalized >> Key Reply extension defined in the Registration Keys draft. >> >> To summarize: >> - I propose to make the Diffie-Hellman work by elliptic curve groups >> in the default case >> - I propose to have the key established by an exchange between the >> foreign agent and home agent, to relieve computational and bandwidth >> requirements on the mobile node >> - I propose a new extension to Agent Advertisements containing a >> 32-bit digest for the D-H computed value to be used. >> - I propose to add support for the recent proposal for passing opaque >> key data from the mobile node to the new foreign agent. How about passing opaque key data from the previous FA to the new FA ? I agree with you that it's more efficient to pass key data from the MN to a new FA. But, I think, there may be some network operators who resist believing MN-supplied key data blindly. As another approach, it's possible to pass the key data from the previous FA to the new FA, I think. This approach works as follows: 1) All FAs in the same administrative domain advertise the same NAI, as someone wrote. 2) In case of movements within the same administrative domain, an MN sends a registration request with a Mobile-Foreign and a Mobile-Home auth extensions, instead with a NAI and an MN-AAA auth extensions. The destination IP address of this request becomes the previous FA's address. 3) The new FA can know the previous FA by the destination address. 4) By a smooth hand-off and/or a key retrieving mehtod, the new FA can receive the key data from the previous FA. I'd like to know this approach is acceptable by the keying philosophy or not. Thanks. -Yoshi From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 04:17:01 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01142 for ; Mon, 7 Feb 2000 04:17:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C154E8D0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 4:13:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28371 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 04:12:50 -0500 Received: from jm2.epitest.fi (194.241.248.126) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.98BC4D00@standards.nortelnetworks.com>; Mon, 7 Feb 2000 4:12:50 -0500 Received: (qmail 12513 invoked by uid 500); 7 Feb 2000 09:15:01 -0000 References: <389AFE78.2A0EA6C0@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i Message-ID: <20000207111501.B12244@jm.epitest.fi> Date: Mon, 7 Feb 2000 11:15:01 +0200 Reply-To: Jouni Malinen Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jouni Malinen Subject: Re: [MOBILE-IP] Registration Keys draft and D-H key exchanges X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <389AFE78.2A0EA6C0@iprg.nokia.com> On Fri, Feb 04, 2000 at 08:29:44AM -0800, Charles E. Perkins wrote: > I propose to make another basic change. Right now, the key exchange > occurs between the foreign agent and the mobile node. This, however, > requires passing a lot of data over the air. It is possible, instead, > to have the foreign agent exchange a key with the home agent, and then > the home agent can send the key to the mobile node using the security > association between the mobile node and the home agent -- just as the > home agent already is specified to do in some other cases. > > There are two points about this rearrangement. First, it becomes > more important for the mobile node to be protected against the > man-in-the-middle attack that can interfere with some Diffie-Hellman > designs. This can be done by having the foreign agent include a > short digest of its Diffie-Hellman computed value along with the > Agent Advertisement. That will prevent (with high probability) > any interloper from getting in the way. Do you propose, that a foreign agent would use the same random exponent with all the key exchanges or would a new number be generated for each registration? If the exponent changes, also the computed value changes and then the digest values would have to be somehow bound to a correct computed value. It would be at least a bit difficult to assign a unique digest for each mobile node performing key exchange with multi/broadcast agent advertisements and there would be a need for unicast advertisements if each key exchange would be required to use a different random value. This may not, however, be necessary, if HA uses different random value for each exchange (generated session key changes). Could you please give a bit more detailed description of the proposed protection against the man-in-the-middle attacks? I'm assuming, that you are using similar method that we use in Dynamics - HUT Mobile IP implementation (MN sends the digest value protected with MN-HA auth. ext. to HA and HA checks whether it matches with the key req. ext.). I think it is still possible for an attacker to change the key exchange in a way that the attacker will know the key that the FA gets, but the HA and the MN get another key (unknown to the attacker). In which operations is the key going to be used? It is quite difficult to protect against all the attacks with one pass (reg. req. and reply). MN could know from the reply, whether the key exchange succeeded, if another digest value generated by HA would be added inside the MN-HA ext. auth. protected area of the reply, but I think that the HA and the FA could not know about all the attacks without further communication with the MN). -- Jouni Malinen From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 06:48:33 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02270 for ; Mon, 7 Feb 2000 06:48:33 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DF555F30@standards.nortelnetworks.com>; Mon, 7 Feb 2000 6:45:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28482 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 06:43:48 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4A032A30@standards.nortelnetworks.com>; Mon, 7 Feb 2000 6:33:47 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02060; Mon, 7 Feb 2000 06:36:07 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200002071136.GAA02060@ietf.org> Date: Mon, 7 Feb 2000 06:36:07 -0500 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-rfc2344-bis-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Reverse Tunneling for Mobile IP Author(s) : G. Montenegro Filename : draft-ietf-mobileip-rfc2344-bis-00.txt Pages : 26 Date : 04-Feb-00 Mobile IP uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign network, and assumes that routing is independent of source address. When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent. This document proposes backwards-compatible extensions to Mobile IP to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc2344-bis-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-rfc2344-bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-rfc2344-bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000204120809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-rfc2344-bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-rfc2344-bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000204120809.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 09:03:30 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09365 for ; Mon, 7 Feb 2000 09:03:30 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C2C75D60@standards.nortelnetworks.com>; Mon, 7 Feb 2000 9:00:20 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28625 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 08:58:24 -0500 Received: from ms1.lightwave.com (208.143.235.3) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.17A0A050@standards.nortelnetworks.com>; Mon, 7 Feb 2000 8:48:23 -0500 MIME-Version: 1.0 Content-Type: text/plain Message-ID: <62EE51AC218ED211AEC800805FBBD8D2C71B8B@EXCHANGE> Date: Mon, 7 Feb 2000 08:51:55 -0500 Reply-To: Pranav Koushik Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pranav Koushik Subject: [MOBILE-IP] Remove To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM =============================================================== From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 11:03:10 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13503 for ; Mon, 7 Feb 2000 11:03:08 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7702F0E0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 10:59:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29063 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 10:59:41 -0500 Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6F0C84F0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 10:59:41 -0500 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Mon Feb 7 11:01:20 EST 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Mon Feb 7 11:01:19 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 6987857042; Mon, 7 Feb 2000 10:01:18 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200002050408.UAA04103@jurassic.eng.sun.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000207160118.6987857042@king.research.bell-labs.com> Date: Mon, 7 Feb 2000 10:01:18 -0600 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: [MOBILE-IP] R-P agent should listen on port 434? X-To: Ashish Mehta To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200002050408.UAA04103@jurassic.eng.sun.com> Content-Transfer-Encoding: 7bit The R-P agent needs to listen directly to port 434 on the internal (towards the radio access network) interface of the FA. After an R-P tunnel is established, agent advertisements and registrations for Mobile IP are carried through the tunnel. So the Mobile IP agent needs to advertise itself and take registrations via these tunneled endpoints, each of which could be considered to be a separate, logical interface. So there should be no confusion between the R-P agent and the Mobile IP agent, as long as you can plumb these interfaces correctly. Doing this in your particular implementation environment is left as an exercise for the reader. :) -Pete Ashish Mehta (AM) writes: AM> draft-ietf-mobileip-3gwireless-ext-02.txt alludes to R-P registration AM> messages being sent to UDP port 434. Does this imply that the mobile AM> IP agent (processing the MobileIP registrations) and the R-P agent AM> (processing the R-P registrations) are one and the same daemon/process? AM> It certianly appears so, since UDP would not be able to distinguish AM> between two unicast listeners on the same port. AM> Would'nt this be a problem for vendors who want to productize only AM> a mobile IP solution and use a third party solution for the R-P AM> agent? AM> Pardon me if this has already been discussed on the mailing list, but AM> I am curious if this has been given any thought. AM> ashish From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 11:09:49 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13638 for ; Mon, 7 Feb 2000 11:09:47 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.07DE8750@standards.nortelnetworks.com>; Mon, 7 Feb 2000 11:03:57 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29097 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 11:03:41 -0500 Received: from crufty.research.bell-labs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FDD6C790@standards.nortelnetworks.com>; Mon, 7 Feb 2000 11:03:40 -0500 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Mon Feb 7 11:04:07 EST 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Mon Feb 7 11:04:07 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 C2F6257042; Mon, 7 Feb 2000 10:04:06 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <19990824163137.6160457036@king.research.bell-labs.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000207160406.C2F6257042@king.research.bell-labs.com> Date: Mon, 7 Feb 2000 10:04:06 -0600 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] Darwinian evolution of proxy tunnelling... X-To: Gabriel Montenegro To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Gabriel Montenegro (GM) writes: >> THEMA was originally conceived to solve a techno-political problem of >> separation of the cellular link-layer termination point from foreign >> agent functionality. It provides a nice interface to FAs that is >> independent of the link layer used to access the network. ... GM> in tsp it was also seen as a way to do remote access GM> and (optionally, by chaining another tunnel) mobility I should point out that THEMA should be considered superseded by draft-ietf-mobileip-3gwireless-ext-02.txt. The protocol described there also tunnels link-layer data (such as octets intended for PPP) which THEMA was not designed to do. We do not plan any further updates to THEMA at this time. -Pete From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 11:32:10 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14446 for ; Mon, 7 Feb 2000 11:32:08 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8B122570@standards.nortelnetworks.com>; Mon, 7 Feb 2000 11:29:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29209 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 11:28:29 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.74A750D0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 11:28:28 -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 IAA01313; Mon, 7 Feb 2000 08:30:39 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs-201.Eng.Sun.COM [129.146.201.28]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA17580; Mon, 7 Feb 2000 08:30:38 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp2.Central.Sun.COM [129.147.36.137]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id IAA13859; Mon, 7 Feb 2000 08:30:29 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-ID: <200002071630.IAA13859@nasnfs.eng.sun.com> Date: Mon, 7 Feb 2000 08:28:12 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] R-P agent should listen on port 434? X-To: Pete McCann To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit True, but the issue is that the spec, as-is, requires that a Foreign Agent also support the R-P interface. Although the packets are similar, the functionality provided is vastly different, begging the question as to whether requiring that a single process provide both functionality is the right design choice. PatC >The R-P agent needs to listen directly to port 434 on the internal >(towards the radio access network) interface of the FA. After an R-P >tunnel is established, agent advertisements and registrations for >Mobile IP are carried through the tunnel. So the Mobile IP agent >needs to advertise itself and take registrations via these tunneled >endpoints, each of which could be considered to be a separate, logical >interface. So there should be no confusion between the R-P agent and >the Mobile IP agent, as long as you can plumb these interfaces >correctly. Doing this in your particular implementation environment >is left as an exercise for the reader. :) > >-Pete > >Ashish Mehta (AM) writes: > >AM> draft-ietf-mobileip-3gwireless-ext-02.txt alludes to R-P registration >AM> messages being sent to UDP port 434. Does this imply that the mobile >AM> IP agent (processing the MobileIP registrations) and the R-P agent >AM> (processing the R-P registrations) are one and the same daemon/process? >AM> It certianly appears so, since UDP would not be able to distinguish >AM> between two unicast listeners on the same port. > >AM> Would'nt this be a problem for vendors who want to productize only >AM> a mobile IP solution and use a third party solution for the R-P >AM> agent? > >AM> Pardon me if this has already been discussed on the mailing list, but >AM> I am curious if this has been given any thought. > >AM> ashish From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 11:36:19 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14511 for ; Mon, 7 Feb 2000 11:36:17 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1BDCF300@standards.nortelnetworks.com>; Mon, 7 Feb 2000 11:33:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29246 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 11:32:20 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FE571E50@standards.nortelnetworks.com>; Mon, 7 Feb 2000 11:32:19 -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 IAA03455; Mon, 7 Feb 2000 08:34:35 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs-201.Eng.Sun.COM [129.146.201.28]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA23212; Mon, 7 Feb 2000 08:34:35 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp2.Central.Sun.COM [129.147.36.137]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id IAA13954; Mon, 7 Feb 2000 08:34:28 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-ID: <200002071634.IAA13954@nasnfs.eng.sun.com> Date: Mon, 7 Feb 2000 08:32:09 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] Registration Keys draft and D-H key exchanges X-To: Yoshiyuki Tsuda To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit >Hello, Charlie, > > My comment to the 4th method is embedde in the following: > >On Fri, 4 Feb 2000 08:29:44 -0800, Charles E. Perkins wrote: >>> Hello folks, >>> >>> I'm still involved with revisions to the Registration Keys draft. >>> Currently, the draft requires a foreign agent supporting smooth >>> handoffs to implement Diffie-Hellman key exchange based on the >>> modular exponentiation group. This facilitates the establishment >>> of keys when there is not any other security association available >>> with that particular foreign agent. However, it turns out that >>> using an elliptic curve group instead is much faster computationally. >>> The algorithms for Diffie-Hellman key exchanges based on the elliptic >>> curve groups are becoming more well known. Standards exist, and >>> in order to speed up smooth handoffs when such key exchanges are >>> needed I think it is prudent to make an elliptic curve algorithm >>> to be the default, instead of the way it is now with exponentiation. >>> >>> I propose to make another basic change. Right now, the key exchange >>> occurs between the foreign agent and the mobile node. This, however, >>> requires passing a lot of data over the air. It is possible, instead, >>> to have the foreign agent exchange a key with the home agent, and then >>> the home agent can send the key to the mobile node using the security >>> association between the mobile node and the home agent -- just as the >>> home agent already is specified to do in some other cases. >>> >>> There are two points about this rearrangement. First, it becomes >>> more important for the mobile node to be protected against the >>> man-in-the-middle attack that can interfere with some Diffie-Hellman >>> designs. This can be done by having the foreign agent include a >>> short digest of its Diffie-Hellman computed value along with the >>> Agent Advertisement. That will prevent (with high probability) >>> any interloper from getting in the way. Secondly, this method >>> allows the home agent to know about the key between the mobile >>> node and the foreign agent. That is a non-issue, however, for >>> several reasons: >>> - This is already true for proposed key establishments initiated by >>> the AAA server in the home domain >>> - The home agent can't reasonably do anything with the key except >>> shorten the registration lifetime of the mobile node at that >>> foreign agent >>> - The foreign agent doesn't need to use the key for any other purpose >>> except managing a smooth handover. In other words, the fact that >>> the home agent knows this key does not represent any security threat >>> to the foreign agent. >>> >>> Besides this business with D-H, I am making some minor revisions to the >>> current Registration Keys draft to take into account Pat Calhoun's >>> recent proposal for having the mobile node supply the registration key >>> to the new foreign agent. That method for establishing the key >>> depends upon a pre-existing security relationship between the >>> foreign agents, and it will be listed as a subtype of the Generalized >>> Key Reply extension defined in the Registration Keys draft. >>> >>> To summarize: >>> - I propose to make the Diffie-Hellman work by elliptic curve groups >>> in the default case >>> - I propose to have the key established by an exchange between the >>> foreign agent and home agent, to relieve computational and bandwidth >>> requirements on the mobile node >>> - I propose a new extension to Agent Advertisements containing a >>> 32-bit digest for the D-H computed value to be used. >>> - I propose to add support for the recent proposal for passing opaque >>> key data from the mobile node to the new foreign agent. > > How about passing opaque key data from the previous FA to the new FA ? > > I agree with you that it's more efficient to pass key data from the MN to > a new FA. But, I think, there may be some network operators who resist > believing MN-supplied key data blindly. > As another approach, it's possible to pass the key data from the previous > FA to the new FA, I think. > > This approach works as follows: > 1) All FAs in the same administrative domain advertise the same NAI, as > someone wrote. > 2) In case of movements within the same administrative domain, an MN sends > a registration request with a Mobile-Foreign and a Mobile-Home auth > extensions, instead with a NAI and an MN-AAA auth extensions. The > destination IP address of this request becomes the previous FA's address. > 3) The new FA can know the previous FA by the destination address. > 4) By a smooth hand-off and/or a key retrieving mehtod, the new FA can > receive the key data from the previous FA. > > I'd like to know this approach is acceptable by the keying philosophy or not. The issue that I have with this approach is that if the FA require that the MN-FA auth be authenticated prior to forwarding the registration message to the HA, it would impose additional latency by requiring a round trip between the FAs to retrieve the keys necessary to authentication the MN-FA. If the MN can receive encrypted keys from the old FA, this round trip is eliminated, further reducing the latency involved in the hand-off. PatC > >Thanks. >-Yoshi From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 12:30:42 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16188 for ; Mon, 7 Feb 2000 12:30:42 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B431D1F0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 12:27:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29510 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 12:25:41 -0500 Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7267EE80@standards.nortelnetworks.com>; Mon, 7 Feb 2000 12:25:40 -0500 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Mon Feb 7 12:26:40 EST 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Mon Feb 7 12:26:38 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 4EE8857042; Mon, 7 Feb 2000 11:26:36 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200002071630.IAA13859@nasnfs.eng.sun.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000207172637.4EE8857042@king.research.bell-labs.com> Date: Mon, 7 Feb 2000 11:26:37 -0600 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] R-P agent should listen on port 434? X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200002071630.IAA13859@nasnfs.eng.sun.com> Content-Transfer-Encoding: 7bit The draft in no way specifies that the R-P and Foreign Agent functionality is implemented in the same process. I was pointing out that, although they both use port 434, they are on logically distinct IP interfaces and so can be implemented by the same or different processes as needed. -Pete Patrice Calhoun (PC) writes: PC> True, but the issue is that the spec, as-is, requires that a Foreign Agent PC> also support the R-P interface. Although the packets are similar, the PC> functionality provided is vastly different, begging the question as to PC> whether requiring that a single process provide both functionality is the PC> right design choice. PC> PatC >> The R-P agent needs to listen directly to port 434 on the internal >> (towards the radio access network) interface of the FA. After an R-P >> tunnel is established, agent advertisements and registrations for >> Mobile IP are carried through the tunnel. So the Mobile IP agent >> needs to advertise itself and take registrations via these tunneled >> endpoints, each of which could be considered to be a separate, logical >> interface. So there should be no confusion between the R-P agent and >> the Mobile IP agent, as long as you can plumb these interfaces >> correctly. Doing this in your particular implementation environment >> is left as an exercise for the reader. :) >> >> -Pete >> >> Ashish Mehta (AM) writes: >> AM> draft-ietf-mobileip-3gwireless-ext-02.txt alludes to R-P registration AM> messages being sent to UDP port 434. Does this imply that the mobile AM> IP agent (processing the MobileIP registrations) and the R-P agent AM> (processing the R-P registrations) are one and the same daemon/process? AM> It certianly appears so, since UDP would not be able to distinguish AM> between two unicast listeners on the same port. >> AM> Would'nt this be a problem for vendors who want to productize only AM> a mobile IP solution and use a third party solution for the R-P AM> agent? >> AM> Pardon me if this has already been discussed on the mailing list, but AM> I am curious if this has been given any thought. >> AM> ashish From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 12:34:39 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16371 for ; Mon, 7 Feb 2000 12:34:39 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.44B2EC50@standards.nortelnetworks.com>; Mon, 7 Feb 2000 12:31:33 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29541 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 12:31:31 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.435928B0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 12:31:31 -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 JAA07069; Mon, 7 Feb 2000 09:33:48 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs-201.Eng.Sun.COM [129.146.201.28]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA00076; Mon, 7 Feb 2000 09:33:46 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp2.Central.Sun.COM [129.147.36.137]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id JAA15230; Mon, 7 Feb 2000 09:33:39 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-ID: <200002071733.JAA15230@nasnfs.eng.sun.com> Date: Mon, 7 Feb 2000 09:31:19 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] R-P agent should listen on port 434? X-To: Pete McCann To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit The fact that they both listen on the same port IMPLIES that the current I-D requires that they be one process. PatC > >The draft in no way specifies that the R-P and Foreign Agent >functionality is implemented in the same process. I was pointing out >that, although they both use port 434, they are on logically distinct >IP interfaces and so can be implemented by the same or different >processes as needed. > >-Pete > >Patrice Calhoun (PC) writes: > >PC> True, but the issue is that the spec, as-is, requires that a Foreign Agent >PC> also support the R-P interface. Although the packets are similar, the >PC> functionality provided is vastly different, begging the question as to >PC> whether requiring that a single process provide both functionality is the >PC> right design choice. > >PC> PatC >>> The R-P agent needs to listen directly to port 434 on the internal >>> (towards the radio access network) interface of the FA. After an R-P >>> tunnel is established, agent advertisements and registrations for >>> Mobile IP are carried through the tunnel. So the Mobile IP agent >>> needs to advertise itself and take registrations via these tunneled >>> endpoints, each of which could be considered to be a separate, logical >>> interface. So there should be no confusion between the R-P agent and >>> the Mobile IP agent, as long as you can plumb these interfaces >>> correctly. Doing this in your particular implementation environment >>> is left as an exercise for the reader. :) >>> >>> -Pete >>> >>> Ashish Mehta (AM) writes: >>> >AM> draft-ietf-mobileip-3gwireless-ext-02.txt alludes to R-P registration >AM> messages being sent to UDP port 434. Does this imply that the mobile >AM> IP agent (processing the MobileIP registrations) and the R-P agent >AM> (processing the R-P registrations) are one and the same daemon/process? >AM> It certianly appears so, since UDP would not be able to distinguish >AM> between two unicast listeners on the same port. >>> >AM> Would'nt this be a problem for vendors who want to productize only >AM> a mobile IP solution and use a third party solution for the R-P >AM> agent? >>> >AM> Pardon me if this has already been discussed on the mailing list, but >AM> I am curious if this has been given any thought. >>> >AM> ashish > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 12:54:41 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17173 for ; Mon, 7 Feb 2000 12:54:40 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.13C5DEB0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 12:51:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29623 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 12:51:11 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.02B14FB0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 12:51:11 -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 JAA19254; Mon, 7 Feb 2000 09:53:31 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs-201.Eng.Sun.COM [129.146.201.28]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA05083; Mon, 7 Feb 2000 09:53:27 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp2.Central.Sun.COM [129.147.36.137]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id JAA15796; Mon, 7 Feb 2000 09:53:17 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-ID: <200002071753.JAA15796@nasnfs.eng.sun.com> Date: Mon, 7 Feb 2000 09:51:00 -0800 Reply-To: pcalhoun@eng.sun.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: [MOBILE-IP] Cleanup of Mobile-IP milestones X-cc: oran@cisco.com, qa3445@email.mot.com, pcalhoun@eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit co-chairs, AD and anyone else that cares, I was on the WG web site, looking for some drafts, and for once I happen to glance at the milestones. These milestones are really out of date, and need to be updated. Here is my proposal: > Jul 96 Submit the IPv4 Mobile Host Protocol to the IESG as a Proposed > Standard. Mark as done. > Dec 96 Submit the IPv6 Mobile Host Protocol to the IESG as a Proposed > Standard. Delete, since it is a duplicate entry. > Mar 97 Review the WG charter and update as needed. I assume that this task was completed, and therefore can be marked as done. >Jun 99 Review the WG charter and update based on current needs and > focus. See previous comment. >Jun 99 Submit Internet-Draft for NAI support in Mobile IP to IESG for > consideration as a Proposed Standard. Mark as done. >Aug 99 Review the use of AAA in Mobile IP to support inter-domain and > intra-domain mobility and dynamic home agent assignment. Is someone on the hook to get this done? Is this simply part of the AAA requirements, and if so, then state it. It really isn't obvious. BTW, we missed that deadline big time, let's pick another random completion date :) >Dec 99 Submit draft on using AAA in Mobile IP for inter-domain and > intra-domain mobility as a proposed standard. See previous comment. >Dec 99 Submit draft capturing cellular requirements to IESG as an > Informational RFC. I am not sure what this is. If we are talking about the joint Ericsson/Telia draft, then this is GSM-specific, and does not take into account the TR45.6 work. In fact, the TR45.6 draft never actually became a WG work item. So we have two choices, either 1) combine the GSM and CDMA draft, or 2) pick one and cross our fingers. Option 1 is quite interesting, and is likely to create a very tense political situation, but would be nonetheless entertaining while 2) is useless (IMHO). The completion date also needs updating. Oh, and it looks as if Raj's e-mail address needs updating on the web page as well. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 14:06:02 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19225 for ; Mon, 7 Feb 2000 14:06:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.07905DF0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 14:02:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29775 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 14:01:59 -0500 Received: from grumpy.usu.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.80E22D20@standards.nortelnetworks.com>; Mon, 7 Feb 2000 13:51:59 -0500 Received: from cc.usu.edu by cc.usu.edu (PMDF V5.2-32 #30472) id <01JLMIMA4OI89FN4UD@cc.usu.edu> for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 11:54:11 MDT MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 7 Feb 2000 11:54:10 -0600 Reply-To: sl531@CC.USU.EDU Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: sl531@CC.USU.EDU Subject: Re: [MOBILE-IP] draft-ietf-mobileip-ipv6-09 X-To: itojun@iijlab.net X-cc: Aaron Griggs To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4586.949898790@coconut.itojun.org> On Mon, 7 Feb 2000 itojun@iijlab.net wrote: > > >I know very little about IPv6 mobility and security issues so correct me > >if am wrong. Please UNICAST me your expert advice. > > cc: limited to mobile-ip list. > > >1> Draft mention that while transmitting packet if corresponding node's > >Binding cache has valid care_of_address entry for mobile node's home > >address then it replaces later by former and append routing header with > >later as last hop. Do the firewall entertain source routing ?? > >2> Also encapsulated packets from home agent can invade foreign network's > >firewall. Is that acceptable ?? > > mobile-ip6 spec talks almost nothing about firewalls so I assumed that > there's no firewall in the picture. > I myself am not sure about it. U mean that if any Firewall exists then it MUST pave way for source routing ?? > >3> While registering primary care_of_address with its home agent mobile > >node sends either an AH [9] or ESP [10] header providing sender > >authentication, data integrity protection, and replay protection, via > >Foreign Agent. Isn't that surrendering your secured data to foreign n/w ?? > > I believe there's no foreign agent in mobile-ip6 (page 4 first > paragraph). Well, I believe foreign agent(router) is no more used by MN for address config but any valid packet address to outside node use available exit (router/gateway etc). > itojun > thanks/ Rajeeb From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 14:20:02 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19479 for ; Mon, 7 Feb 2000 14:20:02 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FEBACAB0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 14:16:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29858 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 14:15:57 -0500 Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D9BCE1D0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 14:15:56 -0500 Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Mon Feb 7 14:16:14 EST 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by scummy; Mon Feb 7 14:16:12 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 4E41157042; Mon, 7 Feb 2000 13:16:12 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200002071733.JAA15230@nasnfs.eng.sun.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000207191612.4E41157042@king.research.bell-labs.com> Date: Mon, 7 Feb 2000 13:16:12 -0600 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] R-P agent should listen on port 434? X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200002071733.JAA15230@nasnfs.eng.sun.com> Content-Transfer-Encoding: 7bit I disagree. They are on the same port but different interfaces. This can be done with distinct processes. UDP sockets are multiplexed based on both the port number and the IP address of the interface on which they arrive. The "virtual" interfaces created by the R-P tunnel endpoints should be considered as logically distinct from the underlying device on which the tunnel is carried. -Pete Patrice Calhoun (PC) writes: PC> The fact that they both listen on the same port IMPLIES that the PC> current I-D requires that they be one process. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 14:27:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19613 for ; Mon, 7 Feb 2000 14:27:55 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1F564E60@standards.nortelnetworks.com>; Mon, 7 Feb 2000 14:25:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29856 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 14:23:47 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8CA48DD0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 14:13:47 -0500 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08137; Mon, 7 Feb 2000 11:38:35 -0700 (MST) Received: from nasnfs.eng.sun.com (nasnfs-201.Eng.Sun.COM [129.146.201.28]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA21763; Mon, 7 Feb 2000 10:38:33 -0800 (PST) Received: from nobel (nobel [129.146.122.141]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA17137; Mon, 7 Feb 2000 10:38:33 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: xfOrSJBH4cDHN0DoubFYjA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_28 SunOS 5.8 sun4u sparc Message-ID: <200002071838.KAA17137@nasnfs.eng.sun.com> Date: Mon, 7 Feb 2000 10:28:07 -0800 Reply-To: Vipul Gupta Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Vipul Gupta Subject: Re: [MOBILE-IP] draft-ietf-mobileip-ipv6-09 X-To: itojun@IIJLAB.NET To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > >1> Draft mention that while transmitting packet if corresponding node's > >Binding cache has valid care_of_address entry for mobile node's home > >address then it replaces later by former and append routing header with > >later as last hop. Do the firewall entertain source routing ?? > >2> Also encapsulated packets from home agent can invade foreign network's > >firewall. Is that acceptable ?? > > mobile-ip6 spec talks almost nothing about firewalls so I assumed that > there's no firewall in the picture. > I myself am not sure about it. Correct, and neither does MIPv4 for that matter. All of them assume direct reachability between the home network and foreign networks. When there are firewalls present, packets may need to carry additional authentication to pass the firewall's checks. The paper "Secure Mobile Networking" at http://playground.sun.com/pub/mobile-ip/ talks about enabling MIPv4 through firewalls. You'll notice that the same technique is applicable to IPv6 as well. > >3> While registering primary care_of_address with its home agent mobile > >node sends either an AH [9] or ESP [10] header providing sender > >authentication, data integrity protection, and replay protection, via > >Foreign Agent. Isn't that surrendering your secured data to foreign n/w ?? > > I believe there's no foreign agent in mobile-ip6 (page 4 first > paragraph). True. This is actually a boon. As explained in the above paper, not having a foreign agent makes it easier to address security. The technique described in the paper requires the use of a co-located care-of address. Fortunately, in MIPv6, this is the only type of care-of address. > itojun vipul From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 14:59:09 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20278 for ; Mon, 7 Feb 2000 14:59:08 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7734D350@standards.nortelnetworks.com>; Mon, 7 Feb 2000 14:56:08 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29982 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 14:54:26 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3A3B8AC0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 14:54:26 -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 LAA01073; Mon, 7 Feb 2000 11:56:44 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs-201.Eng.Sun.COM [129.146.201.28]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA23843; Mon, 7 Feb 2000 11:56:43 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp2.Central.Sun.COM [129.147.36.137]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id LAA19117; Mon, 7 Feb 2000 11:56:37 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-ID: <200002071956.LAA19117@nasnfs.eng.sun.com> Date: Mon, 7 Feb 2000 11:54:15 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] R-P agent should listen on port 434? X-To: Pete McCann To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Why *must* they listen on different interfaces? Is it not conceivable that a PDSN (TR45.6 term for FA with lots of other functionality) can have a single ethernet interface? PatC > >I disagree. They are on the same port but different interfaces. This >can be done with distinct processes. UDP sockets are multiplexed >based on both the port number and the IP address of the interface on >which they arrive. The "virtual" interfaces created by the R-P tunnel >endpoints should be considered as logically distinct from the >underlying device on which the tunnel is carried. > >-Pete > >Patrice Calhoun (PC) writes: > >PC> The fact that they both listen on the same port IMPLIES that the >PC> current I-D requires that they be one process. > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 15:04:14 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20449 for ; Mon, 7 Feb 2000 15:04:14 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2BF76460@standards.nortelnetworks.com>; Mon, 7 Feb 2000 15:01:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30024 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 14:59:28 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EE67F650@standards.nortelnetworks.com>; Mon, 7 Feb 2000 14:59:28 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id MAA13851 for ; Mon, 7 Feb 2000 12:01:48 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id MAA16034 for ; Mon, 7 Feb 2000 12:01:48 -0800 X-Virus-Scanned: Mon, 7 Feb 2000 12:01:48 -0800 Nokia Silicon Valley AntiVirus Appliance Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma015913; Mon, 7 Feb 00 12:01:44 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <389F24A8.C1B47C63@iprg.nokia.com> Date: Mon, 7 Feb 2000 12:01:44 -0800 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: [MOBILE-IP] RFC2002bis To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, I have finished a new revision for RFC2002bis. I made the last updates to allow an advertisement rate by the foreign agent faster than once per second. This change has been requested by a number of people, and those other people whom I have explicitly asked about it have said it would not be disadvantageous from their point of view. It is still the case that the advertised Lifetime in the ICMP header cannot be less than 1 second, but advertisements typically would be sent faster than that Lifetime anyway. You can see the new revision at the following URL: http://www.iprg.nokia.com/~charliep/txt/mobileip/mobileip.txt Comments are requested. If further changes are needed, I can make another revision before the meeting in Adelaide. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 15:23:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20877 for ; Mon, 7 Feb 2000 15:23:21 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D805F3F0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 15:20:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30112 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 15:19:14 -0500 Received: from mw.3com.com (149.112.20.3) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B1833FD0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 15:19:14 -0500 Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id OAA04968; Mon, 7 Feb 2000 14:21:21 -0600 (CST) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8625687E.006FEA6C ; Mon, 7 Feb 2000 14:22:25 -0600 X-Lotus-FromDomain: 3COM@3COM-MWGATE Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <8625687E.006FE244.00@mwgate02.mw.3com.com> Date: Mon, 7 Feb 2000 14:18:17 -0600 Reply-To: Yingchun Xu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yingchun Xu Subject: Re: [MOBILE-IP] R-P agent should listen on port 434? X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Pat, If you want to listen on the same "logical" interface, you are right that one process is required to handle both types of registration. Yes, a PDSN can have one ethernet interface but can be configured to be different logical interfaces (multi-homing). In this case, the two registration tasks can be implemented into separated processes. --Yingchun. Patrice Calhoun on 02/07/2000 01:54:15 PM Please respond to pcalhoun@Eng.Sun.COM Sent by: Patrice Calhoun To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM cc: (Yingchun Xu/MW/US/3Com) Subject: Re: [MOBILE-IP] R-P agent should listen on port 434? Why *must* they listen on different interfaces? Is it not conceivable that a PDSN (TR45.6 term for FA with lots of other functionality) can have a single ethernet interface? PatC > >I disagree. They are on the same port but different interfaces. This >can be done with distinct processes. UDP sockets are multiplexed >based on both the port number and the IP address of the interface on >which they arrive. The "virtual" interfaces created by the R-P tunnel >endpoints should be considered as logically distinct from the >underlying device on which the tunnel is carried. > >-Pete > >Patrice Calhoun (PC) writes: > >PC> The fact that they both listen on the same port IMPLIES that the >PC> current I-D requires that they be one process. > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 15:40:30 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21188 for ; Mon, 7 Feb 2000 15:40:25 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3AA9CE30@standards.nortelnetworks.com>; Mon, 7 Feb 2000 15:37:23 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30169 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 15:35:28 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F5BC63A0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 15:35:28 -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 MAA20067; Mon, 7 Feb 2000 12:37:48 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs-201.Eng.Sun.COM [129.146.201.28]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA22968; Mon, 7 Feb 2000 12:37:47 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp2.Central.Sun.COM [129.147.36.137]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id MAA20327; Mon, 7 Feb 2000 12:37:40 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-ID: <200002072037.MAA20327@nasnfs.eng.sun.com> Date: Mon, 7 Feb 2000 12:35:18 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] R-P agent should listen on port 434? X-To: Yingchun Xu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Of course I have no particular problem with *adding* such a statement to the current draft, since my base provides virtual interfaces. However, is this a valid requirement that anyone implementing this feature *require* virtual interface support? PatC > > >Pat, >If you want to listen on the same "logical" interface, you are right that one >process is required to handle both types of registration. >Yes, a PDSN can have one ethernet interface but can be configured to be >different logical interfaces (multi-homing). In this case, the two registration >tasks >can be implemented into separated processes. > >--Yingchun. > > > > >Patrice Calhoun on 02/07/2000 01:54:15 PM > >Please respond to pcalhoun@Eng.Sun.COM > >Sent by: Patrice Calhoun > > >To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >cc: (Yingchun Xu/MW/US/3Com) >Subject: Re: [MOBILE-IP] R-P agent should listen on port 434? > > > >Why *must* they listen on different interfaces? Is it not conceivable that >a PDSN (TR45.6 term for FA with lots of other functionality) can have >a single ethernet interface? > >PatC >> >>I disagree. They are on the same port but different interfaces. This >>can be done with distinct processes. UDP sockets are multiplexed >>based on both the port number and the IP address of the interface on >>which they arrive. The "virtual" interfaces created by the R-P tunnel >>endpoints should be considered as logically distinct from the >>underlying device on which the tunnel is carried. >> >>-Pete >> >>Patrice Calhoun (PC) writes: >> >>PC> The fact that they both listen on the same port IMPLIES that the >>PC> current I-D requires that they be one process. >> > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 16:11:33 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21897 for ; Mon, 7 Feb 2000 16:11:31 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.93126AB0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 16:08:30 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30252 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 16:07:41 -0500 Received: from crufty.research.bell-labs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.75E73920@standards.nortelnetworks.com>; Mon, 7 Feb 2000 16:07:41 -0500 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Mon Feb 7 16:09:08 EST 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Mon Feb 7 16:09:07 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 F3B4E57042; Mon, 7 Feb 2000 15:09:06 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200002071956.LAA19117@nasnfs.eng.sun.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000207210907.F3B4E57042@king.research.bell-labs.com> Date: Mon, 7 Feb 2000 15:09:07 -0600 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] R-P agent should listen on port 434? X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200002071956.LAA19117@nasnfs.eng.sun.com> Content-Transfer-Encoding: 7bit Yes, everything is going over the same ethernet interface, but the R-P messages are going "raw" IP over ethernet, and the Mobile IP advertisements/requests are encapsulated inside the R-P GRE tunnel. Each tunnel has a separate GRE key field and is in fact a separate logical interface. -Pete Patrice Calhoun (PC) writes: PC> Why *must* they listen on different interfaces? Is it not conceivable that PC> a PDSN (TR45.6 term for FA with lots of other functionality) can have PC> a single ethernet interface? From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 16:25:31 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22175 for ; Mon, 7 Feb 2000 16:25:30 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8A4B2F50@standards.nortelnetworks.com>; Mon, 7 Feb 2000 16:22:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30308 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 16:21:25 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.60F62150@standards.nortelnetworks.com>; Mon, 7 Feb 2000 16:21:25 -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 NAA10762; Mon, 7 Feb 2000 13:23:43 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs-201.Eng.Sun.COM [129.146.201.28]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA03985; Mon, 7 Feb 2000 13:23:43 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp2.Central.Sun.COM [129.147.36.137]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id NAA21672; Mon, 7 Feb 2000 13:23:36 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-ID: <200002072123.NAA21672@nasnfs.eng.sun.com> Date: Mon, 7 Feb 2000 13:21:14 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] R-P agent should listen on port 434? X-To: Pete McCann To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit But the replies from the Home Agent would come back on port 434, unless the FA forwarded the request from another port (and I am not sure that all implementations support this). Therefore, it sounds like this is *still* a problem. No? PatC > >Yes, everything is going over the same ethernet interface, but the >R-P messages are going "raw" IP over ethernet, and the Mobile IP >advertisements/requests are encapsulated inside the R-P GRE tunnel. >Each tunnel has a separate GRE key field and is in fact a separate >logical interface. > >-Pete > >Patrice Calhoun (PC) writes: > >PC> Why *must* they listen on different interfaces? Is it not conceivable that >PC> a PDSN (TR45.6 term for FA with lots of other functionality) can have >PC> a single ethernet interface? > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 16:44:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22588 for ; Mon, 7 Feb 2000 16:44:55 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3574B610@standards.nortelnetworks.com>; Mon, 7 Feb 2000 16:41:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30384 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 16:39:40 -0500 Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EDE971B0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 16:39:40 -0500 Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Mon Feb 7 16:41:13 EST 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by scummy; Mon Feb 7 16:41:11 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 DA96D57042; Mon, 7 Feb 2000 15:41:10 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200002072123.NAA21672@nasnfs.eng.sun.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000207214110.DA96D57042@king.research.bell-labs.com> Date: Mon, 7 Feb 2000 15:41:10 -0600 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] R-P agent should listen on port 434? X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200002072123.NAA21672@nasnfs.eng.sun.com> Content-Transfer-Encoding: 7bit Ahh, you are talking about the registration requests/replies with the HA. Yes, if these come in on the same physical interface that supports the R-P tunnels, and if a user-space process is there to receive them, then port 434 there might be confusing. If your FA doesn't support sending the requests on a different port (which is explicitly allowed by RFC2002), and you only have one physical interface, then you could run into trouble if your implementation tries to separate the two agents into separate processes. However, most of the time, a PDSN will have at least two physical interfaces and will behave much like a firewall. That is, one interface will face inwards towards the RAN and one outwards towards the Internet. Communication with HAs will always take place on the outward interface, and R-P tunnels will always be set up on the inward interface. If you don't do things this way then elements of your RAN will be exposed to the Internet at large, which is not a good idea. Go look under your couch cushions for some change and buy a second ethernet card. -Pete Patrice Calhoun (PC) writes: PC> But the replies from the Home Agent would come back on port 434, unless the PC> FA forwarded the request from another port (and I am not sure that all PC> implementations support this). Therefore, it sounds like this is *still* PC> a problem. PC> No? From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 16:52:47 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22727 for ; Mon, 7 Feb 2000 16:52:46 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.567479D0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 16:49:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30448 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 16:48:42 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.30D45D80@standards.nortelnetworks.com>; Mon, 7 Feb 2000 16:48:42 -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 NAA23473; Mon, 7 Feb 2000 13:50:55 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs-201.Eng.Sun.COM [129.146.201.28]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA22453; Mon, 7 Feb 2000 13:50:53 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp2.Central.Sun.COM [129.147.36.137]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id NAA22332; Mon, 7 Feb 2000 13:50:46 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-ID: <200002072150.NAA22332@nasnfs.eng.sun.com> Date: Mon, 7 Feb 2000 13:48:24 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] R-P agent should listen on port 434? X-To: Pete McCann To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit If it is agreed that it is valid for a host to support both MIP and R-P as separate processes, then I would like to see some text in the new R-P I-D that simply discusses these issues, since it isn't clear to the reader (or at least me) that it was supported. Simply requiring that the implementation be able to listen on specific interfaces, and that the FA should attempt to send on a port other than 434, should do it. PatC > >Ahh, you are talking about the registration requests/replies with the HA. > >Yes, if these come in on the same physical interface that supports the >R-P tunnels, and if a user-space process is there to receive them, >then port 434 there might be confusing. If your FA doesn't support >sending the requests on a different port (which is explicitly allowed >by RFC2002), and you only have one physical interface, then you could >run into trouble if your implementation tries to separate the two >agents into separate processes. > >However, most of the time, a PDSN will have at least two physical >interfaces and will behave much like a firewall. That is, one >interface will face inwards towards the RAN and one outwards towards >the Internet. Communication with HAs will always take place on the >outward interface, and R-P tunnels will always be set up on the inward >interface. If you don't do things this way then elements of your RAN >will be exposed to the Internet at large, which is not a good idea. >Go look under your couch cushions for some change and buy a second >ethernet card. > >-Pete > > >Patrice Calhoun (PC) writes: > >PC> But the replies from the Home Agent would come back on port 434, unless the >PC> FA forwarded the request from another port (and I am not sure that all >PC> implementations support this). Therefore, it sounds like this is *still* >PC> a problem. > >PC> No? > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 17:23:54 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23297 for ; Mon, 7 Feb 2000 17:23:53 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AFE0F1C0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 17:20:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30524 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 17:20:50 -0500 Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.483D39D0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 17:10:50 -0500 Received: from cc.hut.fi (positron.tky.hut.fi [130.233.17.47]) by smtp-2.hut.fi (8.9.3/8.9.3) with ESMTP id AAA93467; Tue, 8 Feb 2000 00:13:03 +0200 (EET) X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.3 i686) MIME-Version: 1.0 References: <20000205194051.36770.qmail@hotmail.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <389F4392.CD5F28BB@cc.hut.fi> Date: Tue, 8 Feb 2000 00:13:38 +0200 Reply-To: Tom Weckström Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Tom Weckström Organization: HUT/TKK Subject: Re: [MOBILE-IP] X-To: Amar To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit > Amar wrote: > > Hello, > > I want to do a project on Mobile IP. For this I am looking at the > Mobile IP implementation in Linux. Please give me ideas as to what I > can do. I am willing to do a real time project or a simulation. Any > help would be appreciated. > > Thanks, > Amar. Hello Amar! Dynamics - HUT Mobile IP is a Mobile IP implementation for Linux. In addition to its close-to-complete RFC2002 compliance, Dynamics - HUT Mobile IP also supports Foreign Agent hierarchies, a feature that really improves handoff times. Dynamics also has a built in support for __secure signaling__, smooth handoffs, signal strength measurement, and roaming decision policies for Wireless LANs. In addition, the current 0.7-prerelease3 version supports duplicate private home addresses of Mobile Nodes in the Foreign Network, FA-registration funtionality to let the upper FAs know the FAs underneath it in the hierarchy, and vendor extensions (as of draft-ietf-mobileip-vendor-ext-08.txt). Dynamics has been tested mainly on Linux 2.2.x kernels. There is a conference paper available about our performance measurements with the old v0.5 and v0.6-pre4. Dynamics is beeing developed under GPL license. The source code is available on our web site. Feel free to find more about Dynamics - HUT Mobile IP on our web pages at http://www.cs.hut.fi/Research/Dynamics/ Best Regards, Tom -- Tom Weckström Dynamics group Helsinki University of Technology dynamics@cs.hut.fi http://www.cs.hut.fi/Research/Dynamics/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 17:44:06 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23507 for ; Mon, 7 Feb 2000 17:44:05 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7EFD8110@standards.nortelnetworks.com>; Mon, 7 Feb 2000 17:40:59 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30624 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 17:39:10 -0500 Received: from digger1.defence.gov.au by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D77176F0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 17:29:09 -0500 Received: by digger1.defence.gov.au; id IAA00501; Tue, 8 Feb 2000 08:58:28 +1030 Received: from dsto-ms2.dsto.defence.gov.au(131.185.2.150) by digger1.defence.gov.au via smap (V4.2) id xma000399; Tue, 8 Feb 00 08:58:16 +1030 Received: from muttley.dsto.defence.gov.au (unverified [131.185.2.1]) by dsto-ms2.dsto.defence.gov.au (Integralis SMTPRS 2.0.15) with ESMTP id for ; Tue, 08 Feb 2000 08:57:58 +1030 Received: from fang.dsto.defence.gov.au (fang.dsto.defence.gov.au [131.185.2.5]) by muttley.dsto.defence.gov.au (8.9.3/8.9.3/8.9.3.LMD.990513) with ESMTP id IAA05811 for ; Tue, 8 Feb 2000 08:58:25 +1030 (CST) Received: from salex004.dsto.defence.gov.au (salex004.dsto.defence.gov.au [131.185.2.9]) by fang.dsto.defence.gov.au (8.9.3/8.9.3/8.9.3.LMD.990513) with ESMTP id IAA27659 for ; Tue, 8 Feb 2000 08:58:25 +1030 (CST) Received: by salex004.dsto.defence.gov.au with Internet Mail Service (5.5.2650.21) id <13LZR0W4>; Tue, 8 Feb 2000 08:57:32 +1030 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2149A0BABC77D311AF890090274E00B2350559@salex005.dsto.defence.gov.au> Date: Tue, 8 Feb 2000 08:58:31 +1030 Reply-To: "Jayasinghe, Sana (Calendar)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Jayasinghe, Sana (Calendar)" Subject: [MOBILE-IP] Meeting To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi I am from DSTO in Adelaide, and am working on a project that includes implementation of mobile IP. Is there a mobile IP WG meeting in Adelaide planned for the near future? If so, when, and where? Also, can anyone attend ? Thanks in advance for your replies. Sana Jayasinghe From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 17:52:51 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23667 for ; Mon, 7 Feb 2000 17:52:50 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C4B60E60@standards.nortelnetworks.com>; Mon, 7 Feb 2000 17:50:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30629 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 17:49:20 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.437CF5D0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 17:39:20 -0500 Received: from zmers013 by smtprch1.nortel.com; Mon, 7 Feb 2000 16:41:20 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Mon, 7 Feb 2000 17:40:54 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id <13LQH1PP>; Mon, 7 Feb 2000 16:40:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF71BC.647BB062" Message-ID: <9A9367D1556AD21182C40000F80930ABA8BD06@crchy28b.us.nortel.com> Date: Mon, 7 Feb 2000 16:40:49 -0600 Reply-To: Vivek Sakhuja Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Vivek Sakhuja Subject: [MOBILE-IP] subscribe mobile-ip 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_01BF71BC.647BB062 Content-Type: text/plain subscribe mobile-ip vivek sakhuja ------_=_NextPart_001_01BF71BC.647BB062 Content-Type: text/html subscribe mobile-ip

subscribe mobile-ip vivek sakhuja

------_=_NextPart_001_01BF71BC.647BB062-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 20:09:54 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24918 for ; Mon, 7 Feb 2000 20:09:53 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AAD922D0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 20:05:23 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30921 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 20:04:06 -0500 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.17615320@standards.nortelnetworks.com>; Mon, 7 Feb 2000 19:54:06 -0500 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (VWALL-IN-motgate2 2.0) with ESMTP id RAA14520 for ; Mon, 7 Feb 2000 17:56:28 -0700 (MST)] Received: [from email1.wes.mot.com (email1.wes.mot.com [154.56.3.101]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id RAA19214 for ; Mon, 7 Feb 2000 17:56:28 -0700 (MST)] Received: by email1.wes.mot.com with Internet Mail Service (5.5.2650.21) id <1CLKQP37>; Mon, 7 Feb 2000 18:56:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <51F347B016ADD011963200805FC1456204BCBF4F@email1.wes.mot.com> Date: Mon, 7 Feb 2000 18:56:12 -0600 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: Re: [MOBILE-IP] R-P agent should listen on port 434? X-To: "pcalhoun@ENG.SUN.COM" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Pat's suggestion is good. My fear about this draft in general is that it assumes a particular implementation for a particular architecture that is connected "on the side" of the Internet. For those who don't have the background this could be quite confusing. Pat knows a lot of the context and has found this confusing, so it will likely be worse for others. Phil -----Original Message----- From: Patrice Calhoun [mailto:Pat.Calhoun@ENG.SUN.COM] Sent: Monday, February 07, 2000 3:48 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] R-P agent should listen on port 434? If it is agreed that it is valid for a host to support both MIP and R-P as separate processes, then I would like to see some text in the new R-P I-D that simply discusses these issues, since it isn't clear to the reader (or at least me) that it was supported. Simply requiring that the implementation be able to listen on specific interfaces, and that the FA should attempt to send on a port other than 434, should do it. PatC > >Ahh, you are talking about the registration requests/replies with the HA. > >Yes, if these come in on the same physical interface that supports the >R-P tunnels, and if a user-space process is there to receive them, >then port 434 there might be confusing. If your FA doesn't support >sending the requests on a different port (which is explicitly allowed >by RFC2002), and you only have one physical interface, then you could >run into trouble if your implementation tries to separate the two >agents into separate processes. > >However, most of the time, a PDSN will have at least two physical >interfaces and will behave much like a firewall. That is, one >interface will face inwards towards the RAN and one outwards towards >the Internet. Communication with HAs will always take place on the >outward interface, and R-P tunnels will always be set up on the inward >interface. If you don't do things this way then elements of your RAN >will be exposed to the Internet at large, which is not a good idea. >Go look under your couch cushions for some change and buy a second >ethernet card. > >-Pete > > >Patrice Calhoun (PC) writes: > >PC> But the replies from the Home Agent would come back on port 434, unless the >PC> FA forwarded the request from another port (and I am not sure that all >PC> implementations support this). Therefore, it sounds like this is *still* >PC> a problem. > >PC> No? > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 7 20:36:37 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25202 for ; Mon, 7 Feb 2000 20:36:32 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.98633240@standards.nortelnetworks.com>; Mon, 7 Feb 2000 20:33:30 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31007 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 7 Feb 2000 20:32:04 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FF41F3E0@standards.nortelnetworks.com>; Mon, 7 Feb 2000 20:22:04 -0500 Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id CAA00596; Tue, 8 Feb 2000 02:24:25 +0100 (MET) Received: from ericsson.com by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id CAA07515; Tue, 8 Feb 2000 02:24:24 +0100 X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 References: <200002071753.JAA15796@nasnfs.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <389F702A.C71EEF59@ericsson.com> Date: Mon, 7 Feb 2000 17:23:54 -0800 Reply-To: Eva Gustafsson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Eva Gustafsson Organization: Ericsson Research Subject: Re: [MOBILE-IP] Cleanup of Mobile-IP milestones X-To: pcalhoun@eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Pat, >> Dec 99 Submit draft capturing cellular requirements to IESG as an >> Informational RFC. > I am not sure what this is. If we are talking about the joint Ericsson/Telia > draft, then this is GSM-specific, and does not take into account the TR45.6 > work. In fact, the TR45.6 draft never actually became a WG work item. So we > have two choices, either 1) combine the GSM and CDMA draft, or 2) pick one > and cross our fingers. Option 1 is quite interesting, and is likely to > create a very tense political situation, but would be nonetheless entertaining > while 2) is useless (IMHO). Yes, this is about the Ericsson/Telia draft, and I don't consider it GSM-specific. As a matter of fact, it lists general requirements on Mobile IP, not so much cellular-specific, but requirements on Mobile IP as an access-independent macro-mobility solution. As such, it is equally applicable to cdma2000. If anyone wants to add requirements or aspects to the draft, I will be happy to include them. /Eva Eva Gustafsson Ericsson Inc. 1555 Adams Drive Menlo Park, CA 94025 USA +1 (510) 305-6107 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 8 02:34:16 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12031 for ; Tue, 8 Feb 2000 02:34:15 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8B2F9B40@standards.nortelnetworks.com>; Tue, 8 Feb 2000 2:31:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31423 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 02:30:23 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7336AC90@standards.nortelnetworks.com>; Tue, 8 Feb 2000 2:30:22 -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 XAA14904 for ; Mon, 7 Feb 2000 23:32:45 -0800 (PST) Received: from antley.eng.sun.com (antley.Eng.Sun.COM [129.146.86.225]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA24418 for ; Mon, 7 Feb 2000 23:32:43 -0800 (PST) Received: from antley (antley [129.146.86.225]) by antley.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA06585; Mon, 7 Feb 2000 23:32:25 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: uUrG61wt0Ol1QlDPvS0quQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Message-ID: <200002080732.XAA06585@antley.eng.sun.com> Date: Mon, 7 Feb 2000 23:32:25 -0800 Reply-To: Carl Williams Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Carl Williams Subject: [MOBILE-IP] Mobile IPv4/Mobile IPv6/DIAMETER interoperability testing alias To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM An alias has been setup for those participating in Connectathon 2000 interoperability testing for: Mobile IPv4 DIAMETER Mobile IPv6 We have a large group of vendors and implementations that will be participating this year for interoperability testing for Mobile IP protocols including Mobile IPv6. As such, an alias has been setup for helping sort out planning/testing issues among those participating in the bakeoff. You can send mail to with the following command in the body of your email message: subscribe mip-cthon In addition to performing interoperability and conformance testing for Mobile IPv4/Mobile IPv6/DIAMETER, presentations will also be given on related topics. This year connectathon 2000 will also be sponsoring a "IPv6 Mobility & Wireless Roundtable". More details on the Roundtable will be sent out to the Mobile IP alias in the coming week. To register for Connectathon 2000 or for more information, see: www.connectathon.org The Mobile IPv4/DIAMETER/Mobile IPv6 testing will be from Monday, March 6 through Thursday, March 9. The "IPv6 Mobility & Wireless Roundtable" will be held on Monday, March 6 from 4:00pm-6:00pm. Details on the roundtable will be posted on the connectathon web site and sent out to the Mobile IP alias a bit later this week. Carl From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 8 02:49:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12104 for ; Tue, 8 Feb 2000 02:49:22 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A5D34CB0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 2:46:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31471 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 02:44:46 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.75D0CD80@standards.nortelnetworks.com>; Tue, 8 Feb 2000 2:44:46 -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 XAA20778 for ; Mon, 7 Feb 2000 23:47:06 -0800 (PST) Received: from antley.eng.sun.com (antley.Eng.Sun.COM [129.146.86.225]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA25381 for ; Mon, 7 Feb 2000 23:47:00 -0800 (PST) Received: from antley (antley [129.146.86.225]) by antley.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA06611; Mon, 7 Feb 2000 23:46:42 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3MmcUt/PmyLgozxEauGsLw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Message-ID: <200002080746.XAA06611@antley.eng.sun.com> Date: Mon, 7 Feb 2000 23:46:42 -0800 Reply-To: Carl Williams Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Carl Williams Subject: [MOBILE-IP] Connectathon Deadline 2/14/00 (MIP, MIPv6, DIAMETER) To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ***** DEADLINE for Connectathon 2000 is 2/14/00 **** Connectathon 2000 is hosting Mobile IPv4, DIAMETER and Mobile IPv6 interoperability and conformance testing. Many vendors and implementations have registered for these protocols. If you are still interested in participating and have not yet registered, please see www.connectathon.org or contact Audrey Van Belleghem at cthon@sun.com. Thanks. Carl --------------------------------------------------------------------- There is only 1 week until Connectathon registration closes. Please be sure to have faxed in your registration forms and sent in your payment. If you are waiting to receive your company check, please fax in your forms at this time. Payment can follow (please let me know when payment will be received). If you have registered but have not provided the names of the individuals from your company, please do so by the Feb. 14, 2000 deadline. All booths need to be registered so we can obtain fire marshall approval for our event at San Jose's Parkside Hall. Please feel free to contact me with any questions. We are looking forward to welcoming you to Connectathon 2000! Audrey Van Belleghem Connectathon Manager cthon@sun.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 8 07:12:52 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14719 for ; Tue, 8 Feb 2000 07:12:52 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6C4BAB70@standards.nortelnetworks.com>; Tue, 8 Feb 2000 7:09:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31678 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 07:07:57 -0500 Received: from tsbgw.wide.toshiba.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.39746160@standards.nortelnetworks.com>; Tue, 8 Feb 2000 7:07:56 -0500 Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id VAA04025; Tue, 8 Feb 2000 21:10:09 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id VAA23496; Tue, 8 Feb 2000 21:10:08 +0900 (JST) Received: from tanuki (tanuki.isl.rdc.toshiba.co.jp [133.196.16.162]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with SMTP id VAA08129; Tue, 8 Feb 2000 21:10:08 +0900 (JST) References: <200002071634.IAA13954@nasnfs.eng.sun.com> X-Mailer: Datula version 1.21.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200002081210.VAA08129@isl.rdc.toshiba.co.jp> Date: Tue, 8 Feb 2000 21:20:32 +0900 Reply-To: Yoshiyuki Tsuda Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yoshiyuki Tsuda Organization: Corporate R&D Center, Toshiba Corporation Subject: Re: [MOBILE-IP] Registration Keys draft and D-H key exchanges X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200002071634.IAA13954@nasnfs.eng.sun.com> Hello, Pat, I still cannot abandon another approach of passing key data between FAs. Some modifications are attached at the bottom of this email; I'll appreciate, if you give me a punch: On Mon, 7 Feb 2000 08:32:09 -0800, Patrice Calhoun wrote: >> >> >On Fri, 4 Feb 2000 08:29:44 -0800, Charles E. Perkins wrote: >> >>> To summarize: >> >>> - I propose to make the Diffie-Hellman work by elliptic curve groups >> >>> in the default case >> >>> - I propose to have the key established by an exchange between the >> >>> foreign agent and home agent, to relieve computational and bandwidth >> >>> requirements on the mobile node >> >>> - I propose a new extension to Agent Advertisements containing a >> >>> 32-bit digest for the D-H computed value to be used. >> >>> - I propose to add support for the recent proposal for passing opaque >> >>> key data from the mobile node to the new foreign agent. >> > >> > How about passing opaque key data from the previous FA to the new FA ? >> > >> > I agree with you that it's more efficient to pass key data from the MN to >> > a new FA. But, I think, there may be some network operators who resist >> > believing MN-supplied key data blindly. >> > As another approach, it's possible to pass the key data from the previous >> > FA to the new FA, I think. >> > >> > This approach works as follows: >> > 1) All FAs in the same administrative domain advertise the same NAI, as >> > someone wrote. >> > 2) In case of movements within the same administrative domain, an MN sends >> > a registration request with a Mobile-Foreign and a Mobile-Home auth >> > extensions, instead with a NAI and an MN-AAA auth extensions. The >> > destination IP address of this request becomes the previous FA's address. >> > 3) The new FA can know the previous FA by the destination address. >> > 4) By a smooth hand-off and/or a key retrieving mehtod, the new FA can >> > receive the key data from the previous FA. >> > >> > I'd like to know this approach is acceptable by the keying philosophy or not. >> >> The issue that I have with this approach is that if the FA require that the >> MN-FA auth be authenticated prior to forwarding the registration message to the >> HA, it would impose additional latency by requiring a round trip between the >> FAs to retrieve the keys necessary to authentication the MN-FA. If the MN >> can receive encrypted keys from the old FA, this round trip is eliminated, >> further reducing the latency involved in the hand-off. >> >> PatC To eliminate the round trip between FAs, how about authenticating the first registration request and reply by the old FA, instead of the new FA ? I think, this could be possible by the followings: 1) At the first request after an MN moves to a new FA, the MN sends a request to the new FA, but the destination IP address is the previous FA. 2) The new FA records the request, but simply forwards it to the previous FA. 3) The previous FA authenticates the request, and forwards it to the HA. The previous FA will find the source address isn't its care-of address, but others. 4) After a while, the previous FA receives a reply from the HA. By checking the destination address, it will find the destination is the new FA, then forwards it to the new FA. 5) When the new FA receives this reply, it will enable a Mobile IP communication for the MN. 6) Between this first request and a second request, the new FA will fetch key data from the previous FA by secure communication or by a keying protocol. This approach will probably need an FA-FA authentication extension, but could eliminate the round trip to get key data at the first request. Strange to say, I cannot believe all MNs, although I'm a programmer of an MN. So, I would hesitate to believe the key data supplied by an MN, even with the proposed protecting method. Can you give me confidence ? :) Thanks. -Yoshi From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 8 08:13:57 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18149 for ; Tue, 8 Feb 2000 08:13:57 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FBFA12E0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 8:10:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31788 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 08:09:51 -0500 Received: from gate1.staff.it (194.243.73.151) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.79483D00@standards.nortelnetworks.com>; Tue, 8 Feb 2000 7:59:49 -0500 Received: from kllklk (PPPa44-ResaleRhodeIsland1-4R1163.saturn.bbn.com [4.48.66.199]) by gate1.staff.it (8.9.1/8.9.1) with ESMTP id OAA15932; Tue, 8 Feb 2000 14:50:40 +0100 X-Mailer: Mozilla 4.70 [en] (Win95; I) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <200002081350.OAA15932@gate1.staff.it> Date: Tue, 8 Feb 2000 06:23:33 -0500 Reply-To: Andrew Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Andrew Subject: [MOBILE-IP] You were saying... X-To: gld74f@gate1.staff.it To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA18149 COMPLETE E-COMMERCE SOLUTION FOR US AND INTERNATIONAL MERCHANTS FOR ONLY $69.95 / MONTH!! Finally we are able to serve US-based merchants AND foreigners! No matter where you are located: United States, Asia, Europe, Africa, South America... We will be able to get your Internet Online store up and running faster than you can think. Get your own merchant account, real-time software, shopping cart system and the web hosting for your site. A ONE-STOP deal. NO ONE CAN BEAT OUR PRICE! IF YOU FIND A BETTER DEAL FOR OUR PACKAGE ANYWHERE ELSE, WE WILL MATCH OUR COMPETITOR'S PRICE PLUS GIVE YOU THE FIRST MONTH FOR FREE. You have never seen a package deal like this before: * Your own merchant account with one of the lowest rates in the industry * Real-Time software to accept VISA, MASTERCARD, AMEX, DISCOVER/NOVUS, DINERSCLUB/CARTE BLANCHE, JCB * Direct deposit within 48 hrs into your checking account * Shopping Cart store front software with an easy to use web based interface * Real-Time Credit Card Processing software * Virtual terminal for phone/fax/mail orders * Automated E-mail receipts to your clients * Recurring billing feature with batch uploads * Password generator for membership sites * Automatic batch closing * Address verification system (AVS) * Back office to 24/7 access account history * 50 MB (megabytes) of disk space * 30 GB (gigabyte) of data transfer per month * 25 POP3 E-mail accounts * Unlimited alias E-mail addresses * Live web site statistics * Unlimited FTP uploads * Anonymous FTP * CGI directory for your own scripts * Site control panel * Installation included * Tech support included US based merchants get all this and more for ONLY $69.95 per month and a one time set up fee of $199.00. International merchants pay an additional $1200 one time administration fee and we will establish the following services for you: * US merchant account to accept credit cards * US bank account to receive credit card deposits, weekly account statements faxed to you anywhere in the world * Fictitious name filing to show your web site name on your customers credit card statements * US postal address with mail forwarding once a month to any address worldwide Optionally you can purchase the following modules: * Language module for your shopping cart to set up your online store in up to 10 different languages ($149.95 + $50 installation fee) * Currency module for your shopping cart to browse all items in your store in any currency, hourly updated with real-time currency conversion ($99.95 + $25 installation fee) NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL AT ANYTIME. Reply TODAY and receive our FREE E-mail information package immediately without obligations. If you are located WITHIN the US please Reply to: mailto:svvt@bigfoot.com?subject=US-INFO-PLEASE If you are located OUTSIDE of the US please Reply to: mailto:svvt@bigfoot.com?subject=INTERNATIONAL-INFO-PLEASE ********************************************************* Remove at mailto:notme@windrivers.net?subject=remove ********************************************************* From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 8 08:20:50 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18600 for ; Tue, 8 Feb 2000 08:20:49 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FA5BAFB0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 8:17:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31896 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 08:16:20 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C7A35F50@standards.nortelnetworks.com>; Tue, 8 Feb 2000 8:16:20 -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 FAA10417; Tue, 8 Feb 2000 05:18:39 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs-201.Eng.Sun.COM [129.146.201.28]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA20091; Tue, 8 Feb 2000 05:18:39 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp2.Central.Sun.COM [129.147.36.137]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id FAA09013; Tue, 8 Feb 2000 05:18:30 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-ID: <200002081318.FAA09013@nasnfs.eng.sun.com> Date: Tue, 8 Feb 2000 05:16:07 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] Registration Keys draft and D-H key exchanges X-To: Yoshiyuki Tsuda To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit >Hello, Pat, > > I still cannot abandon another approach of passing key data between FAs. > Some modifications are attached at the bottom of this email; I'll appreciate, > if you give me a punch: > >On Mon, 7 Feb 2000 08:32:09 -0800, Patrice Calhoun wrote: >>> >>> >On Fri, 4 Feb 2000 08:29:44 -0800, Charles E. Perkins wrote: >>> >>> To summarize: >>> >>> - I propose to make the Diffie-Hellman work by elliptic curve groups >>> >>> in the default case >>> >>> - I propose to have the key established by an exchange between the >>> >>> foreign agent and home agent, to relieve computational and bandwidth >>> >>> requirements on the mobile node >>> >>> - I propose a new extension to Agent Advertisements containing a >>> >>> 32-bit digest for the D-H computed value to be used. >>> >>> - I propose to add support for the recent proposal for passing opaque >>> >>> key data from the mobile node to the new foreign agent. >>> > >>> > How about passing opaque key data from the previous FA to the new FA ? >>> > >>> > I agree with you that it's more efficient to pass key data from the MN to >>> > a new FA. But, I think, there may be some network operators who resist >>> > believing MN-supplied key data blindly. >>> > As another approach, it's possible to pass the key data from the previous >>> > FA to the new FA, I think. >>> > >>> > This approach works as follows: >>> > 1) All FAs in the same administrative domain advertise the same NAI, as >>> > someone wrote. >>> > 2) In case of movements within the same administrative domain, an MN sends >>> > a registration request with a Mobile-Foreign and a Mobile-Home auth >>> > extensions, instead with a NAI and an MN-AAA auth extensions. The >>> > destination IP address of this request becomes the previous FA's >address. >>> > 3) The new FA can know the previous FA by the destination address. >>> > 4) By a smooth hand-off and/or a key retrieving mehtod, the new FA can >>> > receive the key data from the previous FA. >>> > >>> > I'd like to know this approach is acceptable by the keying philosophy or >not. >>> >>> The issue that I have with this approach is that if the FA require that the >>> MN-FA auth be authenticated prior to forwarding the registration message to >the >>> HA, it would impose additional latency by requiring a round trip between the >>> FAs to retrieve the keys necessary to authentication the MN-FA. If the MN >>> can receive encrypted keys from the old FA, this round trip is eliminated, >>> further reducing the latency involved in the hand-off. >>> >>> PatC > > To eliminate the round trip between FAs, how about authenticating the first > registration request and reply by the old FA, instead of the new FA ? > > I think, this could be possible by the followings: > 1) At the first request after an MN moves to a new FA, the MN sends a > request to the new FA, but the destination IP address is the previous FA. > 2) The new FA records the request, but simply forwards it to the previous > FA. > 3) The previous FA authenticates the request, and forwards it to the HA. > The previous FA will find the source address isn't its care-of address, > but others. > 4) After a while, the previous FA receives a reply from the HA. By checking > the destination address, it will find the destination is the new FA, then > forwards it to the new FA. > 5) When the new FA receives this reply, it will enable a Mobile IP > communication for the MN. > 6) Between this first request and a second request, the new FA will fetch > key data from the previous FA by secure communication or by a keying > protocol. Interesting. A hierarchical approach, without being hierarchical. > > This approach will probably need an FA-FA authentication extension, but > could eliminate the round trip to get key data at the first request. > > Strange to say, I cannot believe all MNs, although I'm a programmer of an MN. > So, I would hesitate to believe the key data supplied by an MN, even with the > proposed protecting method. hmmm... if you really don't want to trust the Mobile, then I would prefer to see the keying information be passed in the binding update, as defined in the route opt. draft. Perhaps I don't see your problem here, but why do you need to trust the mobile? The draft in question requires that the keying material be encrypted by symmetric or assymetric keys only known to the FAs. The resulting key will look like a bunch of opaque bits to the Mobile. If the encryption key used by the Foreign Agent is sufficiently strong, I don't see a problem. A possible problem would be for the Mobile to simply send junk, wasting the Foreign Agent's cycles by decrypting a blob that will result in an invalid key. > > Can you give me confidence ? :) Was that enough? PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 8 13:01:45 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05108 for ; Tue, 8 Feb 2000 13:01:45 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.30C22940@standards.nortelnetworks.com>; Tue, 8 Feb 2000 12:58:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32395 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 12:57:03 -0500 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.98E2B9B0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 12:47:02 -0500 Received: from smtp.usemail.com ([4.18.60.20]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id LAA23148 for ; Tue, 8 Feb 2000 11:49:21 -0600 (CST) Received: from empalrio ([171.217.181.101]) by smtp.usemail.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id com; Tue, 8 Feb 2000 09:40:20 -0800 Message-ID: <200002081749.LAA23148@hosaka.smallworks.com> Date: Tue, 8 Feb 2000 11:49:21 -0600 Reply-To: pamela@MAIL.KMSP.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: pamela@MAIL.KMSP.COM Subject: [MOBILE-IP] Quick cash secret banking system To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM QUICK CASH SECRET BANKING SYSTEM Just revealed to the general public at last! Read this carefully please. Simply By Opening These "Special" Accounts you can easily make up to $1500+/Week! Easy Fast Fun Let New York Financial GENIUS show you how to make $1500+/week! Guaranteed Fast CA$H! HOW? By simply opening "special" bank accounts and doing one hour daily legal bank transaction anywhere in the world! The "Quick Cash Secret Banking System" secrets of the Rich & Powerful revealed at last! For the full, exciting details, mailto:bankcash1@newmail.net To unsubscribe mailto:unubscribe208@newmail.net From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 8 16:07:24 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11119 for ; Tue, 8 Feb 2000 16:07:24 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.16C75140@standards.nortelnetworks.com>; Tue, 8 Feb 2000 16:03:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32699 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 16:02:09 -0500 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.74D68500@standards.nortelnetworks.com>; Tue, 8 Feb 2000 15:52:09 -0500 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (VWALL-IN-motgate2 2.0) with ESMTP id NAA13208 for ; Tue, 8 Feb 2000 13:54:33 -0700 (MST)] Received: [from email1.wes.mot.com (email1.wes.mot.com [154.56.3.101]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id NAA25390 for ; Tue, 8 Feb 2000 13:54:32 -0700 (MST)] Received: by email1.wes.mot.com with Internet Mail Service (5.5.2650.21) id <1CLKQR8H>; Tue, 8 Feb 2000 14:54:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <51F347B016ADD011963200805FC1456204BCBF5A@email1.wes.mot.com> Date: Tue, 8 Feb 2000 14:54:27 -0600 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: Re: [MOBILE-IP] Cleanup of Mobile-IP milestones X-To: Eva Gustafsson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Eva, we spoke some time ago about what you wanted to do with this draft. At one point you'd dropped it and then were thinking of reviving it. Do you know want to continue to pursue it as an informational RFC? For the rest of the group, if the draft isn't really cellular specific, does the WG think that it adequately encompasses the cellular requirements that we had for this work item? Phil -----Original Message----- From: Eva Gustafsson [mailto:eva.gustafsson@ERICSSON.COM] Sent: Monday, February 07, 2000 7:24 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Cleanup of Mobile-IP milestones Hello Pat, >> Dec 99 Submit draft capturing cellular requirements to IESG as an >> Informational RFC. > I am not sure what this is. If we are talking about the joint Ericsson/Telia > draft, then this is GSM-specific, and does not take into account the TR45.6 > work. In fact, the TR45.6 draft never actually became a WG work item. So we > have two choices, either 1) combine the GSM and CDMA draft, or 2) pick one > and cross our fingers. Option 1 is quite interesting, and is likely to > create a very tense political situation, but would be nonetheless entertaining > while 2) is useless (IMHO). Yes, this is about the Ericsson/Telia draft, and I don't consider it GSM-specific. As a matter of fact, it lists general requirements on Mobile IP, not so much cellular-specific, but requirements on Mobile IP as an access-independent macro-mobility solution. As such, it is equally applicable to cdma2000. If anyone wants to add requirements or aspects to the draft, I will be happy to include them. /Eva Eva Gustafsson Ericsson Inc. 1555 Adams Drive Menlo Park, CA 94025 USA +1 (510) 305-6107 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 8 16:12:07 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11263 for ; Tue, 8 Feb 2000 16:12:06 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5E92FC90@standards.nortelnetworks.com>; Tue, 8 Feb 2000 16:05:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32706 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 16:04:22 -0500 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C37D1A20@standards.nortelnetworks.com>; Tue, 8 Feb 2000 15:54:21 -0500 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id WAA28872 for ; Tue, 8 Feb 2000 22:56:45 +0200 (EET) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id WAA07422 for ; Tue, 8 Feb 2000 22:56:44 +0200 (EET) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <1RM3D1RH>; Tue, 8 Feb 2000 14:56:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B9295BD@daeis07nok> Date: Tue, 8 Feb 2000 14:56:05 -0600 Reply-To: Raj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Raj.Patil@NOKIA.COM Subject: [MOBILE-IP] RFC2002 bis To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, At the last IETF meeting in Washington D.C we concluded that RFC2002 bis would obsolete the existing Mobile IP for IPv4 RFC (2002). Charles Perkins has published the latest version of the draft (http://www.iprg.nokia.com/~charliep/txt/mobileip/mobileip.txt) and has incorporated suggestions made on the discussion list on various issues. This is the time to make comments and suggestions to the draft for consideration and debate. Please review the new version of RFC2002 bis and provide your comments and feedback. -Basavaraj Patil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 8 16:25:23 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11530 for ; Tue, 8 Feb 2000 16:25:22 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7C7473E0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 16:21:00 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32798 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 16:20:11 -0500 Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F9B1FC30@standards.nortelnetworks.com>; Tue, 8 Feb 2000 16:10:11 -0500 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (VWALL-IN-ftpbox 2.0) with ESMTP id OAA06371 for ; Tue, 8 Feb 2000 14:12:35 -0700 (MST)] Received: [from email1.wes.mot.com (email1.wes.mot.com [154.56.3.101]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA04766 for ; Tue, 8 Feb 2000 14:12:35 -0700 (MST)] Received: by email1.wes.mot.com with Internet Mail Service (5.5.2650.21) id <1CLKQR09>; Tue, 8 Feb 2000 15:12:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <51F347B016ADD011963200805FC1456204BCBF5D@email1.wes.mot.com> Date: Tue, 8 Feb 2000 15:12:30 -0600 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: Re: [MOBILE-IP] Cleanup of Mobile-IP milestones X-To: "pcalhoun@ENG.SUN.COM" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Pat, thanks for raising this issue. I agree we should update this, mostly along the lines you suggest. Embedded are adjustments. If there are no major complaints from the WG, we will do so. Phil Here is my proposal: > Jul 96 Submit the IPv4 Mobile Host Protocol to the IESG as a Proposed > Standard. Mark as done. Agree. > Dec 96 Submit the IPv6 Mobile Host Protocol to the IESG as a Proposed > Standard. Delete, since it is a duplicate entry. Agree. > Mar 97 Review the WG charter and update as needed. I assume that this task was completed, and therefore can be marked as done. Agree. >Jun 99 Review the WG charter and update based on current needs and > focus. See previous comment. Agree. >Jun 99 Submit Internet-Draft for NAI support in Mobile IP to IESG for > consideration as a Proposed Standard. Mark as done. Agree. >Aug 99 Review the use of AAA in Mobile IP to support inter-domain and > intra-domain mobility and dynamic home agent assignment. Is someone on the hook to get this done? Is this simply part of the AAA requirements, and if so, then state it. It really isn't obvious. BTW, we missed that deadline big time, let's pick another random completion date :) See next bullet. >Dec 99 Submit draft on using AAA in Mobile IP for inter-domain and > intra-domain mobility as a proposed standard. See previous comment. I believe the group's involvement in this has become specifying Mobile-IP requirements for AAA. We have a draft of that already. Perhaps we should pick a date of Jul 2000 for compleetion in case there is some iteration needed and make it a single bullet? >Dec 99 Submit draft capturing cellular requirements to IESG as an > Informational RFC. I am not sure what this is. If we are talking about the joint Ericsson/Telia draft, then this is GSM-specific, and does not take into account the TR45.6 work. In fact, the TR45.6 draft never actually became a WG work item. So we have two choices, either 1) combine the GSM and CDMA draft, or 2) pick one and cross our fingers. Option 1 is quite interesting, and is likely to create a very tense political situation, but would be nonetheless entertaining while 2) is useless (IMHO). The completion date also needs updating. I sent an email in response to Eva about this. I'd like the working group to decide what it wants to do for this. From what I know about the two worlds of GSM and IMT-2000, not to mention the others, what they want from mobile IP are quite different. I'm also still not really sure what the purpose of such a document would be anyway. Oh, and it looks as if Raj's e-mail address needs updating on the web page as well. Yes. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 8 16:29:11 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11619 for ; Tue, 8 Feb 2000 16:29:11 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0C770F70@standards.nortelnetworks.com>; Tue, 8 Feb 2000 16:25:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32856 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 16:23:09 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C666F6D0@standards.nortelnetworks.com>; Tue, 8 Feb 2000 16:23:04 -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 NAA03826; Tue, 8 Feb 2000 13:25:27 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs-201.Eng.Sun.COM [129.146.201.28]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA11024; Tue, 8 Feb 2000 13:25:25 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp2.Central.Sun.COM [129.147.36.137]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id NAA20447; Tue, 8 Feb 2000 13:25:16 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-ID: <200002082125.NAA20447@nasnfs.eng.sun.com> Date: Tue, 8 Feb 2000 13:28:46 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] Cleanup of Mobile-IP milestones X-To: Roberts Phil-QA3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Looks good. PatC > >Pat, > > thanks for raising this issue. I agree we should update this, >mostly along the lines you suggest. Embedded are adjustments. If there are >no major complaints from the WG, we will do so. > >Phil > >Here is my proposal: > >> Jul 96 Submit the IPv4 Mobile Host Protocol to the IESG as a >Proposed >> Standard. >Mark as done. >Agree. > >> Dec 96 Submit the IPv6 Mobile Host Protocol to the IESG as a >Proposed >> Standard. >Delete, since it is a duplicate entry. >Agree. > >> Mar 97 Review the WG charter and update as needed. >I assume that this task was completed, and therefore can be marked as done. >Agree. > >>Jun 99 Review the WG charter and update based on current needs and >> focus. >See previous comment. >Agree. > >>Jun 99 Submit Internet-Draft for NAI support in Mobile IP to IESG >for >> consideration as a Proposed Standard. >Mark as done. >Agree. > >>Aug 99 Review the use of AAA in Mobile IP to support inter-domain >and >> intra-domain mobility and dynamic home agent assignment. >Is someone on the hook to get this done? Is this simply part of the AAA >requirements, and if so, then state it. It really isn't obvious. BTW, we >missed >that deadline big time, let's pick another random completion date :) >See next bullet. > >>Dec 99 Submit draft on using AAA in Mobile IP for inter-domain and >> intra-domain mobility as a proposed standard. >See previous comment. >I believe the group's involvement in this has become specifying Mobile-IP >requirements for AAA. We have a draft of that already. Perhaps we should >pick a date of Jul 2000 for compleetion in case there is some iteration >needed and make it a single bullet? > > > > >>Dec 99 Submit draft capturing cellular requirements to IESG as an >> Informational RFC. >I am not sure what this is. If we are talking about the joint Ericsson/Telia >draft, then this is GSM-specific, and does not take into account the TR45.6 >work. In fact, the TR45.6 draft never actually became a WG work item. So we >have two choices, either 1) combine the GSM and CDMA draft, or 2) pick one >and cross our fingers. Option 1 is quite interesting, and is likely to >create a very tense political situation, but would be nonetheless >entertaining >while 2) is useless (IMHO). The completion date also needs updating. >I sent an email in response to Eva about this. I'd like the working group >to decide what it wants to do for this. From what I know about the two >worlds of GSM and IMT-2000, not to mention the others, what they want from >mobile IP are quite different. I'm also still not really sure what the >purpose of such a document would be anyway. > > >Oh, and it looks as if Raj's e-mail address needs updating on the web page >as well. >Yes. > >PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 8 16:29:11 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11621 for ; Tue, 8 Feb 2000 16:29:11 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0D41D980@standards.nortelnetworks.com>; Tue, 8 Feb 2000 16:25:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32807 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 16:23:43 -0500 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.780E9E30@standards.nortelnetworks.com>; Tue, 8 Feb 2000 16:13:43 -0500 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (VWALL-IN-motgate2 2.0) with ESMTP id OAA06411 for ; Tue, 8 Feb 2000 14:16:07 -0700 (MST)] Received: [from email1.wes.mot.com (email1.wes.mot.com [154.56.3.101]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA11670 for ; Tue, 8 Feb 2000 14:16:06 -0700 (MST)] Received: by email1.wes.mot.com with Internet Mail Service (5.5.2650.21) id <1CLKQSAL>; Tue, 8 Feb 2000 15:16:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <51F347B016ADD011963200805FC1456204BCBF5F@email1.wes.mot.com> Date: Tue, 8 Feb 2000 15:15:57 -0600 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: Re: [MOBILE-IP] RFC2002 bis X-To: "Raj.Patil@NOKIA.COM" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM It's important to turn this around quickly if we want it to replace 2002 and then move this from proposed standard to draft standard. We discussed in Washington about the amount of work that will be involved from moving to proposed to draft and agreed that we should update 2002 while working on getting enough implementations to move to draft standard. Getting the replacement done quickly would allow us to get to draft standard this year, hopefully. Phil -----Original Message----- From: Raj.Patil@NOKIA.COM [mailto:Raj.Patil@NOKIA.COM] Sent: Tuesday, February 08, 2000 2:56 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] RFC2002 bis Hello, At the last IETF meeting in Washington D.C we concluded that RFC2002 bis would obsolete the existing Mobile IP for IPv4 RFC (2002). Charles Perkins has published the latest version of the draft (http://www.iprg.nokia.com/~charliep/txt/mobileip/mobileip.txt) and has incorporated suggestions made on the discussion list on various issues. This is the time to make comments and suggestions to the draft for consideration and debate. Please review the new version of RFC2002 bis and provide your comments and feedback. -Basavaraj Patil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 8 21:40:35 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15170 for ; Tue, 8 Feb 2000 21:40:34 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.977BD710@standards.nortelnetworks.com>; Tue, 8 Feb 2000 21:36:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33409 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 21:35:40 -0500 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.71C3ED00@standards.nortelnetworks.com>; Tue, 8 Feb 2000 21:35:39 -0500 Received: (from gdommety@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA09482; Tue, 8 Feb 2000 18:38:04 -0800 (PST) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200002090238.SAA09482@omega.cisco.com> Date: Tue, 8 Feb 2000 18:38:04 -0800 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: Re: [MOBILE-IP] R-P agent should listen on port 434? X-To: Ashish.Mehta@eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200002050408.UAA04103@jurassic.eng.sun.com> from "Ashish Mehta" at Feb 04, 2000 08:07:13 PM Content-Transfer-Encoding: 7bit I know there has been some discussion after this. > draft-ietf-mobileip-3gwireless-ext-02.txt alludes to R-P registration > messages being sent to UDP port 434. Does this imply that the mobile > IP agent (processing the MobileIP registrations) and the R-P agent > (processing the R-P registrations) are one and the same daemon/process? > It certianly appears so, since UDP would not be able to distinguish > between two unicast listeners on the same port. In this case it might be good to implment as one process. Implementation as one process or multiple depends of your system and design. Although the following example is a little off, hope it convays the meaning. One can implement FA and HA functionality as one process or as two processes or even as three processs as long as they communicate with each other. Similarly one can implement Mobile IP and RP message processing in one process or multiple. If you want to implelent as two, then you might want some third process to do the listening and communicate. If you can bind your socket an IP address as well than you can use different IP addresses and implement them. I am not saying that this is a best way to do this but just some random thoughts. > > Would'nt this be a problem for vendors who want to productize only > a mobile IP solution and use a third party solution for the R-P > agent? I guess you will run into the same problem if one implements some of the extensions and want to use other extensions from an other implementation. -Gopal From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 8 22:14:30 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16259 for ; Tue, 8 Feb 2000 22:14:30 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.599B7090@standards.nortelnetworks.com>; Tue, 8 Feb 2000 22:10:46 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33457 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 8 Feb 2000 22:09:51 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.385BEF40@standards.nortelnetworks.com>; Tue, 8 Feb 2000 22:09:51 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA29011; Tue, 8 Feb 2000 20:11:49 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id TAA27895; Tue, 8 Feb 2000 19:11:50 -0800 (PST) Received: from krsna (krsna.Eng.Sun.COM [129.146.86.245]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA01978; Tue, 8 Feb 2000 19:11:48 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SbhH6rT2ZezwPBJ6c5Jn8Q== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Message-ID: <200002090311.TAA01978@jurassic.eng.sun.com> Date: Tue, 8 Feb 2000 19:10:55 -0800 Reply-To: Ashish Mehta Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ashish Mehta Subject: Re: [MOBILE-IP] R-P agent should listen on port 434? X-To: gdommety@cisco.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > >I know there has been some discussion after this. > > > >> draft-ietf-mobileip-3gwireless-ext-02.txt alludes to R-P registration >> messages being sent to UDP port 434. Does this imply that the mobile >> IP agent (processing the MobileIP registrations) and the R-P agent >> (processing the R-P registrations) are one and the same daemon/process? >> It certianly appears so, since UDP would not be able to distinguish >> between two unicast listeners on the same port. > >In this case it might be good to implment as one process. > The question I had in mind was essentially: as an implementor do I have a choice of implementing the R-P and MIP agent as seperate processes. So, it is not as much as what I can do (which your mail seems to address) but what am I allowed to do.Looking at the spec and the ensuing discussion I understand that it may not be possible to seperate them (and hence the clarification text suggested by Pat). Correct me if my understanding is incorrect. ashish >Implementation as one process or multiple depends of your system and >design. Although the following example is a little off, hope it >convays the meaning. One can implement FA and HA functionality as one >process or as two processes or even as three processs as long as they >communicate with each other. Similarly one can implement Mobile IP >and RP message processing in one process or multiple. > >If you want to implelent as two, then you might want some third >process to do the listening and communicate. If you can bind your >socket an IP address as well than you can use different IP addresses >and implement them. > >I am not saying that this is a best way to do this but just some >random thoughts. > >> >> Would'nt this be a problem for vendors who want to productize only >> a mobile IP solution and use a third party solution for the R-P >> agent? > >I guess you will run into the same problem if one implements some of >the extensions and want to use other extensions from an other >implementation. > >-Gopal > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 9 09:12:55 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06647 for ; Wed, 9 Feb 2000 09:12:55 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.27DBAC30@standards.nortelnetworks.com>; Wed, 9 Feb 2000 9:07:57 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34233 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 09:07:40 -0500 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1AE753D0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 9:07:35 -0500 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id QAA15251 for ; Wed, 9 Feb 2000 16:09:59 +0200 (EET) Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id QAA05767 for ; Wed, 9 Feb 2000 16:09:53 +0200 (EET) Received: by esebh01nok with Internet Mail Service (5.5.2650.10) id <1L6HHXV6>; Wed, 9 Feb 2000 16:07:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 9 Feb 2000 16:06:22 +0200 Reply-To: jonne.soininen@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: jonne.soininen@NOKIA.COM Subject: Re: [MOBILE-IP] Cleanup of Mobile-IP milestones X-To: qa3445@EMAIL1.WES.MOT.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Eva & Phil, ignoring Eva's comment about the draft not being cellular specific, I think that the draft adequately updated reflects cellular systems' requirements (GSM and others) for Mobile IP in general. Thus, it should not be dropped if Eva is still willing to update it. Cheers, Jonne. > -----Original Message----- > From: EXT Roberts Phil-QA3445 [mailto:qa3445@EMAIL1.WES.MOT.COM] > Sent: 08. February 2000 22:54 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Cleanup of Mobile-IP milestones > > > Eva, > > we spoke some time ago about what you wanted to do > with this draft. > At one point you'd dropped it and then were thinking of > reviving it. Do you > know want to continue to pursue it as an informational RFC? > > For the rest of the group, if the draft isn't really cellular > specific, does the WG think that it adequately encompasses > the cellular > requirements that we had for this work item? > > Phil > > > -----Original Message----- > From: Eva Gustafsson [mailto:eva.gustafsson@ERICSSON.COM] > Sent: Monday, February 07, 2000 7:24 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Cleanup of Mobile-IP milestones > > > Hello Pat, > > >> Dec 99 Submit draft capturing cellular > requirements to IESG as an > >> Informational RFC. > > > I am not sure what this is. If we are talking about the joint > Ericsson/Telia > > draft, then this is GSM-specific, and does not take into account the > TR45.6 > > work. In fact, the TR45.6 draft never actually became a WG > work item. So > we > > have two choices, either 1) combine the GSM and CDMA draft, > or 2) pick one > > and cross our fingers. Option 1 is quite interesting, and > is likely to > > create a very tense political situation, but would be nonetheless > entertaining > > while 2) is useless (IMHO). > > Yes, this is about the Ericsson/Telia draft, and I don't consider it > GSM-specific. > As a matter of fact, it lists general requirements on Mobile > IP, not so much > cellular-specific, but requirements on Mobile IP as an > access-independent > macro-mobility solution. As such, it is equally applicable to > cdma2000. > > If anyone wants to add requirements or aspects to the draft, > I will be happy > to > include them. > > /Eva > > > Eva Gustafsson > Ericsson Inc. > 1555 Adams Drive > Menlo Park, CA 94025 > USA > > +1 (510) 305-6107 > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 9 10:48:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08422 for ; Wed, 9 Feb 2000 10:48:58 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C79AFC00@standards.nortelnetworks.com>; Wed, 9 Feb 2000 10:45:28 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34575 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 10:44:14 -0500 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3562D840@standards.nortelnetworks.com>; Wed, 9 Feb 2000 10:34:13 -0500 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id RAA11860; Wed, 9 Feb 2000 17:36:34 +0200 (EET) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id RAA24576; Wed, 9 Feb 2000 17:36:32 +0200 (EET) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <1RM26QCC>; Wed, 9 Feb 2000 09:35:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B9295CF@daeis07nok> Date: Wed, 9 Feb 2000 09:35:14 -0600 Reply-To: Raj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Raj.Patil@NOKIA.COM Subject: Re: [MOBILE-IP] Cleanup of Mobile-IP milestones X-To: jonne.soininen@nokia.com X-cc: eva.gustafsson@ERICSSON.COM, qa3445@email1.wes.mot.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Jonne, The I-D has expired as of Dec 99. Unless there is some interest in this draft and someone willing to commit some time to it, I think we should drop it from the milestones. The draft needs to take into consideration the requirements for multiple cellular technologies (as Pat was mentioning earlier). If you are willing to commit some of your time in updating this draft, then you are most welcome. You may wish to contact Eva (the current editor) and work out the details. Another possibility is that we could find out what from the WG at IETF47 if there is any interest in this work at all and decide on the course of action based on feedback. -Basavaraj >Eva & Phil, > >ignoring Eva's comment about the draft not being cellular specific, I think >that the draft adequately updated reflects cellular systems' requirements >(GSM and others) for Mobile IP in general. Thus, it should not be dropped if >Eva is still willing to update it. > >Cheers, > >Jonne. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 9 11:01:00 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08696 for ; Wed, 9 Feb 2000 11:01:00 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7BCCC950@standards.nortelnetworks.com>; Wed, 9 Feb 2000 10:57:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34623 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 10:56:09 -0500 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DFE761E0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 10:46:09 -0500 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id RAA28924 for ; Wed, 9 Feb 2000 17:48:30 +0200 (EET) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id RAA00752 for ; Wed, 9 Feb 2000 17:48:26 +0200 (EET) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <1RM3DJBR>; Wed, 9 Feb 2000 09:48:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B9295D0@daeis07nok> Date: Wed, 9 Feb 2000 09:47:37 -0600 Reply-To: Raj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Raj.Patil@NOKIA.COM Subject: [MOBILE-IP] Change of affiliation To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, I have changed my affiliation from Nortel Networks to Nokia as of this week. Please contact me at my new e-mail address for all Mobile IP related issues. The Mobile IP page will be updated shortly to reflect the change. Regards, -Basavaraj Patil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 9 11:30:13 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09624 for ; Wed, 9 Feb 2000 11:30:12 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.92A72BD0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 11:26:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34919 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 11:25:14 -0500 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EF794BB0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 11:15:13 -0500 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id SAA05156 for ; Wed, 9 Feb 2000 18:17:39 +0200 (EET) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id SAA14690 for ; Wed, 9 Feb 2000 18:17:38 +0200 (EET) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <1RM3DJK0>; Wed, 9 Feb 2000 10:17:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B9295D4@daeis07nok> Date: Wed, 9 Feb 2000 10:16:48 -0600 Reply-To: Raj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Raj.Patil@NOKIA.COM Subject: [MOBILE-IP] WG Last Call - draft-ietf-mobileip-mier-02.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM We would like to issue a WG last call on the Mobile IP Extensions Rationalization (MIER) draft (draft-ietf-mobileip-mier-02.txt). Please provide your comments and feedback within the next two weeks. WG Last call issued on : Feb 9th, 2000 -Basavaraj Patil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 9 11:53:37 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10349 for ; Wed, 9 Feb 2000 11:53:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D0D320A0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 11:50:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35096 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 11:48:50 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3BD462D0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 11:38:50 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09901; Wed, 9 Feb 2000 11:41:13 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200002091641.LAA09901@ietf.org> Date: Wed, 9 Feb 2000 11:41:13 -0500 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-rfc2002-bis-01.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : IP Mobility Support for IPv4, revised Author(s) : C. Perkins Filename : draft-ietf-mobileip-rfc2002-bis-01.txt Pages : 93 Date : 08-Feb-00 This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc2002-bis-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-rfc2002-bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-rfc2002-bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000208091004.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-rfc2002-bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-rfc2002-bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000208091004.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 9 12:06:49 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10833 for ; Wed, 9 Feb 2000 12:06:47 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A80BC1C0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 12:03:20 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35234 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 12:01:32 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.67ECA820@standards.nortelnetworks.com>; Wed, 9 Feb 2000 12:01:32 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id JAA10083; Wed, 9 Feb 2000 09:03:57 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id JAA06063; Wed, 9 Feb 2000 09:03:57 -0800 X-Virus-Scanned: Wed, 9 Feb 2000 09:03:57 -0800 Nokia Silicon Valley AntiVirus Appliance Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma005817; Wed, 9 Feb 00 09:03:52 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <7B5C0390ACE7D211BC9C0008C7EABA2B9295D4@daeis07nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38A19DF8.2F1911AC@iprg.nokia.com> Date: Wed, 9 Feb 2000 09:03:52 -0800 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] WG Last Call - draft-ietf-mobileip-mier-02.txt X-To: Raj.Patil@NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Basavaraj, I find two parts of the draft to be objectionable. 1. The length field is misaligned. 2. There may be future extensions that do NOT need to correspond to the format suggested in the draft. Therefore, I would like to see the mandatory requirement for conformance relaxed. Regards, Charlie P. Raj.Patil@NOKIA.COM wrote: > > We would like to issue a WG last call on the Mobile IP Extensions > Rationalization (MIER) draft (draft-ietf-mobileip-mier-02.txt). > Please provide your comments and feedback within the next two weeks. > > WG Last call issued on : Feb 9th, 2000 > > -Basavaraj Patil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 9 12:38:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12227 for ; Wed, 9 Feb 2000 12:38:16 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BEA34EE0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 12:32:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35428 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 12:31:22 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.92E02710@standards.nortelnetworks.com>; Wed, 9 Feb 2000 12:31:22 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 9 Feb 2000 11:33:28 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Wed, 9 Feb 2000 12:33:13 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id <13LQJZPV>; Wed, 9 Feb 2000 11:33:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7323.BDD84982" Message-ID: <9A9367D1556AD21182C40000F80930AB010BC21B@crchy28b.us.nortel.com> Date: Wed, 9 Feb 2000 11:33:11 -0600 Reply-To: Mohamed Khalil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohamed Khalil Subject: Re: [MOBILE-IP] WG Last Call - draft-ietf-mobileip-mier-02.txt X-To: "charliep@IPRG.NOKIA.COM" 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_01BF7323.BDD84982 Content-Type: text/plain; charset="ISO-8859-1" Hi Charlie, Your two comments has been taken in consideration in draft-ietf-mobileip-mier-02.txt. Thx MK Nortel Networks -----Original Message----- From: Charles E. Perkins [mailto:charliep@IPRG.NOKIA.COM] Sent: Wednesday, February 09, 2000 11:04 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] WG Last Call - draft-ietf-mobileip-mier-02.txt Hello Basavaraj, I find two parts of the draft to be objectionable. 1. The length field is misaligned. 2. There may be future extensions that do NOT need to correspond to the format suggested in the draft. Therefore, I would like to see the mandatory requirement for conformance relaxed. Regards, Charlie P. Raj.Patil@NOKIA.COM wrote: > > We would like to issue a WG last call on the Mobile IP Extensions > Rationalization (MIER) draft (draft-ietf-mobileip-mier-02.txt). > Please provide your comments and feedback within the next two weeks. > > WG Last call issued on : Feb 9th, 2000 > > -Basavaraj Patil ------_=_NextPart_001_01BF7323.BDD84982 Content-Type: text/html; charset="ISO-8859-1" RE: [MOBILE-IP] WG Last Call - draft-ietf-mobileip-mier-02.txt

Hi Charlie,

Your two comments has been taken in consideration in  draft-ietf-mobileip-mier-02.txt.

Thx
MK

Nortel Networks
-----Original Message-----
From: Charles E. Perkins [mailto:charliep@IPRG.NOKIA.COM]
Sent: Wednesday, February 09, 2000 11:04 AM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] WG Last Call - draft-ietf-mobileip-mier-02.txt


Hello Basavaraj,

I find two parts of the draft to be objectionable.

1. The length field is misaligned.

2. There may be future extensions that do NOT need to
   correspond to the format suggested in the draft.
   Therefore, I would like to see the mandatory
   requirement for conformance relaxed.

Regards,
Charlie P.



Raj.Patil@NOKIA.COM wrote:
>
> We would like to issue a WG last call on the Mobile IP Extensions
> Rationalization (MIER) draft (draft-ietf-mobileip-mier-02.txt).
> Please provide your comments and feedback within the next two weeks.
>
> WG Last call issued on : Feb 9th, 2000
>
> -Basavaraj Patil

------_=_NextPart_001_01BF7323.BDD84982-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 9 12:55:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13055 for ; Wed, 9 Feb 2000 12:55:21 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6C57C640@standards.nortelnetworks.com>; Wed, 9 Feb 2000 12:51:46 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35562 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 12:50:32 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4000C2E0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 12:50:32 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id JAA15708; Wed, 9 Feb 2000 09:52:22 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id JAA25325; Wed, 9 Feb 2000 09:52:22 -0800 X-Virus-Scanned: Wed, 9 Feb 2000 09:52:22 -0800 Nokia Silicon Valley AntiVirus Appliance Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma025027; Wed, 9 Feb 00 09:52:15 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <9A9367D1556AD21182C40000F80930AB010BC21B@crchy28b.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38A1A94F.950A9352@iprg.nokia.com> Date: Wed, 9 Feb 2000 09:52:15 -0800 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] WG Last Call - draft-ietf-mobileip-mier-02.txt X-To: Mohamed Khalil To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Khalil, Thanks for pointing me to the right draft. When I checked with the Internet Drafts search page, I saw _two_ MIER drafts. One was ...-02.txt, and the other was ...-03.txt. I looked at the latter one because I thought it would be newer, without checking the dates. The newer draft does indeed answer my two earlier points. I would request that the following language be deleted: > ...... unless there is an overwhelming > reason not to do so. It doesn't really need to be there, and it doesn't look like language I have seen in any other specification. The intent, as I understand it, is that authors of new specifications would be expected to follow the suggested format unless other considerations dictate otherwise. I suggest also that this draft be considered Informational, since it does not specify the format of data that will be transmitted over a network. Regards, Charlie P. > Mohamed Khalil wrote: > > Hi Charlie, > > Your two comments has been taken in consideration in > draft-ietf-mobileip-mier-02.txt. > > Thx > MK From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 9 13:05:58 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13659 for ; Wed, 9 Feb 2000 13:05:54 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B3142F00@standards.nortelnetworks.com>; Wed, 9 Feb 2000 13:00:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35657 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 12:59:20 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7B1688F0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 12:59:20 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 9 Feb 2000 12:01:01 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Wed, 9 Feb 2000 13:00:44 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id <13LQJ6D9>; Wed, 9 Feb 2000 12:00:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7327.940222F0" Message-ID: <9A9367D1556AD21182C40000F80930AB010BC21E@crchy28b.us.nortel.com> Date: Wed, 9 Feb 2000 12:00:36 -0600 Reply-To: Mohamed Khalil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohamed Khalil Subject: Re: [MOBILE-IP] WG Last Call - draft-ietf-mobileip-mier-02.txt X-To: "Charles E. Perkins" 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_01BF7327.940222F0 Content-Type: text/plain; charset="ISO-8859-1" -----Original Message----- From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] Sent: Wednesday, February 09, 2000 11:52 AM To: Khalil, Mohamed [RICH2:IP15:EXCH] Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] WG Last Call - draft-ietf-mobileip-mier-02.txt Hello Khalil, Thanks for pointing me to the right draft. When I checked with the Internet Drafts search page, I saw _two_ MIER drafts. One was ...-02.txt, and the other was ...-03.txt. I looked at the latter one because I thought it would be newer, without checking the dates. The newer draft does indeed answer my two earlier points. I would request that the following language be deleted: > ...... unless there is an overwhelming > reason not to do so. MK> I will delete this statement. It doesn't really need to be there, and it doesn't look like language I have seen in any other specification. The intent, as I understand it, is that authors of new specifications would be expected to follow the suggested format unless other considerations dictate otherwise. I suggest also that this draft be considered Informational, since it does not specify the format of data that will be transmitted over a network. Regards, Charlie P. > Mohamed Khalil wrote: > > Hi Charlie, > > Your two comments has been taken in consideration in > draft-ietf-mobileip-mier-02.txt. > > Thx > MK ------_=_NextPart_001_01BF7327.940222F0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] WG Last Call - = draft-ietf-mobileip-mier-02.txt

-----Original Message-----
From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
Sent: Wednesday, February 09, 2000 11:52 AM
To: Khalil, Mohamed [RICH2:IP15:EXCH]
Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] WG Last Call - = draft-ietf-mobileip-mier-02.txt



Hello Khalil,

Thanks for pointing me to the right draft.  When = I checked with
the Internet Drafts search page, I saw _two_ MIER = drafts.  One
was ...-02.txt, and the other was ...-03.txt.  = I looked at the
latter one because I thought it would be newer, = without checking
the dates.

The newer draft does indeed answer my two earlier = points.
I would request that the following language be = deleted:

>          = ;       = ......         unless there is = an overwhelming
>    reason not to do so.

MK> I will delete this statement.

It doesn't really need to be there, and it doesn't = look like
language I have seen in any other = specification.  The intent,
as I understand it, is that authors of new = specifications would
be expected to follow the suggested format unless = other
considerations dictate otherwise.

I suggest also that this draft be considered = Informational,
since it does not specify the format of data that = will be
transmitted over a network.

Regards,
Charlie P.



> Mohamed Khalil wrote:
>
> Hi Charlie,
>
> Your two comments has been taken in = consideration in
> draft-ietf-mobileip-mier-02.txt.
>
> Thx
> MK

------_=_NextPart_001_01BF7327.940222F0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 9 14:23:47 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18554 for ; Wed, 9 Feb 2000 14:23:46 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D389CFA0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 14:20:33 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36090 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 14:19:32 -0500 Received: from babbage.ececs.uc.edu (129.137.8.2) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.49698280@standards.nortelnetworks.com>; Wed, 9 Feb 2000 14:09:32 -0500 Received: from wayward.ececs.uc.edu (wayward.ececs.uc.edu [129.137.9.117]) by babbage.ececs.uc.edu (8.9.3+Sun/8.9.3) with ESMTP id OAA26435 for ; Wed, 9 Feb 2000 14:11:55 -0500 (EST) Received: (from sdas@localhost) by wayward.ececs.uc.edu (8.9.3+Sun/8.9.1) id OAA24196 for mobile-ip@standards.nortelnetworks.com; Wed, 9 Feb 2000 14:11:40 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <200002091911.OAA24196@wayward.ececs.uc.edu> Date: Wed, 9 Feb 2000 14:11:40 -0500 Reply-To: Samir Das Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Samir Das Subject: [MOBILE-IP] MobiCom 2000 (note new deadline) To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit -- Final Call for Papers -- MobiCom 2000 The Sixth Annual International Conference on Mobile Computing and Networking August 6-11, 2000 Seaport Hotel at the World Trade Center Boston, Massachusetts, USA ** The paper submission deadline for MobiCom 2000 is approaching. ** ** The new extended deadline is Feb 25, 2000. ** ** Visit http://www.research.telcordia.com/mobicom2000/ for the ** ** complete Call for Papers and submission instructions. ** Sponsored by ACM SIGMOBILE; In cooperation with ACM SIGCOMM and SIGMETRICS; the USENIX Association; the IEE; the IEICE (Japan); KICS (Korea) and the IFIP WG 6.3 -------------------------------------------------------------------- IMPORTANT DATES: Paper submissions due: February 25, 2000 <- extended Notification of acceptance: April 28, 2000 Camera-ready version due: May 26, 2000 -------------------------------------------------------------------- Send email to mobicom2000@research.telcordia.com with any questions or comments about the conference or for more information. Please excuse us if you receive duplicates of this message via different email lists. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 9 19:38:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28233 for ; Wed, 9 Feb 2000 19:38:21 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C9DAB330@standards.nortelnetworks.com>; Wed, 9 Feb 2000 19:35:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36645 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 19:33:29 -0500 Received: from ns1.netbizness.co.uk (195.162.97.113) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.24FFBF50@standards.nortelnetworks.com>; Wed, 9 Feb 2000 19:23:29 -0500 Received: from kllklk [209.206.5.251] by ns1.netbizness.co.uk with ESMTP (SMTPD32-4.07) id A5BB2B20082; Thu, 10 Feb 2000 00:26:35 X-Mailer: Microsoft Outlook Express 4..72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 9 Feb 2000 18:29:42 -0500 Reply-To: Thomas Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Thomas Subject: [MOBILE-IP] New Message To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA28233 *Earn $2000 - $5000 weekly-starting within 1-4 weeks *78% Profit Paid Daily *No Selling *No Risk Guarantee *Work from home, No overhead, or employees. *High Tech Training & Support *Not MLM, 100x more profitable *Multibillion Dollar Travel Industry The most incredible part of our business is that ALL MY CLIENTS CALL ME! DO YOU QUALIFY FOR OUR MENTOR PROGRAM? ACCEPTING ONLY 12 NEW ASSOCIATES This is not a hobby! Serious Inquires Only!! Please reply with the following information NAME: EMAIL ADDRESS: PHONE: BEST TIME TO CALL: TO: mailto:rtxx@iwon.com?subject=more_info FOR MORE INFORMATION If your an entrepreneur or have always wanted to be your own BOSS, read on. We supply state-of-the-art training and a support system that allows you to work your business from your home with just a phone-without cold calling. DO NOT REPLY IF YOU ARE LOOKING FOR A "GET RICH QUICK" SCHEME or some extra cash or if you're lazy. We are only looking for FOCUSED serious entrepreneurs. (Pt/FT) with the DESIRE to improve their lifestyle immediately. /////////////////////////////////////////////////////////// Please remove at mailto:aklt@uymail.com?subject=remove /////////////////////////////////////////////////////////// From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 9 22:30:44 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01597 for ; Wed, 9 Feb 2000 22:30:43 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DB2643D0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 22:27:32 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36847 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 22:26:19 -0500 Received: from hoemail2.firewall.lucent.com (192.11.226.163) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.49F6B670@standards.nortelnetworks.com>; Wed, 9 Feb 2000 22:16:19 -0500 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id WAA10785 for ; Wed, 9 Feb 2000 22:18:44 -0500 (EST) Received: from ihgp24.ih.lucent.com (h135-1-53-29.lucent.com [135.1.53.29]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id WAA10781 for ; Wed, 9 Feb 2000 22:18:43 -0500 (EST) Received: by ihgp24.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id VAA19107; Wed, 9 Feb 2000 21:18:43 -0600 (CST) Received: from lucent.com by ihgp24.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id VAA19054; Wed, 9 Feb 2000 21:18:26 -0600 (CST) X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Original-To: dino@procket.com, tony1@home.net, dmm@cisco.com, pst@juniper.net, stan_hanks@enron.net, TIA TSG-P Mailing List <3gpp2tsgp@ice.lyris.net>, "MOBILE-IP@standards.nortelnetworks.com" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38A22DF9.DB09ABDD@lucent.com> Date: Wed, 9 Feb 2000 21:18:17 -0600 Reply-To: Tom Hiller Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Tom Hiller Organization: Lucent Technologies Subject: [MOBILE-IP] GRE key field X-To: dino@procket.com, tony1@home.net, dmm@cisco.com, pst@juniper.net, stan_hanks@enron.net, TIA TSG-P Mailing List <3gpp2tsgp@ice.lyris.net> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit To the authors of draft-meyer-gre-update-03.txt Based on Mobile IP email between Tony Li and Pat Calhoun it appears that the Key field of the GRE tunnel has a highly uncertain fate. However, the cdma2000 wireless community has plans to use this field, and would like for it to not perish. I assume at least one issue is existing RFC text suggesting the "Key" as being involved with authentication. However, cdma2000 use is to allow the encapsulator to identify the source of the payload to the receiver. Tony suggested some alternate wording may help. It also occurred to me that a field name not related to security might be helpful, so here goes: Original text: Key (4 octets) The Key field contains a four octet number which was inserted by the encapsulator. It may be used by the receiver to authenticate the source of the packet. The techniques for determining authenticity are outside of the scope of this document. The Key field is only present if the Key Present field is set to 1. Proposal: Index (4 octets) The Index field contains a four octet number which was inserted by the encapsulator. The encapsulator may use this field to identify the source of the GRE payload to the receiver. The techniques for determining the identity are outside of the scope of this document. The Index field is only present if the Index Present field is set to 1. The cdma2000 architecture would use GRE independent of whether a user invokes Mobile IP or not, i.e. the user does not see or control the GRE tunnel. In this sense, the field has uses outside of Mobile IP and is generally useful to (some) GRE users. Comments? Thanks, Tom Hiller From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Feb 9 22:58:45 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02568 for ; Wed, 9 Feb 2000 22:58:44 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C7B3A3C0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 22:55:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36916 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 9 Feb 2000 22:53:57 -0500 Received: from sigma.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8C0837F0@standards.nortelnetworks.com>; Wed, 9 Feb 2000 22:53:57 -0500 Received: (from kleung@localhost) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA02535; Wed, 9 Feb 2000 19:56:21 -0800 (PST) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200002100356.TAA02535@sigma.cisco.com> Date: Wed, 9 Feb 2000 19:56:21 -0800 Reply-To: "Kent K. Leung" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Kent K. Leung" Subject: Re: [MOBILE-IP] GRE key field X-To: tom.hiller@LUCENT.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <38A22DF9.DB09ABDD@lucent.com> from "Tom Hiller" at Feb 09, 2000 09:18:17 PM Content-Transfer-Encoding: 7bit Note that the GRE Sequence Number may also be needed. draft-ietf-mobileip-3gwireless-ext-02.txt: 5.0 GRE Encapsulation GRE encapsulation as described in [3] shall be supported during user data transmission. A new protocol type might be required to support the link layer protocol defined for the third generation cdma2000 network. The Key field shall be required and its value shall be same as the one from the Session Specific Extension as described above. The sequence number may be required, depending on the requirement of the protocol encapsulated within the GRE frame. -- Kent -- > > To the authors of draft-meyer-gre-update-03.txt > > Based on Mobile IP email between Tony Li and Pat Calhoun it appears that the Key > field of the GRE tunnel has a highly uncertain fate. However, the cdma2000 > wireless community has plans to use this field, and would like for it to not > perish. I assume at least one issue is existing RFC text suggesting the "Key" > as being involved with authentication. However, cdma2000 use is to allow the > encapsulator to identify the source of the payload to the receiver. > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 10 01:32:31 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06605 for ; Thu, 10 Feb 2000 01:32:31 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2EAE8170@standards.nortelnetworks.com>; Thu, 10 Feb 2000 1:28:49 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37074 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 01:27:40 -0500 Received: from tsbgw.wide.toshiba.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.04AB8030@standards.nortelnetworks.com>; Thu, 10 Feb 2000 1:27:39 -0500 Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id PAA00034; Thu, 10 Feb 2000 15:30:00 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id PAA11785; Thu, 10 Feb 2000 15:30:00 +0900 (JST) Received: from tanuki (tanuki.isl.rdc.toshiba.co.jp [133.196.16.162]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with SMTP id PAA09753; Thu, 10 Feb 2000 15:29:59 +0900 (JST) References: <200002081318.FAA09013@nasnfs.eng.sun.com> X-Mailer: Datula version 1.21.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200002100629.PAA09753@isl.rdc.toshiba.co.jp> Date: Thu, 10 Feb 2000 15:40:24 +0900 Reply-To: Yoshiyuki Tsuda Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yoshiyuki Tsuda Organization: Corporate R&D Center, Toshiba Corporation Subject: Re: [MOBILE-IP] Registration Keys draft and D-H key exchanges X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200002081318.FAA09013@nasnfs.eng.sun.com> Hello, Pat, Thanks for your email. Probably, my last comment to this thread is attached at the bottom of this email: On Tue, 8 Feb 2000 05:16:07 -0800, Patrice Calhoun wrote: >> >> >Hello, Pat, >> > >> > I still cannot abandon another approach of passing key data between FAs. >> > Some modifications are attached at the bottom of this email; I'll appreciate, >> > if you give me a punch: >> > >> >On Mon, 7 Feb 2000 08:32:09 -0800, Patrice Calhoun wrote: >> >>> >> >>> >On Fri, 4 Feb 2000 08:29:44 -0800, Charles E. Perkins wrote: >> >>> >>> To summarize: >> >>> >>> - I propose to make the Diffie-Hellman work by elliptic curve groups >> >>> >>> in the default case >> >>> >>> - I propose to have the key established by an exchange between the >> >>> >>> foreign agent and home agent, to relieve computational and bandwidth >> >>> >>> requirements on the mobile node >> >>> >>> - I propose a new extension to Agent Advertisements containing a >> >>> >>> 32-bit digest for the D-H computed value to be used. >> >>> >>> - I propose to add support for the recent proposal for passing opaque >> >>> >>> key data from the mobile node to the new foreign agent. >> >>> > >> >>> > How about passing opaque key data from the previous FA to the new FA ? >> >>> > >> >>> > I agree with you that it's more efficient to pass key data from the MN to >> >>> > a new FA. But, I think, there may be some network operators who resist >> >>> > believing MN-supplied key data blindly. >> >>> > As another approach, it's possible to pass the key data from the previous >> >>> > FA to the new FA, I think. >> >>> > >> >>> > This approach works as follows: >> >>> > 1) All FAs in the same administrative domain advertise the same NAI, as >> >>> > someone wrote. >> >>> > 2) In case of movements within the same administrative domain, an MN sends >> >>> > a registration request with a Mobile-Foreign and a Mobile-Home auth >> >>> > extensions, instead with a NAI and an MN-AAA auth extensions. The >> >>> > destination IP address of this request becomes the previous FA's >> >address. >> >>> > 3) The new FA can know the previous FA by the destination address. >> >>> > 4) By a smooth hand-off and/or a key retrieving mehtod, the new FA can >> >>> > receive the key data from the previous FA. >> >>> > >> >>> > I'd like to know this approach is acceptable by the keying philosophy or >> >not. >> >>> >> >>> The issue that I have with this approach is that if the FA require that the >> >>> MN-FA auth be authenticated prior to forwarding the registration message to >> >the >> >>> HA, it would impose additional latency by requiring a round trip between the >> >>> FAs to retrieve the keys necessary to authentication the MN-FA. If the MN >> >>> can receive encrypted keys from the old FA, this round trip is eliminated, >> >>> further reducing the latency involved in the hand-off. >> >>> >> >>> PatC >> > >> > To eliminate the round trip between FAs, how about authenticating the first >> > registration request and reply by the old FA, instead of the new FA ? >> > >> > I think, this could be possible by the followings: >> > 1) At the first request after an MN moves to a new FA, the MN sends a >> > request to the new FA, but the destination IP address is the previous FA. >> > 2) The new FA records the request, but simply forwards it to the previous >> > FA. >> > 3) The previous FA authenticates the request, and forwards it to the HA. >> > The previous FA will find the source address isn't its care-of address, >> > but others. >> > 4) After a while, the previous FA receives a reply from the HA. By checking >> > the destination address, it will find the destination is the new FA, then >> > forwards it to the new FA. >> > 5) When the new FA receives this reply, it will enable a Mobile IP >> > communication for the MN. >> > 6) Between this first request and a second request, the new FA will fetch >> > key data from the previous FA by secure communication or by a keying >> > protocol. >> >> Interesting. A hierarchical approach, without being hierarchical. >> >> > >> > This approach will probably need an FA-FA authentication extension, but >> > could eliminate the round trip to get key data at the first request. >> > >> > Strange to say, I cannot believe all MNs, although I'm a programmer of an MN. >> > So, I would hesitate to believe the key data supplied by an MN, even with the >> > proposed protecting method. >> >> hmmm... if you really don't want to trust the Mobile, then I would prefer to >> see the keying information be passed in the binding update, as defined in >> the route opt. draft. >> >> Perhaps I don't see your problem here, but why do you need to trust the mobile? >> The draft in question requires that the keying material be encrypted by >> symmetric or assymetric keys only known to the FAs. The resulting key will >> look like a bunch of opaque bits to the Mobile. If the encryption key >> used by the Foreign Agent is sufficiently strong, I don't see a problem. >> >> A possible problem would be for the Mobile to simply send junk, wasting the >> Foreign Agent's cycles by decrypting a blob that will result in an invalid >> key. >> >> > Can you give me confidence ? :) >> >> Was that enough? OK, now enough. I'll persuade myself, after reading the new keying draft and the Diffie-Hellman work by elliptic curve groups. There may be another related problem; in case of wireless access networks, packets may drop due to corruption. I'd like to expect some considerations about packet losses in receiving or sending key data by an MN. Especially, I don't think an MN can send or request key data, as many times as it wants, in order to distinguish true operations from the above junk attacks. Thanks. -Yoshi From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 10 06:32:37 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18674 for ; Thu, 10 Feb 2000 06:32:37 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.229E7C80@standards.nortelnetworks.com>; Thu, 10 Feb 2000 6:29:08 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37308 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 06:27:36 -0500 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8659DE10@standards.nortelnetworks.com>; Thu, 10 Feb 2000 6:17:36 -0500 Received: from manhattan.gr-net.ch ([195.226.0.25]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id FAA05259; Thu, 10 Feb 2000 05:20:01 -0600 (CST) Received: from [208.15.107.223] by manhattan.gr-net.ch (Netscape Mail Server v2.0) with SMTP id AAD11871; Thu, 10 Feb 2000 11:38:35 +0200 X-Priority: 3 X-MSMailPriority: Normal Importance: Normal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_018C_01BD9940.715D52A0" Message-ID: <200002101120.FAA05259@hosaka.smallworks.com> Date: Thu, 10 Feb 2000 06:27:36 -0500 Reply-To: bsn2@aol.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: bsn2@aol.com Subject: [MOBILE-IP] Accept Visa and Mastercard Lowest Rates !!! X-To: rdrd1@aol.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_018C_01BD9940.715D52A0 Content-Type: text/html; ACCEPT ALL MAJOR CREDIT CARDS
99% APPROVAL RATE ALL BUSINESSES ACCEPTED
0 DOWN , NO APPLICATION FEES
LOWEST RATES,LOW MONTHLY PAYMENTS
WE WILL BEAT ANY COMPETITOR'S PRICE
CALL NOW 800-487-9955

ASK ABOUT OUR $100 CASH BACK


 ------=_NextPart_000_018C_01BD9940.715D52A0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 10 06:58:53 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19032 for ; Thu, 10 Feb 2000 06:58:53 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C7C6E230@standards.nortelnetworks.com>; Thu, 10 Feb 2000 6:55:13 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37379 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 06:53:46 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2E1FF910@standards.nortelnetworks.com>; Thu, 10 Feb 2000 6:43:46 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18792; Thu, 10 Feb 2000 06:46:15 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200002101146.GAA18792@ietf.org> Date: Thu, 10 Feb 2000 06:46:14 -0500 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-challenge-09.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Mobile IP Challenge/Response Extensions Author(s) : C. Perkins, P. Calhoun Filename : draft-ietf-mobileip-challenge-09.txt Pages : 15 Date : 09-Feb-00 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-challenge-09.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-challenge-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-challenge-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000209152832.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-challenge-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-challenge-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000209152832.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 10 06:58:53 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19034 for ; Thu, 10 Feb 2000 06:58:53 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C7D51300@standards.nortelnetworks.com>; Thu, 10 Feb 2000 6:55:13 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37380 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 06:53:52 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.314F6710@standards.nortelnetworks.com>; Thu, 10 Feb 2000 6:43:51 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18806; Thu, 10 Feb 2000 06:46:20 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200002101146.GAA18806@ietf.org> Date: Thu, 10 Feb 2000 06:46:20 -0500 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-mier-03.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Mobile IP Extensions Rationalization (MIER) Author(s) : M. Khalil, R. Narayanan, H. Akhtar, E. Qaddoura Filename : draft-ietf-mobileip-mier-03.txt Pages : 8 Date : 09-Feb-00 It is in the interest of the Mobile IP WG to conserve the usage of the type field since we see many drafts proposing new extensions for Mobile IP. Therefore there is a real need to find ways to limit the usage of the type field in the extensions structure. MIER describes a new extension structure to Mobile IP to make the extensions far more extensible. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mier-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-mier-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-mier-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000209152842.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-mier-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-mier-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000209152842.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 10 09:24:18 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26421 for ; Thu, 10 Feb 2000 09:24:18 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.179C9160@standards.nortelnetworks.com>; Thu, 10 Feb 2000 9:20:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37674 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 09:19:39 -0500 Received: from gorilla.mchh.siemens.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F4A8A950@standards.nortelnetworks.com>; Thu, 10 Feb 2000 9:19:39 -0500 Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA11861; Thu, 10 Feb 2000 15:21:10 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([218.1.68.146]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA20214; Thu, 10 Feb 2000 15:19:33 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2448.0) id <1RB3MCYW>; Thu, 10 Feb 2000 15:22:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 10 Feb 2000 15:22:21 +0100 Reply-To: Petri Bernhard Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Petri Bernhard Subject: [MOBILE-IP] Disparate Address Space in RFC 2344bis [Was: [MOBILE-IP] Private addressing reference in rfc2002-bis ?] X-To: Gabriel Montenegro To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Gabriel, I agree with Samita and you that the T bit should not be overloaded to also indicate support of private addresses. Rather than doing this, we could in the future look for something like a separate "P" bit and related solutions. I see your point that the results of the discussions about the use of private addresses are not mature enough to put more into the RFC 2344bis draft than the current Appendix on Disparate Address Space Support. I very much appreciate your work on this Appendix. Although it's just informal information, it generally clarifies quite a number of the issues introduced by the possible use of private addresses within Mobile IP, and could therefore be very useful for subsequent drafting work to solve those issues. With regard to this Appendix, I've just got a few questions/comments on some details: - Below Figure A1, you describe how an MN sends a packet to an FA via layer 2 mechanisms. How does the FA, in this case, know that the source address indicated by the MN belongs to MN's home address space C rather than to the address spaces A or B, i.e. the address spaces of the FA itself? In section A.3, you mention the possibility that some MAC or PPP information may be used for that; in this case, how did the initial fixing of that relation take place? Or, as a related question: how would the FA advertise an address of an address space, it does not support? - Below Figure 2 you show that the HA recovers the original packet by being cognizant of address space C. How is this done? Probably, HA must apply an algorithm saying something like: for every (IP-IP) packet I receive with source address Fb, the inner IP addresses belong to address space C, right ? - In the paragraph below figure 3, I think there's a typo in the third to the last line: H2c -> H2d In general, I think that an extensive use of private IP addresses within mobile IP will require "giving additional domain information" with those addresses (as Pete has worded it in another mail), i.e. to add an explicit indication to which that private IP address belongs. Kind regards -Bernhard Bernhard Petri, Siemens Tel: +49 89 722-34578 Fax: +49 89 722-29098 bernhard.petri@icn.siemens.de ______________________________ > -----Original Message----- > From: Gabriel Montenegro [SMTP:gab@eng.sun.com] > Sent: Thursday, February 03, 2000 11:47 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: > > > It may make sense to update rfc2344 the tunnel routing > > issues for private addresses, > > by the way, i've submitted the rfc2344-bis draft. if you want > to get it before the announcement comes out, you can get it > at: > > http://playground.sun.com/~gab/papers/tunnel.txt > > (the only changes are new section 6.3 and an appendix). > > > but I still think that > > mipagent (FA) somehow needs to inform the mobile nodes > > that it can handle private addresses-- that means having > > 'T' bit in the agent advertisement field is not sufficient > > to provide support for private addresses. > > agreed, but please note that any of this is not in scope for > the update to rfc2344 at this time. > > now, going forward (as a separate task), > we could overload the 'T' bit to also imply support > for private addresses as specified in the revision of 2344. > > if this is not agreeable to everyone, then, yes, perhaps a new 'P' > bit makes sense. > > > It seems logical to me that 'P' bit with agent advertisement > > can let the privately addressed mobile node choose the right FA > > -- but it may have other implications--any particular reasons > > against it ? > > but the 'P' bit (or overloaded 'T' bit) does not answer this question: > > what COA should the MN used for registration? > > notice that the COA may very well be a function of the MN's home > address: for MN's within the FA's domain the COA is probably > an 'inside' address of the FA. for MN's with home addresses outside > the FA's domain, perhaps an 'external' COA makes more sense. > > how are these two different coa's advertised and kept apart? perhaps > a new private addr extension could carry > pairs along these lines: > > nai, coa > > or > > dns authority, coa > > given the first element of the pair, an mn would be in a position to > select > the right coa it needs to use. > > the private addr extension need not be included in all advertisements. > upon hearing a 'P' bit, > the mn could solicit with a special code, say in order to obtain the priv > addr extension. > > this is just wondering out loud what to do, as i said, the revision to > rfc2344 does > not go into this and is very limited in scope. this last stuff is for > later discussion. > > -gabriel From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 10 10:21:21 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00277 for ; Thu, 10 Feb 2000 10:21:21 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.142E4C00@standards.nortelnetworks.com>; Thu, 10 Feb 2000 10:17:47 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37799 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 10:16:19 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DF39EE50@standards.nortelnetworks.com>; Thu, 10 Feb 2000 10:16:19 -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 HAA10675; Thu, 10 Feb 2000 07:18:38 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA25813; Thu, 10 Feb 2000 07:18:37 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp2.Central.Sun.COM [129.147.36.137]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id HAA14234; Thu, 10 Feb 2000 07:18:30 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-ID: <200002101518.HAA14234@nasnfs.eng.sun.com> Date: Thu, 10 Feb 2000 07:21:42 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] Registration Keys draft and D-H key exchanges X-To: Yoshiyuki Tsuda To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit >Hello, Pat, > > Thanks for your email. Probably, my last comment to this thread is attached > at the bottom of this email: > >On Tue, 8 Feb 2000 05:16:07 -0800, Patrice Calhoun wrote: >>> >>> >Hello, Pat, >>> > >>> > I still cannot abandon another approach of passing key data between FAs. >>> > Some modifications are attached at the bottom of this email; I'll >appreciate, >>> > if you give me a punch: >>> > >>> >On Mon, 7 Feb 2000 08:32:09 -0800, Patrice Calhoun wrote: >>> >>> >>> >>> >On Fri, 4 Feb 2000 08:29:44 -0800, Charles E. Perkins wrote: >>> >>> >>> To summarize: >>> >>> >>> - I propose to make the Diffie-Hellman work by elliptic curve groups >>> >>> >>> in the default case >>> >>> >>> - I propose to have the key established by an exchange between the >>> >>> >>> foreign agent and home agent, to relieve computational and >bandwidth >>> >>> >>> requirements on the mobile node >>> >>> >>> - I propose a new extension to Agent Advertisements containing a >>> >>> >>> 32-bit digest for the D-H computed value to be used. >>> >>> >>> - I propose to add support for the recent proposal for passing >opaque >>> >>> >>> key data from the mobile node to the new foreign agent. >>> >>> > >>> >>> > How about passing opaque key data from the previous FA to the new FA ? >>> >>> > >>> >>> > I agree with you that it's more efficient to pass key data from the MN >to >>> >>> > a new FA. But, I think, there may be some network operators who >resist >>> >>> > believing MN-supplied key data blindly. >>> >>> > As another approach, it's possible to pass the key data from the >previous >>> >>> > FA to the new FA, I think. >>> >>> > >>> >>> > This approach works as follows: >>> >>> > 1) All FAs in the same administrative domain advertise the same NAI, >as >>> >>> > someone wrote. >>> >>> > 2) In case of movements within the same administrative domain, an MN >sends >>> >>> > a registration request with a Mobile-Foreign and a Mobile-Home auth >>> >>> > extensions, instead with a NAI and an MN-AAA auth extensions. The >>> >>> > destination IP address of this request becomes the previous FA's >>> >address. >>> >>> > 3) The new FA can know the previous FA by the destination address. >>> >>> > 4) By a smooth hand-off and/or a key retrieving mehtod, the new FA can >>> >>> > receive the key data from the previous FA. >>> >>> > >>> >>> > I'd like to know this approach is acceptable by the keying philosophy >or >>> >not. >>> >>> >>> >>> The issue that I have with this approach is that if the FA require that >the >>> >>> MN-FA auth be authenticated prior to forwarding the registration message >to >>> >the >>> >>> HA, it would impose additional latency by requiring a round trip between >the >>> >>> FAs to retrieve the keys necessary to authentication the MN-FA. If the MN >>> >>> can receive encrypted keys from the old FA, this round trip is >eliminated, >>> >>> further reducing the latency involved in the hand-off. >>> >>> >>> >>> PatC >>> > >>> > To eliminate the round trip between FAs, how about authenticating the >first >>> > registration request and reply by the old FA, instead of the new FA ? >>> > >>> > I think, this could be possible by the followings: >>> > 1) At the first request after an MN moves to a new FA, the MN sends a >>> > request to the new FA, but the destination IP address is the previous >FA. >>> > 2) The new FA records the request, but simply forwards it to the >previous >>> > FA. >>> > 3) The previous FA authenticates the request, and forwards it to the HA. >>> > The previous FA will find the source address isn't its care-of >address, >>> > but others. >>> > 4) After a while, the previous FA receives a reply from the HA. By >checking >>> > the destination address, it will find the destination is the new FA, >then >>> > forwards it to the new FA. >>> > 5) When the new FA receives this reply, it will enable a Mobile IP >>> > communication for the MN. >>> > 6) Between this first request and a second request, the new FA will >fetch >>> > key data from the previous FA by secure communication or by a keying >>> > protocol. >>> >>> Interesting. A hierarchical approach, without being hierarchical. >>> >>> > >>> > This approach will probably need an FA-FA authentication extension, but >>> > could eliminate the round trip to get key data at the first request. >>> > >>> > Strange to say, I cannot believe all MNs, although I'm a programmer of an >MN. >>> > So, I would hesitate to believe the key data supplied by an MN, even with >the >>> > proposed protecting method. >>> >>> hmmm... if you really don't want to trust the Mobile, then I would prefer to >>> see the keying information be passed in the binding update, as defined in >>> the route opt. draft. >>> >>> Perhaps I don't see your problem here, but why do you need to trust the >mobile? >>> The draft in question requires that the keying material be encrypted by >>> symmetric or assymetric keys only known to the FAs. The resulting key will >>> look like a bunch of opaque bits to the Mobile. If the encryption key >>> used by the Foreign Agent is sufficiently strong, I don't see a problem. >>> >>> A possible problem would be for the Mobile to simply send junk, wasting the >>> Foreign Agent's cycles by decrypting a blob that will result in an invalid >>> key. >>> >>> > Can you give me confidence ? :) >>> >>> Was that enough? > > OK, now enough. I'll persuade myself, after reading the new keying draft > and the Diffie-Hellman work by elliptic curve groups. > > There may be another related problem; in case of wireless access networks, > packets may drop due to corruption. I'd like to expect some considerations > about packet losses in receiving or sending key data by an MN. Especially, > I don't think an MN can send or request key data, as many times as it wants, > in order to distinguish true operations from the above junk attacks. Since the keying material is passed in a Registration Reply, if the reply is not received by the Mobile Node, it will retransmit it's request. The Mobile IP messages MUST be received by the MN, regardless of the media. So, I'm not sure that this is an issue. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 10 11:59:02 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03963 for ; Thu, 10 Feb 2000 11:59:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AFA284A0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 11:55:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 38013 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 11:53:54 -0500 Received: from jefferson.patriot.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1AF9AF00@standards.nortelnetworks.com>; Thu, 10 Feb 2000 11:43:53 -0500 Received: from ntti (pool180-92.patriot.net [209.249.180.92]) by jefferson.patriot.net (8.8.7/8.8.7) with SMTP id LAA09675 for ; Thu, 10 Feb 2000 11:46:22 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01BF73BD.D8224140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <001e01bf73e7$c1c1b3c0$5cb4f9d1@ntti> Date: Thu, 10 Feb 2000 11:56:20 -0500 Reply-To: Tanweer Butt Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Tanweer Butt Subject: [MOBILE-IP] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_001B_01BF73BD.D8224140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mobile-IP ------=_NextPart_000_001B_01BF73BD.D8224140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Mobile-IP
------=_NextPart_000_001B_01BF73BD.D8224140-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 10 14:25:27 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08313 for ; Thu, 10 Feb 2000 14:25:26 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.34A83AF0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 14:22:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 38610 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 14:20:49 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.07166DA0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 14:20:48 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA16158 for ; Thu, 10 Feb 2000 12:22:55 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id LAA25450 for ; Thu, 10 Feb 2000 11:22:55 -0800 (PST) Received: (from samita@localhost) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) id LAA21735; Thu, 10 Feb 2000 11:22:53 -0800 (PST) X-Sun-Charset: US-ASCII Message-ID: <200002101922.LAA21735@jurassic.eng.sun.com> Date: Thu, 10 Feb 2000 11:22:53 -0800 Reply-To: Samita Chakrabarti Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Samita Chakrabarti Subject: Re: [MOBILE-IP] Private addressing reference in rfc2002-bis ? X-To: gab@eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Gabriel, Sorry for the delayed reply. > by the way, i've submitted the rfc2344-bis draft. if you want > to get it before the announcement comes out, you can get it > at: > > http://playground.sun.com/~gab/papers/tunnel.txt > > (the only changes are new section 6.3 and an appendix). Thanks, it has clarified several issues of private address support associated with reverse tunnel. Especially the simple case when we have global HA address and global FA addresses and private MN address space. > > It seems logical to me that 'P' bit with agent advertisement > > can let the privately addressed mobile node choose the right FA > > -- but it may have other implications--any particular reasons > > against it ? > > but the 'P' bit (or overloaded 'T' bit) does not answer this question: > > what COA should the MN used for registration? > > notice that the COA may very well be a function of the MN's home > address: for MN's within the FA's domain the COA is probably > an 'inside' address of the FA. for MN's with home addresses outside > the FA's domain, perhaps an 'external' COA makes more sense. If FA advertises two different COA's for private address support, then it seems the MN implementation will also need to change to take into account when to use which COA. Perhaps MNs needs to know that it's using a private address space and then process the agent advertisement accordingly. > > how are these two different coa's advertised and kept apart? perhaps > a new private addr extension could carry > pairs along these lines: > > nai, coa > > or > > dns authority, coa > > given the first element of the pair, an mn would be in a position to select > the right coa it needs to use. > Folks seem to like the nai extension idea. > the private addr extension need not be included in all advertisements. upon hearing a 'P' bit, > the mn could solicit with a special code, say in order to obtain the priv > addr extension. > I like this idea. Although I am not quite clear on the idea about the home agent advertisement. If a HA has one side public net and private net on the other side, then what address would it advertise on the private side ? Do we assume that the private addressed MNs never come back home and they are pre-configured to use HA's global address ? On the other hand if HA advertises private address on it's private net, then we assume that MNs are intelligent enough to figure out which home agent address to use when they are away from home. Thanks, -Samita From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 10 14:53:34 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08833 for ; Thu, 10 Feb 2000 14:53:32 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.225D5200@standards.nortelnetworks.com>; Thu, 10 Feb 2000 14:50:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 38698 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 14:48:59 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F6B8FCD0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 14:48:59 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA03435 for ; Thu, 10 Feb 2000 12:51:25 -0700 (MST) 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 LAA01801 for ; Thu, 10 Feb 2000 11:51:26 -0800 (PST) Received: (from samita@localhost) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) id LAA26903; Thu, 10 Feb 2000 11:51:25 -0800 (PST) X-Sun-Charset: US-ASCII Message-ID: <200002101951.LAA26903@jurassic.eng.sun.com> Date: Thu, 10 Feb 2000 11:51:25 -0800 Reply-To: Samita Chakrabarti Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Samita Chakrabarti Subject: [MOBILE-IP] Routing socket message bitmask for reverse tunnel support X-cc: samita@jurassic.Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM We are thinking about implementing two new bitmask flags for routing socket message identifying the source address and incoming interface of the packet to support reverese tunnel and overlapping private addresses visiting same FA on different links ( i.e. by sending routing socket message from mipagent to kernel, we will ask the kernel to do the source addr based routing lookup for reverse tunnel). The proposal for adding two bitmasks for this purpose in the route.h header file is: #define RTA_SRC 0x100 /* Source sockaddr present */ #define RTA_SRCIFP 0x200 /* Source interface name sockaddr present */ I would like to know if there are any routing socket implementors who have used similar name space for these bitflags for mobileip implementation. Thanks, -Samita From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 10 17:29:43 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12235 for ; Thu, 10 Feb 2000 17:29:42 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DCBE96D0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 17:25:44 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39056 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 17:24:20 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AA956710@standards.nortelnetworks.com>; Thu, 10 Feb 2000 17:24:20 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id OAA14277 for ; Thu, 10 Feb 2000 14:26:50 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id OAA04385 for ; Thu, 10 Feb 2000 14:26:49 -0800 X-Virus-Scanned: Thu, 10 Feb 2000 14:26:49 -0800 Nokia Silicon Valley AntiVirus Appliance Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma004263; Thu, 10 Feb 00 14:26:46 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38A33B26.9FC9454E@iprg.nokia.com> Date: Thu, 10 Feb 2000 14:26:46 -0800 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: [MOBILE-IP] "Route Optimization in Mobile IP" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello folks, A revised Internet Draft for Route Optimization has been sent for distribution to the IETF draft directories. I have also copied the draft to the following URL: http://www.iprg.nokia.com/~charliep/txt/optim/optim.txt for anyone that might be interested. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 10 17:46:04 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12437 for ; Thu, 10 Feb 2000 17:46:04 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.418BB9B0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 17:42:52 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39163 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 17:41:07 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0272C570@standards.nortelnetworks.com>; Thu, 10 Feb 2000 17:41:07 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id OAA16575 for ; Thu, 10 Feb 2000 14:43:38 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id OAA29808 for ; Thu, 10 Feb 2000 14:43:37 -0800 X-Virus-Scanned: Thu, 10 Feb 2000 14:43:37 -0800 Nokia Silicon Valley AntiVirus Appliance Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma029647; Thu, 10 Feb 00 14:43:34 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38A33F16.5920A03A@iprg.nokia.com> Date: Thu, 10 Feb 2000 14:43:34 -0800 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: [MOBILE-IP] New Registration Keys draft To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello folks, I would like to revise the existing Registration Key draft to take into account the possibility for managing Registration Keys delivered by the mobile node to the new foreign agent, as indicated in a recent draft by Pat Calhoun et.al. I believe that the handling for the latter draft will stay the same in the Registration Keys draft, even as the specifics of the opaque data mechanism evolve. The Registration Keys draft has already been updated, although not finished, to define two new Generalized Registration Key extensions -- namely, a Key Request extension and a Key Reply extension. All of the previous extensions for Key Request and Key Reply are now subtypes of one of those generalized extensions. The opaque data extension is a subtype of the Generalized Key Reply extension. Lastly, I would like to change the default key-exchange algorithm. In the old draft, it was Diffie-Hellman exchange using the modular exponentiation group. For some years now it has been known that using the elliptic curve groups is _much_ faster computationally. Furthermore, it has been made clearer that assigning key exchange responsibility to the foreign agent and the home agent, instead of the mobile node, offers several advantages. Since the modular exponentiation algorithm has not been widely implemented, I suspect that changing the defaults will not cause any significant hardship. And, it could offer quite significant benefits for the future. I mentioned this strategy in an earlier note, and it was pointed out that not all foreign agents would be willing to carry out a Mobile IP registration, much less one with a key exchange, without some sort of authentication of the mobile node. If this is a concern, then such foreign agents may require the mobile node to already come equipped with a Registration Key (perhaps from a previous registration). The elliptic curve algorithm to be used in this Registration Key draft will not serve the needs for such foreign agents. On the other hand, if someone would like to figure out how to make the adaptation, I would be very interested to look into making the necessary changes. Unless someone offers a better solution, I will probably specify some default parameters from the "well-known group" GF(2^185), as discussed in appendix E.4 from RFC 2412, using the suggested generating point (24,13) and so on. I can also enable the mobility agents to exchange optional fields to select non-default parameters. Your comments are requested. Thanks, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 10 19:26:20 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13379 for ; Thu, 10 Feb 2000 19:26:20 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.43F75A20@standards.nortelnetworks.com>; Thu, 10 Feb 2000 19:23:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39365 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 19:21:39 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0DB2AEB0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 19:21:38 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id QAA27223 for ; Thu, 10 Feb 2000 16:23:56 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id QAA32135 for ; Thu, 10 Feb 2000 16:23:17 -0800 X-Virus-Scanned: Thu, 10 Feb 2000 16:23:17 -0800 Nokia Silicon Valley AntiVirus Appliance Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma031971; Thu, 10 Feb 00 16:23:13 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------E73F1B41AC3BBD232D2D0AB8" Message-ID: <38A35671.E3744A9@iprg.nokia.com> Date: Thu, 10 Feb 2000 16:23:13 -0800 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: [MOBILE-IP] RFC2002bis acknowledgements To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------E73F1B41AC3BBD232D2D0AB8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello folks, I regret to say that I forgot to update the Acknowledgements section of the recent Internet Draft for RFC2002bis. I have made changes to acknowledge previous working group chairs, contributions of text to the draft, and hosting interoperability tests. For anyone that is interested, I attach the new Acknowledgement section. I didn't make a whole new revision of the Internet Draft, but whenever one is made, the new Acknowledgements would be included. Regards, Charlie P. --------------E73F1B41AC3BBD232D2D0AB8 Content-Type: text/plain; charset=us-ascii; name="Ack" Content-Disposition: inline; filename="Ack" Content-Transfer-Encoding: 7bit 7. Acknowledgments Special thanks to Steve Deering (Xerox PARC), along with Dan Duchamp and John Ioannidis (JI) (Columbia), for forming the working group, chairing it, and putting so much effort into its early development. Thanks also to Kannan Alaggapan, Greg Minshall, Tony Li, Jim Solomon, and Erik Nordmark for their contributions to the group while performing the duties of chairperson, as well as for their many useful comments. Thanks to the active members of the Mobile IP Working Group, particularly those who contributed text, including (in alphabetical order) - Ran Atkinson (Naval Research Lab), - Samita Chakrabarti (Sun Microsystems) - Dave Johnson (Carnegie Mellon University), - Frank Kastenholz (FTP Software), - Anders Klemets (KTH), - Chip Maguire (KTH), - Andrew Myles (Macquarie University), - Al Quirt (Bell Northern Research), - Yakov Rekhter (IBM), and - Fumio Teraoka (Sony). Thanks to Charlie Kunzinger and to Bill Simpson, the editors who produced the first drafts for of this document, reflecting the discussions of the Working Group. Much of the new text in the latest drafts is due to Jim Solomon and Dave Johnson. Thanks to Greg Minshall (Novell), Phil Karn (Qualcomm), Frank Kastenholz (FTP Software), and Pat Calhoun (Sun Microsystems) for their generous support in hosting interim Working Group meetings. --------------E73F1B41AC3BBD232D2D0AB8-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 10 23:08:01 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17608 for ; Thu, 10 Feb 2000 23:07:55 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.34DFBB80@standards.nortelnetworks.com>; Thu, 10 Feb 2000 23:04:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39730 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 23:03:20 -0500 Received: from maredsous.monarch.cs.cmu.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.05C94A00@standards.nortelnetworks.com>; Thu, 10 Feb 2000 23:03:19 -0500 Received: from maredsous.monarch.cs.cmu.edu (localhost [127.0.0.1]) by maredsous.monarch.cs.cmu.edu id XAA19530; Thu, 10 Feb 2000 23:09:55 -0500 (EST) Message-ID: <19528.950242195@maredsous.monarch.cs.cmu.edu> Date: Thu, 10 Feb 2000 23:09:55 -0500 Reply-To: Dave Johnson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Dave Johnson Subject: [MOBILE-IP] New (and I think final) Mobile IPv6 draft submitted X-To: ipng@sunroof.eng.sun.com X-cc: raj.patil@nokia.com, qa3445@email.mot.com, oran@cisco.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This afternoon, I submitted a new version of the Mobile IPv6 draft that I think includes fixes for all of the comments I've received on earlier versions of the draft, including several places where changes or clarifications were needed to get along properly with IPsec. Here is the list of major changes since the previous version of the draft: - Added additional material in Section 10.2, discussing use any automated key management protocol [13] (such as IKE [8]) to create any new SA (or SA bundle) while away from home. - Also added additional material in Section 10.2 to define the order in which the Home Address option and Binding Update option appear in the packet relative to the AH or ESP header that is required when a Binding Update is inserted. In addition, this change corrects the placement of the Home Address option in the packet to be before (not after) the AH or ESP header, so that the Home Address option is processed by the destination node before the AH or ESP header is processed. - Changed the dynamic home agent address discovery mechanism to use dedicated ICMP message types (defined in Sections 5.6 and 5.7) rather than (re)using the Binding Update and Binding Acknowledgement options. This change was primarily motivated by the fact that IP packets sent to an anycast address cannot (currently) use AH or ESP authentication since the packet is not directed to any single node with which a Security Association could be established. In addition, this change simplifies the processing of Binding Updates and Binding Acknowledgements, since it removes the special cases there for dynamic home agent address discovery. - Removed the Binding Acknowledgement option Status value of 135 (dynamic home agent address discovery response) since it is no longer needed with the revised dynamic home agent address discovery mechanism. - Removed the Home Agents List Sub-Option since it is no longer needed with the revised dynamic home agent address discovery mechanism. - Added a Duplicate Address Detection (D) bit in the Binding Update option format, to request the mobile node's home agent to perform Duplicate Address Detection on the mobile node's home link for the home address in this binding. Also defined a new Status value of 138 (Duplicate Address Detection failed) for the Binding Acknowledgement, to indicate any failure of this Duplicate Address Detection on the home link. The addition of the Duplicate Address Detection (D) bit in the Binding Update option also reduced the Reserved field from a 5-bit field to a 4-bit field (and caused it to be renamed Reservd so that the label fits in the packet format drawing). - Added text in Section 9.3 and 10.16 to describe the use of the new Duplicate Address Detection (D) bit in the Binding Update option format. - Changed the description of the Home Agents List conceptual data structure to require maintenance of a Home Agents List by each mobile node, as well as by each home agent. A mobile node uses this list to enable notifying a home agent on its previous link, when the mobile node moves to a new link. - In Section 10.10, changed the procedure for retransmitting Binding Updates to require that the Sequence Number field in each successive retransmission MUST be greater than that used in the previous transmission. The draft previously incorrectly specified here that the same sequence number must be used for each retransmission. The change is needed since such reuse of sequence numbers will fail if the original transmission of the Binding Update was in fact received, but the Binding Acknowledgement (instead of the Binding Update) was lost in transmission on the network. Changing the Sequence Number on each retransmission also avoids the any acknowledgement ambiguity problem, making the start time for the binding lifetime more clear. - Corrected yet a few more minor typographical errors in places. I think (and hope :-) that this version of the draft will be the final version before going to Proposed Standard. We plan to start a Last Call on the draft once the official announcement of this new version comes out on the IETF-Announce mailing list. For those who would like to get a copy of the new version now while we wait for the official announcement, it is available on the CMU Monarch Project web pages at http://www.monarch.cs.cmu.edu/internet-drafts/draft-ietf-mobileip-ipv6-10.txt If you have any comments on this new version, please let me know. Comments are best sent to the Mobile IP mailing list at MOBILE-IP@standards.nortelnetworks.com. Dave -- David B. Johnson dbj@cs.cmu.edu Associate Professor http://www.cs.cmu.edu/~dbj/ Computer Science Department http://www.monarch.cs.cmu.edu/ Carnegie Mellon University Phone: (412) 268-7399 5000 Forbes Avenue Fax: (412) 268-5576 Pittsburgh, PA 15213-3891 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 10 23:48:57 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18390 for ; Thu, 10 Feb 2000 23:48:57 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F2DAE330@standards.nortelnetworks.com>; Thu, 10 Feb 2000 23:45:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39810 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 23:44:11 -0500 Received: from maredsous.monarch.cs.cmu.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BB119390@standards.nortelnetworks.com>; Thu, 10 Feb 2000 23:44:11 -0500 Received: from maredsous.monarch.cs.cmu.edu (localhost [127.0.0.1]) by maredsous.monarch.cs.cmu.edu id XAA19702; Thu, 10 Feb 2000 23:50:25 -0500 (EST) Message-ID: <19700.950244624@maredsous.monarch.cs.cmu.edu> Date: Thu, 10 Feb 2000 23:50:24 -0500 Reply-To: Dave Johnson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Dave Johnson Subject: Re: [MOBILE-IP] draft-ietf-mobileip-ipv6-09 X-To: sl531@cc.usu.edu X-cc: itojun@iijlab.net, Aaron Griggs , ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of "Sun, 06 Feb 2000 21:30:22 CST" >Hi, >I know very little about IPv6 mobility and security issues so correct me >if am wrong. Please UNICAST me your expert advice. > >1> Draft mention that while transmitting packet if corresponding node's >Binding cache has valid care_of_address entry for mobile node's home >address then it replaces later by former and append routing header with >later as last hop. Do the firewall entertain source routing ?? Firewalls *can* do anything they want to (unfortunately) but there is no reason that it should block packets containing such a routing header. >2> Also encapsulated packets from home agent can invade foreign network's >firewall. Is that acceptable ?? Again, there is no reason that a firewall should block such packets. >3> While registering primary care_of_address with its home agent mobile >node sends either an AH [9] or ESP [10] header providing sender >authentication, data integrity protection, and replay protection, via >Foreign Agent. Isn't that surrendering your secured data to foreign n/w ?? There are no foreign agents in Mobile IPv6 (they were optional in Mobile IPv4, but in Mobile IPv6, this is a simple IPv6 router). Also, the Binding Update is sent from the mobile node to the home agent using standard IPsec. I'm not sure what you mean by "surrendering your secured data" here, but the authentication (and optional encryption) is done directly between the mobile node and the home agent. Nothing is shared with the router or anyone else in the foreign network. >Thanks. > >Rajeeb Mishra Dave From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 10 23:59:03 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18451 for ; Thu, 10 Feb 2000 23:59:03 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5B802CA0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 23:55:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39813 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 23:54:33 -0500 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C7A1D2F0@standards.nortelnetworks.com>; Thu, 10 Feb 2000 23:44:32 -0500 Received: from hermes02.musicnetger.de (root@[195.222.127.25]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id WAA11091 for ; Thu, 10 Feb 2000 22:47:03 -0600 (CST) Received: from showme (98CC1F0B.ipt.aol.com [152.204.31.11]) by hermes02.musicnetger.de (8.8.8/8.8.8) with SMTP id FAA13466; Fri, 11 Feb 2000 05:43:00 +0100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7BIT Message-ID: Date: Wed, 10 Nov 1999 20:42:44 -0800 Reply-To: spy2@post.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: spy2@post.com Subject: [MOBILE-IP] INTERNET SPY! X-To: wefr@freya.van.hookup.net To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7BIT From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 11 00:02:13 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18578 for ; Fri, 11 Feb 2000 00:02:13 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A5701780@standards.nortelnetworks.com>; Thu, 10 Feb 2000 23:57:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39838 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 10 Feb 2000 23:57:43 -0500 Received: from coconut.itojun.org (210.160.95.97) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.38B91660@standards.nortelnetworks.com>; Thu, 10 Feb 2000 23:47:42 -0500 Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W/smtpfeed 1.04) with ESMTP id NAA24632; Fri, 11 Feb 2000 13:50:04 +0900 (JST) X-Template-Reply-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Message-ID: <24630.950244604@coconut.itojun.org> Date: Fri, 11 Feb 2000 13:50:04 +0900 Reply-To: itojun@IIJLAB.NET Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: itojun@IIJLAB.NET Subject: Re: [MOBILE-IP] New (and I think final) Mobile IPv6 draft submitted X-To: Dave Johnson X-cc: ipng@sunroof.eng.sun.com, raj.patil@nokia.com, qa3445@email.mot.com, oran@cisco.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: dbj's message of Thu, 10 Feb 2000 23:09:55 EST. <19528.950242195@maredsous.monarch.cs.cmu.edu> > - Also added additional material in Section 10.2 to define the > order in which the Home Address option and Binding Update option > appear in the packet relative to the AH or ESP header that is > required when a Binding Update is inserted. In addition, this > change corrects the placement of the Home Address option in the > packet to be before (not after) the AH or ESP header, so that the > Home Address option is processed by the destination node before > the AH or ESP header is processed. If home address option (or any of option that need authenticity) appear prior to ESP header, we need to mandate use of AH for these packets. ESP does not protect packet portion before ESP header. There are many "AH or ESP" in document, I'm not sure which one (or all of them) need clarification. itojun From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 11 02:17:38 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01064 for ; Fri, 11 Feb 2000 02:17:37 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ADFF1F50@standards.nortelnetworks.com>; Fri, 11 Feb 2000 2:14:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 40095 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 02:12:11 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.01CD81F0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 2:02:10 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA18136; Fri, 11 Feb 2000 00:04:39 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.89.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id XAA20540; Thu, 10 Feb 2000 23:04:40 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA28282; Thu, 10 Feb 2000 23:04:38 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Thu, 10 Feb 2000 23:03:47 -0800 Reply-To: Erik Nordmark Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Erik Nordmark Subject: Re: [MOBILE-IP] New (and I think final) Mobile IPv6 draft submitted X-To: Dave Johnson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <19528.950242195@maredsous.monarch.cs.cmu.edu> > - Added a Duplicate Address Detection (D) bit in the Binding > Update option format, to request the mobile node's home agent to > perform Duplicate Address Detection on the mobile node's home > link for the home address in this binding. Does this imply that if the D bit is set the home agent will wait for a few seconds to do DAD i.e. the update ack will be delayed? Or is the home agent allowed to retain state to the effect "I did DAD for this address 10 minutes ago" to reduce the number of times DAD will occur? > - Changed the description of the Home Agents List conceptual data > structure to require maintenance of a Home Agents List by each > mobile node, as well as by each home agent. A mobile node uses > this list to enable notifying a home agent on its previous link, > when the mobile node moves to a new link. The above description reads as if a MN has a home agent per link... Did you mean "notifying a previous default router which might be used as a home agent for smoother handoff"? Erik From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 11 03:03:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02254 for ; Fri, 11 Feb 2000 03:03:24 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.216D6360@standards.nortelnetworks.com>; Fri, 11 Feb 2000 3:00:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 40225 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 02:59:05 -0500 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F54AB670@standards.nortelnetworks.com>; Fri, 11 Feb 2000 2:59:05 -0500 Received: from gdommety-pc2 (gdommety-dsl2.cisco.com [10.19.17.139]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id AAA15321; Fri, 11 Feb 2000 00:01:33 -0800 (PST) X-Sender: gdommety@omega.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 References: <200002030123.RAA24888@omega.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <200002110801.AAA15321@omega.cisco.com> Date: Fri, 11 Feb 2000 00:14:51 -0800 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: [MOBILE-IP] GRE Draft /RP Issues X-cc: rp-int@cisco.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <38991BE6.40E9F775@home.net> Hello: I received an email from Fred Baker regarding IESGs decision on GRE options. I have attached below part of his email. I replied to him (and the IESG) that I will submit the draft for being kicked around soon. I apologize for the delay in sending this email, too many things happening :( -Gopal > Gopal: > > The IESG discussed your concern this morning, and came up with this > approach. > > We suggest that you write up an addendum/extension to GRE - another > internet draft that specifies how the fields should be used. This can be > kicked around in whatever forum is best, and any users of GRE with Key and > Sequence can then basically implement to the combined specification. > > Are you willing to do that? > Thank You. Regards, Gopal ------------------------------------------------------------------------------------------------------------- Gopal Dommety 408 525 1404 gdommety@cisco.com Cisco Systems, San Jose, CA, 95051 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 11 07:58:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06664 for ; Fri, 11 Feb 2000 07:58:29 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.48DD6110@standards.nortelnetworks.com>; Fri, 11 Feb 2000 7:54:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 40660 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 07:53:34 -0500 Received: from ss3000e.cselt.it by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B0466150@standards.nortelnetworks.com>; Fri, 11 Feb 2000 7:43:29 -0500 Received: from cselt.it (hpi7302.cselt.it [163.162.15.147]) by ss3000e.cselt.it (PMDF V5.2-31 #37044) with ESMTP id <0FPR00C1FNAUZK@ss3000e.cselt.it> for mobile-ip@standards.nortelnetworks.com; Fri, 11 Feb 2000 13:42:30 +0100 (MET) MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en] (Win95; I) Content-type: multipart/mixed; boundary="------------293B5A5B7E1F48E86868888D" X-Accept-Language: en Message-ID: <38A40449.E1B821B4@cselt.it> Date: Fri, 11 Feb 2000 13:44:57 +0100 Reply-To: Simone Ruffino Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Simone Ruffino Organization: CSELT S.p.A. Subject: [MOBILE-IP] (no subject) To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------293B5A5B7E1F48E86868888D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit subscribe mobile-IP --------------293B5A5B7E1F48E86868888D Content-Type: text/x-vcard; charset=us-ascii; name="simone.ruffino.vcf" Content-Description: Card for Simone Ruffino Content-Disposition: attachment; filename="simone.ruffino.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Ruffino;Simone x-mozilla-html:FALSE org:CSELT S.p.A adr:;;;;;; version:2.1 email;internet:simone.ruffino@cselt.it title:Computer Science Engeneer x-mozilla-cpt:;-1 fn:Simone Ruffino end:vcard --------------293B5A5B7E1F48E86868888D-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 11 09:25:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09605 for ; Fri, 11 Feb 2000 09:25:53 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.793E0F60@standards.nortelnetworks.com>; Fri, 11 Feb 2000 9:22:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 40843 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 09:21:08 -0500 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EE7DFFD0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 9:11:08 -0500 Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id IAA13892 for ; Fri, 11 Feb 2000 08:13:35 -0600 (CST) Received: from cc.hut.fi (positron.tky.hut.fi [130.233.17.47]) by smtp-2.hut.fi (8.9.3/8.9.3) with ESMTP id QAA06967; Fri, 11 Feb 2000 16:13:26 +0200 (EET) X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.3 i686) MIME-Version: 1.0 References: <200002111234.EAA25436@nasnfs.eng.sun.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <38A41928.E56D7097@cc.hut.fi> Date: Fri, 11 Feb 2000 16:14:00 +0200 Reply-To: Tom Weckström Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Tom Weckström Organization: HUT/TKK Subject: [MOBILE-IP] true user privacy (Was: Re: Interim WG meeting minutes posted) X-To: pcalhoun@Eng.Sun.COM, Mobile IP lista X-cc: aaa-wg@merit.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit I send this discussion also the the MIP mailing list just to let you know... Is there any need for a REAL user privacy? (If we consider the use of non-trivial NAIs not true privacy.) Will MIP WG be interested to think about a solution for a true privacy, and when, if so? Or is the 'CrYpTeD NAIs' e.g. 23#gksKL5@foo.com enough? Below some discussion and suggestions... Patrice Calhoun wrote: > > see below. as well... :) > > >Patrice Calhoun wrote: > >> > >> In the context of Mobile IP, it means that the roaming user provides an > >> identity that is encrypted in a way that only the home can decrypt it. > >> > >> The issue I have with this requirement, is that it is very difficult to > >> get REAL privacy (given the state of the protocol). Without some challenge > >> of some form (or some unique random data), the encrypted text is always > >> the same, providing encryption, but not privacy. The ISPs can look for > >> the same sequence of binary bits to identify the user. > > > >You are right. REAL privacy would probably mean that the ISPs would not > >get any static ID with which to refer to the user (and with which to > >build e.g. user statistics, profiles, etc.). This clearly requires true > >random idientifiers for users for each registration, AAA session, or > >other renewable entity. > > > >Encypting the user identity so that only the AAAH, HA (or UHO in > >gengeral) can decrypt it, brings still quite a bit more privacy. > >Actually, this might be a desired solution from ISPs' point of view, > >since they might want to build user profiles to learn how their services > >are used. However, linking the encrypted string to a specific user is > >very hard, if all you have is the short string (let's say we would use a > >SHA-1 has from a bunch of data about the user). > > My point of view on this one is simply to use a cryptic (non-encrypted) > NAI. Something along the lines of 3429834hahfd@domain.com is just as > good as an encrypted, and constant, value. > > > > >> > >> More work is needed in Mobile IP to really understand how this can be > >> done. > >> > >> PatC > > > >Yes, indeed. More work is needed, and the goal is quite novel, I think. > >So why was this requirement dropped, then? > > Because the IESG wanted to have a reasonable set of goals that the WG could > achieve. Once the requirements are set, one could always bring in an > I-D that proposes how this can be done, and specifically how it maps to > the specific application being used (Mobile-IP in this case). > > The above is my understanding, I am not speaking for the IESG in this case > (nor have I ever). > > > > >I think even a more complete privacy is achievable. Just my 2 cents in a > >form of a 'quick sketch suggestion': > > > >The mobile user could use a has of his usercode and a one time passwords > >as his identifier. The one time password could be obtained the same way > >as Secure-ID produces its one-time-passwords - through a seeded random > >number gengerator at both ends (AAAH, MN). The AAAF would only know the > >random hash. The recalculation of the one-time-password could be user > >initiated, or timer-based... > > Of course, this requirements an additional Mobile IP message to the Mobile > Node to issue the challenge. As far as PPP is concerned, this can easily > be done via EAP, but in Mobile IP, there isn't a way to issue the > challenge from the AAAH to the Mobile. This is primarily because the > adv that contains the challenge is not generated by the AAAH (since the > FA still has no idea what mobiles are in it's service area). (Note, that my term 'password' is just a term for a random renewable string, that can be used in en/decrypting the NAI.) My idea did not have anything to do with FA advertisements... nor challenges. MN would just renew the password and then inform the AAAH/HA to do the same. All we need is an extension / a bit telling that MN has renewed its password. Since the seeds would be the same, AAAH/HA would be able to calculate the new password, too. The other option was to have this automated so, that the new passwords would be generated every X minutes. This, of course requires clock synchronization. NTP should do. > > So, we (Mobile-IP) need to be a little more clear in how we would actually > support encrypted NAIs before we can make this a real requirement, IMHO. > > PatC OK. Thanks for telling the background. Maybe the use of "scrambled" NAIs is then enough for now. If needs arise and good solutions are proposed, maybe MIP WG can provide a draft for TRUE privacy then... :) Regards, Tom > > > > > >Regards, > > Tom > >> >Perhaps I misunderstand the reason for having "Anonymous Access" but if it > >> >means what I think we have discussed in the past, it would be of value to > >> >ISPs who offer free trial and sign-up services. > >> > > >> >Richard > >> > > >> >On Fri, 11 Feb 2000, Tom Weckström wrote: > >> >> In the meeting minutes it says: > >> >> > >> >> "Anonymous Access: Can we remove this requirement? > >> >> Answer: Yes. " > >> >> > >> >> I would like to get justifications for the removal. > >> >> > >> >> To me, removing this requirement would mean that I would always have to > >> >> reveal my identity to the network operator. > >> >> Am I correct? > >> >> > >> >> It does not matter, if my Home organization AAA knows my identity, but I > >> >> would like to remain anonymous for service providers. If this > >> >> requirement is not fulfilled, then the loads of information the AAAF > >> >> stores may in some occasions be very harmful to roaming users when > >> >> misused. Anonymity would protect roaming users from this kind of terror. > >> > > >> > > > -- Tom Weckström tweckstr@cc.hut.fi Otakaari 20 B 39 Helsinki University of Technology 02150 Espoo Department of Computer Science 09-4683249/040-5642709 http://www.niksula.cs.hut.fi/~tweckstr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 11 11:10:45 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12800 for ; Fri, 11 Feb 2000 11:10:41 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.153D0660@standards.nortelnetworks.com>; Fri, 11 Feb 2000 11:06:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41266 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 11:05:57 -0500 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.930BF940@standards.nortelnetworks.com>; Fri, 11 Feb 2000 10:55:57 -0500 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (VWALL-IN-motgate2 2.0) with ESMTP id IAA06894 for ; Fri, 11 Feb 2000 08:58:25 -0700 (MST)] Received: [from email1.wes.mot.com (email1.wes.mot.com [154.56.3.101]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA27706 for ; Fri, 11 Feb 2000 08:58:24 -0700 (MST)] Received: by email1.wes.mot.com with Internet Mail Service (5.5.2650.21) id <1CLKQ72G>; Fri, 11 Feb 2000 09:58:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <51F347B016ADD011963200805FC1456204BCBF84@email1.wes.mot.com> Date: Fri, 11 Feb 2000 09:58:18 -0600 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: [MOBILE-IP] time slot requests To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Here are the requests I have so far. If you've made a request and it's not on the list, please let me know. If you want a slot and haven't requested one yet, please let us know. The order these are listed implies absolutely nothing. We'll try to accomodate all requests, but time limitations may not allow us to do so. Gabriel M. Reverse Tunneling 10 min Petri Bernhard Private IP addresses 20 min Charlie Perkins AAA Charlie Perkins Regional Registration Charlie Perkins AAA and IPv6 Charlie Perkins Route Optimization Charlie Perkins Registration Keys John Wang Universal Mobile IP ... 20 min Pat Calhoun AAA Keys 10 min Pat Calhoun low latency secure handoff 10 min Pat Calhoun FA assisted handoff 20min Gopal Dommety GRE draft 10 min Gopal Dommety Fast Handover 15 min Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 11 11:18:34 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12985 for ; Fri, 11 Feb 2000 11:18:28 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.37ABEA80@standards.nortelnetworks.com>; Fri, 11 Feb 2000 11:14:52 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41366 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 11:13:43 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0EB8AB90@standards.nortelnetworks.com>; Fri, 11 Feb 2000 11:13: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 IAA17396; Fri, 11 Feb 2000 08:16:08 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA24843; Fri, 11 Feb 2000 08:16:06 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp2.Central.Sun.COM [129.147.36.137]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id IAA29209; Fri, 11 Feb 2000 08:15:59 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-ID: <200002111615.IAA29209@nasnfs.eng.sun.com> Date: Fri, 11 Feb 2000 08:19:03 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] time slot requests X-To: Roberts Phil-QA3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Phil, Since not all of these drafts can be found on the WG web site, could you also provide the relevant I-D names? Thanks, PatC >Here are the requests I have so far. If you've made a request and it's not >on the list, please let me know. If you want a slot and haven't requested >one yet, please let us know. > >The order these are listed implies absolutely nothing. We'll try to >accomodate all requests, but time limitations may not allow us to do so. > >Gabriel M. Reverse Tunneling 10 min >Petri Bernhard Private IP addresses 20 min >Charlie Perkins AAA >Charlie Perkins Regional Registration >Charlie Perkins AAA and IPv6 >Charlie Perkins Route Optimization >Charlie Perkins Registration Keys >John Wang Universal Mobile IP ... 20 min >Pat Calhoun AAA Keys 10 min >Pat Calhoun low latency secure handoff 10 min >Pat Calhoun FA assisted handoff 20min >Gopal Dommety GRE draft 10 min >Gopal Dommety Fast Handover 15 min > >Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 11 11:31:41 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13458 for ; Fri, 11 Feb 2000 11:31:33 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0CBB6A10@standards.nortelnetworks.com>; Fri, 11 Feb 2000 11:27:59 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41416 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 11:27:28 -0500 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.94601030@standards.nortelnetworks.com>; Fri, 11 Feb 2000 11:17:27 -0500 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (VWALL-IN-motgate2 2.0) with ESMTP id JAA05957 for ; Fri, 11 Feb 2000 09:19:55 -0700 (MST)] Received: [from email1.wes.mot.com (email1.wes.mot.com [154.56.3.101]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA09469 for ; Fri, 11 Feb 2000 09:19:55 -0700 (MST)] Received: by email1.wes.mot.com with Internet Mail Service (5.5.2650.21) id <1CLKQ7ND>; Fri, 11 Feb 2000 10:19:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <51F347B016ADD011963200805FC1456204BCBF8B@email1.wes.mot.com> Date: Fri, 11 Feb 2000 10:19:47 -0600 Reply-To: Roberts Phil-QA3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Phil-QA3445 Subject: Re: [MOBILE-IP] time slot requests X-To: "pcalhoun@Eng.Sun.COM" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Yes, I will be happy to. I don't have I-D names for all of them yet, I just wanted to make sure no one's requests have slipped through. I'll send a complete list in the next week or so. -----Original Message----- From: Patrice Calhoun [mailto:Pat.Calhoun@Eng.Sun.COM] Sent: Friday, February 11, 2000 10:19 AM To: Roberts Phil-QA3445; MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] time slot requests Phil, Since not all of these drafts can be found on the WG web site, could you also provide the relevant I-D names? Thanks, PatC >Here are the requests I have so far. If you've made a request and it's not >on the list, please let me know. If you want a slot and haven't requested >one yet, please let us know. > >The order these are listed implies absolutely nothing. We'll try to >accomodate all requests, but time limitations may not allow us to do so. > >Gabriel M. Reverse Tunneling 10 min >Petri Bernhard Private IP addresses 20 min >Charlie Perkins AAA >Charlie Perkins Regional Registration >Charlie Perkins AAA and IPv6 >Charlie Perkins Route Optimization >Charlie Perkins Registration Keys >John Wang Universal Mobile IP ... 20 min >Pat Calhoun AAA Keys 10 min >Pat Calhoun low latency secure handoff 10 min >Pat Calhoun FA assisted handoff 20min >Gopal Dommety GRE draft 10 min >Gopal Dommety Fast Handover 15 min > >Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 11 11:56:20 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14353 for ; Fri, 11 Feb 2000 11:56:17 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.90852DB0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 11:53:08 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41539 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 11:51:32 -0500 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F179CE20@standards.nortelnetworks.com>; Fri, 11 Feb 2000 11:41:32 -0500 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id SAA20557 for ; Fri, 11 Feb 2000 18:44:04 +0200 (EET) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id SAA20244 for ; Fri, 11 Feb 2000 18:44:03 +0200 (EET) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <1RM3DWMR>; Fri, 11 Feb 2000 10:44:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B929600@daeis07nok> Date: Fri, 11 Feb 2000 10:43:22 -0600 Reply-To: Raj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Raj.Patil@NOKIA.COM Subject: [MOBILE-IP] Implementations of Mobile IP Challenge/Response Extensions I-D To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM WG members, Can you please let me or Phil know if you have implemented the Mobile IP Challenge/Response Extensions (draft-ietf-mobileip-challenge-09.txt) I-D. This information is important to the status of the draft as it goes to the IESG. Regards, -Basavaraj Patil <><><><><><><><><><><><><><><><><><><><><><> | Basavaraj Patil | Ph: +1 972-894-6709 Nokia Networks | Fax: +1 972-894-5349 6000 Connection Dr. | M/S M8-540 | Irving, Texas 75039 | e-mail : Raj.Patil@nokia.com <><><><><><><><><><><><><><><><><><><><><><> From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 11 13:57:30 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17360 for ; Fri, 11 Feb 2000 13:57:27 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.77198C70@standards.nortelnetworks.com>; Fri, 11 Feb 2000 13:54:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42184 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 13:52:24 -0500 Received: from btm4r4.alcatel.be by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D3C7F7B0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 13:42:24 -0500 Received: from btmq9s.rc.bel.alcatel.be (root@btmq9s.rc.bel.alcatel.be [138.203.65.182]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id TAA24182 for ; Fri, 11 Feb 2000 19:44:56 +0100 (MET) Received: from alcatel.be (bt00q8 [138.203.66.118]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) with ESMTP id TAA27190 for ; Fri, 11 Feb 2000 19:44:45 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------9C907D3A3DF51230FE6D8888" Message-ID: <38A4588D.92FCE771@alcatel.be> Date: Fri, 11 Feb 2000 19:44:29 +0100 Reply-To: Lieve Bos Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Lieve Bos Subject: [MOBILE-IP] micromobility in IPv6 ? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------9C907D3A3DF51230FE6D8888 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi guys, I am pretty new in this area so don't shoot me if I ask a stupid question. I am trying to get a grip on all this macro and micro mobility stuff. As I understand it, there are two possible (in the case of FA care off addresses) levels of mobility in IPv4: mobile IP for solving the macro mobility problem until the FA and micro mobility between the FA and the terminal. What happens now in IPv6 where there is no FA concept (all co-located care off addresses)? Is there nothing specific that supports fast handoffs in IPv6? As I understand it in IPv6 you have to obtain a new address (network prefix) every time you enter a new network, get authenticated and update bindings (in HA and Correspondent Nodes). Isn't this going to be slower than protocols like cellular IP where routing tables only have to be updated locally... Lieve --------------9C907D3A3DF51230FE6D8888 Content-Type: text/x-vcard; charset=us-ascii; name="lieve.bos.vcf" Content-Description: Card for Lieve Bos Content-Disposition: attachment; filename="lieve.bos.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Bos;Lieve tel;fax:+32(0)3 2409932 tel;work:+32(0)3 2415891 x-mozilla-html:FALSE url:http://www.rc.bel.alcatel.be/projects/mobile/umts/nait1.html org:Alcatel Bell;UMTS service architecture, Corporate Research Centre version:2.1 email;internet:lieve.bos@alcatel.be title:Research engineer adr;quoted-printable:;;Francis Wellesplein 1=0D=0A=0D=0A;Antwerpen;;2018;Belgium x-mozilla-cpt:;11184 fn:Lieve Bos end:vcard --------------9C907D3A3DF51230FE6D8888-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 11 18:07:26 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25603 for ; Fri, 11 Feb 2000 18:07:24 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5951B7D0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 18:03:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42786 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 18:02:26 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.279AF8F0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 18:02:26 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id PAA09170; Fri, 11 Feb 2000 15:03:08 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id PAA15365; Fri, 11 Feb 2000 15:02:56 -0800 X-Virus-Scanned: Fri, 11 Feb 2000 15:02:56 -0800 Nokia Silicon Valley AntiVirus Appliance Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma015243; Fri, 11 Feb 00 15:02:52 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <38A4588D.92FCE771@alcatel.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38A4951C.A369B13F@iprg.nokia.com> Date: Fri, 11 Feb 2000 15:02:52 -0800 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] micromobility in IPv6 ? X-To: Lieve Bos To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Lieve, > I am pretty new in this area so don't shoot me if I ask a stupid > question. I am trying to get a grip on all this macro and micro mobility > stuff. So are a lot of people. > As I understand it, there are two possible (in the case of FA care off > addresses) levels of mobility in IPv4: mobile IP for solving the macro > mobility problem until the FA and micro mobility between the FA and the > terminal. These are not necessarily different. On the other hand, it is always possible to make a difference even if one is not necesary. > What happens now in IPv6 where there is no FA concept (all co-located > care off addresses)? How about using the routers? > Is there nothing specific that supports fast > handoffs in IPv6? I reckon it depends on how fast the stateless or stateful address allocation works. So, it would be nice to make that fast. However, that does not mean that IPv6 is inherently slow. > As I understand it in IPv6 you have to obtain a new > address (network prefix) every time you enter a new network, get > authenticated and update bindings (in HA and Correspondent Nodes). Isn't > this going to be slower than protocols like cellular IP where routing > tables only have to be updated locally... I don't see anywhere in the specifications where it says you have to do a remote authentication on every new network. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 11 18:29:11 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26018 for ; Fri, 11 Feb 2000 18:29:07 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6F826240@standards.nortelnetworks.com>; Fri, 11 Feb 2000 18:25:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42854 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 18:24:21 -0500 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D17FC020@standards.nortelnetworks.com>; Fri, 11 Feb 2000 18:14:21 -0500 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id BAA28322 for ; Sat, 12 Feb 2000 01:16:54 +0200 (EET) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id BAA01825 for ; Sat, 12 Feb 2000 01:16:53 +0200 (EET) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <1RM27ARF>; Fri, 11 Feb 2000 17:16:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B92960F@daeis07nok> Date: Fri, 11 Feb 2000 17:16:11 -0600 Reply-To: Raj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Raj.Patil@NOKIA.COM Subject: [MOBILE-IP] WG Last Call - Mobility Support in IPv6 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Mobile IP WG members, Mobility Support in IPv6 (draft-ietf-mobileip-ipv6-10.txt) has been issued. Please treat this notification as a WG last call on this draft. We would appreciate comments and feedback on this I-D within the next two weeks. WG Last call issued on : Feb 11th, 2000 -Basavaraj Patil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 11 18:31:58 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26141 for ; Fri, 11 Feb 2000 18:31:56 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B7DF7820@standards.nortelnetworks.com>; Fri, 11 Feb 2000 18:27:57 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42857 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 11 Feb 2000 18:26:35 -0500 Received: from gwa.ericsson.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.219304A0@standards.nortelnetworks.com>; Fri, 11 Feb 2000 18:16:35 -0500 Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159]) by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id RAA03257 for ; Fri, 11 Feb 2000 17:19:09 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id RAA29960 for ; Fri, 11 Feb 2000 17:19:09 -0600 (CST) Received: from ericsson.com (pc176197.eur.ericsson.se [138.85.176.197]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA24693 for ; Fri, 11 Feb 2000 17:19:07 -0600 (CST) X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <200002111539.HAA28540@nasnfs.eng.sun.com> <38A48AB5.9A8A9F07@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38A498E7.765B3616@ericsson.com> Date: Fri, 11 Feb 2000 15:19:03 -0800 Reply-To: Tomas =?iso-8859-1?Q?Goldbeck=2DL=F6we?= Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Tomas =?iso-8859-1?Q?Goldbeck=2DL=F6we?= Subject: Re: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-challenge-09.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, As a conclusion from our discussion on the mail list the other week, my understanding was that we agreed on adding text to the challenge / response draft to prevent the deadlock that can occur when the mobile node continously tries to register using old keys. My understanding was adding something like this: A Mobile Node that receives a BAD_AUTHENTICATION error code SHOULD include the MN-AAA Authentication Extension in the next Registration Request. This will make it possible for the Foreign Agent to use its AAA infrastructure in order to authenticate the Mobile Node. Regards, --> Tomas From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 14 01:45:20 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22034 for ; Mon, 14 Feb 2000 01:45:20 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.91C0E4A0@standards.nortelnetworks.com>; Mon, 14 Feb 2000 1:41:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45392 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 01:40:03 -0500 Received: from tsbgw.wide.toshiba.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0437CA00@standards.nortelnetworks.com>; Mon, 14 Feb 2000 1:30:03 -0500 Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id PAA10149; Mon, 14 Feb 2000 15:32:30 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id PAA06785; Mon, 14 Feb 2000 15:32:30 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (cent.isl.rdc.toshiba.co.jp [133.196.16.40]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with ESMTP id PAA16019; Mon, 14 Feb 2000 15:32:30 +0900 (JST) Message-ID: <200002140632.PAA16019@isl.rdc.toshiba.co.jp> Date: Mon, 14 Feb 2000 15:32:29 +0900 Reply-To: FUKUMOTO Atsushi Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: FUKUMOTO Atsushi Subject: Re: [MOBILE-IP] New Registration Keys draft X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: charliep's message of "Thu, 10 Feb 2000 14:43:34 PST." <38A33F16.5920A03A@iprg.nokia.com> Charlie Perkins wrote: > Unless someone offers a better solution, I will probably specify > some default parameters from the "well-known group" GF(2^185), > as discussed in appendix E.4 from RFC 2412, using the suggested > generating point (24,13) and so on. I'm no cryptographer, but, wasn't the GF(2^185) questioned its strength in IPSec group, and incompatible with other standards such as IEEE, ANSI, or NIST recommendation? (ref. draft-ietf-ike-ecc-groups-01.txt) FUKUMOTO Atsushi fukumoto@isl.rdc.toshiba.co.jp From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 14 04:12:01 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02301 for ; Mon, 14 Feb 2000 04:12:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1F476C90@standards.nortelnetworks.com>; Mon, 14 Feb 2000 4:08:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45485 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 04:06:55 -0500 Received: from tokyo.ccrle.nec.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EE625590@standards.nortelnetworks.com>; Mon, 14 Feb 2000 4:06:55 -0500 Received: from wallace.heidelberg.ccrle.nec.de (Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.8.7/3.6W980303HK) with ESMTP id KAA29874 for ; Mon, 14 Feb 2000 10:12:14 +0100 (CET) Received: from ccrle.nec.de (Arthur.heidelberg.ccrle.nec.de [192.168.102.69]) by wallace.heidelberg.ccrle.nec.de (8.8.7/3.6W980203HK) with ESMTP id KAA10030 for ; Mon, 14 Feb 2000 10:23:17 +0100 (CET) X-Mailer: Mozilla 4.6 [de] (WinNT; I) X-Accept-Language: de MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38A7C667.E3A2F1C8@ccrle.nec.de> Date: Mon, 14 Feb 2000 09:10:00 +0000 Reply-To: Hannes Hartenstein Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Hannes Hartenstein Subject: [MOBILE-IP] FA-assisted handoff To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, just a few questions/comments on the draft "Foreign agent assisted handoff" by Kempf and Calhoun. In the draft it is (implicitly) argued that FA advertisements are no longer needed when the proposed hand-off request can be sent and this would save bandwidth over the wireless link. ("...it is questionable whether advertisements are appropriate in a network whose bandwidth is considered scarce..."). But, as I understand it, in order to decide a handoff, a FA needs measurement reports from the mobile node (e.g. link quality parameters), thus, there is some trade-off involved (in GSM, for example, those reports are sent every 480ms). So, does a network-assisted handoff scheme really save some bandwidth? A fast (MN-initiated) handoff can be achieved with Mobile IP using link layer information as, e.g., demonstrated in the HUT Dynamics implementation. A network-assisted/initiated handoff is probably somewhat slower than a locally, i.e., on the MN, decided handoff. Therefore, I see the motivation for the introduction of network-assisted handoffs in the additional ability to take into account traffic considerations (not known to the MN). In my understanding a network- assisted handoff might not be _fast_ but it can nevertheless be _seamless_ since all the "set-up work" can be done while the MN continues to listen to the old base station. Thanks, Hannes -- Dr Hannes Hartenstein Hannes.Hartenstein@ccrle.nec.de Research Staff Member Tel.: +49 6221 905 11 15 C&C Research Laboratories Fax.: +49 6221 905 11 55 NEC Europe Ltd. Adenauerplatz 6 69115 Heidelberg, Germany http://www.ccrle.nec.de/heidelberg/index.html From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 14 04:20:52 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02328 for ; Mon, 14 Feb 2000 04:20:52 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.64732330@standards.nortelnetworks.com>; Mon, 14 Feb 2000 4:17:23 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45551 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 04:16:14 -0500 Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.35C5ACB0@standards.nortelnetworks.com>; Mon, 14 Feb 2000 4:16:04 -0500 Received: from iseran.inrialpes.fr (iseran.inrialpes.fr [194.199.24.100]) by ebene.inrialpes.fr (8.9.3/8.8.5) with ESMTP id KAA09120; Mon, 14 Feb 2000 10:13:49 +0100 (MET) Received: from inrialpes.fr (localhost [127.0.0.1]) by iseran.inrialpes.fr (8.8.7/8.8.5) with ESMTP id KAA02778; Mon, 14 Feb 2000 10:18:28 +0100 (MET) X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <38A4588D.92FCE771@alcatel.be> Content-Type: multipart/alternative; boundary="------------D78BE0247E18375B5DD4022E" Message-ID: <38A7C864.24A7BAE9@inrialpes.fr> Date: Mon, 14 Feb 2000 10:18:28 +0100 Reply-To: Claude.Castelluccia@INRIALPES.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Claude Castelluccia Subject: Re: [MOBILE-IP] micromobility in IPv6 ? X-To: Lieve Bos To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --------------D78BE0247E18375B5DD4022E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Lieve Bos wrote: > Hi guys, > > I am pretty new in this area so don't shoot me if I ask a stupid > question. I am trying to get a grip on all this macro and micro mobility > stuff. > > As I understand it, there are two possible (in the case of FA care off > addresses) levels of mobility in IPv4: mobile IP for solving the macro > mobility problem until the FA and micro mobility between the FA and the > terminal. > > What happens now in IPv6 where there is no FA concept (all co-located > care off addresses)? Is there nothing specific that supports fast > handoffs in IPv6? As I understand it in IPv6 you have to obtain a new > address (network prefix) every time you enter a new network, get > authenticated and update bindings (in HA and Correspondent Nodes). Isn't > this going to be slower than protocols like cellular IP where routing > tables only have to be updated locally... maybe, unless you use some kind of Hierarchical Mobile IPv6 scheme ( see for an example of such scheme http://www.inrialpes.fr/planete/people/ccastel/hmip.ps.gz). In this case you will have comparable performance..... regards, Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------D78BE0247E18375B5DD4022E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,

Lieve Bos wrote:

Hi guys,

I am pretty new in this area so don't shoot me if I ask a stupid
question. I am trying to get a grip on all this macro and micro mobility
stuff.

As I understand it, there are two possible (in the case of FA care off
addresses) levels of mobility in IPv4: mobile IP for solving the macro
mobility problem until the FA and micro mobility between the FA and the
terminal.

What happens now in IPv6 where there is no FA concept (all co-located
care off addresses)? Is there nothing specific that supports fast
handoffs in IPv6? As I understand it in IPv6 you have to obtain a new
address (network prefix) every time you enter a new network, get
authenticated and update bindings (in HA and Correspondent Nodes). Isn't
this going to be slower than protocols like cellular IP where routing
tables only have to be updated locally...


maybe, unless you use some kind of Hierarchical Mobile IPv6 scheme  ( see
 for an example  of such scheme http://www.inrialpes.fr/planete/people/ccastel/hmip.ps.gz).
In this case you will have comparable performance.....

regards,

Claude.
  

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------D78BE0247E18375B5DD4022E-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 14 06:56:39 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03681 for ; Mon, 14 Feb 2000 06:56:39 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.13D269C0@standards.nortelnetworks.com>; Mon, 14 Feb 2000 6:52:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45695 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 06:51:32 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.87EF5E00@standards.nortelnetworks.com>; Mon, 14 Feb 2000 6:41:32 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03459; Mon, 14 Feb 2000 06:44:13 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200002141144.GAA03459@ietf.org> Date: Mon, 14 Feb 2000 06:44:13 -0500 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-ipv6-10.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Mobility Support in IPv6 Author(s) : D. Johnson, C. Perkins Filename : draft-ietf-mobileip-ipv6-10.txt Pages : 103 Date : 11-Feb-00 This document specifies the operation of mobile computers using IPv6. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines four new IPv6 destination options, including one that MUST be supported in packets received by any node, whether mobile or stationary. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-10.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-ipv6-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-ipv6-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000211104135.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-ipv6-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-ipv6-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000211104135.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 14 07:07:54 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03683 for ; Mon, 14 Feb 2000 06:56:39 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.13F3AD60@standards.nortelnetworks.com>; Mon, 14 Feb 2000 6:52:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45696 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 06:51:39 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8B8ECBE0@standards.nortelnetworks.com>; Mon, 14 Feb 2000 6:41:38 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03484; Mon, 14 Feb 2000 06:44:19 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200002141144.GAA03484@ietf.org> Date: Mon, 14 Feb 2000 06:44:19 -0500 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-optim-09.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Route Optimization in Mobile IP Author(s) : C. Perkins, D. Johnson Filename : draft-ietf-mobileip-optim-09.txt Pages : 24 Date : 11-Feb-00 Using the base Mobile IP protocol, all datagrams destined to a mobile node are routed through that mobile node's home agent, which then tunnels each datagram to the mobile node's current location. This document defines Route Optimization messages and extensions to the base protocol to optimize datagram routing to a mobile node. Using these protocol extensions, correspondent nodes may cache the binding of a mobile node, and then tunnel their datagrams for the mobile node directly to the care-of address, bypassing the mobile node's home agent. Extensions are also provided to allow datagrams in flight when a mobile node moves, and datagrams sent based on an out-of-date cached binding, to be forwarded directly to the mobile node's new binding. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-optim-09.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-optim-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-optim-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000211104146.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-optim-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-optim-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000211104146.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 14 09:00:44 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10175 for ; Mon, 14 Feb 2000 09:00:41 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7331C990@standards.nortelnetworks.com>; Mon, 14 Feb 2000 8:56:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45902 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 08:55:41 -0500 Received: from mailgate.rz.uni-karlsruhe.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DFE04690@standards.nortelnetworks.com>; Mon, 14 Feb 2000 8:45:41 -0500 Received: from blackfoot.telematik.informatik.uni-karlsruhe.de (blackfoot.telematik.informatik.uni-karlsruhe.de [129.13.35.14]) by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.02 #2) id 12KLrS-0005ek-00; Mon, 14 Feb 2000 14:48:22 +0100 Received: from tpce13 (paehlke@tpce13.telematik.informatik.uni-karlsruhe.de [129.13.41.113]) by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with SMTP id OAA00152 for ; Mon, 14 Feb 2000 14:48:21 +0100 (MET) X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <38A4588D.92FCE771@alcatel.be> <38A4951C.A369B13F@iprg.nokia.com> MIME-Version: 1.0 Message-ID: <00021414482106.24820@tpce13> Date: Mon, 14 Feb 2000 14:26:49 +0100 Reply-To: paehlke@telematik.informatik.uni-karlsruhe.de Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Frank Paehlke Organization: Universitaet Karlsruhe, Institut fuer Telematik Subject: Re: [MOBILE-IP] micromobility in IPv6 ? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <38A4951C.A369B13F@iprg.nokia.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA10175 Hello, > > I am pretty new in this area so don't shoot me if I ask a stupid > > question. I am trying to get a grip on all this macro and micro mobility > > stuff. > > So are a lot of people. ... including me :-) I am currently involved in a research project focussing on secure micro-mobility support for mobile IP. Since I have already spent a lot of time thinking on how to transparently integrate such mechanisms, the following question has also arised to me: > > As I understand it in IPv6 you have to obtain a new > > address (network prefix) every time you enter a new network, get > > authenticated and update bindings (in HA and Correspondent Nodes). Isn't > > this going to be slower than protocols like cellular IP where routing > > tables only have to be updated locally... > > I don't see anywhere in the specifications where it says you have to > do a remote authentication on every new network. the problem, at least as far as I can tell, is the following sentence which appears in RFC 2002 as well as in the latest RFC 2002bis draft (section 3.6.2.1): "[...] if the Code field indicates that the registration was accepted by the home agent, exactly one Mobile-Home Authentication Extension MUST be present in the Registration Reply, and the mobile node MUST check the Authenticator value in the Extension." This specification, if strictly followed, seems to inhibit any re-registration without involving the home network. Perhaps it would be better to add a statement like "The Mobile-Home Authentication Extension is not needed if a security association is established between the Mobile Node and the foreign network's infrastructure, and the Registration Reply contains a valid Mobile-Foreign Authentication Extension." This is already explicitly demanded by the HAWAII draft and implemented, for example, in HUT Dynamics. Please correct me if I have understood something wrong. Best regards, Frank -- Frank Paehlke Institut fuer Telematik Phone: +49 721 608-6398 Universitaet Karlsruhe (TH) Fax: +49 721 388097 D-76128 Karlsruhe, Germany EMail: paehlke@ira.uka.de From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 14 10:52:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15172 for ; Mon, 14 Feb 2000 10:52:55 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1F123150@standards.nortelnetworks.com>; Mon, 14 Feb 2000 10:49:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 46034 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 10:49:01 -0500 Received: from tokyo.ccrle.nec.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B4E86AC0@standards.nortelnetworks.com>; Mon, 14 Feb 2000 10:39:01 -0500 Received: from wallace.heidelberg.ccrle.nec.de (Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.8.7/3.6W980303HK) with ESMTP id QAA01797; Mon, 14 Feb 2000 16:44:12 +0100 (CET) Received: from ccrle.nec.de (atoll.heidelberg.ccrle.nec.de [192.168.102.96]) by wallace.heidelberg.ccrle.nec.de (8.8.7/3.6W980203HK) with ESMTP id QAA14161; Mon, 14 Feb 2000 16:55:16 +0100 (CET) X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <388E7F29.2BCF55B6@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38A8222E.6265B785@ccrle.nec.de> Date: Mon, 14 Feb 2000 16:41:34 +0100 Reply-To: Karl Jonas Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Karl Jonas Organization: NEC CCRLE Subject: [MOBILE-IP] simultaneous bindings X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello All, is it possible to keep 'simultaneous registrations' in MIP, just by not prohibiting them in the standard? Simultaneous registrations are useful if the mobile terminal cannot listen to multiple basestations all the time, but can switch to a new basestation for a very short duration (enough to register). In this case, the MT may want to register with a new address, then keep listening to the old BS for a while, and switch to the new BS permanently after it can assume that all trafic follows the new path. karl -- Karl Jonas, NEC C&C Research Labs EMail: karl.jonas@ieee.org Tel.: +49.(0)6221.905 11 21 Fax: +49.(0)6221.905 11 55 http://www.ccrle.nec.de/heidelberg/index.html From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 14 11:47:00 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16793 for ; Mon, 14 Feb 2000 11:46:59 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B41D8A90@standards.nortelnetworks.com>; Mon, 14 Feb 2000 11:43:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 46224 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 11:42:08 -0500 Received: from ocelot.cs.odu.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.20609B90@standards.nortelnetworks.com>; Mon, 14 Feb 2000 11:32:08 -0500 Received: from calvin.cs.odu.edu (hamid@calvin.cs.odu.edu [128.82.4.199]) by ocelot.cs.odu.edu (8.9.3/8.9.3) with ESMTP id LAA22178 for ; Mon, 14 Feb 2000 11:34:50 -0500 (EST) Received: from localhost (hamid@localhost) by calvin.cs.odu.edu (8.9.3/8.9.1) with ESMTP id LAA23940 for ; Mon, 14 Feb 2000 11:34:49 -0500 (EST) X-Authentication-Warning: calvin.cs.odu.edu: hamid owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 14 Feb 2000 11:34:49 -0500 Reply-To: Ayman A Abdel Hamid Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ayman A Abdel Hamid Subject: [MOBILE-IP] required registration with FA To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200002141144.GAA03459@ietf.org> Hi, I have a question, i would appreciate if someone would clear it out for me? in mobile-ip for IPv4, -a mobile node decided to register with its home agent after acquiring a co-located care-of-address - the mobile node receives an FA advertisement requiring registration with that foreign agent, "R" bit is set. Question: will the mobile node deregister the first mobility binding with the HA, then register with the FA using its co-located care-of-address?? or will the mobile node register with the FA, which in turn will relay the registration request to the HA. in this case, if HA supports simultaneous bindings, It is OK, if not what happens? regards From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 14 12:04:20 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17601 for ; Mon, 14 Feb 2000 12:04:20 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.19404780@standards.nortelnetworks.com>; Mon, 14 Feb 2000 12:00:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 46314 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 12:00:30 -0500 Received: from tiku.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B133BBA0@standards.nortelnetworks.com>; Mon, 14 Feb 2000 11:50:30 -0500 Received: from beta.hut.fi (jtm@beta.hut.fi [130.233.224.51]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id SAA32411; Mon, 14 Feb 2000 18:53:09 +0200 (EET) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 14 Feb 2000 18:53:16 +0200 Reply-To: Jari T Malinen Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jari T Malinen Subject: Re: [MOBILE-IP] micromobility in IPv6 ? X-To: Frank Paehlke To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <00021414482106.24820@tpce13> Hi, Frank, I would like to give an alternative interpretation to the 3.6.2.1 that you quote below. On Mon, 14 Feb 2000, Frank Paehlke wrote: > I am currently involved in a research project focussing on secure > micro-mobility support for mobile IP. Since I have already spent a lot > of time thinking on how to transparently integrate such mechanisms, the > following question has also arised to me: > > > > As I understand it in IPv6 you have to obtain a new > > > address (network prefix) every time you enter a new network, get > > > authenticated and update bindings (in HA and Correspondent Nodes). Isn't > > > this going to be slower than protocols like cellular IP where routing > > > tables only have to be updated locally... > > > > I don't see anywhere in the specifications where it says you have to > > do a remote authentication on every new network. > > the problem, at least as far as I can tell, is the following sentence > which appears in RFC 2002 as well as in the latest RFC 2002bis draft > (section 3.6.2.1): > > "[...] if the Code field indicates that the registration was accepted > by the home agent, exactly one Mobile-Home Authentication Extension > MUST be present in the Registration Reply, and the mobile node MUST > check the Authenticator value in the Extension." > > This specification, if strictly followed, seems to inhibit any > re-registration without involving the home network. Perhaps it would be > better to add a statement like "The Mobile-Home Authentication > Extension is not needed if a security association is established between > the Mobile Node and the foreign network's infrastructure, and the > Registration Reply contains a valid Mobile-Foreign Authentication > Extension." This is already explicitly demanded by the HAWAII draft and > implemented, for example, in HUT Dynamics. In fact, the draft might be interpreted so that with code 0 it is not necessarily the HA that accepted the message. In such a case, the section 3.6.2.1 would still be valid even though the Mobile-Foreign Authentication extension is used with localized replies. Then, only such message that really comes from HA would be the one to which the MUSTs fully apply. This interpretation would keep the text as is, would properly support at non-regional MN with both MUSTs in place, and would allow regional features as implemented in Dynamics - HUT Mobile IP. > Please correct me if I have understood something wrong. Likewise, e.g. our code interpretation is not 100% clear in this.. > Best regards, > Frank > -- > Frank Paehlke > Institut fuer Telematik Phone: +49 721 608-6398 > Universitaet Karlsruhe (TH) Fax: +49 721 388097 > D-76128 Karlsruhe, Germany EMail: paehlke@ira.uka.de > Regards, --jari Jari Malinen (http://www.cs.hut.fi/~jtm) Researcher, HUT/CS Lab. Tel. +358 9 451 4774, fax +358 9 451 5351. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 14 12:31:29 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18541 for ; Mon, 14 Feb 2000 12:31:28 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E416FA50@standards.nortelnetworks.com>; Mon, 14 Feb 2000 12:27:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 46464 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 12:26:13 -0500 Received: from btm4r4.alcatel.be by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AD0ED7D0@standards.nortelnetworks.com>; Mon, 14 Feb 2000 12:26:10 -0500 Received: from btmq9s.rc.bel.alcatel.be (root@btmq9s.rc.bel.alcatel.be [138.203.65.182]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id SAA28176; Mon, 14 Feb 2000 18:28:51 +0100 (MET) Received: from alcatel.be (bt00q8 [138.203.66.118]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) with ESMTP id SAA25539; Mon, 14 Feb 2000 18:28:46 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: multipart/mixed; boundary="------------937C704148687DBDE4A50222" Message-ID: <38A83B3C.53A90C05@alcatel.be> Date: Mon, 14 Feb 2000 18:28:28 +0100 Reply-To: Lieve Bos Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Lieve Bos Subject: Re: [MOBILE-IP] micromobility in IPv6 ? X-To: Jari T Malinen To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------937C704148687DBDE4A50222 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jari T Malinen wrote: > > Hi, Frank, > > I would like to give an alternative interpretation to the 3.6.2.1 that > you quote below. > > On Mon, 14 Feb 2000, Frank Paehlke wrote: > > > I am currently involved in a research project focussing on secure > > micro-mobility support for mobile IP. Since I have already spent a lot > > of time thinking on how to transparently integrate such mechanisms, the > > following question has also arised to me: > > > > > > As I understand it in IPv6 you have to obtain a new > > > > address (network prefix) every time you enter a new network, get > > > > authenticated and update bindings (in HA and Correspondent Nodes). Isn't > > > > this going to be slower than protocols like cellular IP where routing > > > > tables only have to be updated locally... > > > > > > I don't see anywhere in the specifications where it says you have to > > > do a remote authentication on every new network. > > > > the problem, at least as far as I can tell, is the following sentence > > which appears in RFC 2002 as well as in the latest RFC 2002bis draft > > (section 3.6.2.1): > > > > "[...] if the Code field indicates that the registration was accepted > > by the home agent, exactly one Mobile-Home Authentication Extension > > MUST be present in the Registration Reply, and the mobile node MUST > > check the Authenticator value in the Extension." > > > > This specification, if strictly followed, seems to inhibit any > > re-registration without involving the home network. Perhaps it would be > > better to add a statement like "The Mobile-Home Authentication > > Extension is not needed if a security association is established between > > the Mobile Node and the foreign network's infrastructure, and the > > Registration Reply contains a valid Mobile-Foreign Authentication > > Extension." This is already explicitly demanded by the HAWAII draft and > > implemented, for example, in HUT Dynamics. > > In fact, the draft might be interpreted so that with code 0 it is not > necessarily the HA that accepted the message. In such a case, the > section 3.6.2.1 would still be valid even though the Mobile-Foreign > Authentication extension is used with localized replies. Then, only > such message that really comes from HA would be the one to which the > MUSTs fully apply. This interpretation would keep the text as is, would > properly support at non-regional MN with both MUSTs in place, and > would allow regional features as implemented in Dynamics - HUT Mobile IP. Are you suggesting here that registration reply messages should not always necessarily come from the HA? Can a mobile simply register with a FA (without the HA involved) and get a registration reply from the FA? In that case how do you explain then the following sentence in RFC 2002 bis draft (section 3.4): " If the mobile node is requesting service from a foreign agent, that foreign agent will receive the Reply from the home agent and subsequently relay it to the mobile node." > > Please correct me if I have understood something wrong. > > Likewise, e.g. our code interpretation is not 100% clear in this.. > > > Best regards, > > Frank > > -- > > Frank Paehlke > > Institut fuer Telematik Phone: +49 721 608-6398 > > Universitaet Karlsruhe (TH) Fax: +49 721 388097 > > D-76128 Karlsruhe, Germany EMail: paehlke@ira.uka.de > > > > Regards, > > --jari > > Jari Malinen (http://www.cs.hut.fi/~jtm) > Researcher, HUT/CS Lab. Tel. +358 9 451 4774, fax +358 9 451 5351. --------------937C704148687DBDE4A50222 Content-Type: text/x-vcard; charset=us-ascii; name="lieve.bos.vcf" Content-Description: Card for Lieve Bos Content-Disposition: attachment; filename="lieve.bos.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Bos;Lieve tel;fax:+32(0)3 2409932 tel;work:+32(0)3 2415891 x-mozilla-html:FALSE url:http://www.rc.bel.alcatel.be/projects/mobile/umts/nait1.html org:Alcatel Bell;UMTS service architecture, Corporate Research Centre version:2.1 email;internet:lieve.bos@alcatel.be title:Research engineer adr;quoted-printable:;;Francis Wellesplein 1=0D=0A=0D=0A;Antwerpen;;2018;Belgium x-mozilla-cpt:;11184 fn:Lieve Bos end:vcard --------------937C704148687DBDE4A50222-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 14 13:07:29 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19664 for ; Mon, 14 Feb 2000 13:07:29 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EFD32E90@standards.nortelnetworks.com>; Mon, 14 Feb 2000 13:03:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 46550 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 13:02:38 -0500 Received: from madcow.borg.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5F9469D0@standards.nortelnetworks.com>; Mon, 14 Feb 2000 12:52:38 -0500 Received: from mail.borg.com (mail.borg.com [205.217.206.192]) by madcow.borg.com (8.9.0/8.8.8) with ESMTP id MAA05795; Mon, 14 Feb 2000 12:55:02 -0500 (EST) Received: from swc (cti-fw2.borg.com [205.217.206.199]) by mail.borg.com (8.9.3/8.9.3) with SMTP id MAA67128; Mon, 14 Feb 2000 12:54:57 -0500 (EST) (envelope-from stu@critical.com) X-Sender: stu@mail.borg.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) References: <388E7F29.2BCF55B6@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.6.32.20000214125721.0079a210@mail.borg.com> Date: Mon, 14 Feb 2000 12:57:21 -0500 Reply-To: Stuart Card Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Stuart Card Subject: Re: [MOBILE-IP] simultaneous bindings X-To: Karl Jonas To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <38A8222E.6265B785@ccrle.nec.de> At 04:41 PM 2000-02-14 +0100, Karl Jonas wrote: >is it possible to keep 'simultaneous registrations' in MIP, just by >not prohibiting them in the standard? > >Simultaneous registrations are useful if the mobile terminal cannot >listen to multiple basestations all the time, but can switch to >a new basestation for a very short duration (enough to register). Our R&D for the Air Force involves mobile LANs on aircraft. These aircraft fly in and out of base station coverage areas. They are frequently in overlapping footprints, for instance: a Line-Of-Sight VHF radio link (low bandwidth) to a nearby airfield; a Beyond-LOS HF radio link (very low bandwidth) to a distant base station; and a SATCOM UHF radio link (low bandwidth and severe contention). Since the aggregate bandwidth requirements of the various applications on the flying LAN far exceed the bandwidth of even the fattest available pipe, we need to concurrently route traffic over multiple wireless links (via different basestations, implying via different IP gateways). We _need_ multiple concurrent registrations, _both_ due to the momentary on-again/off-again connectivity seen along the margins of radio footprints, and due to our need to use any and all available links truly _concurrently_. I haven't read the RFCs carefully enough to know exactly how much of what we need to do will be supported by the base Mobile-IP standard, versus how much we will need to implement with vendor extensions (per those provisions). I would be happy to discuss this in greater detail if anyone is interested. ------------------------------------------------------------------------ Stuart W. Card, Chief Scientist & Vice-Pres., Critical Technologies Inc. Suite 400 Technology Center, 4th Floor 1001 Broad Street, Utica NY 13501 315-793-0248 FAX -9710 http://www.critical.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 14 13:22:43 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20125 for ; Mon, 14 Feb 2000 13:22:40 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0C9441C0@standards.nortelnetworks.com>; Mon, 14 Feb 2000 13:18:57 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 46620 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 13:17:54 -0500 Received: from tiku.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8174AD10@standards.nortelnetworks.com>; Mon, 14 Feb 2000 13:07:54 -0500 Received: from beta.hut.fi (jtm@beta.hut.fi [130.233.224.51]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id UAA25412; Mon, 14 Feb 2000 20:10:31 +0200 (EET) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 14 Feb 2000 20:10:39 +0200 Reply-To: Jari T Malinen Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jari T Malinen Subject: Re: [MOBILE-IP] micromobility in IPv6 ? X-To: Lieve Bos To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <38A83B3C.53A90C05@alcatel.be> On Mon, 14 Feb 2000, Lieve Bos wrote: > Jari T Malinen wrote: > > > > Hi, Frank, > > > > I would like to give an alternative interpretation to the 3.6.2.1 that > > you quote below. > > > > On Mon, 14 Feb 2000, Frank Paehlke wrote: > > > > > I am currently involved in a research project focussing on secure > > > micro-mobility support for mobile IP. Since I have already spent a lot > > > of time thinking on how to transparently integrate such mechanisms, the > > > following question has also arised to me: > > > > > > > > As I understand it in IPv6 you have to obtain a new > > > > > address (network prefix) every time you enter a new network, get > > > > > authenticated and update bindings (in HA and Correspondent Nodes). Isn't > > > > > this going to be slower than protocols like cellular IP where routing > > > > > tables only have to be updated locally... > > > > > > > > I don't see anywhere in the specifications where it says you have to > > > > do a remote authentication on every new network. > > > > > > the problem, at least as far as I can tell, is the following sentence > > > which appears in RFC 2002 as well as in the latest RFC 2002bis draft > > > (section 3.6.2.1): > > > > > > "[...] if the Code field indicates that the registration was accepted > > > by the home agent, exactly one Mobile-Home Authentication Extension > > > MUST be present in the Registration Reply, and the mobile node MUST > > > check the Authenticator value in the Extension." > > > > > > This specification, if strictly followed, seems to inhibit any > > > re-registration without involving the home network. Perhaps it would be > > > better to add a statement like "The Mobile-Home Authentication > > > Extension is not needed if a security association is established between > > > the Mobile Node and the foreign network's infrastructure, and the > > > Registration Reply contains a valid Mobile-Foreign Authentication > > > Extension." This is already explicitly demanded by the HAWAII draft and > > > implemented, for example, in HUT Dynamics. > > > > In fact, the draft might be interpreted so that with code 0 it is not > > necessarily the HA that accepted the message. In such a case, the > > section 3.6.2.1 would still be valid even though the Mobile-Foreign > > Authentication extension is used with localized replies. Then, only > > such message that really comes from HA would be the one to which the > > MUSTs fully apply. This interpretation would keep the text as is, would > > properly support at non-regional MN with both MUSTs in place, and > > would allow regional features as implemented in Dynamics - HUT Mobile IP. > > Are you suggesting here that registration reply messages should not > always necessarily come from the HA? Can a mobile simply register with a > FA (without the HA involved) and get a registration reply from the FA? > > In that case how do you explain then the following sentence in RFC 2002 > bis draft (section 3.4): > " If the mobile node is requesting service from a foreign agent, > that foreign agent will receive the Reply from the home agent and > subsequently relay it to the mobile node." Instantaneously yes, on a longer term, no. The non-regional registration would immediately behave like the above sentence while a regional registration caches the functionality of the HA. Once a MN enters a regional network, the first registration would strictly go as quoted above while the subsequent exchanges could use the dynamic trust relationship built from the MN-HA trust relatioinship and delegated down to the access network, e.g. with a session key protocol. Then, a regional-aware FA (or access router) would just cache HA functionality. So, the above would happen, but in a delayed manner. The question is, if the RFC enables the interpretation for this behavior and the implementing messages with the current wording. Since the relay functionality needs not to be instantaneous, and a cache hierarchy would relay the service reply through the access FA, then why not? > > > Please correct me if I have understood something wrong. > > > > Likewise, e.g. our code interpretation is not 100% clear in this.. > > > > > Best regards, > > > Frank > > > -- > > > Frank Paehlke > > > Institut fuer Telematik Phone: +49 721 608-6398 > > > Universitaet Karlsruhe (TH) Fax: +49 721 388097 > > > D-76128 Karlsruhe, Germany EMail: paehlke@ira.uka.de > > > > > > > Regards, > > > > --jari > > > > Jari Malinen (http://www.cs.hut.fi/~jtm) > > Researcher, HUT/CS Lab. Tel. +358 9 451 4774, fax +358 9 451 5351. Regards, --jari Jari Malinen (http://www.cs.hut.fi/~jtm) Researcher, HUT/CS Lab. Tel. +358 9 451 4774, fax +358 9 451 5351. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 14 14:06:29 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21298 for ; Mon, 14 Feb 2000 14:06:29 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.363D5470@standards.nortelnetworks.com>; Mon, 14 Feb 2000 14:03:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 46736 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 14:01:38 -0500 Received: from madcow.borg.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9D1BEF00@standards.nortelnetworks.com>; Mon, 14 Feb 2000 13:51:37 -0500 Received: from mail.borg.com (mail.borg.com [205.217.206.192]) by madcow.borg.com (8.9.0/8.8.8) with ESMTP id NAA07071; Mon, 14 Feb 2000 13:54:11 -0500 (EST) Received: from swc (cti-fw2.borg.com [205.217.206.199]) by mail.borg.com (8.9.3/8.9.3) with SMTP id NAA80579; Mon, 14 Feb 2000 13:54:01 -0500 (EST) (envelope-from stu@critical.com) X-Sender: stu@mail.borg.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.6.32.20000214135731.007a1180@mail.borg.com> Date: Mon, 14 Feb 2000 13:57:31 -0500 Reply-To: Stuart Card Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Stuart Card Subject: [MOBILE-IP] simultaneous mobility bindings: 'tunnels a copy to each' X-cc: dave@critical.com, dan.hague@rl.af.mil To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I studied RFC 2002 a little more carefully and can now elaborate a little more specifically... -- 4.2.3. Home Agent Considerations ... The home agent must examine the IP Destination Address of all arriving datagrams to see if it is equal to the home address of any of its mobile nodes registered away from home. If so, the home agent tunnels the datagram to the mobile node's currently registered care- of address or addresses. If the home agent supports the optional capability of multiple simultaneous mobility bindings, it tunnels a copy to each care-of address in the mobile node's mobility binding list... -- We want to use simultaneous COAs, but we do _not_ want each FA to deliver a copy of each datagram, because that would waste our precious wireless bandwidth (defeating the purpose of our using multiple COAs in the first place): in our case, FAs are routers colocated with radio base stations, and we want to aggregate the bandwidth of multiple wireless links to the MN. The HA sections of the RFC appear to permit (and largely to support) our desired behavior: if the HA tunnels a copy to each FA, but _only one_ FA then delivers it via its wireless medium. Unfortunately, the FA sections seem to require of us that _all_ FAs deliver their copies... -- 4.2.2. Foreign Agent Considerations Upon receipt of an encapsulated datagram sent to its advertised care-of address, a foreign agent MUST compare the inner destination address to those entries in its visitor list. When the destination does not match the address of any mobile node currently in the visitor list, the foreign agent MUST NOT forward the datagram without modifications to the original IP header, because otherwise a routing loop is likely to result. The datagram SHOULD be silently discarded. ICMP Destination Unreachable MUST NOT be sent when a foreign agent is unable to forward an incoming tunneled datagram. Otherwise, the foreign agent forwards the decapsulated datagram to the mobile node... -- The language used is that 'the foreign agent forwards'. There is no 'MUST' here, so maybe we can drop the datagram at all but one FA? This approach is inefficient, in the sense that redundant datagrams traverse the wired networks between the HA and (N-1) of the FAs. It is however efficient in use of the (more precious) wireless bandwidth. Further, each FA, by receiving copies of all datagrams (even those it is not destined to forward), has a complete picture of the traffic flow to/from its registered MNs, potentially enabling it to make smarter forwarding decisions. Finally, this may introduce some opportunities for fault-tolerance: critical traffic might actually be forwarded by more than one of the FAs (all, or a subset) to fight wireless link quality problems with redundancy; or datagrams might be buffered at all FAs, so that NAKed (or unACKed) datagrams might be [re]transmitted by FAs other than the one which originally forwarded (or should have forwarded) them. So, I have several questions: (1) Should I interpret 4.2.2 as requiring that _each_ FA MUST forward _all_ tunneled datagrams, or can I drop a datagram at zero or more FAs, provided I ensure that _at least one_ FA forwards that datagram? (2) Do I seem to be violating any other rules of this (or any other relevant) RFC? (3) Any other comments on this scheme? Thanks! ------------------------------------------------------------------------ Stuart W. Card, Chief Scientist & Vice-Pres., Critical Technologies Inc. Suite 400 Technology Center, 4th Floor 1001 Broad Street, Utica NY 13501 315-793-0248 FAX -9710 http://www.critical.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 14 18:20:05 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26250 for ; Mon, 14 Feb 2000 18:20:04 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9F4BA070@standards.nortelnetworks.com>; Mon, 14 Feb 2000 18:16:33 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 46982 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 14 Feb 2000 18:15:09 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.07E5CDB0@standards.nortelnetworks.com>; Mon, 14 Feb 2000 18:05:09 -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 OAA05246 for ; Mon, 14 Feb 2000 14:18:49 -0800 (PST) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.63.34]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id OAA20333; Mon, 14 Feb 2000 14:18:49 -0800 (PST) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA23417; Mon, 14 Feb 2000 14:18:47 -0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 14 Feb 2000 14:18:47 -0800 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: [MOBILE-IP] More comments on draft-ietf-mobileip-3gwireless-ext-02.txt X-cc: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <38A7C667.E3A2F1C8@ccrle.nec.de> All, As I near implementation of this draft, I still have many concerns that I need to bring up: 1. GRE Key (or session id) generation. The spec requires that the PCF/RAN (or initiator of the reg request) creates the pseudo unique GRE id. Since a PDSN (or termination point of the reg request) will be communicating with many PCFs, the GRE identifier is hardly unique. Since the GRE id is not unique, the PDSN cannot use this value alone to identify a data stream from the PCF. So, we have a couple of options: a) Document that tunnel identification is done by using the GRE id AND the source IP address of the reg request. Of course, this imposes a rather large per packet overhead. b) Change the specification to mimick the VTP approach where the tunnel initiator sets the most significant 16 bits, and the PDSN sets the least significant 16 bits. The 16 bits set MUST be locally unique. This scheme works as long as no more than 65535 sessions are needed per pair (for lookups, the full 32bits are used). 2. The somewhat complicated requirement that both the FA and rpd (that handles the protocol defined in this draft) listen on port 434. Some suggestions have been make that processes only need to listen on certain interfaces, etc. I have thought more about this, and I REALLY don't like this approach. Since the ONLY thing that both Mobile-IP and R-P share in common is the packet format (and the extensions used are different), they are different protocols. Why can we not simply require that R-P be used over a different port? This is a VERY simply problem to the solution, and no longer assumes ANY architectural requirements. Comments? PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 15 04:03:29 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21142 for ; Tue, 15 Feb 2000 04:03:29 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0C6B1900@standards.nortelnetworks.com>; Tue, 15 Feb 2000 3:59:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 47620 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 03:58:18 -0500 Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E3F87BC0@standards.nortelnetworks.com>; Tue, 15 Feb 2000 3:58:17 -0500 Received: from iseran.inrialpes.fr (iseran.inrialpes.fr [194.199.24.100]) by ebene.inrialpes.fr (8.9.3/8.8.5) with ESMTP id JAA02956; Tue, 15 Feb 2000 09:55:45 +0100 (MET) Received: from inrialpes.fr (localhost [127.0.0.1]) by iseran.inrialpes.fr (8.8.7/8.8.5) with ESMTP id KAA04350; Tue, 15 Feb 2000 10:00:36 +0100 (MET) X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <3.0.6.32.20000214135731.007a1180@mail.borg.com> Content-Type: multipart/alternative; boundary="------------0E0E366AB0B26AA3BF90B642" Message-ID: <38A915B3.571ACD0D@inrialpes.fr> Date: Tue, 15 Feb 2000 10:00:36 +0100 Reply-To: Claude.Castelluccia@INRIALPES.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Claude Castelluccia Subject: Re: [MOBILE-IP] simultaneous mobility bindings: 'tunnels a copy toeach' X-To: Stuart Card X-cc: zhao@cs.stanford.edu, mgbaker@cs.stanford.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --------------0E0E366AB0B26AA3BF90B642 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stuart Card wrote: > I studied RFC 2002 a little more carefully and can now elaborate > a little more specifically... > > -- > > 4.2.3. Home Agent Considerations > > ... The home agent must examine the IP Destination Address of all > arriving datagrams to see if it is equal to the home address of any > of its mobile nodes registered away from home. If so, the home agent > tunnels the datagram to the mobile node's currently registered care- > of address or addresses. If the home agent supports the optional > capability of multiple simultaneous mobility bindings, it tunnels a > copy to each care-of address in the mobile node's mobility binding > list... > > -- > > We want to use simultaneous COAs, but we do _not_ want each FA > to deliver a copy of each datagram, because that would waste our > precious wireless bandwidth (defeating the purpose of our using > multiple COAs in the first place): in our case, FAs are routers > colocated with radio base stations, and we want to aggregate the > bandwidth of multiple wireless links to the MN. > > The HA sections of the RFC appear to permit (and largely to support) > our desired behavior: if the HA tunnels a copy to each FA, but > _only one_ FA then delivers it via its wireless medium. Unfortunately, > the FA sections seem to require of us that _all_ FAs deliver their > copies... > > Hello Stuart, Current Mobile IP does not support such functionalities. However we have presented in a Mobicom paper (http://www.inrialpes.fr/planete/people/ccastel/mobicom98.ps.gz) an architecture and some simple Mobile IP extensions that allow to use simultaneously several CoAs for different flows... this should solve your problem... regards, Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------0E0E366AB0B26AA3BF90B642 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Stuart Card wrote:
I studied RFC 2002 a little more carefully and can now elaborate
a little more specifically...

--

4.2.3. Home Agent Considerations

   ... The home agent must examine the IP Destination Address of all
   arriving datagrams to see if it is equal to the home address of any
   of its mobile nodes registered away from home.  If so, the home agent
   tunnels the datagram to the mobile node's currently registered care-
   of address or addresses.  If the home agent supports the optional
   capability of multiple simultaneous mobility bindings, it tunnels a
   copy to each care-of address in the mobile node's mobility binding
   list...

--

We want to use simultaneous COAs, but we do _not_ want each FA
to deliver a copy of each datagram, because that would waste our
precious wireless bandwidth (defeating the purpose of our using
multiple COAs in the first place): in our case, FAs are routers
colocated with radio base stations, and we want to aggregate the
bandwidth of multiple wireless links to the MN.

The HA sections of the RFC appear to permit (and largely to support)
our desired behavior: if the HA tunnels a copy to each FA, but
_only one_ FA then delivers it via its wireless medium.  Unfortunately,
the FA sections seem to require of us that _all_ FAs deliver their
copies...
 
 


Hello Stuart,

Current Mobile IP does not support such functionalities.
However we have presented in a Mobicom paper (http://www.inrialpes.fr/planete/people/ccastel/mobicom98.ps.gz)
an architecture and some simple   Mobile IP  extensions that  allow  to use simultaneously several  CoAs for different
flows... this should solve your problem... 

regards,
Claude.









-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------0E0E366AB0B26AA3BF90B642--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 04:17:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21251
	for ; Tue, 15 Feb 2000 04:17:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.27AC1BE0@standards.nortelnetworks.com>; Tue, 15 Feb 2000 4:14:30 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 47675 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 04:13:05
          -0500
Received: from tokyo.ccrle.nec.de by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F55F3780@standards.nortelnetworks.com>; Tue, 15 Feb 2000 4:13:05
          -0500
Received: from wallace.heidelberg.ccrle.nec.de (Wallace.heidelberg.ccrle.nec.de
          [192.168.102.1]) by tokyo.ccrle.nec.de (8.8.7/3.6W980303HK) with
          ESMTP id KAA04908 for ; Tue,
          15 Feb 2000 10:18:26 +0100 (CET)
Received: from ccrle.nec.de (atoll.heidelberg.ccrle.nec.de [192.168.102.96]) by
          wallace.heidelberg.ccrle.nec.de (8.8.7/3.6W980203HK) with ESMTP id
          KAA20416 for ; Tue, 15 Feb
          2000 10:29:28 +0100 (CET)
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <3.0.6.32.20000214135731.007a1180@mail.borg.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A91944.248ABE33@ccrle.nec.de>
Date:         Tue, 15 Feb 2000 10:15:48 +0100
Reply-To: Karl Jonas 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Karl Jonas 
Organization: NEC CCRLE
Subject:      Re: [MOBILE-IP] simultaneous mobility bindings
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Stuart, Charlie, et al,

it seems that i was unprecise in my previous email, so let me try again:
Simutaneous bindings are possible according to the current MIP draft
BUT as Charlie Perkins noted in one of his emails, this might be dropped
in future drafts of MIP.
He wrote (Jan 26)
  "It is possible for a mobile node to enter simultaneous registrations
  and thus have more than one care-of address.  However, this feature
  has not, to my knowledge, been tested at any interoperability event.
  Thus, unless it is shown to be interoperable, there is the likelihood
  that the feature will be dropped from the standard as we pass from
  Proposed Standard to Draft Standard (possibly later this year)."

The intention of my mail was to keep simultaneous bindings as an option
in MIP, since i expect it to be useful for future implementations, and
-being optional- it does not harm anybody else.

So, it is good to hear that Stuart needs and uses the feature.

karl


--
Karl Jonas, NEC C&C Research Labs
EMail: karl.jonas@ieee.org
Tel.:  +49.(0)6221.905 11 21
Fax:   +49.(0)6221.905 11 55
http://www.ccrle.nec.de/heidelberg/index.html


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 04:39:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21397
	for ; Tue, 15 Feb 2000 04:39:16 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1B4D1E50@standards.nortelnetworks.com>; Tue, 15 Feb 2000 4:35:37 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 47762 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 04:34:27
          -0500
Received: from catarina.usc.edu by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.8BD8FC90@standards.nortelnetworks.com>; Tue, 15 Feb 2000 4:24:27
          -0500
Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu
          (8.9.3/8.9.3) with ESMTP id BAA06479; Tue, 15 Feb 2000 01:27:16 -0800
          (PST)
Received: from localhost (meeta@localhost) by rumi.usc.edu (8.9.3/8.9.3) with
          ESMTP id BAA19217; Tue, 15 Feb 2000 01:27:14 -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  
Date:         Tue, 15 Feb 2000 01:27:14 -0800
Reply-To: Meeta Sharma 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Meeta Sharma 
Subject:      [MOBILE-IP] some doubts about mobile ip
X-To:         charles.perkins@sun.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Dear Sir,

I am a graduate student at University of Southern California, Los Angeles,
working on a project for network protocol verification and testing . As a
case study i am looking at mobile ip for modeling it to be tested under
our methodology.

I have some doubts about certain scenarios:

1. When a mobile node crashes, then it looses it information and again
starts in the state for discovering it's connectivity. But how would it
come to know that the reply it gets from it's some agent with the 'f' bit
set then, how would it know to whom to register with, that is does not
have any information about it's home agent. ( this is supposing that the
node is not in it's home network)

2. When a home agent crashes, then what would happen, how would a new
agent be assigned as the home agent?

Looking forward to your reply,
Thanks,
Regards,
Meeta


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 04:49:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21445
	for ; Tue, 15 Feb 2000 04:49:07 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.83A5F570@standards.nortelnetworks.com>; Tue, 15 Feb 2000 4:45:42 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 47822 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 04:43:52
          -0500
Received: from tsbgw.wide.toshiba.co.jp by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.421A2C70@standards.nortelnetworks.com>; Tue, 15 Feb 2000 4:43:52
          -0500
Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp
          [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP
          id SAA27887; Tue, 15 Feb 2000 18:46:26 +0900 (JST)
Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp
          [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with
          ESMTP id SAA19335; Tue, 15 Feb 2000 18:46:26 +0900 (JST)
Received: from tanuki (tanuki.isl.rdc.toshiba.co.jp [133.196.16.162]) by
          isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with SMTP id SAA05068; Tue,
          15 Feb 2000 18:46:25 +0900 (JST)
References: <3.0.6.32.20000214135731.007a1180@mail.borg.com>
            <38A91944.248ABE33@ccrle.nec.de>
X-Mailer: Datula version 1.21.09 for Windows
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <200002150946.SAA05068@isl.rdc.toshiba.co.jp>
Date:         Tue, 15 Feb 2000 18:56:52 +0900
Reply-To: Yoshiyuki Tsuda 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Yoshiyuki Tsuda 
Organization: Corporate R&D Center, Toshiba Corporation
Subject:      Re: [MOBILE-IP] simultaneous mobility bindings
X-To:         Karl Jonas 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38A91944.248ABE33@ccrle.nec.de>

Hello, Karl,

 I have a plan to check the interoperability about simultaneous binding
 at the coming Sun's Connectathon.  I hope this will help you a bit.
 But, I cannot clearly image there are any applications that really want
 this capability.  So, if you or someone else point out more potential
 applications that need this capability, it will be appreciated more.

Cheers.
-Yoshi


On Tue, 15 Feb 2000 10:15:48 +0100,  Karl Jonas wrote:
>> Stuart, Charlie, et al,
>>
>> it seems that i was unprecise in my previous email, so let me try again:
>> Simutaneous bindings are possible according to the current MIP draft
>> BUT as Charlie Perkins noted in one of his emails, this might be dropped
>> in future drafts of MIP.
>> He wrote (Jan 26)
>>   "It is possible for a mobile node to enter simultaneous registrations
>>   and thus have more than one care-of address.  However, this feature
>>   has not, to my knowledge, been tested at any interoperability event.
>>   Thus, unless it is shown to be interoperable, there is the likelihood
>>   that the feature will be dropped from the standard as we pass from
>>   Proposed Standard to Draft Standard (possibly later this year)."
>>
>> The intention of my mail was to keep simultaneous bindings as an option
>> in MIP, since i expect it to be useful for future implementations, and
>> -being optional- it does not harm anybody else.
>>
>> So, it is good to hear that Stuart needs and uses the feature.
>>
>> karl
>>
>>
>> --
>> Karl Jonas, NEC C&C Research Labs
>> EMail: karl.jonas@ieee.org
>> Tel.:  +49.(0)6221.905 11 21
>> Fax:   +49.(0)6221.905 11 55
>> http://www.ccrle.nec.de/heidelberg/index.html
>>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 06:01:28 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21838
	for ; Tue, 15 Feb 2000 06:01:28 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.967D5E90@standards.nortelnetworks.com>; Tue, 15 Feb 2000 5:57:48 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 47898 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 05:55:49
          -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.4F0EC760@standards.nortelnetworks.com>; Tue, 15 Feb 2000
          5:55:49 -0500
Received: from SMTP (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          LAA22502; Tue, 15 Feb 2000 11:58:31 +0100 (MET)
Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by 153.88.251.29
          (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 15 Feb 2000
          10:58:30 0000 (GMT)
Received: by esealnt400 with Internet Mail Service (5.5.2448.0) id <18LQ8Q8W>;
          Tue, 15 Feb 2000 11:58:29 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <5F05C89FB2F8D211B6430008C791912703EA7E7F@esealnt190>
Date:         Tue, 15 Feb 2000 11:58:20 +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] simultaneous mobility bindings: 'tunnels a copy t
              o each'
X-To:         Stuart Card 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi

>  The HA sections of the RFC appear to permit (and largely to support)
>  our desired behavior: if the HA tunnels a copy to each FA, but
>  _only one_ FA then delivers it via its wireless medium.
>  Unfortunately,
>  the FA sections seem to require of us that _all_ FAs deliver their
>  copies...

I think that it depends on your wireless access technology as to
whether the MN will receive multiple copies of packets over the air
interface. The MN can solve the problem by making sure it is only
attached to one L2 access point at a time (or is constrained to doing
so) for reception/transmission. Switching between L2 technologies or
access points can then be done according to L2 measurements.
I assume that you have one FA per access point as you stated.
Superfluous packets are then discarded since they cannot be delivered.
Some bandwidth is wasted on the wired part due to the multiple flows,
but that is cheap compared to the air interface.

On the other hand, distributing load on several simultaneous COAs
cannot be done. This is quite a complex issue since the intelligence
to distribute the load according to L2 characteristics has to be
in the HA/GFA (simultaneous binding agent) which typically has little
knowledge of this.

Regards,
Karim


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 06:50:38 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22722
	for ; Tue, 15 Feb 2000 06:50:32 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7267D5B0@standards.nortelnetworks.com>; Tue, 15 Feb 2000 6:46:54 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 47974 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 06:45:25
          -0500
Received: from dumburken.it.kth.se by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.3CF4F930@standards.nortelnetworks.com>; Tue, 15 Feb 2000 6:45:25
          -0500
Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id
          MAA03692; Tue, 15 Feb 2000 12:48:03 +0100 (MET)
X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to
                         maguire@dumburken.it.kth.se using -f
References:  <5F05C89FB2F8D211B6430008C791912703EA7E7F@esealnt190>
Message-ID:  <200002151148.MAA03692@dumburken.it.kth.se>
Date:         Tue, 15 Feb 2000 12:48:03 +0100
Reply-To: Gerald Maguire 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Gerald Maguire 
Subject:      Re: [MOBILE-IP] simultaneous mobility bindings: 'tunnels a copy t
              o each'
X-To:         Karim.El-Malki@ERA.ERICSSON.SE
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <5F05C89FB2F8D211B6430008C791912703EA7E7F@esealnt190>
              (Karim.El-Malki@ERA.ERICSSON.SE)

But there are air interfaces that can listen on multiple channels at
one time (for example many CDMA receivers only need another correlator
to listen on a second spreading code). Thus the cost for listening to
multiple access points need not be high.

Chip


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 09:28:52 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03802
	for ; Tue, 15 Feb 2000 09:28:52 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8D17F320@standards.nortelnetworks.com>; Tue, 15 Feb 2000 9:25:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 48157 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 09:24:25
          -0500
Received: from tokyo.ccrle.nec.de by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.73508600@standards.nortelnetworks.com>; Tue, 15 Feb 2000 9:24:25
          -0500
Received: from wallace.heidelberg.ccrle.nec.de (Wallace.heidelberg.ccrle.nec.de
          [192.168.102.1]) by tokyo.ccrle.nec.de (8.8.7/3.6W980303HK) with
          ESMTP id PAA06764 for ; Tue,
          15 Feb 2000 15:29:46 +0100 (CET)
Received: from ccrle.nec.de (atoll.heidelberg.ccrle.nec.de [192.168.102.96]) by
          wallace.heidelberg.ccrle.nec.de (8.8.7/3.6W980203HK) with ESMTP id
          PAA23990 for ; Tue, 15 Feb
          2000 15:40:48 +0100 (CET)
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <5F05C89FB2F8D211B6430008C791912703EA7E7F@esealnt190>
            <200002151148.MAA03692@dumburken.it.kth.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38A9623C.C817B104@ccrle.nec.de>
Date:         Tue, 15 Feb 2000 15:27:09 +0100
Reply-To: Karl Jonas 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Karl Jonas 
Organization: NEC CCRLE
Subject:      [MOBILE-IP] Questions related to FA assisted hand-off
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Reading draft-calhoun-mobileip-proactive-fa-00.txt, a couple of
questions
came up:

* why do you choose the FA to assist the hand-off?
Couldn't this be any node in the network?
Wouldn't it be nicer to separate functionalities?
(Leaving it optional to implement both in one piece of software)

* why does the oFA need to communicate with the nFA?
Could the oFA send a direct message to the MN, asking it
to register with the nFA?
Wouldn't this make more sense, since the MN might not be
able to listen to multiple FAs?

* registering with a new FA could mean to access the network
via a new physical link. This might be useful even in the
absence of FAs. Would you suggest to have a separate hand-off
mechanism for physical connections?

karl


--
Karl Jonas, NEC C&C Research Labs
EMail: karl.jonas@ieee.org
Tel.:  +49.(0)6221.905 11 21
Fax:   +49.(0)6221.905 11 55
http://www.ccrle.nec.de/heidelberg/index.html


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 10:42:06 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10002
	for ; Tue, 15 Feb 2000 10:42:06 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C63D92E0@standards.nortelnetworks.com>; Tue, 15 Feb 2000 10:38:19 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 48269 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 10:36:43
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.276921D0@standards.nortelnetworks.com>; Tue, 15 Feb 2000 10:26:43
          -0500
Received: from e33.esmtp.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by
          hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id JAA12438 for
          ; Tue, 15 Feb 2000 09:29:20 -0600 (CST)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com
          [9.99.132.205]) by e33.esmtp.ibm.com (8.9.3/8.9.3) with ESMTP id
          JAA24608; Tue, 15 Feb 2000 09:21:36 -0600
Received: from d53mta05h.boulder.ibm.com (d53mta05h.boulder.ibm.com
          [9.99.142.5]) by westrelay02.boulder.ibm.com (8.8.8m2/NCO v2.06) with
          SMTP id IAA170672; Tue, 15 Feb 2000 08:25:42 -0700
Received: by d53mta05h.boulder.ibm.com(Lotus SMTP MTA v4.6.5  (863.2
          5-20-1999))  id 87256886.0054B087 ; Tue, 15 Feb 2000 08:25:02 -0700
X-Lotus-FromDomain: IBMCA@IBMUS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
X-created: Reply-To created by westrelay02.boulder.ibm.com
Message-ID:  <87256886.005497CF.00@d53mta05h.boulder.ibm.com>
Date:         Tue, 15 Feb 2000 10:22:05 -0500
Reply-To: radaideh@ca.ibm.com
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: radaideh@ca.ibm.com
Subject:      [MOBILE-IP] SPECTS'2k -- Deadline is approaching
X-To:         SPECTS'2KMailingLists@ca.ibm.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Please be advised that we are 2 weeks from the deadline to submit papers to
SPECTS'2k (Feb 29, 2000).

If you've not received this note directly from me and would be interested
in subscribing to the SPECTS'2K mailing list, please send me a note at
radaideh@ca.ibm.com with "SUBSCRIBE" in the note subject field. To
un-subscribe, please send me a note with "UN-SUBSCRIBE" in the subject
field.
Hope to see you all in Vancouver this coming summer.

Best Regards
M.Radaideh
Publicity Chair, SPECTS'2K

=======================================================================
Call For Papers
SPECTS 2000

2000 SCS Symposium on Performance Evaluation of
Computer and
Telecommunication Systems

July 16-20, 2000
Vancouver, BC, Canada

General Chair
Mohammad S. Obaidat
Dept. of Computer Science, Monmouth University
W. Long Branch, NJ 07764, USA
Tel 732-571-4482
Fax 732-263-5202
E-mail obaidat@monmouth.edu

Vice General Chair
Marco Ajmone Marsan
Dept. of Electronics, Politecnico di Torino
Corso Duca degli Abruzzi, 24, 10129 Torino, Italy
Tel +39-011-564-4032
Fax +39-011-564-4099
E-mail ajmone@polito.it

Program Chair
Franco Davoli
DIST-University of Genoa
via Opera Pia 13, I-16145 Genoa, Italy
Tel +39-010-353-2732
Fax +39-010-353-2154E-Mail franco@dist.unige.it

Vice Program Chairs
Ibrahim Onyuksel
Dept. of Computer Sciences, N. Illinois Univ., USA
E-mail onyuksel@cs.niu.edu

Omar Hammami
University of Aizu, Japan
E-mail hammami@u-aizu.ac.jp

Industrial Track Chair
J. Fox, BT Laboratories, UK
E-mail john.r.fox@bt.com

Technical Program Committee
A. Abonameh, University of Akron, USA
J.  Agrawal, University of Missouri-K.C., USA
I. Akyildiz, Georgia Tech, USA
K. Al-Tawil, KFUPM, Saudi Arabia
R. Ammar, University of Connecticut, USA
H. van As, Vienna University of Technology, Austria
L. G. Birta, University of Ottawa, Canada
N. Boudriga, University of Tunis, Tunisia
A. Campbell, Columbia University, USA
A. K. Elmagarmed, Purdue University, USA
L. Fratta, Politecnico di Milano, Italy
G. Gabor, Ericsson Radio Systems, Sweden
A. Ganz, University of Massachusetts, USA
M. Gerla, UCLA, USA
M. Guizani, Univ. of Missouri-Columbia / K.C., USA
W. Hahn, University of Passau, Germany
J. Harju, Tampere Univ. of Technology, Finland
H. Hughes, Michigan State University, USA
A. Jajszczyk, Cracow Univ.-Mining/Metallurgy, Poland
G. Karlsson, KTH, Sweden
H. Khalid, Motorola Inc., USA
U. Killat, TU Hamburg-Harburg, Germany
B. Kraimeche, Washington State University, USA
K. Kwiat, Air Force Research Laboratory, USA
T. Gon Kim, KAIST, Korea
P. J. Kuehn, University of Stuttgart, Germany
A. Lehmann, Univ. der Bundeswehr Muenchen, Germany
L. Lenzini, University of Pisa, Italy
M. T. Liu, Ohio State University, USA
I. Mahgoub, Florida Atlantic University, USA
K. Makki, University of Southwestern Louisiana, USA
S. Makki, RMIT, Australia
X. Meng, University of Texas - Pan American, USA
H. Mouftah, Queen's University, Canada
F. Neri, Politecnico di Torino, Italy
G. Pacifici, IBM, USA
S. Palazzo, University of Catania, Italy
G. Papadimitriou, Aristotle University, Greece
A. Pattavina, Politecnico di Milano, Italy
K. Pawlikowski, University of Canterbury, New Zealand
G. Polyzos, UCSD, USA
R. Puigjaner, Universitat de les Illes Balears, Spain
V. Lagrange M. Reis, Compaq Computers Corp., USA
G. Paolo Rossi, Universita` di Milano, Italy
I. Rubin, UCLA, USA
D. Schilling, CUNY, USA
C. Tim Spracklen, Aberdeen University, UK
T. Suda, UCI, USA
P. Tran-Gia, University of Wuerzburg, Germany
I. Toda, Fujutsu Laboratories Ltd., Japan
K. S. Vastola, Rensselaer Polytechnic Institute, USA
M. Veeraraghavan, Brooklyn Polytechnic University, USA
M. Villen Altamirano, Telefonica, Spain


International Liaisons:
B. Sadoun, Applied Science Univ., Jordan
Bsadoun@go.com.jo
M. Sawan, Montereal Poly, Canada
Sawan@vlsi.polymtl.ca
N. Tchamov, Tampere Univ. of Technology, Finland
Nikoly@cs.tut.fi
Hiedeki Tode, Osaka Univ., Japan
Tode@ise.eng.osaka-u.ac.jp

Publicity Committee
M. Radaideh (Publicity Chair), IBM, Canada, radaideh@ca.ibm.com
H. Choi, ETRI, Korea, hchoi@pec.etri.re.kr
J. Fox, British Telecom, United Kingdom,
john.r.fox@bt.com
W. Hahn, University of Passau, Germany,
hahn@fmi.uni-passau.de
H. Karatza, Aristotle University of Thessaloniki,
Greece,
karatza@olymp.ccf.auth.gr
A. Nusseirat, Al-Isra University, Jordan,
anuseirat@firstnet.com.jo
R. Bolla, University of Genoa, Italy,
Ielus@dist.unige.it

This annual international conference is a forum for
professionals
involved in performance evaluation of computer and
telecommunication
systems. Evaluation of computer systems and networks
is needed at every
stage in the life cycle of the product including
design, manufacturing,
sales/purchase, use, upgrade, tuning, etc. The
discipline of performance
evaluation has progressed rapidly in the past decade,
and it has now
begun to approach maturity. Significant progress has
been made in
analytic modeling, simulation, and measurement
approaches for
performance evaluation of computer and
telecommunication systems.

Topics of interest include, but are not limited to
- ATM Simulation
- Wireless Systems
- High-Speed Networking
- Parallel and Distributed Simulation
- Teletraffic
- Mobile Networks/Computing
- Client/Server
- Parallel and Distributed Computing
- High-Performance Computing
- Adaptive Communications
- Electronic Commerce
- UMTS/IMT-2000 Systems
- Multimedia Communications
- Verification and Validation
- Performance Tools and Methodologies
- Neural Networks and Fuzzy Logic Applications to High
Performance
Computing/Networking
- Microprocessors/Microcomputers
- Quality of Service, QOS
- Memory Systems
- Software Evaluation and Testing
- Hardware and Software Monitors
- Interconnection Networks
- Optical Networks
- Multimedia Systems
- Network Protocols
- Network Management
- Performance Optimization
- Security and Authentication
- Workload and Traffic Characterization
- Scientific Computing Algorithms
- High Performance I/O
- Scalability Studies
- Reconfigurable Computing
- Web-based Applications

Interested authors should submit 5 copies of a full
paper describing
their work (maximum of 20 double-spaced pages
including all
illustrations). Authors should obtain company and
government clearances
prior to submission of papers. Please submit five
copies of your
complete paper to the SPECTS 2000 Program Committee
Chair. For more
information regarding presentation or exhibition at
SPECTS 2000 contact
Steve Branch
The Society for Computer Simulation International
4838 Ronson Court, Ste. L
San Diego, CA  92111, USA
Tel 858-277-3888,
Fax 858-277-3930
E-mail sbranch@scs.org

Submissions must include a cover sheet providing the
name, mailing
address, phone number, fax number, and E-mail of the
primary contact
author for the paper. Papers accepted will be
allocated a maximum of
seven two-column pages in the proceedings. Extended
versions of accepted
papers in SPECTS 2000 will be considered for possible
publication in
scholarly journals. We also solicit proposals for
tutorials and panel
sessions. Please send proposals to the Symposium
General Chair.

Deadlines
Submission of Papers - February 29, 2000
Notification of Acceptance - April 24, 2000
Final Camera-Ready Submission - May 22, 2000

Sponsored by The Society for Computer Simulation
International
P.O. Box 17900
San Diego, CA  92177-7900
Tel 858-277-3888
Fax 858-277-3930
E-mail scs@scs.org
http://www.scs.org/confernc/scsc00/spects/spects2k.html

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 11:28:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12352
	for ; Tue, 15 Feb 2000 11:28:20 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3BDBFD60@standards.nortelnetworks.com>; Tue, 15 Feb 2000 11:24:33 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 48395 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 11:23:58
          -0500
Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.2640ADC0@standards.nortelnetworks.com>; Tue, 15 Feb 2000 11:23:57
          -0500
Received: from iseran.inrialpes.fr (iseran.inrialpes.fr [194.199.24.100]) by
          ebene.inrialpes.fr (8.9.3/8.8.5) with ESMTP id RAA11794 for
          ; Tue, 15 Feb 2000 17:21:41
          +0100 (MET)
Received: from inrialpes.fr (localhost [127.0.0.1]) by iseran.inrialpes.fr
          (8.8.7/8.8.5) with ESMTP id RAA05897 for
          ; Tue, 15 Feb 2000 17:26:32
          +0100 (MET)
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="------------CCDD56AC585EEB6C6C859841"
Message-ID:  <38A97E38.81A5774A@inrialpes.fr>
Date:         Tue, 15 Feb 2000 17:26:32 +0100
Reply-To: Claude.Castelluccia@INRIALPES.FR
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Claude Castelluccia 
Subject:      [MOBILE-IP] -IPCN2000 CFP-
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

--------------CCDD56AC585EEB6C6C859841
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Dear all,

IPCN2000 (http://www.upperside.fr/baipcn.htm) submission deadline has
been extended until friday, 18th of February
as requested by many people.
IPCN2000 will be held  in May which is a great time to visit Paris ;-)

So you still have 4 days to submit a one-page abstract....

regards,

Claude.




--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/



--------------CCDD56AC585EEB6C6C859841
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



 

Dear all,

IPCN2000 (http://www.upperside.fr/baipcn.htm) submission deadline has
been extended until friday, 18th of February

as requested by many people.

IPCN2000 will be held  in May which is a great time to visit Paris
;-)

So you still have 4 days to submit a one-page abstract....

regards,

Claude.

 

 

 

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------CCDD56AC585EEB6C6C859841--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 11:57:25 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13569
	for ; Tue, 15 Feb 2000 11:57:24 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4BD22740@standards.nortelnetworks.com>; Tue, 15 Feb 2000 11:53:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 48451 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 11:51:50
          -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A5539580@standards.nortelnetworks.com>; Tue, 15 Feb 2000 11:41:49
          -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 IAA25039; Tue, 15 Feb 2000 08:44:32
          -0800 (PST)
Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM
          [129.146.91.34]) by engmail3.Eng.Sun.COM
          (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id IAA15692; Tue, 15 Feb
          2000 08:44:31 -0800 (PST)
Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id
          IAA02987; Tue, 15 Feb 2000 08:44:29 -0800
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  
Date:         Tue, 15 Feb 2000 08:44:29 -0800
Reply-To: "pcalhoun@eng.sun.com" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: "pcalhoun@eng.sun.com" 
Subject:      Re: [MOBILE-IP] Questions related to FA assisted hand-off
X-To:         Karl Jonas 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID" <38A9623C.C817B104@ccrle.nec.de>

Karl, see my responses below.

PatC

> Reading draft-calhoun-mobileip-proactive-fa-00.txt, a couple of
> questions
> came up:
>
> * why do you choose the FA to assist the hand-off?
In today's cellular network, the BSC/BTS is responsbile for such hand-offs (at
least in the CDMA network, I'm not sure about GSM). As some of us in 3GPP2
(and WMIF) are trying to come up with an All-IP cellular network
infrastructure, we are looking at how we can expand existing IETF protocols to
suit our requirements.

The BSC/BTS currently measures the signal strength in order to determine the
mobile's movements. This is done by the link layer, and it seemed to make
sense to write an interface of some form between this link layer and the
Mobile IP FA stack. The idea here is to take as much as we can from the
cellular networks and put as much as we can in IP, and make the cellular
networks look like nothing more than a link layer (albeit a rather complex
link layer).

> Couldn't this be any node in the network?
Such as? I suppose that we could introduce a new IP device in the network, but
I fail to see the reason for doing so (except to sell more boxes :). I suppose
the BTS itself, which is a rather dumb device, could send these messages.

> Wouldn't it be nicer to separate functionalities?
> (Leaving it optional to implement both in one piece of software)

Well, I'm not so sure. I think that I would like to have the FA be responsible
for this function. Further, as move along this thread, we may decide that
simultaneous bindings at the FA (in a hierarchical network) would provide
another cellular requirement, which is that a mobile must receive multiple
identical data streams from multiple BTS. The FA could be responsible for
this, but it would need to know where the mobile is, and where it is going.

>
> * why does the oFA need to communicate with the nFA?
Because we know that oFA and nFA can communicate.

> Could the oFA send a direct message to the MN, asking it
> to register with the nFA?
It isn't clear that oFA can still communicate with the Mobile Node. All it
knows is that the signal is sufficiently degraded, and if the mobile is moving
at fast enough speeds, it is possible for the oFA NOT be to able to send the
said message to the MN.

> Wouldn't this make more sense, since the MN might not be
> able to listen to multiple FAs?
Well, in today's cellular networks, the Mobile Node receives up to 6 data
streams from different BTS' (again, in a CDMA network). It also isn't clear
that the Mobile can still receive packets from oFA (due to signal strength).

Another alternative is to have both oFA and nFA send the indication to the
mobile.

>
> * registering with a new FA could mean to access the network
> via a new physical link. This might be useful even in the
> absence of FAs. Would you suggest to have a separate hand-off
> mechanism for physical connections?
I *have* been thinking about something along these lines. In today's CDMA
network (again, I need some help as far as GSM is concerned), the MN can
receive up the data stream from up to 6 BTS. If a new simultaneous
binding-like function was added to Mobile IP, it would allow the FA to send
multiple instances of packets to the relevant BTS, and provide BSC-like
functionality.

Note, that the last paragraph is still an very rough idea that I have, and
requires lots of engineering.

PatC

>
> karl
>
>
> --
> Karl Jonas, NEC C&C Research Labs
> EMail: karl.jonas@ieee.org
> Tel.:  +49.(0)6221.905 11 21
> Fax:   +49.(0)6221.905 11 55
> http://www.ccrle.nec.de/heidelberg/index.html


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 12:22:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14952
	for ; Tue, 15 Feb 2000 12:22:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CEAB2240@standards.nortelnetworks.com>; Tue, 15 Feb 2000 12:18:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 48553 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 12:17:18
          -0500
Received: from crufty.research.bell-labs.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.99D0DC40@standards.nortelnetworks.com>; Tue, 15 Feb 2000 12:17:17
          -0500
Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Tue Feb
          15 12:19:50 EST 2000
Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Tue Feb
          15 12:19:49 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 8805957042; Tue, 15 Feb 2000 11:19:48 -0600 (CST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <38A7C667.E3A2F1C8@ccrle.nec.de>
            
X-Mailer: VM 6.33 under Emacs 19.34.2
Message-ID:  <20000215171948.8805957042@king.research.bell-labs.com>
Date:         Tue, 15 Feb 2000 11:19:48 -0600
Reply-To: Pete McCann 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Pete McCann 
Subject:      [MOBILE-IP] More comments on
              draft-ietf-mobileip-3gwireless-ext-02.txt
X-To:         "pcalhoun@eng.sun.com" 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  
Content-Transfer-Encoding: 7bit

Hi, Pat,

"pcalhoun@eng.sun.com"  (psc) writes:

psc> 1. GRE Key (or session id) generation. The spec requires that the
psc> PCF/RAN (or initiator of the reg request) creates the pseudo
psc> unique GRE id. Since a PDSN (or termination point of the reg
psc> request) will be communicating with many PCFs, the GRE identifier
psc> is hardly unique. Since the GRE id is not unique, the PDSN cannot
psc> use this value alone to identify a data stream from the PCF. So,
psc> we have a couple of options:

psc>         a) Document that tunnel identification is done by using
psc> the GRE id AND the source IP address of the reg request. Of
psc> course, this imposes a rather large per packet overhead.

psc>         b) Change the specification to mimick the VTP approach
psc> where the tunnel initiator sets the most significant 16 bits, and
psc> the PDSN sets the least significant 16 bits. The 16 bits set MUST
psc> be locally unique.  This scheme works as long as no more than
psc> 65535 sessions are needed per pair (for lookups, the full 32bits
psc> are used).

If you think about it carefully, I think you'll see that this actually
limits us to 65535 sessions *total*, *per PDSN*.  There is no
coordination between the PCFs defined to pick unique 16 bit numbers,
so we only have the PDSN's 16 bits of uniqueness to work with.  This
was considered too limiting a number by 3GPP2.  So yes, I think we
need to demultiplex based on the source PCF address as well.  I would
support adding such language to the draft.

psc> 2. The somewhat complicated requirement that both the FA and rpd
psc> (that handles the protocol defined in this draft) listen on port
psc> 434. Some suggestions have been make that processes only need to
psc> listen on certain interfaces, etc. I have thought more about
psc> this, and I REALLY don't like this approach. Since the ONLY thing
psc> that both Mobile-IP and R-P share in common is the packet format
psc> (and the extensions used are different), they are different
psc> protocols. Why can we not simply require that R-P be used over a
psc> different port? This is a VERY simply problem to the solution,
psc> and no longer assumes ANY architectural requirements.

I agree that R-P and Mobile IP are really separate protocols.  I
actually don't have a very strong objection to picking a new port for
R-P aside from the fact that it will introduce some additional delay
in standardization due to getting a new port from IANA, etc.  I still
don't believe it's technically necessary since a PDSN should be
maintaining the kind of "virtual interface" structures you allude to
(how else will we deal with dynamic address assignment?) and the MIP
and RP daemons should be configurable to run on only a single
interface or set of interfaces.

Anyway, let's go ahead and make the change - it shouldn't cause much
more delay over and above the other changes that will probably be
introduced at Adelaide.

-Pete


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 12:26:27 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15119
	for ; Tue, 15 Feb 2000 12:26:27 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1676CD90@standards.nortelnetworks.com>; Tue, 15 Feb 2000 12:20:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 48541 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 12:18:59
          -0500
Received: from maxcow.borg.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.70742290@standards.nortelnetworks.com>; Tue, 15 Feb 2000 12:08:58
          -0500
Received: from mail.borg.com (mail.borg.com [205.217.206.192]) by
          maxcow.borg.com (8.9.0/8.8.8) with ESMTP id MAA07302; Tue, 15 Feb
          2000 12:11:37 -0500 (EST)
Received: from swc (cti-fw2.borg.com [205.217.206.199]) by mail.borg.com
          (8.9.3/8.9.3) with SMTP id MAA24614; Tue, 15 Feb 2000 12:11:30 -0500
          (EST) (envelope-from stu@critical.com)
X-Sender: stu@mail.borg.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
References: <38A91944.248ABE33@ccrle.nec.de>
            <3.0.6.32.20000214135731.007a1180@mail.borg.com>
            <38A91944.248ABE33@ccrle.nec.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <3.0.6.32.20000215120552.0079cc80@mail.borg.com>
Date:         Tue, 15 Feb 2000 12:05:52 -0500
Reply-To: Stuart Card 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Stuart Card 
Subject:      Re: [MOBILE-IP] simultaneous mobility bindings
X-To:         Yoshiyuki Tsuda 
X-cc:         dan.hague@rl.af.mil, dave@critical.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200002150946.SAA05068@isl.rdc.toshiba.co.jp>

At 06:56 PM 2000-02-15 +0900, Yoshiyuki Tsuda wrote:

> I have a plan to check the interoperability about simultaneous binding
> at the coming Sun's Connectathon.  I hope this will help you a bit.
> But, I cannot clearly image there are any applications that really want
> this capability.  So, if you or someone else point out more potential
> applications that need this capability, it will be appreciated more.

I'm confused: I thought I _did_ identify 2 cases where it is needed...

(1) When a wireless mobile is moving through regions of marginal
wireless connectivity, it will acquire and lose link repeatedly,
potentially at a very rapid rate; it would be infeasible to change
Mobile-IP registrations at this rate.  This is _not_ just a
'micromobility' problem that can be solved below the IP layer:
the different base stations with which the mobile can communicate
may have network gateways in different parts of the IP address space,
may be operated by different providers, and indeed may involve
entirely different link layer technologies (see my previous example
involving VHF, HF and UHF radio links).  This is also _not_ just
a military problem: a commercial mobile might have both Iridium
and cellular capabilities; it may want to maintain continuous
reachability as it wanders in and out of cellular link, but
not pay the high price to use Iridium continuously; it would
be wasteful to have to re-register with Iridium every time
it momentarily lost cellular link, and vice versa.

(2) A less common situation is that where a wireless mobile
is capable of using, _truly concurrently_, multiple wireless
links, and wants to aggregate their bandwidths.  The Air Force
has this need: there are typically multiple narrowband radios
on an aircraft; no one link provides anywhere near adequate
bandwidth; but the aggregate of all its wireless links may
offer something on the order of a low speed wireline link.

With regard to this not having been tested for interoperability,
I cannot _yet_ help there; we have not yet fully implemented our
test & demonstration system... but we are working on it!

------------------------------------------------------------------------
Stuart W. Card, Chief Scientist & Vice-Pres., Critical Technologies Inc.
Suite 400 Technology Center, 4th Floor 1001 Broad Street, Utica NY 13501
315-793-0248   FAX -9710       http://www.critical.com


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 12:38:04 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15121
	for ; Tue, 15 Feb 2000 12:26:27 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.17C48340@standards.nortelnetworks.com>; Tue, 15 Feb 2000 12:20:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 48542 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 12:20:44
          -0500
Received: from maxcow.borg.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.AF6BAC20@standards.nortelnetworks.com>; Tue, 15 Feb 2000 12:10:44
          -0500
Received: from mail.borg.com (mail.borg.com [205.217.206.192]) by
          maxcow.borg.com (8.9.0/8.8.8) with ESMTP id MAA07372; Tue, 15 Feb
          2000 12:13:26 -0500 (EST)
Received: from swc (cti-fw2.borg.com [205.217.206.199]) by mail.borg.com
          (8.9.3/8.9.3) with SMTP id MAA24932; Tue, 15 Feb 2000 12:13:19 -0500
          (EST) (envelope-from stu@critical.com)
X-Sender: stu@mail.borg.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <3.0.6.32.20000215121637.0079acf0@mail.borg.com>
Date:         Tue, 15 Feb 2000 12:16:37 -0500
Reply-To: Stuart Card 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Stuart Card 
Subject:      Re: [MOBILE-IP] simultaneous mobility bindings: 'tunnels a copy
              to each'
X-To:         "Karim El-Malki (ERA)" 
X-cc:         Gerald Maguire ,
              dan.hague@rl.af.mil, dave@critical.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <5F05C89FB2F8D211B6430008C791912703EA7E7F@esealnt190>

At 11:58 AM 2000-02-15 +0100, Karim El-Malki (ERA) wrote:

>I think that it depends on your wireless access technology as to
>whether the MN will receive multiple copies of packets over the air
>interface. The MN can solve the problem by making sure it is only
>attached to one L2 access point at a time (or is constrained to doing
>so) for reception/transmission. Switching between L2 technologies or
>access points can then be done according to L2 measurements.

I wasn't sufficiently clear...

We _want_ to use more than one link _truly concurrently_.
For instance, maybe I have 2 links of equal bandwidth:
I want half my packets to traverse one, and the other half
the other.  This is because my links are _SLOW_! Some of
them are only 2400 bps.  One might argue that this is a
very special case: most folks have faster links.  True,
most folks have faster links... but they also want to
move _more data_, so on a relative basis, the situation
remains the same: load balancing is common is backbone
networks, which have incredibly high speed links.

>On the other hand, distributing load on several simultaneous COAs
>cannot be done. This is quite a complex issue since the intelligence
>to distribute the load according to L2 characteristics has to be
>in the HA/GFA (simultaneous binding agent) which typically has little
>knowledge of this.

It 'cannot be done' using only standard Mobile-IP HA functionality;
however, once we have Mobile-IP in place, with multiple simultaneous
bindings, our routing and forwarding processes can take advantage of
those concurrent paths, and provide the additional intelligence not
present in the HA itself.  I agree it is 'quite a complex issue':
we are talking about QoS routing, which is so hard most folks have
given up on it; and then compounding the problem by not merely
selecting the one 'best' route, but rather forwarding packets
over multiple concurrent paths.

------------------------------------------------------------------------
Stuart W. Card, Chief Scientist & Vice-Pres., Critical Technologies Inc.
Suite 400 Technology Center, 4th Floor 1001 Broad Street, Utica NY 13501
315-793-0248   FAX -9710       http://www.critical.com


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 12:45:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15894
	for ; Tue, 15 Feb 2000 12:45:36 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0E3324A0@standards.nortelnetworks.com>; Tue, 15 Feb 2000 12:42:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 48728 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 12:40:35
          -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.DA7942C0@standards.nortelnetworks.com>; Tue, 15 Feb 2000
          12:40:34 -0500
Received: from SMTP (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          SAA10102; Tue, 15 Feb 2000 18:43:18 +0100 (MET)
Received: from esealnt172.ericsson.se ([130.100.184.165]) by 153.88.251.32
          (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 15 Feb 2000
          17:43:18 0000 (GMT)
Received: by esealnt172 with Internet Mail Service (5.5.2448.0) id <18LJ8D68>;
          Tue, 15 Feb 2000 18:43:16 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <5F05C89FB2F8D211B6430008C791912703EA7E87@esealnt190>
Date:         Tue, 15 Feb 2000 18:43: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] simultaneous mobility bindings: 'tunnels a copy t
              o each'
X-To:         Stuart Card 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

I agree it is 'quite a complex issue':
>  we are talking about QoS routing, which is so hard most folks have
>  given up on it; and then compounding the problem by not merely
>  selecting the one 'best' route, but rather forwarding packets
>  over multiple concurrent paths.

Well, simultaneous bindings are definitely not a means of "compounding
the problem" as you put it, but quite the opposite. In many cases,
having multiple concurrent paths is a good thing.
If a MN is making a handoff between FAs, having copies of the
same packets reaching both FAs for a short period will help
in improving the quality of handoffs. Therefore your specific
requirements are not the only ones we should be considering.

Regards,
Karim


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 12:58:46 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16359
	for ; Tue, 15 Feb 2000 12:58:46 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E26E6440@standards.nortelnetworks.com>; Tue, 15 Feb 2000 12:55:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 48792 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 12:54:15
          -0500
Received: from emrys.qualcomm.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.C33DC5C0@standards.nortelnetworks.com>; Tue, 15 Feb 2000 12:54:14
          -0500
Received: from jwillkie1 (jwillkie1.qualcomm.com [129.46.219.171]) by
          emrys.qualcomm.com (8.8.5/1.4/8.7.2/1.15) with SMTP id JAA02727; Tue,
          15 Feb 2000 09:56:55 -0800 (PST)
X-Sender: jwillkie@apprentice.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
References: <"Your message with ID" <38A9623C.C817B104@ccrle.nec.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <4.1.20000215094449.00cdcf00@apprentice.qualcomm.com>
Date:         Tue, 15 Feb 2000 09:56:39 -0800
Reply-To: Jim Willkie 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Jim Willkie 
Subject:      Re: [MOBILE-IP] Questions related to FA assisted hand-off
X-To:         "pcalhoun@eng.sun.com" 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

Folks:
Excuse me for jumping into the middle of a topic, but a couple things below
need clarity...


At 08:44 AM 2/15/00 -0800, pcalhoun@eng.sun.com wrote:
>Karl, see my responses below.
>
>PatC
>
>> Reading draft-calhoun-mobileip-proactive-fa-00.txt, a couple of
>> questions
>> came up:
>>
>> * why do you choose the FA to assist the hand-off?
>In today's cellular network, the BSC/BTS is responsbile for such hand-offs (at
>least in the CDMA network, I'm not sure about GSM). As some of us in 3GPP2
>(and WMIF) are trying to come up with an All-IP cellular network
>infrastructure, we are looking at how we can expand existing IETF protocols to
>suit our requirements.
>
>The BSC/BTS currently measures the signal strength in order to determine the
>mobile's movements. This is done by the link layer, and it seemed to make
>sense to write an interface of some form between this link layer and the
>Mobile IP FA stack. The idea here is to take as much as we can from the
>cellular networks and put as much as we can in IP, and make the cellular
>networks look like nothing more than a link layer (albeit a rather complex
>link layer).

Correction: signal strength (and most other BSC/BTS functionality
mentioned) is in the physical layer, not the link layer.

>> Wouldn't this make more sense, since the MN might not be
>> able to listen to multiple FAs?
>Well, in today's cellular networks, the Mobile Node receives up to 6 data
>streams from different BTS' (again, in a CDMA network). It also isn't clear
>that the Mobile can still receive packets from oFA (due to signal strength).
>
>Another alternative is to have both oFA and nFA send the indication to the
>mobile.


It is a misrepresenation to state that CDMA mobiles can receive multiple
streams. To state more correctly a CDMA mobile can receive its signal from
multiple BTS's, which is a great aid to dealing with multipath issues. This
unique benefit of CDMA is a physical layer thing, and does nothing to
provide multiple link layer streams to a single mobile.

>> * registering with a new FA could mean to access the network
>> via a new physical link. This might be useful even in the
>> absence of FAs. Would you suggest to have a separate hand-off
>> mechanism for physical connections?
>I *have* been thinking about something along these lines. In today's CDMA
>network (again, I need some help as far as GSM is concerned), the MN can
>receive up the data stream from up to 6 BTS. If a new simultaneous
>binding-like function was added to Mobile IP, it would allow the FA to send
>multiple instances of packets to the relevant BTS, and provide BSC-like
>functionality.
>
>Note, that the last paragraph is still an very rough idea that I have, and
>requires lots of engineering.

Ditto from above..... I don't profess to be on top of the bigger issue of
this thread but I wanted to make sure the actual behavior of the CDMA air
interface is properly understood.

Thanks, Jim Willkie


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 13:07:39 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16726
	for ; Tue, 15 Feb 2000 13:07:38 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2701AB70@standards.nortelnetworks.com>; Tue, 15 Feb 2000 13:04:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 48789 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 13:02:53
          -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.92945830@standards.nortelnetworks.com>; Tue, 15 Feb 2000 12:52:53
          -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 JAA07594; Tue, 15 Feb 2000 09:55:35
          -0800 (PST)
Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM
          [129.146.95.34]) by engmail3.Eng.Sun.COM
          (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id JAA29618; Tue, 15 Feb
          2000 09:55:33 -0800 (PST)
Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id
          JAA12107; Tue, 15 Feb 2000 09:55:32 -0800
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  
Date:         Tue, 15 Feb 2000 09:55:32 -0800
Reply-To: "pcalhoun@eng.sun.com" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: "pcalhoun@eng.sun.com" 
Subject:      Re: [MOBILE-IP] simultaneous mobility bindings: 'tunnels a copy
              to each'
X-To:         "Karim El-Malki (ERA)" 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <5F05C89FB2F8D211B6430008C791912703EA7E87@esealnt190>

> I agree it is 'quite a complex issue':
> >  we are talking about QoS routing, which is so hard most folks have
> >  given up on it; and then compounding the problem by not merely
> >  selecting the one 'best' route, but rather forwarding packets
> >  over multiple concurrent paths.
>
> Well, simultaneous bindings are definitely not a means of "compounding
> the problem" as you put it, but quite the opposite. In many cases,
> having multiple concurrent paths is a good thing.
> If a MN is making a handoff between FAs, having copies of the
> same packets reaching both FAs for a short period will help
> in improving the quality of handoffs. Therefore your specific
> requirements are not the only ones we should be considering.

Yes, but in a hierarchical scheme, wouldn't it be nice if a parent FA could
handle the distribution of packets to multiple lower layer children FAs?

PatC
>
> Regards,
> Karim


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 13:13:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16916
	for ; Tue, 15 Feb 2000 13:13:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.000D2D40@standards.nortelnetworks.com>; Tue, 15 Feb 2000 13:10:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 48839 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 13:09:06
          -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.6FB429C0@standards.nortelnetworks.com>;
          Tue, 15 Feb 2000 12:59:04 -0500
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id LAA04788; Tue, 15 Feb 2000 11:01:11
          -0700 (MST)
Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM
          [129.146.55.34]) by engmail4.Eng.Sun.COM
          (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id KAA27690; Tue, 15 Feb
          2000 10:01:01 -0800 (PST)
Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id
          KAA15475; Tue, 15 Feb 2000 10:00:57 -0800
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  
Date:         Tue, 15 Feb 2000 10:00:57 -0800
Reply-To: "pcalhoun@eng.sun.com" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: "pcalhoun@eng.sun.com" 
Subject:      Re: [MOBILE-IP] Questions related to FA assisted hand-off
X-To:         Jim Willkie 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <4.1.20000215094449.00cdcf00@apprentice.qualcomm.com>

> Folks:
> Excuse me for jumping into the middle of a topic, but a couple things below
> need clarity...
>
>
> At 08:44 AM 2/15/00 -0800, pcalhoun@eng.sun.com wrote:
> >Karl, see my responses below.
> >
> >PatC
> >
> >> Reading draft-calhoun-mobileip-proactive-fa-00.txt, a couple of
> >> questions
> >> came up:
> >>
> >> * why do you choose the FA to assist the hand-off?
> >In today's cellular network, the BSC/BTS is responsbile for such hand-offs
> (at >least in the CDMA network, I'm not sure about GSM). As some of us in
> 3GPP2 >(and WMIF) are trying to come up with an All-IP cellular network
> >infrastructure, we are looking at how we can expand existing IETF protocols
> to >suit our requirements.
> >
> >The BSC/BTS currently measures the signal strength in order to determine the
> >mobile's movements. This is done by the link layer, and it seemed to make
> >sense to write an interface of some form between this link layer and the
> >Mobile IP FA stack. The idea here is to take as much as we can from the
> >cellular networks and put as much as we can in IP, and make the cellular
> >networks look like nothing more than a link layer (albeit a rather complex
> >link layer).
>
> Correction: signal strength (and most other BSC/BTS functionality
> mentioned) is in the physical layer, not the link layer.
>
> >> Wouldn't this make more sense, since the MN might not be
> >> able to listen to multiple FAs?
> >Well, in today's cellular networks, the Mobile Node receives up to 6 data
> >streams from different BTS' (again, in a CDMA network). It also isn't clear
> >that the Mobile can still receive packets from oFA (due to signal strength).
> > >Another alternative is to have both oFA and nFA send the indication to the
> >mobile.
>
>
> It is a misrepresenation to state that CDMA mobiles can receive multiple
> streams. To state more correctly a CDMA mobile can receive its signal from
> multiple BTS's, which is a great aid to dealing with multipath issues. This
> unique benefit of CDMA is a physical layer thing, and does nothing to
> provide multiple link layer streams to a single mobile.

Correct, that was what I meant to state (and failed).

PatC


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 13:17:28 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17002
	for ; Tue, 15 Feb 2000 13:17:27 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.47B76DE0@standards.nortelnetworks.com>; Tue, 15 Feb 2000 13:12:16 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 48894 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 13:10:27
          -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.069478D0@standards.nortelnetworks.com>; Tue, 15 Feb 2000
          13:10:26 -0500
Received: from SMTP (esealnt406.al.sw.ericsson.se [153.88.251.29]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          TAA18704; Tue, 15 Feb 2000 19:13:09 +0100 (MET)
Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by 153.88.251.29
          (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 15 Feb 2000
          18:13:08 0000 (GMT)
Received: by esealnt400 with Internet Mail Service (5.5.2448.0) id <18LRCWJJ>;
          Tue, 15 Feb 2000 19:13:07 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <5F05C89FB2F8D211B6430008C791912703EA7E89@esealnt190>
Date:         Tue, 15 Feb 2000 19:13:04 +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] simultaneous mobility bindings: 'tunnels a copy t
              o each'
X-To:         "pcalhoun@eng.sun.com" 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

>  > I agree it is 'quite a complex issue':
>  > >  we are talking about QoS routing, which is so hard most
>  folks have
>  > >  given up on it; and then compounding the problem by not merely
>  > >  selecting the one 'best' route, but rather forwarding packets
>  > >  over multiple concurrent paths.
>  >
>  > Well, simultaneous bindings are definitely not a means of
>  "compounding
>  > the problem" as you put it, but quite the opposite. In many cases,
>  > having multiple concurrent paths is a good thing.
>  > If a MN is making a handoff between FAs, having copies of the
>  > same packets reaching both FAs for a short period will help
>  > in improving the quality of handoffs. Therefore your specific
>  > requirements are not the only ones we should be considering.
>
>  Yes, but in a hierarchical scheme, wouldn't it be nice if a
>  parent FA could
>  handle the distribution of packets to multiple lower layer
>  children FAs?

I agree, in fact I was thinking about the hierarchical case. Either the
GFA or intermediate regional FAs could do that.
I presented this at the Oslo IETF called Fast Handoffs
http://www.ietf.org/internet-drafts/draft-elmalki-mobileip-fast-handoffs-01.txt
which is specifically for hierarchies, and plan to submit an updated
draft for Adelaide.

rgds,
Karim


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 14:33:10 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19811
	for ; Tue, 15 Feb 2000 14:33:10 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.10BE3E80@standards.nortelnetworks.com>; Tue, 15 Feb 2000 14:29:28 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 49032 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 14:27:40
          -0500
Received: from maxcow.borg.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.6AB21DA0@standards.nortelnetworks.com>; Tue, 15 Feb 2000 14:17:40
          -0500
Received: from mail.borg.com (mail.borg.com [205.217.206.192]) by
          maxcow.borg.com (8.9.0/8.8.8) with ESMTP id OAA12523; Tue, 15 Feb
          2000 14:19:57 -0500 (EST)
Received: from swc (cti-fw2.borg.com [205.217.206.199]) by mail.borg.com
          (8.9.3/8.9.3) with SMTP id OAA47598; Tue, 15 Feb 2000 14:19:50 -0500
          (EST) (envelope-from stu@critical.com)
X-Sender: stu@mail.borg.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
References: <"Your message with ID"             
            <5F05C89FB2F8D211B6430008C791912703EA7E87@esealnt190>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <3.0.6.32.20000215142210.0079b970@mail.borg.com>
Date:         Tue, 15 Feb 2000 14:22:10 -0500
Reply-To: Stuart Card 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Stuart Card 
Subject:      Re: [MOBILE-IP] simultaneous mobility bindings: 'tunnels a copy
              to each'
X-cc:         "Karim El-Malki (ERA)" ,
              "pcalhoun@eng.sun.com" ,
              dan.hague@rl.af.mil, dave@critical.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

Karim.El-Malki@ERA.ERICSSON.SE wrote --

>> ... In many cases, having multiple concurrent paths is a good thing...
>> your specific requirements are not the only ones we should be considering.

Agreed!

pcalhoun@eng.sun.com then wrote:

>Yes, but in a hierarchical scheme, wouldn't it be nice if a parent FA could
>handle the distribution of packets to multiple lower layer children FAs?

Indeed! The general case is rather complex, and a FA hierarchy could help.

We have:

  Correspondent Host (CH);

  Mobile Host (MH);

  Home Agent of the Mobile Host (HAmh);

  Foreign Agent of the Mobile Host (FAmh);

  Mobile Router (MR);

  Home Agent of the Mobile Router (HAmr); and

  Foreign Agents of the Mobile Router (FAmr0..FAmrN).

Typically, FAmh = MR.

If we tell HAmr only about FAmr0, and have the latter
act as a parent FAmr for all the other FAmr1..FAmrN, we
could limit distribution of link status to the FAmr net:
each FAmrJ need know only about MR and FAmr0; and FAmr0
is the only node that needs to know about all the other
FAmr1..FAmrN (and, for each, whether its link to MR is
currently usable, or better still, its current link QoS).

MR, of course, must also know about each FAmr1..FAmrN,
but that is nothing new if it is registered with each;
further, it is only 1 hop from each, across the wireless
links, knowledge of whose current QoS is our major concern.

Interposing the parent FAmr does not reduce the complexity,
but it _hides_ it from HAmr, allowing HAmr to be 'merely' a
standard HA with mobile router support, rather than also a
QoS-aware, load-balancing, concurrent multipath router
(as FAmr takes on that responsibility).  This buys us nothing
if we own (and thus can put fancy QoS routing code in) HAmr;
but if we don't own HAmr, it buys us much.

Our approach here is to _use_ Mobile-IP to provide multiple
concurrent tunnels; but not to _burden_ Mobile-IP itself
(the baseline HA and FA functionalities) with our fancy
routing.  Once the HA has constructed the tunnels, the
decision as to which tunnel to use for a given packet
(or [micro]flow) is left to the forwarding process.

A HA is, in essence, a router; but typically it has
only one route to the mobile node -- the tunnel defined
by a single registration.  Allowing multiple simultaneous
registrations merely allows for multiple tunnels, thus
multiple paths, yielding a situation more akin to that
normally found in core routers.  We can then use tricks
used in core routers to select among those paths.

***

What this boils down to, IMHO, is this:

FA hierarchies allow us to _optimize_ this, and are generally
A Good Thing;

but the current option for multiple simultaneous registrations at
the HA allows us to do this _without_ introducing a requirement
for FA heirarchies;

and furthermore, that option supports at least one straightforward
approach for _creating_ FA heirarchies.

Thus, that option should _NOT_ be removed from RFC 2002!

------------------------------------------------------------------------
Stuart W. Card, Chief Scientist & Vice-Pres., Critical Technologies Inc.
Suite 400 Technology Center, 4th Floor 1001 Broad Street, Utica NY 13501
315-793-0248   FAX -9710       http://www.critical.com


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 15 15:24:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21258
	for ; Tue, 15 Feb 2000 15:24:02 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.332DB020@standards.nortelnetworks.com>; Tue, 15 Feb 2000 15:20:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 49101 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 15 Feb 2000 15:19:44
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.B080BC40@standards.nortelnetworks.com>; Tue, 15 Feb 2000 15:09:43
          -0500
Received: from gull.prod.itd.earthlink.net (gull.prod.itd.earthlink.net
          [207.217.121.85]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP
          id OAA14302 for ; Tue, 15 Feb 2000 14:12:24
          -0600 (CST)
Received: from oemcomputer (sdn-ar-002nvlvegP326.dialsprint.net
          [206.133.195.104]) by gull.prod.itd.earthlink.net (8.9.3/8.9.3) with
          SMTP id MAA04896; Tue, 15 Feb 2000 12:11:08 -0800 (PST)
Message-ID:  <200002152011.MAA04896@gull.prod.itd.earthlink.net>
Date:         Tue, 15 Feb 2000 12:11:08 -0800
Reply-To: mikerobbins_afs@HOTMAIL.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: mikerobbins_afs@HOTMAIL.COM
Subject:      [MOBILE-IP] Guaranteed way to instantly have Excellent Credit!!
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Dear Friend,

Give yourself the ADVANTAGE of a new, legal, unblemished credit file in less
than 30 days, allowing you to enter this New Millennium with EXCELLENT CREDIT!!

Over the past 8 years I have perfected a system called the Proven Credit
Advantage Program. It's a guaranteed way for legally getting an excellent
credit rating almost instantly. Here's how.

You will simply go through my easy 5 step program to quickly get a new, legal,
unblemished credit file and establish Excellent Credit.

Step 1 -
Because no two people in the United States have the same Social Security
Number, Banks and Creditors access your credit file almost entirely by your SS#.

You will not want to change your Social Security Number because it is extremely
difficult to do so and you need it for your Employment, Taxes and Social
Security Benefits. The FEDERAL PRIVACY ACT OF 1974 clearly states that only
the Government and your employer can force you to use your SS#. Because of this
law you are allowed to legally use another 9 digit number to use in place of
your Social Security # on credit applications.

The first day you become my client, you will receive your own number through
the Employer Identification Number Program. You will need us for this because 95%
of all Employer Identification Numbers, although 9 digits, do not look anything
like Social Security Numbers and cannot be used on credit applications.
We will legally get you an Employer Identification Number that fits in the same
range of Social Numbers in use today. Because the Federal Laws do not require
you to give your SS# to anyone besides your Employer and the Government, you
can now legally use this number in place of your SS# on credit applications.
Remember, your new number will only be used for new credit.

Step 2 -
No two people with the same name have the same mailing address, so you will need
to obtain a new mailing address for use on your new credit file. A friend,
relative or mailbox address in your area will be perfect.

Step 3 -
No two people with the same name have the same telephone numbers, so you will
also need a new telephone number for use on your new credit file. A friend,
relative, voice mail or pager will again work perfectly.

Step 4 -
With your new Social Security number, new address and new telephone number we
will open your new credit file. It will now be totally impossible for any
creditor to know anything about your past credit history.

Step 5-
To guarantee that you will quickly qualify for credit again, we will assist you
in instantly adding positive information to your new credit file. This is an
unknown way of adding real accounts to your new credit file to give you an
Excellent Credit Rating in less than 30 days. As you know, the more positive
information on your credit file, the more money banks will lend you.

Many of our clients have credit lines over $100,000 because of our Proven Credit
Advantage Program!

When we are finished you will have a copy of your new, legal, unblemished credit
file proving that you now have excellent credit again. This will take less than
30 days. You will now be able to easily qualify for credit!

To order your Proven Credit Advantage Program simply send me your name, complete
mailing address including zip code and telephone number (optional) along with a
check or money order payable to American Financial Services Inc. for $39.00.

Send to:

American Financial Services Inc.
Attn: Mike Robbins
311 N. Robertson Blvd.
Suite 625
Beverly Hills, CA 90210

All necessary paperwork along with a telephone number to contact us for
assistance will be priority mailed to you within 48 hours.

RISK FREE DOUBLE YOUR MONEY BACK GUARANTEE

My Proven Credit Advantage Program unconditionally guarantees you will qualify
for personal loans, business loans, credit cards, auto loans, home loans and any
other credit you apply for!

If you are not able to qualify for credit after using my program, simply
return your Proven Credit Advantage Program along with your denial letter and
your $39.00 investment will be refunded DOUBLE! That's a $78.00 refund if this
doesn't work like I say!

I make this guarantee to you because the Proven Credit Advantage Program has
already helped thousands of people just like you. I KNOW it works - all you need
to do is order! I truly look forward to making you another SATISFIED CLIENT!!


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Feb 16 01:21:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08134
	for ; Wed, 16 Feb 2000 01:21:00 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8F02AAB0@standards.nortelnetworks.com>; Wed, 16 Feb 2000 1:17:14 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 49657 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Feb 2000 01:15:38
          -0500
Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.EFA8DD00@standards.nortelnetworks.com>;
          Wed, 16 Feb 2000 1:05:38 -0500
Received: from cc.hut.fi (root@alpha.hut.fi [130.233.224.50]) by smtp-2.hut.fi
          (8.9.3/8.9.3) with ESMTP id IAA55997; Wed, 16 Feb 2000 08:08:17 +0200
          (EET)
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i586)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <38AA3F79.3C70FEA7@cc.hut.fi>
Date:         Wed, 16 Feb 2000 08:11:05 +0200
Reply-To: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" 
Organization: HUT
Subject:      Re: [MOBILE-IP] simultaneous mobility bindings: 'tunnels a copyto
              each'
X-To:         "pcalhoun@eng.sun.com" 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

"pcalhoun@eng.sun.com" wrote:
>
> Yes, but in a hierarchical scheme, wouldn't it be nice if a parent FA could
> handle the distribution of packets to multiple lower layer children FAs?
>
> PatC

Exactly. I haven't seen anyone mentioning packet duplication here. Has
the current suggestion been to let the HA to duplicate the packets to
all the tunnels it has for the MN? That is at least what a standard
implementation would do, if it had multiple tunnels for a single MN.

OTOH, using FA hierarchies is more like multicasting; the HA sends the
packets to one destination (the Highest FA) which could then do a policy
decision, whether to duplicate packets to multiplse lower FAs. If FA
functionality were improved, some QoS style balancing for the different
tunnels could be added.

If one of the problem to be solved was how to multiply the bandwith over
the _Internet_, then this scheme would not help. If the goal was to
multiply the BW inside a FA hierarchy, then my point is valid.

My point was to make this transparent for the HA, reduce the number of
packets (duplicates) traversing the Internet, and also provide fast
localized handoffs in the FA hierarchy while also giving a possibility
to multiply BW inside the FA hierarchy (with additional QoS logic in the
FA).

--
        Tom Weckström           Dynamics group
                                Helsinki University of Technology
                                dynamics@cs.hut.fi
                                http://www.cs.hut.fi/Research/Dynamics/


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Feb 16 01:26:39 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08613
	for ; Wed, 16 Feb 2000 01:26:38 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.674CFF60@standards.nortelnetworks.com>; Wed, 16 Feb 2000 1:23:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 49667 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Feb 2000 01:21:42
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.C88E1220@standards.nortelnetworks.com>; Wed, 16 Feb 2000 1:11:41
          -0500
Received: from paxcomm.com (IDENT:root@paxws1.chungnam.ac.kr [168.188.60.34])
          by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id AAA17424 for
          ; Wed, 16 Feb 2000 00:14:23 -0600 (CST)
Received: from icon ([203.253.129.235]) by paxcomm.com (8.9.3/8.9.3) with SMTP
          id PAA01425 for ; Wed, 16 Feb 2000 15:11:19
          +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0005_01BF7890.1756C710"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.3825.400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.3825.400
Message-ID:  <000801bf7844$abc16230$eb81fdcb@keti.re.kr>
Date:         Wed, 16 Feb 2000 15:11:25 +0900
Reply-To: =?ks_c_5601-1987?B?w9bHyr/1?= 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: =?ks_c_5601-1987?B?w9bHyr/1?= 
Subject:      [MOBILE-IP] subscribe request..
X-To:         mobile-ip@smallworks.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01BF7890.1756C710
Content-Type: text/plain;
        charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

c3Vic2NyaWJlIHJlcXVlc3QuLg0K

------=_NextPart_000_0005_01BF7890.1756C710
Content-Type: text/html;
        charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA1LjUwLjM4MjUuMTMwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv
SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPnN1YnNjcmli
ZSByZXF1ZXN0Li48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg==

------=_NextPart_000_0005_01BF7890.1756C710--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Feb 16 04:44:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21163
	for ; Wed, 16 Feb 2000 04:43:49 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CFC14EF0@standards.nortelnetworks.com>; Wed, 16 Feb 2000 4:39:29 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 49872 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Feb 2000 04:38:07
          -0500
Received: from tokyo.ccrle.nec.de by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9ED05110@standards.nortelnetworks.com>; Wed, 16 Feb 2000 4:38:07
          -0500
Received: from wallace.heidelberg.ccrle.nec.de (Wallace.heidelberg.ccrle.nec.de
          [192.168.102.1]) by tokyo.ccrle.nec.de (8.8.7/3.6W980303HK) with
          ESMTP id KAA10701 for ; Wed,
          16 Feb 2000 10:43:29 +0100 (CET)
Received: from ccrle.nec.de (atoll.heidelberg.ccrle.nec.de [192.168.102.96]) by
          wallace.heidelberg.ccrle.nec.de (8.8.7/3.6W980203HK) with ESMTP id
          KAA29513 for ; Wed, 16 Feb
          2000 10:54:30 +0100 (CET)
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38AA70A5.B21376E3@ccrle.nec.de>
Date:         Wed, 16 Feb 2000 10:40:53 +0100
Reply-To: Karl Jonas 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Karl Jonas 
Organization: NEC CCRLE
Subject:      Re: [MOBILE-IP] Questions related to FA assisted hand-off
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Pat et al, thanks for the replies.

Let me argue again for a separation of FA functionality and hand-off
support,
and for a 'direct' communication with the MN.

The discussion (in particular Claude's arguments) shows that there is
concern to move more functionality from the MN into the network.
Although I think that is is always good to OFFER support from the
network
(for whatever), this should be separated fro required functions and
optional
to implement/provide. A MN should not rely on it.

If hand-off-support would become part of FA functionality, it would go
away
with the FA in IPv4 CoCOA mode  and in IPv6. If it, on the other hand,
is
an independent service it could still be co-located / implemented with
the FA.

This would also make independent service provision simpler.
Operators might want to optimise network resource usage, thus offering
hand-off support in the access network.
I might want to optimise on cost, with hand-off support either on my
MN or my home network (HA?), or both.
Someone else might want to offer this as a third party service.

These are a few examples why network-assisted hand-off should not
necesarily be supported by the FA, but be independent.

This hand-off support agent (let me call it X) should use the most
appropriate
way to communicate with the MN, which is either via the current FA or
using
the current CoCOA.

Also, it should be considered that these messages could be interpreted
by the MN as
hints or as requests. An operator might want to be able to force
hand-over, while
my private cost-optimiser just wants to inform.

Maybe the messages do not allways need to be sent to the MN, but to the
old FA,
since the oFA could force a hand-over (is this part of MIP?).

comments?

karl



--
Karl Jonas, NEC C&C Research Labs
EMail: karl.jonas@ieee.org
Tel.:  +49.(0)6221.905 11 21
Fax:   +49.(0)6221.905 11 55
http://www.ccrle.nec.de/heidelberg/index.html


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Feb 16 05:53:12 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21901
	for ; Wed, 16 Feb 2000 05:53:12 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9B633240@standards.nortelnetworks.com>; Wed, 16 Feb 2000 5:49:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 49965 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Feb 2000 05:48:11
          -0500
Received: from marc (171.212.48.253) by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.0297B500@standards.nortelnetworks.com>; Wed, 16 Feb 2000 5:38:10
          -0500
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Wed, 16 Feb 2000 05:48:11 -0500
Reply-To: Marc Lev 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Marc Lev 
Subject:      [MOBILE-IP] We pay cash, now!
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Do you know someone who is currently trying to sell their mobile home or mobile home park?  Do you know someone who is currently receiving
payments from the sale of a mobile home or mobile home park?  If you answered yes to any of these questions we may be able to help.

At Trans World Funding we are in the businesss of helping people convert payments from their mobile home or park into immediate cash.  We have
investors who purchase these notes and give the sellers a lump sum of cash instead of them having to receive monthly payments over a long
period of time.

If you know of someone who is selling a mobile home or park, this program may help them sell it faster.  If you know of someone whom has sold a
mobile home with seller financing and is reveiving payments, this may help them financially.

Please feel free to contact me regarding this issue.

Success always,

Marc L. Lev, DCFS
President
Trans World Funding
TWF20000@aol.com

PS We pay top dollar for referrals!


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Feb 16 06:01:04 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22013
	for ; Wed, 16 Feb 2000 06:01:04 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BBAFF9B0@standards.nortelnetworks.com>; Wed, 16 Feb 2000 5:57:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 50010 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Feb 2000 05:56:48
          -0500
Received: from mw.3com.com (149.112.20.3) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.9C678D70@standards.nortelnetworks.com>; Wed, 16 Feb 2000 5:56:47
          -0500
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com
          Corporation) id EAA28041; Wed, 16 Feb 2000 04:59:26 -0600 (CST)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id
          86256887.003C7BBB ; Wed, 16 Feb 2000 05:00:38 -0600
X-Lotus-FromDomain: 3COM@3COM-MWGATE
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <86256887.003C7AE8.00@mwgate02.mw.3com.com>
Date:         Wed, 16 Feb 2000 04:51:44 -0600
Reply-To: Yingchun Xu 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Yingchun Xu 
Subject:      Re: [MOBILE-IP] More comments on draft-ietf-mobileip-3gwireless
              -ext-02.txt
X-To:         "pcalhoun@eng.sun.com" 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Pat,
I agree with you that we need to make it clear that both PCF IP address and
session key field are necessary to mux/demux a GRE tunneled data. But we did
have sentences stating that each RP tunnel session is uniquely identified by PCF
IP address and session key combination.

By the way, why do you think that using source IP address will impose large
overhead since the source IP address is already there in outer IP packet header.
Do you have anyway to eliminate the source IP address?

--Yingchun.




"pcalhoun/@eng.sun.com" 

Sent by:  "pcalhoun@eng.sun.com" ; Wed, 16 Feb 2000 07:26:40 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9F9F4260@standards.nortelnetworks.com>; Wed, 16 Feb 2000 7:22:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 50107 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Feb 2000 07:21:39
          -0500
Received: from bom3.vsnl.net.in by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.114961E0@standards.nortelnetworks.com>; Wed, 16 Feb 2000 7:11:38
          -0500
Received: from AshishBaweja ([203.197.226.188]) by bom3.vsnl.net.in
          (8.9.0/8.9.0) with SMTP id RAA13436; Wed, 16 Feb 2000 17:43:31 +0530
          (IST)
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.00.2314.1300
Message-ID:  
Date:         Wed, 16 Feb 2000 17:48:04 +0530
Reply-To: Ashish Baweja 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Ashish Baweja 
Subject:      Re: [MOBILE-IP] micromobility in IPv6 ?
X-To:         charliep@IPRG.NOKIA.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38A4951C.A369B13F@iprg.nokia.com>
Content-Transfer-Encoding: 7bit

Hi,
        I am pretty new on this to this area and am interested in doing my major
B.Tech. project on mobile IP over IPV6.
I have just started reading documents and trying sampe implementations. I
have few basic queries to sort out before i start:
1. I don't have access to wavelan cards. So can I implement and test MIPV6
over ethernet networks and does any of sample implmentation work over
ethernet.
2. Can i implement MIPV6 over NS-2 and can code will be ported easily frm
NS-2 to wavelan and ethernet.
Ashish Baweja


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Feb 16 10:45:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02886
	for ; Wed, 16 Feb 2000 10:45:54 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7203A050@standards.nortelnetworks.com>; Wed, 16 Feb 2000 10:41:56 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 50248 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 16 Feb 2000 10:40:13
          -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.CB554C00@standards.nortelnetworks.com>; Wed, 16 Feb 2000 10:30:07
          -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 HAA29007; Wed, 16 Feb 2000 07:32:53
          -0800 (PST)
Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM
          [129.146.101.34]) by engmail3.Eng.Sun.COM
          (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id HAA03910; Wed, 16 Feb
          2000 07:32:52 -0800 (PST)
Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id
          HAA19515; Wed, 16 Feb 2000 07:32:44 -0800
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  
Date:         Wed, 16 Feb 2000 07:32:44 -0800
Reply-To: "pcalhoun@eng.sun.com" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: "pcalhoun@eng.sun.com" 
Subject:      Re: [MOBILE-IP] More comments on draft-ietf-mobileip-3gwireless
              -ext-02.txt
X-To:         Yingchun_Xu@3com.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <88256887.003C2AFD.00@hqoutbound.ops.3com.com>

Simply because a single 32-bit compare algorith is faster than a 2 32-bit one.
Of course, one could hash both values and use a hash lookup, but there are
chances that there are collisions, which then requires that you walk through a
list of entries doing 2 32-bit compares.

This isn't a big deal, I was simply making an observation.

PatC

>
>
> Pat,
> I agree with you that we need to make it clear that both PCF IP address and
> session key field are necessary to mux/demux a GRE tunneled data. But we did
> have sentences stating that each RP tunnel session is uniquely identified by
> PCF IP address and session key combination.
>
> By the way, why do you think that using source IP address will impose large
> overhead since the source IP address is already there in outer IP packet
> header. Do you have anyway to eliminate the source IP address?
>
> --Yingchun.
>
>
>
>
> "pcalhoun/@eng.sun.com" 
> Please respond to "pcalhoun@eng.sun.com" 
>
> Sent by:  "pcalhoun@eng.sun.com" 
>
> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> cc:    (Yingchun Xu/MW/US/3Com)
> Subject:  [MOBILE-IP] More comments on
>       draft-ietf-mobileip-3gwireless-ext-02.txt
>
>
>
>
> All,
>
> As I near implementation of this draft, I still have many concerns that I
> need to bring up:
>
> 1. GRE Key (or session id) generation. The spec requires that the PCF/RAN (or
> initiator of the reg request) creates the pseudo unique GRE id. Since a PDSN
> (or termination point of the reg request) will be communicating with many
> PCFs, the GRE identifier is hardly unique. Since the GRE id is not unique,
> the PDSN cannot use this value alone to identify a data stream from the PCF.
> So, we have a couple of options:
>
>         a) Document that tunnel identification is done by using the GRE id
> AND
>            the source IP address of the reg request. Of course, this imposes
> a
>            rather large per packet overhead.
>         b) Change the specification to mimick the VTP approach where the
> tunnel
>            initiator sets the most significant 16 bits, and the PDSN sets the
>            least significant 16 bits. The 16 bits set MUST be locally unique.
>            This scheme works as long as no more than 65535 sessions are
> needed
>            per pair (for lookups, the full 32bits are used).
>
> 2. The somewhat complicated requirement that both the FA and rpd (that
> handles the protocol defined in this draft) listen on port 434. Some
> suggestions have been make that processes only need to listen on certain
> interfaces, etc. I have thought more about this, and I REALLY don't like
> this approach. Since the ONLY thing that both Mobile-IP and R-P share in
> common is the packet format (and the extensions used are different), they
> are different protocols. Why can we not simply require that R-P be used over
> a different port? This is a VERY simply problem to the solution, and no
> longer assumes ANY architectural requirements.
>
> Comments?
>
> PatC
>
>
>
>


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Feb 17 08:37:25 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12307
	for ; Thu, 17 Feb 2000 08:37:22 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A72625C0@standards.nortelnetworks.com>; Thu, 17 Feb 2000 8:33:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 53211 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 17 Feb 2000 08:31:24
          -0500
Received: from nutpagw.nutec.com.br by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F989FBE0@standards.nortelnetworks.com>; Thu, 17 Feb 2000 8:21:22
          -0500
Received: from NOTESPOA by nutpagw.nutec.com.br via smtpd (for
          standards.nortelnetworks.com [137.118.21.16]) with SMTP; 17 Feb 2000
          14:25:45 UT
Received: from nutpagw.nutec.com.br ([209.206.4.242]) by notespoa.nutec.com.br 
          with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 17 Feb 2000 10:14:19
          -0300
Received: from cranston-ip-1-242.dynamic.ziplink.net ([209.206.4.242]) by
          nutpagw.nutec.com.br via smtpd (for NOTESPOA [200.17.174.66]) with
          SMTP; 17 Feb 2000 14:23:18 UT
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <003ca1914131120NOTESPOA@notespoa.nutec.com.br>
Date:         Thu, 17 Feb 2000 06:49:09 -0500
Reply-To: Marc 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
Comments:     RFC822 error:  Incorrect or incomplete address field found and
              ignored.
From: Marc 
Subject:      [MOBILE-IP] Start Today
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA12307

Start your own 1-900 business or Adult Web Site Business!

People are making $$$ week, after week in the 1-900 business.  We'll
teach you all of our incredible secrets that will take your new
exciting business to a whole new level!

It's The Simplest and Most Exciting Business You Could Ever Start!

*You'll use our "state" of the art equipment!
*You'll use our "Live 1 on 1 Psychics" & "Chat Line" girls!
*You'll use our incredible Date Line program(s)!

No chargebacks!
Quick payouts!
No expertise needed!

Complete programs start at only $99 (no additional charges)

The only thing you'll have to do is advertise! This is an excellent
turnkey business.

We also have excellent turnkey programs if you want to own your own
"top" of the line adult web site.

ACT NOW!!!


For a free color brochure:
reply to: mailto:lak34@iwon.com?subject=brochure
With the following information:

          Name:_________________
       Address:_________________
City/State/Zip:_________________
 email address:_________________
     Telephone:_________________ (optional)

///////////////////////////////////////////////////
To be removed permanantly from this list reply to:
mailto:tracie9090@usa.net?subject=remove
///////////////////////////////////////////////////


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Feb 18 10:44:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25363
	for ; Fri, 18 Feb 2000 10:44:43 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9AC05A40@standards.nortelnetworks.com>; Fri, 18 Feb 2000 10:40:42 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 54064 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 18 Feb 2000 10:39:06
          -0500
Received: from mainframe.dgrc.crc.ca by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.FB9D5400@standards.nortelnetworks.com>; Fri, 18 Feb 2000 10:29:05
          -0500
Received: from crc.ca (curly [142.92.38.251]) by mainframe.dgrc.crc.ca
          (8.9.3/8.9.3) with ESMTP id KAA17721 for
          ; Fri, 18 Feb 2000 10:27:40
          -0500 (EST)
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38AD65E4.1F67C673@crc.ca>
Date:         Fri, 18 Feb 2000 10:31:48 -0500
Reply-To: Guilhem Tardy 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Guilhem Tardy 
Organization: CRC
Subject:      [MOBILE-IP] Home Agents list: understanding of the list of global
              addresses
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi!

I would like to ask for your understanding of the following, found in
draft-ietf-mobileip-ipv6-10.txt, page 17, about the Home Agents list:

          -  One or more global IP addresses for this home agent,
             learned through Prefix Information options with the
             Router Address (R) bit is set, received in Router
             Advertisements from this link-local address.  Global
             addresses for the router in a Home Agents List entry MUST
             be deleted once the prefix associated with that address is
             no longer valid [17].

Does this mean that a node might keep, for each home agent (on each
interface), at least one global address? Hence, it could only keep the
*one* with longest lifetime (and no list of several global addresses is
required)?
I don't see any drawback here, unless a prefix expires before its
advertised lifetime.

Guilhem Tardy.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Feb 19 05:06:27 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22450
	for ; Sat, 19 Feb 2000 05:06:27 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.94623390@standards.nortelnetworks.com>; Sat, 19 Feb 2000 5:02:54 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 54883 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 19 Feb 2000 05:01:44
          -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.6ACF3230@standards.nortelnetworks.com>; Sat, 19 Feb 2000 5:01:44
          -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 CAA20746
          for ; Sat, 19 Feb 2000
          02:04:40 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.9.3/8.9.3-VIRSCAN) id CAA01481 for
          ; Sat, 19 Feb 2000 02:04:40
          -0800
X-Virus-Scanned:  Sat, 19 Feb 2000 02:04:40 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from  (charliep.iprg.nokia.com
          [205.226.2.89]) by darkstar.iprg.nokia.com  SMTP/WTS (12.69)
          xma026852; Sat, 19 Feb 00 02:02:02 -0800
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38AE6A1A.771CD873@iprg.nokia.com>
Date:         Sat, 19 Feb 2000 02:02:02 -0800
Reply-To: charliep@IPRG.NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: "Charles E. Perkins" 
Organization: Nokia Research Center
Subject:      [MOBILE-IP] Two new Internet Drafts about key distribution
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello folks,

I have just sent in two new Internet Drafts about key distribution
to the mobile node.  The Registration Keys draft is a revision of
an old draft from three years ago that is intended to work with
Binding Updates to enable smooth handovers.  The Generalized Key
Distribution draft specifies three generalized extensions, using
the general extension format suggested in MIER.

These drafts are available on my web page:
        http://www.iprg.nokia.com/~charliep/txt/regkey/regkey.txt
        http://www.iprg.nokia.com/~charliep/txt/genkey/genkey.txt

The Registration Keys draft represents quite a departure from
the earlier version.  I have attempted to make it fairly well
contained by including a certain amount of material about elliptic
curve key exchange.  While I believe the material is all correct,
and I've checked it over quite a few times, I also must point
out that I do not claim expertise in this area.  Thus, I expect
that some improvements will be suggested over the next weeks
before Adelaide.  I can make yet another revision for this
draft before the deadline if need be.

Lastly, the Registration Keys draft cites the recent "opaque-data"
draft by Pat Calhoun et.al.  I expect that there will be some
overlap of interest between these two drafts and that their
technical content should remain mutually coordinated.

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sun Feb 20 13:05:00 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11887
	for ; Sun, 20 Feb 2000 13:05:00 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.81B144E0@standards.nortelnetworks.com>; 20 Feb 2000 13:00:48 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 56216 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 20 Feb 2000 12:59:12
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.E2C9E810@standards.nortelnetworks.com>; 20 Feb 2000 12:49:11 -0500
Received: from dik.faulk.loma.net (ip24.tucson4.az.pub-ip.psi.net
          [38.29.64.24]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id
          LAA19974; Sun, 20 Feb 2000 11:52:01 -0600 (CST)
Message-ID:  <200002201752.LAA19974@hosaka.smallworks.com>
Date:         Sun, 20 Feb 2000 11:52:01 -0600
Reply-To: travelright@MAILER.EXCITE.COM-RLY-ACE.GQ.NU
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: travelright@MAILER.EXCITE.COM-RLY-ACE.GQ.NU
Subject:      [MOBILE-IP]
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

RE: A Spectacular Orlando Magical Vacation - - The vacation capital
of the world!

Walt Disney World, Seaworld, Universal Studios and Islands of
Adventure.

Plus Casino Cruises.

Stay 5 days / 4 nights in a luxury 1200 sf condo

This discounted corporate vacation is NOW only $299.00 per
person, plus tax, processing and handling. (doule occupancy)

Kids Stay FREE!

Call Now! 1.800.230.7135 Ext. 700 or 1.800.893.8050  Ext. 700

Make your travel arrangements anytime over the next 12 months

Register TODAY and Receive Complimentary:

2 Adult 4 day Disney Park Hopper passes
2 Adult Casino Cruise Passes
Continental Breakfast - Monday through Friday
Free Shuttle Service to Disney

Also receive your choice of a 3 day 2 night Getaway Bonus with
over 50 locations to choose from!!

Maui, Hawaii; Cancun, Mexico; Las Vegas !!!

This promotional price includes all of the above!!

Don't forget to ask your Agent about Discounted Rental Car with
Unlimited Mileage

HAVE YOUR CREDIT CARD READY AND CALL NOW !!!

1.800.230.7135 Ext. 700 or 1.800.893.8050  Ext. 700


TO REMOVE YOUR ADDRESS FROM FURTHER PROMOTIONAL
OFFERS; REPLY WITH "delete" IN THE SUBJECT LINE AND YOUR
ADDRESS WILL BE DELETED FROM OUR DATABASE.
OR CALL 888-376-8620.
THANK YOU...STAFF


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sun Feb 20 14:18:35 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12287
	for ; Sun, 20 Feb 2000 14:18:35 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DD216D50@standards.nortelnetworks.com>; 20 Feb 2000 14:14:56 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 56343 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 20 Feb 2000 14:13:15
          -0500
Received: from marc (152.172.153.189) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.3B037690@standards.nortelnetworks.com>; 20 Feb 2000 14:03:14 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Sun, 20 Feb 2000 14:13:15 -0500
Reply-To: Marc Lev 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Marc Lev 
Subject:      [MOBILE-IP] $200.00 free!
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Here's a new opportunity to check out.  Ezze to start and quick to pay dividends.  A worthy program to make you rich!

Go to:  http://Magic-NJ.com/office/suite17051.shtml

You,vr received this e-mail becuase we have communicated before or our names have been on the same distrubution lists.  If this is a problem, I
appologize, but please stay calm and simply reply "remove" Thank you for your time.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sun Feb 20 14:36:39 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12435
	for ; Sun, 20 Feb 2000 14:36:39 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.62E1C640@standards.nortelnetworks.com>; 20 Feb 2000 14:32:59 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 56386 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 20 Feb 2000 14:31:09
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.BB4E9030@standards.nortelnetworks.com>; 20 Feb 2000 14:21:09 -0500
Received: from ashley2.net ([199.1.88.146]) by hosaka.smallworks.com
          (8.9.1/8.9.1) with SMTP id NAA20440 for ;
          Sun, 20 Feb 2000 13:24:04 -0600 (CST)
X-Sender: yzptc@mauimail.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3
X-MSMail-Priority: Normal
Message-ID:  <200002201924.NAA20440@hosaka.smallworks.com>
Date:         Sun, 20 Feb 2000 14:33:44 -0500
Reply-To: yzptc@MAUIMAIL.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: yzptc@MAUIMAIL.COM
Subject:      [MOBILE-IP] Your Platinum Free Vacation and Airline Tickets>.
X-To:         mobile-ip@smallworks.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Platinum Travel Club Would Like To Offer You A Complimentary Vacation Of A Lifetime And Two Free Airline Tickets.

Please click on   http://www.platinumtravelclub.com

or if you can not click on  the link please simply visit our website at www.platinumtravelclub.com
for Details Of How To Receive This Now.

Please understand that this is a one time offer and Platinum Club will not resend this offer to you again.

If you do not respond and you have received this message in error we apologize for the inconvenience and
we would like to confirm that you will not receive this offer or any other offer from us again. Thank You.
Code P.F.C.C.52598


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Feb 21 16:47:39 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17783
	for ; Mon, 21 Feb 2000 16:47:39 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CCEE17B0@standards.nortelnetworks.com>; Mon, 21 Feb 2000 16:43:37 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 57235 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 21 Feb 2000 16:41:45
          -0500
Received: from marc (152.169.163.139) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.242E96A0@standards.nortelnetworks.com>; Mon, 21 Feb 2000 16:31:44
          -0500
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Mon, 21 Feb 2000 16:41:45 -0500
Reply-To: Marc Lev 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Marc Lev 
Subject:      [MOBILE-IP] We pay cash, now!
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Do you know someone who is currently trying to sell their mobile home or mobile home park?
Do you know someone who is currently receiving
payments from the sale of a mobile home or mobile home park?  If you answered yes to any of
these questions we may be able to help.

At Trans World Funding we are in the businesss of helping people convert payments from their
mobile home or park into immediate cash.  We have
investors who purchase these notes and give the sellers a lump sum of cash instead of them
having to receive monthly payments over a long
period of time.

If you know of someone who is selling a mobile home or park, this program may help them sell it
faster.  If you know of someone whom has sold a
mobile home with seller financing and is reveiving payments, this may help them financially.

Please feel free to contact me regarding this issue.

Success always,

Marc L. Lev, DCFS
President
Trans World Funding
TWF20000@aol.com

PS We pay top dollar for referrals!


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 22 01:11:06 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24834
	for ; Tue, 22 Feb 2000 01:11:05 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.180E9080@standards.nortelnetworks.com>; Tue, 22 Feb 2000 1:06:48 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 57348 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Feb 2000 01:05:09
          -0500
Received: from homebase.htt-consult.com (63.82.18.210) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.77457B60@standards.nortelnetworks.com>; Tue, 22 Feb 2000
          0:55:09 -0500
Received: from rgm ([63.82.18.195]) by homebase.htt-consult.com ; Tue, 22 Feb
          2000 00:58:13 -0500
X-Sender: rgm-ietf@homebase.htt-consult.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.0.58.20000222004424.00cffc60@homebase.htt-consult.com>
Date:         Tue, 22 Feb 2000 00:57:46 -0500
Reply-To: Robert Moskowitz 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Robert Moskowitz 
Subject:      [MOBILE-IP] Recommended reading - drafts
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38AE6A1A.771CD873@iprg.nokia.com>

I have been a MobileIP lurker for some time.  I am now delurking.

I have discussed bringing up the following with the co-chairs and ADs:

In Dec '98 I started out studying why IPsec was not delivering security
services to the protocols that needed privacy and/or authentication.  My
first opinion was it took too long; later I realized that a fundamental
design of IP was central to IPsec and MobileIP's complexity.  That is the
confounding of naming and routing.  I set out to design a namespace that
would decouple the internetworking and transport layers (BTW, I am on the
IRTF NSRG).  The current result is documented in my Host Identity Payload
drafts:


  http://www.ietf.org/internet-drafts/draft-moskowitz-hip-arch-01.txt
  http://www.ietf.org/internet-drafts/draft-moskowitz-hip-01.txt
  http://www.ietf.org/internet-drafts/draft-moskowitz-hip-impl-00.txt

I will be the first to admit that these drafts need improvement in
presentation.  But in brief, by creating a cryptographically based host
namespace that is statistically globally unique with 3 representations, I
am able to use ESP 'transport layer' in place of the internetworking layer
(either IPv4 or IPv6) for the transport binding.

This provides full mobility of both initiators and responders (responders
need a rendezvous server for initial contact).  Mobility does not need
Dynamic DNS, only DNSSEC (to address man-in-the-middle attacks).

HIP and its ESP can traverse any addressing realm boundaries (NATs, IPv6/4
gateways).

I can appreciate that this is radical thinking, but I ask that people here
look over HIP and send me comments.  Has HIP met its goals?  Does it offer
real end-to-end services?  Can it reduce the complexity in the network and
even the end systems?

I am working on the next set of drafts.  I will not be in Adelaide, but
might be able to get someone to present HIP at one of your sessions if
there is interest.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 22 04:11:24 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07644
	for ; Tue, 22 Feb 2000 04:11:24 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.405B73F0@standards.nortelnetworks.com>; Tue, 22 Feb 2000 4:06:53 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 57397 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Feb 2000 04:05:22
          -0500
Received: from qhars001.nortel.com (192.100.101.18) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.A448BAF0@standards.nortelnetworks.com>; Tue, 22 Feb 2000
          3:55:22 -0500
Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com;
          Tue, 22 Feb 2000 08:56:28 +0000
Received: from zmers013 by smtprch1.nortel.com; Tue, 22 Feb 2000 02:56:28 -0600
Received: from zhard00m.europe.nortel.com (actually zhard00m) by zmers013; Tue,
          22 Feb 2000 03:56:19 -0500
Received: by zhard00m.europe.nortel.com with Internet Mail Service
          (5.5.2650.21) id ; Tue, 22 Feb 2000 08:56:16 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF7D12.AD61DDFE"
Message-ID:  
Date:         Tue, 22 Feb 2000 08:56:16 -0000
Reply-To: Javier Gonzalez 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Javier Gonzalez 
Subject:      Re: [MOBILE-IP] We pay cash, now!
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_01BF7D12.AD61DDFE
Content-Type: text/plain

CAN WE NOT STOP THESE MASS E-MAILINGS ???????

IF NOT, PLEASE UNSUBSCRIBE ME FROM THIS LIST !

JAVIER E. GONZALEZ
Nortel Networks
* (33)(1) 64768249 (bureau)  --> ESN 578-8249
* (33)(6) 85744815 (mobile)  --> ESN 754-4815
* (33)(1) 64767840 (fax)  --> ESN 578-7840
> *javigon@nortelnetworks.com
>
> -----Original Message-----
> From: Marc Lev [SMTP:marclev@VISTO.COM]
> Sent: Monday, February 21, 2000 10:42 PM
> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      [MOBILE-IP] We pay cash, now!
>
> Do you know someone who is currently trying to sell their mobile home or
> mobile home park?
> Do you know someone who is currently receiving
> payments from the sale of a mobile home or mobile home park?  If you
> answered yes to any of
> these questions we may be able to help.
>
> At Trans World Funding we are in the businesss of helping people convert
> payments from their
> mobile home or park into immediate cash.  We have
> investors who purchase these notes and give the sellers a lump sum of cash
> instead of them
> having to receive monthly payments over a long
> period of time.
>
> If you know of someone who is selling a mobile home or park, this program
> may help them sell it
> faster.  If you know of someone whom has sold a
> mobile home with seller financing and is reveiving payments, this may help
> them financially.
>
> Please feel free to contact me regarding this issue.
>
> Success always,
>
> Marc L. Lev, DCFS
> President
> Trans World Funding
> TWF20000@aol.com
>
> PS We pay top dollar for referrals!

------_=_NextPart_001_01BF7D12.AD61DDFE
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: [MOBILE-IP] We pay cash, now!




CAN WE NOT STOP THESE =
MASS E-MAILINGS ???????




IF NOT, PLEASE =
UNSUBSCRIBE ME FROM THIS LIST !




JAVIER E. =
GONZALEZ

Nortel =
Networks

( (33)(1) 64768249 =
(bureau)  à =
ESN =
578-8249

( (33)(6) 85744815 =
(mobile)  à =
ESN =
754-4815

( (33)(1) 64767840 =
(fax)  à =
ESN =
578-7840

+javigon@nortelnetworks.com



    

    -----Original Message-----

    From:   Marc Lev [SMTP:marclev@VISTO.COM]

    Sent:   Monday, February 21, 2000 10:42 PM

    To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

    Subject:       =
 [MOBILE-IP] We pay cash, now!

    


    Do you know someone who is currently =
trying to sell their mobile home or mobile home park?

    Do you know someone who is currently =
receiving

    payments from the sale of a mobile =
home or mobile home park?  If you answered yes to any of

    these questions we may be able to =
help.

    


    At Trans World Funding we are in the =
businesss of helping people convert payments from their

    mobile home or park into immediate =
cash.  We have

    investors who purchase these notes =
and give the sellers a lump sum of cash instead of them

    having to receive monthly payments =
over a long

    period of time.

    


    If you know of someone who is selling =
a mobile home or park, this program may help them sell it

    faster.  If you know of someone =
whom has sold a

    mobile home with seller financing and =
is reveiving payments, this may help them financially.

    


    Please feel free to contact me =
regarding this issue.

    


    Success always,

    


    Marc L. Lev, DCFS

    President

    Trans World Funding

    TWF20000@aol.com

    


    PS We pay top dollar for =
referrals!

    




------_=_NextPart_001_01BF7D12.AD61DDFE--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 22 06:49:12 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08781
	for ; Tue, 22 Feb 2000 06:49:12 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5817CCD0@standards.nortelnetworks.com>; Tue, 22 Feb 2000 6:45:02 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 57516 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Feb 2000 06:43:36
          -0500
Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.BF216F00@standards.nortelnetworks.com>; Tue, 22 Feb 2000 6:33:35
          -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id GAA08463; Tue, 22 Feb 2000 06:36:40
          -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200002221136.GAA08463@ietf.org>
Date:         Tue, 22 Feb 2000 06:36:40 -0500
Reply-To: Internet-Drafts@ietf.org
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
Comments:     RFC822 error:  Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject:      [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-regkey-01.txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF.

        Title           : Registration Keys for Route Optimization
        Author(s)       : C. Perkins, D. Johnson
        Filename        : draft-ietf-mobileip-regkey-01.txt
        Pages           : 26
        Date            : 21-Feb-00

Route optimization defines extensions to Mobile IP Registration
Requests that allow datagrams in flight when a mobile node moves,
and datagrams sent based on an out-of-date cached binding, to
be forwarded directly to the mobile node's new binding.  These
extensions for smooth handoff require a registration key to be
established between the mobile node and foreign agent.  This document
defines additional extensions to the registration requests to allow
for the establishment of single-use registration keys between a
mobile node and foreign agent.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-regkey-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-mobileip-regkey-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-ietf-mobileip-regkey-01.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
        access-type="mail-server";
        server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:     <20000221090026.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-regkey-01.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-mobileip-regkey-01.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <20000221090026.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 22 10:51:44 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13317
	for ; Tue, 22 Feb 2000 10:51:42 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.32A075C0@standards.nortelnetworks.com>; Tue, 22 Feb 2000 10:47:22 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 57697 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Feb 2000 10:46:55
          -0500
Received: from dirty.research.bell-labs.com (204.178.16.6) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.BCD4C770@standards.nortelnetworks.com>; Tue, 22 Feb 2000
          10:36:55 -0500
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Tue Feb 22
          10:39:42 EST 2000
Received: from blhothuelpc (thuelpc [135.180.240.114]) by
          bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id KAA29461 for
          ; Tue, 22 Feb 2000 10:39:41
          -0500 (EST)
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 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Message-ID:  <000501bf7d4a$ffd479b0$72f0b487@dnrc.belllabs.com>
Date:         Tue, 22 Feb 2000 10:39:26 -0500
Reply-To: Sandy Thuel 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Sandy Thuel 
Subject:      [MOBILE-IP] Registration latency on Cisco routers?
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <86256887.003C7AE8.00@mwgate02.mw.3com.com>
Content-Transfer-Encoding: 7bit

Hi,

Does anyone have measurements on the latency
for completing a Mobile IP registration on
a Home Agent implemented on a Cisco router?

Thanks,
Sandy


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 22 14:13:10 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19282
	for ; Tue, 22 Feb 2000 14:12:48 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2BAFF760@standards.nortelnetworks.com>; Tue, 22 Feb 2000 14:07:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 57874 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Feb 2000 14:06:24
          -0500
Received: from cheetah.cs.ucla.edu by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9A3D94A0@standards.nortelnetworks.com>; Tue, 22 Feb 2000 13:56:22
          -0500
Received: from localhost (sjlee@localhost) by cheetah.cs.ucla.edu
          (8.9.1/UCLACS-5.0) with ESMTP id KAA00885; Tue, 22 Feb 2000 10:57:17
          -0800 (PST)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-342241519-951245837=:21125"
Message-ID:  
Date:         Tue, 22 Feb 2000 10:57:17 -0800
Reply-To: SJ Lee 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: SJ Lee 
Subject:      [MOBILE-IP] Call for Papers - MobiHOC 2000
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---559023410-342241519-951245837=:21125
Content-Type: TEXT/PLAIN; charset=US-ASCII


[Please accept our apologies if you receive duplicate messages]

NOTE: The submission deadline has been changed!
=========================================================================


               Announcement and Call for Papers


                 THE FIRST ANNUAL WORKSHOP ON
             MOBILE AD HOC NETWORKING & COMPUTING

               in conjunction with Mobicom 2000

                        August 11, 2000
                  Boston, Massachusetts, USA

         http://www.ece.gatech.edu/~cktoh/workshop.html





SCOPE
=====

We are interested in work-in-progress, visionary papers, experimental
and systems-related papers. Papers should describe original, previously
unpublished, and not currently under review by another conference,
workshop, or journal. Topics of interest include, but are not limited to:

 - Ad Hoc Routing Protocols
 - Ad Hoc Multicasting Protocols
 - Ad Hoc Transport Issues
 - Service Discovery Protocols
 - Media Access Techniques
 - Low Power Algorithms and Protocols
 - Ad Hoc Mobile Applications
 - Sensor & Data Fusion Ad Hoc Networks
 - Quality of Service Issues
 - Ad Hoc Mobile Computing Platforms
 - Secure Ad Hoc Services

Please consult the program chairs if you are uncertain whether your paper
falls within the theme of this workshop.


SUBMISSIONS
===========

Postscript copies of your submissions should be sent to
C.-K. Toh (cktoh@ece.gatech.edu) and Nitin Vaidya (vaidya@cs.tamu.edu).
All papers will be reviewed for technical merit. Submissions should not
exceed 20 double-spaced pages (including text and figures).


IMPORTANT DATES
===============

Paper submission due:                  April 10th, 2000
Notification of acceptance:            May 15th, 2000
Camera ready version due:              June 1st, 2000


SPONSORSHIP
===========

    ACM SIGMOBILE and IEEE Communications Society


ORGANIZING COMMITTEE
====================

General Chair:
    Charles E. Perkins (Nokia Research Center)

Technical Co-Chairs:
    C.-K. Toh (Georgia Institute of Technology)
    Nitin H. Vaidya (Texas A&M University)

Advisory Committee:
    Leonard Kleinrock (UCLA/Nomadix)
    Victor O.K. Li (USC/Hong Kong University)

Local Arrangement Chair:
    Katia Obraczka (USC/ISI)

Publicity Chair:
    Sung-Ju Lee (University of California, Los Angeles)

Registration Chair:
    Elizabeth M. Royer (University of California, Santa Barbara)

Publication Co-Chairs:
    Stefano Basagni (University of Texas, Dallas)
    Violet R. Syrotiuk (University of Texas, Dallas)

Treasurer:
    Bruce Worthman (IEEE)

Steering Committee:
    Charles E. Perkins (Nokia Research Center)
    C.-K. Toh (Georgia Institute of Technology)
    Nitin H. Vaidya (Texas A&M University)

Technical Program Committee:
    Samir Das                     University of Cincinnati
    Deborah Estrin                USC/ISI
    J.J. Garcia-Luna-Aceves       University of California, Santa Cruz
    Mario Gerla                   University of California, Los Angeles
    Zygmunt Haas                  Cornell University
    Parviz Kermani                IBM Research
    Katia Obraczka                USC/ISI
    Stephen Pink                  University of Arizona
    Ram Ramanathan                BBN Technologies
    Adam Wolisz                   Technische Universitat Berlin



---559023410-342241519-951245837=:21125
Content-Type: APPLICATION/pdf; name="cfp.pdf"
Content-ID: 
Content-Description: 
Content-Disposition: attachment; filename="cfp.pdf"
Content-Transfer-Encoding: BASE64

JVBERi0xLjIKJcfsj6IKNCAwIG9iago8PC9MZW5ndGggNSAwIFIvRmlsdGVy
IC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO19DaxfVbXnfH90JvPxn0+mM87/
OQ4oQ/+cs/c+X68EXkv7sLXlqx3xKU8t7W1vP+69pb2XC0SxxkBAjNhAMSPw
MArkDVEjIUSTMfPwRQNRIwnJCORpIgkJEYMx70WNJi939vdea+19zv9/a/mf
v8hR2u579zlnrb3XXmvttX9rnWyUDzP1P/v3/oUNN264Rv533Ya8yYZVLbLh
woaiYfVImNYx12qykciyUv5A9Qyt+Q2LG7IRGx7ewLJcdqyGVcbzUVXJB+VN
U48yMSybpho1ub63ESMun51ligb9g2KUl+oHbFSLoW4XtWqLUQOb5agQw/0b
wk9y+dpC9qibUanbQr0jb6pqVDeyzbJRWek7ynxUF+onkr5a9hDCvJKzkShl
m0kSfFPeUDeN+pfvUFf1qGTqAcWIc9kumSUhH7Fc3yHKkeazVO/Ma16PeC7b
8saMgXYh38T1De4n8hVMPVI+QHJRNjlXP5ev4IrfspYjyMwdVTOqS/mTWv5G
US1HMJNPqKtyxNRIMQHbim9R6Xf4HqWmRj8hUyNVF2rI5TtKxY4eWz5quKRC
TkalxtbNX1bBhhzw3HS3P5FTYeauGjFmmMi4mbxKMZkXamr0HY1q1qOCycln
GZO8FIqiWk62+kHejJpa/aBUU6R/Uo2K3HQRzVC25RxoJppRodtcDblr71d3
MP3W0CPTTKknlFy2s1rNqn5H5agaNfonUqwV2WzUqEdWxUgNdF2pN8umlIZC
969zMxVlM1Jsyn61ekEp51CPc6MkU7bFyPSX064ns2jMOInMUFBo3vTU5cK3
tQQytZR8D/to/QpWG3GpczOVtREPKZuKaDV1SuLkMKkblGyXBWgX8lV6Vfif
SOnQPRhTsqllONcyaxdmzqx01IoNtbKU7Ko75ABmalkUchkotlippMa1NePc
LBzXQ8pwqTSEWoG5mgoxqtQ7mJwAM3lynYvc/CTTk1WNSmHWrnySnry88W19
h1ysDPSQi1K/k0v9UKq2UNMu23ao5uU9kgMt+VKOFzYcvFDrwBuHudaN7q/9
C8OtezdcvGWYD/ce3OBU5ib1D/mAkV7/Ulz2Lrzz77xr75EN2/cOrzkHunS9
lMhZqwIlf7dHSpRUzAYlUt8XgZK/1yMlUqGUgZK/3x8lXKqFPFDyD3qkhFVw
dv5hj5SIAs7OP+qREm0pPCX/uEdKpGkDq/if9EiJdC5mQ2KFtJQiUPJPzyEl
LVRcm0sbL10xZmnhoq6He6VBNX3VQ5TfVUj7Kx1tSdNeRZMkVhpZ2U35OdKJ
kV33HnjnvPqV7F800ueSv8xGXJpd+bjVDcr/kT6b6Tc3tM8IPVUf6TxllbTN
us8fu9cor0F1qZTTqn912N1dFVz/Slp+85sThoBcOgH6sVLUyyzLzS9PutuY
faIkr9b/XN0gvY1A3vLQ8uE7qi7h/Vv0r/UgyU72h4uLaFzMkOrfrJinscby
KofC/mYf5RFQJH0TORaWr2NDOrKGIuVOFqbLdfYt7u3a/9W/WaLDZe7jcMjs
YBX+jUfN46Teyi3RTeGfeBKxKh3v8Kt5/7hMuXZm5i27S8eHkEgz55UeeUyp
/f2IlxGbi0MyxU5yuH3J7jA5TG3BwoPdcxErN1ChQG87TCdI+XX+3mPt4u4l
0os6yzPINhT1LdGYNfo1wvz6QFIc5RPUdJku70YSWaHxRARmpV+PahDsG/Yn
32CIsMN6JXkUes8cHUS5cwi3LpOHmzG0a221g3Ios4ZevMzNeKI1fnT8dGaW
BuFvWiRiV4YBsi88NKTPlTMl7EpFM3H+cOoq24+RkQurt4Xc98ipAor7cjhq
cjcZ2FuiYi731uY3C0irQEaPo0HzNzhl56Qd6f1lOopCT3mdmJ2wyvDs4Gnp
0d3OMrkZkrZvpMf2+sU+SZGmKZDyz3qkRNmdQMk/75MSFeWZiTFhQoXrvKCc
6JMUMCT/os/tewkF9l/2SIlgcgsyG5Soraqn5F/1SEnB4dL5131S0kAdO+gz
zFPA2emTkiqXpnY2KCnh7PQpsTWHKvbf9ElJA2fn3/ZISSOQf9Kn2Wlmw+yo
uGQ9E5PDsxpOzr/rkZJcQIHtcRFzlkGz8+/7pARIyX/okQ7OoXPS5xLmvIaO
fa+kCAbXTp/zI2q4dv5jj5QUSFLO65OSGurYHvdd6pxjVlZPiQblP/VISYXU
fZ/GWEFnZoMSfQw1G4JSl9CR7dMaK1xKoGRjn5Q00PT85x7P5jRMbDZCfqxU
MqtgKIqU/9InJdqVdZS8rc+oUgXH5L/2G1XKAyXn8kTgLKJKzWzMTsGgnPxB
n5SUyvI4St7eZ1SJqTjoLMxOWcEx6XPtKORjoOS/9RvfKmZDxypM8Gzok1rA
2elTYhug69/RZygng3qtRylR4a1yJlYOz9DK+e99hrcKOCbn9xlUYlDDXtBn
LEflUHhKrn9nn6SAybn+XX0S0kA5ubDPoFI5G1JScLiG+1w5pYDe9P/ok5IG
etMX9Rk9QXqtT0rqHHoE55ISTcDwxKFWGFQh79eAuYMaVMSzikHkKstMnpO0
0HVVK+rmHXZQlBa5mAWY3bJDJ7HKPqiQ//Q4SYd3yrlFW4mRxS39IXmqcmD1
Ly6+OP1Ee98KQF7aH52kNxhMJoTZKcQpzwS6LWA4+SgPcKuThDD0sBF9FdNI
XvQq9JL9k9AG3iUZdZy6d/kpMu+yw3RoH7kXoGqjOZmUSv8qQ6V9VacAtIyI
AO/CDwYcHlhp58FLQV1mdcTDbZ4HQ4z98f6jVN4aPbUMjwsYUUvnEuUxQQkQ
VUDJKuUfQZCXIuED7LcIoOOBiWgmTsbDyXMP1Jxfipab9ORy1ipOPNAyT+/E
q5yw4cfNIh39XdWoDEv1WH8KVt08LLTlkRpsU4+ElJIET8ioP0JyqdB5oOTi
PikpAx1Zj3TkufzTU5L3SYkKrnlKWJ+UKJfeU8J7pISJ2RgRVs2GjHA2G6tX
qI2wp0T0SUkxAnNT9EhJgcak7JOSCtqbPikpC6hJ+lzBZS035Z6SqkdKqhzq
+V4pASNS90lHA72SQEk+PLxBFdBQRoApm6ReXQ+1/1wPT8y5mgBvTKqQKoFg
M4UUmWVuEm9wdmch9U/DckX3Fd4/tsmKQ7z7cT/noyK43IvkJuGz8ey2kDN0
G0w9VFSxkPRjvXGXGZkJS7D6d16rjcQq7ulSI1mdg9w1k1hkib+cEm9/7nZK
hObo3ehhhwmvbJSHXfC5xI50JH+BGc0yZrd5eEZ5KeWr9mlffpRRTGOe8ILy
ruyu3L/ATF0BGJXPbGoGNpJuSqIh4mHSnSSp8hq1y6TT/1zF0nHSTazvaCa2
8hRudxNlM/KMdJjtnt2BjoZ07oF42BddnZBeyTUS4O5RiCMTR9MyhDLd/H15
CZYRHBokeC6aU9vlYLhlozp0uWgayYdlWv5Q8mFecMWVksI603rlSsiyEcIo
sOCGXzEtWsYR6R00jpvM2KzqAfW5nfu8APAGJAzbd18bvbvG0+5uQtN+Mlo2
IOYxB2lCt+0jz0RCeKLrmftbnzk/jQmvJlE4eS2XTe4LBABWkMqZ208XJMpG
n1+kE17DZXWYmBOkfN2ToTmpztac+J5AX9TAnARRBsnvS0RZoNs2ETuF9MXE
JioIdlrD4IHqsFKRcEM1MxMmLGuUfQGZy0b1IXEakRE3fJZgxDdFVsrKxHuQ
9ShGRVD6oyklcVc+h9urfK9BVampGg7CXix2IKa5hAQfqZV5OHLeaCA7P22j
QdeW55iVKmFdccyypC+K1lpCz+JiD0TPoki1v00pWfubQ5O4fbGpCRTtS/sa
9gFUK6LFPIc0vNGI+fQ0fJ6cHbocVaWB2ttyOFJmYtxILRPfEPlTh5GsmtW3
aj1EUuIDi4l5hx2Ud2OFAN4+7aUL1YuXZGULSzhi740kGWibSJMjC099xSBv
BxLL3o7CLWMd+8htRi/tw5FEi8YPpdyZMit8ddK7wOvo5ngd8bT3pV7ZNKbc
CvazrfgJAfcdRuHaZ22xIygyvwCAQ3u+o8HaJK0t9L9XsQrbnRT0Gm6l/mer
rxE5SpPvUm+avolHCkWqd707COvjXJ4mTeDGtio5oXJBSi1nW6gyR2rmQOyX
MTC4Y+fFSSGal5PwoWgDkN4jwWo4kUpF6/mWDpUqJvRqvTwje7rgXp5XrlAP
KPjiDlWdhjQnyhUei+C78eCGLi9HKpMF93Zubvoi7KaMSIzCKxsh3hVNEjgh
n0OThP0VGj4zR88l0ltMtAYgwNTzEBKwqurA1F3ZFu8uVwghMFrvoesESWMc
QsqJ6zdZUADFAhaJwMWrKBnL8e51UQoQloG7zjCvPJDpYxexGujR5w4hGqGc
FD0jxrKu29aISW1NYgMCJmw0hC8G++0cj39y846G9aD3wFFUSngADFFyAIzV
HfQ9FoU7AYuH6a3Imz0Y+28k8IX3KSlxRLZgIsOfsC77OsSxP2+PaNOSO/u7
i1rY9KDFbpyD0qUDf2jjvAW/A6jrxUNEqGs9lBQLhhUQ79Jd8CAlir0Q+B94
Lpj4c3lUvs7grlcaPFdrCUxTIq7L8UwlxXSB6Bpn7A7QETDjjvdCcGRL73jd
3P/GzwqxKqDUwH2f76j2fVhpeKOClMZ+ch+yKw7759Y4OFyhAUjZqap4GUU5
T7REOYNZuyreYRPgKFGG9snvSer7wHcP+3OsAEK4qRnJ/R2YrF1k0JFCONzz
ninnlV55gdxZ8CFEpn4ppCuRZUkfgpxsne1m1Q8HClVjx8EIOI4B+rlUklgg
l0FAl2Gao5iSxbJWQwXGcc/SCjEUOdM1VbHfnzYUy3BY0GDSA180DZ1nXgl/
pABz269ZsnpXCLmic3hgEFulMX7eYeSulbSA8NR9teR9FxPljW59N3yoD1Tj
Df2ir2frt5VGHoV+Etbk9EEZWGX2QdGmDz7njQthEa0Akw1m4UhUDq0C3ETO
bNJLSq5IeqIJuIwkRM4lyytg6q0IHnNT7XWhtfUAbr8lirU4c30CyXYFqop7
ApKUL7bGx6hjjZx2HyVx0STE8wK51USTaFAAI5QwPV7cN6la3TYmiyLIyx2e
kZ0yp1yc52ZkugIaFgTli45FjaLyad82BxpmJnzbvJLSGwI4SaHpPtBYpof4
ai7MQ1axqOybldiVOpJEvF+FZhlFrm4gLjhajCcI6+hAeh8ZUHSnVwVO6tDK
uJUEoUhB9LZVikMC6Ikz4V2qLx/pUT/LANUkYIh1+pc4IN/hX6KQFAluAdVr
HT1IO/L0Er4choa8SX059e2t8vfIl8MAFnvrDvxQEJPeQ25DVnTH9D2g9OEI
r5uREHoWr47dBbC7dtmTIcIOzMAN8QACq3qMru4QK9xPb0RhusPEJUCLC8dY
AkwBgC3dmRoGHqNTwnWgurqxx/hoY2awx+kgLq/VdyK0ndxDGbXTvejANoxb
Rw8pvU1khfokzZ3JPQlapitJ2LAdeHpEh7DC3vnEJrYg/mUZBeRmwVZyrj4r
qYe+PDtjWU0gY12nOUmjmQWDCAP4v+VpTjDt0zzQsQ+mBzrB15qhA50Iioa8
F3q2ko85k4I529P1DlrsSpU7u7LuIxya0JLco5zFEU4xxTGaAMnCVb09g8em
IHdkotphlBPhITuBLGAPFEcnwdiWZINEIh4EwIU3VjCtHy9Z8NR2SMASXSfy
n8zvRWFAI2ntS6kB/bPOGYZ7RjONWtai2qVxbe23x+yA9TiRyiXHYXh7C5QZ
J2owmRxxA30ogkbPEXo6ztg8sAYc0c0HFZtwNHYj3ewMJfryXB8nYelkHek7
MDSR17Za1aVb6JjGWhWtUR4OaJ0FpAlMJZ+FqAMekqJUBzJ6SESbO7Ue873+
KPaY2EPrCw/Oyhaec+GQRW+aLXybp4Xnye3R90Xvaw/t+M1MInutH5cLLwih
v40O5nQrtmrQ644mphk3MTckbxPjbts3M4GOvHQnt70FOiZympAFXJ/TFH8u
cmKnCSvZ2Gnqgh2n0ZpvJdOtMyaTla4InovJwPScNs8c+Ds+b5unjuYORrcK
JIAJ78wpRxxiQwK6NDMuklzfDA6i1X7+IAclgPjPOrsQFDLfJ8mtKKi4Dw0K
MieHWh2CCcyaN14h23wWolaq7kRpxvUsj3gmdrPOMmr1W2CQacUBu1RSCUx2
iU2evRRXBgBuJLCQF1ENjARnWzzaOOsAKAkaPGsFPB+DD0V2YzwTs3DEzZpK
jsSk8M1YUdKjwfiT4a2wT7olhaeKHH6webktNMpDichrk1KPs6enfsDu+cbq
leWKPDDye9D4osqRLrcRx4FSLiZyZ7p3TcvI20Fe2QrO40CA5FnQoQVTVW71
2LVG/rsNxcR5HGe3VZ38mDyhNcFR+XQVZ+8Ta7VRXcuNl57XMdq6fRd9rFW2
e9fIEwHpmCqqNUFtkRM4ya5TDlD0+CQVPgSKWGmVuxNzM1PwiZW5ZA76pr4j
HqNYQTZtbKaQiF5/j7JG/5Nkms71UDojmTiea2g6GJbriHCAHEu61UyalGQR
EQLPSZUhLtGabIMytu6WYIk1EoLq7fjZYyaCI98o/1aPtlFWOxy94YCoDqZm
+/bt01cu6Z2x/gS8US4xqKZ9ZwxkYG4uguNL4SPhg01thhUhZX0UMLw6jbCG
AJOkSUgnbcPsKwizjZO2ITeprG0Cm8EhTYBmAnvb9CA65G8PGd0tmpTzkeBv
lc57q3Ren6XztBSKt0rndfmps186bzKFw4Srg/L7W+gMDMLvSaEzzXH9VqGz
WSt0xnIxaoq3Cp1NXugMjNhbhc7Gm/2uQmd6KMu3Cp29cVmiBbCnsxDcyht1
Hv47Uzg3SjNFdXMjZxEFcOPdQtpWQRPXWYclhRYl8G+/xZXPKFApDBeJaZFN
sO+yXhkHJoAcKvi3GH5J9TO3PtD3tBK7bLAHj2ujwV12ujaaw+D1sJNOh1by
uhpxlAiSiKE6dVX54zKwShODxHh0YJEF/ZOVVv8g/9iVO/HYBSubAF1zLXWS
c7IR7tUzyZnCusAB3UYWdPI8gAAQIDobAALqahbwlwGNWo5Kw+lZJrJMnPU5
3USWWPxoHgv2NItIGyTw6/GXNxJB+3XXyVuM1D4GLk65GE6rq55XtSQLroeO
JIe0nbiBxv7RwcD4fO3Iw0dWcb6//TX2LvNGKVwwXtuJl4g+PtldhywO8tJK
BVEkgqL8Y9QEPt+YlX178M6ZMv96/Frx4P0ClSbXSqjyEX2SXRbrTUsPAvCm
TktXhZreTCWGpqrD09BpSZID/ewkOgBIwIgMTj5qwhCk7psh3y1jhM90uA8D
ZsfU+w3wMVDrN2HvQUpT5xbQe4wB3Qs0sIsvxwnZu+DWyO/nnO6ACaZQXKOA
DamAgk+M8PdTCFjd/jKuYAQ08n4UQkXb5pvogI5RV7zAON4u1GW/Fqtiyo1W
QneWbvQkNQe6DJZbuS0Gq4ZqL367nZ+ZyWZSH8a0OKw3heYnUJIpZjNFJ58Y
ywA8UlDwvX0UaJ1ExM+tPYRCyPmWFR+Ru9pRu8mCMkmhBCKd1IARzKQ9X4cc
3Ljz4ulvR1C6dNiO5CM0JldQNdyeT0oyb+LhgEhrrLfKON8ncTLQfygEj5XJ
ztWDNTtlsNqU95gYSAKxPnkxj3WmIzj7hZRueyHxvpUuhp92F+uoulhwGKDp
W84WB58zV8rr97FYx0RFFHLGHUz1/a1jdIs7uPeQUjRIqKR6mXbEExU6cZoK
DPFM0U441VGmglZhbNLFZuFW8N1d+4B9UVwc7QV+p1BiQn9CSY9Nq1faqSYm
03SdgZw2xY+sx7H0FzVREvAbtzfp7/B3shOynI9K4wKloJRdPmHyC0DIA7qp
a4VHBVfkJp5bQD8Cnd46K0VYcxOCDSP2HspCCjYF4igJ19FrUrTKF0ikZHxu
biSm8VgnFAsQ1h68zRa9IvRBoxrlOgD5gcpEe46tbkjCKTtr7Ck7qhS+Ow0P
QBCQGFGqjB+ezo7vpiD/6bdAlWLFOPuo0pY01jwTrgrj712lZsD7W5Wap1ap
WY/6G31mP/kW9a1KzVMJjDaFBhC+qQKjb6pKzRM5onWpEFhigvow+PQpUbwA
nJTYITg+T29MFY0jgUv0hMVOxPnVrRSPAxwknTmc7+/cNTRvsxMcLJVTrGav
Nmtwpj7A1AIcbQkMJoCjts+WSA+0RcSRHuisUXprq/pYWpzy2Xi7cq3U4YBZ
lnEV14R+9fsZ6bkID9MFzsLCzFRUyvT3zM6awRgmuv4NW+cxdCtujn5+L8a+
eDqS2QiJxeJ0USp5qSeNEy3IkJ+Y61krjb7ZaqsNeODAJrAFbEZ2Jq5M6+9q
JMKop/MdXC5pIm/I7bgWI12D/LJEPSJXYS7KhELo8rRWnMG4csIjN+qjrFRF
VwE/Z55IFT+QXAsklbkK7nPO68Q5/7Q1S3vhB3W2CDhP1X2AH99qDdskChaH
pR7bFj5hPOLW9rhkn9lIwaWonehYt37dCX0wJTN95DWiMWGk66YOVUGFjBKu
CCgEtzUajEnSnlv8FHeAFRWfAty+0dLQDHOvRBBwgQldlKvQNT1gTS7bD+Wr
GCkIZtsBDo7je3JYGuCN1xW5IV0XHuMkSubY49II5SVUFDy4rKK0TlSuvqth
aXdOr3siMGWkJHnJSxuYzkhkqeU1SP/M+S/31VAczZugjbLSrKPY2KNgjY3a
otP0ZUoBqi1nBVlklniUJhMRn4xlsEKI6NaThKTEvjJD9JCPbdvBHnG7h7DM
HHCqpIDAd7TBPJx8glmCbqn5pd/+mFX0mEofO2IwAZhwhlLbrIoTONinXleV
3MVkw2raRFjioyQn6aBHeCKY8k2ADPus42SeUaruCfQiNMkuJc/fCNZGi3jU
XeLhslHd8as9/gcHAx4g4aowgiDuTXSNILZdsZrSvlEtkCzD571+lBE5h8GA
5QRyASgpovNSrxaUDPh3pTWCSA12kE+QSGI/NpUWzOPRm4sgmvuAZgbvPE5n
CvEyR8hVgV2a4uGnMZlcloCrTKOkHlT6kDuq9ZkYNVxr/Tk/Pkhb2fzqxDwn
Ri5RraFs1Z5oXQOVcJhKMhI8X7Ip81sVqB8z5Isskvcg+peJtMQV1ZHJGfHM
Jo8j+TmWtIIJJHskeYtJaUcy63W6E7FY5k+ip6DCp7eQm4MyXrcJImgHwXwA
qoqiD17J1NGncKBaRlpmE5EWr5xPxPQAUZmjs+Rn/hiZFZTduS8SC5DzlRgB
eog61giTqYKqZgrqiZQDaldPSe3knX9AJyjEcTVhojzn5LdoV/nPRhTAIjhO
hngJ6HGXus8d7c4vedKAgV6JRAAY/WPogWj+D0zbYU8pbRXWMa76gUnGt8MN
hXKOpGB/NDUk0gy0c/zxZuqF30DJzEZVZl19nKA6jOfSRCrwSVirg9llU2Iv
5lAsBSRq3uFjYheHaBfsiWVxMIXhEbpoCBZQFeuMwC+gMPIykauEDHpYVzcl
JL+FYeTU49FeIaIVnhJ7k7xtZeEdSNXl4QnwWuJ2onOsaDaOr0CRNOsqyCQa
ByCHx2IpB5ukw4T5MI0nwZg7kzpPF1oYK2xNghWBMoK4uYh6G4li9etyNJxa
63KrFxODTsDjfrM4ykrvJQG339dp94OQgXPL/WDUyPdhyuSmLBJ8FM2ko1pE
ZQK6wwFg0nksEkG3ee5umQGjIJpmJBptFFYWI7OQlyFsQ0ZWB6X0v0klkBPD
OELjQkAFdvMj45JSMnFFsG4Pq/EyJXJb3NOLx+oQruqYrBtaRB4slluSjjsS
/H1E8OGaWiKSBHyLZWBsgADN09Hs9IXItAC/qGUp6ShkES8oAJxfWiQvURLl
z4cOTmBNuvZz3V46Xt6xAS0I9XigspgQFi3ui6LYFZrwKGzVHrMi1QOBTaTw
CLDdQfedJOuCyEBiO42trNctxyG76IZkNChP8wSlCT3+RDq2imLaR6jmo+5Y
xH1CewebkRpS0SYWNHQU+1W4YHDwq/x9UwK5gxg7y/VGJdbRdTXKjOO+Fw0C
+h5myt06HvMefYHFrb3gjexv30IhvXAy6XXnTQxicZt3OShc/3MVT/zBCcTp
dyFUj+slp9wbtFtaHh6OR7AZs2OAkzRuu0DHaiW9W0htB6M61DmLhijafTgz
SrfJis7KGmNkPJYnDYONCf22HwY59Z+UVRFb5tSkQSM9PBYFGo0fwdSjdZ+F
w0Qk89xP22SBsrM/q4FORJ5HZW2gIghS9ofnUNWpJ7Souy1SpZnDRP1TRY7+
fEA+FGWjtFszBZVbCOIQl244AwaCFVrcpSSNmM+bm27kHU9xIEzj8z1hW5Ly
UsGMvgNdJ3NWYN/thcbcWhCh8R5jwCAi+dnv5NLr+RCAgeXOgRclBP6GeKsz
kAg4LIewDKpnOMGG1X0NAjvBaAVdTfQNekWHE0L1R9IOhRiJV69LRAOi+yAu
AASbu5ezS+gFcQbiYfa61otSfQ589la7qN23eWduvQfSZm3FoxMmtOJ3+1c0
cPuzMpHoOsqD65KIsuQTu7J+cUUfWg6BSOA9JWKRwGl7S/ukp5CUE2iJcvaq
enSe1QyqHnOUPnNqx5A1YyrH75JjleN2x94PQRvkE0TUk/WuUzG7SFWwRLTG
he2PkwdFoZpJDqHA3gPXlRhSDjMQD99BCPWn4ScDoepriN7zcrr4bI8Be13L
PB/ls7iWGVfT2sNypnaFrmZP2B467cbItJ+u0zUUxTQTKLJE+eUkqCKK2oId
PLI6HjfajubcRslI5iO0u8XIUYhOtSPFsHQTpR3FNsbDFFowa/b+W97U3sLv
xl4lV4+dQSVjIlK9KBns8lMl4wnbTe16g7DZwHKCiPKBdekRZQddzRwM1PLB
vga6I8hl2ULpq9RnoLs3DS0nTKTERjJsDpb+yZNJTwZgj/bS96Aah3MReeDh
LYtwnkIaAaKhA7ByoyU0XuwJ14EWjJ9d1yErRrMYb+RN7b5o1sdWoGtdA9J2
ge1vRZzblvN3tIpXk2YNHcNfnd5h++MkjLuyG4lVKpFoua8DvpDcyiBet5DF
FA6FjwH/yIUnDqH1tZ4dQYyXI5nZLWESQsA8fRY63lloV1seI30yeUyD0kjx
BiqEP4ASWjyQnnqufbguj2b8EXDCo2l1Z1p9mTevI8Mbbk4MZk3l1YX7Ts2s
RT8AaTMWARkXdPWUosCrQx4RYb8hluoq3jPFisbh2lLY3LDI5to8MedrbQFj
4n52HFNakMgKoZTUKwaUkjwmAh0LGnBskBgD/u3QLGO/CVsqGjMCJ8j964Ja
EjOLukCV3Be96IIxoRNA2R4qSXHsBEBIYYXeOIpI7AO4j8db7hZIFoCcReCA
EERE3sv5aVUF9h/bKJPBwaFLwq+VCNiAvnQIU6SSTgBC6/8x8f/g0REGj+f4
zAZqBxTBoSmspd0zeoRjy5hwrKjOkQ2AaMJJ7QAMtLREwoAdcF/e9do5VTEK
5HEVBEECmUDZxKkk3nZndj2ASBRfx0mmvWrLchZPjHipBnom3SZP2TXE3cEf
nCAY3rb8SQzWpO4I8gCWU2s8uCK3DBNwxLyxcESw0g8mFRT6+OhEEXQIK2wL
/KKS8zH6nUH/BR1d5dB36QyfUwAcBemA+Pm4AyRLNPoybksgCKOuZzQQxIti
JqEoXCiA1GzuigJpb+2KJtoVATwq3hXJXnnrUrwc7ouqCFHtM6nD9mjB34ES
qH0iGwCjAvxtHGbilE/M4W8Jc7FPvpq+F22fziILW2B+vJJDrudBRLvXbktE
X8dROJC4DvQ1jZzVsMBV/8pNqC+YzaBy43JfxGZymxcom8DAQ92EzFp7WmJ3
rZiUzsA5B2ltisC0Eytlun3o2KWgvcP6dymJfd563KiuNP9oL5ECIpAMwnFA
BJBv23G456d2SrUKUzJM0oR41khmc/gxDCcnaBsd2ShgmKJIGJDrNGSSlAVI
CzEnhi+q/SVaDzDJ2U9izzA+spJFUZX1oVBBJAWJzPIwHLdkUe5OlLiJXPMC
D0naCxifxg+WwPiROhTv0DEADWwwEvVcvRXMRoVARW2sECwkpxc5HPsJdWCK
56ON4fjqCLh+hGcMzdLkFUHoO7LolMvFkVJbyOAjHSRzavaOMOu76zjQPtZn
w1uJbck77sySaktl686SahHGVBGFSWp3TZaX21nMBRTnIBV38KZ40kBCuqId
Sv/srGhnyVtNRzgmytiGwbfA8DnJAY+HsOciA6wpR3WmLdNE0h/VC2mJfjsd
eiJabyDcnS6fhL5EEsnH+uoPjccS4I0eIu9gJMWcmNz2cBg9cwaaDUXGTrY5
jkCzrdJXoQKNNKMxzsuA1GOF3hbPSqAfnR+yuP5Ex8mMLpjEIWEpVnh0MQr8
CliYJcefccDnEK52fEyaPzEN1egiDZzY/aesT1gNB5ODZ2zQGExEAikCFDkF
0KpPnllxQ99RbxU3MLZv3DkCLKxAi1UGnzbHDJ+LwgrTKBgwttwwq/KRSdvY
g+21QtngEkb2swJIU/iQho2UgQyJcIYOToVIfNjfF31FIlpFDrCDvle8iN+B
FOXsbLSYqBwy5Go0xmibtURWS2Jb0pZhRu5ECu7c1l9LBfpAEaz2fRDaV09Q
pgmceKRqgLS8MC5X0b5pTakljLttLQFAIIxp9crOmXN/lu4NiXDHiyOLt7lR
HBttxhaoRgeFCk5SEa3jj6VHwrmOXTryVfxLhyfx4MKCjPTZEUaiDabcVtln
gqpynQXOEuUJia9Bwh7eNMX2MLGsi6KlLgSqnkqB3VlrKbXlWPybaPLeaPtV
pY+aqIblQkpb7T+KBhcl8hVaK32/B5ppy/QqPrkcTeVrERXKnUBnr57pslT4
GsD0XrCxFHFoh1epvcyUPp2Jd3ouUOF5qYtRaScQnGBG587og7HXv/Mckm7o
OHHorD9s0DDFE+CgI2Z1NNIvNJHKKUmgrVygq9DVWIlO/iOqVPIshE/JXjHO
/IjDLDh+zcvovhHdC8TxwvaI3LhzuI5afV0JNh3Rwbi45Yi+C8lWByTvQLfZ
mPKpewqUYkWSN7n6piMQyevflQwHIpBKFyLfGeUD09aBrfgCkZdqgwKU4JVE
wJDijwKxSMCW28zCYapB4/q80zQIKQ0q9f1ITiEYiOnbKVLaylEm5MpCU/Re
r+FQXDRWDYn6yOm47QH/RFdvs92lnNJnBpOrlDosTH3dyizN3oxZ2Ot74oSe
sEDcTbFG71Tn3e7+gfa5uSXxoqgkY1brb6YSTf9HVJ/nqicwEK3HsM48oD3Q
iDCGrEPiDIF82hsgbeBJFxF8jFDmLiwISei2hvH+OKwEsl/sWeI5L9VnUaHE
vwsOPvpwl/8qACjPCOqNxol0DoQZVdIGH9IIk3SMbM/Q9u6ND/wnP06SPmYU
cRhincF4UkS8HXs20ZDBXWD8VffWTW0V/EZ/lu9GA2xqO+r7kpO/WO5TKFgc
gh67kuLshFV6XyI5FBrjqOQi5tKH6ymiLM5IRIft+CMb003bb9tqZ40DdCaK
pXY67UnMUyLtnMafRMtcxnCc1qQsLOZpNMKxYXziot0ZgT/9M6b+KzjISXzy
uS0DN3wY2dkACodCq25PcHsgENLH77wVwvE7SiJCIE5S78RHpNAXgBK5NMlP
e8U1ndPxue7YHyBqOuE/iDL9LcJ/6/q+AfgKlE9MHibFEx0itHyM4+Yu0zYG
yJauMes/NQxZtsoQcc2yIXb7zEQ1IIe75eRsBU8ToHiib2oQrUQ+hQG/DxXG
adP01awPpWM1K/f0DluKYvXrwSm0zun+tjkFx3edopx4d8v3pewbD9FJ6awc
hiuhpHAJJCcFuEJmO4X28olDSbiTxIHxc1o6G6x2Wj67I28HG4J1AOgxNiGG
P+BVQb/56dRG9FG+Cc/zouASFsWJCj0grwkVejhIJ8E4T8lvCoVZONS2KSLg
amzCz/Zrq1ivgD0l3fG4zzJPQd14BEA4JqeqpsptobcdzsjH/IUNLNISxwO8
2zwajqQ/30dPoigZghaOz/f9Y5RaKO1RZuIwOYOypwObVqtvA5tv8JnTfejh
NJtVxKiFOcwr+vLy7KANclHJ6YSw7vARPegqUE0Nzcq5grKNP4MG+zlg2+B3
B4B7lsiygoVp1n86jeDAkUXAHmpS8y4O0aFArLY8cBy78VSiguMMjmrPZZn9
NpmqchwPbMiuT7AgVFUN0/j8MCPImavF4fYJaKlGWyR3zoowVoeP0a2PNWcA
bZtnVN/mTC95sooDJAYEmSjOEEnlRfTlaIPFHAd4SdnfZvRW++Nsysqh46Q8
58rhzf15SSekLlUdKTpIQTk4ByPnixykpAMx56Siis3gJoVVurO4a10oz9I+
+REZcavHcTEJoj3ai7Rjm8YHoRPnoRO4t4CpSb5924N68rhoqp6UVBe1ryMJ
mKmjXFC4fD1fZB+drqWK4C95kVJBBDAbp8YnlE9QkG8G5dN+6JXLyapN6PBy
Io0oDNz9ZdMoSEe+zN0dbofFQFlhi4GiOOy+ljg1yENMfRCVfoeuMykuWmUk
RJJyNTo/WBpVFsZ4snhg1vN5+Tbc6USgvim5TT3ppIQb7lSSEnZz6r2TKgMc
s10kCze4YWRQ5oZ5pL90J1V4DvvUwTojkxHbZf91v7RSYS1K5aw00TR3u214
96Y0BZphAB0m/2CYOY3BBJw5+gpxtMrJrtipjWlvElMOvR2HiqmHFd6hR4BJ
d6h6Od3DhbgcAkLvTtfpZH6Y9kRiCeVlh/ttJJ1XEAKQk7qb3tZANX6VmwKn
9NC9WylB6DuEO+iClY8R+p+rgbZd29PZq6WH33VFvpxXdiAd0gTZFxMRs327
o4bAJjk4/oE1QhIo0fTnWRYWoKaW3I2Pb1KI8TpOZKdQWhEIMayy2FJ9AESW
93S8JHauo5PJNOmpPIU4MB7ML839hLHs4EdGX4qulFEaVhVTA7qwQWSl1jam
fcy3mdQbx3xv09LKRgqSigBoHbKpYJm8y/Qq1EMkR4VUQMo2suG2pQ3+tbyp
9GultlGvzUUm9Gt1+1hol7rleuuWea1/p6LTdFBvrLh949YdGy6+fM/w4isu
vm6YX/xu+d/Wqy8f1ht2bBu+umH7DkgJc2/SdDThTaGVjSwdtq9pG0qs5EtS
FE26jyZFDVxECsek/PSFlzAxdRFeqMhRWEZAgGsXWvW73oVX/Rt4jsdF9dDE
5IlxKTAxP3vxpZdeIORk7nWKGCsq5uWuJWo7NravbRtyRIbHps4MOUWZGJsK
k/OaJCciqOLhpZqkGr40tLW0+t5BWosCj4/qoQgSTWJ8GiI3zz1vLkxS6V+p
COLglb7FSztGtq9tG5JKgcdI9jEkicQY5USWX3c0Pf//CFV5eLOiS2TwzaHN
DF22Nwvrq8EDVdolzavUAiNi/RNJ1XP6v+eefw7TVZTuvZqqIrzXt6zq8X1t
29BV13i0ZB9DF0uNFpHwV5773vee++535f+f/e73nvs+pkw0UBFKS8rg20M7
07S53lnQAxnHQ6a6IC2ISCPS/sq3n0HXs4Q44V6uSavCy30rt6rT9bVtS5xu
gXGTnQxxWWrcqOQT4p559tuYPA5IUASWiATfzgyBtncGyGNEn3Orz/OUPmc5
Hbtno+tbhEDmCNDkNYGA0HJK3vVFSp4TLc+tls9SWp6R9fCjp/8ydWESWRHI
UERWJSTDtcvGqH7T27QsiQXR/czq/iyl+xlZGq9+4+nkRSaaZY4IRWKdByJ8
q3YGwfatoUHIS2IRmLEIZZOyCIwukhYin376m5jMnAdSNKE1JCW0jZlwvYOZ
yCtiJ3JjJ8o6ZScYWS4/bCXz6W9+AxOaeUIUmQ0gxLcqZzxs3woaj7wm1iOr
LaEp68HJwnnpya91XYTUPJAjiS2yDJIT2saiuN7BokjnFY9pZkxKWaVMCidL
6OUnOkn9+lOIWNaUjhhNahGI8a3SKnbXt4RmhmXYzqhOhtiUneFkMf2wm1h5
PYHJrZtAkiI4Z5Ck0NYK3/cOtocxbHt0F0VumbI9nCyrF5948il/PfnEV/UF
f6Z+TAgWjiBNbhUI8q3CKn/Xt4D2iHFsj1QnQ3DKHnGywH70+Jft9ZXHH3v0
2Zdf++nrr7/+8x9//8nHH/vSl/1FSK4AWYpohsjybWGItr0FIFlgG6W7KJKL
lI0SZKn9lSPsS1/4xi/X8PX8Vx/7imeIEM0cUZrkJhAVWtZA+L7QbrEC2y3V
SRMtUnZLkEX3wuNf0deXH/rJWup64s+/Yq8vY7LLIpCmCOclJM23uTYcrjcP
tkwVn0BjXRaW7JQtE2T5Pf/5R/X1wKuWzr99fHmOV/nc/Jm/tD/50hdNl8e+
SAjPHGGKbJEHwnyLWSPi+jJo31iN7ZvqpAnnKfsmyEL88Z9poh7+tiHy6wsD
eNUP6Z++/vlHDOmPYNILHsjTxNeQvNDWxsX3Bhv5Bts83UWRzlI2T5Al+ZOH
NFGf+1tN4wcG8XWd/s2Tdm6IwATiFOmQON/KraFxfXNoB3mG7aDqZIhP2cGC
RgQ08V98WFO4nKBdXfvUL199UFP/yFcJ+XkgUTFgRcOR7NvMMGB7B9vIc2wb
dRdFfp6yjQVZpq/e/+ADDzxw/1cVgY+/o4X8wWDj/5W//+WnVd8HHiAM2AWZ
G3tpF6Qh17UyZy9t3wzaS86IveTWXuYpe1lQ5/OzD8rrs99RDHyklX51Lagu
dzykuj/wJcyCVYeZs6FWHTqyfdvYUNc72FAuiA1l1oZmKRtaVNEcyOtzX1L0
7e1kQS5k2efXp9JMCEekZqEKRLpW0Ti7avq6tmWiIHaVWbuapexqQRbxK3ef
UddpxcQYHtSl1sMn9B1niBrNAamKkRqR6tu1YcT2rgEbJbG1ubG1RZOytSXd
D95+Wl13KTa2T8DHdtnv9D36ntNfIIwwR6hmowmEhpazv64vtL+8IvY3N/a3
qFP2t6QL+w5N0z0/kgR+fAJGBoMjsuf+M4aVhzErxu015ClmjNvryXftythk
27sCocWG2OSssKykbHJJQy933qtouveMJPAbE7EyGHxD9l0wvJwmxs5sNhR5
C2pPmQdifat0dtr2LXFgktjpzNjpokrZ6ZLuQ0/ddae6Pq4k7LwJuXmb7Dt/
j77vzjseQuzkZqtnSNQM1ZDk0NYG0fcOtlvk2HbrLoqdMmW7S7LsX/7EXeZ6
UJK4Zzjh9Tali3febe688wHMUO0JVuzkgGDfKqxxdH0LaM8Fw/ZcdTIMpex5
RRWAY+ijksRfDfJJr8FP19Y232HvvZPMkQlvGDIVUya84dnwbWaYsr2DjVfp
+GiOamPjiyJl4yuiCl65zUjOnXd9SvJ02WWXTHptXpb+72WftHff8SBmygSV
FJmapSIQ7VvCGlDXV0C7LwS2+6qTYSpl9yuiFF5evM1eK2olvePSzusy+T/9
t/prKDdRb7/V3f7RT2G2TEjPkKoYMyE9z4pva8PqewdfQJTYF9BdFFsi5QtU
RD28vHTKESYHf+1TO3ft2q2uXebavWvr1i07VGvb1q1bd1+x7QOXqp9uufSy
K3bt2ikV5Ce2f9wzdpowJhzhmq0qEO5b3BpZ15dD/0BU2D9QnQxjKf+gov7B
iY+dstfHlBhWO3ddeuk11+zavHnXTnnt2Hrqhedf/Ey1Y+fWJ59//q8uvFe6
Oe+74pIPvbL2iweqXbuulN7n224/5a8zmLUCkK+YE4h832aGOdubAdZq7DPo
Loo1nvIZaroFOLrqr5Wn5S5r93u3vKD3A3/9vj17915z1G4c91+7+2X51wO6
Mfec+eG2vVuUx7QMHkHmzRweKHI1a00gPrSsIfZ9oR8hGuxHqE6aOZbyI2oa
PFtYCdeRX8uN+57dfhM/v3fPrb5xw64fR7v8R6+58utra9dfC56xfAdmz5zc
GJIVg+bkxrPk2rk20K53HnyLIse+he6i2Uv5FjVVI5C9FeUC3fkBOYVr337s
L+SfP7puj45V7HtS/vnyLjV7a5+de0b99bNLt8o/X9v6wfvX1h7Ob4YMfoYw
mDkGFHvmuMyy41qZNdaubwb9DTMUYP6E9TfylL9RU3/jKGRwRU3X8vXyj6cG
521SjLz9EfnH7kG9+U/k36NX5B+rg/PPM1589Rn514X7j6+t/XDjrfApy0RE
zVmlIVszWUM2Qtv4IK43OFrlxAfh1gfJUj5ITVTLj/ceQdcpSfWHj951/d7z
Rwt6mandxuOD+SNHj/yf0w9vVpGdjVct6UE4b/Go2rkPFuYkj4Oj6DHzH8NM
Ms+EYrECTLiWWWnHfF/XtkwK4pcw65dkKb+kIUrmh+8/iq4j9yklsrC446OP
vGLWmuLyQ9sW1C8v2VIpWR3sP6q4vPGyBcOl4vlXg4P4QfOnCJt5YEUxas7m
PWuuXTvTbvvX0LQXhfdXcs2pcVeEgVpQTpXGYQDY8L4jB9E195gk/siyZvKL
N9xqWb1qXgri6vz8/EE1oYObV+blXysfXll5RDdVa/Cn+EHzH3rs+Q8eJex/
XqmuxdWgs9TD93zg+JK8brzxiBrcwYmlD6uHf2Bp6Qu6uU/6RXQcjx65KyUv
ZmCCxPiB8+0MSkydpeTFLAorL6JOORJUXn521b4PoeuE2hF9Uq/vwfCLls/7
5qTBUSP7nJaXj6wqW7Wyf3X1Ud2UbvqPBu/Fz3nfn6XWviI8rHzLlGs5ZI7r
W0G3Aqx9syzs2hd1yq2ga//nV30YUXezpPtjn1Nqa/NHP6p5UhHz93781MeU
Vrj2B+onnzilxmJl/tSpx1XzdulAvjJ4H2bykZQOFw5yZPW2Z8y1S6jFRZnU
4dZIGR0ukqAjqsP/ei9k8sPvl1Tfo7yIzTffrAMVAx11+cwptch/ozYiMY/3
yKUzuB6y+CcPp+ywKKEVtgz5lnMzXF/oZgA7bM2UscMiCWaidvgX1+wB12WS
5m/dAfyIwadf9P++auPP9E/0Du3EjXfdpYKXg7u/v7Z2egAfctWDKT9KOHyU
9Z08U65tIEquN8BHAT/KOonMMph0NIgf9asr9wbSdkjJ/NknPqvZ+cUlygB/
+vY/t+x9aPCR1w1/t6kZlPw9If8+73b5x86N14VnXPm5lA8sDN7KeryWGddy
UCfXF+Otgg9s3UTjA4sk4Ir6wH+z872BNOkSrd115vjCrbddOti4et7gHbfd
d3rLg89993u3DwbHz5weDAYb/9d9Z+6Wf9983333vG8wyO9RHL8jcHflo6m9
i3DYLbtf8Qz5tgC7FwGwW2DvYjdlZu8ikuAtunf5+VY/d3ulo7B2+vSZT89v
v+bE/WfkNuvj957+3MIF51+wac/p+06flru3j957+vS9H7ntI586ffr0J2+7
Ta3KFweVZ23XmdR+UxgMmN1dWkZcyyGvXF+EAQP7TbstayxryXAHUS2vj3bt
sFcuOXv9/gcffOjhh3V8WV8PfeHzn//8ww88mLru/4W0nINt7v7L7knFBwT3
QY8CEh/aDEQIBICRgfiAmTMbHxBJHBmND/w832np2vY1pRwfmvxS2nSw0Y3L
1s+lYjmCMxDJsUy4lsN9ub4IhQZiOTY8ZZ2jJAyNxnJev8yStVNFnp99+AuT
Xg9/S6rUwQWWq233pmJuwgHYbJzNM+LbGYi6CQBgAzE3G6CyvkoSwEZjbj/f
vHWbvjZLiVp74NFJL+3UDuzNl9ydiosKA3uzUVDLgGs5jJnri2BvIC5q5snG
RUUS9kbjor/OL9msrkvUqvrBY49Pdj2qLNt5Gy/Vt/JPpeLWwgHlbKzaM+Ha
GYxcCwCUA3FrG4S3PkgSKEfj1r+4wFC1We7n1776lckuZZk3Dwp9X/5Q6kxB
ZPBEwRLvW+54xPVFxyMN9jfcmYJIwuromcJrIxMGrZTJfeyJSS5loP9isPFS
dVt+d+qsRzgAnj3f8QzYNjdoN9ubAwAeOOuxh1bWt0gC8OhZz08Ho03q+lPF
zJNfH3/9b9XxvIG+6W2rqfM3bmB69rTNEu5aDgvn+iKYHjh/s8dWxo/gSZge
PX973bAy/KYk8JWnxjLyZcXIFYO36Xs+nToP5Q7IZ89APfG+LcCJKAdAPnAe
ag91jc/Ak0A+eh762lAzojZZay9+45vd11Nqk3Lz4DzNxidTZ9PcwPzsSbQl
2rUcjs71RTA/cDZtj3Uby0YS3kCR9O+4UF2ajd881YpNVNdTqo/08C6Q/d/+
kRRGgHsAoMEFeMJ9mwGUAAcAQIARMHNhMQI8CQCkGIFfbTTHaNq//vYzMeLX
Xs88u6bnwVyEBYO84BYWaFAZlmDX8rBA2xfBAgFOw8JMcstCEuZAlvgvB4CF
V59+JnU9+8zTyn6sXWn73p/CyXAPFDTYGE+0b2cAKcMBUBDgZCzQxNh4ngQK
RjgZOwcm7P3Sd3zygb+ee1bHV9eus+TfnsIocQsbhOT5locN2r4YNthge+4w
SjwJG6QYpVctUTeaTdrLz34Hkf697/5U//wnb7f9jqawYdwDCK2AeAChbQuI
DuMQQFgT222xYTwNIKQAE0vUhT+ye8xXX3r+Bz944YUXfvD8iy/9jf2ZRzss
p/B4XEA0niXUt5yddn0RjLAidtri8XgaRlhQe2CvSx9dS1/zG10XfLBgMY3c
AwmtcvRAQtu2QELbGwIJC2KTLf6Rp4GEFH/hJGEwOBMT/dq2cLi/ksKacgsj
tGbJwghty8MIbV8MIxTE/lqsKU/DCMkyfS2QLQf0V4Dkr40gIuHGFKaXewBh
jggLbWNrXW+YCUhsrcX08iSAkGJ6f0PgElUhr+oC8tOPp3DT3MIGrUtmYYO2
5WGDti+CDQLctIUhW7uahA1S3PQrg/EXjidbrDn3QEHjFHsifdvYUNc72FCA
SzdjbHHpPAkUpLj08QQfSWH+uYUFmu2IJc61HL7O9UWwQID5t+kJ1l4mYYEU
8//qOomtA0Ehm8IT6Nsmgcv1BglcNbaNLpeCJwGANJfiZ52kYn/QZpxwA/Oz
2SiWMNtiDitn+zIE8wP5KWZcbX4KT8L8aH7KK8N2QrEiszk8zAH5bI6PJ861
a5jxwwCQD+T72KQkY/NYEshH831ePb+NzIVU7hSrYeaUJcq3XHqX64vSuwps
31zuFEvC9GjuFFVd7sLOJzeBQOYAeDbvzBPm2gbF5noDAB7IQbNJcswSmUzw
ojmZSRI/TUisHAkhi88S5FoOk+b6IlgdyOOzaXLGbrEkrI7m8f14/EQLQETI
hPRE+bZJ7HK9QWJXjm2Uy4NkSaBclAcZkXcwlUPKDOzNZoxaYlzL4cVcXwR7
AzmkNk2zseQlk4ErGkLAF/albDotcwA2m27rCfJtk8DlegfbU2PT41JvWRK/
FqXeQp+Ergxz8sYKBlKVLR2u5aBbri9CoVXEythkZZYEodFk5ZeBkjlK6KrD
u0Nyt6fFt41Fcb2DRSmJQbGp3SyJIqOp3b/yVOHgjs1qZwYDZjPeLQ2u5UBT
ri/CgBXEdtgceJaEgDVpVx67NTb3nznslq0N4MlwbQN4cr0hdotYCVsngCWh
WxRtpwm6OVVHgTFYRcG+3recQXB9UWCS2ANbR4El4VYJL+uDqRoTzOGjbF0J
T4JrG0CR6w3wUTnR/LbGBEvCo6LAItqEi4yrZ1SVxTTI/QhzrWO2ZaTJ9YQS
nbMsVPvQ60D2snnGNaj2IUK1D1Nd6MShDfnwsHS4C6VF1Fl7meXSQR3p4jpF
Jt9xYm7DwQvlLf8fdSxFpWVuZHN0cmVhbQplbmRvYmoKNSAwIG9iagoxNjIz
OAplbmRvYmoKMyAwIG9iago8PAovVHlwZSAvUGFnZQovTWVkaWFCb3ggWzAg
MCA2MTIgNzkyXQovUGFyZW50IDIgMCBSCi9SZXNvdXJjZXMgPDwgL1Byb2NT
ZXQgWy9QREYgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgL1RleHRdCi9YT2Jq
ZWN0PDwvUjc0Cjc0IDAgUi9SNzIKNzIgMCBSPj4KL0ZvbnQgPDwKL1I3MSA3
MSAwIFIKL1I2OSA2OSAwIFIKL1I2OCA2OCAwIFIKL1I2NyA2NyAwIFIKL1I1
NCA1NCAwIFIKL1IxOCAxOCAwIFIKL0EgNyAwIFIKPj4KPj4KL0NvbnRlbnRz
IDQgMCBSCj4+CmVuZG9iago3MSAwIG9iago8PC9UeXBlL0ZvbnQvTmFtZS9S
NzEvU3VidHlwZS9UeXBlMS9CYXNlRm9udC9IZWx2ZXRpY2EtQm9sZD4+CmVu
ZG9iago2OSAwIG9iago8PC9UeXBlL0ZvbnQvTmFtZS9SNjkvU3VidHlwZS9U
eXBlMS9CYXNlRm9udC9UaW1lcy1Cb2xkSXRhbGljPj4KZW5kb2JqCjY4IDAg
b2JqCjw8L1R5cGUvRm9udC9OYW1lL1I2OC9TdWJ0eXBlL1R5cGUxL0Jhc2VG
b250L1RpbWVzLUl0YWxpYz4+CmVuZG9iago2NyAwIG9iago8PC9UeXBlL0Zv
bnQvTmFtZS9SNjcvU3VidHlwZS9UeXBlMS9CYXNlRm9udC9UaW1lcy1Cb2xk
Pj4KZW5kb2JqCjU0IDAgb2JqCjw8L1R5cGUvRm9udC9OYW1lL1I1NC9TdWJ0
eXBlL1R5cGUxL0Jhc2VGb250L0hlbHZldGljYT4+CmVuZG9iagoxOCAwIG9i
ago8PC9UeXBlL0ZvbnQvTmFtZS9SMTgvU3VidHlwZS9UeXBlMS9CYXNlRm9u
dC9UaW1lcy1Sb21hbj4+CmVuZG9iago3IDAgb2JqCjw8L1R5cGUvRm9udC9O
YW1lL0EvU3VidHlwZS9UeXBlMy9FbmNvZGluZyA2IDAgUi9GaXJzdENoYXIg
MC9MYXN0Q2hhciA1Ny9DaGFyUHJvY3M8PC9hNTcKNzAgMCBSL2E1Ngo2NiAw
IFIvYTU1CjY1IDAgUi9hNTQKNjQgMCBSL2E1Mwo2MyAwIFIvYTUyCjYyIDAg
Ui9hNTEKNjEgMCBSL2E1MAo2MCAwIFIvYTQ5CjU5IDAgUi9hNDgKNTggMCBS
L2E0Nwo1NyAwIFIvYTQ2CjU2IDAgUi9hNDUKNTUgMCBSL2E0NAo1MyAwIFIv
YTQzCjUyIDAgUi9hNDIKNTEgMCBSL2E0MQo1MCAwIFIvYTQwCjQ5IDAgUi9h
MzkKNDggMCBSL2EzOAo0NyAwIFIvYTM3CjQ2IDAgUi9hMzYKNDUgMCBSL2Ez
NQo0NCAwIFIvYTM0CjQzIDAgUi9hMzMKNDIgMCBSL2EzMgo0MSAwIFIvYTMx
CjQwIDAgUi9hMzAKMzkgMCBSL2EyOQozOCAwIFIvYTI4CjM3IDAgUi9hMjcK
MzYgMCBSL2EyNgozNSAwIFIvYTI1CjM0IDAgUi9hMjQKMzMgMCBSL2EyMwoz
MiAwIFIvYTIyCjMxIDAgUi9hMjEKMzAgMCBSL2EyMAoyOSAwIFIvYTE5CjI4
IDAgUi9hMTgKMjcgMCBSL2ExNwoyNiAwIFIvYTE2CjI1IDAgUi9hMTUKMjQg
MCBSL2ExNAoyMyAwIFIvYTEzCjIyIDAgUi9hMTIKMjEgMCBSL2ExMQoyMCAw
IFIvYTEwCjE5IDAgUi9hOQoxNyAwIFIvYTgKMTYgMCBSL2E3CjE1IDAgUi9h
NgoxNCAwIFIvYTUKMTMgMCBSL2E0CjEyIDAgUi9hMwoxMSAwIFIvYTIKMTAg
MCBSL2ExCjkgMCBSL2EwCjggMCBSPj4vRm9udEJCb3hbMCAtNTUgMTg3IDIz
OV0vRm9udE1hdHJpeFsxIDAgMCAxIDAgMF0vV2lkdGhzWwowIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAg
MCAwIDAgMCAwIDAgMCAwXT4+CmVuZG9iagplbmRvYmoKMiAwIG9iago8PCAv
VHlwZSAvUGFnZXMgL0tpZHMgWwozIDAgUgpdIC9Db3VudCAxCj4+CmVuZG9i
agoxIDAgb2JqCjw8IC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAyIDAgUgo+Pgpl
bmRvYmoKNzYgMCBvYmoKPDwgL0NyZWF0aW9uRGF0ZSAoRDoyMDAwMDIyMjEw
MjEyNikKL1Byb2R1Y2VyIChBbGFkZGluIEdob3N0c2NyaXB0IDUuMTApCj4+
CmVuZG9iago2IDAgb2JqCjw8L1R5cGUvRW5jb2RpbmcvRGlmZmVyZW5jZXNb
MAovYTAvYTEvYTIvYTMvYTQvYTUvYTYvYTcvYTgvYTkvYTEwL2ExMS9hMTIv
YTEzL2ExNC9hMTUKL2ExNi9hMTcvYTE4L2ExOS9hMjAvYTIxL2EyMi9hMjMv
YTI0L2EyNS9hMjYvYTI3L2EyOC9hMjkvYTMwL2EzMQovYTMyL2EzMy9hMzQv
YTM1L2EzNi9hMzcvYTM4L2EzOS9hNDAvYTQxL2E0Mi9hNDMvYTQ0L2E0NS9h
NDYvYTQ3Ci9hNDgvYTQ5L2E1MC9hNTEvYTUyL2E1My9hNTQvYTU1L2E1Ni9h
NTcvYTU4L2E1OS9hNjAvYTYxL2E2Mi9hNjMKL2E2NC9hNjUvYTY2L2E2Ny9h
NjgvYTY5L2E3MC9hNzEvYTcyL2E3My9hNzQvYTc1L2E3Ni9hNzcvYTc4L2E3
OQovYTgwL2E4MS9hODIvYTgzL2E4NC9hODUvYTg2L2E4Ny9hODgvYTg5L2E5
MC9hOTEvYTkyL2E5My9hOTQvYTk1Ci9hOTYvYTk3L2E5OC9hOTkvYTEwMC9h
MTAxL2ExMDIvYTEwMy9hMTA0L2ExMDUvYTEwNi9hMTA3L2ExMDgvYTEwOS9h
MTEwL2ExMTEKL2ExMTIvYTExMy9hMTE0L2ExMTUvYTExNi9hMTE3L2ExMTgv
YTExOS9hMTIwL2ExMjEvYTEyMi9hMTIzL2ExMjQvYTEyNS9hMTI2L2ExMjcK
L2ExMjgvYTEyOS9hMTMwL2ExMzEvYTEzMi9hMTMzL2ExMzQvYTEzNS9hMTM2
L2ExMzcvYTEzOC9hMTM5L2ExNDAvYTE0MS9hMTQyL2ExNDMKL2ExNDQvYTE0
NS9hMTQ2L2ExNDcvYTE0OC9hMTQ5L2ExNTAvYTE1MS9hMTUyL2ExNTMvYTE1
NC9hMTU1L2ExNTYvYTE1Ny9hMTU4L2ExNTkKL2ExNjAvYTE2MS9hMTYyL2Ex
NjMvYTE2NC9hMTY1L2ExNjYvYTE2Ny9hMTY4L2ExNjkvYTE3MC9hMTcxL2Ex
NzIvYTE3My9hMTc0L2ExNzUKL2ExNzYvYTE3Ny9hMTc4L2ExNzkvYTE4MC9h
MTgxL2ExODIvYTE4My9hMTg0L2ExODUvYTE4Ni9hMTg3L2ExODgvYTE4OS9h
MTkwL2ExOTEKL2ExOTIvYTE5My9hMTk0L2ExOTUvYTE5Ni9hMTk3L2ExOTgv
YTE5OS9hMjAwL2EyMDEvYTIwMi9hMjAzL2EyMDQvYTIwNS9hMjA2L2EyMDcK
L2EyMDgvYTIwOS9hMjEwL2EyMTEvYTIxMi9hMjEzL2EyMTQvYTIxNS9hMjE2
L2EyMTcvYTIxOC9hMjE5L2EyMjAvYTIyMS9hMjIyL2EyMjMKL2EyMjQvYTIy
NS9hMjI2L2EyMjcvYTIyOC9hMjI5L2EyMzAvYTIzMS9hMjMyL2EyMzMvYTIz
NC9hMjM1L2EyMzYvYTIzNy9hMjM4L2EyMzkKL2EyNDAvYTI0MS9hMjQyL2Ey
NDMvYTI0NC9hMjQ1L2EyNDYvYTI0Ny9hMjQ4L2EyNDkvYTI1MC9hMjUxL2Ey
NTIvYTI1My9hMjU0L2EyNTUKXSA+PgplbmRvYmoKOCAwIG9iago8PC9MZW5n
dGggMjcyID4+CnN0cmVhbQowIDAgMCAwIDE3NSAxNTMgZDEKMTc1IDAgMCAx
NTMgMCAwIGNtCkJJCi9JTSB0cnVlL1cgMTc1L0ggMTUzL0JQQyAxL0YvQ0NG
L0RQPDwvSyAtMS9Db2x1bW5zIDE3NT4+CklEICOGsdjYNn/4MEDINdhhBhQ0
1aq9Wq9W19Xq67q67q67q67r90t90t90t90t90v219b7pb7pb7pb7pY7Xvr2
va9r2vayBG42/11t11t11t11t1+2l+67rrbrrbrrbr9tL90t913XW3X7aX7a
X7pb7pb7+0v20v20v3S33S33ra39pftpfulvvW1vW1v7Sv7S/dLfetresdr3
17X9r/+nTpwQOn/ABABACkVJCmVuZHN0cmVhbQplbmRvYmoKOSAwIG9iago8
PC9MZW5ndGggMTg5ID4+CnN0cmVhbQowIDAgMCAwIDEzOSAxNjIgZDEKMTM5
IDAgMCAxNjIgMCAwIGNtCkJJCi9JTSB0cnVlL1cgMTM5L0ggMTYyL0JQQyAx
L0YvQ0NGL0RQPDwvSyAtMS9Db2x1bW5zIDEzOT4+CklEIDL3rrqFBSOGQE/B
w7vv/8ho2K8Pvv+/7/nYKG//////////////////////////////////////
/////////////////////913Wg4Tgge/4AIAIApFSQplbmRzdHJlYW0KZW5k
b2JqCjEwIDAgb2JqCjw8L0xlbmd0aCAyMTQgPj4Kc3RyZWFtCjAgMCAwIC00
MyAxNzAgMTUzIGQxCjE3MCAwIDAgMTk2IDAgLTQzIGNtCkJJCi9JTSB0cnVl
L1cgMTcwL0ggMTk2L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMS9Db2x1bW5zIDE3
MD4+CklEICOGv/7UGCsK1av9f/////////////////////////////////nY
Ef/9f9evC4/////////kG+wfg/fv3/3//j//////////////////////+Zcf
6/+uuuCx//66qFBf8yGgoO++/gAgAgpFSQplbmRzdHJlYW0KZW5kb2JqCjEx
IDAgb2JqCjw8L0xlbmd0aCAzNjEgPj4Kc3RyZWFtCjAgMCAwIC00IDE4NyAx
NTYgZDEKMTg3IDAgMCAxNjAgMCAtNCBjbQpCSQovSU0gdHJ1ZS9XIDE4Ny9I
IDE2MC9CUEMgMS9GL0NDRi9EUDw8L0sgLTEvQ29sdW1ucyAxODc+PgpJRCA7
DDSnfAyTscFmTID+CBwQOCBwg4IHCDhBwg4ToOEHRAn9wiCsBB0Q2il0Q1wt
wiGqsOgQMOgg3QQN0EG6CDdBN0EG6QboJuk9BBuk3SbpN6ek3Sb09Juk3p6T
fek3rpN96V6et6ft0vvq6/fV1f+vt19f+3/9L//v/3//X//9/9f/1//9/f0v
/33X1/fdd11v7rrb+lvuu0rf0ra7q67StruraVtdpW0ra7SthK2lbW2lhhK2
lYYStpWGErDCVhhKwwShgwlYYIKyGupKwZKw2oZBUGwrIEmihiFahhQwoahh
QwUMKDChgoMFJkB/OxwWZ3wMk7IDUnagEgAgAgpFSQplbmRzdHJlYW0KZW5k
b2JqCjEyIDAgb2JqCjw8L0xlbmd0aCAyOTIgPj4Kc3RyZWFtCjAgMCAwIDAg
MTU2IDE1MyBkMQoxNTYgMCAwIDE1MyAwIDAgY20KQkkKL0lNIHRydWUvVyAx
NTYvSCAxNTMvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xL0NvbHVtbnMgMTU2Pj4K
SUQgI4ap3UGt/+DBHYQM2GEwrCavWkr111XS/0ul/pdfXS6+ul/pdfXS6+ul
19dL/S6+ul19dLr66+ul19dLr66XX116Xrr66XX116Xrr0sV8geDYWSB4Kov
IHgyicHh4PD3h7w97yGjfvndYNXOwYZnB+G+G+/b7fft9+/vv//b///f//f/
///11///X/rr/r669el16XXhLrwS4S53WDVzsgNXFa1rC1SwqCoKEFBAsFkD
wUymQPBUCgAQAQpFSQplbmRzdHJlYW0KZW5kb2JqCjEzIDAgb2JqCjw8L0xl
bmd0aCAyNzggPj4Kc3RyZWFtCjAgMCAwIC0zNCAxNzQgMTUzIGQxCjE3NCAw
IDAgMTg3IDAgLTM0IGNtCkJJCi9JTSB0cnVlL1cgMTc0L0ggMTg3L0JQQyAx
L0YvQ0NGL0RQPDwvSyAtMS9Db2x1bW5zIDE3ND4+CklEICOGv/7UMFDCtWr/
X///////////////////////////////////+QPBWWJA8CcFkDwWimQyEKwe
Dw8PDw94e973veQb7SPnYkGnzsWBq4b4fhvhvvw337fb/37f+3/v/t//39//
/+////+v///pf//pf6/6X+l16XXpdelwvCXS4LwS52NBq87CAqYrWta1haoL
CoKEFCChAsFkMiK5A8FoLkDwZDIAEAEKRUkKZW5kc3RyZWFtCmVuZG9iagox
NCAwIG9iago8PC9MZW5ndGggMjcyID4+CnN0cmVhbQowIDAgMCAwIDE3NSAx
NTMgZDEKMTc1IDAgMCAxNTMgMCAwIGNtCkJJCi9JTSB0cnVlL1cgMTc1L0gg
MTUzL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMS9Db2x1bW5zIDE3NT4+CklEICOG
sdjYNn/4MEDINdhhBhQ01aq9Wq9W19Xq67q67q67q67r90t90t90t90t90v2
19b7pb7pb7pb7pY7Xvr2va9r2vayBG42/11t11t11t11t1+2l+67rrbrrbrr
br9tL90t913XW3X7aX7aX7pb7pb7+0v20v20v3S33S33ra39pftpfulvvW1v
W1v7Sv7S/dLfetresdr317X9r/+nTpwQOn/ABABACkVJCmVuZHN0cmVhbQpl
bmRvYmoKMTUgMCBvYmoKPDwvTGVuZ3RoIDI0MSA+PgpzdHJlYW0KMCAwIDAg
MCAxNDYgMTUzIGQxCjE0NiAwIDAgMTUzIDAgMCBjbQpCSQovSU0gdHJ1ZS9X
IDE0Ni9IIDE1My9CUEMgMS9GL0NDRi9EUDw8L0sgLTEvQ29sdW1ucyAxNDY+
PgpJRCAjhqf+8MFDCtWr/X////////////////////////////yB4NRVIHg2
CUgeCoBQeHh4eHvD3ve95DRs753qDRwfg32+H7fD9v/b7/7f+//ff////3/7
/r/X////19f6/6X+vrr0uvCXXhLhLneoNHOzhpYrX1hapYVKEFCChAsFgsge
G0UAAgAgCkVJCmVuZHN0cmVhbQplbmRvYmoKMTYgMCBvYmoKPDwvTGVuZ3Ro
IDIxOCA+PgpzdHJlYW0KMCAwIDAgLTkgMTQwIDE2MiBkMQoxNDAgMCAwIDE3
MSAwIC05IGNtCkJJCi9JTSB0cnVlL1cgMTQwL0ggMTcxL0JQQyAxL0YvQ0NG
L0RQPDwvSyAtMS9Db2x1bW5zIDE0MD4+CklEIDKb19VUFI4ZAX8HDu+//yGj
Ytwff9/3/87Cg3///////////////////zub/1/1/14Xk0BMf//////+Q0bj
379+/+/+P/////////////////Oyt/6/6/68Lj//9fWsLBf/OzMEmTiQ97+/
8AEAEApFSQplbmRzdHJlYW0KZW5kb2JqCjE3IDAgb2JqCjw8L0xlbmd0aCA0
MDIgPj4Kc3RyZWFtCjAgMCAwIC00IDE1NiAxNTYgZDEKMTU2IDAgMCAxNjAg
MCAtNCBjbQpCSQovSU0gdHJ1ZS9XIDE1Ni9IIDE2MC9CUEMgMS9GL0NDRi9E
UDw8L0sgLTEvQ29sdW1ucyAxNTY+PgpJRCA7sGqTMFWVkCiVUGeQsDxwQOCD
kXA8DEIOCDgg4ThBwThBwiBZ7l8IgpjQcJhEFcrdtEFRTewiG0tuxBA3gg3Y
IN2EHwQbsIN4TdhB8Ju09hN4XabwntPavT2vve393/b2uE4+v+utVr6VaULC
ULBKdkgaU7BQbJ2BAsTvwPB5WwPDKlTA8GuS0Dw1oJSLAeG3BKEoQUIKEFQU
IFQKgVEDw1BVEDwzS1EDwYWkQWNp5Bt2JohpbK0QadgsFQLCpYVL6pa+q/X/
////2dlndP+7/bv+7t+07rsJ2GuwnbWwwnhhbYJ2DC2GCdgwWwZJAbbIaoJs
g2ibsgyV4YuyB4EkbBNwwm4YLhhMKGCGGChgoMFBgoMgeiokoLErYMk7NQ1J
2gHgAgAgCkVJCmVuZHN0cmVhbQplbmRvYmoKMTkgMCBvYmoKPDwvTGVuZ3Ro
IDE2OSA+PgpzdHJlYW0KMCAwIDAgMCA2MyA2NyBkMQo2MyAwIDAgNjcgMCAw
IGNtCkJJCi9JTSB0cnVlL1cgNjMvSCA2Ny9CUEMgMS9GL0NDRi9EUDw8L0sg
LTEvQ29sdW1ucyA2Mz4+CklEICahCWBPhgoeC//+DC//B4X//wwX/4eC/j/h
hf/5CKP4MGEF//8MF/+Hgv//+DBhBf////wwwQL///w/8MQv/4ML//+ACACA
CkVJCmVuZHN0cmVhbQplbmRvYmoKMjAgMCBvYmoKPDwvTGVuZ3RoIDE0MiA+
PgpzdHJlYW0KMCAwIDAgMTYgNDQgNjcgZDEKNDQgMCAwIDUxIDAgMTYgY20K
QkkKL0lNIHRydWUvVyA0NC9IIDUxL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMS9D
b2x1bW5zIDQ0Pj4KSUQgJwcnCecAv/4IfIIj4XgiMBPhA///////////////
//////////+ACACACkVJCmVuZHN0cmVhbQplbmRvYmoKMjEgMCBvYmoKPDwv
TGVuZ3RoIDE2OSA+PgpzdHJlYW0KMCAwIDAgMTQgNDcgODYgZDEKNDcgMCAw
IDcyIDAgMTQgY20KQkkKL0lNIHRydWUvVyA0Ny9IIDcyL0JQQyAxL0YvQ0NG
L0RQPDwvSyAtMS9Db2x1bW5zIDQ3Pj4KSUQgMwL+CINR/D/yScH/w4kIE/8G
D/yGDH4IP/zgbXIIj4XgiMBPhA/hf/hf///////////4Yf//4Yf8hgj8YPh/
OoMeACACCkVJCmVuZHN0cmVhbQplbmRvYmoKMjIgMCBvYmoKPDwvTGVuZ3Ro
IDE1OSA+PgpzdHJlYW0KMCAwIDAgMTQgMzkgNjcgZDEKMzkgMCAwIDUzIDAg
MTQgY20KQkkKL0lNIHRydWUvVyAzOS9IIDUzL0JQQyAxL0YvQ0NGL0RQPDwv
SyAtMS9Db2x1bW5zIDM5Pj4KSUQgMwz+YDN/hA/kJoH/w5MJ+C/8f8LmsG8L
zMMvwXBeEQb6cIg6j+Qhj///IS/DIfT/H/Mwzf5DBjwAQAQKRUkKZW5kc3Ry
ZWFtCmVuZG9iagoyMyAwIG9iago8PC9MZW5ndGggMTM3ID4+CnN0cmVhbQow
IDAgMCAyIDMyIDY3IGQxCjMyIDAgMCA2NSAwIDIgY20KQkkKL0lNIHRydWUv
VyAzMi9IIDY1L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMS9Db2x1bW5zIDMyPj4K
SUQgOoP5ODfwXkIR8L4Pwv//////////////5NQav/84E//////8AEAECkVJ
CmVuZHN0cmVhbQplbmRvYmoKMjQgMCBvYmoKPDwvTGVuZ3RoIDEzNiA+Pgpz
dHJlYW0KMCAwIDAgMCA0MCA2NyBkMQo0MCAwIDAgNjcgMCAwIGNtCkJJCi9J
TSB0cnVlL1cgNDAvSCA2Ny9CUEMgMS9GL0NDRi9EUDw8L0sgLTEvQ29sdW1u
cyA0MD4+CklEICOGv/+dQn////////////////////8jgX///8nDHnUJ//B/
ABABCkVJCmVuZHN0cmVhbQplbmRvYmoKMjUgMCBvYmoKPDwvTGVuZ3RoIDEy
MSA+PgpzdHJlYW0KMCAwIDAgNTUgMjAgODQgZDEKMjAgMCAwIDI5IDAgNTUg
Y20KQkkKL0lNIHRydWUvVyAyMC9IIDI5L0JQQyAxL0YvQ0NGL0RQPDwvSyAt
MS9Db2x1bW5zIDIwPj4KSUQgJqL//DD//w//g4P///DD/+D8AEAECkVJCmVu
ZHN0cmVhbQplbmRvYmoKMjYgMCBvYmoKPDwvTGVuZ3RoIDE2MyA+PgpzdHJl
YW0KMCAwIDAgLTMgNDQgNjcgZDEKNDQgMCAwIDcwIDAgLTMgY20KQkkKL0lN
IHRydWUvVyA0NC9IIDcwL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMS9Db2x1bW5z
IDQ0Pj4KSUQgJqCp//IQT8OH8GD+QwoD+DD8MP4OH8GH8HD+D+GH8P+GD/g/
/hh/////+Xv+DC+F/ITT/HgvBheSAY/gAgAgCkVJCmVuZHN0cmVhbQplbmRv
YmoKMjcgMCBvYmoKPDwvTGVuZ3RoIDE2NyA+PgpzdHJlYW0KMCAwIDAgLTMg
NDQgNjcgZDEKNDQgMCAwIDcwIDAgLTMgY20KQkkKL0lNIHRydWUvVyA0NC9I
IDcwL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMS9Db2x1bW5zIDQ0Pj4KSUQgOgY8
nAv/BB+EQ9Af/4QP+CBBh///+F/hQYP///////////////////+GCh4L////
gwsHhfwwX+OGC8GF50DH8AEAEApFSQplbmRzdHJlYW0KZW5kb2JqCjI4IDAg
b2JqCjw8L0xlbmd0aCAxNjUgPj4Kc3RyZWFtCjAgMCAwIDAgNTEgNjcgZDEK
NTEgMCAwIDY3IDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDUxL0ggNjcvQlBDIDEv
Ri9DQ0YvRFA8PC9LIC0xL0NvbHVtbnMgNTE+PgpJRCAmoaXyG1T+H8hFAf/B
8P/g//Dw///////4X/4X+VAY/jwXyG1T+C+QgMH/hh/8Ph///////4X/C+F/
H/hfIaVfABABCkVJCmVuZHN0cmVhbQplbmRvYmoKMjkgMCBvYmoKPDwvTGVu
Z3RoIDE1OCA+PgpzdHJlYW0KMCAwIDAgMTQgNDcgNjcgZDEKNDcgMCAwIDUz
IDAgMTQgY20KQkkKL0lNIHRydWUvVyA0Ny9IIDUzL0JQQyAxL0YvQ0NGL0RQ
PDwvSyAtMS9Db2x1bW5zIDQ3Pj4KSUQgOoMeThl/wg/BEEQD/Cw8ED/wg///
/CCBg////////////wwwQL///wwv4YMEF/HBgvDC/nUGPABABApFSQplbmRz
dHJlYW0KZW5kb2JqCjMwIDAgb2JqCjw8L0xlbmd0aCAxNDQgPj4Kc3RyZWFt
CjAgMCAwIDE0IDQ0IDY3IGQxCjQ0IDAgMCA1MyAwIDE0IGNtCkJJCi9JTSB0
cnVlL1cgNDQvSCA1My9CUEMgMS9GL0NDRi9EUDw8L0sgLTEvQ29sdW1ucyA0
ND4+CklEICahCoCf//////////////////////////IYq/DCBfx5CP/wwv/i
aBjwAQAQCkVJCmVuZHN0cmVhbQplbmRvYmoKMzEgMCBvYmoKPDwvTGVuZ3Ro
IDE3MyA+PgpzdHJlYW0KMCAwIDAgMCA1OCA2NyBkMQo1OCAwIDAgNjcgMCAw
IGNtCkJJCi9JTSB0cnVlL1cgNTgvSCA2Ny9CUEMgMS9GL0NDRi9EUDw8L0sg
LTEvQ29sdW1ucyA1OD4+CklEICahCLhP///////////81n/4IP////wv//wf
/yK//8LD+C/////BYP4Qf////woYf///Bf/+D//gsP4X////xCDH//+D/8F/
/gAgAgpFSQplbmRzdHJlYW0KZW5kb2JqCjMyIDAgb2JqCjw8L0xlbmd0aCAx
NTUgPj4Kc3RyZWFtCjAgMCAwIDE0IDQ0IDY3IGQxCjQ0IDAgMCA1MyAwIDE0
IGNtCkJJCi9JTSB0cnVlL1cgNDQvSCA1My9CUEMgMS9GL0NDRi9EUDw8L0sg
LTEvQ29sdW1ucyA0ND4+CklEICcMGgTzgGP/CHyHI+F5CF/4f///+H/Dw/8h
oR+MPk4aWRAF/ImE//C5wgQX8eC+F/Jwb+ACACAKRUkKZW5kc3RyZWFtCmVu
ZG9iagozMyAwIG9iago8PC9MZW5ndGggMTUwID4+CnN0cmVhbQowIDAgMCAx
NCA0MiA2NyBkMQo0MiAwIDAgNTMgMCAxNCBjbQpCSQovSU0gdHJ1ZS9XIDQy
L0ggNTMvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xL0NvbHVtbnMgNDI+PgpJRCA1
gR5OGb/CB4Ihgj4XkOD/CD/+D4QX////////8MP8F/wwwvyGCPxg+Qwyv5rA
jwAQAQpFSQplbmRzdHJlYW0KZW5kb2JqCjM0IDAgb2JqCjw8L0xlbmd0aCAx
NTEgPj4Kc3RyZWFtCjAgMCAwIC0zIDQ0IDY3IGQxCjQ0IDAgMCA3MCAwIC0z
IGNtCkJJCi9JTSB0cnVlL1cgNDQvSCA3MC9CUEMgMS9GL0NDRi9EUDw8L0sg
LTEvQ29sdW1ucyA0ND4+CklEICahCoCf//////////////////////////IY
q/DCBfx5CP/wwv/5oGP8f///////4AIAIApFSQplbmRzdHJlYW0KZW5kb2Jq
CjM1IDAgb2JqCjw8L0xlbmd0aCAxNTggPj4Kc3RyZWFtCjAgMCAwIDE0IDQ3
IDY3IGQxCjQ3IDAgMCA1MyAwIDE0IGNtCkJJCi9JTSB0cnVlL1cgNDcvSCA1
My9CUEMgMS9GL0NDRi9EUDw8L0sgLTEvQ29sdW1ucyA0Nz4+CklEIDWGjyGD
T/Mw18EQxp/5CE/hBA//g+EF///kFY1//kIT//+GH/gvBfhh/8GUAn8cH8hg
X/msCPABABAKRUkKZW5kc3RyZWFtCmVuZG9iagozNiAwIG9iago8PC9MZW5n
dGggMTUzID4+CnN0cmVhbQowIDAgMCAwIDUzIDY3IGQxCjUzIDAgMCA2NyAw
IDAgY20KQkkKL0lNIHRydWUvVyA1My9IIDY3L0JQQyAxL0YvQ0NGL0RQPDwv
SyAtMS9Db2x1bW5zIDUzPj4KSUQgNYZ/Jwaf4Ihr/wiGNA/wWDyCBP8ED///
8IIMP////////////////////////////////wAQAQpFSQplbmRzdHJlYW0K
ZW5kb2JqCjM3IDAgb2JqCjw8L0xlbmd0aCAxODIgPj4Kc3RyZWFtCjAgMCAw
IC0zIDU0IDY3IGQxCjU0IDAgMCA3MCAwIC0zIGNtCkJJCi9JTSB0cnVlL1cg
NTQvSCA3MC9CUEMgMS9GL0NDRi9EUDw8L0sgLTEvQ29sdW1ucyA1ND4+CklE
ICGBfzgav8jgrfIMVB/8PIQx/kxT/wcED+P/+C4WC8gQN/NYNXk4a+F5wNLw
uQLpPIYFeEQ5V/C////wyK/8MgQ4f/DBkYD/xwfwwvNYN/4AIAIKRUkKZW5k
c3RyZWFtCmVuZG9iagozOCAwIG9iago8PC9MZW5ndGggMTI0ID4+CnN0cmVh
bQowIDAgMCAwIDEwIDY3IGQxCjEwIDAgMCA2NyAwIDAgY20KQkkKL0lNIHRy
dWUvVyAxMC9IIDY3L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMS9Db2x1bW5zIDEw
Pj4KSUQgJqE////////////////8nDf5NQn//4AIAIAKRUkKZW5kc3RyZWFt
CmVuZG9iagozOSAwIG9iago8PC9MZW5ndGggMTQ0ID4+CnN0cmVhbQowIDAg
MCAxNCA0NCA2NyBkMQo0NCAwIDAgNTMgMCAxNCBjbQpCSQovSU0gdHJ1ZS9X
IDQ0L0ggNTMvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xL0NvbHVtbnMgNDQ+PgpJ
RCAmoQqAn//////////////////////////yGKvwwgX8eQj/8ML/4mgY8AEA
EApFSQplbmRzdHJlYW0KZW5kb2JqCjQwIDAgb2JqCjw8L0xlbmd0aCAxNTAg
Pj4Kc3RyZWFtCjAgMCAwIDE0IDQyIDY3IGQxCjQyIDAgMCA1MyAwIDE0IGNt
CkJJCi9JTSB0cnVlL1cgNDIvSCA1My9CUEMgMS9GL0NDRi9EUDw8L0sgLTEv
Q29sdW1ucyA0Mj4+CklEIDWBHk4Zv8IHgiGCPheQ4P8IP/4PhBf////////w
w/wX/DDC/IYI/GD5DDK/msCPABABCkVJCmVuZHN0cmVhbQplbmRvYmoKNDEg
MCBvYmoKPDwvTGVuZ3RoIDE1OCA+PgpzdHJlYW0KMCAwIDAgMTQgNDcgNjcg
ZDEKNDcgMCAwIDUzIDAgMTQgY20KQkkKL0lNIHRydWUvVyA0Ny9IIDUzL0JQ
QyAxL0YvQ0NGL0RQPDwvSyAtMS9Db2x1bW5zIDQ3Pj4KSUQgOoMeThl/wg/B
EEQD/Cw8ED/wg////CCBg////////////wwwQL///wwv4YMEF/HBgvDC/nUG
PABABApFSQplbmRzdHJlYW0KZW5kb2JqCjQyIDAgb2JqCjw8L0xlbmd0aCAx
MzkgPj4Kc3RyZWFtCjAgMCAwIDAgMjcgODYgZDEKMjcgMCAwIDg2IDAgMCBj
bQpCSQovSU0gdHJ1ZS9XIDI3L0ggODYvQlBDIDEvRi9DQ0YvRFA8PC9LIC0x
L0NvbHVtbnMgMjc+PgpJRCAmoEfIN88H/mp/4Yg+H////////////////zMM
//+Ugb/NYT//8AEAEApFSQplbmRzdHJlYW0KZW5kb2JqCjQzIDAgb2JqCjw8
L0xlbmd0aCAxNDIgPj4Kc3RyZWFtCjAgMCAwIDE2IDQ0IDY3IGQxCjQ0IDAg
MCA1MSAwIDE2IGNtCkJJCi9JTSB0cnVlL1cgNDQvSCA1MS9CUEMgMS9GL0ND
Ri9EUDw8L0sgLTEvQ29sdW1ucyA0ND4+CklEICcHJwnnAL/+CHyCI+F4IjAT
4QP/////////////////////////gAgAgApFSQplbmRzdHJlYW0KZW5kb2Jq
CjQ0IDAgb2JqCjw8L0xlbmd0aCAxMzcgPj4Kc3RyZWFtCjAgMCAwIDIgMzIg
NjcgZDEKMzIgMCAwIDY1IDAgMiBjbQpCSQovSU0gdHJ1ZS9XIDMyL0ggNjUv
QlBDIDEvRi9DQ0YvRFA8PC9LIC0xL0NvbHVtbnMgMzI+PgpJRCA6g/k4N/Be
QhHwvg/C///////////////k1Bq//zgT//////wAQAQKRUkKZW5kc3RyZWFt
CmVuZG9iago0NSAwIG9iago8PC9MZW5ndGggMTc3ID4+CnN0cmVhbQowIDAg
MCAxNiA2NiA2NyBkMQo2NiAwIDAgNTEgMCAxNiBjbQpCSQovSU0gdHJ1ZS9X
IDY2L0ggNTEvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xL0NvbHVtbnMgNjY+PgpJ
RCAhhCXCf////wWH/DBf///+RX/+FhhEWwf/wX////D///BhAv/wX4f///B/
//hggg///+F//4UPw//4/wX/////+F4OEGED////gAgAgApFSQplbmRzdHJl
YW0KZW5kb2JqCjQ2IDAgb2JqCjw8L0xlbmd0aCAxNTEgPj4Kc3RyZWFtCjAg
MCAwIC0zIDQ0IDY3IGQxCjQ0IDAgMCA3MCAwIC0zIGNtCkJJCi9JTSB0cnVl
L1cgNDQvSCA3MC9CUEMgMS9GL0NDRi9EUDw8L0sgLTEvQ29sdW1ucyA0ND4+
CklEICahCoCf//////////////////////////IYq/DCBfx5CP/wwv/5oGP8
f///////4AIAIApFSQplbmRzdHJlYW0KZW5kb2JqCjQ3IDAgb2JqCjw8L0xl
bmd0aCAxNzMgPj4Kc3RyZWFtCjAgMCAwIDAgNTggNjcgZDEKNTggMCAwIDY3
IDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDU4L0ggNjcvQlBDIDEvRi9DQ0YvRFA8
PC9LIC0xL0NvbHVtbnMgNTg+PgpJRCAmoQi4T////////////NZ/+CD////8
L//8H/8iv//Cw/gv////wWD+EH////8KGH///wX//g//4LD+F////8Qgx///
g//Bf/4AIAIKRUkKZW5kc3RyZWFtCmVuZG9iago0OCAwIG9iago8PC9MZW5n
dGggMTgxID4+CnN0cmVhbQowIDAgMCAtMyA2MyA2NyBkMQo2MyAwIDAgNzAg
MCAtMyBjbQpCSQovSU0gdHJ1ZS9XIDYzL0ggNzAvQlBDIDEvRi9DQ0YvRFA8
PC9LIC0xL0NvbHVtbnMgNjM+PgpJRCAgw0edQ0v4QfgiGNAf4WHkOo/gggwf
/4IH/CCDD/////hBBh/////////////8MKHhf////wwwgv4MF/hhYPBfhkMa
BfxwYLwwvIMNH8AEAEAKRUkKZW5kc3RyZWFtCmVuZG9iago0OSAwIG9iago8
PC9MZW5ndGggMTY1ID4+CnN0cmVhbQowIDAgMCAwIDUxIDY3IGQxCjUxIDAg
MCA2NyAwIDAgY20KQkkKL0lNIHRydWUvVyA1MS9IIDY3L0JQQyAxL0YvQ0NG
L0RQPDwvSyAtMS9Db2x1bW5zIDUxPj4KSUQgJqGl8htU/h/IRQH/wfD/4P/w
8P//////+F/+F/lQGP48F8htU/gvkIDB/4Yf/D4f//////+F/wvhfx/4XyGl
XwAQAQpFSQplbmRzdHJlYW0KZW5kb2JqCjUwIDAgb2JqCjw8L0xlbmd0aCAx
MzEgPj4Kc3RyZWFtCjAgMCAwIDAgMzAgNjcgZDEKMzAgMCAwIDY3IDAgMCBj
bQpCSQovSU0gdHJ1ZS9XIDMwL0ggNjcvQlBDIDEvRi9DQ0YvRFA8PC9LIC0x
L0NvbHVtbnMgMzA+PgpJRCAjhm//k4T/////////////////////////+Rwz
f/wAQAQKRUkKZW5kc3RyZWFtCmVuZG9iago1MSAwIG9iago8PC9MZW5ndGgg
MTY5ID4+CnN0cmVhbQowIDAgMCAtMyA1OSA2NyBkMQo1OSAwIDAgNzAgMCAt
MyBjbQpCSQovSU0gdHJ1ZS9XIDU5L0ggNzAvQlBDIDEvRi9DQ0YvRFA8PC9L
IC0xL0NvbHVtbnMgNTk+PgpJRCAqwz+aw1f5DBWwRBiv4XkOBfBBEUL/ggfw
oPwv/4QX/////////+HD//D/hwX4MF+GQIID/hkGK/xg+aw1fKsG/8AEAEAK
RUkKZW5kc3RyZWFtCmVuZG9iago1MiAwIG9iago8PC9MZW5ndGggMTYzID4+
CnN0cmVhbQowIDAgMCAtMyA0NCA2NyBkMQo0NCAwIDAgNzAgMCAtMyBjbQpC
SQovSU0gdHJ1ZS9XIDQ0L0ggNzAvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xL0Nv
bHVtbnMgNDQ+PgpJRCAmoKn/8hBPw4fwYP5DCgP4MPww/g4fwYfwcP4P4Yfw
/4YP+D/+GH/////5e/4ML4X8hNP8eC8GF5IBj+ACACAKRUkKZW5kc3RyZWFt
CmVuZG9iago1MyAwIG9iago8PC9MZW5ndGggMTY3ID4+CnN0cmVhbQowIDAg
MCAtMyA0NCA2NyBkMQo0NCAwIDAgNzAgMCAtMyBjbQpCSQovSU0gdHJ1ZS9X
IDQ0L0ggNzAvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xL0NvbHVtbnMgNDQ+PgpJ
RCA6BjycC/8EH4RD0B//hA/4IEGH///4X+FBg////////////////////4YK
Hgv///+DCweF/DBf44YLwYXnQMfwAQAQCkVJCmVuZHN0cmVhbQplbmRvYmoK
NTUgMCBvYmoKPDwvTGVuZ3RoIDE3MiA+PgpzdHJlYW0KMCAwIDAgMCA2MSA1
OCBkMQo2MSAwIDAgNTggMCAwIGNtCkJJCi9JTSB0cnVlL1cgNjEvSCA1OC9C
UEMgMS9GL0NDRi9EUDw8L0sgLTEvQ29sdW1ucyA2MT4+CklEIDqGjycGrIQj
+ERjA/wUGQ5HwsPCD/4YP8LD//g//B//w///w4f//hwf//4P/w/4MP/hfwfD
/4MMEC/h81hIX4Mh6AvykDR/ABABCkVJCmVuZHN0cmVhbQplbmRvYmoKNTYg
MCBvYmoKPDwvTGVuZ3RoIDEzOSA+PgpzdHJlYW0KMCAwIDAgMjIgMzkgNTgg
ZDEKMzkgMCAwIDM2IDAgMjIgY20KQkkKL0lNIHRydWUvVyAzOS9IIDM2L0JQ
QyAxL0YvQ0NGL0RQPDwvSyAtMS9Db2x1bW5zIDM5Pj4KSUQgI4f/+GH///g/
4f/4f+Qj/wYyQf8GCDkI////BQyb/wseaBPwAQAQCkVJCmVuZHN0cmVhbQpl
bmRvYmoKNTcgMCBvYmoKPDwvTGVuZ3RoIDE3MSA+PgpzdHJlYW0KMCAwIDAg
MTkgNTEgNzMgZDEKNTEgMCAwIDU0IDAgMTkgY20KQkkKL0lNIHRydWUvVyA1
MS9IIDU0L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMS9Db2x1bW5zIDUxPj4KSUQg
OAY/hEJoR1/BYPBB/+H+DBhf45OGb4XwXC+C+RRf8H8MgXr8hmkBkEv/BQf4
UGH///////4YOF+DggX8ZwZEBn/JQH8AEAEKRUkKZW5kc3RyZWFtCmVuZG9i
ago1OCAwIG9iago8PC9MZW5ndGggMTU1ID4+CnN0cmVhbQowIDAgMCAyMiA0
NyA1OCBkMQo0NyAwIDAgMzYgMCAyMiBjbQpCSQovSU0gdHJ1ZS9XIDQ3L0gg
MzYvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xL0NvbHVtbnMgNDc+PgpJRCAzDnA/
5gNEPIfP/wgxISwX+FBw//8H//wwf//Dg////8OHD///wfD/4P/hhhA/451D
nAn4AIAICkVJCmVuZHN0cmVhbQplbmRvYmoKNTkgMCBvYmoKPDwvTGVuZ3Ro
IDE1NSA+PgpzdHJlYW0KMCAwIDAgMjIgNTEgNTggZDEKNTEgMCAwIDM2IDAg
MjIgY20KQkkKL0lNIHRydWUvVyA1MS9IIDM2L0JQQyAxL0YvQ0NGL0RQPDwv
SyAtMS9Db2x1bW5zIDUxPj4KSUQgJqCFOCfwwg/Id/+D4ML////h+H/hwYP/
w4f+D///hw//hwf+D//yCWH/8MGF+YDP80CfgAgAgApFSQplbmRzdHJlYW0K
ZW5kb2JqCjYwIDAgb2JqCjw8L0xlbmd0aCAxNDEgPj4Kc3RyZWFtCjAgMCAw
IDMgMjUgNTggZDEKMjUgMCAwIDU1IDAgMyBjbQpCSQovSU0gdHJ1ZS9XIDI1
L0ggNTUvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xL0NvbHVtbnMgMjU+PgpJRCA4
CeEHkO//Bhf//w8P8H/4cH//4f8H///wfmA0fx/kMfggf///gwXgAgAgCkVJ
CmVuZHN0cmVhbQplbmRvYmoKNjEgMCBvYmoKPDwvTGVuZ3RoIDE1NiA+Pgpz
dHJlYW0KMCAwIDAgMjIgNDEgNTggZDEKNDEgMCAwIDM2IDAgMjIgY20KQkkK
L0lNIHRydWUvVyA0MS9IIDM2L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMS9Db2x1
bW5zIDQxPj4KSUQgJqZID/5sDH/wx+DD+Dhmch6f8MTF/8gmmdBR8ly8k7zm
dAn/4M+Gf+OH8MH4Mhn8P/DITT4AIAIKRUkKZW5kc3RyZWFtCmVuZG9iago2
MiAwIG9iago8PC9MZW5ndGggMTY5ID4+CnN0cmVhbQowIDAgMCAwIDU2IDU4
IGQxCjU2IDAgMCA1OCAwIDAgY20KQkkKL0lNIHRydWUvVyA1Ni9IIDU4L0JQ
QyAxL0YvQ0NGL0RQPDwvSyAtMS9Db2x1bW5zIDU2Pj4KSUQgOgaPJwyshyP4
IhBhPX4QQYP8Fh8H/gg/4WH//B/8f/////DB//8iV/D4P/8P8MH/4WD/4Yf/
DBYf/BkOQRuD/KgG//gAgAgKRUkKZW5kc3RyZWFtCmVuZG9iago2MyAwIG9i
ago8PC9MZW5ndGggMTQ0ID4+CnN0cmVhbQowIDAgMCAyMiA0MSA1OCBkMQo0
MSAwIDAgMzYgMCAyMiBjbQpCSQovSU0gdHJ1ZS9XIDQxL0ggMzYvQlBDIDEv
Ri9DQ0YvRFA8PC9LIC0xL0NvbHVtbnMgNDE+PgpJRCAnBjzgZeQn/wggw/+D
/BYfB///4f/DD//+D//8PDwvw/+DBhBfxzqDHgAgAgpFSQplbmRzdHJlYW0K
ZW5kb2JqCjY0IDAgb2JqCjw8L0xlbmd0aCAxNzMgPj4Kc3RyZWFtCjAgMCAw
IDIyIDczIDU4IGQxCjczIDAgMCAzNiAwIDIyIGNtCkJJCi9JTSB0cnVlL1cg
NzMvSCAzNi9CUEMgMS9GL0NDRi9EUDw8L0sgLTEvQ29sdW1ucyA3Mz4+CklE
ICaghQCGoJ/+EH//wYYMOEXv//DD//+D///4YP/w4fhw4cH/////+Dg4P//h
w4f/hw///wi9CL3//hiCDH/mAz/z4Q6B/8AEAEAKRUkKZW5kc3RyZWFtCmVu
ZG9iago2NSAwIG9iago8PC9MZW5ndGggMTQwID4+CnN0cmVhbQowIDAgMCAx
MCAyOSA1OCBkMQoyOSAwIDAgNDggMCAxMCBjbQpCSQovSU0gdHJ1ZS9XIDI5
L0ggNDgvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xL0NvbHVtbnMgMjk+PgpJRCA4
H8IHkO//DD/wZr/w//wx/h///g/4f///D8wGV5OH//wfh//4AIAICkVJCmVu
ZHN0cmVhbQplbmRvYmoKNjYgMCBvYmoKPDwvTGVuZ3RoIDE1MSA+PgpzdHJl
YW0KMCAwIDAgMjIgMzcgNTggZDEKMzcgMCAwIDM2IDAgMjIgY20KQkkKL0lN
IHRydWUvVyAzNy9IIDM2L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMS9Db2x1bW5z
IDM3Pj4KSUQgPgR4QeQlP4QQM8/goZs///8fkNFf8glkIf+GQTPw4cHB/w4Y
P//ww/yQLBfxzWGPABABCkVJCmVuZHN0cmVhbQplbmRvYmoKNzAgMCBvYmoK
PDwvTGVuZ3RoIDIyMSA+PgpzdHJlYW0KMCAwIDAgMCA3MCA3OSBkMQo3MCAw
IDAgNzkgMCAwIGNtCkJJCi9JTSB0cnVlL1cgNzAvSCA3OS9CUEMgMS9GL0ND
Ri9EUDw8L0sgLTEvQ29sdW1ucyA3MD4+CklEICa3yKZg/w/DIRY8hhTB/kGA
Tw4f5BuL8MgYEvINBgH+H8hpFw/yGrVwZDWI8HD/IKl+QZDUPhGFCV/wjU+F
JgXBQX4IImC/yoCeTL/CCBGJ/ynL8FOgTBSYl8II6H/gvmLPhAic/84f4IeZ
yax8III6X+PC8EbccAEAEApFSQplbmRzdHJlYW0KZW5kb2JqCjcyIDAgb2Jq
Cjw8IC9UeXBlIC9YT2JqZWN0IC9OYW1lIC9SNzIgL1N1YnR5cGUgL0ltYWdl
IC9MZW5ndGggNzMgMCBSCi9Db2xvclNwYWNlIC9EZXZpY2VHcmF5L1dpZHRo
IDM5MS9IZWlnaHQgODcvQml0c1BlckNvbXBvbmVudCA4Cj4+CnN0cmVhbQr/
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
///////////////////5+//49fv8/vz+/vv7/f3+/v//////////////////
////////////////////////////////////////////////////////////
/////////fX7////////////////////////////////////////////////
/////////vz9+v3t9vj76vn+/f35+fv+////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////+
9/3+9Pn+/f33/Pz08ff7+/7/////////////////////////////////////
///////////////////////////////////////////////z+/7+/v767/7+
/v7+/v7+//////////////////////////////////////////789v7+8P39
/v329Pj09vz9/v//////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
/////////////////////////////////////////vv99vb+/v35/f39+/n8
/fr+////////////////////////////////////////////////////////
/////////////////////////////v77/vP9+f7+/v7+/v7+/v//////////
///////////////////////////////+/vX+/f7//P7+/v7+/f399f7/////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
///////////////////////4/vD7/vT+/vHz9fb5+/n3/v//////////////
////////////////////////////////////////////////////////////
//////////z67f72/vH7/v7+/v7+/v7/////////////////////////////
/////////////v7+/PX++vH99vz9+PH5/f3+////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////+f33/fbr/ff9+fr8+vPx9v7/////////////////////////////////
///////////////////////////////////////////////////7/v79/Pz8
+v7+/v7+/v7+///////////////////////////////////////////7//70
/fb9+/z8+Pb8/Pr3/v//////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
//////////////////////////////////////////////39+P319Py6dEcb
DSBauPv9////////////////////////////////////////////////////
////////////////////////////////+PPobW1y2fX+/v7+/v7+/v//////
////////////////////////////////////9v39/P37/KFaRRUSS369/P7/
///////+/v7//f7+/v7+/v79/v7+/f3+/v7+//7+/f7+/f3+/v7+/v7+/v7+
/v3+/v7+/v7+/v3+/v39/f3+/v7+//7+/f39/v7+///+/v7+/v7+/v39/v7+
/v3+/f39/v39/f7+/v39/v39/v7+/v39/v/+/v/+/v7+/f7+/f7+/v3+/v7+
/v7+/v7+/v7+/v7+/v39/f39/v7+/v7+/v7+/v79/v7+/v7+/f39/v7+/f3+
/v39/v7+/v7+/f7+/v39/v/+/v39/v39/f3+/v79/f7+/v7+//7+/v39/f7+
/v7+/v7+/v3+/f39/v7+//7+/v7+++z8+P3tah4VGiUcEStU/P3+//7+/v7+
/v79/v7+/v39/v7+/f7+/f79/f39/f39/f3+/f39/vz8/f3+/v7///79/f7+
/v7+/f/+/f39/fz+/h0OCsP4/f39/v7+///+/f7+/v7+/v7+/v7+/f79/f3+
/v79/f3+/v3+/v7//v7++f39+u8nDiIWERoMPK79////////+v389/3u/fr8
+/f8/fD+9/T4/P75+vT98vb8/Pb0+vr3+/38/fzw/Pf2/f345v3s9fz4/PP5
+Pz3/Pf9/u/x/Pvr/Pvm/vz4/f32/f3x9v38+ez89fv8+fr68fz7+Pb58Pzx
+Pzw/fv9/fzy+PD9/fv3/Pv99Pr9+Pn7+/n4+vf9+/318fz99fn5/f37+vz8
/On7+/j39/r0/fT3/PP0+/z78/r9/fj7/Pr6+fb0/On89vX0/fj89/v6/Pj7
/P73/fH6/Pf87Pf4+P389Pv9+v3w/fP6+v39+u39/Ov9+fb88fjs+vru+P36
9P70/PT+/f30/fD9/bBioreshBQfFar8/P72/fT99vzx8fzz8/z6+Pv9/fz8
8P36/PH2+t/5+PH7+/n58vj25/n07P3y/v77+vz0+fv2/PH78vL78fr88/og
KBap9fvx/Pb88Pv98vvu+/zx/fn4+vz8/P39+Pv88/38+Pr6/fzw/fb7/v/9
8/398/38bmG3o8BJGB0R4v74/P//8/v8+vb99Pvhs6/88/b87/37/M2mqez+
+Pz3tnlyX4fV6Pzz/emLsdP6mXdayPvm/vnIn6vN/Pr5srqs4ff6/OTkqlhm
aIm5/uj98Pe3tP3w8Pz89v7sq7Gu+PzolGVizfyYqcDS7v39+ve0ur3o/fb8
+aess+z5+Pv3tXhyX4XR9PX2/Pjkzolua2CN5P3v+PH8mK/x/f3z/OS8tr78
9vzt+7pLbGJ+tPL8+PPFeE920Pz7+c+kpNDw/Pm1r6T9+Oj9+fDklHVTZLDw
+vvx/KirrOn9/Pn88rqpsvD89q29uLz2+r+pvtb9/f2yqarh+vyywKvo/P38
9Lun3flhFiB39/P7/fr+/fCzaWB3yvulo7jT9P30+vzq/Oq3hFJjdH2/x+Pl
+uKUanVVv/369vf4sbWz+/z+ubKt/fz7sqOw9f3vFQocu45cZpHv/fz+5ex3
gnzY76qwvf3c6frw0bWD3P79p7G64PP66by1tPny3+vv1/zZ+/znpbL07yAQ
Ksj++fz8//X7/Pn0/fz1wR8h7/rzq6n0/PBwFiOp+Pj2VDcXEygkFJHx9vrC
EC1LaAsWExRf/PT2eCEYaOfu9wsfHafm/e2NDiAQDichCvv+8/n+SBfV+vzx
/OvzbBQaYfz4MhooJhemShcSsfz48v3tJhgbqfv9/PUmHhmy7fzzUzgXEyYi
Emj6+e/yegkUDS4LH7D9/f39/RIkuvrw/PxtIyBZ7+v8uTEKOBASKCKm7PqO
JCYbG7Hq7fxXJDBH9PasHRwiw/z9/PCrKBgTKC8NP9n0/fQlHzCt8/v2/fgM
LRGq7pMJKQuf+etfFy11+PTtIh0kuvPzIxwSwPPppDAZGxt7qiUNX/X7+f3z
/btACiYbFxsrFywp++/+/ff3/LMuJBceIRIYGQf88KcyHgoYJRQ+3vr89icI
F/X86BcTJevu+C8XGOr7+xkbFDApHykiPeH36PlPEwcyMLsTKgvx+vuCLBgh
HLD96xMVKrD79qkQDynu/KkyHRnx+ep/HBEdMa9WKwuw+v3++v/5+fv89P38
864UFvn6yBYpZ/T2aBgmpvf3gS8QDdbbDRokhPv8uBUKG2+0ZBElIcL8+Ggf
FWz8+fwcIxi1/PyJGRoWisWeelv77/7+8KU6cvj87/b91h8PE7Dygy4LFDJs
D0gjDLn27/368RUWHbT68fH7Ex0QtPf5fjAVEtjZDRsagvXwcB8OK0ystZnK
8/X9/vUNEbH96fy2IA0PdPf83R4VIEO1uoxQs/znNA0YPqfu9vz8JQ0YE/L1
hxAdHXf89vTOIR4RnflFDSIz9/j5DQsSqfz78v74ISIcqPk/JBZa6fr0chkZ
Yvn8+xMVE7r5+hAUHbjz+kwiIg8UH2YbI2n1/fz0/N5EEi5Eu4QlCSAOue/6
/v7v+6EdCBgbdLinuWNA5bcrCBOf+0wIHi/j+/EcJR/28/olFRr68/wSFB/5
9PkXHxs2npgQIw57/PnSGioYLB5JGRok7+76QBkaLKrj/fsdGRO16fm8Hhse
8vS4DBkO7fzPEiAhHSczRyoTrP7+/vr/+/j7/fX6/PWtGB709IIZGyb4+2IP
HKn79CMJJ2r5+mEjDzLw+K4pGyP289sxDyRo4vFcIBdm+fP6FxYNo/rrPxgT
keb57+78+f39+/vvFBP58vzz7pkbHED281kNJiXS7pcrCyXC/P7y/vwfER6x
/Pz9+xQaGK789h8ILG/4+WEkJB/z+SUQIyb0/Pb5/P328v7zMimo/PvcMA8p
G2zv+3AhDkr56fnr/Pz08DMVGJf8+/vwuRUUGRam+UwcJxcw8PvzaBQWDPvo
sys0B7nt+x8kG7T9/PP89iULFsSBFRUd8fz1/GoLKIT29/wRFxer8+wPJyyj
58ELDSRq5LIrGBll9/359fyVCRdI9d2fHhopHL/0/fP9+eoeHR4w4/z8+/z4
/PlsHRwh+eesJBgXrPr7DxMZ9/z7DR4a+O/6FRsg+fzuJAoetvjzQSMvC/b8
pR8gHH6YHyIVIu319w0VLaX88vbzKB8Utuz5qRgTF/L2tCQiGfroYBsWFKLy
diMXFrH+/vz6//35+/339/n4sikd+fI5KAwLn/RgESO07KUbICOm8uKrGx8V
vfqnDhsS+vL6ThQgH/z7YxwTYvv9/CAiJa34xw8lJcC8lbC2sfr7/Pj9+1EN
HRMcHCIkGQeN+vMMJBVU+vr6DxEdmPn8/e/0HBEirPr89vEaISij8K8XHiSn
8eCpGhsUsKATISGb/Pv9/u7x/f3++hYYovn1cBgiGBxY9vo8DiN4urGqsJ/Q
/PgHJyeg+Pzu/JUgIWIbXfkfFSUbK+rn/BUcIV/59/oIDzZd+foQFAyq/Pr5
+/oZIBeoMjQQmvf+/f2CDBeS/f/zEhglqPr5EBwUrvtsCSQV4vrkQiAWWv37
9P31XRQWuu/aRRkXNBkG7v33/fyEEx4myPb3/Oz2/fX8EiATYPP7+wgkK2jv
9RMcJO71+BYWFff6+iAXC/L7+SQVHqPu8rAXCgzA6rMZHQ/575AVFhj5+/kg
KQm99/f99R0QF7j2+qojHiX0/K0bCAr79iUbHUv59MoPFSay/Pr3+f/9+/j9
+/b3+bIZCfnMFx1PJmz2axEZu/uzGiIIsfr5xiEVD6f9thcnG+777mIpGQ33
7lsaIWz4+ekQEh2y+LIOGxYOFC8RGBz8+vvz+fySDiAeGRsNESgm5+f3Kx4c
Ufrt7BknI7D79P39/CMZI7Lq+vzvIRYaq/y3GCAIr/z4xyEeIbeyIRgTqPr5
/P78/P3q+PsNJcL7ohcWIxodZvrtFiEsHhkNJiUlvubxJSAauPH64PtlHhLA
Ihu4FBthXhyc+N4nERJg+vfmIDYNZfr8GyAat/z8+vj4GRoYOTALU/nl/vzv
rTEOgfb19h0jJ5Xr9BgkF6v6VCcjB/r39mwPGWD8/fb98YUnHJXpfw8QYepB
IHn9+/vuOyQiHPrx9/X+/ff87hkdJl356fkUDg1k9vYVHyX0+PsaJBf07u8T
HBz89PkSIyGT+PO9LR4wpfyvGRYZ+PG0HxsQ+vjwEyQIyPv79fYhISCm/Par
EBQb7/ukJTEn7ugVHRZd+dv5FQsktPr6+vn/+fz1/fz4+PixHRL0fBEhz0Qg
2WwfF6r4tR0YHLrz+aAcGCG49K0nFhj69vZyER4j8/loGx5i7v36JhYRs/yy
KQ8aur+oJhgT+f3u+vv49zcJ3vrwjxUQVfP5+g4bGW33+fkrDRmy9Pz9/PcZ
GRGVp7imsxQfGrL7nR8XGrn1+6MdEyGlsSQOGr789/X9+/b4/fn6GB2o2zoh
G0diFmX2+hgYFIG+uzweEbT78R0RFbr5+vzsFigM+V8fYyIlsL8UZvT8ECIb
Xvrv+RUUH2f38x0ZGrb1+vv1+xkeFZA5G5zt/Ov9/ZMTH7H8/PsPGCKd+vMd
GiOp93MVHC3m+fFjJB1q8v38+v3fKyMWhB4ZH9f3fhdT8fr7+g8XF2ns+/z+
9/v97/wOHSBh9PvtFicmbfr4EhcZ+fj3EBgN+vj1DBkd9/fvJxcMz+r4pRIa
E676vRwYIvb4tCISIfL2+gomGar5/fL7FhUhvfbzvxUeGur0uRcSEvr7FCAk
Wfj36BghGrf9/v77/vX+/fn9/v7xtyMK9jIKP+yaIJllFRiz+/gZCx1o8/lh
GB8f+PKzHB0Uq+bpHxgQVfvybCsUav31/SYaGLb89gkeDdH55x4PY/b3/Pz8
8/p3Gn7w9C8aIor77vtXFCMQ2/n6GRokse78/fzxFSYXFRgXDR4pEB+n+e0a
ECBn8/pjFykU8OQjDB5J9fz49fn6/P39+R4QsmIQJR7XZyFo+fdTHRyB+Otr
ESX85foZEhmy+fX9zQ0qXve4IiYTD+vfIhHv/FoTJxfv+bUPHBbC8/YZJQw9
0/Ta9PMYKBOztxUb2fb99fx5GCLB/PP6FBQeIZWFIisIuPWoHiQgkfvxZSIb
bf38/fn98edQGRojFZzy+rMVHvn7+/MkGhhr8vv4/Pf99PL6cxcoEff4oyMk
GLX48xQTF5715BcXGZj64A8dIfr57xslEUT5+UsPGhLn9bEVIhf2+awbHBT6
+PoNHyir/PH68h0eErD596khFyUquGEfHxL69WAbHxze9vMMGB6z/vz7/vP/
+/38/fr98LYSHMQaKX364hhaWhojsfz4c0AFLeLRIRIbfvzwuhYTPgtoTw8h
KZP1+2YPCmf49PwVFw648PKPHSVH7pYqLKb8+/z8/fn6siEy+cslCinm+/n8
0yAIK2+oVxoXDrD7/PL9+SESGlxxaG5uEhsWu/n0dkkHMuPSJBcRgPv7kiUR
GmWvpHag4vv+9PsiGGciIBOz8V8gavfyvh8HIuXgHxZF4vGzHRg3gKj5/oof
FJb75xENID/z61Mdv/u/Hw8PrPRJNAgy8fzyHBMfZBsVKu/nFxgcwO50DlL4
/fj1awoSnPz5+hIYFWwQKhwNHs776z4PFSaoiRkLHVz0/f74/vP371gqDiBD
1/bkr7D99fz7FyAXPPnn+P799vr7864oBSmQ+0AbDTb86fQzHBdQSkYPGSVK
QUYkDwv78voOHBNePUEXLw5X5vq1GxUK+vuwFhol8PmwEQwegqL87vMUKBqy
+vywEBxBQRIbHQsz+/zFGyYMULlFLSASsPv8/P71//f9/fz2/PS3GSRgCzDD
9fREG0AVHqv5+/ZjIBQRHRUaZ+f9+LsdGU2TASsZBrbu/ft2GSR57vf9HSUd
vfn5+mcfDxsoHzv7+f36+vv99vVFGchXHxRy/Pvy+u9tMQwNMkQqHRyq8/X9
9fMgDSiw7PPy4xsnE7f49vVuLxoPGhcfYvnu6+9yIBoKLxYqrvv8+/f8GRIf
Igh1+vpiElz88futJBQaFQ8vyff8ECEOChwd+/hULxm78/tbISRh+fuKDpHn
7rMgJAkZJQ5A2fzy+hcOJqs5Fgr7+R8QGKn3xDcjx/H75nAiIHD89OYaGR61
MhMSDWfs9vqbGCQfGihaMxp37/r++fz2+/lFGRKJJxti7Pn8/fz6+2YSKh3s
+/zq/vD6/vL8pSwHECUTFkTg4vz5Bxwg4TEtICJy1y8PFCSJ9O7tEx0ppDcd
FBobyvnpwxohJfb5riAZGPj4FzAnDhou+vrwGA8ltPH6sRUdS5cdDCEqj/Tl
8WgVKhcWXTUNKbr6/f3+9//2/f39+fz3thwWGRg48P34nQ4pGBi09Pz9/MuD
e2930uL99vmlGRgU79Nadb30/f34xqCwyvr7+RMVHan9/vzj03Zjdrj7/P3+
+vn8/fT8jB1nECEg0vr3/f737teCkpjjMRIvt/z//fX8GhshsPz9/voYGByp
/fr7+tOEdmx30/r8/f389tajbG9roPX88f78/BkcEx847/L7aBde/Oz8+u6G
cGh25vrw/K4HJiV9qPr8s7G4/Pz7yMjk8Pzx57u8/fv34J5nZE288vT68+u7
vqf23J5p6/AiGSCr+/zEtcHz/PfHuLC7+v38q6ur59yOaYnS/Prt+vh8bIHk
6qKxwP30/fr9+PrGIBkr7tgNFMfz+v399fzTLBsIie727/L98vP2/Pzgn2Zx
YKrq+/3q/LyXx/fcdWN/+/fjimeh9PP9/au4rvDajF6R4fv8/c+su7D8/eaz
sqP7+bAGJiGFk/37+bmts9f7/fa2rKf6xGlilfD88/z24pBoqPzNmbLX/v78
/vr/+v39/fz89LIaGBsjdvT++uAjEBgVvvL+9/T8++75/Pf99vb6rSUmFf3u
/Pz2/PL8/Prw+fH+/vEcGRqr/Pro/PH8/Pz98Pf+/f77/vz5/dscHRQbPPn1
/ff4/fT8+Pn7+g4VGJ/7/uj7/A4iFqj39fT6FBAcr/369vT8/Oz6/fb79Pjw
+v34+vLz+v39+vv9+fsYJhYkxvz7/Fwgavjx/u/4/vn1+vXz/Pv+JB0QrPvr
+/Tv/Pzz6Pz8/f39+v31/fHo/fff/f393v3++/z++/zt9f7s6/38ERISsvX6
+Pbx/fz87/n4+e/u/fT7++T9+eb8/Pn87f35/P3w/Or3/fT+9vz7/fr5ugUp
cejaJRi7/Pz3/P3791MWJSpp0/zh5ram/ebx/Pf6/Pz5/Pr+++r8/e/5/vz0
/PX79/3m9f3z/PX3/PXo/PP98/z09P3++Pz67vfy+/f89fH8IhkKqP318/z4
+fb2/fH9/fvr/Pn9+Pz9+/v48fr3/f7i/fz08/78+f3///79/P36/fC3Ghki
EMvz+vP4UQ8ZGLnz//70+v37/v75+PT8+LgcECX68fz88/X9/P25bWua9P3y
Gx0Nt/r4/fj9/P36/vL+/fr9+/36/fL8ZxATJ5/7/Pr9/f749/39/PYSKxuz
/P39+f0RFRq1/v3+/SEdF7r2/frz9v35/P33/vj9/u/o/PP79/n9+P7++fj9
FBkeqPz7/PxfGWbv/vn9+/j+/fj9/PH94f7druz6/P399/r0/fz2/Pz3/vv+
/f39+v37/On97f3+9vb3/er9/fr7/f315xwaEr38+v35/Pv39p5qaJj+/Pz1
/Pv9/f39/fzy/fr2+/37/Pv89vn5/P39+vr8/flECBRmNhAv3fz+/vv99Pz7
YSAUEBIQEQYpTvz8/Pr9+fv++vD6/f3+9Pb8+PP8/Pr95vv4/f35/vb99/3+
/fz9+/39/vz+5/z1/fX99/3y9vz88PvnvvH+7fz6XlJqz/38+ff7+/b+9/3u
+Pr8/P78+ffq/vX2/f3++/n8///9/vz9+fr402BbZVv5/f39/KhvbnHL/f35
/vv9/fH2/f39+vOwGAwg+f3q+vz9+/H6gRocce789xgkE7H0+v35/fP9/ev+
+vr6/fr9/P72/dRsYYH1/f3y+f32/f3v/fz8HhQdvfzo+P34clxqxP73+uxt
bWXY9v35+/z8+vT4/vH98Pn99/3+/Pb8/f30+f79/mZpff31/fX9pGic9P33
+f7x/Pzu/fT69Pzy8/f89/j0/fz6+Pz8+/v++/z8/Pn84f32+/v98/3+5vb9
9v39/f378/r8+PwfHByu8P77/vz++vlqGhRe8fz8/fjy/vD8/uv8/f39/fru
/P7x/fP8+PL8/fn6/f728JkPGByG7fv2+/39/PX87fvZbTEdFCYac6r8/Pzx
/P3z/f7+/e/37/7+/vn9+/X88P3x/P729/Tw/f74/P72+/776v727/399frz
/fj9/f3y+fzv/fj3/v78/B8TJK/q+fz5+vvy/Pj+8P398vr99vz8/fz+/v3+
+v79+v//+fr8/fr7/PD59/v7+fL6+Pj78/b2/f7w/fz6/f79/fj++/H5yWN3
aO39+v34/fb7+KiDlcH99vZtd2TC/Pfz/f79/v39/v74/P35/v79/fT89f3x
/Pf9/f36/P34/P39+V9obLr8/P38/Pzw+/n8/f39/Pn4/Pn5/v39/fn7/vb9
/f399/399vn9/fL9/fv9/fHx/P70/vT9/fz3/vju/f7+/Pz8/P39/f309fv6
+v7+8P33/Pr++f3z/v3x/Pz6/f3y/fD8+P76/v389vj7/vv8/v31/fv3YmNv
zPD98f3+/vD5iG1qof35+P39/Ov9/f38/Pz9+fr9/fX//ef+8fzy/Pz4/P36
/vj88fz15/379Pz3+fv89Pz79e776vrx9vr9/O7+/Pf3/v31/PH99/3+7f78
/fP8+/34+f70+f39/fD+/f35/vn4/f30/vf4+/v8/PT9+vr8/f38/f75/fv+
7P1gZ2XN+vr7/fz6+/3++f38/P31+vv8+/X9+vf9/ff+/vn9/vz9/f38/Pz8
/f38/f7+/P38+/z9/P/6/fz7+/v8/f39+vv8/Pr5+vz9/f3+/v/9/f37/fn9
/v79+v33/Pv7/Pr5+/7+/v7+/vn9/v7+/f39/v79/v/+/fz9/Pv7/P3+/vb9
/Pn5/P36/PL8/fv9/Pz9/f39/f39/f359vr8/v34/fv8/v79+/3+/fj2/f39
+f7+/f39/f7+/vv9/vf7/fv8/Pr9+fr9/f35/fv9/vn7+v38/Pj8/vv+/v79
/v39/f3+/v79/f39+f369f7+/f38/f39+/z2/Pv6+/z8/P79/v38/Pr5/f39
/Pf3/P39+vz9/P3+/v38+/39/Pj4/v7++/r9/f39/f39/f79/f38+/v8/f38
/Pz9/Pj2+fz9/f7+/f39/f39+/3+/v79/Pz5+/z8/f7+/vn9/Pj9/vz9/f7+
/v7+/v/+/v7+/v7+/v7//f3+/v7+/v7+/v7+/v7+//79/fz8/P39/f/+/f7+
/v79/f7+/f39/f39/v7////////////8/f79/Pz8/f79/f3+/v39+fL29fj/
/P39/v7+/Pv6+v79/f78/P39/v39/v7+/v7+/v349/z6/Pz9+vz8/f/+/v7+
/Pz8/P3+/vz28/X5/ff29vj8/f399vj7/P37+fj9/Pf3+/3+/f37/fr2/fz5
/Pz9/v79/f33/P7++vn9/f39/f39+fn79/79/vzz9/3+/v79/f39/v78/f37
/f35+/z8/v7+/fz9/f7+/vz3+/3+/v38/f73/v7+/v7+/f39/f7+/v39/fr9
/f39/ff3+/f6+/v9/f3+/fz8/f39/f349vv9/f399/n9/v7++vj7+vr7+/v7
+/b5/Pz9/Pj2/Pz9/v33+f39/f3//v39/Pz7/P39/fz87/j9/v79/f37/P39
/Pjz8Pf39/n6/f39+/v8+vf19fX3/v///vr5/v//////////////////////
////////////////////////////////////////////////////////////
/////////////f3+/fz8/P37+/v7+vv7+vz0/fn5//v6/P3+/v39/fz++/j3
9/n6+v7+/f3+/v7+9/r7/Pv8/v39/vf7+vP+8v7++vn8/v7+8/f+/v7+/v79
/Pr4+Pn5+fv8/P38+/399fn+/v34+v79/fz4/f39/Pv6+/v7+/v7/f78+v39
/fbz8PD1+fv8/P367vL7/v3+/v7//f39/f789vn9+fv89/v8+Pz78/7v9Pb6
/Pz3+vz9+fn5+fn18/7+/v7+/v39/f39/f7+/v7v8/f6+vj3+vz5/P39/v73
/v39/f39/f3z/f35+v3+7/7+/fv5+fz8/Pz6+fn6/Pz8+vf4+/z9/O79/fj5
/v30/f3+/v79/f38/P39/f38/P39+ff6/f39/vv6+/39/Pv8+/Ty9PX29vr8
/Pz7+vz99fz7+/389/7+////////////////////////////////////////
//////////////////////////////////////////////////////39/v38
/Pz8+/r6+vr6+vrt4v79/P76+fr7+/z8/f39/f38/P39/v79/v39/f7+/v3+
+Pv7+/z4/Pz7+/vv/v73+/39/v7++/7+/Pn49/b2x8G7trOxsK/A0un2+fTv
7Pf+/v77+/3//Pz8/P3t8fP5+fr6+vr6+/P9/fj3+/r5/OnHsKu40+nx+/z9
/f79//39/fz8/P39/fj5/Pz8/Pz9/Pj69uz9/f799fn59Pz8+/b6+fn49f79
/f39/f39/f3+/v3+/v3+/ffz+fr6/Pz27vb4+vb+/v7+/f39/f39/vj4/v7x
9f38+/ju3saxpImIhoSEhoiJpbLH3/D5/Pz89O/9/vb3/v39/v7+/v39/f39
/f39/f39+/v9/f379fz8/Pzy3L6poJeNiIiIhoOAiJSisL7L0vv78fL9/fX3
/v//////////////////////////////////////////////////////////
///////////////////////////////////9/f79/Pz8/Kqqqqqqqqqqr6/9
/fz9/v79/fr49vb4+fr6+/z8/fz6/v7+/v39/f7+7cnLzMDBsaissbSyrfby
+v79/vv8/Pn4+vz35cWii4iEgH5/gYODg4GDi6DE6/v9/v7z+P39+v39/Pz6
rqy3qqqqqqqqqqrk9/j0/Prbw3h4fYSIhoiKlLbY6/f8/fX9/f39/P39/MSx
q6+usre0qqutr62r9fP026+rq6GtqK2osausqq7c/f39/f39/f39/v79/v3+
/fLDqq2rqq2osay4ub7D/f3+/f39/f39/f79/fb6/fzx6tGqi31+hoyGhYOB
gYOFhoyHgH6MrNLr8fz89vL7/v39/f39/f7+//38/Pz9/v399vr9/f38/fz4
4LucjImKjIyHgoKGiIaCh4iIh4SDg4R+kqvO7PT2/P7/////////////////
////////////////////////////////////////////////////////////
/////////////////f3+/f38/PuGhoaGhoaGhoWL9/39/P3+/Pz8+/n7/f37
/P38+vj4+f7//v79/f3+9dGOh4uBi3qHh4iGhYn2/vv+/vv5/vz8/OrBnIaA
goaLiIaGiYyNjYiJiIaEhoyR1fH9/Pz8/fz9/fv884J4iIaGhoaGhoaGx/H7
8uzPm3yXj4eDgH+DiXV5fY225/z8+/z8/Pz8/PypkISGhIaKh4SEh4eHivP3
+dGNhod8i4GIgY2DhoWL0Pv8/Pz8/Pz8/f7+/f7+/v30rYWHhYWIgYN6gn6D
kPL7/f38/f39/f3w/f34+vzYnoeDgYSJioR+iYmHhoaHiYl8g4mHg4CChp3X
+/b0/f7u/v7+/v39/v38/Pz8/f79/f389vr99+HNl5GKhYSDf32CgH+BhYeE
g36Bg4SFhomKh4qCenyKseH9////////////////////////////////////
//////////////////////////////////////////////////////////39
/v38/fz7iIiIiIiIiIiChPv+/vv9+/r6/Pv49fXz9/v8+fb2/P7+/v7//v39
/v3UhX6Ff5KDioSEf3+B+/74/f36/P3567+skn95fYSIh4SCgoODgoGGhYKA
gYWKjpKy4Pz89/f9+f37/PaBeYOIiIiIiIiHiIng+tqnfHGGeXl/iIuJiIqT
kIh9eI/G9vv8/Pz8/P37qI2BhYSFhoOIg4OBgoT5+fzTh4SJfpKFin+KgIaF
h9f7/Pz8/Pz8/P3+/v3+/v79+6p/h4aHjYOOgol/g4z7/f39/f39/f39/u7t
++WqhYWIhoWHiIqHhIODg4KCg4ODg4eJiIaEhYeEhKnj+evs/f39/v79/f39
/Pz8/f39/f339/v88tCeeYuIhIGBg4aIiYiIh4aFhoaIiYmHhIKDg3SFkJON
gYuo/P//////////////////////////////////////////////////////
///////////////////////////////////////9/f79/P38+4aGhYaGhoaG
g3/5+v38/vn7+/v17OHX0NXZ29fT2Oby/f7+/v7+/f391YaDioCUg4SBhISH
hPz4/v39/v354MKFgYGGi4uGgYWCgoOEhYWEg4ODhoeHhYKFeZDN9/z8/vf9
+/n6i4eJhoaGhoaGhoaAtraRiIOBkIyIhYaGgICEgXh/j4p7i636/Pz8/Pz9
+6SJfoeJioqHiYKAgIWF/Pj60oSEiXuQg49/iX6IhoPV+vz8/Pz8/Pz9/v7+
/v7+/PuogIuIhouBhHqFgYWJ9vb9/f39/f3+/fX88a58e4eFg4WFhYOCg4WD
hIaGhYWFhIaEg4SFh4aFhId8fa7x/PH9/f7+/f39/f39/f39/f39+vz605x6
fY6ChYiJh4OCgoKDgYCAgYSGgIGEhIODhYaOioCAhYWSrPz/////////////
////////////////////////////////////////////////////////////
/////////////////////P39/v39/PmFhYWEhISFhYZ/+/r6/fz8+/zy/NKE
fIiJhIp9iYCG9/z1+v79/P78+9mDhYWEhoODhYOGhIH8+vj9/vH89ISVhYWF
hYWEhIWHe4WPgYCJhIyEgYaIhoOFhoOGjK/w/O/9/v349ox6hoWFhYSFhYWE
hYaJioR9gIiGh4aFgoCDh4WFhYSFhIWFoPz9+f7+9v2thIWIgoiEg4OFgoeE
gfz5+9mDhYaDhoKFg4WHgoeD1/n7/f3+/f38/f7+/f38/Pv5qYeFg4WBhoWC
goiFf/r6+/789f3+/ff70JiDh4mHhoeLin9/hod/goaEgIGFhoN/hoR+foiL
hYSGiIaDmNL8+f3+/PT8/fz9/vb1/f3u+vzxwIl5io6Ag4iJhoSFhoWEg4SG
iYqJh4aEgoSIiIN/gn+GgYOFiar8////////////////////////////////
////////////////////////////////////////////////////////////
//z9/f79/fz5hYWEhYSFhYWGgPr6+v38/Pz29vyviIODioCIf4qEg9n8+Pv9
/fz+/PvZg4WGhIaCg4WChoSB/Pr+9/7396WRiIWEhYSEhYWEhYOJhXiCj4eJ
hoeGf4OKhYmDgoOWwu79+/r8/PSIfoeFhYWFhYWFhX+Hh4OLlIlyd4WMh4WJ
hn+EhYWFhYWFhI/H+P78/vv6rYSFiIKIhYSDhYOHg4H8+fvZg4SGhIaDhYOF
h4OHgtf5+/3+/v39/f3+/v39/Pz7+KmHhYOFgIeFg4KIhX/5+v73/f79/Pz2
u52DgYiJh4iGgYSLioGCi4OGhoOChoaDjYOBio2Fg4eIhoiHgIOevPn9/Pz+
/fj9/vn+/f34/PzaroeBiYiCg4h+fYmOhoGDgYB/fn5+gYKBgYGBg4eMkIWA
h4SEg4es/P//////////////////////////////////////////////////
///////////////////////////////////////////7/f3+/v38+YWFhYWF
hYWFhoD7+/r9/Pz98Pz0homJf4x7h4OJiYCs+Pv+/fz9/vz72YOFhoOFg4OF
goeEgfz6/vn5+7aDh4OFhIWEhISFhIB+h4uDg4Z/hICKiHuCjYOHhIKDhI7D
/Pz4+/7yhIOGhYWFhYWFhYWCgYeNhXqEmZKFgIWIhYOIhYSEhIWFhYWHhub9
9/7++a2EhYiCiIWEg4WDh4SB/Pn72YOFhoSGg4WDhIaDh4PX+fv9/v79/f39
/v79/fz8+/iph4WDhYGHhYOCiIV/+fr/9f39/Prw04uDgYeIhIKHg4KAgoiJ
g3iBhYaEg4WFgXqEi4mCgYOEh4OEiYaAg4vT8vv8/v71/f33/f3y/fzem4F5
iIx/gZGHgoOEg4CGkYaLkJCMiIWFiYyNiYJ+f4KLgoyNin5/pvz/////////
////////////////////////////////////////////////////////////
////////////////////////+/39/v39/fmFhYWFhYWFhYaA+/v6/vz8/fX9
03iIiIKLe4iHhYqCje39/fv8/v39+9mDhYaEhYODhYOHhIH8+fn4/NB5j3yD
hIWFhYWEhYWahZDG9fvhw5J8gYuChYyAgoaGiod7nOD9/Pv+8oOIhYWFhYWF
hYSFhoGEioOFrNzTvJ2Ff4OJiYWFhIWFhYWFiXa//Pf+/fythIWHgoiFhIOF
g4aEgfz5+9mDhYWEhoOFg4WGg4eD1/n7/f7+/f39/v7+/f38/Pv5qYeFg4WB
h4WDgoiFf/n6/v759/33yZOJh4iKhoGCh4aGhoSCgoiPmrDM3d3MsJqOh4GB
g4SEhImDgYaJh4aIlMn4/fb4/v38/f7y9fzqoHyFi4eDhoiJg4iHgYGIioaK
h4F7fYqerqirrqqgkoeCi32AgYJ+iLn8////////////////////////////
////////////////////////////////////////////////////////////
//////v9/f39/f36hYWEhYWFhIWGgPv7+v78/Pn++6SDgoOJhnyJiYGHhoPX
+P36/f79/fvZg4WGhIWDg4SDh4SB/Pn6+fGNf4OHgIWFhYSFhISFZqLg+vv3
+fzEkn2HiYaHg4SIhomNgIar+P37/fSFiYGFhYWFhYSEhYWHf4Co4ffy+/zm
qISJjH6EhYSFhIWFhYWGkvD9/vf7rYSFiIKIhYSDhYOGhIH8+fvZg4WFhIaD
hIKEhoOGg9f5+/3+/v7+/f3+/v39/Pz7+KmHhYOFgYeFg4KIhX/6+vn9+Pj8
3JN6hYOChYSDhIiJg4eNg4Wt4Pr79vHx9/z736yEgoyFgoiKhoOEhIKChXqT
3Pz39/75+f358fzxtH+Ei4V6gpKLdYV+foiQjIB3e5a+4fP6/Pz4+fv8+vPn
4Maun42De4Gt/f//////////////////////////////////////////////
///////////////////////////////////////////////7/f38/fz9+oWF
hIWFhYWFhoD7+/r+/Pz3/ueDkYCAjIWCiIeBhImEte39+f7//Pz62YOFhYSF
g4OFg4eEgfz5/PyuhIt3iYGFhYWFhYWFhZfe/Pj6/f3s98CLgYmFg4uKiIGB
iIaDiNn9+/v3homAhYWFhYWFhYSIgIar5Pz98v39/e24hXyOhYSFhYSEhYV4
j3rJ/f7y962EhYiCiIWEg4WCh4SB/Pn72YOFhoOGg4WDhYeCh4PX+fv9/v7+
/v39/f79/fz8+/mph4WDhICHhYOCiIV++vv4/fz996pzjIOBg4aGhYSBgoZ9
dZLL8/v1/P39/v799v30zZR3foeDg4SGh4WBgoONc6r2/fz++ff99/z7v4SG
iIWCgoSFhYOJfX+Kg3eLr/D09/j39/n8/v78/P79/Pr88urXxKqRov7/////
////////////////////////////////////////////////////////////
////////////////////////////+/z8/Pz8/fqFhYWFhYSFhYaA+/v6/vz8
+v7HfJCAgoeEh4SGhoSHhpPe/ff9/vj8+tmDhYaDhoODhYOHhIH9+frvgY6F
gIKFhYWFhYWEhIWz7/3z8P39/vznp4GJhn2Li4ODhIOFiIGn/Pz4+YSGg4WF
hYWFhYWFiXub4vz17Pv65/T96Jp8koSFhISFhYWEfYiAl/n+9/mthIWIgoiF
hIOFgoeEgfz5+9mDhYaEhoOFg4WHg4eD1/n7/f7+/v/9/f7+/f38/Pv5qYeF
g4WBh4WDgoiFf/r7/vn9+MSGepOGh4iIh4aDf4GGgIfA+/zv/P789fX7/f3w
/fvCh4GGgn+DhoeHh4iIlHuGw/f9+v779vr82JV5i4SEiIyFfIORhYiIgn6U
xvH0+Pz+/fz8+/37+Pb4+Pr79/n9/P301tn+////////////////////////
////////////////////////////////////////////////////////////
//////////z9/f39/f36hYWFhYSFhYWGgPv7+v78/Pz8r4KJgYWChYl/g4uD
hIZ90/z1/P73+/vZg4WGhIaDg4WDh4SB/Pr6wJV2jIWHg4WFhYWFhYWF6/r5
+f388/74+b6Gi4l6hYd+ipCDhI2Hf/T79fuDg4WFhYSFhYSFhYGEren9+PT9
/fz5+e7Jl3OFhIWEhYWEhI5/knLq+v38rYSFiIKIhYSDhYOHhIH8+fvZg4WG
hIaDhYOFh4KHg9f5+/39/v7//f3+/v39/Pz8+amHhYOFgYeFg4KIhX/7/P32
/d2Oe5CChIWEgoGDh4eNfZPT+PXx/Pv+/f79/f37/PD099KTe4yHhoOAgIWH
hoOQfI3d/fb9/vb87K6HhH2JhICCh4uEfHuLhnug5vz4/f36+vv7+/v7/v39
/f3+//v5+vD4/vX+/v//////////////////////////////////////////
///////////////////////////////////////////////////9/f39/f38
/IWEhIWEhYWFi4P0+vv2/fr894WOgoaFiIWBgomJgoGFipL78Pr4+fv72YOF
hoSFg4SGhIeDgPz5/JWHjImEkIOGhIiBgoSHqPv8/P38/f399vv6hIuGgIWF
hYWFhYWFhIXR+vr4gouAhYSFhYWFhYSFiqv6/fn9/fv+/vr97YeAhYWFhYWF
hYSAhouBx/31+62EhYiCiISEhYKCiIV/+/z82YOFhoSFg4SDhIeDh4PX+vz9
/f79/fz8/f39/f38/Pmph4WDhICHgoWDh4SB/Pr7/PuflYKEgIKGiYeFhISC
foTK9v397/39//7+/v7+/v7u+/z0zIeAgoOEhYeJhoF8hYSTnfv8+Pj999mT
dpGFhYWFhYWFhYWBhneo5fP+/P38/Pz9/f39/v7+/v7///////7+/v7+/v//
////////////////////////////////////////////////////////////
/////////////////////////////////f3+/fz9/PyFhYWFhYWFhYaD9fv8
+f38+tZ8h4KHh4OKh4WFhYWHioWM4/n5+vn6+9mDhYaEhYOEhYSHg4D8+PKM
goiHg5CDhYCFhIl/i838/Pz9/P39/fz8/J2KiIKIhYWFhYSFhYWDu/j79YSK
g4WFhYWFhYWFhYqr+v35/f76/f79/fiiiYWFhYWFhYWEgoaIgLL89/qthIWI
goiFhISCgoiFf/v8/NmDhYaEhYOFg4WHg4eD1/r8/f3+/fz8/P39/fz8/fz5
qYeFg4WBhoOFg4eEgfz6+vzmlY6ChYWDhoaFhYaHh36q5vz+/PX9/f7//v7+
/v7+9fr7++isf4aHhoWFhoaEgoaEjZPp/Pn6+Pq0jH6OgoWFhYWFhIWEhoCn
2fX+/vv8/Pz9/f39/f7/////////////////////////////////////////
////////////////////////////////////////////////////////////
//////////////39/v38/fz8hYWFhYWFhYWEhPn7/Pj++vure4SEhol/hoeF
gYGFh4aBhr379/z7+vvZg4WGhIWDhIWEh4OA/PjjhoCGhoKNgoOBgoeNd4zx
/P39/fz9/P3/+vzAhYiDh4WFhYWEhYWFgpv3/PKHh4aFhYWEhYWEhYWKq/r9
+f39+vz+/fz8w4uEhYWFhYWFhIOHhIKV+vv5rYSFiIKIhYSEgoKIhX/7/PzZ
g4WGhIWDhYOFh4OHg9f6/P39/v38/P39/f39/P39+amHhYKFgYaDhYOHhIH8
+vv8wYiGg4WIhoWDhIaHiImE1/z9/Pn8/P3+//7+/v7+/v/4+/3814OJiIeG
hIOFh4iHhYaIw/z6+/Xwi4SHiYKFhYWFhYSFhIWD1/z5/vn6/Pz8/f39/f3+
////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////9/f79
/P38/IWFhYWFhYWFhYb6+/n0+/b0i4OIhoSKgH6Eh4SEh4V+gYSZ+/b9+/n7
2YOFhoSFg4SFhIeDgPz41YeEh4mCiYCBh4SDjXaN+/z9/f39/f39/vX64ICG
gYSFhYWFhIWFhYWC+fzxiYWHhYWFhIWFhYWFiqv6/fn9/f37/f30/NuDhYWF
hIWFhIWEiIOHf/r99a2EhYiCiIWEhIKCiIV/+/z82YOFhoSFg4WDhYeDh4PX
+v39/f38/Pv9/v39/fz9/fmph4WChIGGg4WDh4SB/Pr7+J+AgYWEiIeDgoSH
hoaHmfH8+v34/fv9/v7+/v7+/v7++Pz6/fGXh4aGh4SCg4iJhYeCgqH6+/v5
ynuCiIaChYWFhYWEhYWAp+/89/v4/vz9/P39/f39/v//////////////////
////////////////////////////////////////////////////////////
/////////////////////////////////////f3+/fz9/PyFhYWFhYWFhYeH
+vv59/332XmLioaBioaChYiGhoiGg4KHhe33/fv4+9mDhYaEhYOEhYSHg4D8
+MOEhYSJgYaAf4yIfoyBl/v8/f3+/fz9/f72+/V/hYOEhYWFhYSFhYWJePv8
84iEhYWFhYWEhIWFhYqr+v35/f39/Pz88vzrfoWFhYWFhYWFg4mEjHn7/fSt
hIWIgoiFhISCgoiFf/v8/NmDhYaEhYOFg4WHg4eD1/v9/f39/Pz7/f39/f39
/f35qYeFgoSBhoOFg4eEgfz6/OuMgYGIgoWGgoKHh4OChcT8+PX++f36/f7+
/v7+/v7+/vv+9/n9woWBhIeHgoKGhYKJg4ON6/z7/JqFhoOEgoWEhYWFhYWF
hN/6+f34/v39/fz9/f39/f7/////////////////////////////////////
////////////////////////////////////////////////////////////
//////////////////39/v38/fz8hYWFhYWFhYWGh/n7+/3896x0ioWGgYeL
hoGBg4OBgoaEi3/I9/35+fvZg4WGhIWDhIWEh4OA/PiwfoSAiIGGhH+Mi4CL
jaf6/f3+/fz9/f3++vz7g4aJhoWFhYWEhYWFinz8/PeFhYKFhYWFhYWFhYWK
q/r9+f39+v77/ff6+YOFhYWFhYWFhISIg4x//P31rYSFiIKIhYSEgoKIhX/7
/PzZg4WGhIWDhYOFh4OGg9f7/f39/fz7+/z9/f39/f39+amHhYOFgYaDhIOG
hIH8+vzSiISBi4CChoKCiIeBg4rs/PX2/fz5+v7+/v7+/v7+/Pr9//n4/e2K
g4GHiIOChoKAioKGh9H8+vR9jomAhIOFhIWFhYSFhZj7/PL9+vz9/f39/f39
/f3+////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////9
/f79/P38/IWFhYWFhYWFhIb4+/z+/OuJgId/ioWCiYR/go6OgX+FgYuCnvj9
+Pv72YOFhoSFg4SFhIeDgPz4qH+GgIiChoeEhomEh4yt+v39/f38/fz9/v38
+4eFi4WFhYWFhIWFhYeE+ff8gYiAhYWFhIWFhYWFiqv6/fn9/ff++fz89fqG
hYWFhYWFhYSGh4GGh/n8+a2EhYiCiIWEhIKCiIV/+/z82YOFhoSFg4WDhYaD
hoPX+/39/f38/Pv9/f39/f39/fmph4WDhYCGg4SDhoSB+/n5tomEf4yEgoaC
hIiEgImY/Pj7+Pz+9/z+/v7+/v7+/v34/v78//r8mImAhIiEgoaDgYqBh4ez
+ffffoeJgoWFhYSEhYWFhYTE+fzx/P32+Pz9/f39/f39/v//////////////
////////////////////////////////////////////////////////////
/////////////////////////////////////////f3+/fz9/PyFhYWFhYWF
hYSG+Pv9+/HbeZGHfYyJfYSGgY6mpo6Ahn+KhYL2/fj8+9mDhYaEhYOEhYSH
g4D8+KuGjYKKg4WIioCHh4GCqvn9/f39/f38/fv9+faHgoqChYWFhYSFhYWD
ivfz/H6Lf4WFhYWFhYWFhYqr+v35/f33/fj8/O35g4WFhYWFhYWEiIZ+gI32
+/uthIWIgoiFhISCgoiFf/v8/NmDhYaEhYOFg4SGg4eD1/r9/f7+/Pz8/f79
/f39/fz5qYeEg4WAh4OEg4eEgfz5+KOMg3uMhYaIg4SGgoCPo/nt/Pj0/vn9
/v7//v7+/v7++f72/f7w+6OPgIKFhIOIhoKJfoWJoPf2zYp6hoWFhYWEhIWF
hYWF8fH99fn99fz8/f39/f39/f//////////////////////////////////
////////////////////////////////////////////////////////////
//////////////////////39/v38/fz8hYWFhYWFhYWMdvz78vv7m4WFhYWF
hYWFgYd729x8iIOCiYhzzPz4+/rYhIaGhIWChIWEh4OA/PiplnmSiIN9h4iD
foyEgrz5+fv9/fz8/P3++P37eod/h4WFhYWEhYWFhYj58/yAioaFhYWFhYWF
hYt5uPz5/vD+/Pr8/O/88IaFhYWFhYWFhI2AgYaH9P32rYSFiIKIhYSChIOH
hIH8+vzZg4WGhIWDiHmKh46Bf9r6+/z8/fz8/Pz8/f39/f379qSDkYR4g4qE
hISIhIH7+PyOgoCFg4WFh4iDhomJfdX7/Pz8/f39/f7+//7+/v7+/v7+/v7+
/v3Xf4mJhIKGh4WDhoOGh4D4+6uJgIp8hIKDhIWGe46Ek/v8/f38/P39/f39
/f39/f3/////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
///9/f79/P38/IWFhYWFhYWFioL2/Pb584+FhYWFhYWFhY2FifLyiYaOhoOJ
e6748/z62ISGhoSFgoSFhIeDgPz4rI1+iYKHgoOIgoKIhICt+fv8/v38+/z+
/vn9+X+LgoiFhYWFhIWFhYeE/Pb7gYeFhYWFhIWFhYWKgKr59v73/fz+/fz4
9/WHhYWFhYWFhYSIhIKJhfj99q2EhYiCiIWEgoSDh4SB/Pr82YOFhoSFg419
iIGIhYnb9/j4+fn4+Pj4+fn5+fn5+PqugoqJhouGhISEiIOB+/jyhoKDh4OE
hIaHhYeIh4Dc/P38/P39/f3+///+/v7+/v7+/v7+/v7+3oGIiIaEh4WFg4aD
hoaA+PihhYCJfoSDhoOEiX2LhaD7/f39/Pz9/f39/f39/f39////////////
////////////////////////////////////////////////////////////
/////////////////////////////////////////////f3+/fz9/PyFhYWF
hYWFhYeN8fz7+9qBhYWFhYSFhYWLgqn8/KmBioh/iYWM5fL9+tiEhoaEhYKE
hYSHg4D8+MCEiIJ/ioZ+iIGJgYSAmvr8/v/9+/v9/v35++uBi4SIhYWFhYSF
hYWJgfz8+YSDhYWFhYSEhIWFiIOx7fzz/vv8/v38/PbthYWFhYWFhYWEgoqC
ioH8/PethIWIgoiFhIKEg4eEgfz6/NmDhYaEhYOLgYh+hYmJxfj4+fn5+fj4
+fn5+fr6+fnfoYGGhYiKgISFg4iDgfv44H6Dh4iDhIKDh4aHhoaF5/z8/Pz9
/f39/v///v7+/v7+/v7+/v7+/uqGh4aGhYaEhYKGg4aHgPjxlYGAh4CGhIiD
g4t+h4i1/P39/f39/f39/f39/f79/f7/////////////////////////////
////////////////////////////////////////////////////////////
//////////////////////////39/v38/fz8hYWFhYWFhYWHivT5/Py1foWF
hYWEhYWFgYPa+fjZgoCFgYaKfL/6/frYhIaGhIWChIWEh4OA/PndgI2ChImE
gYZ/jX+Fgor1/f7+/vv7/f75+/rXgIWBh4WFhYWEhYWFhob8/PeFgYWFhYWF
hYWEhYGMq/j87Pv9/Pv8/Pn8zoKFhYWFhYWFhX6OgYZ//Pr5rYSFiIKIhYSC
hIOHhIH8+vzZg4WGhIWDhIOLgoeIfZuGhoaGhoaGhoaGhoaGhoaGmIaGiYB/
hoSDhYSIhIH7+Nd7homHg4WEgoWGiIWEifL8/fz8/f39/f7+/v7+/v7+/v7+
/v7+/v70ioSEh4aGgoWDhoOGh4D48IuCgoaDhoaIhIGNgoOJyvz9/f39/f39
/v38/P3+/f3+////////////////////////////////////////////////
////////////////////////////////////////////////////////////
///////9/f79/P38/IWFhYWFhYWFin789vz8koSFhYWFhIWFhISK/Pf3/IqD
goeBioCV/Pr62ISGhoSFgoSFhIeDgPz474GHhYeEf4iEf4x/iYWE5Pz+/v38
+/39+f75wYCBgYeFhYWFhIWFhYOZ+vz3hYKGhYWFhYWFhYV/kYv78P3x/v3x
/P3y/KSBhYWFhIWFhIV/joCAhPz5+62EhYiCiIWEgoSDh4SB/Pr82YOFhoSF
g4KEioWGhnuAg4OCg4KDg4ODg4ODg4KDg3Z/jI+EgoiKhIWEiISB+/jXfomI
hIGGhoOFhomEg4v5/f38/P39/fz//v7+/v7+/v/+//7+/v7++oyDg4iGhYOE
g4aDhoeA+POFhoWEhIWFiIaBjIOCidb8/f39/f39/f38/Pz9/f39/v//////
////////////////////////////////////////////////////////////
/////////////////////////////////////////////////f3+/fz9/PyF
hYWFhYWFhIt2/Pf55n+KhYSFhYWFhYWInfz6+/yfi4CKfoeJfef5+tiEhoaE
hYKEhYSHg4D8+PaQf4WHgX+NgoGKgoqGhcb3+/39/Pz8/f3+8qiCg4WHhYWF
hYSFhYWCvPn4+4KGhoWFhYSFhYWFiX2Exfb9/vv98f798vOJhYSFhYWFhYWE
g4qCfpX6+fythIWIgoiFhIKEg4eEgfz6/NmDhYaEhYOHhYWDg4aEgoiIiIiI
iIiIh4eHh4eHh4eDh4iHh4eHhoSFhIiEgfv42oKKhoKBh4aFhYaJhIGK+f39
/fz9/fz8//7+/v7+//////7//v///vyLgoOIhYSDhYOGg4aHf/j4gYmIgoWD
hIWJgYqGgoja+/39/f39/f79/Pz8/f39/f7/////////////////////////
////////////////////////////////////////////////////////////
//////////////////////////////39/v38/fz8hYWFhYWFhYSJefz7+bp8
iISFhYWEhYWFg8r4+fv5zomCiH+GiX+4+PrYhIaGhIWChIWEh4OA/Pn7s4KH
hIWCiYOFhYSHg4eh8/f8/vz8/Pz+++GNhImIgoWFhYWEhYWFhuT59vx+ioWF
hYWEhYWFhIp4jInc9v70/Pj+/fnAgoiFhYWFhYWFhIaFiICt+vr6rYSFiIKI
hYSChIOHhIH8+vzZg4WGhIWDiYOBhYOEi4aCgYGCgoGCgoGCgoKCgYKCi4qC
gYiIg4WEhYSIhIH7+NmBiYSBgoeGh4aFiYSBiPj9/f38/f38/P/+/v7+//7+
/v7+/v7+/v77iYCEiISEhoWDhoOGh4D4+n2Kh3+FgoaBi4KHhoKG1/z9/f39
/f39/Pz8/P79/f3+////////////////////////////////////////////
////////////////////////////////////////////////////////////
///////////9/f79/P38/IWFhYWFhYWEh4Dz/PiYgYWFhYWFhIWFhXz4+fr8
/PqEhYWCh4SKkPj52ISGhoSFgoSFhIeDgPz5/NSMiYGKhYKEiIKHhn+IiO/0
+v39/Pv7/PPQeIOMiHqEhYSFhISFhYr6+/b8fIyDhYWFhIWFhIV+lH+LlPzu
+vb8/Pb9kYWHhYWFhYWEhIWJgY2Ev/z6+a2EhIiCiIWEgoSCh4SB/Pr82YOF
hoSFg4eCgYqFg4mChYWFhYWFhYWEhISEhISEhIOIhYaLhoSNg4WEiIOB+/jW
f4eEgYOHhIiGhIiFgIb2/P38/P39/Pz//v7+//7+/v7+/v7+/v7++IiAhIeE
hYiEgoaDhoeA+Pp4iYZ8hYOHfo2DhYaFhNP8/f39/f39/fz8/P39/f39/f7+
/v7+/v//////////////////////////////////////////////////////
/////////////////////////////////////////////////////f3+/fz9
/PyFhYWFhYWFhIWG9Pzdf4qBjnyIiYSGgoia/Pz9+ff8pIaDjIR8jIfi+NWF
h4OGjH+ChIOHhIH7+vb2mXmWe3SVg4OEhIWGhoWf6fz08/39+v3Ok3+EiIWC
iYKDh4OBhIbH7Pz49H2JgYWFhISEhYWFiH6Bgoui6/Px/PvcqISAi4WEhYSE
hYWEjn+GfOz98fythIWHgYiFhIOFg4eEgfz6/NmDhYaEhoOEiYSGhYSKhISD
hIOEhISDhISEg4SEhISJjoZ/goGAiYOFg4eDgPv42X2DiYqBiIGFgo6BiIOM
9Pr3+Pj4/v3x/v39/v39/f36/vz5/v33+vSMg4iBjoKEioOHgoCOhfP2jXqD
jX+MgIaJf4WNe4zM/fj+/ff+/fv8/Pz9/fz8/Pz8/Pz9/f39/v7+/v7+/v7/
////////////////////////////////////////////////////////////
//////////////////////////////////39/v38/fz8hYWFhYWFhYSFiPP7
vYaDhYl/ioWCi4SCxPz7/Pn2/MyAhoWEfYGMu/rSf4eFhImEg4WDh4SB+/n7
+8uGfpGIfoSEg4SEhoaGisr4/fv59vXftIt/h4mFgYx3hI99gJCI4ff9+fd/
iYCFhYWEhIWFhZCLfI9+goqv1saqjXt8iZWFhYWFhYWFhYKHkJb5+v35rYSF
h4KIhYSDhYOHhIH8+vzZg4WGhIaDhYiChIWBgoKJiYmJiYmIiYmJiYmJiYmJ
fIOFhYmGg4iEhoSHg4D8+eiAhYiFgoeEh4OMf4aAheP6+vz8+/799/79/f79
/f39/P36/P7++fvjhICGgIuDh4iGhoKEiYT095mAhIt9i4KFiYGDi32Kv/z4
/f36/f36/P39/v38/Pz8/Pz8/Pz9/f7+///+/v7+////////////////////
////////////////////////////////////////////////////////////
///////////////9/f79/P38/IWFhYWFhYWEhYj08pWNfIiFgouBgY2Fhez8
+/789v3xiIaChIN5kY/60nyHiYKGioOFg4eEgfz6/Pb1pm+QkXyEg4SFhYWG
hnGW0fX7+/z8q5WCg4qJhYN/i4GEkn2Dv/j9/Pf7gImChYWFhISFhYV/g4aG
hIpuk4uGg4SKioN8hIWFhYWFhYWAh4HC+/f9+K2EhYeBiIWEg4WDh4SB/Pr8
2YOFhoSFg4SGgoOGg4OQg4ODg4OCgoODgoKDg4ODg5CJhomLhoSGhIaEh4OA
/Pn4hYaIf4WGh4iDiYCHgYLO+fr8/P38/f39/f39/v39/f77+v7++/j7zoKB
h4CIg4iEiYSCiIKI9vmqhYWHfYqEg4mDgoqBh6n8+/n8/v79+/z9/f39/f39
/Pz8/P39/f3///39/f39/f//////////////////////////////////////
/////////////////////////////////////////////////////////f3+
/fz9/PyFhYWFhYWFhIaE+tx/jnuIhYKKgoGEhZ759v7+/fv2/KmChYaIfY9/
5dGFh4eDhoqDhYKHhIH8+v3w/NiPgIiOhYWFhYWEhYWYeH2ozdvEl42FgYWI
h4SGf5CEhZF8m/v9+/b2+3+Hh4WFhYSEhYWFjJDDfISThH5+goWIiIeFhYWF
hIWFhYWEjIR97PX+7futhIWHgYiFhIOFgoeEgfz6/NmDhYaEhoOCg4aEiIaL
sdjY2NjY2NjY2NjY2NjY2NjIpIiGhYKFh4SGhIeDgPz5/I+FiH2IhIeGg4WC
i4aFu/j59/v9+/r9/P39/f3+/v3++/3++vX4+7uFhouChoKGgYyCg4x9lPf5
vIaBiIGJhYGJhIGHhYWT+f33+//8/v38/f39/f39/f39/f39/f39/v79/f39
/f3+////////////////////////////////////////////////////////
//////////////////////////////////////39/v38/fz8hYWFhYWFhYWF
fvq7fomBhYh/h4aCeYfF+fX//f399PrVf4mEiYeFhr3OkYaDhYeGgoWDh4SB
/Pr9+vf7z4yChoWFhYWEhYWFgoKQj3x+hn6IhoWGhoSGiY11h41xmuf9/Pr3
+Pt8h4iFhYWEhISFhY+V8Z52hI56i4uJg35/houEhYWEhYWEhISJtvz4/u78
rYOFh4GIhYOChIOHhIH8+vzZg4WGhIWCgIKLg4eEjs35+vv7/Pv7+vr7+/z8
+/r58rOGhISFh4aEhYOHg4D8+f2khIiAiISEhYSFhIuGhKT4/ff3/fz3/f39
/f39/f39/vn+/vb2/f2khIaLg4WEhoGMgYSNfav5+s+FfoiGiYOCiIWChYeE
hOv9+fn+9/79/Pz8/f39/v39/f39/f39/f39/f39/f39/v//////////////
////////////////////////////////////////////////////////////
///////////////////9/f79/P38/IWFhYWFhYWFh3zymoSFhoKJgIWJhXaR
5/z7/vj3/fr68YuJg4SMfY2XxJOFgoeFgoOEg4eEgfz6+f7u/fi6k2+GhoSF
hYWEg4iDgYGGk5OAi4qIhoWEhoiGfYWBi9T88P3+/fv7fYaHhYWFhYWEhYV7
h/beg32DjYWEhIiMiYJ8hYWEhYWFhIV2oPv1+/78+K2EhYiBiIWDg4WDh4OB
+/n72YOFhoOFgoSCjIGFf4fZ+vv7+/z8/Pz8/Pz8/Pz8+vqtgIaJiYqEhIWD
h4OA/Pn6xYOIhIWHgYaGhISHgICM7v399/389Pz9/f39/f39/fz4/v72/v7x
jICBh4SDhoeCioGFiYLK+PnkjH+JiIeDhYWGhYWGhYDK/P36/vX9/Pz8/fz9
/f39/f38/f39/f39/f3+/f39/v7/////////////////////////////////
////////////////////////////////////////////////////////////
/f3+/fz9/PyFhYWFhYWFhIaA24GHhYaAhYOHhoeBoPr9/vr6+vr++/uqhoiD
jYCIg7SJg4aGgYSDhYKHhIH8+vj79/n57MSQhoWGhIWEhIN+i4uEhIKAhIeG
hoSHiIeFfpGJmdj69vb9/f35+oCJgoWFhYSFhIWFiIfu+b2JeIOMhoB/hIiK
iISFhIWFhIWFmM789/j6/vWthIWIgYeEhIKFg4eEgfz5+9mDhYaDhoOHgIl/
ioGA2fr7+/v7+/v7+/v7+/v7+/r3pn6LiYWJhISGhIeDgPz5+euEhoqAioCG
iYWFhYCCgs73/ff9/PP8/fz9/f38/f389/7+9v77zoKCgIWFhYiGhIeBhoSI
6Pf595uHiISChYeDhYiFhYaDofj8/P71/fj8/Pz8/f39/f39/f39/f39/v7+
/v39/f3+////////////////////////////////////////////////////
//////////////////////////////////////////39/v38/fz8hYWFhYWF
hYSGhcl0hYaFgoCHiYKKjaz8/P/1/v32/fj8xoWOhI2JgXuofoKMhX2Hg4WC
h4SB/Pr+8P777/3104aGhYWFg4OEgoh/gI2Fe4d/gIKFiYuHgI2Bmt37/PP9
+/348viEjIKFhYWEhYWFhYl63uf4qpCBfYWMjIeDg4iEhYWFhIWFhdX65P71
/fv8rYSFh4KIhYSDhYOHhIH8+fvZg4WGg4aDin6IgZGJf9j7/P38/f38/f38
/f39/f38+6eBjYV+h4SEhoSHg4D8+fr9hYSMfIyAgomFiIeEiIOs6f31/v31
/f38/f39/Pz8/vf+/PP97KqDiISHh4WIg4aEgoeBjfn3+PynjoeAgIiLgYWK
hISIhoTv/Pz+9v30/fz8/Pz9/Pz9/f39/f39/f39/v7+/v3+/v//////////
////////////////////////////////////////////////////////////
///////////////////////9/f79/P38/IWFhYWFhYWEhYWFhIWFhYWFiomB
jILx+f3+/f39/f38+vmdgYWHgImEhYSFhYWEhIKFg4eEgfz6/f39/f79/fzn
u4p4hI+IeoaHiIeEgoKCf4SIiISDhomay/j8+PT5/fr9/vj5gImDhYWFhIWF
hYWCjcD69vK/g4SGh4N9fYKGfX+Hin59oMv7/Pz+/f39/KqQfYGIhoOCfn6D
ioR8/PX72YOFhoOFgoSDhYaDh4PX+v39/v38/Pv8/Pz8/f3+/Puqh4aFh4KH
hYOCiIV/+/z6+72JhYKEioSEhYWFhYWFgfP87vz1+/39/Pn4+Pn8/f779fzu
/PSBhYWFhYSFhYWHhIWIibv5+/T943+HjX+NhYWFhYWFhIWFwPP89vn+/f39
/Pz8/Pz9/vz7/P38/v7+9/3+/Pz+/f7/////////////////////////////
////////////////////////////////////////////////////////////
/////f3+/fz9/PyFhYWFhYWFhYWFhYWFhYWFhIiHhIWd9vz9/f39/f39/fv2
u3+Mg4WGhYWFhYSFhISChYOHhIH8+v39/f39/v39+/rrwZF4f5GAgoWIioqJ
h4OCf32CkaWz6/b69fT7/f36/f74+YCJg4WFhYWFhYWFgom49/f87s+RiISI
kZKHe5SGfIKVtOD8/Pz9/fz9/fyijX6ChoWDhJCIhoCDhfb4+9mDhYaDhoOF
g4WHg4eD1/r8/f79/Pz6+/z8/P39/fz7qoeGhYeDh4WDgoiFf/v8/fjngYWB
h4SFhYWFhYSFhYuf8/zz/vvz+v3+/f79/Prz+/7z/POfi4WFhYWFhYWFgYiE
iIHm9/39+PSUhn6LgoWEhYWFhIWFf5nN+vz39v79/f3+/fz6+vv6/P3+/v7+
/vn29PH2/f3+////////////////////////////////////////////////
//////////////////////////////////////////////39/v38/fz8hYWF
hYWFhYWFhYWFhYWFhYKGhoh+xvz9/f39/f39/f379uGDkH+IhIWFhIWEhYSE
goWDh4SB/Pr9/f39/f3+/fX2+fnx3cKtj4qFg4OEgoCBi52xyOH3/P39+vb6
/f72+v3++PmAiIOFhYWFhYWEhYiGsfPy/f389dGef3qDiox6hJi11Oz2+Pz9
/f38/f395NfP0tXT0tTTztXI0Mn9/PvZg4WGg4aChYOFh4OHg9f6/Pz9/fz7
+vv7/Pz8/f38+6qHhoWHg4eFg4KIhX/7/Pv3/JeBiYWEhYWFhYWEhYWOe9f7
7vb//vr6+vr6+vr6/v317fvXe46FhYWFhIWFhYKFi4OX/Pf8/vzy1nWLhoOF
hYWFhIWEhYJ+oOD7+fH29fb4+v3+/f7+/v79+vf08v39/f39/fz1/v//////
////////////////////////////////////////////////////////////
///////////////////////////9/f79/P38/IWFhYWFhYWFhIWFhYSFhYWE
hYSKgOn8/f39/f39/f39/Pn5lYmCiISFhYSFhIWEhIKFg4eEgfz6/f39/f39
/f7+/Pr9/Pz17/Xq3NTU19jX5ez2+/v59fPu9/z8/v7/+fr9/fj5gIiDhIWF
hYWFhYWJgq/28/j5/Pz8/Pbq3M/H2uv5/P39/vz8/f39/f39/f379/r6+Pn8
+ff89vr0+Pj82YOFhoSFgoWDhYeDh4PX+vz8/v38+/r6/Pz8/P39/Puqh4aF
h4OHhYOCiIR/+/v4/PzMipJ7iYWFhYWFhIWFg5Sa1fvz/f7+/v78/P39//39
8vrVmpSDhYWFhYSEhYWJfJKLzf38+P398fyQk32KhYSFhYSFhIWJgIat4vv8
7v7+/v7//fz8+/3+/v79/f39/Pby9/r7/f7/////////////////////////
////////////////////////////////////////////////////////////
/////////f3+/fz9/PyFhYWFhYWFhYWFhYWEhIWFhIWDi5X8+/v9/f79/f39
/f3+/LWAhoSHhYSEhYSFhISChYOHhIH8+v39/v39/f39/v3++fLx+P39/fbz
9/v8/Pv7/P39/f39+v3++vf5/v76/f74+YCJg4WFhYWFhYWFhn2t/P3++/3x
9vf18PH5/Pf9/ffu8fb1/Pz9/f39/f339vf59/b3+fz2++n59/H8/NmDhYaE
hoOFgoWHg4eD1/r8/f7+/fz7/Pz9/f39/vz7qoeGhYeDhoWDgoiEf/v7+vv0
9rSPeoiFhYWFhYSEhXuVc5fs/Pzx9vz9/Pz+/Pbx/Pvrl3OVe4WFhYSFhYWF
iXqPtPf0/Pv98/7114qCiYWFhIWEhYWFhISAi7Pm+/z3+Pj4+fv+/v7+/vf2
+vv4+P38/f318P3+////////////////////////////////////////////
//////////////////////////////////////////////////39/v38/fz8
hYWFhYWFhYWFhYWFhYSFhYSHg4m6/fj6/f39/fz9/P38/vvahomCh4WEhIWE
hYSEgoWCh4SB/Pr9/f3+/f39/PTy8/v9/fvy+ff4/P39+/n9/fv49vb3+P39
+fn8/f37+v39+PqAiYOFhYWFhYWFhYp/rPz+/v39/f39/f389vLu9fj6/v7+
/Pz8/f39/f39/f38/f7+/f39+vnv+fz5/fzZg4WGhIaChIOFh4OHg9f6/P39
/v79/Pz8/v39/f39+6qHhoWHgoaFg4KIhX/7/Pv5+Pznm4WBhYWFhYWFhIWF
gIl7oeXy/fv8/PX1/P/8/fLloXuJf4aFhYSFhYWFhYOFmeX9+fr8+Pz79fWo
ioSFhYSFhIWFhYKBgoKJocvt+vv9/v7+/fz9/v75+P39+f388+zkyszy/v//
////////////////////////////////////////////////////////////
///////////////////////////////9/f79/P38/IWFhYWFhYWFhYWFhYWF
hIWDiIOI4/34/v39/f38/Pz9/f759pqGhoSFhYSFhIWEhIKFgoeEgfz6/P39
/f39/fz9/f348PH7/fv7/f39/fr39/n9/f39/fr49vj9/f369/r9/ff6f4mD
hYWFhYWFhYWKg6/59/v6+/z6+fv9/fv2/f739Pb7+/f8/P39/f39/fj6+vr5
+fj3+fz6/Pv4+fT82YOFhoOGg4WDhYeCh4PX+/z8/f39/fz9/f38/Pz9/fuq
h4aFh4OHhYOCiIV//Pv5+v37+c6TgoWFhIWFhYSFjH6XgnSiyOj3/P39/f7+
+OjIonSCl3+MhIWEhYWFhYWEk8v2+/37+vT97f303quEhYSFhYSFhYWGgoOF
fHmRsPD0+/39/Pfz8fr9+fr8/Pjj0auVjH+o+/7/////////////////////
////////////////////////////////////////////////////////////
/////////////f39/f39/PyFhYWFhYWFhYWFhYWFhYWEgIqEiPz8+f79/f39
/fz8/fz7+fyugYuChYWFhYWFhIWDhIOHhIH8+v39/f39/f399/b4/P39+/b9
/fz7+vz+/v38+/v7+/r4/P39/ff0+v36/f74+oCJg4WFhYSFhYWFgYGz+/j9
/fz3+fv6+fr9/fP3/v79+vr8/f39/f39/f39/Pz8+/z7+fr99vz29P34+9mD
hYaEhoKFg4WHg4eD1/v8/Pz8/P38/f39/Pz8/P37qoeGhYeDhoWDgoiFf/z8
7vv9+vL8mYqFhYWFhYWFhIOJe4+LeJCXvtjx/Pzx2L6XkHiMj3uJg4WFhYWF
hYWFjZn77/v9/e71/vnv/PXdhIWFhYSEhYWFiYWFiIiFgYCAka7M5vT8/Pn8
9N/LvKmWj46EiIp5ovv9////////////////////////////////////////
///////////////////////////////////////////////////////+/v39
/Pz6h4eHh4eHhoeFhYWFhYWFhYmIgrz0/f7y/Pz9/fz8/P36+/325nyEi4WF
hYWFhYWFhY2BgoN6+fv+/v7//v/+/v7+/v7+/v7+/v7+/v7//v7+/v7+/v7+
/v39/v38/Pz9+/38+PuBiYKEhYSEhIWFhYSJqvn8+Pz9/f39/v7+///+////
/v7+//3+/v79/Pz60qmqrqivrayurbCtrqT8+frSiIWCgYSUeoiEiIKDiNL8
+/v7/P39/Pz8/f39/Pz88rSNh35+iIWCjH+Cg3z8/vr+/vj+/uS9hIOCgoOF
hoeIhoOEhoaGhISFhYWFhYWFh4eIhoSDhIWHhoWCgoKDhbvi/Pv4/v36/v39
+v3879+DhoiHhYaJi4KFiYuKhoOBhYWFhYWFhYSGhYODhISEhI2AfIiJhbD0
/v//////////////////////////////////////////////////////////
///////////////////////////////////+//38/Pv7+YWFhYWFhYSFhoaG
hYaGhoaHjYTc9ff9+/z7/f38/Pz9/vj8/PighYmGhoWGhoaGhnyIgomQh/z5
/v////////////////////////////////////////79/f39/Pz8/fv9+/j6
gYmChYWEhYSEhYWEiar5/Pj8/f7///////////////////38/f39/fz8+qyD
hIeBiYaFgoKFho6N9fP71IiKjIh5eY6RhomDhInV/Pz7/P39/Pz8/P39/fz9
+/KthoyOjoyAe4aAipCI/Pr6/v35/v7+7KiShIeLhoGDhISFhoeEf3uFhYWF
hYWFhX2BhYeHhIOCgoKGi4aEkqjq/P79+P39+v3+/fr+/frxxpd6hYx9eYWJ
h4J/foGHi4WFhYWFhYWFhYSEhISFhoWAhImLgoCw9f3/////////////////
////////////////////////////////////////////////////////////
/////////////////f79/Pz8+/mGhYaGhoaFhoaHh4aHh4aHf4OO/P36+vn8
+/39/Pz8/f36+f38vn2Fh4eHh4eHh4eJioCAhoL29P7/////////////////
///////////////////////+/f3+/fz8/P37/fz4+oGJgoWFhYWFhYWFhImq
+fz4/P7+///////////////////9/P39/f38/PmshIWIgomHhYaCg4CIi/n6
+Mp8f4aLg4aIhnuFg4KG1fz8/Pz9/fz8+/z9/v79/fv5q32Cg4OHg4mKgICG
gvX0/P3++/z+/v33t39+j4+HiIyJhYOEh4iIhIWFhYWFhIWJiYeEg4SJjIaI
kI99f7b4/P3++vr9/fz+/v36/f39/PzOlHyBiYeBhYeLjY2JhICFhYWFhYWF
hIODhIaGhoWFhouKhXuAtvn9////////////////////////////////////
//////////////////////////////////////////////////////////39
/v39/Pv5hISEhISDhIODg4ODgoOCg42BsPz9/vj5/Pv9/f38/P35/fz899uF
h4ODg4ODg4ODhoWAfoSI+/3+////////////////////////////////////
/////v39/v38/Pz9+/389/qBiYKFhYWEhYWFhISJqvn8+Pz+/v//////////
/////////fz9/f79/Pz5r4eHioSLiIeLiIZ/hYb1+vzYjIaChYOLg4N+jYuE
htb8/fz9/fz8+/v9/f7+/f37+bCFiIF9iI6GhYB+hIf5/Pv7/f399/f68fvg
lXCEkYOHhYKCg4SCg4WFhIWFhYWFgoODgoKDhoiCkINvlN788fn29/z+/fz7
/v7++/n6/Pz0++u5h3iDjomHg4GAgH9+hIWFhYWFhYWChIaGhYSEhIeDf4OC
grDw/f//////////////////////////////////////////////////////
///////////////////////////////////////9/f79/fz7+YWFhYSFhYWF
hISDg4SEhISSh+Xz9fz3/fz8/f39/f397/39+fn4noGEhISEhISEhISDioOD
hO/2/v////////////////////////////////////////79/f79/Pz8/fv+
/Pf6gYiChYSFhYWEhYSEiar4/Pj8/v7///////////////////38/f3+/v38
+aqBgYR+hYKBgoCCfoOF8/n20YmGhYmBgoKFf4qEfoHR/P39/f39/Pz7/Pz9
//39+/Ksho2Jg4aEhoWLg4SD7fP59/r9/fz7/f3z8fTHgXCNgoWKjpCLg3yE
hIWEhISEhHyCi4+PioWCjG+AxvHw8f39/P3//vv4+v3+/v77+Pj6+/f7+deg
goGEhISHiYiEgISEhISFhYWFg4WGhYOBgoOHgYaUkIex9v3/////////////
////////////////////////////////////////////////////////////
/////////////////////f3+/f38/PqJiYmJiYiJiIqKioqKioqKcon8+P36
9/38/P39/f38/Pf9+Pj6/LNzioqKioqKioqNhYt/ho/4/f7/////////////
///////////////////////////+/f39/fz8/Pz7/vz3+oGJgoWEhYWEhYSF
hImq+fz4/P7+///////////////////9/P39/v79+/mwh4eKg4qHhYeGioaK
ivf8/NOBfISQiYaDiH+EgoWL1/z9/f39/fz7+/z9/v/9/fv8toSChIeIfY6G
jIGGjvb9/fr4+vz8/f33/vz1+fLCiYiEgH6AhYiKhYWFhYWFhYWKiYWBfn+D
h4jB8Pbz+fz2/v38/Pv5/P78+/79/fv7/f707fr88cWfkIqDgYOFhYSFhYWF
hYWFhYOGh4WBgIOGg4KChHp4sfv+////////////////////////////////
////////////////////////////////////////////////////////////
//3+/v39/Pz7g4ODg4ODg4OEg4SEhISEhJC3/P3++fr5/f39/f39/Pz9/ff8
9vnZnISEhISEhISEgnWDfoyX8/b+////////////////////////////////
/////////v39/f38/P38+/789/qBiYKFhISFhIWFhYOJqvn8+Pz+/v//////
/////////////fz9/f3+/fv5rYSFh4CHhIKFhYiChYTx9vHRi4SBhoGCg4uB
hYmQi8X8/f39/f38/Pv8/f/+/f375q2Ign6GjoSCdoN+jJfy9v3+/Pj2+Pn7
8vz+/v389eazppODfH6DhoWFhYWFhYWFiIR/fYOSpbLk9Pz8/f368Pr6+Pb5
/v///vr7/f79/P3s/v748fv988+5m4R8gIiOhYWFhYWFhYWEhoeFgoOJjoON
jYmKl8P3/v//////////////////////////////////////////////////
///////////////////////////////////////////+//39/fz8+/n5+fj4
+fn5+Pf39/f39/fy/PD1/fP99/39/f39/f39+/z5/fP0/Ov4+Pj5+fn4+Pju
+/n54v3w//////////////////////////////////////////79/f39/f39
/fv+/Pf6gYmChYWFhYWFhYWEiar5/Pj8/v7///////////////////79/f7+
/v37+a6FhoiBh4SDgoKHgoeJ+P32/e77+Pb1/PP78/T2+eL8/f39/f39/fz7
/f3+/v39/P3x+Pz09Pv2+O78+vni/vDz/v39+/39/v79+fn7/fz8/Pflz7ef
jICFhYWFhYWFhYOOobfP5PT7+/z8+fb3+/39/f78/v7/9f76+Pz++vr9/vf0
+/36+v37+vTr2LqYgoWFhYWFhYWFgoWHhYOGjpWhvM3Y7Pv7+/7/////////
////////////////////////////////////////////////////////////
/////////////////////////f39/f38/f39/Pz7+/z8/P39/fz8/Pz8/Pz8
/f38/P3+/v7+///9/v39/Pz9/fz8+/v8/Pz7/Pv8/Pz8/P39/f7/////////
///////////////////////////////+/f39/f39/f389f36/IKNg4aFhoaG
hoWGgXm0+v38/fz+///////////////////+/f39/v79/PuqkH6BiIaDg31+
g4yGfvz2/f38/Pv8/f38+/v7+/z8/f39/f39/f79/f39/f39/f39/Pz8/Pz8
/Pz8/Pz9/f39/f39/f7+/f78/fz9/fz8/Pv7+vr6+vr63NrW1NTW2tz6+vr6
+vr6+/7+/v7+/v7+/v7+/v7+/v79/f39/f39/f39/fz8/fz9+/v6+vr6+vry
5tfS1NfU0NDX4u31+fr5+/v7/Pz9/P3+////////////////////////////
////////////////////////////////////////////////////////////
//////39/f38/fz9/f39/f39/Pz8/f39/f39/f39/f39/f39/v7+/v/+/f79
/f39/f39/f39/f39/f39/fz8/f79/f3+////////////////////////////
//////////////39/f39/f39//778u2Ei4GEhISEg4SEhIyEs+z08fn2/v//
//////////////////39/f79/fz8oo1+goeFg4SPiIeChYf4+v39/fz8/f39
/f39/f39/f39/f39/f39/f79/f39/fz9/f39/f39/f38/P39/f39/f39/f39
/f39/f39/f39/Pz8/fz8/Pz8/Pz7+ff3+fv9+/v8/Pz8/Pz+/v7+/v7+/v7+
/v7+/v7+/f39/f39/f39/fz8/Pz8/fz8/Pz8/Pz8/v749/r9+/f09vj7/P38
+/z8/P39/f39/v//////////////////////////////////////////////
///////////////////////////////////////////////9/f39/f39/f39
/f39/f38/Pz8/P39/f39/v79/f39/f/////+/v7+/f39/f39/f39/f39/f39
/f39/f39/f39/v/////////////////////////////////////////9/f39
/f39/f7++f39zNjY0tLS0tLS0tLTyeH9/P3+/f7////////////////////+
/v39/f39/OTXz9LV09LU0s7WydLL/f39/f39/f39/f39/f39/f39/f39/f39
/f39/f39/Pz9/f39/f39/fz8/f39/f39/f39/f39/f39/f39/f39/f39/f39
/f39/f3+/fz8/Pz9/vz8/Pz8/Pz8/f39/f7+/v7+/v7+/v7+/v39/f39/f39
/P39/f39/P38/Pz8/Pz8/Pz7+/z+/v79/f39/fz9/f39/Pz9/fz8/f7/////
////////////////////////////////////////////////////////////
/////////////////////////////f39/f39/f39/f39/f39/fz8/Pz8/f39
/f39/v39/f3+///+/v7+/v39/f39/f39/v7+/v7+/v79/f39/f39/f7/////
/////////////////////////////////////f39/f39/f38//f9/fT7/Pv7
+/v7+/v7/Pf9/fr9/vn//////////////////////v79/f39/P3++/j7+/j5
/Pj4/Pn9+fr5/f39/f39/f39/f39/f39/f39/f39/f39/f39/f38/f39/f7+
/f39/f39/f39/f39/f39/f39/f39/f39/f39/v7+/v7+/v7++/z8/f38/Pv8
/P39/f39/f39/v7+/v7+/v7+//7+/v7+/f39/f39/f39/P38/Pz9/fz8/P39
/f35+/z8/Pv6+vr5+Pj5+/39/Pz8/fz9/P3+////////////////////////
////////////////////////////////////////////////////////////
//////////39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/v///v7+
/v7+/f3+/f39/f7+/v7+/v7+/f39/f39/f3/////////////////////////
//////////////////39/f39/f39+f70+vz7+vz5+fn5+fn5+f38/Pr3+/76
//////////////////////39/f39/f399/b4+fj29/n79vzr/fvz/f39/f39
/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39
/f39/f39/f39/f39/f3+/v79/f39/v3+/f7+/v79/f39/f39/f3+/v7+/v7+
/v7///7+/v7+/v39/f39/f39/f39/f39/f39/f39/f39/v7+/fv6/P39/Pz8
/Pv6+fz9/P39/f39/v//////////////////////////////////////////
///////////////////////////////////////////////////9/f39/f39
/v39/fz9/fz9/f39/f39/f39/f39/f39/f7+//7+/v7//f38/f39/f39/v39
/f39/f39/f39/f39//////////////////////////////////////////78
/f39/f39/fj++fr+/v7+/f39/f7+/v7+/v78/f7+/v//////////////////
///9/f39/f79/f39/v79/f39/fv68Pz++v79/f39/f39/fz9/fz9/f39/v39
/f39/f39/f39/f39/f39/f39/f39/f38/P39/f3+/v39/f3+/f38/f39/f39
/f39/fz9/fz6+vv7+/v6+v7+/v7+/v7+/v3+/f7+/////v7+/v7+//39/f39
/f39/f3+/v79/f3+/v7+/v7+/vv6+ff3+Pv9/Pz9/v39/Pv9/f39/f39/f7/
////////////////////////////////////////////////////////////
/////////////////////////////////f38/Pz8/P39/P38/Pz8/Pz8/Pz9
/f39/f39/f38/Pz+/v/+/f3+/vz8/P39/Pz9/fz8/Pz8/f39/f39/f39/P7/
///////////////////////////////////////+/Pz9/f39/f39/v72/fXv
8/j4+Pj4+Pj4+/36+Pz49Pn//////////////////////f39/f3+/f34+vr6
+fn49/r8/P7++/v1/f39/f39/v39/Pz9/f39/fz8/Pz8/f39/Pz9/f39/f39
/Pz8/Pz8/Pz8/P39/f39/Pz8/P39/f38+/z8/P39/f39/f38/Pz8//7+/v7+
/v7+/v7+/v7+/v79/v3+/v7+/v7+/v7+/v/9/P39/f39/f39/f39/f39/v7+
/v7+/v7+/v79/v7+/vf4+vz9/v7+/fz8/Pz8/f3/////////////////////
////////////////////////////////////////////////////////////
//////////////38/Pz8/Pz8/fz8/Pz8/Pz7/Pz8/P39/f79/f39/Pz8/v7/
/v39/v78/Pz9/fz8/fz8+/v7+/v8/f39/f39/f3+////////////////////
/////////////////////vz8/f39/f39/Pn+9f77+v38/P39/f39/fr8+fv+
/Pj+/////////////////////v39/f39/v39/fz8+/v8+vn5/Pf++fb++vz9
/f39/f39/Pz8/P39/f38/Pz8/P39/fz8/f3+/f39/Pz8/Pz8/Pz8/Pz8/f39
/Pz8/Pz8/P39/Pv7+/z8/f38/Pz8+/v6/P38+/v7+/z9/v7+/v7+/v7+/f7+
/v7+/v7+/v7+/v7//fz9/f39/f38/Pz8/f39/f7+/v7+/v7+/v38/P38+vj9
/f78+/v7/P38/Pz8/Pz9/v//////////////////////////////////////
//////////////////////////////////////////////////////8KZW5k
c3RyZWFtCmVuZG9iago3MyAwIG9iagozNDAxOAplbmRvYmoKNzQgMCBvYmoK
PDwgL1R5cGUgL1hPYmplY3QgL05hbWUgL1I3NCAvU3VidHlwZSAvSW1hZ2Ug
L0xlbmd0aCA3NSAwIFIKL0NvbG9yU3BhY2VbL0luZGV4ZWQgL0RldmljZVJH
QiAyNTUKPDAwMDAwMDAwMDBjZTAwMDdkMjBkMGUxNzk4MGYwMDBjMTcyNGEw
MTcxMDEzMTgwOTAwMWNkOTEwMWQyYmE3MWUxZTFkMjIwZTFkMjMyODFkMjcx
MDI0MjkwZTBiMmEzYzFiMmFkOTIyMmQzNjExMmY0MDJjMmYxMDI4MzIxMjJj
MzIzYzJmMzI4OWFkMzQzMzMzMzUxMzFkM2E0OTJjM2E0YTMwM2ExMjNiM2Ix
MjNhM2Q5MjM0NDA5MWIzNDA0MTM3NDFlMDQzNDMxNzJkNDU3NTQzNDY0Nzcz
NDgwZTFiNDk2YTRjNDkxMzNiNGI5YzdhNGQxMjQ1NGVlMTU1NTExN2I4NTI1
MzQwNTM4YzIwNTU3YTU0NTc1NzVlNTgxNDlkNTkyMDhhNWMwZjI4NWQ3ZTU3
NWRlNjM3NWVhZjZiNWUwYWMwNjA2NzQ5NjE5ZmEwNjExNjY4NjIxNDMwNjY4
OTY1Njc2ODY3NjgzYzc0NmEwZjMzNmU5ODU1NmZhMzVmNmY0YTZhNzFlODdl
NzIxMDQxNzRjM2M1NzQ2ZjdiNzgzNDNlNzlhOTZiN2E0Mzg1N2ExMTMzN2Jj
NzVjN2RhZDczN2VlMTdhN2ZmNWNlODE4NzQ3ODNiYjc3ODRjMzhlODYxMjM1
OGFkNmM1OGEyYTg5OGI1Mjg5OGM4ZTQ4OGVjYTg3OGVmNTljOGYxMDgzOTQ1
MmQzOTQ5MjhjOTVkYjRiOThkM2ExOTk1OWFiOTkxMTk4OWIxZDlhOWM5ZTU1
YTFkYmQ5YTJhYmI4YTMxMzM4YTVmMjk0YTU1OWEwYThmNDQyYTllMGMwYWM1
ZmE5YWRiM2MyYWQxMWUzYjNiODU3YjVlN2EyYjg2OGNjYjgxMWI3YjkxY2I5
YmRkNzY2YmZlZWQ1YmYwOWNmYzA4M2M1YzMxMGJjYzU1N2RjYzdjZGIyY2E5
ZmRiY2EwZTgzY2VmMmRiZDdhOWRiZGFlZGE4ZGNmNWVjZThiZmU3ZWFmNmY0
ZjVmYmZmZmZmZjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw
MDAwMDAwMDAwMDAwMD4KXS9XaWR0aCAyMDEvSGVpZ2h0IDkxL0JpdHNQZXJD
b21wb25lbnQgOAo+PgpzdHJlYW0Kf39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39+fH5+fn9/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f35+
fX18fn9/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/fn59fX19fn9/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39+fn9/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f35+fn19fH1+
fn9/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/fn5+fn5/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/fX9/f39/f39/
f39/f39/f39/f39/fn59fH19fX1+fn5/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f35+fn5+fn5/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/fX99fn5/f39/f39/f39/f39/f39/f39+fn19fX19fXx+fn5/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/fn5/f39/fn58f39/f35+f39/fnx/fn5+fn5+fn58f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f399f31/fn5/f39/f39/f39/
f39/f39/fn58fX19fH19fX1+fn5/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39+fn5/f39+fn5+fnx/fn5+f39+fn5+
fn5+fn5+fn5+fn9/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/fX58fX1/fX9/f31/f39/f39/f39/f35+fn59fX19fX18fX18fn5+f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f35+fn9+
fn5/f35+fn5+fn5+fn5+fH9+fn5+fn5+fnx+fn5+fn9/f35+f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f399f319fX19f318f399fH9/f39/f39+
fn5+fn19fXx9fX19fX1+fn5+f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39+fn5+fnx+fn58f35+fn5+fn5+fn5+fn5+fn5+fn5+
fX19fn5+fn9/fn5+f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f35/
fX19fXx+fn5/fX99f358f39/f35+fn59fH19fX19fH19fX5+fn5+f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/fn5+fXx9fn5+fn5+
fn5+fn5+fn5+fn5+fn5+fn5+fn59fX19fn5+fnx/fn5+fn9/f39/f39/f39/
f39/f39/f39/f39/f39/f39/fnx9fXx9fX1/fX99f31/fX99f3x/fn5+fH19
fX18fX19fX18fX5+fn5+fn9/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39+fnx9fX19fn5+fn5+fn5+fn5+fn19fn5+fn5+fn5+fH19fH1+
fn5+fn5+fn5+fn9/f39/f39/f39/f39/f39/f39/f39/f39/f39+fn19fX19
fX99f31/fX9+fn5+fn5+fn5+fX19fX19fXx9fX19fXx+fn5+fn9/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/fn5+fX19fX19fn5+fn5+fn5+
fnx+fX19fH5+fn5+fn59fX19fX18fn5+fn5+fn5+fn9/f39/f39/f39/f39/
f39/f39/f39/f39/f31/fX19fH19fH1/fX99f31/fX99f35+fn99fX19fH19
fX19fXx9fn5+fn5+fn9/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39+fn18fX19fH1+fn5+fn5+fn5+fn19fH19fn5+fn5+fH19fXx9fX19fn5+
fn5+fn5+fn5/f39/f39/f39/f39/f39/f39/f39/f39/fn99fXx9fX19fX99
f35/fX9+fn5+fn5+fXx9fXx9fX18fX19fX19fn5+fn5+fn5/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f35+fX19fX19fX18fn5+fn5+fn5+fX19
fX1+fn5+fn59fX19fX19fH1+fn5+fn5+fnx9fX5/f39/f39/f39/f39/f39/
f39/f39/f39+fn19fX19fX19f31/fX99f31/fX99f359fX19fX19fX19fX19
fH1+fn5+fn5+fn5/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39+fn59
fXx9fX18fX19fn5+fn5+fn18fX18fX1+fn5+fXx9fX19fH19fX1+fn5+fn5+
fX19fX5/f35/f35+fn9/f39/f39/f39/f39/f35/fX18fX18fX18fX99f31/
fX5+fn5+fXx9fXx9fXx9fXx9fXx9fX1+fn5+fn18fX5/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/fn5+fn19fX19fX19fX19fn5+fn5+fX19fX19fX1/
fX99fX19fXx9fX19fX5+fn5+fn59fX19fn5/fnpvZWVvfX1/f39/f39/f39/
f39/fn59fX19fX19fX19f39/fX99f399f359fX19fX19fX19fX19fX19fX5+
fn5+fX19fX5/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39+fn5+fX19fX19
fX19fX1+fn5+fn59fX19fX19fX9+fn19fX19fX19fX19fn5+fX5+fn19fX19
fn9/elYgCAEgS3p+f39/f39+f35+f39/fn19fX19fX19fX19f399f31/f31+
fn19fX19fX19fX19fX19fX19fX5+fn59fX19fX5/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/fn5/f39/f39/
f39/f39/f39/f399en1+fnp6fn59dXV9en5+fn11fn59fX1/enV9f31/fnp1
fXp9fXp6fX5/en5+enV/dXp9fXV/fn19em9aSzMpIG9/f39/f35+fX19f35/
fXp9fn16dXp6fX1/f399dXp/fX96dXp9fX16dXp6fX11fX5+fXp9f35+fX59
dX19fX5/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39+f39/f35+fn5+f39/f39/f39/f39/f39/f31vb356fVp1en1vWm9v
b3p9fWVven1lWm99em9len99fWhab29vem9vf316ZXp9b291b296b296enpl
b3VvWlYpEFZ6fn9/fn1vb29lb3p9b299fWVvaG96en1/f396Wm9vf3plb3V9
en1vb09venpvb31/fVp1fX56Wm9ab3p9fn9/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39+fn99fn5/fn59fH5+fn9+f39/f39/
f39/f39/fnozKX1lTBApTExBEBAgM299KSAQb28QECB9WhAgVn9lMxAQARAz
bykzfXpoEDNlICl1MylvSxBoZVYpM39lKRABAUFlfn9+fUEQIDMpQVp6QSlv
VhABECloen9/f39lEBAzf1opEEx9dVoQARAQT1ogM2V9ZRBPb31MEAEQEG9/
fn9/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39v
VktMVn1+fn19fX56Wlplen5/f39/f39/f39/f30zIGVWKRAQMzMgARAgKVZ1
ICBPemUQARBWMwEQM3pMIAggKRAgWiAgZXplEBApKUt9MyBaMxBLWm8gIHVB
ICkgASllf39+fUEQS1YzM0F9MxBaMwEBECBBb35/f39aAQggfUEQASBWWjMB
MzMIKTMgKUt9bxBBWkwzECAQAVp9fn9/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/fn1aIAEBIG99fX19fXplKSApb31+f39/f39/
f39/f34pIFozEAEQECAQARAgEFpvEClvfWUBEBAgEAEIIFozIAEzTBAgVhAQ
TGVlEAEIKVp/QRBMMyApWm8gIG8pEEwpCCBMf39+ejMQZWVMIDN9KRAzIAEI
ECAzVn5/f39WAQEgVjMgEBAzQSkBTFoBECApICllZSkzMykgKTMpAVp1fn9/
f39/f31+fX9/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/fW8gAQEB
EDNlfX19fVopEBAQKVp/f39/f39/f39/f39LKTMQECAgEDMzARApEEtvICBM
ZUwCTE8QEBAzKRApIAggMxAQTCAQEEtoEAEBEEx/TCAzMzMQIEwQIGUpASkg
AQhBf39+fUEQS1ZlEBBMIBBMKQEIEBAgQX1/f3VaASAzICAgMykQQTMBICAQ
ICAzKQEzQTMpKSkQECkpATNlf39/f31+f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f399ZU8QAQEBARBLfX19fVogEBAQKWV/f39/f39/f39/
f35aKRAQEEwpAUFMECAgM1pvKRAgMzMQWm8gICBWTBAzMxAgIBAzZUEQECAz
IBAQIDNvVkEzS0sgECAgTG9BIBAQEBBBf39+ejMIIDNWEBAgECllWikQCCAz
ZX5/fXVaAUxBEBAgWikQKSkgEBAQIEFaQRAgKTMgIEEgASAQCDNafn56em9v
ZWVlZW99f39/f39/f39/f39/f39/f39/f39/f39/f39/f359TAEBAQEIAQEp
Wn1+fXpLAgEQTHp/f39/f39/f39/f39lQQEBIG9WAWhaQSAgb3pvKQEBIDMQ
ZX1MQUx6ZSBMVjMQECBMfWVBMxAQKSkgIDNBVmVBWmUzEBBMb31lKRAgKSBM
fn99ZTMBASBMIAEIIFZ9fG8gICBvfn9/f3VPAW9lCAEQb08gIEFBIBAITG91
WikgM0EQIHpMEBAQECBMf3pqVkxMKSkpIEF6f39/f39/f39/f39/f39/f39/
f39/f39/f39/fm9LEAEQEDMpEAEQEGh6fX16QUtMfX1/f39/f39/f39/f391
QQEQM3pWAVplem9vfX59bykBVm96en56enp9fXp6enpvb296fn16em9lTCAQ
ZXp6emUpZXp6b296fX99emVvem96fn9+fWVBKUx6IBBBZXp+fnx6ZXp9f39/
fnVBCGVvIBAQYWVBECl6ZW9ven19em96b28gIG96b29lQSAzfXp1VkxBIBAQ
IDN9f39/f39/f39/f39/f39/f39/f39/f39/f39/emUgEBAgM1pLSyAQEE9a
fX19em96fn9/f39/f39/f39/f399byBBWn1lIGV6f39/f39+em8pen5/f39/
f39/f39/f39/f39/f39/f399ZUwgen5/fW9BZX5+f39/f39/f39/f39/f39/
f3pvTGV/TClaen1+fn5/f31+f39/fnxaIHV6VilPb3plQVp9fn9/f39/f35+
fn5MKW9+f396ZSlBfW9aM0FBEBAgIEF6f39/f39/f39/f39/f39/f39/f39/
f39/f39/ZSkBEDNab29vaFozEAEzan59fX1+f39/f39/f39/f39/f39/fXV8
fX5+en19f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/fWVWen9/
f3pMZX9/f39/f39/f39/f39/f39/f39/f39+b2V1fX1+fn5/f39+f39/f359
dX1/fXV1fn5+dXp+f39/f39+fn5+fn5lTHp+f39+fWVlfVYQCBAgKTNMM0F6
f39/f39/f39/f39/f39/f39/f39/f39/f3plMxApT29LTCAzM1paSyAgM296
fX1+f39/f39+fn5/f39/f39/fn19f39+fn5/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/fX16fn5+fn56en5/f39/f39/f39/f39/f39/f39/
f35+fX19fX5+fn5/f31+f39/f39+fX5/fn59fn9/fX1/f39/f35+fn5+fn59
en5+fn5+fnp6fnplZWVvb296b299f39/f39/f39/f39/f39/f39/f39/f39/
fW9BICBMaFozEAEBIEtaWkwgEFpvfn5+f39/f35+fX1/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f35+f39/f39/f39/f35+fn5+fn5/
f39/f39/f39/f39/f39/f39/f39+fn5+fn5+fn5+fn5/f39+fn9/f39/f39/
f39/f39/f39/f39/fn5+fn5+fn5+fn5+fn5+f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/b0wQKVpoWiAQAQEBARAgWmFaQSlLen5+
f39/fn59fXx/f39/f39/f39/f39/f39/f35/f39/f39/f39/f39/f39/f39/
fn5+f39/f39/f39/f31+fn5+fn5/f39/f39/f39/f39/f39/f39/f35+fn5+
fn5+fn5+fn5/f31+fn9/f39/f39/f39/f39/f39/f35+fn5+fn5+fn5+fn5+
fn5+f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f3pvSzMz
VlpBKRABECkgEAEQIE9aZUszT299f39+fn19fX19f39/f39/f39+f35+fn99
f35+fn5/f39/f39/f35/fn5+fn5+fn9+fn5/fn5+f35/fn9+f35+fn5+f39/
f39+fn5+f35+fn9+fn5/fn5+f35/fn5+fn5+fn5+f35/fX9/f39/f35+fn5/
fn5+fn9+fn5+fn5/fn5+f35+fn5/fn5+fn9/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/fXpLKTNaVkwgAQEIKWVBIAgBASBLb1pPKVp9fn5+
fX18fX1/f39/f39/fXp6enp9enp9enp6fXp9fn9/f316fXp6enp9enp9enp6
fXp6en16enp6enp6enp6fXp9en1/f396en16enp9enp6fXp6en16enp6en16
en16en16enp6fXp9f39/enp6fXp6enp9enp6fXp6fXp6en16enp6fXp6enp9
enp9fn9/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39+b0spWmhaMxAI
AQEgS316TwEBARAQQW9vMzNPb399fX19fX99f39/f39+ejMgIBAgECAQIBAg
EExvfX9/fmUpECAQIBAgECAQIBAgECAQIBAgECAQIBAgECAQIBAgQW99fn1L
IBAgECAQIBAgECAQIBAgECAQIBAgECAQIBAgECAQIEx6fX9lKSAQIBAgECAQ
IBAgECAQIBAgECAQIBAgECAQIBAgEClWfn9/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f35vS0tPWm8zEAgBAQEpWn56bwIBAQECIEFab0EzTGV6fX19
fX1/f39/f39+bykQAgICAgICAgICATNlfn9/fmUBAgICAgICAgICAgICAgIC
AQIBAQgBCAIBAQgBAQEBKWV9f34zAQICAgICAgICAgICAgICAQIBAgICAQIB
AgEBCAEIEDNvfX9lEAIBAgICAgICAgICAgICAgECAQIBCAIBAgEIAQEBARBB
fn9/f39/f39/f39/f39/f39/f39/f39/f39/f39+fmVBKU91ZUEIAQEBAQEg
Wn99bwEBAQEBASBBb28zIE91en19fn99f39/f39+bykQAQECAgICAgICATNl
fn9/fmUBCAECAgICAgICAgIBAgECCAEIAQEBAQEIAQEBCAEBKVp9f30gCAEC
AgICAgICAgICAQICCAEIAQEBCAEIAQgBAQEBEDNvfX9lEAEIAQICAgICAgIC
AgIBAggBCAEBAQEIAQEBCAEIARBBfn9/f39/f39/f39/f39/f39/f39/f39/
f39/f359VjMgTGVlQRABAQEBAQEgWn98bwEBAQIBAQIgM2VvMykpb3p/fX5+
f39/f39+dSAQCAICAgICAgEIATNlfn9/fWUBAQICAgICAgICAgEIAQgBAQEB
AQEIAQgBAQEIAQEBKWh9f30zAQgCAgICAgICAgIBCAIBAQEBAQgBAQEBAQEB
AQgBEDNvfX9lEAECAgICAgICAgICAgEIAQEBAQEBCAEBAQgBAQEBARBBfX9/
f39/f39/f39/f39/f39/f39/f39/f39+fnpaKSkpX2UzEAEIAQEBAQEQS396
WhABAQEBAgECIEtaSzMQT2h+f399f39/f399bykQAQICAgICAgICAjNlfn9/
fWUBCAECAgICAgICAgECAQEBCAEBCAEBAQEBCAEBAQgBKWV9fn0pCAECAgIC
AgICAgICAQEIAQEIAQEBCAEBCAEIAQEBEDNvfn9lEAECAgICAgICAgIBAgEB
AQgBAQgBAQEIAQEBCAEBCBBBf39/f39/f39/f39/f39/f39/f39/f39/f35+
flYQATNaZUEIAQEBAQEBAQIQQX91WgEBAQEBAQIBARBLYVoQECBven9+fn9/
f39/bykQAgICAgICAgICATNlfn9/fWUCAgICAgICAgICAQgBAQgBAQgBAQgB
AQgBAQEIAQEBKVp9f30zCAECAgICAgICAgIBCAEBCAEBAQgBAQgBAQEBAQgB
EDNvfn9lEAgBAgICAgICAgEIAQEIAQEIAQEBCAEBAQgBAQgBARBBfn9/f39/
f39/f39/f39/f39/f39/f39/fnpvMxAQM09aMyABCAEBAQEBAQEgS396WhAB
AQEBAQEBAQEQTEtaIBAgWm9+fn9/f39/byAQAQICAgICAgICAjNlfn9/fW8B
AgICAgICAgICAgEBAQEBAQEBAQEBAQEBAQEBAQEIIGV9f30zAQgBAgICAgIC
AgEBAQEBAQEBAQEBAQEBAQEBAQEBEDNlf39lEAEIAQICAgICAgIBAQEBAQEB
AQEBAQEBAQEBAQEBARBBfX9/f39/f39/f39/f39/f39/f39/f39+fW9PAQgg
WlpaEAgBAQEBEBAgICkzZX51ZSAgIBAQAQEBAQEIIE9aQRAIKUxvfX9/f39+
bykQCAICAgICAgIBATNlfn9/fWUCAgICAgICAgICAQgBEAEQARABEAEQARAB
EAEQARABM2V9f30pCAIBAgICAgICAQgBARABEAEQARABEAEQARABEAEQEEFl
f39lEAICAgICAgICAgEBCAEQARABEAEQARABEAEQARABECBMfn9/f39/f39/
f39/f39/f39/f39/f356ZSABASBLb1ogAQEBAQEQS296enp/fXx9fXVvb29a
IBABAQEBASlaaEsBCBApZX9/f39/byAQAQICAgICAgICCDNlf39/f2UBAgIC
AgICAgIBAgEQKTMzMzMpMzMzMzMzMzMzMzMpWm99f30zAQEIAQICAgICAgII
ICAzMzMzMykzMzMzMzMzMzMzQVZ6f39lEAECAgICAgICAgIBECkzMzMzMzMz
MzMzMzMzKTMzM0FlfX9/f39/f39/f39/f39/f39/f39+fWVMKRABEDNLWjMQ
AQEBIE9ab29lT0xBZXx6ZU8zQU9lZUwgCAEBARApWlogEAEQIEx6fX9/bykQ
AQICAgICAgICATNlfn9/fWUCAgICAgICAgEIAQhBZWVvZW9lb2VvZW9lb2Vv
ZW9lenp+f34gCAICAgICAgICAgEQWmVvZW9lb2VvZW9lb2VvZW9lb3p9f39l
EAIBAgICAgIBCAEBM1plb2VvZW9lb2VvZW9lb2VvZXp6fX9/f39/f39/f39/
f39/f39/f396ZTMgAQEBEEtaMxABAQEQWnp+fWUzEAEQQX96TAECEClafm9W
AQEIAQEBWlozEAEIARBvf399bykQAQgBAgICAgICATNlfn9/fWUBAQICAgIC
AgICARBaf39/f39/f39/f39/f39/f39/f39/f30zCAECAgICAgICAggpfX9/
f39/f39/f39/f39/f39/f39/f39lEAEIAQICAgICAgEBVn1+f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39LIAEBAQEIKVpaKRABARAg
b35+ZTMQAQEQQX9vSxABAQEgWm9lEAEBAQEBS1paEAEBCBB6fX9/bykQAgIC
AgICAgEIATNlfn9/fWUIAgICAgICAgIBAQhWf39/f39/f39/f39/f39/f39/
f39/fn0zAQICAgICAgICAgEpen5/f39/f39/f39/f39/f39/f39/f39lEAIC
AgICAgICAQgBWnp/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39vICABCAEQIEtaQRABARAgWn1/ekwzIAEQQX9lSwEQECBBb2VLEAEB
AQEQWlpLEAEBASBvf399bykQAQECAgICAgICAjNlfn9/fmUBAgICAgICAgIC
CAhafn9/f39/f39/f39/f39/f39/f39/f30pCAECAgICAgICAgggen9/f39/
f39/f39/f39/f39/f39/f39lEAECAgICAgICAgIBVn1+f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f399b0wpAQEBEEFaTyABAQEBT296
f35vSxAQQX9vSgEQQWh1fUsgAQEBARAgWlopEAEBECB6f39/bykQCAICAgIC
AgICATNlfn9/fWUCAQICAgICAgICARBaf39/f35/f39+f39/f39/f39/f39/
fn0zAQECAgICAgIBCAEgen99fn9/fn9/f39/f399f39/f39/f39lEAECAgIC
AgICAgEBWnp/f39+f39/f31/fn9/f35/f39/f39/f39/f39/f39/f39/f39/
f39/fnplTBAIASBMb08QAQEBEClab316WhAIM39lMwEpWmpvMyAIAQEBASBL
WkEQAQEgS3p9f39+byAQAQICAgICAgICATNlf39/fWUBCAECAgICAgICAghM
fn19fn99fX5/fX19fn19fX9/f39/f30zCAECAgICAgICAQEgfHp/f319f399
fX99fX1/fn9+f39/f39lEAEIAQICAgICAgIBTHV+fn1/fX99fX99f319fn5+
f39/f39/f39/f39/f39/f39/f39/f39/f399b0EgARAgaFpLEAEBARApQVpa
MxAQQX9lQQggM08zEAEBAQEBEE9aTxABEDNMen5/f39/bykQAgICAgICAgEI
ATNlfn9/fWUCAgICAgICAgICAgIzWlpaWlZlWlpaWlpaWmVab31+f39/f30p
CAECAgICAgIBCAEQS1plWlpaWlZlWlpaWlpaZXp9f39/f39lEAIBAgICAgIC
AgICKVpaZVpaWlpWZVpaWlplZW96f39/f39/f39/f39/f39/f39/f39/f39/
f39/f31lEAEQM1pqMxABAQEBAQEBAQggWn5vTBABAQEBAQEBAQEQS1pvIAEI
QW99f39/f399bykQAgICAgICAgICAjNlfn9/fmUBAgICAgICAgICAgICAgIC
AgICAgIBAggBAQEIT3p9f39/f30zCAgBAgICAgICAgICAgICAgECAgIBAgEC
AQEIIFp6f39/f39lEAEIAQICAgICAgICAgICAgECAgICCAEIAQgBAUFlfn9/
f39/f39/f39/f39/f39/f39/f39/f39/f316ZTMgEExvWk8IAQEIAQEBAQFa
en5+bzMQAQEBAQEBASAzaFopECBab31/f39/f39/bykQAQICAgICAgICATNl
fn9/fWUCAQICAgICAgICAgICAgICAQIBAgEIAQEBAQgBS3V+f39/f30pAQEC
AgICAgICAgICAgIBAQgCAQEIAQgBCAEBIFp6f39/f39lEAICAgICAgICAgIC
AgICAQgCAQIBAQEBAQEBATNlf39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/fWUpICBMb1ogEAEBAQEBAQFvfX5+ekEQAQEBAQEBEClaaEEQIEx1f39/
f39/f39+bykQAQgBAgICAgICATNlfn9/fWUBCAECAgICAgICAgICAQICCAEI
AQEBAQgBCAEBS29/f39/fn0zCAEBCAECAgICAgICAgEIAQEBCAEBAQEBAQEB
IFp6f39/f39lEAECAgICAgICAgICAgECAQEBCAEIAQgBCAEIEDNlf39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f396TCAQWm9oKQgBAQEBARBPen5/
byAQAQEBAQEQIFpaMyAgWnp/f39/f39/f39/bykQAgICAgICAgEIATNlfn9/
fW8CAQICAgICAgICAgIBCAIBAQEBAQgBCAEBAQEBS3V+f39/f30pCAECAgIC
AgICAgIBCAEBAQgBAQEIAQEIAQgBIFp6f39/f39lEAIBAgICAgICAgICAQgB
CAEIAQEBAQEBAQEBATNlf39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f399b1YzM09vWjMQAQEBAQEpWn59bxABAQEBARAgWlpBIDNaen1/f39/f39/
f399bykQAQICAgICAgICAjNlfn9/fWUBCAECAgICAgICAgIBAQEIAQgBAQEB
AQEIAQEBTG9/f39/f30zCAECAgICAgICAgICAQEIAQEBCAEBAQgBAQEBIFp6
f39/f39lEAEIAQICAgICAgICAgEBAQEBAQgBCAEIAQgBAUFlf39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f3pMIDNab1opEAEBAQgQQX51WhAB
AQEBEClaWksgM2V9f39/f39/f39/f39/bykQAQICAgICAgICATNlfn9/f2UB
AQICAgICAgICAgEIAQgBAQEBAQgBCAEBCAEIS29+f39/f30pCAEBAgICAgIC
AgEBAQgBAQEIAQEBCAEBAQgBIFp6fn9/f39lEAICAgICAgICAgEIAQEIAQgB
CAEBAQEBAQEBCDNlf39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f396WjMgWm9vKRABAQIBKX1aTAEBAQEQM1pvQSkzb3p+f39/f39/f39/f399
bykQCAECAgICAgICAjNlfn9/fWUBCAECAgICAgICAgEBAQEBCAEBAQEBAQEB
AQEBQW99f39/fn0zCAEIAQICAgICAgIIAQEBCAEBAQEBAQEBAQEBIEx6f39/
f39lEAECAgICAgICAgIBAQEBAQEBAQEBAQEBAQEBATNlf39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/elozM09vWjMQAQEBIFpBIAEBASAz
WlpPKUtlen9/f39/f39/f39/f39/bykQAQICAgICAgIBATNlfn9/fWUCAgIC
AgICAgICAQgQECAgEBAgIBAQICAQECAgQXp+f39/f30zAQECAQICAgICAgIB
ECAgECAQIBAgECAQIBAQQW96f39/f39lEAICAgICAgICAQgBEBAgECAgECAg
IBAgICAQKUFvf39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f3paICBWb28pEAEBECAQEAEBEE9vYUEpIGV9f39/f39/f39/f39/f39/byAQ
AQgBAgICAgICCDNlf39/fWUBAgICAgICAgICAgEgQUFMTExMTExMTExMTExM
b31+f39/fn0gCAEBCAECAgICAQIQM0FBTExMTExMTExMTExMWnV9f39/f39l
EAEBAgICAgICAgICIClMQUxMTExMTExMTExMQWV6f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f399WjMgQV9lSyAQAQEBAQEpWm9aSyAz
ZXp/f39/f39/f39/f39/f39/bykQAgECAgICAgICATNlfn9/fWUCAgICAgIC
AgICAgFBenp6enp6enp6enp6enp6fX5/f39/f30zCAECAgICAgIBCAEgZW99
enp6enp6enp6enp6fX5+f39/f39lEAgCAgICAgICAgIBT296enp6enp6enp6
enp6en1+f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
b2UgKUFaWkspEAEQECBPZW9MIDNlen9/f39/f39/f39/f39/f399bykQAQgB
AgICAgICATNlfn9/f2UBAgICAgICAgICAghWf35/f39/f39/f39/f39/f39/
f39/fn0zCAECAgICAgICAgEgen1/f39/f39/f35+fn9/f39/f39/f39lEAEC
AgICAgICAgICWnp/fX9/f39/f39/f39/f39+fn5/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f3pLIAEpWmplSxAgM29vaCkgEGV6f39/
f39/f39/f39/f39/f39/bykQAgICAgICAgEIATNlfX9/fWUCAQICAgICAgIC
ARBafn9/f39/f39/f35/fn9/f39/f39/f34zCAEBAgICAgEIAQggen5/fn9/
fn9+fn5+fn9/f39/f39/f39lEAECAgICAgICAgIBWnp/fn9/f35/f39/f39/
fn5+fn5/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f316
QSAQIExaZVpaWk9PIBApWnp+f39/f39/f39/f39/f39/f39+byAQAQECAgIC
AgICATNlfn9/fWUBCAECAgICAgICAhBaf31/fX19f319f31+fX99fX19f39/
f30gAQgBAgICAgICAgIpfX5/fn99f31/fX99f319fX1+fn9/f39lEAEIAQIC
AgICAgICWnp9f31/fX9+fX1/fX19f359f35+f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39+ZUEQEBAzTFpaTDMgARBaen9/f39/f39/
f39/f39/f39/f39/bykQCAICAgICAgEIATNlfn9/fWUCAgICAgICAgICAhBB
en1ven16b3p6em99enpvenp6en5/f30zCAECAgICAgICAgIgZXp6em96enpv
enp6b3p6en16en1/f39lEAIBAgICAgICAgICQW96enpvenpvenpvenp6b3p6
b31+f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/fW8g
AQEQECkpIAEBEFp1f39/f39/f39/f39/f39/f39/f399bykQAQECAgECAgIB
ATNlf39/fmUBAQIBAgICAgICAgIQMzNBM0EzQTNBM0EzQTNBQUFBb31/f30p
CAEBAgECAQICAgICKSlBM0EzQTNBM0EzQTNBM0EzVnp/f39lEAEIAQICAgIC
AgECECkzQTNBM0EzQTNBM0EzQTNBQWV9f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f31lMwEBEBAQCAEgQW9/f39/f39/f39/f39/
f39/f39/f39/bykQAQgCAQgCAgEIATNlfn9/fWUBCAEIAgICAQICAgEIEBAQ
EBAQEBAQEBAQEBAQEBAgWn5+f30zCAEIAQgBCAICAgIBEBAQEBAQEBAQEBAQ
EBAQEBAQM3p9f39lEAEBAgICAgEIAQgBCBAQEBAQEBAQEBAQEBAQEBAQEFp6
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f399WhAB
AQEBAQFBb31/f39/f39/f39/f39/f39/f39/f39+byAQAQEBAgEBAgEBATNl
fn9/fWUBAQEBAgECCAEBAggBAQEBAQEBAQEBAQEBAQEBAQEITH1/fn0gCAEB
AQECAQECAQIBAQEBAQEBAQEBAQEBAQEBAQEBIG9/f39lEAEIAQEBAgEBAQIB
AQEBAQEBAQEBAQEBAQEBAQEBAUxvf39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/emgQAQEBCCBlf39/f39/f39/f39/f39/f39/
f39/f39/bykQCAEIAQEIAQgBCDNlfn9/fWUBCAEIAQgBAQEIAQEBAQEBCAEB
CAEBCAEBAQgBCAEITH1+f31BAQEIAQgBAQgBCAEIAQEIAQEIAQEIAQEIAQEB
AQEBIG99f39lEAEBCAEIAQgBCAEIAQgBAQgBAQgBAQgBAQgBCAEIAUt1fX9/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/fnpBIAEB
IFZ6f39/f39/f39/f39/f39/f39/f39/f399bykQAQEBAQgBAQEBATNlf39/
f2UBAQEBAQEBCAEBAQgBAQEBAQEBAQEBAQEBAQEBAQEIS31/fn0gCAEBAQEB
CAEBAQEBAQEBAQEBAQEBAQEBCAEIAQEBIHp9f39lEAEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQEBAU96f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39vTAEQM3p/f39/f39/f39/f39/f39/f39/f39/
f39/bykQAQgBCAEBAQEIATNlfX9/fWUBAQgBAQgBAQEIAQEBCAEBCAEBCAEB
CAEBCAEBCAEITH1/f30zCAEIAQEIAQEBAQgBAQgBAQgBAQgBAQgBAQEBCAEI
IG99f39lEAgBCAEBCAEBCAEBCAEBCAEBCAEBCAEBCAEBCAEIAU9vf39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f399VgggVn1/
f39/f39/f39/f39/f39/f39/f39/f39/bykQAQEBAQEIAQgBATNlf39/fWUB
CAEBCAEBCAEBCAEIAQEIAQEIAQEIAQEIAQEIAQEITH1/fX0zAQEBAQgBAQgB
CAEBCAEBCAEBCAEBCAEBCAEBAQEBIG9/f39lEAEBAQEIAQEIAQEIAQEIAQEI
AQEIAQEIAQEIAQEBAU96f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/b0Fab31/f39/f39/f39/f39/f39/f39/f39/f39/
bykQAQgBCAEBAQEBATNlfX9/fWUBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEITH1/f30gCAEIAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQgBIG9/
f39lEAEBCAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEIAUxvf39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/byAQAQEBARABAQEQATNlfn9/fWUQAQEQ
AQEQAQEQAQEBEAEBEAEBEAEBEAEBEAEBEAEITH1/fn0zCAEBARABARABAQEQ
AQEQAQEQAQEQAQEQAQEQAQEBIG99f39lEBABAQEQAQEQAQEQAQEQAQEQAQEQ
AQEQAQEQAQEBAVp1fX9/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/fW9v
ZWVlZWVlZWVlZXp6f39/f3plZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVl
ZWVven9/f396ZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlb39/f396
b2VlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZXp9f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/
f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/CmVu
ZHN0cmVhbQplbmRvYmoKNzUgMCBvYmoKMTgyOTIKZW5kb2JqCnhyZWYKMCA3
NwowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMTgwNDcgMDAwMDAgbiAKMDAw
MDAxNzk4OCAwMDAwMCBuIAowMDAwMDE2MzQ0IDAwMDAwIG4gCjAwMDAwMDAw
MTUgMDAwMDAgbiAKMDAwMDAxNjMyMyAwMDAwMCBuIAowMDAwMDE4MTg4IDAw
MDAwIG4gCjAwMDAwMTcwNzggMDAwMDAgbiAKMDAwMDAxOTQyNSAwMDAwMCBu
IAowMDAwMDE5NzQ2IDAwMDAwIG4gCjAwMDAwMTk5ODQgMDAwMDAgbiAKMDAw
MDAyMDI0OCAwMDAwMCBuIAowMDAwMDIwNjU5IDAwMDAwIG4gCjAwMDAwMjEw
MDEgMDAwMDAgbiAKMDAwMDAyMTMyOSAwMDAwMCBuIAowMDAwMDIxNjUxIDAw
MDAwIG4gCjAwMDAwMjE5NDIgMDAwMDAgbiAKMDAwMDAyMjIxMCAwMDAwMCBu
IAowMDAwMDE3MDAzIDAwMDAwIG4gCjAwMDAwMjI2NjIgMDAwMDAgbiAKMDAw
MDAyMjg4MSAwMDAwMCBuIAowMDAwMDIzMDczIDAwMDAwIG4gCjAwMDAwMjMy
OTIgMDAwMDAgbiAKMDAwMDAyMzUwMSAwMDAwMCBuIAowMDAwMDIzNjg4IDAw
MDAwIG4gCjAwMDAwMjM4NzQgMDAwMDAgbiAKMDAwMDAyNDA0NSAwMDAwMCBu
IAowMDAwMDI0MjU4IDAwMDAwIG4gCjAwMDAwMjQ0NzUgMDAwMDAgbiAKMDAw
MDAyNDY5MCAwMDAwMCBuIAowMDAwMDI0ODk4IDAwMDAwIG4gCjAwMDAwMjUw
OTIgMDAwMDAgbiAKMDAwMDAyNTMxNSAwMDAwMCBuIAowMDAwMDI1NTIwIDAw
MDAwIG4gCjAwMDAwMjU3MjAgMDAwMDAgbiAKMDAwMDAyNTkyMSAwMDAwMCBu
IAowMDAwMDI2MTI5IDAwMDAwIG4gCjAwMDAwMjYzMzIgMDAwMDAgbiAKMDAw
MDAyNjU2NCAwMDAwMCBuIAowMDAwMDI2NzM4IDAwMDAwIG4gCjAwMDAwMjY5
MzIgMDAwMDAgbiAKMDAwMDAyNzEzMiAwMDAwMCBuIAowMDAwMDI3MzQwIDAw
MDAwIG4gCjAwMDAwMjc1MjkgMDAwMDAgbiAKMDAwMDAyNzcyMSAwMDAwMCBu
IAowMDAwMDI3OTA4IDAwMDAwIG4gCjAwMDAwMjgxMzUgMDAwMDAgbiAKMDAw
MDAyODMzNiAwMDAwMCBuIAowMDAwMDI4NTU5IDAwMDAwIG4gCjAwMDAwMjg3
OTAgMDAwMDAgbiAKMDAwMDAyOTAwNSAwMDAwMCBuIAowMDAwMDI5MTg2IDAw
MDAwIG4gCjAwMDAwMjk0MDUgMDAwMDAgbiAKMDAwMDAyOTYxOCAwMDAwMCBu
IAowMDAwMDE2OTMwIDAwMDAwIG4gCjAwMDAwMjk4MzUgMDAwMDAgbiAKMDAw
MDAzMDA1NyAwMDAwMCBuIAowMDAwMDMwMjQ2IDAwMDAwIG4gCjAwMDAwMzA0
NjcgMDAwMDAgbiAKMDAwMDAzMDY3MiAwMDAwMCBuIAowMDAwMDMwODc3IDAw
MDAwIG4gCjAwMDAwMzEwNjggMDAwMDAgbiAKMDAwMDAzMTI3NCAwMDAwMCBu
IAowMDAwMDMxNDkzIDAwMDAwIG4gCjAwMDAwMzE2ODcgMDAwMDAgbiAKMDAw
MDAzMTkxMCAwMDAwMCBuIAowMDAwMDMyMTAwIDAwMDAwIG4gCjAwMDAwMTY4
NTYgMDAwMDAgbiAKMDAwMDAxNjc4MCAwMDAwMCBuIAowMDAwMDE2NzAwIDAw
MDAwIG4gCjAwMDAwMzIzMDEgMDAwMDAgbiAKMDAwMDAxNjYyMiAwMDAwMCBu
IAowMDAwMDMyNTcyIDAwMDAwIG4gCjAwMDAwNjY3NDkgMDAwMDAgbiAKMDAw
MDA2Njc3MSAwMDAwMCBuIAowMDAwMDg2Nzc1IDAwMDAwIG4gCjAwMDAwMTgw
OTYgMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSA3NyAvUm9vdCAxIDAgUiAv
SW5mbyA3NiAwIFIKPj4Kc3RhcnR4cmVmCjg2Nzk3CiUlRU9GCg==
---559023410-342241519-951245837=:21125--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 22 15:08:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21416
	for ; Tue, 22 Feb 2000 15:08:36 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.240E8FA0@standards.nortelnetworks.com>; Tue, 22 Feb 2000 15:04:39 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 57912 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Feb 2000 15:03:21
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.8FE8CCB0@standards.nortelnetworks.com>; Tue, 22 Feb 2000 14:53:21
          -0500
Received: from localhost (98ADA122.ipt.aol.com [152.173.161.34]) by
          hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id NAA06129 for
          ; Tue, 22 Feb 2000 13:56:26 -0600 (CST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID:  <744.549288.39444@localhost>
Date:         Tue, 22 Feb 2000 15:03:21 -0500
Reply-To: teresapoole@BIGFOOT.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: teresapoole@BIGFOOT.COM
Subject:      [MOBILE-IP] book,software & product reviewers needed - keep all
              review titles
              for your use
X-To:         mobile-ip@smallworks.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Win a Compaq Aero 1500 palm size computer or a DVD player or a
Digital Camera!


Our records show that you have had an interest in books, software
and consumer products.

We need reviewers to write brief reviews and post them to our
review web site.

The process is very simple! You can request virtually any product
and receive these review products directly from the publisher or
manufacturer. They even pay all shipping charges! You keep all
review products after you post a brief review to our review web
site.

All you have to do is register to become a reviewer and we send
you the necessary forms and information showing you how to start
receiving review products and how to write product reviews. In
the event you don't receive all of the products you requested we
have a free replacement policy. See the FAQ section on our web
page for more information on our replacement policy.


TO RECEIVE FREE INFORMATION ON HOW TO BECOME A REVIWER:


Send an email to teresapoole@bigfoot.com with the words STARTER
KIT 0222DTI in the message subject line. We will send you
complete information on how you can become a registered reviewer
for us. You will see what hundreds of other individuals who had
absolutely no experience in writing reviews, have received. One
woman received over $4,000 in books alone over the past year.

Remember you can request virtually any PC or Macintosh software
program, any book (fiction or non-fiction) and any consumer
product costing less than $300.

Just by ordering one review request package you will be entered
into our March 29th drawing for the above prizes.


Sincerely,

Kristen Matthews,  Marketing Director

PS - We are looking for several individuals to work out their
home for us. You can earn cash income on a weekly basis.

If you are interested in the details please send an email to
teresapoole@bigfoot.com with the words HOME INCOME in the message
subject line. We will send you a complete information package
describing the job opportunity and benefits.

REMOVE INSTRUCTIONS: To have your email message removed from our
database reply to this message with the word REMOVE in the
message subject line.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 22 15:24:47 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21962
	for ; Tue, 22 Feb 2000 15:24:44 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6283DEF0@standards.nortelnetworks.com>; Tue, 22 Feb 2000 15:20:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 57962 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 22 Feb 2000 15:20:39
          -0500
Received: from maredsous.monarch.cs.cmu.edu by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.5FE39190@standards.nortelnetworks.com>; Tue, 22 Feb 2000 15:20:38
          -0500
Received: from maredsous.monarch.cs.cmu.edu (localhost [127.0.0.1]) by
          maredsous.monarch.cs.cmu.edu id PAA18416; Tue, 22 Feb 2000 15:28:01
          -0500 (EST)
Message-ID:  <18414.951251281@maredsous.monarch.cs.cmu.edu>
Date:         Tue, 22 Feb 2000 15:28:01 -0500
Reply-To: Dave Johnson 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Dave Johnson 
Subject:      Re: [MOBILE-IP] [Fwd: Home Agents list: understanding of the list
              of global
              addresses]
X-To:         Guilhem Tardy 
X-cc:         "Charles E. Perkins" ,
              "pcalhoun@eng.sun.com" 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  Your message of "Tue, 22 Feb 2000 13:50:35 EST" 
              <38B2DA7B.C06DCE5B@crc.ca>

>Hi!
>
>I sent this to the mailing list last week, but it didn't come back (does
>the mailing list confirm messages?) and nobody answered so far,
>therefore I am let to believe this didn't reach its target.
>Maybe I will be more lucky with direct emailing...
>
>> I would like to ask for your understanding of the following, found in
>> draft-ietf-mobileip-ipv6-10.txt, page 17, about the Home Agents list:
>>
>>           -  One or more global IP addresses for this home agent,
>>              learned through Prefix Information options with the
>>              Router Address (R) bit is set, received in Router
>>              Advertisements from this link-local address.  Global
>>              addresses for the router in a Home Agents List entry MUST
>>              be deleted once the prefix associated with that address is
>>              no longer valid [17].
>>
>> Does this mean that a node might keep, for each home agent (on each
>> interface), at least one global address? Hence, it could only keep the
>> *one* with longest lifetime (and no list of several global addresses is
>> required)?
>> I don't see any drawback here, unless a prefix expires before its
>> advertised lifetime.
>
>Obviously, storing only one global address for each HA is simpler than
>dealing with a whole list and various expiration times. Therefore, I
>would appreciate to understand the reasons behind this requirement of
>storing many global addresses as provided by the router advertisements
>of a single HA.
>
>Guilhem Tardy.


I think it would be fine to keep only the global address with the
longest lifetime for each home agent.  I put the language in there as
it is, due to the simularity with various pieces of Neighbor
Discovery.  In particular, the reason for suggesting that you should
keep multiple addresses is to handle the case of a node's (a home
agent's, in this case) prefix changing.  However, since you never use
these home agent addresses to open a TCP connection to it (for
example), I think there is no need to keep the older addresses (with
the older prefix and shorter remaining lifetime).  I need to think
about this more carefully, but I think what you are suggesting is
fine.

                                        Dave


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Feb 23 01:05:21 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03289
	for ; Wed, 23 Feb 2000 01:05:20 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7724C530@standards.nortelnetworks.com>; Wed, 23 Feb 2000 1:01:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 58238 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 23 Feb 2000 00:59:34
          -0500
Received: from catarina.usc.edu by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.3F5B7590@standards.nortelnetworks.com>; Wed, 23 Feb 2000 0:59:33
          -0500
Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu
          (8.9.3/8.9.3) with ESMTP id WAA73938 for
          ; Tue, 22 Feb 2000 22:02:41
          -0800 (PST)
Received: from localhost (meeta@localhost) by rumi.usc.edu (8.9.3/8.9.3) with
          ESMTP id WAA79644 for ; Tue,
          22 Feb 2000 22:02:54 -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  
Date:         Tue, 22 Feb 2000 22:02:53 -0800
Reply-To: Meeta Sharma 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Meeta Sharma 
Subject:      [MOBILE-IP] home agent crash???
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <18414.951251281@maredsous.monarch.cs.cmu.edu>

Hi,

I have one doubt, in RFC2002 , there is nothng mentioned about the
scenario when the home agent crashes!
What if the home agent crashes and the mobile node is in the foreign
network, and there is no home agent on the LAN, to capture the packets
destined for Mobile node, so the packets would be lost and the mobile node
would not know this till it's registration does not expire! Then wouldn't
this lead to an erroneous situation and further degradation???

Looking forward to your response,
Thanks,
Meeta


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Wed Feb 23 23:27:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10076
	for ; Wed, 23 Feb 2000 23:27:13 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F588D040@standards.nortelnetworks.com>; Wed, 23 Feb 2000 23:23:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 58974 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 23 Feb 2000 23:21:42
          -0500
Received: from mw.3com.com (149.112.20.3) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.BE0BCBE0@standards.nortelnetworks.com>; Wed, 23 Feb 2000 23:21:42
          -0500
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com
          Corporation) id WAA16822; Wed, 23 Feb 2000 22:24:41 -0600 (CST)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id
          8625688F.00185869 ; Wed, 23 Feb 2000 22:25:54 -0600
X-Lotus-FromDomain: 3COM@3COM-MWGATE
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <8625688F.001856D6.00@mwgate02.mw.3com.com>
Date:         Wed, 23 Feb 2000 22:26:07 -0600
Reply-To: Yingchun Xu 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Yingchun Xu 
Subject:      Re: [MOBILE-IP] RFC2344bis support of Dynamic Home Agent
              Assignment
X-To:         gab@sun.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi, Gabriel,
It seems that you forget to make the change in section 5.1.2 and 5.2.2 for
dynamic home agent assignment.
The orginal text:

"IP Destination Address

         Copied from the Home Agent field within the Registration
                  Request."

should be:

"IP Destination Address

         Copied from the Home Agent field within the Registration
                  Reply."

--Yingchun.




Gabriel Montenegro  on 11/11/99 10:02:30 AM

Please respond to gab@sun.com

Sent by:  Gabriel Montenegro 


To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
cc:    (Yingchun Xu/MW/US/3Com)
Subject:  Re: [MOBILE-IP] Dynamic Home Agent Assignment



good point. we can use language similar to what rfc2344 already has
for the short MN->FA tunnel in the encapsulated delivery style:

        The address of the agent as learned from the IP source
        address of the agent's most recent registration reply.

i suggest modifying the above very slightly (one word added) as
follows and to use it for reverse tunnels as well:

        The address of the agent as learned from the IP source
        address of the agent's most recent successful  registration
        reply.

the question is: should i produce an rfc2004version2 with the above
changes? any other tweaks needed for 2344?

phil? raj?

-gabriel

>In draft-ietf-mobileip-home-addr-alloc-00.txt, dynamic home agent function is
>described. It seems that this function break the reverse tunneling function as
>specified in RFC2344.
>
>In RFC2344, IP destination address is copied from  the Home Agent field within
>the Registration Request.
>
>In order to support dynamic Home Agent assignment, the IP destination address
>of
>a reverse tunneling IP packet has to be copied from the Home Agent field within
>the Registration Reply (Of course, the registration has to be successful).
>
>It seems a modification to RFC2344 is required to  support dynamic Home Agent
>assignment. Any comments?
>
>
>--Yingchun.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Feb 24 02:46:37 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24232
	for ; Thu, 24 Feb 2000 02:46:37 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C61512D0@standards.nortelnetworks.com>; Thu, 24 Feb 2000 2:42:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 59034 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 24 Feb 2000 02:40:39
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.2392DC00@standards.nortelnetworks.com>; Thu, 24 Feb 2000 2:30:39
          -0500
Received: from dns1.peopledaily.com.cn ([202.99.23.252]) by
          hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id BAA18648 for
          ; Thu, 24 Feb 2000 01:33:42 -0600 (CST)
Received: from tical ([152.174.64.129]) by dns1.peopledaily.com.cn (Netscape
          Messaging Server 3.6)  with SMTP id AFN432E; Thu, 24 Feb 2000
          12:29:57 +0800
Message-ID:  <7735EB8313AC.AFN432E@dns1.peopledaily.com.cn>
Date:         Thu, 24 Feb 2000 12:29:57 +0800
Reply-To: cybil@123EMAIL.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: cybil@123EMAIL.COM
Subject:      [MOBILE-IP] Telecommute your way to Financial Freedom
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

   If you're interested in driving a car with no note,
   living in a house with no mortgage, or having a free
   website which makes you money 24-7-365, All Automatically,
   then read the following Free Insider Information.

Telecommute your way to Financial Freedom while driving a
Company Paid Car and living in a Company Paid *House* that
you got from your own Free WEBSITE !

Not just a web page but a complete 1500+ page website that
you can use to generate a Lifetime Residual Income! Finally
an opportunity for the average person to build a Financial
Future using the computer and the internet.

Your TURN-KEY Nutri-Net Internet Store operates 24-7-365
and is stocked with over 400 high quality products that SELL.

Many are EXCLUSIVE!

Your Nutri-Net Store does all of the selling for you and the
company ships out the products for you *Automatically*!

Your Automated Money-Making System includes the following:

  Automated Lead Generation
  Automated Followup - can handle 1000s of leads simultaneously!
  Deal only with HOT INTERESTED PROSPECTS
  NO selling or rejection

All You Do Is USE THE *AUTOMATED* SYSTEM and CASH THE CHECKS!

Now You Have A Way To MAKE MONEY AUTOMATICALLY
24 Hours a Day, 365 Days a Year!

For about the price of a nice night out on the town, you can
become a member of the Nutri-Net Online Marketing Team and own
your own personalized Internet Web Store and make a STABLE,
LIFETIME RESIDUAL INCOME!!

You owe it to yourself to check out this once in a lifetime
home based business opportunity with a PROVEN 14-year-old,
product-driven, publicly held NETWORK MARKETING COMPANY led
by Professionals experienced in helping people like you
MAKE MONEY ON THE INTERNET.

These Pros Will SHOW YOU How To Work The
SYSTEM For MAXIMUM CASH FLOW!

For The Full, Free, Exciting Details,

Send Your

Name:
Phone Number (required):
(Available in USA Only)

To mailto:lifetimecash11@newmail.net


To unsubscribe mailto:unsubscribe221@newmail.net


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Feb 24 14:21:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08833
	for ; Thu, 24 Feb 2000 14:21:58 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EFA66F70@standards.nortelnetworks.com>; Thu, 24 Feb 2000 14:17:52 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 59323 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 24 Feb 2000 14:16:53
          -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.66EE16C0@standards.nortelnetworks.com>;
          Thu, 24 Feb 2000 14:06:53 -0500
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id MAA06863; Thu, 24 Feb 2000 12:10:00
          -0700 (MST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by
          engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id
          LAA09150; Thu, 24 Feb 2000 11:09:59 -0800 (PST)
Received: from cali (cali [129.146.122.121]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id LAA14161; Thu, 24 Feb 2000 11:09:57
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  
Date:         Thu, 24 Feb 2000 11:09:57 -0800
Reply-To: Gabriel Montenegro 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Gabriel Montenegro 
Subject:      Re: [MOBILE-IP] RFC2344bis support of Dynamic Home Agent 
              Assignment
X-To:         Yingchun Xu 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID" <8625688F.001856D6.00@mwgate02.mw.3com.com>

"Yingchun Xu"  wrote:
> It seems that you forget to make the change in section 5.1.2 and 5.2.2 for
> dynamic home agent assignment.
> The orginal text:
>
> "IP Destination Address
>
>          Copied from the Home Agent field within the Registration
>                   Request."
>
> should be:
>
> "IP Destination Address
>
>          Copied from the Home Agent field within the Registration
>                   Reply."

i did not forget, but had interpreted the included msg below from raj to
mean that this particular change was not warranted. but since we're modifying
2344 for private addresses already, it would make sense to put this very slight
change in, specially as it brings things more in line with existing text
on encapsulating delivery style:

section 5.2.2, for the packet format between MN->FA:

      IP Destination Address

         The address of the agent as learned from the IP source address
         of the agent's most recent registration reply.

i propose to add "successful" to the above and use this:

         The address of the agent as learned from the IP source address
         of the agent's most recent successful registration reply.
                                    ^^^^^^^^^^

as for the text you're concerned with in 5.1.2 and 5.2.2, i propose this
for the header between FA->HA (add "successful" to your suggestion):

      IP Destination Address

         Copied from the Home Agent field within the most recent
         successful Registration Reply.
         ^^^^^^^^^^^

if there are no objections, i will make these very slight changes to
rfc2344bis before adelaide. this does seem like a safer way of doing things,
and since we were already doing it this way for the MN->FA in section 5.2.2,
i bet not doing so for the FA->HA headers in 5.1.2 and 5.2.2 was just an oversight.

tnx,

-gabriel

--------------------------------------------------------------------
Date: Tue, 16 Nov 1999 22:41:17 -0600
From: "Basavaraj Patil" 
Subject: Re: [MOBILE-IP] Dynamic Home Agent Assignment
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM


>> Have you get any words from chairs how to resolve the issue? We need
>> this since the "Dynamic Home Agent Assignment" feature is one of the
>> requirement for cdma2000 network. This is definitely a requirement
>> when reverse tunneling becomes mandatory.

>i have had some private conversations with the chairs that lead me
>to believe that the slight changes required in rfc2344 would be
>ok to do. i sent the query last week hoping they would reply
>and make public their opinion.
>
>raj? phil?
>
>-gabriel

>>>In draft-ietf-mobileip-home-addr-alloc-00.txt, dynamic home agent
>>>function is described. It seems that this function break the reverse
>>>tunneling function as specified in RFC2344.

First of all I need to clarify that this I-D is currently not a WG
document. Dynamic Home agent assignment can be done many ways and I do
not believe it needs to be specified by the Mobile IP protocol.

In view of the consensus that the WG arrived regarding how we address
the issue of mobile nodes with private addresses, I believe an update
to RFC2344 describing the solution is sufficient. I do not think there
is enough justification to write another I-D to specifically include
this solution. The solution is an addendum to RFC2344 and can be
mentioned as a reference in the new Mobile IP for IPv4 I-D which will
become a proposed standard at some point soon.

-Basavaraj


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Feb 24 17:38:41 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12119
	for ; Thu, 24 Feb 2000 17:38:41 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.78432B00@standards.nortelnetworks.com>; Thu, 24 Feb 2000 17:34:57 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 59388 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 24 Feb 2000 17:33:43
          -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.E648FAA0@standards.nortelnetworks.com>;
          Thu, 24 Feb 2000 17:23:43 -0500
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id PAA05618 for
          ; Thu, 24 Feb 2000 15:26:56
          -0700 (MST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by
          engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id
          OAA28394; Thu, 24 Feb 2000 14:26:55 -0800 (PST)
Received: from cali (cali [129.146.122.121]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id OAA24440; Thu, 24 Feb 2000 14:26:54
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  
Date:         Thu, 24 Feb 2000 14:26:54 -0800
Reply-To: Gabriel Montenegro 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Gabriel Montenegro 
Subject:      Re: [MOBILE-IP] Private addressing reference in rfc2002-bis ?
X-To:         Samita Chakrabarti 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              <200002101922.LAA21735@jurassic.eng.sun.com>

[kind words about rfc2344bis appendix elided (thanks!)...]

> If FA advertises two different COA's for private address support,
> then it seems the MN implementation will also need to change to
> take into account when to use which COA. Perhaps MNs needs to know
> that it's using a private address space and then process the agent
> advertisement accordingly.

in general, this is very hard to do, because the problem is not
whether one device is using a "private" address space, but if two
address spaces are incongruent
in any way such that communication between their address spaces
is not transparent as per rfc2775:

   ..."transparency" refers to the original
   Internet concept of a single universal logical addressing scheme, and
   the mechanisms by which packets may flow from source to destination
   essentially unaltered.

there are too many ways transparency breaks (see 2775), it would be extremely
hard or impossible for the mobile node to look at the fa's address
and know if that belongs to another address space. sometimes you
cannot know other than looking at routing tables. sometimes, you'll
have to examine the dns (split dns), etc.

> Folks seem to like the nai extension idea.

i've been thinking about this in the context of rsip and of
rfc2344bis and i am more and more convinced that what we need
is almost there but not quite. what we don't need is the nai.
the nai (rfc2486) was designed for and is suitable to identify users
and roaming devices to the network (e.g. "user@realm").

what we need is for the network to qualify itself to the users
or roaming devices (e.g. by providing a "realm identifier").
at first thought, it
would seem like this is nothing but the "realm" as defined
in rfc2486 (nai).  whereas mn's and users
may use nai's to identify themselves, network elements like
fa's, routers, network access servers could conceivably
use "realm indicators" to indicate what address space
or realm they provide access to.

so a "realm" as in the nai is almost it, but we still need
a human readable ascii label (or do we?) for the root realm
(sometimes referred to as the public internet).

this root domain has several representations in section 3.1
of rfc1034:

   binary: null label
        'null (i.e., zero length) label used for the root'

   ascii: " "
        'For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " "'

   ascii: "."
        'The most common interpretation uses the root "." '

given that an absolute or rooted fqdn (from which the "realm" in the
nai derives) terminates with a "." (e.g. "domain.com."), then
perhaps that could be used as the ascii representation of
the root realm, specially given the precedent shown above.
the ABNF for a "realm indicator" (ri) could simply be:

   realm-indicator  = realm / "."

   realm            = 

a general "private address" extension might need to indicate
what ri an agent address belongs to (home agent or care-of
address):

        coa, ri

>
> > the private addr extension need not be included in all advertisements. upon hearing a 'P' bit,
> > the mn could solicit with a special code, say in order to obtain the priv
> > addr extension.
> >
>
> I like this idea. Although I am not quite clear on the idea about the home
> agent advertisement. If a HA has one side public net and private net on the
> other side, then what address would it advertise on the private side ? Do we
> assume that  the private addressed MNs never come back home and they are
> pre-configured to use HA's global address ? On the other hand if HA
> advertises private address on it's private net, then we assume that MNs are
> intelligent enough  to figure out which home agent address to use when they
> are away from home.

a multihomed device with one interface on the "public internet"
could advertise more than one coa/ri pair, for example:

        ipaddr1, "domain.com."
        ipaddr2, "."

a cursory glance might indicate that the above is similar to the
use of point code and network indicator in section 3.2.2 of:

http://search.ietf.org/internet-drafts/draft-coene-ss7-over-ip-00.txt

but i really don't understand ss7.
just some random thoughts...

-gabriel


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Feb 24 17:52:40 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12252
	for ; Thu, 24 Feb 2000 17:52:40 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6E9E39D0@standards.nortelnetworks.com>; Thu, 24 Feb 2000 17:49:00 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 59417 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 24 Feb 2000 17:47:08
          -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.C5A30F50@standards.nortelnetworks.com>; Thu, 24 Feb 2000 17:37:07
          -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 OAA28971; Thu, 24 Feb 2000 14:40:17
          -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by
          engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id
          OAA12201; Thu, 24 Feb 2000 14:40:16 -0800 (PST)
Received: from cali (cali [129.146.122.121]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id OAA24768; Thu, 24 Feb 2000 14:40:15
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  
Date:         Thu, 24 Feb 2000 14:40:15 -0800
Reply-To: Gabriel Montenegro 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Gabriel Montenegro 
Subject:      Re: [MOBILE-IP] Disparate Address Space in RFC 2344bis [Was:
              [MOBILE-IP]
              Private  addressing reference in rfc2002-bis ?]
X-To:         Petri Bernhard 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              

[kind words about rfc2344bis appendix elided (thanks!)...]

> With regard to this Appendix, I've just got a few questions/comments on some
> details:
>
> - Below Figure A1, you describe how an MN sends a packet to an FA via layer
> 2 mechanisms. How does the FA, in this case, know that the source address
> indicated by the MN belongs to MN's home address space C rather than to the
> address spaces A or B, i.e. the address spaces of the FA itself?

perhaps this is inferred from the mn's nai?

> In section
> A.3, you mention the possibility that some MAC or PPP information may be
> used for that; in this case, how did the initial fixing of that relation
> take place?

at registration time? the registration process would have to
keep in its bindings all the info it also keeps for forwarding
packets FA->MN after terminating the forward tunnels.

> Or, as a related question: how would the FA advertise an address
> of an address space, it does not support?
>
> - Below Figure 2 you show that the HA recovers the original packet by being
> cognizant of address space C. How is this done? Probably, HA must apply an
> algorithm saying something like:  for every (IP-IP) packet I receive with
> source address Fb, the inner IP addresses belong to address space C, right ?

i guess. this is where the extra information you can include in the
gre key id field coiuld help (i guess it is getting un-deprecated?).

>
> - In the paragraph below figure 3, I think there's a typo in the third to
> the last line:  H2c  -> H2d

yup, caught that soon after submitting it.

>
> In general, I think that an extensive use of private IP addresses within
> mobile IP will require "giving additional domain information" with those
> addresses (as Pete has worded it in another mail), i.e. to add an explicit
> indication to which that private IP address belongs.

yes, perhaps along the lines of my previous message to
the list?

tnx,

-gabriel


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Thu Feb 24 18:06:43 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12434
	for ; Thu, 24 Feb 2000 18:06:43 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.64DEE2D0@standards.nortelnetworks.com>; Thu, 24 Feb 2000 18:03:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 59449 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 24 Feb 2000 18:01:51
          -0500
Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.D3CC0530@standards.nortelnetworks.com>; Thu, 24 Feb 2000 17:51:50
          -0500
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by
          mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id AAA21191; Fri, 25 Feb
          2000 00:55:03 +0200 (EET)
Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com
          [172.18.242.183]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id
          AAA17273; Fri, 25 Feb 2000 00:55:02 +0200 (EET)
Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <1RM3FVXS>;
          Thu, 24 Feb 2000 16:55:01 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <7B5C0390ACE7D211BC9C0008C7EABA2B9296BD@daeis07nok>
Date:         Thu, 24 Feb 2000 16:54:11 -0600
Reply-To: Basavaraj.Patil@NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Basavaraj Patil 
Subject:      Re: [MOBILE-IP] RFC2344bis support of Dynamic Home Agent  Assignm
              ent
X-To:         gab@eng.sun.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Comments below:

>"Yingchun Xu"  wrote:
>> It seems that you forget to make the change in section 5.1.2 and 5.2.2
for
>> dynamic home agent assignment.
>> The orginal text:
>>
>> "IP Destination Address
>>
>>          Copied from the Home Agent field within the Registration
>>                   Request."
>>
>> should be:
>>
>> "IP Destination Address
>>
>>          Copied from the Home Agent field within the Registration
>>                   Reply."
>
>i did not forget, but had interpreted the included msg below from raj to
>mean that this particular change was not warranted. but since we're
modifying
>2344 for private addresses already, it would make sense to put this
>very slight change in, specially as it brings things more in line
>with existing text on encapsulating delivery style:
>
>section 5.2.2, for the packet format between MN->FA:
>
>      IP Destination Address
>
>         The address of the agent as learned from the IP source address
>         of the agent's most recent registration reply.
>
>i propose to add "successful" to the above and use this:
>
>         The address of the agent as learned from the IP source address
>         of the agent's most recent successful registration reply.
>                                    ^^^^^^^^^^
>
>as for the text you're concerned with in 5.1.2 and 5.2.2, i propose this
>for the header between FA->HA (add "successful" to your suggestion):
>
>      IP Destination Address
>
>         Copied from the Home Agent field within the most recent
>         successful Registration Reply.
>         ^^^^^^^^^^^
>
>if there are no objections, i will make these very slight changes to
>rfc2344bis before adelaide. this does seem like a safer way of doing
things,
>and since we were already doing it this way for the MN->FA in section
5.2.2,
>i bet not doing so for the FA->HA headers in 5.1.2 and 5.2.2 was just an
oversight.
>
>tnx,
>
>-gabriel

Gabriel,

Please go ahead and make the changes. I agree with your observations
here.

-Basavaraj


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Feb 25 00:44:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20083
	for ; Fri, 25 Feb 2000 00:44:14 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E6E10830@standards.nortelnetworks.com>; Fri, 25 Feb 2000 0:40:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 59693 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Feb 2000 00:38:31
          -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.A3DC5AD0@standards.nortelnetworks.com>; Fri, 25 Feb 2000 0:38: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 VAA18323;
          Thu, 24 Feb 2000 21:41:14 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.9.3/8.9.3-VIRSCAN) id VAA13317; Thu, 24 Feb 2000 21:41:13 -0800
X-Virus-Scanned:  Thu, 24 Feb 2000 21:41:13 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from  (maxdialin13.iprg.nokia.com
          [205.226.20.243]) by darkstar.iprg.nokia.com  SMTP/WTS (12.69)
          xma013062; Thu, 24 Feb 00 21:41:05 -0800
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <389AFE78.2A0EA6C0@iprg.nokia.com>
            <20000207111501.B12244@jm.epitest.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38B61576.3552FA6E@iprg.nokia.com>
Date:         Thu, 24 Feb 2000 21:39:03 -0800
Reply-To: "Charles E. Perkins" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: "Charles E. Perkins" 
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] Registration Keys draft and D-H key exchanges
X-To:         Jouni Malinen 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Jouni,

I'm catching up on e-mail, sorry for the long delay...

I said:

>
> >           This can be done by having the foreign agent include a
> > short digest of its Diffie-Hellman computed value along with the
> > Agent Advertisement.  That will prevent (with high probability)
> > any interloper from getting in the way.

You said:

>
> Do you propose, that a foreign agent would use the same random
> exponent with all the key exchanges or would a new number be generated
> for each registration? If the exponent changes, also the computed
> value changes and then the digest values would have to be somehow
> bound to a correct computed value. It would be at least a bit
> difficult to assign a unique digest for each mobile node performing
> key exchange with multi/broadcast agent advertisements and there would
> be a need for unicast advertisements if each key exchange would be
> required to use a different random value. This may not, however, be
> necessary, if HA uses different random value for each exchange
> (generated session key changes).

What I had in mind was for the foreign agent to generate a new
digested value for each registration from the same mobile node.
That should protect both the foreign agent and the mobile node
against interlopers.

> Could you please give a bit more detailed description of the proposed
> protection against the man-in-the-middle attacks? I'm assuming, that
> you are using similar method that we use in Dynamics - HUT Mobile IP
> implementation (MN sends the digest value protected with MN-HA
> auth. ext. to HA and HA checks whether it matches with the key
> req. ext.). I think it is still possible for an attacker to change the
> key exchange in a way that the attacker will know the key that the FA
> gets, but the HA and the MN get another key (unknown to the attacker).

If the foreign agent advertises the digest, and the mobile node makes it
impossible for an interloper to replace the foreign agent's (expanded)
computed value, how can there be a man-in-the-middle attack?  I am
not aware of the Dynamics method, sorry I haven't read that yet.
I would like to know how an attacker can change anything without
detection, except by making the Registration Key unusable.

> In which operations is the key going to be used? It is quite difficult
> to protect against all the attacks with one pass (reg. req. and
> reply). MN could know from the reply, whether the key exchange
> succeeded, if another digest value generated by HA would be added
> inside the MN-HA ext. auth. protected area of the reply, but I think
> that the HA and the FA could not know about all the attacks without
> further communication with the MN).

The registration key is designed for use with the Binding Update that
would eventually get sent back to the same foreign agent after the
mobile node moves away (and sends a Previous Foreign Agent
Notification extension).  I don't know whether it is safe to use it
as an encryption key.

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Feb 25 05:38:50 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04569
	for ; Fri, 25 Feb 2000 05:38:50 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.01A1CCD0@standards.nortelnetworks.com>; Fri, 25 Feb 2000 5:34:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 59869 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Feb 2000 05:32:47
          -0500
Received: from gorilla.mchh.siemens.de by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.BC018D00@standards.nortelnetworks.com>; Fri, 25 Feb 2000 5:32:41
          -0500
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
          by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA00258; Fri,
          25 Feb 2000 11:34:52 +0100 (MET)
Received: from mchh246e.demchh201e.icn.siemens.de ([218.1.68.146]) by
          moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA19931; Fri, 25
          Feb 2000 11:35:46 +0100 (MET)
Received: by MCHH246E with Internet Mail Service (5.5.2448.0) id ;
          Fri, 25 Feb 2000 11:36:24 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Fri, 25 Feb 2000 11:36:23 +0100
Reply-To: Petri Bernhard 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Petri Bernhard 
Subject:      Re: [MOBILE-IP] Private addressing reference in rfc2002-bis ?
X-To:         Gabriel Montenegro 
X-cc:         "ion@sunroof.eng.sun.com" 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi Gabriel,

some time ago, we ran into similar discussions on how to handle private
addresses in the ION WG, and developed the VPN-ID concept there (RFC 2685).
By this concept, we've e.g. extended existing ION protocols like NHRP (RFC
2332, an address resolution protocol) to be able to also handle private
address realms (RFC 2735).  RFC 2735 e.g. says:
** In order to properly resolve a private VPN address, it is necessary for
the NHRP device to be able to identify the VPN in which the address has
meaning and determine resolution information based on that "scope". ***

VPN-IDs use a fixed 7-octet structure which has been derived from the
structure of the MAC Addresses (3 octet organization identifier "OUI" +
subsequent index value). In the draft I've submitted, I've used the VPN-ID
as a "realm identifier" within the context of IP-IP tunnels. It could
similarly also be used for indicating supported address realms in FA
advertisements.

I prefer such a small fixed-size identfier to DNS-like solutions for the
indication of an address realm. It's easy to use and can be easily inserted
in protocol formats. If a company already owns an OUI, it can immediately
identify their address realms without asking any remote allocation
authority; also, network/service providers can immediately allocate
realm-IDs for the private address schemes of user groups / customers without
administrative overhead.

Kind regards
-Bernhard

Bernhard Petri, Siemens
Tel: +49 89 722-34578
Fax: +49 89 722-29098
bernhard.petri@icn.siemens.de
______________________________

> -----Original Message-----
> From: Gabriel Montenegro [SMTP:gab@eng.sun.com]
> Sent: Thursday, February 24, 2000 11:27 PM
> To:   MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: [MOBILE-IP] Private addressing reference in rfc2002-bis
> ?
>
         (...) 

> > Folks seem to like the nai extension idea.
>
> i've been thinking about this in the context of rsip and of
> rfc2344bis and i am more and more convinced that what we need
> is almost there but not quite. what we don't need is the nai.
> the nai (rfc2486) was designed for and is suitable to identify users
> and roaming devices to the network (e.g. "user@realm").
>
> what we need is for the network to qualify itself to the users
> or roaming devices (e.g. by providing a "realm identifier").
> at first thought, it
> would seem like this is nothing but the "realm" as defined
> in rfc2486 (nai).  whereas mn's and users
> may use nai's to identify themselves, network elements like
> fa's, routers, network access servers could conceivably
> use "realm indicators" to indicate what address space
> or realm they provide access to.
>
> so a "realm" as in the nai is almost it, but we still need
> a human readable ascii label (or do we?) for the root realm
> (sometimes referred to as the public internet).
>
> this root domain has several representations in section 3.1
> of rfc1034:
>
>    binary: null label
>         'null (i.e., zero length) label used for the root'
>
>    ascii: " "
>         'For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " "'
>
>    ascii: "."
>         'The most common interpretation uses the root "." '
>
> given that an absolute or rooted fqdn (from which the "realm" in the
> nai derives) terminates with a "." (e.g. "domain.com."), then
> perhaps that could be used as the ascii representation of
> the root realm, specially given the precedent shown above.
> the ABNF for a "realm indicator" (ri) could simply be:
>
>    realm-indicator  = realm / "."
>
>    realm            = 
>
> a general "private address" extension might need to indicate
> what ri an agent address belongs to (home agent or care-of
> address):
>
>         coa, ri
>
> >
> > > the private addr extension need not be included in all advertisements.
> upon hearing a 'P' bit,
> > > the mn could solicit with a special code, say in order to obtain the
> priv
> > > addr extension.
> > >
> >
> > I like this idea. Although I am not quite clear on the idea about the
> home
> > agent advertisement. If a HA has one side public net and private net on
> the
> > other side, then what address would it advertise on the private side ?
> Do we
> > assume that  the private addressed MNs never come back home and they are
> > pre-configured to use HA's global address ? On the other hand if HA
> > advertises private address on it's private net, then we assume that MNs
> are
> > intelligent enough  to figure out which home agent address to use when
> they
> > are away from home.
>
> a multihomed device with one interface on the "public internet"
> could advertise more than one coa/ri pair, for example:
>
>         ipaddr1, "domain.com."
>         ipaddr2, "."
>
> a cursory glance might indicate that the above is similar to the
> use of point code and network indicator in section 3.2.2 of:
>
> http://search.ietf.org/internet-drafts/draft-coene-ss7-over-ip-00.txt
>
> but i really don't understand ss7.
> just some random thoughts...
>
> -gabriel


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Fri Feb 25 20:11:24 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23925
	for ; Fri, 25 Feb 2000 20:11:24 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F5C59AC0@standards.nortelnetworks.com>; Fri, 25 Feb 2000 20:07:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 60549 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 25 Feb 2000 20:05:49
          -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.503560A0@standards.nortelnetworks.com>; Fri, 25 Feb 2000 19:55:49
          -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 QAA12230; Fri, 25 Feb 2000 16:59:05
          -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by
          engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id
          QAA20492; Fri, 25 Feb 2000 16:59:04 -0800 (PST)
Received: from cali (cali [129.146.122.121]) by nasnfs.eng.sun.com
          (8.9.3+Sun/8.9.1) with SMTP id QAA15529; Fri, 25 Feb 2000 16:59:02
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  
Date:         Fri, 25 Feb 2000 16:59:02 -0800
Reply-To: Gabriel Montenegro 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Gabriel Montenegro 
Subject:      Re: [MOBILE-IP] Private addressing reference in rfc2002-bis ?
X-To:         Petri Bernhard 
X-cc:         "ion@sunroof.eng.sun.com" 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID"
              

interesting, thanks for the pointer to the vpn-id stuff.
hmmm... oui's are another name space...

what i like about realm names is that there is no extra
administration overhead and they are already used within the
nai. from rfc2486 (nai):

   This document defines a new namespace that will need to be
   administered, namely the NAI realm namespace. In order to to avoid
   creating any new administrative procedures, administration of the NAI
   realm namespace will piggyback on the administration of the DNS
   namespace.

   NAI realm names are required to be unique and the rights to use a
   given NAI realm for roaming purposes are obtained coincident with
   acquiring the rights to use a particular fully qualified domain name
   (FQDN).  Those wishing to use an NAI realm name should first acquire
   the rights to use the corresponding FQDN. Using an NAI realm without
   ownership of the corresponding FQDN creates the possibility of
   conflict and therefore is to be discouraged.

also, what is the oui for the root realm?

not all realms will map to a unique oui. in order to specify different
realms (for example for small/informal/impromptu/soho), owners of oui's might
have to get in the business of further administering the subsequent
4 byte octet index value in the vpn-id, to avoid collisions. it gets
messy, specially because the small network operators (driving forces
behind nats and rsip applications) now have to ask a much larger
corporation (large enough to own an oui) to allocate some vpn-id
space for them. perhaps oui's work best at the high-end, with large
corporations and ISP's. not sure they're a good easy thing to use
for smaller networks, where a DNS domain name may be simpler.

by the way, if the idea is to use a fixed size binary representation
for a "vpn-id", did the ion working group consider

in addition to this:

        3 octet oui + 4 octet index value

this?:

        2 octet ASN (autonomous system number) + 4 octet index value

saves you one byte, but most importantly, it reuses stuff that's
already needed as a precondition to getting on the internet.
seems like both oui and asn variations could be useful.

regards,

-gabriel


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sat Feb 26 06:00:53 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13387
	for ; Sat, 26 Feb 2000 06:00:53 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.467B6790@standards.nortelnetworks.com>; Sat, 26 Feb 2000 5:56:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 60714 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 26 Feb 2000 05:55:11
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A54BC870@standards.nortelnetworks.com>; Sat, 26 Feb 2000 5:45:11
          -0500
Received: from ns1.centernix.net (adsl-209-233-220-226.dsl.lsan03.pacbell.net
          [209.233.220.226]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP
          id EAA04638 for ; Sat, 26 Feb 2000 04:48:24
          -0600 (CST)
Received: from localhost (12.30.178.52 [12.30.178.52]) by ns1.centernix.net
          with SMTP (Microsoft Exchange Internet Mail Service Version
          5.5.2650.21) id FLVX880H; Sat, 26 Feb 2000 02:42:31 -0000
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Low
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-References: 0200B2D09, 0604E6D0C
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.7
MessageID: 
Message-ID:  <200002261048.EAA04638@hosaka.smallworks.com>
Date:         Sat, 26 Feb 2000 05:55:11 -0500
Reply-To: 524qfdah@FREEMAILFORALL.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: 524qfdah@FREEMAILFORALL.COM
Subject:      [MOBILE-IP] Private Cyber Club Pays You By The Minute.
X-To:         mdelmar@sprintmail.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,

I just want you to take a quick look at this TRULY
PHENOMENAL one-of-a-kind, PRIVATE OFFSHORE Wealth
Building Program.

It's a PRIVATE By-Invitation-Only OFFSHORE CLUB,
where many of us are earning $500 to $3,500 per DAY!

We get paid BY-THE-MINUTE directly into our Private
Offshore Bank Accounts - 24 hrs a day, 7 days a week
AS PEOPLE JOIN! We are talking about some serious
money here. You'll want to further investigate this
opportunity.

People are JOINING US FAST and you earn $500 EACH.
And that's just from ONE Income Stream - there are
3 MORE! Many are making $80,000 to $100,000 in just
10 to 12 weeks. Yes - it is REALLY TRUE!

Some people are already making 5 figures PER WEEK
from ONE of the other Income Streams that requires
absolutely NO SPONSORING! That's right - this great
program works for everyone. Sales ability is not
required.


GREAT NEWS FOR INTERNATIONAL ENTREPRENEURS

This AMAZING 100% Private Offshore Wealth Building
Program WORKS for people living IN EVERY country in
the WORLD - USA, Australia, Canada, Mexico, Japan,
Brazil, Italy, England, Norway, Germany, France.
EVERY COUNTRY - now 80 countries in just 20 weeks.


MEMBERS PRIVILEDGES INCLUDE:

+ Legal Private Offshore Class 'A' Bank Account.

+ Private International Gold MasterCard Credit Card.
NO daily Cash Limit!!!

+ Private Encrypted Banking Software Program. Allows
you to manage your Offshore account from anywhere in
the world at anytime.

+ Private Secure Encrypted Email Account.

+ Access to International Investment Opportunities.
(PHENOMENAL High Yield)

+ Receive your own complete marketing web site when
you join. People can sign up on-line on it from
around the world 24 hours a day 7 days a week.

This is a LEGAL and LEGITIMATE business opportunity,
that WILL MAKE YOU MORE MONEY than you've ever made
in your life !!  Some Members have retired in just
120 days.


ARE YOU INTERESTED IN LEARNING MORE ?

If you like what you've read so far, and want to
hear about real people who are making more money
than they have ever made before - then I'll send
instructions to my website that has two great
Opportunity Overview Real Audio messages on it!

You can listen for free on your computer, it will
blow you away. If you still want more information,
you can participate in a one of the many free live
interactive daily conference calls, which are open
to any questions you may have.

This program is working better than any other I
have been in - and it's working for those people
who have not been successful at other programs.
You join just once, but the cash keeps rolling in!
I love this program :-)


TO LEARN HOW YOU CAN BECOME A MEMBER ....


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

SEND an email to    info659@crescotek.com

And write "MORE INFO" in the Subject.

Please DO NOT just HIT the REPLY button to this email.
You WON'T get your  "INFO"  IF YOU DO THAT :-(

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

-------------------------------------------------------
If you DON'T want to receive any email we will honor
that. Send an email to  undefin1@lemailparisien.com
-------------------------------------------------------


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Sun Feb 27 15:46:46 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11584
	for ; Sun, 27 Feb 2000 15:46:45 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4302A8F0@standards.nortelnetworks.com>; 27 Feb 2000 15:42:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 61240 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 27 Feb 2000 15:40:42
          -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.01509340@standards.nortelnetworks.com>; 27 Feb 2000 15:40:42 -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 MAA05175;
          Sun, 27 Feb 2000 12:43:32 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.9.3/8.9.3-VIRSCAN) id MAA24839; Sun, 27 Feb 2000 12:43:31 -0800
X-Virus-Scanned:  Sun, 27 Feb 2000 12:43:31 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from  (charliep.iprg.nokia.com
          [205.226.2.89]) by darkstar.iprg.nokia.com  SMTP/WTS (12.69)
          xma024463; Sun, 27 Feb 00 12:43:19 -0800
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38B98C67.A0DC6E22@iprg.nokia.com>
Date:         Sun, 27 Feb 2000 12:43:19 -0800
Reply-To: charliep@IPRG.NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: "Charles E. Perkins" 
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] Revised Network Access Requirements doc
X-To:         Pat Calhoun 
X-cc:         Tom =?iso-8859-1?Q?Weckstr=F6m?= ,
              aaa-wg@merit.edu
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Pat et.al.,

I try to keep up with the discussion, but I might have missed
something.  But when I see the following, I get very nervous...

Tom said:
> > 1. Auditability
> > This is left uncommented by the MIP WG. What does this mean?
> > - MIP does not care whether the MN users get overcharged?
> > - There is no exact decision about this requirement?
> > - This requirementis not affecting MIP implementations, so no comments?
> > Personally, I would place a 'MUST' here.

Pat replied:
> This is an item for the Mobile-IP WG to resolve, not the AAA WG.

I'm not so sure about this.

On the one hand, Mobile IP will run just fine in conjunction with
AAA whether or not the Mobile IP users get overcharged.

On the other hand, the uses for which Mobile IP is to be put in
the cellular industry demand that Mobile IP users _not_ be overcharged.

So, from the system design viewpoint, auditability is a MUST.
But, from the protocol design standpoint, auditability is irrelevant.

Don't we have to state the requirements from the standpoint of
the expected system design?  If so, I agree with Tom that we
need a MUST.

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Feb 28 09:22:37 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09353
	for ; Mon, 28 Feb 2000 09:22:36 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BA1D5820@standards.nortelnetworks.com>; Mon, 28 Feb 2000 9:18:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 61578 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Feb 2000 09:17:40
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A8E51480@standards.nortelnetworks.com>; Mon, 28 Feb 2000 9:17:39
          -0500
Received: from baldo.fub.it (baldo.fub.it [193.204.211.129]) by
          hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id IAA18243 for
          ; Mon, 28 Feb 2000 08:20:55 -0600 (CST)
Received: from [193.204.209.162] by baldo.fub.it (Post.Office MTA v3.5.3
          release 223 ID# 506-59675U600L2S100V35) with ESMTP id it for
          ; Mon, 28 Feb 2000 15:22:46 +0100
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  
Date:         Mon, 28 Feb 2000 15:24:14 +0100
Reply-To: Roberto Winkler 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Roberto Winkler 
Subject:      [MOBILE-IP] comparison of micro-mobility solutions
X-To:         mobile-ip@smallworks.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

hello,

a quick question: has anybody produced a paper comparing the solutions
proposed in the last two years for micro-mobility enhancement of Mobile IP ?

Thanks very much for your help

Roberto

Roberto Winkler
Senior Researcher
Fondazione Ugo Bordoni
Via B. Castiglione, 59
00142 Rome Italy

tel +39 0654803411
fax. +39 0654804404
e-mail wnk@fub.it


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Feb 28 10:36:41 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11814
	for ; Mon, 28 Feb 2000 10:36:41 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1414EA50@standards.nortelnetworks.com>; Mon, 28 Feb 2000 10:32:14 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 61653 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Feb 2000 10:30:50
          -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7C75DF20@standards.nortelnetworks.com>; Mon, 28 Feb 2000 10:20:50
          -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 HAA03686; Mon, 28 Feb 2000 07:23:51
          -0800 (PST)
Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM
          [129.146.65.34]) by engmail2.Eng.Sun.COM
          (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id HAA15452; Mon, 28 Feb
          2000 07:23:50 -0800 (PST)
Received: from darius by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id
          HAA06217; Mon, 28 Feb 2000 07:23:47 -0800
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  
Date:         Mon, 28 Feb 2000 07:23:47 -0800
Reply-To: "pcalhoun@eng.sun.com" 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: "pcalhoun@eng.sun.com" 
Subject:      Re: [MOBILE-IP] Revised Network Access Requirements doc
X-To:         "Charles E. Perkins" 
X-cc:         Pat Calhoun ,
              =?iso-8859-1?Q?Tom_Weckstr=F6m?= ,
              aaa-wg@merit.edu
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID" <38B98C67.A0DC6E22@iprg.nokia.com>

Charlie,

My point was that I, as document editor, could not simply *change* the
document because one person though that the Mobile IP working group really
meant MUST. If you believe that the WG is in fact in the position that
auditability is a MUST for Mobile IP, I will make that change.

PatC
----
>
> Hello Pat et.al.,
>
> I try to keep up with the discussion, but I might have missed
> something.  But when I see the following, I get very nervous...
>
> Tom said:
> > > 1. Auditability
> > > This is left uncommented by the MIP WG. What does this mean?
> > > - MIP does not care whether the MN users get overcharged?
> > > - There is no exact decision about this requirement?
> > > - This requirementis not affecting MIP implementations, so no comments?
> > > Personally, I would place a 'MUST' here.
>
> Pat replied:
> > This is an item for the Mobile-IP WG to resolve, not the AAA WG.
>
> I'm not so sure about this.
>
> On the one hand, Mobile IP will run just fine in conjunction with
> AAA whether or not the Mobile IP users get overcharged.
>
> On the other hand, the uses for which Mobile IP is to be put in
> the cellular industry demand that Mobile IP users _not_ be overcharged.
>
> So, from the system design viewpoint, auditability is a MUST.
> But, from the protocol design standpoint, auditability is irrelevant.
>
> Don't we have to state the requirements from the standpoint of
> the expected system design?  If so, I agree with Tom that we
> need a MUST.
>
> Regards,
> Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Feb 28 10:42:12 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11982
	for ; Mon, 28 Feb 2000 10:42:12 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5C2A6FE0@standards.nortelnetworks.com>; Mon, 28 Feb 2000 10:34:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 61662 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Feb 2000 10:33:11
          -0500
Received: from sonne.darmstadt.gmd.de by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.35E84730@standards.nortelnetworks.com>; Mon, 28 Feb 2000 10:33:11
          -0500
Received: from darmstadt.gmd.de (rho [141.12.34.56]) by sonne.darmstadt.gmd.de
          (8.8.8/8.8.5) with ESMTP id QAA18405; Mon, 28 Feb 2000 16:36:30 +0100
          (MET)
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: de,en,it
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38BA95CA.E7C8C8BA@darmstadt.gmd.de>
Date:         Mon, 28 Feb 2000 16:35:38 +0100
Reply-To: Wolfgang Schoenfeld 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Wolfgang Schoenfeld 
Organization: GMD IPSI Darmstadt Deutschland
Subject:      Re: [MOBILE-IP] comparison of micro-mobility solutions
X-cc:         Roberto Winkler 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Roberto Winkler wrote:
>
> hello,
>
> a quick question: has anybody produced a paper comparing the solutions
> proposed in the last two years for micro-mobility enhancement of Mobile IP ?
>
> Thanks very much for your help
>
> Roberto
>
> Roberto Winkler
> Senior Researcher
> Fondazione Ugo Bordoni
> Via B. Castiglione, 59
> 00142 Rome Italy
>
> tel +39 0654803411
> fax. +39 0654804404
> e-mail wnk@fub.it

There is "Mobility Management in Next-Generation Wireless Systems" by Akyildiz
e.a.
in Proc. IEEE 87.8 (Aug. 1999), but it's not precisely what you seem to look
for.
In particular, it does not mention Hierarchical MIP, Cellular MIP etc.

There is also draft-ietf-mobileip-arc (expired July 1999),
a general description of the problem.

But I don't know of a paper which really fits to your question
(and suppose that there is none).
--
Wolfgang Schoenfeld
GMD-IPSI, Dolivostr. 15, Room 128, D-64293 Darmstadt
+49-6151-869-865 (Phone), -818 (FAX)
+49-170-2285450 (Mobile Phone)


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Feb 28 15:19:47 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19202
	for ; Mon, 28 Feb 2000 15:19:46 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.88BFF120@standards.nortelnetworks.com>; Mon, 28 Feb 2000 15:14:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 61922 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Feb 2000 15:12:44
          -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.DDDC0970@standards.nortelnetworks.com>; Mon, 28 Feb 2000
          15:02:44 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 28 Feb 2000 14:06:10 -0600
Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Mon, 28
          Feb 2000 15:05:45 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          ; Mon, 28 Feb 2000 14:05:45 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF8227.30E1D94A"
Message-ID:  
Date:         Mon, 28 Feb 2000 14:05:41 -0600
Reply-To: Parag Panse 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Parag Panse 
Subject:      [MOBILE-IP] test
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_01BF8227.30E1D94A
Content-Type: text/plain;
        charset="ISO-8859-1"


------_=_NextPart_001_01BF8227.30E1D94A
Content-Type: text/html;
        charset="ISO-8859-1"






test





------_=_NextPart_001_01BF8227.30E1D94A--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Feb 28 15:25:43 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19326
	for ; Mon, 28 Feb 2000 15:25:43 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.854728A0@standards.nortelnetworks.com>; Mon, 28 Feb 2000 15:21:44 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 62009 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Feb 2000 15:20:24
          -0500
Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.55A67880@standards.nortelnetworks.com>; Mon, 28 Feb 2000 15:20:24
          -0500
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by
          mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id WAA20079; Mon, 28 Feb
          2000 22:23:46 +0200 (EET)
Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com
          [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id
          WAA02282; Mon, 28 Feb 2000 22:23:45 +0200 (EET)
Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <1RM2916F>;
          Mon, 28 Feb 2000 14:22:55 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <7B5C0390ACE7D211BC9C0008C7EABA2B9296EB@daeis07nok>
Date:         Mon, 28 Feb 2000 14:22:52 -0600
Reply-To: Basavaraj.Patil@NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Basavaraj Patil 
Subject:      [MOBILE-IP] WG last call - draft-ietf-mobileip-rfc2002-bis-01.txt
X-cc:         qa3445@email1.wes.mot.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

WG members,

I-D draft-ietf-mobileip-rfc2002-bis-01.txt is the revised version of
the IP Mobility Support for IPv4 RFC.
This is a WG last call for this I-D. This draft will be sent to the
IESG requesting a proposed standard status at the end of the last call
period. Comments appreciated.

WG last call issued on : Feb 28th, 2000
Expires on : March 10th, 2000


Regards,
Basavaraj Patil
Phil Roberts


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Feb 28 17:10:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21696
	for ; Mon, 28 Feb 2000 17:10:06 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.14351780@standards.nortelnetworks.com>; Mon, 28 Feb 2000 17:05:57 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 62167 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Feb 2000 17:04:14
          -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.D73E3FF0@standards.nortelnetworks.com>; Mon, 28 Feb 2000
          17:04:14 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 28 Feb 2000 16:06:14 -0600
Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Mon, 28
          Feb 2000 17:06:00 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          ; Mon, 28 Feb 2000 16:06:01 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF8237.FF122B7A"
Message-ID:  
Date:         Mon, 28 Feb 2000 16:05:59 -0600
Reply-To: Parag Panse 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Parag Panse 
Subject:      [MOBILE-IP] IP address allocation and NAI
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_01BF8237.FF122B7A
Content-Type: text/plain;
        charset="ISO-8859-1"

Hi,
I have two questions regarding dynamic IP address allocation for a mobile
node.
1. The NAI extension draft allows the MN's home address to be zero. This
would imply that as a part of the registration process the HA would issue
the MN an IP address. My question is at what point in time should the HA
take action to free this allocated IP address? One indication to free up
this address is when the MN's registration timer at the HA expires. However
as a part of the (implicit) de-registration process when the MN moves from
FA to HA, the timer is killed. In such an event how is the HA to free up the
IP address.

A side question is that if DHCP is to be used at the HA for IP address
allocation then once DHCP server allocates the address, who manages the
timer for the DHCP request? Is it the HA or the MN?

2. The NAI extension draft talks about what should be done at the FA.
However when an MN (having zero home address) boots up in it's home network,
there is no registration reqest sent. How should it's address allocation be
done?

Regards...
-Parag

------_=_NextPart_001_01BF8237.FF122B7A
Content-Type: text/html;
        charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






IP address allocation and NAI




Hi,

I have two questions regarding =
dynamic IP address allocation for a mobile node.

1. The NAI extension draft allows the =
MN's home address to be zero. This would imply that as a part of the =
registration process the HA would issue the MN an IP address. My =
question is at what point in time should the HA take action to free =
this allocated IP address? One indication to free up this address is =
when the MN's registration timer at the HA expires. However as a part =
of the (implicit) de-registration process when the MN moves from FA to =
HA, the timer is killed. In such an event how is the HA to free up the =
IP address.



A side question is that if DHCP is to =
be used at the HA for IP address allocation then once DHCP server =
allocates the address, who manages the timer for the DHCP request? Is =
it the HA or the MN?



2. The NAI extension draft talks about =
what should be done at the FA. However when an MN (having zero home =
address) boots up in it's home network, there is no registration reqest =
sent. How should it's address allocation be done?



Regards...

-Parag





------_=_NextPart_001_01BF8237.FF122B7A--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Feb 28 23:30:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29087
	for ; Mon, 28 Feb 2000 23:30:36 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3AABF1B0@standards.nortelnetworks.com>; Mon, 28 Feb 2000 23:26:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 62529 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Feb 2000 23:24:32
          -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.F7AC2650@standards.nortelnetworks.com>; Mon, 28 Feb 2000 23:24:32
          -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 UAA19788;
          Mon, 28 Feb 2000 20:27:25 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.9.3/8.9.3-VIRSCAN) id UAA29273; Mon, 28 Feb 2000 20:27:24 -0800
X-Virus-Scanned:  Mon, 28 Feb 2000 20:27:24 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from  (charliep.iprg.nokia.com
          [205.226.2.89]) by darkstar.iprg.nokia.com  SMTP/WTS (12.69)
          xma028942; Mon, 28 Feb 00 20:27:11 -0800
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <38A4588D.92FCE771@alcatel.be> <38A4951C.A369B13F@iprg.nokia.com>
            <00021414482106.24820@tpce13>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38BB4A9F.34ACF492@iprg.nokia.com>
Date:         Mon, 28 Feb 2000 20:27:11 -0800
Reply-To: charliep@IPRG.NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: "Charles E. Perkins" 
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] micromobility in IPv6 ?
X-To:         paehlke@telematik.informatik.uni-karlsruhe.de
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Frank,

I take your comment as relevant to the recently announced Last Call
for RFC2002bis.  In that case, we should get some clarification so
that I can figure out whether to change the current draft.

> the problem, at least as far as I can tell, is the following sentence
> which appears in RFC 2002 as well as in the latest RFC 2002bis draft
> (section 3.6.2.1):
>
> "[...] if the Code field indicates that the registration was accepted
> by the home agent, exactly one Mobile-Home Authentication Extension
> MUST be present in the Registration Reply, and the mobile node MUST
> check the  Authenticator value in the Extension."

Yes, the idea being that a mobile node registers _only_ with its
home agent.

>                                             Perhaps it would be
> better to add a statement like "The Mobile-Home Authentication
> Extension is not needed if a security association is established between
> the Mobile Node and the foreign network's infrastructure, and the
> Registration Reply contains a valid Mobile-Foreign Authentication
> Extension." This is already explicitly demanded by the HAWAII draft and
> implemented, for example, in HUT Dynamics.

In the first place, any new protocol specification that advances
to Proposed Standard can suggest modifications to RFC2002bis that
have the effect of obsoleting part of the prior specification for
any network device that adheres to the later specification.

Even so, I would agree that minor adjustments to RFC2002bis are
preferable to waiting for advancement of other specifications,
whenever the adjustments are known to be interoperable and effective
and so on.

I don't see that this change satisfies those criteria.  But, if
others in the working group ask for the change, I would not mind
putting something in.

One major problem would be to have an unambiguous definition of the
words "foreign network's infrastructure".  That's pretty vague, it
seems to me.

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Mon Feb 28 23:53:28 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29607
	for ; Mon, 28 Feb 2000 23:53:28 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.744C6AF0@standards.nortelnetworks.com>; Mon, 28 Feb 2000 23:49:30 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 62592 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 28 Feb 2000 23:47:51
          -0500
Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.D3BA4450@standards.nortelnetworks.com>; Mon, 28 Feb 2000 23:37:51
          -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 UAA08643 for
          ; Mon, 28 Feb 2000 20:41:16
          -0800 (PST)
Received: from audeen.eng.sun.com (audeen.Eng.Sun.COM [129.146.86.142]) by
          engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id
          UAA09434; Mon, 28 Feb 2000 20:41:14 -0800 (PST)
Received: from audeen (audeen [129.146.86.142]) by audeen.eng.sun.com
          (8.9.3+Sun/8.9.3) with SMTP id UAA04284; Mon, 28 Feb 2000 20:39:34
          -0800 (PST)
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 4v7C11to7We7KvWr6pR5DQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4m sparc
Message-ID:  <200002290439.UAA04284@audeen.eng.sun.com>
Date:         Mon, 28 Feb 2000 20:39:33 -0800
Reply-To: Carl Williams 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Carl Williams 
Subject:      [MOBILE-IP] IPv6 Wireless and Mobility Roundtable
X-To:         ipng@sunroof.eng.sun.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

IPv6 Wireless and Mobility Roundtable
=====================================

Connectathon 2000 is presenting a roundtable
discussion on IPv6 Wireless and Mobility as part of
the interoperability testing event this year. The
roundtable is being cosponsored with the IPv6 Forum.

The panel will contain key individuals leading the
standards, research and/or implementation efforts in
IPv6 and Wireless protocols. The discussion is open to
anyone.  An email invitation is being sent out to the
Mobile IP and IPv6 IETF working group members to
participate in the audience.  Members of the audience
will have an opportunity to ask questions to the panel
on topics relating to IPv6 and Wireless.

Round Table Discussion: IPv6 for Wireless and Mobility

The wireless cellular industry, particularly as it
prepares to deploy 2.5G and 3G services has been touted
as the "killer application" for IPv6. An obvious first
consideration to support this notion is the sheer number of
devices expected to come on-line via cellular technologies.
Predictions range from 600 million to 1 billion at the turn
of 4 to 5 years. Managing such a large and sudden influx
of devices connected via highly dynamic and unreliable
links is a task far more challenging than any the Internet
has faced to date.

The panel will explore how IPv6 can rise to the challenge,
as well as its remaining deficiencies. The following
features of IPv6 are some of the topics (but not limited to)
that will be discussed at the roundtable:

- How can IPv6 streamline the routing infrastructure?
  IPv6 may have a better chance than IPv4 at
  route aggregation, because of better initial
  assignment of address ranges and because of
  its provisions for renumbering. What remains
  to be done?
- Role of autoconfiguration for mobile networking.
  Mobile and wireless devices need to bootstrap all
  configuration information based on a secure token
  or on a cryptographic identity. The rest should
  be automatic. This is particularly relevant when
  considering other wireless technologies like
  Bluetooth that will need to interact with cellular,
  and in which the automatic configuration requirements
  apply to a collection of devices.
- How can IPv6 improve the security infrastructure?
  IPv6 does mandate IPsec, but how practical or
  deployable is it in a cellular environment?
- Can Mobile IP simplify the future Internet? Does
  IPv6 provide other mechanisms to deal with mobility?
  Is it better handled at a layer other than layer 3
  (as in Mobile IP)?
- What is the interaction between IPv6 and cellular
  telephone standards?
  There seems to be little more than lip service to IPv6
  on the part of next generation cellular consortiums
  like 3GPP, 3GPP2, and MWIF. Do they have valid concerns?
- Issues with supporting 500 Million IP Wireless Devices.
  What is the right addressing scheme that needs to be used?
  Are E.164 based addresses more appropriate for cellular
  than EUI-64 (more common with LAN hardware)?
- The IPv6 header is twice as large as its IPv4 counterpart,
  but routers should have a much easier time processing and
  forwarding packets.

The above issues apply to both the core network as well as
to the wireless devices.  Members of the audience can
raise any topic regarding IPv6 for Mobility or Wireless
at this roundtable.  Discussion is not limited to those
topics above.


Roundtable Panel

Charlie Perkins                      Robert Hinden
Nokia Research Laboratories          Nokia

Steve Deering                        Martin Korling
Cisco Systems                        Ericsson Research

Erik Nordmark                        Dave Johnson
Sun Microsystems                     Carnegie Mellon University

Brian Zill                           Jun-ichiro Hagino
Microsoft Research                   Internet Initiative Japan Inc.

Mihai Mateescu
Mobile and Broadband Wireless Communications of GMD


Date, Time and Place

Monday, March 6, 2000
4:00pm-6:00pm

Crowne Plaza Hotel
282 Almaden Blvd
San Jose, CA
Phone # for Crowne Plaza: (408) 998-0400

The roundtable discussion will take place in the Crowne
Plaza Hotel Ballroom.  You do *not* need to RSVP to attend
the roundtable.  Just show up at the Crowne Plaza Hotel
Ballroom.  There is no registration required for participating.
While admission to the IPv6 Wireless and Mobility roundtable is
free and open to all, only registered participants of Connectathon
will be allowed into the testing halls.

Mobile IP Dinner
================

Some members of the panel will be joining Connectathon
participants for dinner after the event at a local San Jose
restaurant.  If you are interested in attending the dinner
you *must* RSVP John Hird at jrh@eng.sun.com.  You will be
responsible for the cost of your dinner.  More information
about where the dinner will be provided at the roundtable
event.  There will be limited room so the RSVP will be on
a first come basis.

Ericsson Presentation
=====================

A presentation by Ericsson will be made on their Mobile IPv6
research implementation immediately preceding the roundtable
in the same room (Crowne Plaza Hotel Ballroom) from 3:00pm-3:45pm.
Conny Larsson of Ericsson Research will be presenting.  Again,
this is open to anyone.

Abstract of talk by Conny Larsson, Ericsson Research:

The Ericsson Mobile IPv6 implementation is a free implementation
using FreeBSD and the KAME IPv6 implementation. It has been
implemented as part of a research project at Ericsson. It consists
of three parts; the Correspondent Node, the Home Agent and the
Mobile Node. In addition, two applications are offered for
configuration and retrieving statistical information.  This talk
will go over the Ericsson Research Mobile IPv6 implementation.


References:

www.connectathon.org  - for more information on Connectathon 2000.
www.ipv6forum.com     - for more information on the Worldwide
                        consortium of leading Internet vendors,
                        Research & Education Networks.

Connectathon 2000 participants performing interoperability testing
for the Mobile IP, IPv6, Mobile IPv6 and/or DIAMETER protocols:

Apple Computer, Inc., Cisco Systems, Inc., Carnegie Mellon University,
Ericsson Inc., ENST (Ecole National Superieure des Telecommunications) Bretagne,
Hewlett-Packard Company, Hitachi, Ltd., IBM Corporation, KAME Project,
MCI Worldcom, Microsoft Corporation, NEC Corporation, Nokia Research Center,
SCO Ltd., Sun Microsystems, Inc., Silicon Graphics, Inc., TAHI, Toshiba
Corporation, University of New Hampshire, Mobile and Broadband Wireless
Communications of GMD


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 03:22:51 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13372
	for ; Tue, 29 Feb 2000 03:22:51 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B03ACD00@standards.nortelnetworks.com>; Tue, 29 Feb 2000 3:18:45 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 62730 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 03:17:28
          -0500
Received: from mymlan.lifix.fi by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.1BE56E90@standards.nortelnetworks.com>; Tue, 29 Feb 2000 3:07:27
          -0500
Received: from ban by mymlan.lifix.fi with local id 12PhjJ-0006Ad-00; Tue, 29
          Feb 2000 10:10:05 +0200
Mail-Followup-To: Basavaraj Patil ,
                  MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
References: <7B5C0390ACE7D211BC9C0008C7EABA2B9296EB@daeis07nok>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.0.1i
Message-ID:  <20000229101005.A23614@mymlan.lifix.fi>
Date:         Tue, 29 Feb 2000 10:10:05 +0200
Reply-To: bjorn@lifix.fi
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Bjorn Andersson 
Subject:      Re: [MOBILE-IP] WG last call -
              draft-ietf-mobileip-rfc2002-bis-01.txt
X-To:         Basavaraj Patil 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <7B5C0390ACE7D211BC9C0008C7EABA2B9296EB@daeis07nok>; from
              Basavaraj.Patil@NOKIA.COM on Mon, Feb 28, 2000 at 02:22:52PM -0600
Content-Transfer-Encoding: 8bit

On Mon, Feb 28 2000, at 14:22:52 -0600, Basavaraj Patil wrote:
> I-D draft-ietf-mobileip-rfc2002-bis-01.txt is the revised version of
> the IP Mobility Support for IPv4 RFC.
> This is a WG last call for this I-D. This draft will be sent to the
> IESG requesting a proposed standard status at the end of the last call
> period. Comments appreciated.

In section 3.7.1 there is a reference to a section that is not
right:
    - the IP Destination Address (as specified in 3.6.2.3)

I believe this should be "as specified in 3.6.1.1".

(It would also be nice with form feeds at the end of each page.)

Regards,
Björn Andersson

--
Björn Andersson                          +358-50-3412556
Lifix Systems Oy 
Tekniikantie 21, FIN-02150 Espoo                         +358-9-25175272


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 03:26:47 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13435
	for ; Tue, 29 Feb 2000 03:26:47 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F7EEAA90@standards.nortelnetworks.com>; Tue, 29 Feb 2000 3:20:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 62733 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 03:18:54
          -0500
Received: from mailgate.rz.uni-karlsruhe.de by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.B56FA7F0@standards.nortelnetworks.com>; Tue, 29 Feb 2000 3:18:54
          -0500
Received: from blackfoot.telematik.informatik.uni-karlsruhe.de
          (blackfoot.telematik.informatik.uni-karlsruhe.de [129.13.35.14]) by
          mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.02 #2) id
          12PhvA-00059P-00; Tue, 29 Feb 2000 09:22:20 +0100
Received: from telematik.informatik.uni-karlsruhe.de
          (paehlke@tpce13.telematik.informatik.uni-karlsruhe.de
          [129.13.41.113]) by blackfoot.telematik.informatik.uni-karlsruhe.de
          (8.9.3/8.9.3) with ESMTP id JAA19037; Tue, 29 Feb 2000 09:22:19 +0100
          (MET)
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: German, de, en
MIME-Version: 1.0
References: <38A4588D.92FCE771@alcatel.be> <38A4951C.A369B13F@iprg.nokia.com>
            <00021414482106.24820@tpce13> <38BB4A9F.34ACF492@iprg.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38BB81BB.5284AF6A@telematik.informatik.uni-karlsruhe.de>
Date:         Tue, 29 Feb 2000 09:22:19 +0100
Reply-To: paehlke@TELEMATIK.INFORMATIK.UNI-KARLSRUHE.DE
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Frank Paehlke 
Organization: University of Karlsruhe
Subject:      Re: [MOBILE-IP] micromobility in IPv6 ?
X-To:         "Charles E. Perkins" 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello,

"Charles E. Perkins" wrote:
>
> Hello Frank,
>
> I take your comment as relevant to the recently announced Last Call
> for RFC2002bis.  In that case, we should get some clarification so
> that I can figure out whether to change the current draft.

many thanks for your interest, which I consider a big honour. Since the
mentioned comment was my first posting to this list, I was really a bit
afraid of being flamed.

> > the problem, at least as far as I can tell, is the following sentence
> > which appears in RFC 2002 as well as in the latest RFC 2002bis draft
> > (section 3.6.2.1):
> >
> > "[...] if the Code field indicates that the registration was accepted
> > by the home agent, exactly one Mobile-Home Authentication Extension
> > MUST be present in the Registration Reply, and the mobile node MUST
> > check the  Authenticator value in the Extension."
>
> Yes, the idea being that a mobile node registers _only_ with its
> home agent.

This is surely the most obvious approach as far as optimized local
handoff is not an issue. It also guarantees secure mutual authentication
of an MN and its home agent.

> >                                             Perhaps it would be
> > better to add a statement like "The Mobile-Home Authentication
> > Extension is not needed if a security association is established between
> > the Mobile Node and the foreign network's infrastructure, and the
> > Registration Reply contains a valid Mobile-Foreign Authentication
> > Extension." This is already explicitly demanded by the HAWAII draft and
> > implemented, for example, in HUT Dynamics.
>
> In the first place, any new protocol specification that advances
> to Proposed Standard can suggest modifications to RFC2002bis that
> have the effect of obsoleting part of the prior specification for
> any network device that adheres to the later specification.
>
> Even so, I would agree that minor adjustments to RFC2002bis are
> preferable to waiting for advancement of other specifications,
> whenever the adjustments are known to be interoperable and effective
> and so on.

The idea behind my comment was to facilitate the development of
specifications which provide fast local handoffs (I am doing research in
this area, together with some colleagues, for my PhD thesis). As far as
I can see, such handoffs will have to be carried out without involving
the HA, which is difficult to achieve without breaking the standard in
its current form. All proposals for fast handoff (e.g., HAWAII the HUT
Dynamics implementation) require the establishment of a security
association between the MN and the foreign network, which is then used
to authenticate the MN upon subsequent registrations without involving
the home agent.

> I don't see that this change satisfies those criteria.  But, if
> others in the working group ask for the change, I would not mind
> putting something in.
>
> One major problem would be to have an unambiguous definition of the
> words "foreign network's infrastructure".  That's pretty vague, it
> seems to me.

Probably the most common approach would be to establish a security
association between the MN and the foreign agent (e.g., as specified in
the AAA-regkey draft). When saying "foreign network's infrastructure", I
was thinking that perhaps there could also be a security association
with some other entity, e.g., a AAA server or the like. In HUT Dynamics,
for example, the security association is between the MN and *all*
foreign agents on the path towards the "highest FA".

But as long as these thoughts are relatively vague, I now agree with you
that it would probably be better to explicitly demand a security
association between the MN and a foreign agent (old, new, or first
common parent of old and new). I deliberately chose the wording "a
statement like..." because I was not 100% sure (and because I am not a
native speaker of English :-)

Regards,
Frank Paehlke
--
Frank Paehlke
Institut fuer Telematik       Phone: +49 721 608-6398
Universitaet Karlsruhe (TH)   Fax:   +49 721 388097
D-76128 Karlsruhe, Germany    EMail: paehlke@ira.uka.de


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 06:35:37 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15077
	for ; Tue, 29 Feb 2000 06:35:37 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8E17FC50@standards.nortelnetworks.com>; Tue, 29 Feb 2000 6:31:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 62950 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 06:30:28
          -0500
Received: from mail3.intekom.com (196.25.69.16) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.123E9F40@standards.nortelnetworks.com>; Tue, 29 Feb 2000 6:20:27
          -0500
Received: from cbs53-03-173.wc.saix.net ([155.239.135.173] helo=[192.168.1.3])
          by mail3.intekom.com with esmtp (Exim 3.13 #2) id 12Pkkl-00041z-00;
          Tue, 29 Feb 2000 13:23:48 +0200
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Mime-version: 1.0
X-Priority: 3
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Message-ID:  
Date:         Tue, 29 Feb 2000 13:25:00 +0000
Reply-To: Baron Victor von Maltzahn 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Baron Victor von Maltzahn 
Subject:      [MOBILE-IP] Unsubscribe
X-To:         paehlke@TELEMATIK.INFORMATIK.UNI-KARLSRUHE.DE
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Unsubscribe

----------
>From: Frank Paehlke 
>To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
>Subject: Re: [MOBILE-IP] micromobility in IPv6 ?
>Date: Tue, 29 Feb, 2000, 8:22
>

> Hello,
>
> "Charles E. Perkins" wrote:
>>
>> Hello Frank,
>>
>> I take your comment as relevant to the recently announced Last Call
>> for RFC2002bis.  In that case, we should get some clarification so
>> that I can figure out whether to change the current draft.
>
> many thanks for your interest, which I consider a big honour. Since the
> mentioned comment was my first posting to this list, I was really a bit
> afraid of being flamed.
>
>> > the problem, at least as far as I can tell, is the following sentence
>> > which appears in RFC 2002 as well as in the latest RFC 2002bis draft
>> > (section 3.6.2.1):
>> >
>> > "[...] if the Code field indicates that the registration was accepted
>> > by the home agent, exactly one Mobile-Home Authentication Extension
>> > MUST be present in the Registration Reply, and the mobile node MUST
>> > check the  Authenticator value in the Extension."
>>
>> Yes, the idea being that a mobile node registers _only_ with its
>> home agent.
>
> This is surely the most obvious approach as far as optimized local
> handoff is not an issue. It also guarantees secure mutual authentication
> of an MN and its home agent.
>
>> >                                             Perhaps it would be
>> > better to add a statement like "The Mobile-Home Authentication
>> > Extension is not needed if a security association is established between
>> > the Mobile Node and the foreign network's infrastructure, and the
>> > Registration Reply contains a valid Mobile-Foreign Authentication
>> > Extension." This is already explicitly demanded by the HAWAII draft and
>> > implemented, for example, in HUT Dynamics.
>>
>> In the first place, any new protocol specification that advances
>> to Proposed Standard can suggest modifications to RFC2002bis that
>> have the effect of obsoleting part of the prior specification for
>> any network device that adheres to the later specification.
>>
>> Even so, I would agree that minor adjustments to RFC2002bis are
>> preferable to waiting for advancement of other specifications,
>> whenever the adjustments are known to be interoperable and effective
>> and so on.
>
> The idea behind my comment was to facilitate the development of
> specifications which provide fast local handoffs (I am doing research in
> this area, together with some colleagues, for my PhD thesis). As far as
> I can see, such handoffs will have to be carried out without involving
> the HA, which is difficult to achieve without breaking the standard in
> its current form. All proposals for fast handoff (e.g., HAWAII the HUT
> Dynamics implementation) require the establishment of a security
> association between the MN and the foreign network, which is then used
> to authenticate the MN upon subsequent registrations without involving
> the home agent.
>
>> I don't see that this change satisfies those criteria.  But, if
>> others in the working group ask for the change, I would not mind
>> putting something in.
>>
>> One major problem would be to have an unambiguous definition of the
>> words "foreign network's infrastructure".  That's pretty vague, it
>> seems to me.
>
> Probably the most common approach would be to establish a security
> association between the MN and the foreign agent (e.g., as specified in
> the AAA-regkey draft). When saying "foreign network's infrastructure", I
> was thinking that perhaps there could also be a security association
> with some other entity, e.g., a AAA server or the like. In HUT Dynamics,
> for example, the security association is between the MN and *all*
> foreign agents on the path towards the "highest FA".
>
> But as long as these thoughts are relatively vague, I now agree with you
> that it would probably be better to explicitly demand a security
> association between the MN and a foreign agent (old, new, or first
> common parent of old and new). I deliberately chose the wording "a
> statement like..." because I was not 100% sure (and because I am not a
> native speaker of English :-)
>
> Regards,
> Frank Paehlke
> --
> Frank Paehlke
> Institut fuer Telematik       Phone: +49 721 608-6398
> Universitaet Karlsruhe (TH)   Fax:   +49 721 388097
> D-76128 Karlsruhe, Germany    EMail: paehlke@ira.uka.de


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 06:49:28 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15079
	for ; Tue, 29 Feb 2000 06:35:37 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8E3BB0F0@standards.nortelnetworks.com>; Tue, 29 Feb 2000 6:31:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 62951 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 06:30:33
          -0500
Received: from mail3.intekom.com (196.25.69.16) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.14BD81F0@standards.nortelnetworks.com>; Tue, 29 Feb 2000 6:20:32
          -0500
Received: from cbs53-03-173.wc.saix.net ([155.239.135.173] helo=[192.168.1.3])
          by mail3.intekom.com with esmtp (Exim 3.13 #2) id 12Pkkh-00041z-00;
          Tue, 29 Feb 2000 13:23:43 +0200
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Mime-version: 1.0
X-Priority: 3
Content-type: text/plain; charset="ISO-8859-1"
Message-ID:  
Date:         Tue, 29 Feb 2000 13:24:55 +0000
Reply-To: Baron Victor von Maltzahn 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Baron Victor von Maltzahn 
Subject:      [MOBILE-IP] Unsubscribe
X-To:         bjorn@lifix.fi
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA15079

Unsubscribe

----------
>From: Bjorn Andersson 
>To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
>Subject: Re: [MOBILE-IP] WG last call - draft-ietf-mobileip-rfc2002-bis-01.txt
>Date: Tue, 29 Feb, 2000, 8:10
>

> On Mon, Feb 28 2000, at 14:22:52 -0600, Basavaraj Patil wrote:
>> I-D draft-ietf-mobileip-rfc2002-bis-01.txt is the revised version of
>> the IP Mobility Support for IPv4 RFC.
>> This is a WG last call for this I-D. This draft will be sent to the
>> IESG requesting a proposed standard status at the end of the last call
>> period. Comments appreciated.
>
> In section 3.7.1 there is a reference to a section that is not
> right:
>     - the IP Destination Address (as specified in 3.6.2.3)
>
> I believe this should be "as specified in 3.6.1.1".
>
> (It would also be nice with form feeds at the end of each page.)
>
> Regards,
> Björn Andersson
>
> --
> Björn Andersson                          +358-50-3412556
> Lifix Systems Oy 
> Tekniikantie 21, FIN-02150 Espoo                         +358-9-25175272


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 06:52:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15262
	for ; Tue, 29 Feb 2000 06:52:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F28F3700@standards.nortelnetworks.com>; Tue, 29 Feb 2000 6:48:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 63049 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 06:47:02
          -0500
Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.62B94630@standards.nortelnetworks.com>; Tue, 29 Feb 2000 6:37:01
          -0500
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by
          ftpbox.mot.com (ftpbox 2.1) with ESMTP id EAA19955 for
          ; Tue, 29 Feb 2000 04:40:28
          -0700 (MST)]
Received: [from charminar.mihy.mot.com (charminar.mihy.mot.com [217.1.175.3])
          by pobox.mot.com (MOT-pobox 2.0) with ESMTP id EAA16090 for
          ; Tue, 29 Feb 2000 04:40:13
          -0700 (MST)]
Received: from hydmail.mihy.mot.com (hydmail.mihy.mot.com [217.1.175.7]) by
          charminar.mihy.mot.com (8.9.1/8.9.1) with ESMTP id RAA23116 for
          ; Tue, 29 Feb 2000 17:10:29
          -0500 (GMT)
Received: by HYDMAIL with Internet Mail Service (5.5.2650.21) id ;
          Tue, 29 Feb 2000 17:08:42 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Tue, 29 Feb 2000 17:08:42 +0530
Reply-To: Ravi Shukla 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Ravi Shukla 
Subject:      Re: [MOBILE-IP] Unsubscribe
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Unsubscribe
-----Original Message-----
From: Baron Victor von Maltzahn [mailto:vma@INTEKOM.CO.ZA]
Sent: Tuesday, February 29, 2000 6:55 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: [MOBILE-IP] Unsubscribe


Unsubscribe

----------
>From: Frank Paehlke 
>To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
>Subject: Re: [MOBILE-IP] micromobility in IPv6 ?
>Date: Tue, 29 Feb, 2000, 8:22
>

> Hello,
>
> "Charles E. Perkins" wrote:
>>
>> Hello Frank,
>>
>> I take your comment as relevant to the recently announced Last Call
>> for RFC2002bis.  In that case, we should get some clarification so
>> that I can figure out whether to change the current draft.
>
> many thanks for your interest, which I consider a big honour. Since the
> mentioned comment was my first posting to this list, I was really a bit
> afraid of being flamed.
>
>> > the problem, at least as far as I can tell, is the following sentence
>> > which appears in RFC 2002 as well as in the latest RFC 2002bis draft
>> > (section 3.6.2.1):
>> >
>> > "[...] if the Code field indicates that the registration was accepted
>> > by the home agent, exactly one Mobile-Home Authentication Extension
>> > MUST be present in the Registration Reply, and the mobile node MUST
>> > check the  Authenticator value in the Extension."
>>
>> Yes, the idea being that a mobile node registers _only_ with its
>> home agent.
>
> This is surely the most obvious approach as far as optimized local
> handoff is not an issue. It also guarantees secure mutual authentication
> of an MN and its home agent.
>
>> >                                             Perhaps it would be
>> > better to add a statement like "The Mobile-Home Authentication
>> > Extension is not needed if a security association is established
between
>> > the Mobile Node and the foreign network's infrastructure, and the
>> > Registration Reply contains a valid Mobile-Foreign Authentication
>> > Extension." This is already explicitly demanded by the HAWAII draft and
>> > implemented, for example, in HUT Dynamics.
>>
>> In the first place, any new protocol specification that advances
>> to Proposed Standard can suggest modifications to RFC2002bis that
>> have the effect of obsoleting part of the prior specification for
>> any network device that adheres to the later specification.
>>
>> Even so, I would agree that minor adjustments to RFC2002bis are
>> preferable to waiting for advancement of other specifications,
>> whenever the adjustments are known to be interoperable and effective
>> and so on.
>
> The idea behind my comment was to facilitate the development of
> specifications which provide fast local handoffs (I am doing research in
> this area, together with some colleagues, for my PhD thesis). As far as
> I can see, such handoffs will have to be carried out without involving
> the HA, which is difficult to achieve without breaking the standard in
> its current form. All proposals for fast handoff (e.g., HAWAII the HUT
> Dynamics implementation) require the establishment of a security
> association between the MN and the foreign network, which is then used
> to authenticate the MN upon subsequent registrations without involving
> the home agent.
>
>> I don't see that this change satisfies those criteria.  But, if
>> others in the working group ask for the change, I would not mind
>> putting something in.
>>
>> One major problem would be to have an unambiguous definition of the
>> words "foreign network's infrastructure".  That's pretty vague, it
>> seems to me.
>
> Probably the most common approach would be to establish a security
> association between the MN and the foreign agent (e.g., as specified in
> the AAA-regkey draft). When saying "foreign network's infrastructure", I
> was thinking that perhaps there could also be a security association
> with some other entity, e.g., a AAA server or the like. In HUT Dynamics,
> for example, the security association is between the MN and *all*
> foreign agents on the path towards the "highest FA".
>
> But as long as these thoughts are relatively vague, I now agree with you
> that it would probably be better to explicitly demand a security
> association between the MN and a foreign agent (old, new, or first
> common parent of old and new). I deliberately chose the wording "a
> statement like..." because I was not 100% sure (and because I am not a
> native speaker of English :-)
>
> Regards,
> Frank Paehlke
> --
> Frank Paehlke
> Institut fuer Telematik       Phone: +49 721 608-6398
> Universitaet Karlsruhe (TH)   Fax:   +49 721 388097
> D-76128 Karlsruhe, Germany    EMail: paehlke@ira.uka.de


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 07:17:25 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15480
	for ; Tue, 29 Feb 2000 07:17:25 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.73926090@standards.nortelnetworks.com>; Tue, 29 Feb 2000 7:13:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 63111 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 07:11:41
          -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.3A3FB1D0@standards.nortelnetworks.com>; Tue, 29 Feb 2000
          7:11:41 -0500
Received: from zmers013 by smtprch1.nortel.com; Tue, 29 Feb 2000 06:14:21 -0600
Received: from zhard00m.europe.nortel.com (actually zhard00m) by zmers013; Tue,
          29 Feb 2000 07:14:00 -0500
Received: by zhard00m.europe.nortel.com with Internet Mail Service
          (5.5.2650.21) id ; Tue, 29 Feb 2000 12:13:57 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF82AE.74492CBA"
Message-ID:  
Date:         Tue, 29 Feb 2000 12:13:57 -0000
Reply-To: Javier Gonzalez 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Javier Gonzalez 
Subject:      [MOBILE-IP] unsubscribe
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_01BF82AE.74492CBA
Content-Type: text/plain

unsubscribe

------_=_NextPart_001_01BF82AE.74492CBA
Content-Type: text/html






unsubscribe




unsubscribe





------_=_NextPart_001_01BF82AE.74492CBA--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 10:21:54 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20662
	for ; Tue, 29 Feb 2000 10:21:53 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3240BB90@standards.nortelnetworks.com>; Tue, 29 Feb 2000 10:17:34 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 63320 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 10:15:36
          -0500
Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.EB3D6950@standards.nortelnetworks.com>; Tue, 29 Feb 2000 10:15:35
          -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 HAA18248;
          Tue, 29 Feb 2000 07:18:29 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.9.3/8.9.3-VIRSCAN) id HAA13104; Tue, 29 Feb 2000 07:18:28 -0800
X-Virus-Scanned:  Tue, 29 Feb 2000 07:18:28 -0800 Nokia Silicon Valley Email
                  Exploit Scanner
Received: from  (charliep.iprg.nokia.com
          [205.226.2.89]) by darkstar.iprg.nokia.com  SMTP/WTS (12.69)
          xma012982; Tue, 29 Feb 00 07:18:23 -0800
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <7B5C0390ACE7D211BC9C0008C7EABA2B9296EB@daeis07nok>
            <20000229101005.A23614@mymlan.lifix.fi>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <38BBE33F.C5CEDF3D@iprg.nokia.com>
Date:         Tue, 29 Feb 2000 07:18:23 -0800
Reply-To: charliep@IPRG.NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: "Charles E. Perkins" 
Organization: Nokia Research Center
Subject:      Re: [MOBILE-IP] WG last call
              -draft-ietf-mobileip-rfc2002-bis-01.txt
X-To:         =?iso-8859-1?Q?Bj=F6rn?= Andersson 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

Hello Björn,

Thanks for your note.

> In section 3.7.1 there is a reference to a section that is not
> right:
>     - the IP Destination Address (as specified in 3.6.2.3)
>
> I believe this should be "as specified in 3.6.1.1".

This is correct.  Thanks!

> (It would also be nice with form feeds at the end of each page.)

The copy of the draft that I sent in does have the form feeds.
The copy of the draft that I retrieved from the IETF web page
does not have the form feeds.  How can I make sure that the
form feeds are preserved?

Regards,
Charlie P.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 11:44:53 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24590
	for ; Tue, 29 Feb 2000 11:44:52 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D0B15630@standards.nortelnetworks.com>; Tue, 29 Feb 2000 11:40:45 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 63445 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 11:38:51
          -0500
Received: from tiku.hut.fi by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.8CF9D390@standards.nortelnetworks.com>;
          Tue, 29 Feb 2000 11:38:51 -0500
Received: from akaatti.hut.fi (tweckstr@akaatti.hut.fi [130.233.249.61]) by
          tiku.hut.fi (8.9.3/8.9.3) with ESMTP id SAA10140; Tue, 29 Feb 2000
          18:41:49 +0200 (EET)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Message-ID:  
Date:         Tue, 29 Feb 2000 18:41:49 +0200
Reply-To: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= 
Subject:      Re: [MOBILE-IP] comparison of micro-mobility solutions
X-To:         Roberto Winkler 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  
Content-Transfer-Encoding: 8BIT

Hello Roberto,


Dynamics group from Helsinki University of Technology presented a paper
about enhanced fast handoffs with hierarchical Mobile IP in MoMuC'99,
November 1999.

The paper covers some references worth reading - and may be worth reading
itself as well. ;)

The references reflect the state of the research until July 1999 when the
paper was submitted.

You can get the paper e.g. from Dynamics - HUT Mobile IP web site at

http://www.cs.hut.fi/Research/Dynamics/

Regards,
         Tom


On Mon, 28 Feb 2000, Roberto Winkler wrote:

wnk >hello,
wnk >
wnk >a quick question: has anybody produced a paper comparing the solutions
wnk >proposed in the last two years for micro-mobility enhancement of Mobile IP ?
wnk >
wnk >Thanks very much for your help
wnk >
wnk >Roberto
wnk >
wnk >Roberto Winkler
wnk >Senior Researcher
wnk >Fondazione Ugo Bordoni
wnk >Via B. Castiglione, 59
wnk >00142 Rome Italy
wnk >
wnk >tel +39 0654803411
wnk >fax. +39 0654804404
wnk >e-mail wnk@fub.it
wnk >


--
        Tom Weckström           Dynamics group
                                Helsinki University of Technology
                                dynamics@cs.hut.fi
                                http://www.cs.hut.fi/Research/Dynamics/


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 14:40:05 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00510
	for ; Tue, 29 Feb 2000 14:40:04 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4BECF530@standards.nortelnetworks.com>; Tue, 29 Feb 2000 14:35:59 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 63592 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 14:34:17
          -0500
Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.A95A1C90@standards.nortelnetworks.com>;
          Tue, 29 Feb 2000 14:24:17 -0500
Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM
          (8.9.3+Sun/8.9.3) with ESMTP id MAA23940; Tue, 29 Feb 2000 12:27:41
          -0700 (MST)
Received: from atlantic.East.Sun.COM (atlantic.East.Sun.COM [129.148.174.27])
          by eastmail1.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP
          id OAA00476; Tue, 29 Feb 2000 14:27:39 -0500 (EST)
Received: from onion (onion [129.148.174.110]) by atlantic.East.Sun.COM
          (8.9.1b+Sun/8.9.1) with SMTP id OAA23311; Tue, 29 Feb 2000 14:28:11
          -0500 (EST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Message-ID:  
Date:         Tue, 29 Feb 2000 14:27:56 -0500
Reply-To: Steven Glass - Solaris Software 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Steven Glass - Solaris Software 
Subject:      Re: [MOBILE-IP] WG last call
              -draft-ietf-mobileip-rfc2002-bis-01.txt
X-To:         charliep@IPRG.NOKIA.COM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  "Your message with ID" <38BBE33F.C5CEDF3D@iprg.nokia.com>

> > (It would also be nice with form feeds at the end of each page.)
>
> The copy of the draft that I sent in does have the form feeds.
> The copy of the draft that I retrieved from the IETF web page
> does not have the form feeds.  How can I make sure that the
> form feeds are preserved?

 Charlie,

    Depends on how you get it.  Whenever I "Save As" from Netscape it seems to strip out the ^L's, but if I ftp it, they're in there.

                              Cheers,
                                  Steve


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 16:26:34 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02829
	for ; Tue, 29 Feb 2000 16:26:33 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2D505B80@standards.nortelnetworks.com>; Tue, 29 Feb 2000 16:22:30 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 63959 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 16:21:00
          -0500
Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.91794BF0@standards.nortelnetworks.com>; Tue, 29 Feb 2000 16:11:00
          -0500
Received: from sbol01.olg.com (sbolnet.com [206.161.118.65]) by
          hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id PAA27501 for
          ; Tue, 29 Feb 2000 15:14:27 -0600 (CST)
Received: from sbolnet.com (unverified [38.11.233.97]) by sbol01.olg.com
          (Rockliffe SMTPRA 3.4.5) with SMTP id 
          for ; Tue, 29 Feb 2000 16:16:28 -0500
Message-ID:  
Date:         Tue, 29 Feb 2000 16:12:12 EST
Reply-To: sell29@earthlink.net
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: ghh@AOL.COM
Subject:      [MOBILE-IP] It's so exciting, here's your tickets!
X-To:         mobile-ip@smallworks.com
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM







Click Here





OR go to   http://209.155.119.174/flyaway/getaway/


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 17:32:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04196
	for ; Tue, 29 Feb 2000 17:32:45 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.68FB8A20@standards.nortelnetworks.com>; Tue, 29 Feb 2000 17:28:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 64063 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 17:26:37
          -0500
Received: from ziggy.stardust.com (205.184.205.34) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.BC208D60@standards.nortelnetworks.com>; Tue, 29 Feb 2000
          17:16:37 -0500
Received: from WHITESTAR (dhcp204-106.stardust.com [205.184.204.106]) by
          ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA23445;
          Tue, 29 Feb 2000 14:18:25 -0800
X-Sender: martinb@stardust.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <3.0.5.32.20000229141821.009eaaf0@stardust.com>
Date:         Tue, 29 Feb 2000 14:18:21 -0800
Reply-To: Marty Bickford 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Marty Bickford 
Subject:      [MOBILE-IP] Call for Presentations: iBAND4 June 11-14
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Call for Papers - http://www.stardust.com/iband4/conference.htm
---------------

iBAND4 - Advancing the Technology of Internet Bandwidth
         Management and Traffic Engineering

         Technical Conference - June 11-13
         Workshops with DMTF  - June 14

iBAND4 is the fourth in a series of events focused on innovation in the
areas of bandwidth management and traffic engineering. iBAND5 will be
co-located and run together with ISPCON.

The goal of iBAND is to help IP network professionals at ISP's and
enterprise's understand the direction of work being done by standards
groups and vendors. These events have also become a meeting place for the
folks driving innovation in the areas of bandwidth management and traffic
engineering.

iBAND attendees include IP network engineers, network architects,
engineering and business executives, MIS and IT professionals, product and
development managers, researchers and other innovators.

You are invited to submit a presentation proposal. To aid you in submitting
a proposal, please visit http://www.stardust.com/iband4/conference.htm

If you do not wish to present, we hope you will mark your calendar to
attend this fun and innovative conference. Email or call me with any
questions.

Sincerely,
Marty

---
Marty Bickford  - 408.879.8080 (8081-fax)
Stardust.com - http://www.stardust.com


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 18:10:43 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04851
	for ; Tue, 29 Feb 2000 18:10:42 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BD5A1AA0@standards.nortelnetworks.com>; Tue, 29 Feb 2000 18:06:45 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 64175 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 18:05:09
          -0500
Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.8415C3C0@standards.nortelnetworks.com>; Tue, 29 Feb 2000 18:05:09
          -0500
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by
          mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id BAA24600 for
          ; Wed, 1 Mar 2000 01:08:37
          +0200 (EET)
Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com
          [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id
          BAA12422 for ; Wed, 1 Mar
          2000 01:08:36 +0200 (EET)
Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <1RM29MH4>;
          Tue, 29 Feb 2000 17:07:45 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Tue, 29 Feb 2000 17:08:34 -0600
Reply-To: weijun.jiang@NOKIA.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Weijun Jiang 
Subject:      Re: [MOBILE-IP] WG last call -draft-ietf-mobileip-rfc2002-bis-01.
              txt
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

If you have Winzip(a pc utility), you can zip the file and send
out. Whoever downloads the zip file can use Winzip to
unzip the file. The format will be preserved.

weijun

 Weijun Jiang
 Nokia Mobile Phones
 12278 Scripps Summit Dr.
 San Diego, CA 92131
 Phone: (858)831-5824
 FAX:   (858)831-6515
 E-mail: weijun.jiang@nokia.com



-----Original Message-----
From: EXT Steven Glass - Solaris Software
[mailto:Steven.Glass@East.Sun.COM]
Sent: Tuesday, February 29, 2000 11:28 AM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] WG last call
-draft-ietf-mobileip-rfc2002-bis-01.txt


> > (It would also be nice with form feeds at the end of each page.)
>
> The copy of the draft that I sent in does have the form feeds.
> The copy of the draft that I retrieved from the IETF web page
> does not have the form feeds.  How can I make sure that the
> form feeds are preserved?

 Charlie,

    Depends on how you get it.  Whenever I "Save As" from Netscape it seems
to strip out the ^L's, but if I ftp it, they're in there.

                              Cheers,
                                  Steve


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 18:25:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05006
	for ; Tue, 29 Feb 2000 18:25:44 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D9EB6B40@standards.nortelnetworks.com>; Tue, 29 Feb 2000 18:21:52 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 64227 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 18:20:23
          -0500
Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.3F587470@standards.nortelnetworks.com>; Tue, 29 Feb 2000 18:10:23
          -0500
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by
          motgate2.mot.com (motgate2 2.1) with ESMTP id QAA12406 for
          ; Tue, 29 Feb 2000 16:13:51
          -0700 (MST)]
Received: [from email1.wes.mot.com (email1.wes.mot.com [154.56.3.101]) by
          pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id QAA04934 for
          ; Tue, 29 Feb 2000 16:13:51
          -0700 (MST)]
Received: by email1.wes.mot.com with Internet Mail Service (5.5.2650.21) id
          ; Tue, 29 Feb 2000 17:13:39 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <51F347B016ADD011963200805FC1456204BCC05D@email1.wes.mot.com>
Date:         Tue, 29 Feb 2000 17:13:38 -0600
Reply-To: Roberts Phil-QA3445 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Roberts Phil-QA3445 
Subject:      [MOBILE-IP] charter update?
X-cc:         "raj.patil@nokia.com" 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Greetings gentlepeople,

    We've got 4 presentations lined up at the Adelaide meeting on various
proposals for handoff.  This together with the fact that several of our
current drafts are motivated by 3G data support indicates to Raj and me that
there continues to be some interest in the group in supporting cellular
specific extensions to mobile-ip.  The charter doesn't specify a strong
support of these activities.  The current wording is "The WG moving forward
will focus on deployment issues in Mobile IP and provide appropriate
protocol solutions to address known deficiencies and shortcomings. For
example, the wireless/cellular industry is considering using Mobile IP as
one technique for IP mobility for wireless data. The working group will
endeavor to gain an understanding of data service in cellular systems such
as GPRS, UMTS, CDMA2000, and interact with other standards bodies that are
trying to adopt and deploy Mobile IP WG protocols in these contexts."
So I'd like to find out whether there is interest in the group to extending
the charter for specific support of cellular systems.  If there is general
support I'll propose some wording.  One obvious work item would be to submit
a draft to the IESG for support of fast handover.

Comments?
Phil


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 18:43:22 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05180
	for ; Tue, 29 Feb 2000 18:43:22 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.18978200@standards.nortelnetworks.com>; Tue, 29 Feb 2000 18:37:56 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 64306 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 18:36:38
          -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.E9C3E5E0@standards.nortelnetworks.com>; Tue, 29 Feb 2000
          18:36:38 -0500
Received: from zmers013 by smtprch1.nortel.com; Tue, 29 Feb 2000 17:39:42 -0600
Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Tue, 29
          Feb 2000 18:39:24 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          ; Tue, 29 Feb 2000 17:39:25 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF830E.35E09B1A"
Message-ID:  
Date:         Tue, 29 Feb 2000 17:39:23 -0600
Reply-To: Emad Qaddoura 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Emad Qaddoura 
Subject:      Re: [MOBILE-IP] charter update?
X-To:         Roberts Phil-QA3445 
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_01BF830E.35E09B1A
Content-Type: text/plain;
        charset="ISO-8859-1"

Phil,

        So why is the current charter not sufficient for addressing the
interest by the cellular interest?

        I understand that the MIP WG is interested in getting MIP deployed
over cellular or other technologies. However, my personal view is: if we
mandate the Cellular support as a requirement in the charter, it may become
more of a "MIP for Cellular WG" than general MIP solution.

thx.
Emad.

> -----Original Message-----
> From: Roberts Phil-QA3445 [mailto:qa3445@EMAIL1.WES.MOT.COM]
> Sent: Tuesday, February 29, 2000 5:14 PM
> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject: [MOBILE-IP] charter update?
>
>
> Greetings gentlepeople,
>
>     We've got 4 presentations lined up at the Adelaide
> meeting on various
> proposals for handoff.  This together with the fact that
> several of our
> current drafts are motivated by 3G data support indicates to
> Raj and me that
> there continues to be some interest in the group in
> supporting cellular
> specific extensions to mobile-ip.  The charter doesn't
> specify a strong
> support of these activities.  The current wording is "The WG
> moving forward
> will focus on deployment issues in Mobile IP and provide appropriate
> protocol solutions to address known deficiencies and shortcomings. For
> example, the wireless/cellular industry is considering using
> Mobile IP as
> one technique for IP mobility for wireless data. The working
> group will
> endeavor to gain an understanding of data service in cellular
> systems such
> as GPRS, UMTS, CDMA2000, and interact with other standards
> bodies that are
> trying to adopt and deploy Mobile IP WG protocols in these contexts."
> So I'd like to find out whether there is interest in the
> group to extending
> the charter for specific support of cellular systems.  If
> there is general
> support I'll propose some wording.  One obvious work item
> would be to submit
> a draft to the IESG for support of fast handover.
>
> Comments?
> Phil
>

------_=_NextPart_001_01BF830E.35E09B1A
Content-Type: text/html;
        charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [MOBILE-IP] charter update?




Phil,




        So why is =
the current charter not sufficient for addressing the interest by the =
cellular interest?




        I =
understand that the MIP WG is interested in getting MIP deployed over =
cellular or other technologies. However, my personal view is: if we =
mandate the Cellular support as a requirement in the charter, it may =
become more of a "MIP for Cellular WG" than general MIP =
solution. 



thx.

Emad.




> -----Original Message-----

> From: Roberts Phil-QA3445 [mailto:qa3445@EMAIL1.WES.MOT.C=
OM]

> Sent: Tuesday, February 29, 2000 5:14 PM

> To: =
MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

> Subject: [MOBILE-IP] charter update?

> 

> 

> Greetings gentlepeople,

> 

>     We've got 4 =
presentations lined up at the Adelaide 

> meeting on various

> proposals for handoff.  This together with =
the fact that 

> several of our

> current drafts are motivated by 3G data support =
indicates to 

> Raj and me that

> there continues to be some interest in the =
group in 

> supporting cellular

> specific extensions to mobile-ip.  The =
charter doesn't 

> specify a strong

> support of these activities.  The current =
wording is "The WG 

> moving forward

> will focus on deployment issues in Mobile IP =
and provide appropriate

> protocol solutions to address known =
deficiencies and shortcomings. For

> example, the wireless/cellular industry is =
considering using 

> Mobile IP as

> one technique for IP mobility for wireless =
data. The working 

> group will

> endeavor to gain an understanding of data =
service in cellular 

> systems such

> as GPRS, UMTS, CDMA2000, and interact with =
other standards 

> bodies that are

> trying to adopt and deploy Mobile IP WG =
protocols in these contexts."

> So I'd like to find out whether there is =
interest in the 

> group to extending

> the charter for specific support of cellular =
systems.  If 

> there is general

> support I'll propose some wording.  One =
obvious work item 

> would be to submit

> a draft to the IESG for support of fast =
handover.

> 

> Comments?

> Phil

> 





------_=_NextPart_001_01BF830E.35E09B1A--


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 19:04:55 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05371
	for ; Tue, 29 Feb 2000 19:04:54 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.52EAD080@standards.nortelnetworks.com>; Tue, 29 Feb 2000 19:01:02 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 64375 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 19:00:34
          -0500
Received: from crufty.research.bell-labs.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.DBE6C940@standards.nortelnetworks.com>; Tue, 29 Feb 2000 18:50:33
          -0500
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Tue Feb 29
          18:53:34 EST 2000
Received: from valjean.dnrc.bell-labs.com (IDENT:root@valjean
          [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with
          ESMTP id SAA00947; Tue, 29 Feb 2000 18:53:34 -0500 (EST)
Received: (from salga@localhost) by valjean.dnrc.bell-labs.com (8.9.3/8.8.7) id
          SAA11588; Tue, 29 Feb 2000 18:53:33 -0500
Mail-Followup-To: Emad Qaddoura ,
                  MOBILE-IP@standards.nortelnetworks.com
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
X-Operating-System: Linux 2.2.12-20
X-Organization: Lucent Technologies, Bell Laboratories
Message-ID:  <20000229185333.G27822@bell-labs.com>
Date:         Tue, 29 Feb 2000 18:53:33 -0500
Reply-To: Luca Salgarelli 
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Luca Salgarelli 
Subject:      Re: [MOBILE-IP] charter update?
X-To:         Emad Qaddoura 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  ; from emadq@nortelnetworks.com on Tue,
              Feb 29, 2000 at 05:39:23PM -0600

Hi Emad.

>            So why is the current charter not sufficient for addressing
>    the interest by the cellular interest?

Personally, I think that one of the work items that are missing from the
charter (wrt cellular/wireless) is support for fast handover: this should
be a must for the use of MIP not only in cellular networks, but in any
wireless network where QoS counts.

Regards
Luca

>
>            I understand that the MIP WG is interested in getting MIP
>    deployed over cellular or other technologies. However, my personal
>    view is: if we mandate the Cellular support as a requirement in the
>    charter, it may become more of a "MIP for Cellular WG" than general
>    MIP solution.


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM  Tue Feb 29 20:38:12 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06330
	for ; Tue, 29 Feb 2000 20:38:11 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.55D6B9F0@standards.nortelnetworks.com>; Tue, 29 Feb 2000 20:34:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 64497 for
          MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 29 Feb 2000 20:32:33
          -0500
Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.1B423C60@standards.nortelnetworks.com>; Tue, 29 Feb 2000 20:32:33
          -0500
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Tue Feb 29
          20:34:28 EST 2000
Received: from dnrc.bell-labs.com (IDENT:21257@ramjeepc [135.180.240.106]) by
          bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id UAA03214; Tue,
          29 Feb 2000 20:34:26 -0500 (EST)
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38BC73AE.6E67FC1@dnrc.bell-labs.com>
Date:         Wed, 1 Mar 2000 01:34:38 +0000
Reply-To: ramjee@DNRC.BELL-LABS.COM
Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)"
              
From: Ramachandran Ramjee 
Subject:      Re: [MOBILE-IP] comparison of micro-mobility solutions
X-To:         Roberto Winkler 
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,

While I haven't seen any paper that compares the different
micro-mobility
enhancements in a comprehensive manner, our ICNP paper on HAWAII has a
very brief discussion of HFA and Cellular IP in the related works
section.
You can get the paper from:

http://www.bell-labs.com/user/ramjee/papers/icnp99.ps.gz

Regards,
Ram

Roberto Winkler wrote:
>
> hello,
>
> a quick question: has anybody produced a paper comparing the solutions
> proposed in the last two years for micro-mobility enhancement of Mobile IP ?
>
> Thanks very much for your help
>
> Roberto
>
> Roberto Winkler
> Senior Researcher
> Fondazione Ugo Bordoni
> Via B. Castiglione, 59
> 00142 Rome Italy
>
> tel +39 0654803411
> fax. +39 0654804404
> e-mail wnk@fub.it



internet spy





INTERNET
SPY ORDER FORM!!




////////////////////////////////////////
This is a one time mailing! No need to be removed.
////////////////////////////////////////

CONFIDENTIAL INFORMATION YOU WANT TO KNOW.

This is the software they want banned from the INTERNET!

"The Internet Desktop Spy" shows you how to get the facts on anyone using the

Internet.

LOCATE MISSING PERSONS, find lost relatives, obtain addresses and phone
numbers of old school friends, even skip trace dead beat spouses.  This is
not a Private Investigator, but a SOFTWARE program DESIGNED to automatically
CRACK YOUR CASE with links to thousands of Public Record Databases

Find out SECRETS about your relatives, friends, enemies, and everyone else!
-- even your spouse! With the New - "Internet Desktop SPY"

You will be AMAZED at what you can discover:

LICENSE PLATE NUMBER - Get anyone's name and address with just a license
plate number! (Find that girl you met in traffic!)

DRIVING RECORD - Get anyone's driving record!

SOCIAL SECURITY NUMBER - Trace anyone by social security number!

ADDRESS - Get anyone's address with just a name!

UNLISTED PHONE NUMBERS - Get anyone's phone number with just a name- even
unlisted numbers!

LOCATE - Long lost friends, relatives, a past lover who broke your heart!

E-MAIL - Send anyone anonymous e-mail that's completely untraceable!

DIRTY SECRETS - Discover dirty secrets your in-laws don't want you to know!

INVESTIGATE ANYONE - Use the sources that private investigators use (all on
the Internet) secretly!

EX-SPOUSE - Learn how to get information on an ex-spouse that will help you
win in court! (Dig up old skeletons)

CRIMINAL SEARCH - BACKGROUND CHECK - Find out about your daughter's
boyfriend! (or her husband)

FIND OUT - If you are being investigated!

NEIGHBORS - Learn all about your mysterious neighbors!  Find out what they
have to hide!

PEOPLE YOU WORK WITH - Be astonished by what you'll learn about the people
you work with!

EDUCATION VERIFICATION - Did he really graduate college?  Find out!

"The Internet Desktop Spy" will help you discover ANYTHING about anyone, with

clickable hyperlinks and no typing in Internet addresses!  Just download the
software and go!  You will be shocked and amazed by the secrets that can
be discovered about absolutely everyone!  Find out the secrets they don't
want you to know!  About others, about yourself!

LIMITED TIME OFFER -- ORDER TODAY!  ONLY $20 (US)

You can dowmload the  "The Internet DeskTop Spy" software NOW so you can
begin
discovering all the secrets you ever wanted to know!  You can know EVERYTHING

about ANYONE with "The Internet DeskTop Spy" software.

- Works with all browsers and all versions of AOL
- PC Versions available Only!

DON'T WAIT TO GET STARTED… It's as easy as 1, 2, 3.
ORDER TODAY - While this software is still legal!

VISA/MC ONLY

For Credit Card Orders, Click on the link below:

Click
Here To Order!

NOTES:
- This program will not work on Windows 3.11 and older
- DISCLAIMER - The seller of this powerful software resource will not be held

responsible for how the purchaser chooses to use its resources.