From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 3 00:49: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 AAA15617 for ; Mon, 3 Jan 2000 00:49:26 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D05D0610@standards.nortelnetworks.com>; Mon, 3 Jan 2000 0:38:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102081 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jan 2000 00:37:23 -0500 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4DC56EF0@standards.nortelnetworks.com>; Mon, 3 Jan 2000 0:27:23 -0500 Received: from sabre.uol.com.mx ([200.34.157.210]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id XAA11550 for ; Sun, 2 Jan 2000 23:37:34 -0600 (CST) Received: from pike.uol.com.mx (200.34.157.14) by sabre.uol.com.mx (NPlex 4.5.042) id 38693D7B0002C5D3; Sun, 2 Jan 2000 21:22:04 -0600 Received: from 200.34.157.14 (254-pool6.ras12.casnc.agisdial.net [206.84.13.254]) by pike.uol.com.mx (8.8.8+Sun/8.8.8) with SMTP id VAA02070; Sun, 2 Jan 2000 21:20:24 -0600 (CST) Message-ID: <200001030320.VAA02070@pike.uol.com.mx> Date: Thu, 18 Nov 1999 19:20:59 EST 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: Friend@public.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM //////////////////////////////////////// One time mailing, no need for removal. //////////////////////////////////////// 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: http://204.4.8.12/internetspy 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. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 3 12:12: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 MAA04416 for ; Mon, 3 Jan 2000 12:12:33 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.460425B0@standards.nortelnetworks.com>; Mon, 3 Jan 2000 12:01:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102546 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jan 2000 11:59:52 -0500 Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0AEC6E60@standards.nortelnetworks.com>; Mon, 3 Jan 2000 11:59:52 -0500 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Mon Jan 3 12:08:46 EST 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Mon Jan 3 12:08:46 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 9CA645701C; Mon, 3 Jan 2000 11:08:45 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <199912240108.RAA07599@omega.cisco.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000103170845.9CA645701C@king.research.bell-labs.com> Date: Mon, 3 Jan 2000 11:08:45 -0600 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: [MOBILE-IP] Multiple IP addresses per NAI X-To: Gopal Dommety To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <199912240108.RAA07599@omega.cisco.com> Content-Transfer-Encoding: 7bit Hi, Gopal, Maybe the Identification field can play this role, so we don't need to do any new protocol specification. Things could work this way: a Registration Request that already has an IP home address does not get allocated a new one. Any Registration Request that is missing a home address and has a unique Identification field does get allocated a new address. Retransmissions of the same Request with the same Identification get the same address. There could be some limit placed by the home agent on the number of IP addresses that can be acquired by any given NAI; we may need to define a new rejection code (number of IP addresses exceeded) if they are all used up. Maybe there are some pathological conditions involving lost Replies that would cause addresses to be used up unnecessarily - for instance, if a Reply is lost, the MN might retransmit a request with a new Identification value and accidentally get a second address without ever knowing about the first. But the old address would time out after the Lifetime expired anyway, so maybe it's not such a problem. Thoughts? -Pete Gopal Dommety (GD) writes: GD> Hello: GD> There has been some discussion (several operators are also GD> requesting for this) to be able to allocate multiple IP addresses GD> based on one NAI (For example, connect a laptop, PDA, and cell GD> phone with the same NAI simultaneously). One way of acheive this GD> request is to have a field in the NAI extension to distinguish GD> these requests. Authentication can be performend based on NAI and GD> address allocation and session management functions can use this GD> new field. GD> Any thoughts??? let me know if you need further explaination of GD> the problem. GD> Thanks GD> Gopal From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 3 12:43: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 MAA04791 for ; Mon, 3 Jan 2000 12:43:33 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9CC46960@standards.nortelnetworks.com>; Mon, 3 Jan 2000 12:32:35 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102587 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jan 2000 12:30:38 -0500 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F11D0AA0@standards.nortelnetworks.com>; Mon, 3 Jan 2000 12:20:37 -0500 Received: from ani.univie.ac.at (heraklit.ani.univie.ac.at [131.130.32.104]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id LAA15088 for ; Mon, 3 Jan 2000 11:30:37 -0600 (CST) Received: from www.archimedes.ani.univie.ac.at (archimedes [131.130.32.138]) by ani.univie.ac.at (8.9.3/8.8.8) with ESMTP id SAA08102 for ; Mon, 3 Jan 2000 18:25:55 +0100 (MET) Received: (from gabi@localhost) by www.archimedes.ani.univie.ac.at (8.8.8+Sun/8.8.8) id SAA03672 for mobile-ip@SMALLWORKS.COM; Mon, 3 Jan 2000 18:30:25 +0100 (MET) Message-ID: <200001031730.SAA03672@www.archimedes.ani.univie.ac.at> Date: Mon, 3 Jan 2000 18:30:25 +0100 Reply-To: Gabriele Kotsis Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gabriele Kotsis Subject: [MOBILE-IP] CFP DAPSYS2K X-To: mobile-ip@smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM CALL FOR PAPERS DAPSYS'2000 (AUSTRIAN-HUNGARIAN WORKSHOP ON DISTRIBUTED AND PARALLEL SYSTEMS) Balatonfured, Lake Balaton, Hungary September 10th-13th, 2000 The 3rd Austrian-Hungarian Workshop on Distributed and Parallel Systems (DAPSYS'2000) will be organized jointly with the 7th EuroPVM/MPI conference at the Lake Balaton in Hungary. Participants of the two events will share invited talks, tutorials and social events while contributed paper presentations will go on in separate tracks in parallel. Meanwhile EuroPVM/MPI is dedicated to the latest developments of PVM and MPI, DAPSYS is expected to be a major event to discuss general aspects of distributed and parallel systems. In this way the two events are complement to each other and participants of the DAPSYS'2000 workshop can benefit from the joint organization of the two events. Selected papers of DAPSYS'96 (held in Miskolc) have been published in a special issue (Vol. 22, No. 3. 1997 February) of Parallel Computing. Best papers of DAPSYS'98 (Budapest) are also published in Future Generation Computer Systems (to appear in 2000). The proceedings of DAPSYS'2000 will be published by Kluwer and selected papers will be included in a special issue of New Generation Computing. SCOPE: DAPSYS'2000 is expected to be a major event for vendors, researchers and teachers to consider present and future topics in distributed and parallel systems. Papers presenting original research, educational methods, new concepts, and results of international projects are being sought. Papers describing clusters, cluster programming, metacomputing and related fields are especially welcome. Typical, but not exclusive, topics include: Operating systems Web Computing Languages Metacomputing Algorithms Java/CORBA Systems Database Systems Cluster Programming Architectures Data Mining I/O Systems Middlewares SUBMISSION OF PAPERS: Contributors are invited to submit a full paper not exceeding 10 double-spaced pages in English. The title page should contain a 100-word abstract and five specific keywords. DAPSYS2000 accepts submissions only in electronic format sent by February 15, 2000, via the following WWW-Interface (thanks to David Nicol for providing WIMPE): http://scylla.ani.univie.ac.at/~gabi/dapsys2k. In case of any problems with this submission procedure, please contact the program chair Dr. Gabriele Kotsis Univ. of Vienna Email: gabi@poseidon.ani.univie.ac.at Interested experts in one or many of the DAPSYS focal points are invited to register as a reviewer http://scylla.ani.univie.ac.at/~gabi/dapsys2k. DEADLINES: Submission of complete papers February 15 Notification of authors March 31 Camera ready papers April 30 WORKSHOP CHAIR: Peter Kacsuk (MTA SZTAKI, Hungary) VICE CHAIR: Zsolt Nemeth (MTA SZTAKI, Hungary) PROGRAM CHAIR: Gabriele Kotsis (Univ. of Vienna, Austria) PROGRAM COMMITTEE: M. Amamiya (Kyushu Univ., Japan) L. Boeszoermenyi (Univ. Klagenfurt, Austria) L. Brunie (INSA-Lyon, France) Y. Cotronis (Univ. of Athens, Greece) J. Cunha (Univ. Nova de Lisboa, Portugal) W. Gentzsch (Genias, Germany) A. Goscinski (Daekin Univ., Australia) G. Gupta (New Mexico State Univ., USA) Z. Juhasz (Univ. of Veszprem, Hungary)
P. Kacsuk (MTA SZTAKI, Hungary) K. Kondorosi (Technical Univ. of Budapest, Hungary) H. Kosch (Univ. Klagenfurt, Austria) D. Laforenza (CNUCE-CNR, Italy) E. Luque (Univ. Autonoma de Barcelona, Spain) W. Schreiner (RISC Linz, Austria) V. Sunderam (Emory Univ., USA) G. Terstyanszky (Univ. of Miskolc, Hungary)
F. Vajda (MTA SZTAKI, Hungary) S. Winter (Westminster Univ., UK) R. Wismueller (Technical Univ. of Munich, Germany) CONFERENCE ADDRESS: Mrs. Judit Ajpek Conference Tours H-1055 Budapest, Kossuth L. ter 6-8. Hungary Fax: +36 1 353 00 25 Tel: +36 1 353 00 25 e-mail: rheni@mtesz.hu You can get more information on the following web page: http://www.lpds.sztaki.hu/DAPSYS2000/ --------------91497E700139FA9B171C8EE7-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 3 13:04:32 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 NAA05100 for ; Mon, 3 Jan 2000 13:04:31 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8F6B0640@standards.nortelnetworks.com>; Mon, 3 Jan 2000 12:53:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102648 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jan 2000 12:52:08 -0500 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F26784A0@standards.nortelnetworks.com>; Mon, 3 Jan 2000 12:42:08 -0500 Received: from ani.univie.ac.at (heraklit.ani.univie.ac.at [131.130.32.104]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id LAA15208 for ; Mon, 3 Jan 2000 11:52:20 -0600 (CST) Received: from www.archimedes.ani.univie.ac.at (archimedes [131.130.32.138]) by ani.univie.ac.at (8.9.3/8.8.8) with ESMTP id SAA09240 for ; Mon, 3 Jan 2000 18:47:44 +0100 (MET) Received: (from wetice2k@localhost) by www.archimedes.ani.univie.ac.at (8.8.8+Sun/8.8.8) id SAA03977 for mobile-ip@SMALLWORKS.COM; Mon, 3 Jan 2000 18:52:14 +0100 (MET) Message-ID: <200001031752.SAA03977@www.archimedes.ani.univie.ac.at> Date: Mon, 3 Jan 2000 18:52:14 +0100 Reply-To: Gabriele Kotsis Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gabriele Kotsis Subject: [MOBILE-IP] CFP WETICE2K X-To: mobile-ip@smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM WET ICE 2000 IEEE Eighth International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises June 14-16, 2000, National Institute of Standards and Technology Gaithersburg, Maryland, USA Sponsors: IEEE Computer Society and CERC at West Virginia University Host: Center for Design Research, Stanford University WORKSHOP: Web-based Infrastructures and Coordination Architectures for Collaborative Enterprises http://www.dsi.unimo.it/wetice2000/ CALL FOR PAPERS This workshop continues two threads of workshops in the WETICE series that were held over the last four years. In general these workshops addressed the question of how Web techniques can be used to achieve or to improve collaboration within or between organizations, and which coordination mechanisms could be used in such an architecture. A list of topics of interest includes (but is not limited to): Collaborative Applications virtual organisations show case scenarios reports on hands-on experiences Infrastructure and Technology coordination models and languages for the Web workflow languages languages and architectures for Web interoperability use of recent Internet and Web standards agent based approaches support for mobile users and software Development of Collaborative Applications engineering methodologies for collaborative Web applications collaboration versus competition development methodologies, tools and platforms coordination patterns Workshop Organization Each paper will be reviewed by at least three reviewers. The workshop will consist of 3 sessions presenting and discussing papers and a final working session preparing the workshop report. 40% of the workshop's time will be dedicated to discussion. Each paper presentation should provide answers and/or considerations related to a list of main questions/topics that each presenter will receive prior to the workshop. Submission Details Papers should contain original contributions not published or submitted elsewhere, and references to related state-of-the-art work. Authors of accepted papers are expected to present their views of the field at the oral presentation. Papers up to six pages (including figures, tables and references) can be submitted. Papers should follow the IEEE format , which is single spaced, two columns, 10 pt Times/Roman font. Papers should include a title, the name and affiliation of each author, an abstract of up to 150 words and no more than eight keywords. Authors are also required to provide contact addresses, if different from the submitting electronic address. Please, submit your paper in electronic format (PostScript or PDF) via the following WWW-Interface (thanks to David Nicol for providing WIMPE): http://scylla.ani.univie.ac.at/~wetice2k/forms/authpaper_reg.html Additionally, authors may send the URL of their paper and/or of their home page to be included into the WWW page of the workshop. As an exception, papers may also be submitted as hardcopies. In that case submit 5 copies of your paper to one of the organisers. Interested experts in one or many of the workshop's focal points are invited to register as a referee via http://scylla.ani.univie.ac.at/~wetice2k/forms/referee_reg.html Full papers accepted for the workshop will be included in the post-proceedings. The best paper of the workshop will be nominated for the WETICE best-paper award. Paper submissions are not required for participation in the workshop. If you plan to participate and want to receive a copy of the question/topics-list prior to the workshop, please contact the organizers. If you have further questions or remarks, don't hesitate to contact the workshop organizers. Workshop Organizers KIRSTIE L. BELLMAN Aerospace Integration Science Center The Aerospace Corporation, Mail Stop M6/214 P.O.Box 92957 Los Angeles, California 90009-2957, USA Phone: +1 (310) 336-2191 bellman@aero.org GABRIELE KOTSIS Institut fuer Angewandte Informatik Universitaet Wien Lenaugasse 2/8 A-1080 Wien Phone: +43 1 4277 38463, Fax: +43 1 4277 38451 gabi@ani.univie.ac.at http://www.ani.univie.at/~gabi CHRISTOPHER LANDAUER Aerospace Integration Science Center The Aerospace Corporation, Mail Stop M6/214 P.O.Box 92957 Los Angeles, California 90009-2957, USA Phone: +1 (310) 336-1361 cal@aero.org GUSTAF NEUMANN Information Systems and Software Techniques University of Essen Universtaetsstrasse 9 D-45141 Essen Germany Phone: +49 201 183-4074, Fax: +49 201 183-4073 neumann@wi-inf.uni-essen.de http://nestroy.wi-inf.uni-essen.de/ ROBERT TOLKSDORF Technische Universität Berlin FB 13, Informatik, KIT/FLP FR 6-10 Franklinstr. 28/29 D-10587 Berlin Germany tolk@cs.tu-berlin.de http://www.cs.tu-berlin.de/~tolk FRANCO ZAMBONELLI Dipartimento di Scienze dell'Ingegneria Universita' di Modena e Reggio Emilia Via Campi 213-b 41100 Modena ITALY Phone: +39-059-376735 franco.zambonelli@unimo.it http://www.dsi.unimo.it/Staff/st35/Zambonelli.idc Important Dates Full papers due to workshop organizers March 10, 2000 Notification of decisions to paper authors April 14, 2000 Advance Registration May 26, 2000 Workshop June 14-16, 2000 Final papers due for proceedings July 1, 2000 Papers are submitted directly to the Workshop organizers. Please use the following URL for submission to this workshop: http://scylla.ani.univie.ac.at/~wetice2k/forms/authpaper_reg.html. General WETICE Information: see http://www.ida.liu.se/conferences/WETICE/WETICE2000/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 3 13:29: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 NAA05556 for ; Mon, 3 Jan 2000 13:29:27 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.09EE1030@standards.nortelnetworks.com>; Mon, 3 Jan 2000 13:18:35 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102712 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jan 2000 13:16:37 -0500 Received: from sigma.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C3A22710@standards.nortelnetworks.com>; Mon, 3 Jan 2000 13:16:37 -0500 Received: (from kleung@localhost) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA16016; Mon, 3 Jan 2000 10:26:42 -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: <200001031826.KAA16016@sigma.cisco.com> Date: Mon, 3 Jan 2000 10:26:42 -0800 Reply-To: "Kent K. Leung" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Kent K. Leung" Subject: Re: [MOBILE-IP] Multiple IP addresses per NAI X-To: mccap@RESEARCH.BELL-LABS.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <20000103170845.9CA645701C@king.research.bell-labs.com> from "Pete McCann" at Jan 03, 2000 11:08:45 AM Content-Transfer-Encoding: 7bit > Maybe the Identification field can play this role, so we don't need to > do any new protocol specification. Things could work this way: a > Registration Request that already has an IP home address does not get > allocated a new one. Any Registration Request that is missing a home > address and has a unique Identification field does get allocated a new > address. Retransmissions of the same Request with the same Identification > get the same address. > But this doesn't work for re-registration by the same MN. How can a HA differentiate between an MN that's doing re-registration vs. MN registering another device? > Maybe there are some pathological conditions involving lost Replies > that would cause addresses to be used up unnecessarily - for instance, > if a Reply is lost, the MN might retransmit a request with a new > Identification value and accidentally get a second address without > ever knowing about the first. But the old address would time out > after the Lifetime expired anyway, so maybe it's not such a problem. > This scenario also exhaust addresses unnecessarily. The expiration of the leased address depends on the registration lifetime, which may be long. IMHO, I don't think using the Identification field is sufficient. -- Kent -- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 3 14:30: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 OAA06374 for ; Mon, 3 Jan 2000 14:30:25 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8AD9A0D0@standards.nortelnetworks.com>; Mon, 3 Jan 2000 14:19:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102809 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jan 2000 14:17:49 -0500 Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.501ED690@standards.nortelnetworks.com>; Mon, 3 Jan 2000 14:17:48 -0500 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Mon Jan 3 14:26:20 EST 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Mon Jan 3 14:26: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 9533F5701C; Mon, 3 Jan 2000 13:26:18 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20000103170845.9CA645701C@king.research.bell-labs.com> <200001031826.KAA16016@sigma.cisco.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000103192618.9533F5701C@king.research.bell-labs.com> Date: Mon, 3 Jan 2000 13:26:18 -0600 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] Multiple IP addresses per NAI X-To: "Kent K. Leung" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200001031826.KAA16016@sigma.cisco.com> Content-Transfer-Encoding: 7bit Hi, Kent, "Kent K. Leung" (KKL) writes: >> Maybe the Identification field can play this role, so we don't need to >> do any new protocol specification. Things could work this way: a >> Registration Request that already has an IP home address does not get >> allocated a new one. Any Registration Request that is missing a home >> address and has a unique Identification field does get allocated a new >> address. Retransmissions of the same Request with the same Identification >> get the same address. KKL> But this doesn't work for re-registration by the same MN. How can KKL> a HA differentiate between an MN that's doing re-registration vs. KKL> MN registering another device? Re-registrations will presumably have valid Home Address fields in the registration request. New registrations will have 0.0.0.0. >> Maybe there are some pathological conditions involving lost Replies >> that would cause addresses to be used up unnecessarily - for instance, >> if a Reply is lost, the MN might retransmit a request with a new >> Identification value and accidentally get a second address without >> ever knowing about the first. But the old address would time out >> after the Lifetime expired anyway, so maybe it's not such a problem. KKL> This scenario also exhaust addresses unnecessarily. The expiration KKL> of the leased address depends on the registration lifetime, which KKL> may be long. You may be right. KKL> IMHO, I don't think using the Identification field is sufficient. Maybe so, but I don't think we should necessarily augment the NAI extension itself - that would slow down too many other efforts. Maybe a new Session ID extension should be created. -Pete From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 3 15:22:32 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 PAA06964 for ; Mon, 3 Jan 2000 15:22:31 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D7213320@standards.nortelnetworks.com>; Mon, 3 Jan 2000 15:11:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102917 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jan 2000 15:10: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.B10EA5F0@standards.nortelnetworks.com>; Mon, 3 Jan 2000 15:10:38 -0500 Received: from zmers013 by smtprch1.nortel.com; Mon, 3 Jan 2000 14:20:35 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Mon, 3 Jan 2000 15:20:27 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 3 Jan 2000 14:20:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5627.F3ECC73C" Message-ID: <9A9367D1556AD21182C40000F80930AB010BC176@crchy28b.us.nortel.com> Date: Mon, 3 Jan 2000 14:20:17 -0600 Reply-To: Mohamed Khalil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohamed Khalil Subject: Re: [MOBILE-IP] Multiple IP addresses per NAI X-To: Pete McCann 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_01BF5627.F3ECC73C Content-Type: text/plain Hi Pete, I think the correct and clean way to allow any user to have multiple devices is to have each device owned by a user to send a new extension during the registration phase called a Device Extension. This extension may be attached to both registration request and reply. The home agent will use the device id to allocate a mobile device an IP address when it is necessary. 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 | sub-type | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | device parameters ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | device id ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Generic Device extension type (TBD) length The length of the NAI-INFO field. Sub-Type 1 ETHERNET_DEV. 2 TDMA_DEV. 3 CDMA_DEV. device parameters this section defines the device parameters which is requested by the mobile node. this section MAY be modified by the home agent or foreign agent to match the current operating capability of the network and the services which is allowed for the user. The structure of this section depends on the type of the device. device id It is the device identification. example MCI-LAPTOP-193.193.193.20 > -----Original Message----- > From: Pete McCann [SMTP:mccap@RESEARCH.BELL-LABS.COM] > Sent: Monday, January 03, 2000 1:26 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Multiple IP addresses per NAI > > Hi, Kent, > > "Kent K. Leung" (KKL) writes: > > >> Maybe the Identification field can play this role, so we don't need to > >> do any new protocol specification. Things could work this way: a > >> Registration Request that already has an IP home address does not get > >> allocated a new one. Any Registration Request that is missing a home > >> address and has a unique Identification field does get allocated a new > >> address. Retransmissions of the same Request with the same > Identification > >> get the same address. > > KKL> But this doesn't work for re-registration by the same MN. How can > KKL> a HA differentiate between an MN that's doing re-registration vs. > KKL> MN registering another device? > > Re-registrations will presumably have valid Home Address fields in the > registration request. New registrations will have 0.0.0.0. > > >> Maybe there are some pathological conditions involving lost Replies > >> that would cause addresses to be used up unnecessarily - for instance, > >> if a Reply is lost, the MN might retransmit a request with a new > >> Identification value and accidentally get a second address without > >> ever knowing about the first. But the old address would time out > >> after the Lifetime expired anyway, so maybe it's not such a problem. > > KKL> This scenario also exhaust addresses unnecessarily. The expiration > KKL> of the leased address depends on the registration lifetime, which > KKL> may be long. > > You may be right. > > KKL> IMHO, I don't think using the Identification field is sufficient. > > Maybe so, but I don't think we should necessarily augment the NAI > extension itself - that would slow down too many other efforts. Maybe > a new Session ID extension should be created. > > -Pete ------_=_NextPart_001_01BF5627.F3ECC73C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] Multiple IP addresses per NAI

Hi Pete,

I think the correct = and clean way to allow any user to have multiple devices is to have = each device owned by a user to send a new extension during the = registration phase called a  Device Extension. This extension may = be attached to both registration request and reply. The home agent will = use the device id to allocate a mobile device an IP address when it is = necessary.

 0        &n= bsp;          = 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            = |      = sub-type          = |      = length           =             =     |
    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
    = |            = ;            = ;    device parameters = .....           =      
    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
    = |            = ;            = ;    device id = .....           =      
    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =


    = Type            = Generic Device extension type (TBD)
   =
    = length         The length of = the NAI-INFO field.

    = Sub-Type       1   = ETHERNET_DEV.
         &nb= sp;           &nb= sp;   2   TDMA_DEV.
         &nb= sp;           &nb= sp;   3   CDMA_DEV.

    = device parameters  this section defines the device = parameters
         &nb= sp;           &nb= sp; which is requested by the mobile node. this
         &nb= sp;           &nb= sp; section MAY be modified by the home agent
         &nb= sp;           &nb= sp; or foreign agent to match the current operating
         &nb= sp;           &nb= sp; capability of the network and the services
         &nb= sp;           &nb= sp; which is allowed for the user. The structure
         &nb= sp;           &nb= sp; of this section depends on the type of the device.

   device = id  It is the device identification.

         &nb= sp;    example MCI-LAPTOP-193.193.193.20


    -----Original Message-----
    From:   Pete McCann = [SMTP:mccap@RESEARCH.BELL-LABS.COM]
    Sent:   Monday, January 03, 2000 1:26 PM
    To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: [MOBILE-IP] Multiple IP = addresses per NAI

    Hi, Kent,

    "Kent K. Leung" = <kleung@cisco.com> (KKL) writes:

    >> Maybe the Identification = field can play this role, so we don't need to
    >> do any new protocol = specification.  Things could work this way: a
    >> Registration Request that = already has an IP home address does not get
    >> allocated a new one.  = Any Registration Request that is missing a home
    >> address and has a unique = Identification field does get allocated a new
    >> address.  = Retransmissions of the same Request with the same Identification
    >> get the same address.

    KKL> But this doesn't work for = re-registration by the same MN.  How can
    KKL> a HA differentiate between an = MN that's doing re-registration vs.
    KKL> MN registering another = device?

    Re-registrations will presumably have = valid Home Address fields in the
    registration request.  New = registrations will have 0.0.0.0.

    >> Maybe there are some = pathological conditions involving lost Replies
    >> that would cause addresses = to be used up unnecessarily - for instance,
    >> if a Reply is lost, the MN = might retransmit a request with a new
    >> Identification value and = accidentally get a second address without
    >> ever knowing about the = first.  But the old address would time out
    >> after the Lifetime expired = anyway, so maybe it's not such a problem.

    KKL> This scenario also exhaust = addresses unnecessarily.  The expiration
    KKL> of the leased address depends = on the registration lifetime, which
    KKL> may be long.

    You may be right.

    KKL> IMHO, I don't think using the = Identification field is sufficient.

    Maybe so, but I don't think we should = necessarily augment the NAI
    extension itself - that would slow = down too many other efforts.  Maybe
    a new Session ID extension should be = created.

    -Pete

------_=_NextPart_001_01BF5627.F3ECC73C-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 3 15:52: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 PAA07544 for ; Mon, 3 Jan 2000 15:52:47 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0BFB0720@standards.nortelnetworks.com>; Mon, 3 Jan 2000 15:41:48 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102998 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jan 2000 15:40:12 -0500 Received: from sigma.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D278BCE0@standards.nortelnetworks.com>; Mon, 3 Jan 2000 15:40:12 -0500 Received: (from kleung@localhost) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA08191; Mon, 3 Jan 2000 12:50:00 -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: <200001032050.MAA08191@sigma.cisco.com> Date: Mon, 3 Jan 2000 12:50:00 -0800 Reply-To: "Kent K. Leung" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Kent K. Leung" Subject: Re: [MOBILE-IP] Multiple IP addresses per NAI X-To: mkhalil@NORTELNETWORKS.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <9A9367D1556AD21182C40000F80930AB010BC176@crchy28b.us.nortel.com> from "Mohamed Khalil" at Jan 03, 2000 02:20:17 PM Content-Transfer-Encoding: 7bit > I think the correct and clean way to allow any user to have multiple devices > is to have each device owned by a user to send a new extension during the > registration phase called a Device Extension. This extension may be I agree with this approach. > > Re-registrations will presumably have valid Home Address fields in the > > registration request. New registrations will have 0.0.0.0. > > I think part of the problem is that address allocation has not been sufficiently covered by any drafts. The NAI draft does not explain the meaning when NAI extension exist and home address is non-zero. Does this always happen for re-registrations? Re-registrations may have zero home address field. My interpretation is that the HA could use this ip address as a hint for address allocation even for new registrations (similar to dial environment). But if address is used, then HA will return a new ip address. But some maybe the MN really wanted that address for some reason. In that case, MN should deregister that address after being accepted. Anyways, it's ambiguous on how HA deal with registrations with NAI ext and non-zero Home Address. > > Maybe so, but I don't think we should necessarily augment the NAI > > extension itself - that would slow down too many other efforts. Maybe > > a new Session ID extension should be created. > > I don't have problem with that. Not all cases require further NAI subidentification. -- Kent -- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 09:49: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 JAA29113 for ; Tue, 4 Jan 2000 09:49:24 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6DA232A0@standards.nortelnetworks.com>; Tue, 4 Jan 2000 9:38:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 103643 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 09:36:17 -0500 Received: from hawk.ee.nus.edu.sg by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C086D180@standards.nortelnetworks.com>; Tue, 4 Jan 2000 9:26:16 -0500 Received: from localhost (ccfoo@localhost) by hawk.ee.nus.edu.sg (8.9.3+Sun/8.9.1) with ESMTP id WAA04245; Tue, 4 Jan 2000 22:36:45 +0800 (SGT) X-Sender: ccfoo@hawk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Tue, 4 Jan 2000 22:36:44 +0800 Reply-To: ccfoo@HAWK.EE.NUS.EDU.SG Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: ccfoo@HAWK.EE.NUS.EDU.SG Subject: [MOBILE-IP] Software Using Wavelan Signal Strength Measurement to Improve MIP Handoff is available To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Greetings, The NUS Mobile IP project is pleased to announce the availability of code using Wavelan signal strength measurement to improve the handoff performance of MIP. We would like to thank and acknowledge David Pavon and Mohammed Shabeer of BT Labs Ipswich, UK for completely developing and kindly contributing this code for inclusion into the NUS Mobile IP project. Thank you BT Labs UK! The code and documentation can be downloaded from http://mip.ee.nus.edu.sg/v3.0beta/btlabs/ Have a belated Merry Xmas and a Happy New Millenium, Foo Chun Choong, The NUS Mobile IP Project, http://mip.ee.nus.edu.sg National University of Singapore From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 09:54: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 JAA29243 for ; Tue, 4 Jan 2000 09:54:19 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FDF5D460@standards.nortelnetworks.com>; Tue, 4 Jan 2000 9:42:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 103644 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 09:41:15 -0500 Received: from hawk.ee.nus.edu.sg by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7212EFB0@standards.nortelnetworks.com>; Tue, 4 Jan 2000 9:31:14 -0500 Received: from localhost (ccfoo@localhost) by hawk.ee.nus.edu.sg (8.9.3+Sun/8.9.1) with ESMTP id WAA04250; Tue, 4 Jan 2000 22:41:44 +0800 (SGT) X-Sender: ccfoo@hawk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Tue, 4 Jan 2000 22:41:44 +0800 Reply-To: ccfoo@HAWK.EE.NUS.EDU.SG Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: ccfoo@HAWK.EE.NUS.EDU.SG Subject: [MOBILE-IP] Greetings from the world of NUS Mobile IP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Greetings from the world of NUS Mobile IP! At the dawn of this new millenium, here are some news and updates from the Mobile IP project here at the National University of Singapore: - Source code to "Utilizing Wavelan Signal-Strength Measurement to Improve the Handoff Performance of Mobile IP" is now available. The code and documentation can be obtained from http://mip.ee.nus.edu.sg/v3.0beta/btlabs/ We would like to publicly thank and acknowledge the efforts of David Pavon and Mohammed Shabeer of British Telecoms (BT) Labs UK for implementing this code and for kindly letting us have the code for inclusion into future releases of "NUS MIPv4 for Linux". Thank you BT Labs UK 8-) - An M.Eng thesis regarding "Mobile IP and RSVP" integration is now available for download. Just go to the Technical Papers section of our web page to obtain it. - Some preliminary work is underway by the global NUS Mobile IP community to port the "NUS MIPv6 for Linux" codes to the 2.2/2.3 Linux kernel. More information and some code can be obtained from http://mip.ee.nus.edu.sg/mipv6/v1.1-workinprogress/ Please do drop us a mail if you're interested in helping out in this porting effort. The NUS Mobile IP project needs you! Central to the future of the NUS Mobile IP project is its global open-source NUS Mobile IP community of volunteer researchers and developers. Please let us know if you are interested in participating in the many projects available: - Two ambitious umbrella projects requiring your expertise: - Umbrella Project 1 - Extreme Mobile IP: MIP for Mission Critical and Enterprise Environments. Looking into issues such as: - Improving the scalability performance of MIP. - Management of MIP systems. - Robustness and Reliable MIP. - Universal Firewall Traversal for MIP. - Umbrella Project 2 - Value-added Mobile IP. Looking into issues such as: - Improving the Handoff Performance of Mobile IP via Fast Handoff and RAFA. (completed) - MIP and RSVP/IntServ integration. (almost completed) - MIP and MPLS integration. (ongoing) - MIP and DiffServ integration. - MIP and ATM integration. - Mobile networks support under MIP. (ongoing) - MIP and SNMP integration. - MIP and MANET integration. - MIP and 3G integration. - Further improvements to the "NUS MIPv4 for Linux", "NUS MIPv6 for Linux" and "NUS MIPv4 for Windows" software packages. We here at the NUS Mobile IP project would like to wish the Mobile IP community a belated Merry Xmas and a Happy Millenium New Year. Best Regards, Foo Chun Choong, The NUS Mobile IP Project, http://mip.ee.nus.edu.sg National University of Singapore ccfoo@hawk.ee.nus.edu.sg From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 12:12: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 MAA02561 for ; Tue, 4 Jan 2000 12: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.75F39FC0@standards.nortelnetworks.com>; Tue, 4 Jan 2000 12:01:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 103886 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 12:00:39 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5146BD10@standards.nortelnetworks.com>; Tue, 4 Jan 2000 12:00:39 -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 JAA11408 for ; Tue, 4 Jan 2000 09:10:55 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id JAA07983 for ; Tue, 4 Jan 2000 09:10:55 -0800 X-Virus-Scanned: Tue, 4 Jan 2000 09:10:55 -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) xma007896; Tue, 4 Jan 00 09:10: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: <3872299C.18A3D8CC@iprg.nokia.com> Date: Tue, 4 Jan 2000 09:10: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] AAA functionality To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, There has been some discussion about how to let AAA authorize a mobile node's connectivity separately from the process of Mobile IP registration. The idea would be to give a mobile node a little unauthorized time while the AAA process goes to completion. It is expected that a Mobile IP registration will be faster than authentication/authorization by AAA. Suppose that the Mobile IP registration succeeds, and the AAA authentication fails. Then, one might expect that the Mobile IP registration should be terminated immediately without waiting for the registration lifetime to expire. Mobile IP does not currently have any mechanism to do this. I think the mobile node has to be notified that something went wrong. Thus, we need a way to send the notification to the mobile node. This could be a new Mobile IP message, or ICMP, or ... ? Any such message would have to be authenticated in some way that is credible to the mobile node. The alternative would be just to cut off service to the mobile node without notification, which seems rather draconian. Can anyone offer a good solution to enable this sort of parallel processing for mobile node registrations? Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 12:25: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 MAA02797 for ; Tue, 4 Jan 2000 12:25:57 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.066E0DF0@standards.nortelnetworks.com>; Tue, 4 Jan 2000 12:12:52 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 103974 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 12:12:34 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FB947F40@standards.nortelnetworks.com>; Tue, 4 Jan 2000 12:12:34 -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 JAA04257; Tue, 4 Jan 2000 09:22:49 -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 JAA12243; Tue, 4 Jan 2000 09:22:48 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id JAA01003; Tue, 4 Jan 2000 09:22:41 -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: <200001041722.JAA01003@nasnfs.eng.sun.com> Date: Tue, 4 Jan 2000 09:20:11 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] AAA functionality X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Perhaps I am missing something, but I *really* don't see how the AAA and Mobile-IP requests can be done in parallel. If a requirement is that it must be possible to separate the two, then I would prefer to see that both requests are done sequentially, first AAA then Mobile-IP. This would remove many strange interactions, and would be a much cleaner approach. PatC >Hello, > >There has been some discussion about how to let AAA authorize >a mobile node's connectivity separately from the process of >Mobile IP registration. The idea would be to give a mobile >node a little unauthorized time while the AAA process >goes to completion. It is expected that a Mobile IP registration >will be faster than authentication/authorization by AAA. > >Suppose that the Mobile IP registration succeeds, and the AAA >authentication fails. Then, one might expect that the Mobile IP >registration should be terminated immediately without waiting for >the registration lifetime to expire. Mobile IP does not currently >have any mechanism to do this. I think the mobile node has to >be notified that something went wrong. Thus, we need a way to >send the notification to the mobile node. > >This could be a new Mobile IP message, or ICMP, or ... ? >Any such message would have to be authenticated in some >way that is credible to the mobile node. > >The alternative would be just to cut off service to the mobile >node without notification, which seems rather draconian. > >Can anyone offer a good solution to enable this sort of >parallel processing for mobile node registrations? > >Regards, >Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 14:41: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 OAA04838 for ; Tue, 4 Jan 2000 14:41:33 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.36C198B0@standards.nortelnetworks.com>; Tue, 4 Jan 2000 14:30:14 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 104233 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 14:29:18 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1529BE30@standards.nortelnetworks.com>; Tue, 4 Jan 2000 14:29:17 -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 LAA12829 for ; Tue, 4 Jan 2000 11:39:34 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id LAA17548 for ; Tue, 4 Jan 2000 11:39:33 -0800 X-Virus-Scanned: Tue, 4 Jan 2000 11:39:33 -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) xma017457; Tue, 4 Jan 00 11:39:30 -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: <38724C72.6F77B7D8@iprg.nokia.com> Date: Tue, 4 Jan 2000 11:39:30 -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] draft-ietf-mobileip-rfc2002-bis-01.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, I am finalizing a new draft for RFC2002bis. I have taken all the messages I can find from the mailing list, and the discussion from the last IETF meeting as reflected in the minutes as my recipe for making the revisions. If anyone has additional comments, please send them in as soon as possible. > == from the minutes for IETF 46. > > == some of my discussion, also from the minutes. > FA can now configure a max number of pending registrations, and may > delete them if > 7 seconds old > > >Clarification by Charles: > >RFC2002 offers 7 seconds as a typical value for this timeout. Particular > >implementations can still pick whatever value they like. Other > >discussion at the meeting suggested the specification of a minimum > >value, and changing the suggested maximum from 7 seconds to something > >more. > > Max number of outstanding requests not standardize, but 7 seconds is hardcoded. > Dave J. & Nordmark: why is this hard coded? > A: ok, we'll talk about it There wasn't any more discussion. The draft currently _suggests_ 7 seconds as a default value, but it also suggests that any value may be configured. I inserted language that any such value SHOULD be chosen to be at least 3 seconds. I'm happy to use alternative language if it is supplied. > What to do with this draft? Mandatory support for reverse tunneling? I included language that foreign agents SHOULD support reverse tunneling, and home agents MUST support decapsulation of reverse tunnels. > Do we take it to draft standard or to an intermediate proposed > standard? Does it become an RFC? I think the consensus was to recycle at Proposed. > Q: new FA forwarding text; sometimes two MNs on the same FA sometimes get > traffic forwarded directly rather than via HA. Also MNs can introduce > denial of service if they make a mistake in their registration > messages - sometimes re-registrations can be redirected at a MN! Do I need to do anything here? > A: Reverse tunneling might be important enough to go in. Done. ======================================================================== From: Henry Haverinen > Therefore, I'd like to propose one of the following clarifications to > be added to Section 4.2.3 of RFC2002bis: > Alternative 1 > For multihomed home agents, the source address in the outer IP header of > the encapsulated datagram MUST be the address that the mobile node used in > the home agent field of the registration request. That is, the home agent > cannot use the the address of some other network interface as the source > address. Done. ========================================================================= Happy New Year, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 15:29: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 PAA05776 for ; Tue, 4 Jan 2000 15:29:23 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F186A630@standards.nortelnetworks.com>; Tue, 4 Jan 2000 15:18:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 104358 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 15:16:52 -0500 Received: from gunpowder.stanford.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.52579200@standards.nortelnetworks.com>; Tue, 4 Jan 2000 15:06:47 -0500 Received: (qmail 2986 invoked by alias); 4 Jan 2000 20:15:42 -0000 Received: (qmail 2974 invoked from network); 4 Jan 2000 20:15:42 -0000 Received: from thermite.stanford.edu (171.64.67.72) by gunpowder.stanford.edu with SMTP; 4 Jan 2000 20:15:42 -0000 X-Mailer: exmh version 2.0.2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20000104201542.2985.qmail@gunpowder.stanford.edu> Date: Tue, 4 Jan 2000 12:19:13 -0800 Reply-To: Xinhua Zhao Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Xinhua Zhao Subject: Re: [MOBILE-IP] AAA functionality X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of "Tue, 04 Jan 2000 09:20:11 PST." <200001041722.JAA01003@nasnfs.eng.sun.com> > Perhaps I am missing something, but I *really* don't see how the AAA > and Mobile-IP requests can be done in parallel. If a requirement is > that it must be possible to separate the two, then I would prefer to > see that both requests are done sequentially, first AAA then Mobile-IP. > This would remove many strange interactions, and would be a much cleaner > approach. I agree that it would be a cleaner approach to do them sequentially. Although doing them in parallel won't work without devising some new mechanism, the idea of letting a mobile host to obtain connectivity as soon as possible (potentially translating into faster handoff) without having to wait for AAA (presumably takes longer) to complete is worth some consideration. So, in case we want to do them in parallel, there is another possibility in addition to the two mentioned by Charlie. See below. > > PatC > >Hello, > > > >There has been some discussion about how to let AAA authorize > >a mobile node's connectivity separately from the process of > >Mobile IP registration. The idea would be to give a mobile > >node a little unauthorized time while the AAA process > >goes to completion. It is expected that a Mobile IP registration > >will be faster than authentication/authorization by AAA. > > > >Suppose that the Mobile IP registration succeeds, and the AAA > >authentication fails. Then, one might expect that the Mobile IP > >registration should be terminated immediately without waiting for > >the registration lifetime to expire. Mobile IP does not currently > >have any mechanism to do this. I think the mobile node has to > >be notified that something went wrong. Thus, we need a way to > >send the notification to the mobile node. > > > >This could be a new Mobile IP message, or ICMP, or ... ? > >Any such message would have to be authenticated in some > >way that is credible to the mobile node. > > > >The alternative would be just to cut off service to the mobile > >node without notification, which seems rather draconian. > > > >Can anyone offer a good solution to enable this sort of > >parallel processing for mobile node registrations? Another possibility would be for the mobile host to treat the registration reply as temporary (with a certain timeout value), indicated through an extension. Short of subsequent AAA authorization messages, the mobile host must terminate the registration at the end of the temporary usage period. The advantage of this approach is that it does not introduce any new messages. Regards, Xinhua MosquitoNet Project on Mobile and Wireless Computing Stanford University http://MosquitoNet.Stanford.EDU > > > >Regards, > >Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 15:53: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 PAA06258 for ; Tue, 4 Jan 2000 15:53:14 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2BEA9680@standards.nortelnetworks.com>; Tue, 4 Jan 2000 15:41:30 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 104433 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 15:39:46 -0500 Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ED441320@standards.nortelnetworks.com>; Tue, 4 Jan 2000 15:39:45 -0500 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Tue Jan 4 15:49:06 EST 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Tue Jan 4 15:49:04 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 3480F5701C; Tue, 4 Jan 2000 14:49:04 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <9A9367D1556AD21182C40000F80930AB010BC176@crchy28b.us.nortel.com> <200001032050.MAA08191@sigma.cisco.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000104204904.3480F5701C@king.research.bell-labs.com> Date: Tue, 4 Jan 2000 14:49:04 -0600 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] Multiple IP addresses per NAI X-To: "Kent K. Leung" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200001032050.MAA08191@sigma.cisco.com> Content-Transfer-Encoding: 7bit Hi, Kent, "Kent K. Leung" (KKL) writes: >> I think the correct and clean way to allow any user to have multiple devices >> is to have each device owned by a user to send a new extension during the >> registration phase called a Device Extension. This extension may be KKL> I agree with this approach. But what about a mobile device with two different interfaces of two different technologies - wouldn't it be nice to be able to continue a session from, say, CDMA to Ethernet? I don't think we need to pin down the device's link-layer address (maybe Mohamed's extension doesn't quite do that, but it at least gives the specific technology. This may preclude handoff from one technology to another). A logical session identifier seems more appropriate. This could just be a single (small) integer, and it should be independent of the link-layer technology in use. >> > Re-registrations will presumably have valid Home Address fields in the >> > registration request. New registrations will have 0.0.0.0. KKL> I think part of the problem is that address allocation has not been KKL> sufficiently covered by any drafts. The NAI draft does not explain KKL> the meaning when NAI extension exist and home address is non-zero. KKL> Does this always happen for re-registrations? Re-registrations KKL> may have zero home address field. KKL> My interpretation is that the HA could use this ip address as a hint KKL> for address allocation even for new registrations (similar to dial KKL> environment). But if address is used, then HA will return a new ip KKL> address. But some maybe the MN really wanted that address for some KKL> reason. In that case, MN should deregister that address after being KKL> accepted. Anyways, it's ambiguous on how HA deal with registrations KKL> with NAI ext and non-zero Home Address. Perhaps whatever new extension is defined could clarify these issues. My feeling is that if the MN gives an address, it expects to have that address assigned to it. We need to preserve compatibility with nodes that don't do dynamic address assignment. >> > Maybe so, but I don't think we should necessarily augment the NAI >> > extension itself - that would slow down too many other efforts. Maybe >> > a new Session ID extension should be created. KKL> I don't have problem with that. Not all cases require further KKL> NAI subidentification. -Pete From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 16:36: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 QAA07222 for ; Tue, 4 Jan 2000 16:36:37 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.56B40D50@standards.nortelnetworks.com>; Tue, 4 Jan 2000 16:25:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 104538 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 16:25:10 -0500 Received: from mw.3com.com (149.112.20.3) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.44E0C230@standards.nortelnetworks.com>; Tue, 4 Jan 2000 16:25:09 -0500 Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id PAA11676; Tue, 4 Jan 2000 15:35:10 -0600 (CST) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8625685C.0076A127 ; Tue, 4 Jan 2000 15:35:45 -0600 X-Lotus-FromDomain: 3COM@3COM-MWGATE Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <8625685C.00769E22.00@mwgate02.mw.3com.com> Date: Tue, 4 Jan 2000 15:25:29 -0600 Reply-To: Yingchun Xu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yingchun Xu Subject: Re: [MOBILE-IP] AAA functionality To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Another way of doing this will be to merge AAA and Mobile-IP request procedures. +===========================================+ | AAA Infrastructure | +===========================================+ /|\ | | /|\ RRQ RRP RRQ RRP | \|/ \|/ | +=======+ +=======+ | FA | <-----Tunneling Data-------> | HA | | | | | +=======+ +=======+ Here RRQ and RRP will be the Mobile IP Registration Request and Reply Messages. The data tunneling will be between FA and HA. For repeat registration caused by lifetime expiration, the registration can optionally go directly from FA to HA. --Yingchun. Xinhua Zhao on 01/04/2000 02:19:13 PM Please respond to Xinhua Zhao Sent by: Xinhua Zhao To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM cc: (Yingchun Xu/MW/US/3Com) Subject: Re: [MOBILE-IP] AAA functionality > Perhaps I am missing something, but I *really* don't see how the AAA > and Mobile-IP requests can be done in parallel. If a requirement is > that it must be possible to separate the two, then I would prefer to > see that both requests are done sequentially, first AAA then Mobile-IP. > This would remove many strange interactions, and would be a much cleaner > approach. I agree that it would be a cleaner approach to do them sequentially. Although doing them in parallel won't work without devising some new mechanism, the idea of letting a mobile host to obtain connectivity as soon as possible (potentially translating into faster handoff) without having to wait for AAA (presumably takes longer) to complete is worth some consideration. So, in case we want to do them in parallel, there is another possibility in addition to the two mentioned by Charlie. See below. > > PatC > >Hello, > > > >There has been some discussion about how to let AAA authorize > >a mobile node's connectivity separately from the process of > >Mobile IP registration. The idea would be to give a mobile > >node a little unauthorized time while the AAA process > >goes to completion. It is expected that a Mobile IP registration > >will be faster than authentication/authorization by AAA. > > > >Suppose that the Mobile IP registration succeeds, and the AAA > >authentication fails. Then, one might expect that the Mobile IP > >registration should be terminated immediately without waiting for > >the registration lifetime to expire. Mobile IP does not currently > >have any mechanism to do this. I think the mobile node has to > >be notified that something went wrong. Thus, we need a way to > >send the notification to the mobile node. > > > >This could be a new Mobile IP message, or ICMP, or ... ? > >Any such message would have to be authenticated in some > >way that is credible to the mobile node. > > > >The alternative would be just to cut off service to the mobile > >node without notification, which seems rather draconian. > > > >Can anyone offer a good solution to enable this sort of > >parallel processing for mobile node registrations? Another possibility would be for the mobile host to treat the registration reply as temporary (with a certain timeout value), indicated through an extension. Short of subsequent AAA authorization messages, the mobile host must terminate the registration at the end of the temporary usage period. The advantage of this approach is that it does not introduce any new messages. Regards, Xinhua MosquitoNet Project on Mobile and Wireless Computing Stanford University http://MosquitoNet.Stanford.EDU > > > >Regards, > >Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 16: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 QAA07440 for ; Tue, 4 Jan 2000 16:44:45 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.78132F20@standards.nortelnetworks.com>; Tue, 4 Jan 2000 16:33:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 104603 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 16:33:16 -0500 Received: from sigma.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.66E1F060@standards.nortelnetworks.com>; Tue, 4 Jan 2000 16:33:16 -0500 Received: (from kleung@localhost) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA02260; Tue, 4 Jan 2000 13:43:30 -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: <200001042143.NAA02260@sigma.cisco.com> Date: Tue, 4 Jan 2000 13:43:30 -0800 Reply-To: "Kent K. Leung" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Kent K. Leung" Subject: Re: [MOBILE-IP] Multiple IP addresses per NAI X-To: Pete McCann To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <20000104204904.3480F5701C@king.research.bell-labs.com> from "Pete McCann" at Jan 04, 2000 02:49:04 PM Content-Transfer-Encoding: 7bit Hi Pete. > But what about a mobile device with two different interfaces of two > different technologies - wouldn't it be nice to be able to continue a > session from, say, CDMA to Ethernet? I don't think we need to pin > down the device's link-layer address (maybe Mohamed's extension > doesn't quite do that, but it at least gives the specific technology. > This may preclude handoff from one technology to another). A logical > session identifier seems more appropriate. This could just be a > single (small) integer, and it should be independent of the > link-layer technology in use. > I agreed with the general approach of having a sub-NAI extension. Actually, I was thinking along the line that the extension would just contain Type-Length-Value where Value is defined by NAI's username grammar (in RFC 2486). This provides some flexibility. > Perhaps whatever new extension is defined could clarify these issues. > My feeling is that if the MN gives an address, it expects to have that > address assigned to it. We need to preserve compatibility with nodes > that don't do dynamic address assignment. > Yes, it needs clarification. A node that doesn't do dynamic address assignment can still deal with the reply properly. But the scheme allows for nodes to say "I prefer this address, but give me any if that's not available" as well. Since the sub-NAI extension deals with address allocation, the draft should clarify ambiguities that will cause interoperability. -- Kent -- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 17:55: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 RAA08595 for ; Tue, 4 Jan 2000 17:55:57 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6B726970@standards.nortelnetworks.com>; Tue, 4 Jan 2000 17:44:59 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 104758 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 17:43:28 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.35113550@standards.nortelnetworks.com>; Tue, 4 Jan 2000 17:43:27 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 4 Jan 2000 16:53:34 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Tue, 4 Jan 2000 17:53:09 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 4 Jan 2000 16:53:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5706.77E82F8E" Message-ID: <9A9367D1556AD21182C40000F80930AB010BC17C@crchy28b.us.nortel.com> Date: Tue, 4 Jan 2000 16:53:06 -0600 Reply-To: Mohamed Khalil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohamed Khalil Subject: Re: [MOBILE-IP] Multiple IP addresses per NAI X-To: Pete McCann 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_01BF5706.77E82F8E Content-Type: text/plain Hi Pete, > -----Original Message----- > From: Pete McCann [SMTP:mccap@RESEARCH.BELL-LABS.COM] > Sent: Tuesday, January 04, 2000 2:49 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Multiple IP addresses per NAI > > Hi, Kent, > > "Kent K. Leung" (KKL) writes: > > >> I think the correct and clean way to allow any user to have multiple > devices > >> is to have each device owned by a user to send a new extension during > the > >> registration phase called a Device Extension. This extension may be > > KKL> I agree with this approach. > > But what about a mobile device with two different interfaces of two > different technologies - wouldn't it be nice to be able to continue a > session from, say, CDMA to Ethernet? I don't think we need to pin > down the device's link-layer address (maybe Mohamed's extension > doesn't quite do that, but it at least gives the specific technology. > This may preclude handoff from one technology to another). A logical > session identifier seems more appropriate. This could just be a > single (small) integer, and it should be independent of the > link-layer technology in use. > [MK>] The device id is actually an id which is offered by the ISP when the user obtained the service. It could be something like mci-phone-214-78-9898 or it could be an integer #. The User NAI and the device id will be used by the mobile agent to uniquely identify the device. The device could support multiple technologies but it is still have one device id. If the user's device needs to re-register because it has changed technology, it should use the same device id in the registration request. if the device has already assigned an IP by the home subnetwork, it will not be reassigned another IP because it has changed technology. I did not understand how this proposal will preclude handoff from one technology to another technology. > >> > Re-registrations will presumably have valid Home Address fields in > the > >> > registration request. New registrations will have 0.0.0.0. > > KKL> I think part of the problem is that address allocation has not been > KKL> sufficiently covered by any drafts. The NAI draft does not explain > KKL> the meaning when NAI extension exist and home address is non-zero. > KKL> Does this always happen for re-registrations? Re-registrations > KKL> may have zero home address field. > > KKL> My interpretation is that the HA could use this ip address as a hint > KKL> for address allocation even for new registrations (similar to dial > KKL> environment). But if address is used, then HA will return a new ip > KKL> address. But some maybe the MN really wanted that address for some > KKL> reason. In that case, MN should deregister that address after being > KKL> accepted. Anyways, it's ambiguous on how HA deal with registrations > KKL> with NAI ext and non-zero Home Address. > > Perhaps whatever new extension is defined could clarify these issues. > My feeling is that if the MN gives an address, it expects to have that > address assigned to it. We need to preserve compatibility with nodes > that don't do dynamic address assignment. > > >> > Maybe so, but I don't think we should necessarily augment the NAI > >> > extension itself - that would slow down too many other efforts. > Maybe > >> > a new Session ID extension should be created. > > KKL> I don't have problem with that. Not all cases require further > KKL> NAI subidentification. > > -Pete ------_=_NextPart_001_01BF5706.77E82F8E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] Multiple IP addresses per NAI

Hi Pete,

    -----Original Message-----
    From:   Pete McCann = [SMTP:mccap@RESEARCH.BELL-LABS.COM]
    Sent:   Tuesday, January 04, 2000 2:49 PM
    To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: [MOBILE-IP] Multiple IP = addresses per NAI

    Hi, Kent,

    "Kent K. Leung" = <kleung@CISCO.COM> (KKL) writes:

    >> I think the correct and clean = way to allow any user to have multiple devices
    >> is to have each device owned = by a user to send a new extension during the
    >> registration phase called = a  Device Extension. This extension may be

    KKL> I agree with this = approach.

    But what about a mobile device with = two different interfaces of two
    different technologies - wouldn't it = be nice to be able to continue a
    session from, say, CDMA to = Ethernet?  I don't think we need to pin
    down the device's link-layer address = (maybe Mohamed's extension
    doesn't quite do that, but it at = least gives the specific technology.
    This may preclude handoff from one = technology to another).  A logical
    session identifier seems more = appropriate.  This could just be a
    single (small) integer, and it should = be independent of the
    link-layer technology in use.

    [MK>]  The device id is actually an = id which is offered by the ISP when the user obtained the service. It = could be something like mci-phone-214-78-9898

    or it could be an = integer #. The User NAI and the device id will be used by the mobile = agent to uniquely identify the device. The device could support = multiple technologies but it is still have one device id. If the user's = device needs to re-register because it has changed technology, it = should use the same device id in the registration request. if the = device has already assigned an IP by the home subnetwork, it will not = be reassigned another IP because it has changed technology. I did not = understand how this proposal will preclude handoff from one technology = to another technology.

    >> > Re-registrations will = presumably have valid Home Address fields in the
    >> > registration = request.  New registrations will have 0.0.0.0.

    KKL> I think part of the problem is = that address allocation has not been
    KKL> sufficiently covered by any = drafts.  The NAI draft does not explain
    KKL> the meaning when NAI = extension exist and home address is non-zero.
    KKL> Does this always happen for = re-registrations?   Re-registrations
    KKL> may have zero home address = field.

    KKL> My interpretation is that the = HA could use this ip address as a hint
    KKL> for address allocation even = for new registrations (similar to dial
    KKL> environment).  But if = address is used, then HA will return a new ip
    KKL> address.  But some maybe = the MN really wanted that address for some
    KKL> reason.  In that case, = MN should deregister that address after being
    KKL> accepted.  Anyways, it's = ambiguous on how HA deal with registrations
    KKL> with NAI ext and non-zero = Home Address.

    Perhaps whatever new extension is = defined could clarify these issues.
    My feeling is that if the MN gives an = address, it expects to have that
    address assigned to it.  We need = to preserve compatibility with nodes
    that don't do dynamic address = assignment.

    >> > Maybe so, but I don't = think we should necessarily augment the NAI
    >> > extension itself - that = would slow down too many other efforts.  Maybe
    >> > a new Session ID = extension should be created.

    KKL> I don't have problem with = that.  Not all cases require further
    KKL> NAI subidentification.

    -Pete

------_=_NextPart_001_01BF5706.77E82F8E-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 18:22: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 SAA09194 for ; Tue, 4 Jan 2000 18:22:55 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.34C20710@standards.nortelnetworks.com>; Tue, 4 Jan 2000 18:12:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 104831 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 18:11:45 -0500 Received: from crufty.research.bell-labs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.28C33240@standards.nortelnetworks.com>; Tue, 4 Jan 2000 18:11:45 -0500 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Tue Jan 4 18:21:51 EST 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Tue Jan 4 18:21:51 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 59BA85701C; Tue, 4 Jan 2000 17:21:50 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <9A9367D1556AD21182C40000F80930AB010BC17C@crchy28b.us.nortel.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000104232150.59BA85701C@king.research.bell-labs.com> Date: Tue, 4 Jan 2000 17:21:50 -0600 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] Multiple IP addresses per NAI X-To: Mohamed Khalil To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <9A9367D1556AD21182C40000F80930AB010BC17C@crchy28b.us.nortel.com> Content-Transfer-Encoding: 7bit Mohamed Khalil (MK) writes: MK> The device id is actually an id which is offered by the ISP when MK> the user obtained the service. It could be something like MK> mci-phone-214-78-9898 or it could be an integer #. The User NAI MK> and the device id will be used by the mobile agent to uniquely MK> identify the device. The device could support multiple MK> technologies but it is still have one device id. If the user's MK> device needs to re-register because it has changed technology, it MK> should use the same device id in the registration request. if the MK> device has already assigned an IP by the home subnetwork, it will MK> not be reassigned another IP because it has changed technology. I MK> did not understand how this proposal will preclude handoff from MK> one technology to another technology. Hi, Mohamed, I must have misunderstood your intention, then. Your extension had these two fields: Sub-Type 1 ETHERNET_DEV. 2 TDMA_DEV. 3 CDMA_DEV. device parameters this section defines the device parameters which is requested by the mobile node. this section MAY be modified by the home agent or foreign agent to match the current operating capability of the network and the services which is allowed for the user. The structure of this section depends on the type of the device. device id It is the device identification. example MCI-LAPTOP-193.193.193.20 Since the Sub-Type gave the specific link-layer technology, I was assuming that device parameters contained a link-layer address and that this was used to distinguish sessions. I can see now that you didn't actually say that. Still, this extension seems overly complicated to me. For one thing, the HA needs to know the semantics of each Sub-Type to properly find the device id (since device parameters is variable length). I just don't think it's necessary to give any information about the link-layer interface to solve the multiple-sessions-per-NAI problem. All we need is one integer called a "session id". If you want to send link-layer interface information, that could be accomplished with a separate extension (note that there may be more than one session id per interface! That's another reason not to couple these two things together in one extension). -Pete From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 18:32: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 SAA09499 for ; Tue, 4 Jan 2000 18:32:04 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.792F28A0@standards.nortelnetworks.com>; Tue, 4 Jan 2000 18:21:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 104823 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 18:19:58 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E93A6530@standards.nortelnetworks.com>; Tue, 4 Jan 2000 18:09:58 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA28283; Tue, 4 Jan 2000 16:20:10 -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 PAA18894; Tue, 4 Jan 2000 15:20:10 -0800 (PST) Received: from onion (onion.East.Sun.COM [129.148.174.110]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA18841; Tue, 4 Jan 2000 15:20:08 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SMNXFapqeTqOShYCP67rTg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_36 SunOS 5.8 sun4u sparc Message-ID: <200001042320.PAA18841@jurassic.eng.sun.com> Date: Tue, 4 Jan 2000 18:20:12 -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] AAA functionality X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I don't think I'd be in favor of parallel AAA and MIP authentications where the MN is allowed some short access time. I am assuming you mean only the first registration with a FA would be allowed for a short time, otherwise the MN will simply 'renew' every second to stay within that window. If a good parallel mechanism came forward I might be in favor of that, but not where the MN has some free time (figuratively, and literally). I see this as allowing a short security violation on the grounds that it may not really be a security violation. A mechanism to allow the registration reply to have a short timeout, requireing the MN to be 'honorable' and stop trying to use it's binding is silly, since the FA is the enforcement point. I agree the FA killing the service without letting the MN node is draconian, so there needs to be a way for the MN to know its been cut off. The FA could simply send a registration reply with a denial, though this breaks RFC2002[-bis] in that an FA isn't allowed to generate a registration reply that is not in response to a request (though I suppose you could argue it's simply the second response to a request). Personally, I've always thought there should be a way to terminate a binding in MIP, independant of what AAA may need it for. Cheers, Steve >X-Virus-Scanned: Tue, 4 Jan 2000 09:10:55 -0800 Nokia Silicon Valley AntiVirus Appliance >X-Accept-Language: en >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >From: "Charles E. Perkins" >Subject: [MOBILE-IP] AAA functionality >To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > >Hello, > >There has been some discussion about how to let AAA authorize >a mobile node's connectivity separately from the process of >Mobile IP registration. The idea would be to give a mobile >node a little unauthorized time while the AAA process >goes to completion. It is expected that a Mobile IP registration >will be faster than authentication/authorization by AAA. > >Suppose that the Mobile IP registration succeeds, and the AAA >authentication fails. Then, one might expect that the Mobile IP >registration should be terminated immediately without waiting for >the registration lifetime to expire. Mobile IP does not currently >have any mechanism to do this. I think the mobile node has to >be notified that something went wrong. Thus, we need a way to >send the notification to the mobile node. > >This could be a new Mobile IP message, or ICMP, or ... ? >Any such message would have to be authenticated in some >way that is credible to the mobile node. > >The alternative would be just to cut off service to the mobile >node without notification, which seems rather draconian. > >Can anyone offer a good solution to enable this sort of >parallel processing for mobile node registrations? > >Regards, >Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 19:31: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 TAA10475 for ; Tue, 4 Jan 2000 19:31:19 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C00BBF60@standards.nortelnetworks.com>; Tue, 4 Jan 2000 19:20:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 105054 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 19:19:09 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.936849B0@standards.nortelnetworks.com>; Tue, 4 Jan 2000 19:19:09 -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 QAA15878 for ; Tue, 4 Jan 2000 16:29:26 -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 QAA02431 for ; Tue, 4 Jan 2000 16:29:25 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id QAA16589; Tue, 4 Jan 2000 16:29:12 -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: <200001050029.QAA16589@nasnfs.eng.sun.com> Date: Tue, 4 Jan 2000 16:26:46 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] AAA functionality X-To: Steven Glass - Solaris Software To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I second this concern for security. Note that in the PPP world, which is really not all that different from what we are talking about here, I have I *never* heard of a PPP server granting temporary access while waiting for the AAA server to respond. If no authentication is required, then simply do not use AAA. Again, sequential is the correct behavior. PatC > I don't think I'd be in favor of parallel AAA and MIP authentications where >the MN is allowed some short access time. I am assuming you mean only the >first >registration with a FA would be allowed for a short time, otherwise the MN will >simply 'renew' every second to stay within that window. If a good parallel >mechanism came forward I might be in favor of that, but not where the MN has >some free time (figuratively, and literally). I see this as allowing a short >security violation on the grounds that it may not really be a security >violation. > > A mechanism to allow the registration reply to have a short timeout, >requireing the MN to be 'honorable' and stop trying to use it's binding is >silly, since the FA is the enforcement point. I agree the FA killing the >service without letting the MN node is draconian, so there needs to be a way >for >the MN to know its been cut off. The FA could simply send a registration reply >with a denial, though this breaks RFC2002[-bis] in that an FA isn't allowed to >generate a registration reply that is not in response to a request (though I >suppose you could argue it's simply the second response to a request). >Personally, I've always thought there should be a way to terminate a binding in >MIP, independant of what AAA may need it for. > > Cheers, > Steve > > >>X-Virus-Scanned: Tue, 4 Jan 2000 09:10:55 -0800 Nokia Silicon Valley AntiVirus >Appliance >>X-Accept-Language: en >>MIME-Version: 1.0 >>Content-Transfer-Encoding: 7bit >>From: "Charles E. Perkins" >>Subject: [MOBILE-IP] AAA functionality >>To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >> >>Hello, >> >>There has been some discussion about how to let AAA authorize >>a mobile node's connectivity separately from the process of >>Mobile IP registration. The idea would be to give a mobile >>node a little unauthorized time while the AAA process >>goes to completion. It is expected that a Mobile IP registration >>will be faster than authentication/authorization by AAA. >> >>Suppose that the Mobile IP registration succeeds, and the AAA >>authentication fails. Then, one might expect that the Mobile IP >>registration should be terminated immediately without waiting for >>the registration lifetime to expire. Mobile IP does not currently >>have any mechanism to do this. I think the mobile node has to >>be notified that something went wrong. Thus, we need a way to >>send the notification to the mobile node. >> >>This could be a new Mobile IP message, or ICMP, or ... ? >>Any such message would have to be authenticated in some >>way that is credible to the mobile node. >> >>The alternative would be just to cut off service to the mobile >>node without notification, which seems rather draconian. >> >>Can anyone offer a good solution to enable this sort of >>parallel processing for mobile node registrations? >> >>Regards, >>Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 19:49: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 TAA10673 for ; Tue, 4 Jan 2000 19:49:19 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.480825A0@standards.nortelnetworks.com>; Tue, 4 Jan 2000 19:38:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 105122 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 19:36:58 -0500 Received: from gunpowder.stanford.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AAE81B50@standards.nortelnetworks.com>; Tue, 4 Jan 2000 19:26:58 -0500 Received: (qmail 3896 invoked by alias); 5 Jan 2000 00:35:24 -0000 Received: (qmail 3884 invoked from network); 5 Jan 2000 00:35:24 -0000 Received: from thermite.stanford.edu (171.64.67.72) by gunpowder.stanford.edu with SMTP; 5 Jan 2000 00:35:24 -0000 X-Mailer: exmh version 2.0.2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20000105003524.3895.qmail@gunpowder.stanford.edu> Date: Tue, 4 Jan 2000 16:39:27 -0800 Reply-To: Xinhua Zhao Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Xinhua Zhao Subject: Re: [MOBILE-IP] AAA functionality X-To: Steven Glass - Solaris Software To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of "Tue, 04 Jan 2000 18:20:12 EST." <200001042320.PAA18841@jurassic.eng.sun.com> > I don't think I'd be in favor of parallel AAA and MIP authentications where > the MN is allowed some short access time. I am assuming you mean only the first > registration with a FA would be allowed for a short time, otherwise the MN will > simply 'renew' every second to stay within that window. If a good parallel > mechanism came forward I might be in favor of that, but not where the MN has > some free time (figuratively, and literally). I see this as allowing a short > security violation on the grounds that it may not really be a security > violation. > > A mechanism to allow the registration reply to have a short timeout, > requireing the MN to be 'honorable' and stop trying to use it's binding is > silly, since the FA is the enforcement point. I agree the FA killing the > service without letting the MN node is draconian, so there needs to be a way for > the MN to know its been cut off. The FA could simply send a registration reply Steve, Actually, I agree that relying on a well-behaving mobile node is not sufficient. The idea was just to use the absence of AAA authorization messages before the timeout to implicitly signal the mobile node that something may have gone wrong. It's just that instead of requiring a mobile node to be prepared to process explicit negative notifications, it requires the mobile node to be prepared for failure by itself in the absence of positive notifications. The FA should still enforce the cut-off of traffic to a mobile node when it fails AAA authorization. This implicit signaling avoids new packets that have to be sent and processed. But it can potentially take longer for a mobile to notice the failure as compared to explicit notification. Though it has both pros and cons, in my opinion it is an alternative nonetheless. > with a denial, though this breaks RFC2002[-bis] in that an FA isn't allowed to > generate a registration reply that is not in response to a request (though I > suppose you could argue it's simply the second response to a request). > Personally, I've always thought there should be a way to terminate a binding in > MIP, independant of what AAA may need it for. A mechanism to explicitly terminate a binding can potentially be useful in the scenario when an FA needs to be turned down and allow another FA in the same subnet to take over. Waiting for the mobile node to figure this out by its own through the loss of FA "beacons" can take too long. Is this what is in your mind for such a mechanism? Regards, Xinhua MosquitoNet Project on Mobile and Wireless Computing Stanford University http://MosquitoNet.Stanford.EDU > > Cheers, > Steve > > > >X-Virus-Scanned: Tue, 4 Jan 2000 09:10:55 -0800 Nokia Silicon Valley AntiVirus > Appliance > >X-Accept-Language: en > >MIME-Version: 1.0 > >Content-Transfer-Encoding: 7bit > >From: "Charles E. Perkins" > >Subject: [MOBILE-IP] AAA functionality > >To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > >Hello, > > > >There has been some discussion about how to let AAA authorize > >a mobile node's connectivity separately from the process of > >Mobile IP registration. The idea would be to give a mobile > >node a little unauthorized time while the AAA process > >goes to completion. It is expected that a Mobile IP registration > >will be faster than authentication/authorization by AAA. > > > >Suppose that the Mobile IP registration succeeds, and the AAA > >authentication fails. Then, one might expect that the Mobile IP > >registration should be terminated immediately without waiting for > >the registration lifetime to expire. Mobile IP does not currently > >have any mechanism to do this. I think the mobile node has to > >be notified that something went wrong. Thus, we need a way to > >send the notification to the mobile node. > > > >This could be a new Mobile IP message, or ICMP, or ... ? > >Any such message would have to be authenticated in some > >way that is credible to the mobile node. > > > >The alternative would be just to cut off service to the mobile > >node without notification, which seems rather draconian. > > > >Can anyone offer a good solution to enable this sort of > >parallel processing for mobile node registrations? > > > >Regards, > >Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 21:33: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 VAA11830 for ; Tue, 4 Jan 2000 21:33:53 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DAA89530@standards.nortelnetworks.com>; Tue, 4 Jan 2000 21:22:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 105199 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 21:21:44 -0500 Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4D3C5160@standards.nortelnetworks.com>; Tue, 4 Jan 2000 21:11:43 -0500 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Tue Jan 4 21:20:20 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 VAA01897 for ; Tue, 4 Jan 2000 21:20:20 -0500 (EST) Received: (from salga@localhost) by valjean.dnrc.bell-labs.com (8.9.3/8.8.7) id VAA16004 for MOBILE-IP@standards.nortelnetworks.com; Tue, 4 Jan 2000 21:20:16 -0500 References: <200001050029.QAA16589@nasnfs.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us X-Operating-System: Linux 2.2.12-20 X-Organization: Lucent Technologies, Bell Laboratories Message-ID: <20000104212016.A15987@bell-labs.com> Date: Tue, 4 Jan 2000 21:20:16 -0500 Reply-To: Luca Salgarelli Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Luca Salgarelli Subject: Re: [MOBILE-IP] AAA functionality To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200001050029.QAA16589@nasnfs.eng.sun.com>; from Pat.Calhoun@Eng.Sun.COM on Tue, Jan 04, 2000 at 04:26:46PM -0800 Pat, I don't agree with you here: with MIP there could be the need of a fast hand-off to a new domain. That need is probably not (yet) so urgent in the PPP world. While I agree that there are some security concerns, I think there is the need to design a AAA/MIP interaction scheme that guarantees fast hand-offs. Luca On Tue, Jan 04, 2000 at 04:26:46PM -0800, Patrice Calhoun wrote: > I second this concern for security. Note that in the PPP world, which is > really not all that different from what we are talking about here, I have > I *never* heard of a PPP server granting temporary access while waiting for > the AAA server to respond. > > If no authentication is required, then simply do not use AAA. > > Again, sequential is the correct behavior. > > PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 5 03:43: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 DAA29284 for ; Wed, 5 Jan 2000 03:43:03 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.60C68130@standards.nortelnetworks.com>; Wed, 5 Jan 2000 3:31:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 105557 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jan 2000 03:29:49 -0500 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1ECA9140@standards.nortelnetworks.com>; Wed, 5 Jan 2000 3:29:49 -0500 Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id KAA14522; Wed, 5 Jan 2000 10:40:05 +0200 (EET) Received: from esebh02nok.ntc.nokia.com (esebh02nok.ntc.nokia.com [131.228.118.151]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id KAA25372; Wed, 5 Jan 2000 10:40:03 +0200 (EET) Received: by esebh02nok with Internet Mail Service (5.5.2650.10) id ; Wed, 5 Jan 2000 10:40:02 +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, 5 Jan 2000 10:39:59 +0200 Reply-To: patrik.flykt@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrik Flykt Subject: Re: [MOBILE-IP] AAA functionality X-To: Pat.Calhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, >Perhaps I am missing something, but I *really* don't see how the AAA >and Mobile-IP requests can be done in parallel. If a requirement is >that it must be possible to separate the two, then I would prefer to >see that both requests are done sequentially, first AAA then Mobile-IP. >This would remove many strange interactions, and would be a much cleaner >approach. I suppose there is a requirement that AAA and MIP messages can be separated (be it parallell or serial message sending). When you pay for access with your credit card the authorization/accounting goes to the credit card company's AAA server, while the Mobile IP messages go to your home agent. The sequential approach is extremely useful if the only case of using AAA with MIP is to ensure that the provider of the foreign agent is able to account for every second of foreign agent usage. However, the provider could also be interested in allowing a short grace period to ensure that the real-time applications used in the mobile node would experience the shortest possible service disruption. I suppose the AAA processing will take at least a couple of seconds and even longer when there are several brokers between the visited and home domains. The grace period enables of course a possibility of fraud, which the provider has to take into account. Minimizing fraud could be done for example by allowing the grace period only to those who have visited the same provider's network earlier and have been given a session key, as described in the "Minimal Latency Secure Hand-off" draft. There is also a third possibility when the provider is providing free access for everyone without any accounting but with authorization. The provider wants to be sure that the home AAA domain authorizes the mobile node, i.e. it is not stolen, in the (for some reason) wrong domain, etc. Regards, Patrik From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 5 05:21: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 FAA00595 for ; Wed, 5 Jan 2000 05:21:07 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.18372F60@standards.nortelnetworks.com>; Wed, 5 Jan 2000 5:09:51 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 105689 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jan 2000 05:08:25 -0500 Received: from telecom.samsung.co.kr (165.213.221.4) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7F110F00@standards.nortelnetworks.com>; Wed, 5 Jan 2000 4:58:24 -0500 Received: from keg ( [165.213.177.180] (may be forged)) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id TAA18861 for ; Wed, 5 Jan 2000 19:08:10 +0900 (KST) MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Message-ID: <009701bf5764$528a3a80$b4b1d5a5@keg.telecom.samsung.co.kr> Date: Wed, 5 Jan 2000 19:04:53 +0900 Reply-To: Woo-June Kim Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Woo-June Kim Subject: Re: [MOBILE-IP] AAA functionality To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id FAA00595 Hi, The discussion upto now basically brings up two conflicting requirements. When the user is registering for the first time with a FA, AAA authentication/authorization should it seems be done before MIP registration. (This could also be done by embedding the MIP msgs inside the AAA msg as suggested earlier, but this would also result in a sequential check - presumably if the AAA authentication/authorization fails, the MIP registration is never carried out.) Another requirement seems to be the wish for allowing previously connected registered users a fast registration method when registering with a new FA near the old FA. i.e minimization of service disruption. This requirement becoming more severe when Real-Time services are used in the future. Allowing grace periods seems fraught with problems of fraud etc. As suggested by Patrik in the e-mail below some sort of localized caching behaviour (my generic term for the use of session_id as envisioned below) may help solve this problem. Another may be to enable the AAAs to not only act as proxies, but also exhibit a caching behaviour so as to allow previously connected users to get quicket authentication/authorization. (I am not sure if this is in the AAA requirements document generated by this group.) Note that there has also been a fair amount of discussion within this group regarding methods for "speeding up" MIP registration or carrying out faster handoffs for the same reasons as above. C. Perkins "Regionalized Tunnel Management" being one example. ("Cellular IP" also being another, though relying on slightly different methods.) As Charles has previously said, there may or may not be a need for such methods. Correct setting of parameters etc. may be enough. (Correct me if I am incorrect in my understanding or recollection of Charles' comments. I think they were in reply to a thread on Cellular IP ..) But if we must develop a solution, one based on localized caching methods seems to be the simplest way out. Maybe not optimal, but one that is fairly robust. Optimality would have to be provided by correct dimensioning, capacity allocation, placement of caches etc. by the operators - a good way for such operators to differentiate themselves from other service providers. Comments ? bye Woojune Kim, Senior Engineer Samsung Electronics Ltd. tel : +82-342-779-8526 hp : +82-11-368-7480 e-mail : keg@telecom.samsung.co.kr > Hi, > >>Perhaps I am missing something, but I *really* don't see how the AAA >>and Mobile-IP requests can be done in parallel. If a requirement is >>that it must be possible to separate the two, then I would prefer to >>see that both requests are done sequentially, first AAA then Mobile-IP. >>This would remove many strange interactions, and would be a much cleaner >>approach. > >I suppose there is a requirement that AAA and MIP messages can be separated >(be it parallell or serial message sending). When you pay for access with >your credit card the authorization/accounting goes to the credit card >company's AAA server, while the Mobile IP messages go to your home agent. > >The sequential approach is extremely useful if the only case of using AAA >with MIP is to ensure that the provider of the foreign agent is able to >account for every second of foreign agent usage. However, the provider could >also be interested in allowing a short grace period to ensure that the >real-time applications used in the mobile node would experience the shortest >possible service disruption. I suppose the AAA processing will take at least >a couple of seconds and even longer when there are several brokers between >the visited and home domains. The grace period enables of course a >possibility of fraud, which the provider has to take into account. >Minimizing fraud could be done for example by allowing the grace period only >to those who have visited the same provider's network earlier and have been >given a session key, as described in the "Minimal Latency Secure Hand-off" >draft. There is also a third possibility when the provider is providing free >access for everyone without any accounting but with authorization. The >provider wants to be sure that the home AAA domain authorizes the mobile >node, i.e. it is not stolen, in the (for some reason) wrong domain, etc. > >Regards, > > Patrik > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 5 06: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 GAA01789 for ; Wed, 5 Jan 2000 06:58:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B66AAF10@standards.nortelnetworks.com>; Wed, 5 Jan 2000 6:47:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 105971 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jan 2000 06:46:14 -0500 Received: from ingate.uk.neceur.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.29601340@standards.nortelnetworks.com>; Wed, 5 Jan 2000 6:36:13 -0500 Received: from internal-mail.uk.neceur.com by ingate.uk.neceur.com id fOo308gBpXJKP1; Wed, 5 Jan 2000 11:44:35 GMT Received: from tokyo.ttd.neceur.com by internal-mail.uk.neceur.com id Zju204gBpXpMO1; Wed, 5 Jan 2000 11:44:33 GMT from tokyo.ttd.neceur.com (localhost [127.0.0.1]) id Zju204gBpXpMO1 for (3.3.2/3.1.31); Wed, 5 Jan 2000 11:44:33 GMT Received: by tokyo.ttd.neceur.com with Internet Mail Service (5.5.1960.3) id ; Wed, 5 Jan 2000 11:44:15 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Message-ID: <3B9AA5E712DCD011AAD500609770A0E920382F@tokyo.ttd.neceur.com> Date: Wed, 5 Jan 2000 11:44:10 -0000 Reply-To: "BINAR, Simon" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "BINAR, Simon" Subject: [MOBILE-IP] 3G Mobile Architectures To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi everyone. There have been recently a lot of discussions on this mailing list about how to make MIP suitable for 3G networks. As most people on this list will know, one of the driving forces behind the standardisation of 3G is 3GPP (I'm a European, so I want talk here about 3GPP 2). Looking at the discussions in 3GPP and the MIP WG of the IETF, it seems to me that both groups are taking different approaches to solve the same problem, and I would like to get some opinions from list members why the IETF model could be better/worse than the 3GPP model. Essentially, the difference I see in the discussions is that the MIP WG assumes in many cases base stations to be IP addressable devices. In other words, the "IP cloud" reaches all the way to the utmost edge of the wireless network. In 3GPP however, the access network is considered (as far as I understand) to be a separate entity. Currently, it seems that the UTRAN is based on ATM transport, IP could be used as an option (correct me if I'm wrong). The higher-layer signalling protocols used in the access network for R'99 are very much SS7 oriented (using things like RANAP, the Radio Access Network Application Part). In this architecture, it seems to me that IP is not "all-embracing", and is restricted more to the core network... Here is now my question: which advantage is there to have IP totally completely utterly all-embracing in the wireless network as opposed to have it deployed only in the core network? My first guess is that there might be advantages in the area of network management (but I'm not an NM expert, therefore, I'd like to get comments from more knowledgeable people in this area). I think that arguments such as "the IETF approach is more elegant" is not valid, since, by the end of the day, we also have to think about business... Anyway, this was my question, and as usual, comments are most welcome... Simon Binar From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 5 09:43: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 JAA06030 for ; Wed, 5 Jan 2000 09:43:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A9489880@standards.nortelnetworks.com>; Wed, 5 Jan 2000 9:31:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 106173 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jan 2000 09:29:40 -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.642B6B60@standards.nortelnetworks.com>; Wed, 5 Jan 2000 9:29:40 -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 PAA28874 for ; Wed, 5 Jan 2000 15:39:58 +0100 (MET) Received: from esealnt172.ericsson.se ([130.100.184.165]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 05 Jan 2000 14:39:47 0000 (GMT) Received: by esealnt172 with Internet Mail Service (5.5.2448.0) id ; Wed, 5 Jan 2000 15:39:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <0DF8FF84C95BD211A9210008C7A433610674819F@esekint290.ki.sw.ericsson.se> Date: Wed, 5 Jan 2000 15:39:50 +0100 Reply-To: "Martin Johnsson (ERA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Martin Johnsson (ERA)" Subject: Re: [MOBILE-IP] AAA functionality To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello Charlie and others, First of all, I think it is of importance that the procedures of authentication and authorization are something being specified by the AAA group as part of their charter. AAA may come up with different solutions for different technologies, e.g. one for MIP and another one for PPP (if they can be separated), or perhaps AAA defines something self-contained in which case the interoperation with other protocols should be defined. Just out from semantics, the AAA process is something different from MIP registration and should thus not be intermixed (actually the AAA process might result in that the MIP service is available to the user?). Do we know anything about what the AAA guys think about this? Cheers, /Martin -----Original Message----- From: Charles E. Perkins [mailto:charliep@IPRG.NOKIA.COM] Sent: den 4 januari 2000 18:11 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] AAA functionality Hello, There has been some discussion about how to let AAA authorize a mobile node's connectivity separately from the process of Mobile IP registration. The idea would be to give a mobile node a little unauthorized time while the AAA process goes to completion. It is expected that a Mobile IP registration will be faster than authentication/authorization by AAA. Suppose that the Mobile IP registration succeeds, and the AAA authentication fails. Then, one might expect that the Mobile IP registration should be terminated immediately without waiting for the registration lifetime to expire. Mobile IP does not currently have any mechanism to do this. I think the mobile node has to be notified that something went wrong. Thus, we need a way to send the notification to the mobile node. This could be a new Mobile IP message, or ICMP, or ... ? Any such message would have to be authenticated in some way that is credible to the mobile node. The alternative would be just to cut off service to the mobile node without notification, which seems rather draconian. Can anyone offer a good solution to enable this sort of parallel processing for mobile node registrations? Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 5 10:00: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 KAA06620 for ; Wed, 5 Jan 2000 10:00:19 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0E36FF00@standards.nortelnetworks.com>; Wed, 5 Jan 2000 9:48:44 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 106263 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jan 2000 09:47:18 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DAA0F8D0@standards.nortelnetworks.com>; Wed, 5 Jan 2000 9:47:18 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 5 Jan 2000 08:57:01 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Wed, 5 Jan 2000 09:56:52 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 5 Jan 2000 08:56:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF578D.1953017E" Message-ID: <9A9367D1556AD21182C40000F80930AB010BC17F@crchy28b.us.nortel.com> Date: Wed, 5 Jan 2000 08:56:49 -0600 Reply-To: Mohamed Khalil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohamed Khalil Subject: Re: [MOBILE-IP] Multiple IP addresses per NAI X-To: Pete McCann 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_01BF578D.1953017E Content-Type: text/plain; charset="ISO-8859-1" Hi Pete, > -----Original Message----- > From: Pete McCann [SMTP:mccap@research.bell-labs.com] > Sent: Tuesday, January 04, 2000 5:22 PM > To: Khalil, Mohamed [RICH2:IP15:EXCH] > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Multiple IP addresses per NAI > > > Mohamed Khalil (MK) writes: > > MK> The device id is actually an id which is offered by the ISP when > MK> the user obtained the service. It could be something like > MK> mci-phone-214-78-9898 or it could be an integer #. The User NAI > MK> and the device id will be used by the mobile agent to uniquely > MK> identify the device. The device could support multiple > MK> technologies but it is still have one device id. If the user's > MK> device needs to re-register because it has changed technology, it > MK> should use the same device id in the registration request. if the > MK> device has already assigned an IP by the home subnetwork, it will > MK> not be reassigned another IP because it has changed technology. I > MK> did not understand how this proposal will preclude handoff from > MK> one technology to another technology. > > Hi, Mohamed, > > I must have misunderstood your intention, then. Your extension had > these two fields: > > Sub-Type 1 ETHERNET_DEV. > 2 TDMA_DEV. > 3 CDMA_DEV. > > device parameters this section defines the device parameters > which is requested by the mobile node. this > section MAY be modified by the home agent > or foreign agent to match the current operating > capability of the network and the services > which is allowed for the user. The structure > of this section depends on the type of the device. > > device id It is the device identification. > example MCI-LAPTOP-193.193.193.20 > > > Since the Sub-Type gave the specific link-layer technology, I was > assuming that device parameters contained a link-layer address and > that this was used to distinguish sessions. I can see now that you > didn't actually say that. > > Still, this extension seems overly complicated to me. For one thing, > the HA needs to know the semantics of each Sub-Type to properly find > the device id (since device parameters is variable length). I just > don't think it's necessary to give any information about the > link-layer interface to solve the multiple-sessions-per-NAI problem. > All we need is one integer called a "session id". If you want to send > link-layer interface information, that could be accomplished with a > separate extension (note that there may be more than one session id > per interface! That's another reason not to couple these two things > together in one extension). [MK>] I think we are in agreement that the device id is something which should identify uniquely the device. I think to make the definition for device id more general we should allow the device id to be an integer or a string like the NAI. This device id could be for example the phone number for the device 972-678-9929. This could be represented as an integer or could be represented as a string which encode some more information about the device such as mci-cdma-972-678-9929. [MK>] Regarding the device parameter field I had in mind that this field will contain some parameters which are necessary to establish data channels between the mobile device (which might support multiple technologies) and the foreign subnetworks. I assumed that could be used in the future when we send the control signals such as registration request over a separate control channels and then we establish a data channel according to the parameters defined in the device parameter section. I think I was too futuristic when I have taken this assumption and sorry for the confusion this assumption caused. > -Pete > > ------_=_NextPart_001_01BF578D.1953017E Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] Multiple IP addresses per NAI

Hi Pete,

    -----Original Message-----
    From:   Pete McCann = [SMTP:mccap@research.bell-labs.com]
    Sent:   Tuesday, January 04, 2000 5:22 PM
    To:     Khalil, Mohamed [RICH2:IP15:EXCH]
    Cc:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: [MOBILE-IP] Multiple IP = addresses per NAI


    Mohamed Khalil (MK) writes:

    MK>  The device id is actually = an id which is offered by the ISP when
    MK> the user obtained the service. = It could be something like
    MK> mci-phone-214-78-9898 or it = could be an integer #. The User NAI
    MK> and the device id will be used = by the mobile agent to uniquely
    MK> identify the device. The = device could support multiple
    MK> technologies but it is still = have one device id. If the user's
    MK> device needs to re-register = because it has changed technology, it
    MK> should use the same device id = in the registration request. if the
    MK> device has already assigned an = IP by the home subnetwork, it will
    MK> not be reassigned another IP = because it has changed technology. I
    MK> did not understand how this = proposal will preclude handoff from
    MK> one technology to another = technology.

    Hi, Mohamed,

    I must have misunderstood your = intention, then.  Your extension had
    these two fields:

        = Sub-Type          &nbs= p;  1   ETHERNET_DEV.
             &nb= sp;           &nb= sp;   2   TDMA_DEV.
             &nb= sp;           &nb= sp;   3   CDMA_DEV.

        device = parameters  this section defines the device parameters
             &nb= sp;           &nb= sp; which is requested by the mobile node. this
             &nb= sp;           &nb= sp; section MAY be modified by the home agent
             &nb= sp;           &nb= sp; or foreign agent to match the current operating
             &nb= sp;           &nb= sp; capability of the network and the services
             &nb= sp;           &nb= sp; which is allowed for the user. The structure
             &nb= sp;           &nb= sp; of this section depends on the type of the device.

       device id  It is the = device identification.
             &nb= sp;    example MCI-LAPTOP-193.193.193.20


    Since the Sub-Type gave the specific = link-layer technology, I was
    assuming that device parameters = contained a link-layer address and
    that this was used to distinguish = sessions.  I can see now that you
    didn't actually say that.

    Still, this extension seems overly = complicated to me.  For one thing,
    the HA needs to know the semantics of = each Sub-Type to properly find
    the device id (since device = parameters is variable length).  I just
    don't think it's necessary to give = any information about the
    link-layer interface to solve the = multiple-sessions-per-NAI problem.
    All we need is one integer called a = "session id".  If you want to send
    link-layer interface information, = that could be accomplished with a
    separate extension (note that there = may be more than one session id
    per interface!  That's another = reason not to couple these two things
    together in one extension).
    [MK>]  I think we are in agreement = that the device id is something which should identify uniquely the = device. I think to make the definition for device id more general we = should allow the device id to be an integer or a string like the NAI. = This device id could be for example the  phone number  for = the device 972-678-9929. This could be represented as an integer or = could be represented as a string which encode some more information = about the device such as mci-cdma-972-678-9929.

    [MK>] Regarding the device parameter field I had in = mind that this field will contain some parameters which are necessary = to establish data channels between the mobile device (which might = support multiple technologies) and the foreign subnetworks. I assumed = that could be used in the future when we send the control signals such = as registration request over a separate control channels and then we = establish a data channel according to the parameters defined in the = device parameter section. I think I was too futuristic when I have = taken this assumption and sorry for the confusion this assumption = caused.

    -Pete


------_=_NextPart_001_01BF578D.1953017E-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 5 10:32: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 KAA07803 for ; Wed, 5 Jan 2000 10:32:24 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8AAF2CC0@standards.nortelnetworks.com>; Wed, 5 Jan 2000 10:20:51 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 106342 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jan 2000 10:19:46 -0500 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.637E8560@standards.nortelnetworks.com>; Wed, 5 Jan 2000 10:19:45 -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 RAA26486 for ; Wed, 5 Jan 2000 17:29:58 +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 RAA03488; Wed, 5 Jan 2000 17:29:24 +0200 (EET) Received: by esebh01nok with Internet Mail Service (5.5.2650.10) id ; Wed, 5 Jan 2000 17:29:14 +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, 5 Jan 2000 17:29:10 +0200 Reply-To: patrik.flykt@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrik Flykt Subject: Re: [MOBILE-IP] AAA functionality X-To: charliep@iprg.nokia.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, >be notified that something went wrong. Thus, we need a way to >send the notification to the mobile node. > >This could be a new Mobile IP message, or ICMP, or ... ? This is not only a problem of a parallell execution of both AAA and MIP, it seems to be more general than that. What if some AAA event occurs which forces the mobility binding to be terminated at the foreign agent ? It seems rather draconian just to cut off service since the mobile node may still hear the agent advertisements from the foreign agent and do nothing since it isn't aware of the termination. Is there any chance of defining a new Mobile IP message or to send a new binding reply denying the registration ? Regards, Patrik Flykt From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 5 10:38: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 KAA08143 for ; Wed, 5 Jan 2000 10:38:18 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.63FD5CE0@standards.nortelnetworks.com>; Wed, 5 Jan 2000 10:26:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 106340 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jan 2000 10:26:36 -0500 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F269B2F0@standards.nortelnetworks.com>; Wed, 5 Jan 2000 10:16: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 RAA19937 for ; Wed, 5 Jan 2000 17:26:54 +0200 (EET) Received: from loki.research.nokia.com (loki.research.nokia.com [172.21.33.76]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id RAA02217 for ; Wed, 5 Jan 2000 17:26:49 +0200 (EET) Received: from possu.research.nokia.com (possu.research.nokia.com [172.21.33.80]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id RAA16341 for ; Wed, 5 Jan 2000 17:26:30 +0200 (EET) Received: from localhost (asokan@localhost) by possu.research.nokia.com (8.9.1/8.9.1) with ESMTP id RAA07837 for ; Wed, 5 Jan 2000 17:26:29 +0200 (EET) X-Authentication-Warning: possu.research.nokia.com: asokan owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 5 Jan 2000 17:26:29 +0200 Reply-To: n.asokan@nokia.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "N. Asokan" Subject: Re: [MOBILE-IP] AAA functionality To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Steven Glass - Solaris Software wrote: > I don't think I'd be in favor of parallel AAA and MIP authentications where > the MN is allowed some short access time. I am assuming you mean only the first > registration with a FA would be allowed for a short time, otherwise the MN will > simply 'renew' every second to stay within that window. If a good parallel > mechanism came forward I might be in favor of that, but not where the MN has > some free time (figuratively, and literally). I see this as allowing a short > security violation on the grounds that it may not really be a security > violation. I think whether to allow free time or not is ultimately a policy issue. Seems to me that we shouldn't devise a mechanism that precludes that policy. A visited network that makes this policy decision (to support fast handoffs, or for whatever reason) can easily use its own local mechanisms to detect and prevent attacks like the above -- it is not necessary to standardize them. As we pointed out earlier, there can be other reasons for not bundling the AAA and MIP signalling: e.g., AAA and MIP home domains could be completely different and far apart. I too agree that there are other scenarios where a visited network may want to unilaterally terminate service: e.g., in the pre-paid access model when the pre-paid amount is used up. So it would be nice to have a clean way to inform MN when its registration is being revoked. Regards, - Asokan --- N. Asokan, Communication Systems Lab, Nokia Research Center, Helsinki From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 5 10:43: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 KAA08338 for ; Wed, 5 Jan 2000 10:43:30 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AD443680@standards.nortelnetworks.com>; Wed, 5 Jan 2000 10:28:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 106417 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jan 2000 10:27:53 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.85C4D2E0@standards.nortelnetworks.com>; Wed, 5 Jan 2000 10:27:52 -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 HAA18682; Wed, 5 Jan 2000 07:38:06 -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 HAA04723; Wed, 5 Jan 2000 07:38:05 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id HAA01750; Wed, 5 Jan 2000 07:37:58 -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: <200001051537.HAA01750@nasnfs.eng.sun.com> Date: Wed, 5 Jan 2000 07:35:21 -0800 Reply-To: pcalhoun@eng.sun.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] AAA functionality X-To: patrik.flykt@nokia.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit > > Hi, > >>Perhaps I am missing something, but I *really* don't see how the AAA >>and Mobile-IP requests can be done in parallel. If a requirement is >>that it must be possible to separate the two, then I would prefer to >>see that both requests are done sequentially, first AAA then Mobile-IP. >>This would remove many strange interactions, and would be a much cleaner >>approach. > >I suppose there is a requirement that AAA and MIP messages can be separated >(be it parallell or serial message sending). When you pay for access with >your credit card the authorization/accounting goes to the credit card >company's AAA server, while the Mobile IP messages go to your home agent. > >The sequential approach is extremely useful if the only case of using AAA >with MIP is to ensure that the provider of the foreign agent is able to >account for every second of foreign agent usage. However, the provider could >also be interested in allowing a short grace period to ensure that the >real-time applications used in the mobile node would experience the shortest >possible service disruption. I suppose the AAA processing will take at least >a couple of seconds and even longer when there are several brokers between >the visited and home domains. The grace period enables of course a >possibility of fraud, which the provider has to take into account. The ISDN world comes to mind when I read this. If you recall, people figured out how to send messages in-band in the D channel, and this was enough for them to get the message across. The result, no need to actually establish a call, just initiate a call and send the message in the request. This seems very similar. An MS could get connected with a bogus user-name and get access long enough to send an instant message to his/her home network. No fee necessary. I would be quite interested in hearing from the carriers on whether this is acceptable or not. >Minimizing fraud could be done for example by allowing the grace period only >to those who have visited the same provider's network earlier and have been >given a session key, as described in the "Minimal Latency Secure Hand-off" >draft. In the case of the Minimal Latency Security Handoff scheme, a visit to the AAA wouldn't even be necessary since the keying information is provided. This draft allows the MS to maintain the session keys for the FA, and the keys have an explicit life-time. So, if the MS calls within the expiration period, no visit to the AAA is necessary. There is also a third possibility when the provider is providing free >access for everyone without any accounting but with authorization. The >provider wants to be sure that the home AAA domain authorizes the mobile >node, i.e. it is not stolen, in the (for some reason) wrong domain, etc. This is done in the PPP world. No authentication, but accounting messages are maintained. Therefore, the AAA is never reached when access is requested. PatC > >Regards, > > Patrik From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 5 11:41: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 LAA10050 for ; Wed, 5 Jan 2000 11:41:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3B941F60@standards.nortelnetworks.com>; Wed, 5 Jan 2000 11:30:13 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 106594 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jan 2000 11:28:43 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.05AED200@standards.nortelnetworks.com>; Wed, 5 Jan 2000 11:28:43 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26966; Wed, 5 Jan 2000 09:38:46 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id IAA12723; Wed, 5 Jan 2000 08:38:46 -0800 (PST) Received: from onion (onion.East.Sun.COM [129.148.174.110]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA03759; Wed, 5 Jan 2000 08:38:45 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ENecI9NDoW7Lue+AXQkx7g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_36 SunOS 5.8 sun4u sparc Message-ID: <200001051638.IAA03759@jurassic.eng.sun.com> Date: Wed, 5 Jan 2000 11:38:49 -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] AAA functionality X-To: zhao@cs.stanford.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >Xinhua, So - no news is bad news? If the MN doesn't hear it's OK to continue within X seconds of getting the [first] registration reply, it MUST assume it's not OK to continue. What if that reply is delayed (we don't know how long they're "supposed to take", but the rule is likely to be 2x or 3x that long for the timeout), or what if the reply is lost [UDP], or the [TCP] reply needs to be retransmitted (which may mean renegotiated)? The MN will have to assume it's dead, but it wont know why, so it wont know how to correct the action. I see the need for different MIP and AAA path processing, but I don't think the MN should get an answer until it gets one it can live with for the duration of the registration lifetime. In this event, that means the FA passes the regreq [inside a AAA packet] to the Foreign AAA server, then that server passes AAA messages to the credit card company while the mip packets [still inside AAA packets] go to the home domain (to set up FA/MN keys, etc). The foreign AAA server waits until all AAA replies are received, then merges them into one response to the FA which relays it to the MN (or it can likely wait until the first 'no' comes back). >A mechanism to explicitly terminate a binding can potentially be useful >in the scenario when an FA needs to be turned down and allow another FA >in the same subnet to take over. Waiting for the mobile node to figure >this out by its own through the loss of FA "beacons" can take too long. >Is this what is in your mind for such a mechanism? Sure, though this case could be solved by 'resetting' the FA so it sends one becon with the busy bit set. That broadcasts to all MNs that it's been reset, but isn't servicing any more bindings. It would be useful, however, if an HA was going down... Cheers, Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 5 13:48: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 NAA13123 for ; Wed, 5 Jan 2000 13:48:25 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E42C00F0@standards.nortelnetworks.com>; Wed, 5 Jan 2000 13:36:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 106678 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jan 2000 13:35:31 -0500 Received: from mw.3com.com (149.112.20.3) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BC37E280@standards.nortelnetworks.com>; Wed, 5 Jan 2000 13:35:30 -0500 Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id MAA27235; Wed, 5 Jan 2000 12:44:46 -0600 (CST) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8625685D.00670899 ; Wed, 5 Jan 2000 12:45:24 -0600 X-Lotus-FromDomain: 3COM@3COM-MWGATE Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <8625685D.006706F5.00@mwgate02.mw.3com.com> Date: Wed, 5 Jan 2000 12:42:51 -0600 Reply-To: Yingchun Xu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yingchun Xu Subject: [MOBILE-IP] Cellular IP for Private Network Access To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM It seems that Cellular IP has limitation for Private Network Access. During private network access, conflicted Mobile Node IP addresses may be assigned which will cause the failure of IP packet forwarding. Tunneling Based Protocol for MicroMobility Management will not have the issue since MN IP packets are wrapped. Any comments? --Yingchun. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 5 14:24: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 OAA14021 for ; Wed, 5 Jan 2000 14:24:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F614DDA0@standards.nortelnetworks.com>; Wed, 5 Jan 2000 14:12:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 106828 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jan 2000 14:11:42 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C86B4290@standards.nortelnetworks.com>; Wed, 5 Jan 2000 14:11: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 LAA27956; Wed, 5 Jan 2000 11:21:57 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id LAA27295; Wed, 5 Jan 2000 11:21:53 -0800 X-Virus-Scanned: Wed, 5 Jan 2000 11:21:53 -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) xma027124; Wed, 5 Jan 00 11:21:48 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <200001042003.MAA19380@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <387399CC.613C5C50@iprg.nokia.com> Date: Wed, 5 Jan 2000 11:21:48 -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] RFC2002bis comments X-cc: Alper Yegin To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, I am forwarding some comments from Alper Yegin to the list for further clarification. I'll put in my $.02, but in every case I do not have any strong opinion one way or the other. Alper Yegin wrote: > [1] > > 3.4. Registration Reply > ... > UDP fields: > > Source Port > > Destination Port Copied from the source port of the > corresponding Registration Request > (Section 3.7.1). > > Why source port is a variable, why not 434? Forcing it to be 434 would make it > *possible* to recognize this packet as MIP signalling on the wire. How about > even saying that MN should use port 434? This seems like a perpetual unsolved design issue. Some people say that having the source port variable enables better multi-threaded design. Some say not. I'll change it if people say to change it, but I don't think it should be changed unless there is more support. > [2] > > 3.1. Registration Overview > ... > The registration messages defined in Sections 3.3 and 3.4 use the > User Datagram Protocol (UDP) [17]. A nonzero UDP checksum SHOULD be > included in the header, and MUST be checked by the recipient. > > ...and later: > > 3.7.2.1. Validity Checks > > Registration Requests with an invalid, non-zero UDP checksum MUST be > silently discarded. > > It's not very clear if a UDP chekcsum 0 is accepted or not. I agree it's not clear. I can add text that clarifies it. One possibility would be to let the foreign agent accept such packets, and to let action by the mobile node and home agent be defined by whatever is in the Mobility Security Association between them. > [3] > > 4.6. ARP, Proxy ARP, and Gratuitous ARP > ... > Finally, while the > mobile node is away from home, it MUST NOT reply to ARP Requests > in which the target IP address is its own home address, unless the > ARP Request is sent by a foreign agent with which the mobile node > is attempting to register or a foreign agent with which the mobile > node has an unexpired registration. > > But we know that the FA MUST NOT send ARP. So, this is contradicting. Which part should be changed? > Alper Yegin > Internet Engineering > Sun Microsystems, Inc. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 5 18:40: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 SAA18243 for ; Wed, 5 Jan 2000 18: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.C886AF70@standards.nortelnetworks.com>; Wed, 5 Jan 2000 18:29:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 107110 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jan 2000 18:27:45 -0500 Received: from servo.qualcomm.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8F556B60@standards.nortelnetworks.com>; Wed, 5 Jan 2000 18:27:45 -0500 Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.14) id PAA23119; Wed, 5 Jan 2000 15:38:02 -0800 (PST) Message-ID: <200001052338.PAA23119@servo.qualcomm.com> Date: Wed, 5 Jan 2000 15:38:02 -0800 Reply-To: Phil Karn Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Phil Karn Subject: Re: [MOBILE-IP] Cellular IP for Private Network Access X-To: Yingchun_Xu@MW.3COM.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <8625685D.006706F5.00@mwgate02.mw.3com.com> (message from Yingchun Xu on Wed, 5 Jan 2000 12:42:51 -0600) >conflicted Mobile Node IP addresses may be assigned which will cause the failure > of IP packet forwarding. I don't know what this means. I do know from personal observation how Sprint PCS's wireless web service is set up, though. PPP gives you an address on network 10, and routes you through a bidirectional NAT in Kansas City. I.e., the NAT assigns you a routable address and translates between that and your network 10 address without any port translation. This forces you to run Mobile IP with tunneling in both directions if you want to give your mobile computer a predictable routable address. Is this what you had in mind? Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 5 19:44: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 TAA18847 for ; Wed, 5 Jan 2000 19:43:56 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9C4E6890@standards.nortelnetworks.com>; Wed, 5 Jan 2000 19:32:32 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 107250 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jan 2000 19:31:27 -0500 Received: from smtpgw2.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.753F04D0@standards.nortelnetworks.com>; Wed, 5 Jan 2000 19:31:26 -0500 Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw2.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id SAA12618; Wed, 5 Jan 2000 18:41:41 -0600 (CST) Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jan 2000 18:41:41 -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, 5 Jan 2000 18:41:38 -0600 Reply-To: "Lipford, Mark" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lipford, Mark" Subject: Re: [MOBILE-IP] AAA functionality X-To: patrik.flykt@NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM As a wireless carrier interested in deploying a MIP solution I don't feel comfortable allowing a "grace" period. We have received many request for potential customers on how quickly they could send a "short burst" of data through our network for particular applications (i.e. telemetry and telematics are two big ones). If we allow users a grace period they could potentially run their business without getting properly authorized. While there are possibly other ways to block this usage AAA is the best solution. -----Original Message----- From: Patrik Flykt [mailto:patrik.flykt@NOKIA.COM] Sent: Wednesday, January 05, 2000 2:40 AM To: MOBILE-IP@standards.nortelnetworks.com Subject: Re: [MOBILE-IP] AAA functionality Hi, >Perhaps I am missing something, but I *really* don't see how the AAA >and Mobile-IP requests can be done in parallel. If a requirement is >that it must be possible to separate the two, then I would prefer to >see that both requests are done sequentially, first AAA then Mobile-IP. >This would remove many strange interactions, and would be a much cleaner >approach. I suppose there is a requirement that AAA and MIP messages can be separated (be it parallell or serial message sending). When you pay for access with your credit card the authorization/accounting goes to the credit card company's AAA server, while the Mobile IP messages go to your home agent. The sequential approach is extremely useful if the only case of using AAA with MIP is to ensure that the provider of the foreign agent is able to account for every second of foreign agent usage. However, the provider could also be interested in allowing a short grace period to ensure that the real-time applications used in the mobile node would experience the shortest possible service disruption. I suppose the AAA processing will take at least a couple of seconds and even longer when there are several brokers between the visited and home domains. The grace period enables of course a possibility of fraud, which the provider has to take into account. Minimizing fraud could be done for example by allowing the grace period only to those who have visited the same provider's network earlier and have been given a session key, as described in the "Minimal Latency Secure Hand-off" draft. There is also a third possibility when the provider is providing free access for everyone without any accounting but with authorization. The provider wants to be sure that the home AAA domain authorizes the mobile node, i.e. it is not stolen, in the (for some reason) wrong domain, etc. Regards, Patrik From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 5 20:30: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 UAA19233 for ; Wed, 5 Jan 2000 20:30:45 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.31E10FB0@standards.nortelnetworks.com>; Wed, 5 Jan 2000 20:19:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 107343 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jan 2000 20:18:06 -0500 Received: from servo.qualcomm.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F9948650@standards.nortelnetworks.com>; Wed, 5 Jan 2000 20:18:05 -0500 Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.14) id RAA24773; Wed, 5 Jan 2000 17:28:23 -0800 (PST) Message-ID: <200001060128.RAA24773@servo.qualcomm.com> Date: Wed, 5 Jan 2000 17:28:23 -0800 Reply-To: Phil Karn Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Phil Karn Subject: Re: [MOBILE-IP] AAA functionality X-To: MLipfo01@SPRINTSPECTRUM.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: (MLipfo01@SPRINTSPECTRUM.COM) >telematics are two big ones). If we allow users a grace period they could >potentially run their business without getting properly authorized. While >there are possibly other ways to block this usage AAA is the best solution. Why is this an issue for you? In a properly layered network, Mobile IP would be outside the scope of the wireless carrier. It would exist as a co-located FA on the mobile user's computer and as a HA on the user's home network, e.g., at his residence or business. That's if it even existed at all, since MIP would be a user choice, and most mobile users given the choice wouldn't need it in the first place. You would just charge for the user's generic internet access service, and the behavior of MIP (or even its existence) wouldn't matter to you. It would all just be billable user data to you. Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 6 00:47: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 AAA23364 for ; Thu, 6 Jan 2000 00:47:25 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.032D9B60@standards.nortelnetworks.com>; Thu, 6 Jan 2000 0:36:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 107632 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jan 2000 00:34:34 -0500 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.680BAB00@standards.nortelnetworks.com>; Thu, 6 Jan 2000 0:24:33 -0500 Received: from openworld.co.uk (post.openworld.co.uk [194.207.107.3]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id XAA06225 for ; Wed, 5 Jan 2000 23:34:51 -0600 (CST) Received: from safe (171.214.140.7) by openworld.co.uk with SMTP (Eudora Internet Mail Server 2.2.2); Thu, 6 Jan 2000 04:05:26 +0000 Message-ID: <1264991000-35207076@openworld.co.uk> Date: Thu, 6 Jan 2000 04:04:56 +0000 Reply-To: terri@AUSI.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: terri@AUSI.COM Subject: [MOBILE-IP] Great work at home opportunity - lifetime monthly income 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:lifetimecash7@newmail.net For removal, mailto:unsubscribe104@newmail.net From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 6 03:15: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 DAA06044 for ; Thu, 6 Jan 2000 03:15:51 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B8EFD210@standards.nortelnetworks.com>; Thu, 6 Jan 2000 3:04:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 107781 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jan 2000 03:03:30 -0500 Received: from sunny.recin.com (206.171.92.254) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.36917360@standards.nortelnetworks.com>; Thu, 6 Jan 2000 2:53:30 -0500 Received: from [206.171.92.254] ([203.197.182.193]) by sunny.recin.com (Netscape Mail Server v2.0) with SMTP id AAF26179 for ; Thu, 6 Jan 2000 00:04:40 -0700 X-mailserver: Sent using the PostMaster (v3.1.5) X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: Date: Thu, 6 Jan 2000 11:22:35 +0500 Reply-To: kevin@sz.huawei.com.cn Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: kevin Organization: Huawei Technology Subject: [MOBILE-IP] Too frequent Registration Request To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit In RFC 2002 Section 3.6.3, it say: The minimum time between Registration Requests MUST NOT be less than 1 second. Should FA discard the second packet if FA receive the Registration Request from the same MN within 1 second? -------------------------------------------------------------- HUAWEI (BANGALORE) BUSINESS OPERATION, BANGALORE, INDIA From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 6 06:51: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 GAA07292 for ; Thu, 6 Jan 2000 06:51:57 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EDCD29B0@standards.nortelnetworks.com>; Thu, 6 Jan 2000 6:40:32 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 107952 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jan 2000 06:39:29 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.62852570@standards.nortelnetworks.com>; Thu, 6 Jan 2000 6:29:29 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06998; Thu, 6 Jan 2000 06:39:53 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200001061139.GAA06998@ietf.org> Date: Thu, 6 Jan 2000 06:39:52 -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-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 : Mobile IP Extensions Rationalization (MIER) Author(s) : M. Khalil, R. Narayanan, H. Akhtar, E. Qaddoura Filename : draft-ietf-mobileip-mier-00.txt Pages : 7 Date : 05-Jan-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-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-mier-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-mier-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: <20000105082547.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-mier-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-mier-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000105082547.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 6 06:57: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 GAA07423 for ; Thu, 6 Jan 2000 06:57:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.368271B0@standards.nortelnetworks.com>; Thu, 6 Jan 2000 6:42:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 107954 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jan 2000 06:40:44 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8F262A20@standards.nortelnetworks.com>; Thu, 6 Jan 2000 6:30:43 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07147; Thu, 6 Jan 2000 06:41:09 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200001061141.GAA07147@ietf.org> Date: Thu, 6 Jan 2000 06:41:08 -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-mn-nai-06.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 Network Access Identifier Extension for IPv4 Author(s) : P. Calhoun, C. Perkins Filename : draft-ietf-mobileip-mn-nai-06.txt Pages : 7 Date : 05-Jan-00 AAA servers are in use within the Internet today to provide authentication and authorization services for dial-up computers. Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI). Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request. This draft also updates RFC2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mn-nai-06.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-mn-nai-06.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-mn-nai-06.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: <20000105151820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-mn-nai-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-mn-nai-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000105151820.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 6 10:19: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 KAA14279 for ; Thu, 6 Jan 2000 10:18:59 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C357B160@standards.nortelnetworks.com>; Thu, 6 Jan 2000 10:06:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 108220 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jan 2000 10:06:18 -0500 Received: from ns.gte.com (132.197.8.19) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.46E5BDD0@standards.nortelnetworks.com>; Thu, 6 Jan 2000 9:56:18 -0500 Received: from exc-atlanta1.mobilnet.gte.com ([167.163.53.152]) by ns.gte.com (8.9.1/8.9.1) with ESMTP id KAA14853 for ; Thu, 6 Jan 2000 10:06:40 -0500 (EST) Received: by exc-atlanta1.mobilnet.gte.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jan 2000 10:05:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: Date: Thu, 6 Jan 2000 10:05:37 -0500 Reply-To: "Munson, Mark A." Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Munson, Mark A." Subject: Re: [MOBILE-IP] AAA functionality To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >Pat Calhoun wrote: >The ISDN world comes to mind when I read this. If you recall, people figured >out how to send messages in-band in the D channel, and this was enough for >them to get the message across. The result, no need to actually establish a >call, just initiate a call and send the message in the request. >This seems very similar. An MS could get connected with a bogus user-name and >get access long enough to send an instant message to his/her home network. >No fee necessary. I would be quite interested in hearing from the carriers >on whether this is acceptable or not. This is something that we have discussed within TR-45.6 and have concluded (at least the carriers have) that this it is not an acceptable design to return a successful RR to the MS until both the AAA and MIP registrations have completed successfully. The fraud risks and state complexities are too much for a fee based system. It would appear that tightly tying the AAA and MIP registration message flows together provides the cleanest solution in this case. Regards, Mark From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 6 10:32: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 KAA14522 for ; Thu, 6 Jan 2000 10:32:21 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BB245190@standards.nortelnetworks.com>; Thu, 6 Jan 2000 10:21:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 108295 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jan 2000 10: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.7B374470@standards.nortelnetworks.com>; Thu, 6 Jan 2000 10:19:14 -0500 Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id JAA10728; Thu, 6 Jan 2000 09:29:23 -0600 (CST) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8625685E.00552561 ; Thu, 6 Jan 2000 09:30:01 -0600 X-Lotus-FromDomain: 3COM@3COM-MWGATE Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <8625685E.00552375.00@mwgate02.mw.3com.com> Date: Thu, 6 Jan 2000 09:27:26 -0600 Reply-To: Yingchun Xu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yingchun Xu Subject: Re: [MOBILE-IP] Cellular IP for Private Network Access X-To: Phil Karn To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Phil, Sprint network does not have Cellular IP. In Cellular IP draft, no PPP is used. Between GW and BS, Mobile Host IP addresses are used for packet routing. Cellular IP nodes maintain Route Cache. The problem occurs when two Mobile Hosts accessing different private networks get assigned the same IP address at WAN level. In this case, Cellular IP node will have problem for IP packet routing based on Mobile Host IP address. --Yingchun. Phil Karn on 01/05/2000 05:38:02 PM Please respond to Phil Karn Sent by: Phil Karn To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM cc: (Yingchun Xu/MW/US/3Com) Subject: Re: [MOBILE-IP] Cellular IP for Private Network Access >conflicted Mobile Node IP addresses may be assigned which will cause the failure > of IP packet forwarding. I don't know what this means. I do know from personal observation how Sprint PCS's wireless web service is set up, though. PPP gives you an address on network 10, and routes you through a bidirectional NAT in Kansas City. I.e., the NAT assigns you a routable address and translates between that and your network 10 address without any port translation. This forces you to run Mobile IP with tunneling in both directions if you want to give your mobile computer a predictable routable address. Is this what you had in mind? Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 6 11:03: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 LAA15115 for ; Thu, 6 Jan 2000 11:03:28 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.121912C0@standards.nortelnetworks.com>; Thu, 6 Jan 2000 10:52:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 108341 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jan 2000 10:50:10 -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.6777D960@standards.nortelnetworks.com>; Thu, 6 Jan 2000 10:40:09 -0500 Received: from lt.eth.ericsson.se (lt.eth.ericsson.se [164.48.158.205]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id QAA11676; Thu, 6 Jan 2000 16:50:31 +0100 (MET) Received: from eth.ericsson.se by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA28765; Thu, 6 Jan 2000 16:50:29 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: Hungarian, hu, en MIME-Version: 1.0 References: <8625685D.006706F5.00@mwgate02.mw.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3874B9C4.A6364CAE@eth.ericsson.se> Date: Thu, 6 Jan 2000 16:50:28 +0100 Reply-To: Zoltan.Turanyi@ETH.ERICSSON.SE Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Zoltan Richard Turanyi Organization: Ericsson TrafficLab Subject: Re: [MOBILE-IP] Cellular IP for Private Network Access X-To: Yingchun Xu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Yingchun Xu wrote: > > It seems that Cellular IP has limitation for Private Network Access. During > private network access, > conflicted Mobile Node IP addresses may be assigned which will cause the failure > of IP packet forwarding. > Tunneling Based Protocol for MicroMobility Management will not have the issue > since MN IP packets are wrapped. When two mobile hosts with private home addresses move into the same network, possibly encapsulation is the only plausible way to prevent an address clash. Tunneling can also be used in a Cellular IP network for hosts that have private addresses. One advantage of Cellular IP is that you have to use encapsulation only in such cases. When you talk about "Tunneling Based Protocol for MicroMobility Management" do you refer to a specific protocol or just tunneling based approaches in general? /Zoltan From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 6 11:40: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 LAA15812 for ; Thu, 6 Jan 2000 11:40:40 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.42C28E10@standards.nortelnetworks.com>; Thu, 6 Jan 2000 11:29:14 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 108444 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jan 2000 11:27:41 -0500 Received: from mw.3com.com (149.112.20.3) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0B137D30@standards.nortelnetworks.com>; Thu, 6 Jan 2000 11:27:41 -0500 Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id KAA15494; Thu, 6 Jan 2000 10:37:46 -0600 (CST) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8625685E.005B6A3A ; Thu, 6 Jan 2000 10:38:29 -0600 X-Lotus-FromDomain: 3COM@3COM-MWGATE Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <8625685E.005B697A.00@mwgate02.mw.3com.com> Date: Thu, 6 Jan 2000 10:35:52 -0600 Reply-To: Yingchun Xu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yingchun Xu Subject: Re: [MOBILE-IP] Cellular IP for Private Network Access X-To: Zoltan.Turanyi@ETH.ERICSSON.SE To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Yingchun Xu wrote: >> >> It seems that Cellular IP has limitation for Private Network Access. During >> private network access, >> conflicted Mobile Node IP addresses may be assigned which will cause the failure >> of IP packet forwarding. >> Tunneling Based Protocol for MicroMobility Management will not have the issue >> since MN IP packets are wrapped. > When two mobile hosts with private home addresses move into the same > network, possibly encapsulation is the only plausible way to prevent an > address clash. Tunneling can also be used in a Cellular IP network for > hosts that have private addresses. One advantage of Cellular IP is that > you have to use encapsulation only in such cases. Encapsulation may not be a disadvantage if it does not across air link. > When you talk about "Tunneling Based Protocol for MicroMobility > Management" do you refer to a specific protocol or just tunneling based > approaches in general? I meant tunneling based approaches in general. Can you point out how this is done and where it is described in "Cellular IP draft"? It seems to me that a unified approach for handling both public and private network access is prefered. --Yingchun. /Zoltan From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 6 11:58: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 LAA16357 for ; Thu, 6 Jan 2000 11:58:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C97AB480@standards.nortelnetworks.com>; Thu, 6 Jan 2000 11:47:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 108504 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jan 2000 11:46:18 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A4A08040@standards.nortelnetworks.com>; Thu, 6 Jan 2000 11:46:17 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03982; Thu, 6 Jan 2000 09:56:37 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id IAA29804; Thu, 6 Jan 2000 08:56:35 -0800 (PST) Received: from onion (onion.East.Sun.COM [129.148.174.110]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA23570; Thu, 6 Jan 2000 08:56:33 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0CsSS90EvvWRsagGfd9vzA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_36 SunOS 5.8 sun4u sparc Message-ID: <200001061656.IAA23570@jurassic.eng.sun.com> Date: Thu, 6 Jan 2000 11:56:38 -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] Too frequent Registration Request X-To: kevin@sz.huawei.com.cn X-cc: charliep@iprg.nokia.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >In RFC 2002 Section 3.6.3, it say: > >The minimum time between Registration Requests MUST NOT be less than 1 second. > >Should FA discard the second packet if FA receive the Registration Request from >the same MN within 1 second? As I recall, from various places in the document, it says a couple of related things; it's a loop-hole in the spec. Sorry, I don't have the time to reference them right now, but thanks for asking, as I meant to send this off to Charlie a long time ago. According to 2002: If the FA rejects the registration request, it MUST NOT send a reply to the MN more often than 1/s. Nothing is said in the case of the FA accepting the registration request; it can simply forward it to the HA. Nothing is said about how often it can do this. The implication, and I feel the spirit of 2002, though, is the FA should reject any registrtaion request that is generated by a MN more often than 1/s. Nothing is said about the HA generating more than 1 reply/s. This should be allowed because a MN may be registering simultaneous bindings, or the FA could have reset itself. The FA can then forward the HA's reply, of which there can be more than 1/s. I'm hoping this is resolved in 2002-bis, since a malicious node can pretend to be a MN and flood two networks this way using FAs that behave to spec. To answer your question, though, I would say a responsible FA should should ignore a second registration request appearing from the same MN within 1 second. Analogously, a HA that supports simultaneous bindings should be able to ignore registration requests from the same MN through the same FA that arrive more often than 1/second (network timing issues aside). A HA that does not support simultaneous bindings should be able to ignore registration requests from the same MN regardless of FA that arrive more often the 1/second. Cheers, Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 6 12:25: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 MAA17308 for ; Thu, 6 Jan 2000 12:25:35 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.95791E70@standards.nortelnetworks.com>; Thu, 6 Jan 2000 12:14:30 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 108613 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jan 2000 12:13:28 -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.0A9ED020@standards.nortelnetworks.com>; Thu, 6 Jan 2000 12:03:27 -0500 Received: from lt.eth.ericsson.se (lt.eth.ericsson.se [164.48.158.205]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id SAA27073; Thu, 6 Jan 2000 18:13:49 +0100 (MET) Received: from eth.ericsson.se by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id SAA01391; Thu, 6 Jan 2000 18:13:47 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: Hungarian, hu, en MIME-Version: 1.0 References: <8625685E.005B697A.00@mwgate02.mw.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3874CD4B.3F4D9C4D@eth.ericsson.se> Date: Thu, 6 Jan 2000 18:13:47 +0100 Reply-To: Zoltan.Turanyi@ETH.ERICSSON.SE Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Zoltan Richard Turanyi Organization: Ericsson TrafficLab Subject: Re: [MOBILE-IP] Cellular IP for Private Network Access X-To: Yingchun Xu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Yingchun Xu wrote: > Encapsulation may not be a disadvantage if it does not across air link. It may not. But, the fact that something is not disadvantageous is no reason to use it. > I meant tunneling based approaches in general. > Can you point out how this is done and where it is described in "Cellular IP > draft"? It is not included in this version of Cellular IP. > It seems to me that a unified approach for handling both public and private > network access is prefered. I do not think that the tunneling of packets containing private addresses breaks the "uniform approach" of Cellular IP. Besides, public and private addresses are handled differently in fixed networks as well. /Zoltan -- Zoltan Richard Turanyi Research Fellow, Ericsson Hungary Traffic Analysis and Network Performance Lab From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 6 19:31: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 TAA25843 for ; Thu, 6 Jan 2000 19:31:52 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1DD25AD0@standards.nortelnetworks.com>; Thu, 6 Jan 2000 19:20:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 109617 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jan 2000 19:19:23 -0500 Received: from mullian.ee.mu.OZ.AU by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8A321B90@standards.nortelnetworks.com>; Thu, 6 Jan 2000 19:09:22 -0500 Received: from ee.mu.oz.au (cell.ee.mu.OZ.AU [128.250.76.149]) by mullian.ee.mu.OZ.AU (8.9.1a/8.9.1) with ESMTP id LAA27373; Fri, 7 Jan 2000 11:19:36 +1100 (EST) X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <3B9AA5E712DCD011AAD500609770A0E920382F@tokyo.ttd.neceur.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38753118.A44F43F5@ee.mu.oz.au> Date: Fri, 7 Jan 2000 11:19:36 +1100 Reply-To: Rami Gabriel Mukhtar Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Rami Gabriel Mukhtar Subject: Re: [MOBILE-IP] 3G Mobile Architectures X-To: "BINAR, Simon" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "BINAR, Simon" wrote: > > Here is now my question: which advantage is there to have IP totally > completely utterly all-embracing in the wireless network as opposed to > have it deployed only in the core network? My first guess is that there > might be advantages in the area of network management (but I'm not an NM > expert, therefore, I'd like to get comments from more knowledgeable > people in this area). I think that arguments such as "the IETF approach > is more elegant" is not valid, since, by the end of the day, we also > have to think about business... > Simon, these are my thoughts... Bringing IP addresses out to the base station has the advantage of making the network far more flexible. Although currently cellular networks are large proprietary networks, they may not be in the future. In the future as base station density increases and access to IP networks becomes more predominant, it may be cheaper for a Telco to connect additional base stations to an existing IP network with a SLA rather than run another leased line to the base station. In order for this to be practical, base stations need to be IP addressable. From another perspective, operators may wish to connect small clusters of base stations directly to the internet. For example a company may wish to connect a single private cell to the internet to enable network access within a building without incurring expensive Telco charges. If the base station is IP addressable this can be done without having to construct a core network. Hope this helps, Regards, -- Rami Mukhtar ___________________________________________ Post Graduate Student Telecommunications Group The University of Melbourne Ph: (03) 9344-9207 WWW: http://www.ee.mu.oz.au/pgrad/rgmukht ___________________________________________ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 01:05: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 BAA00487 for ; Fri, 7 Jan 2000 01:05:05 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9A85CAC0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 0:53:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 109898 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 00:51:56 -0500 Received: from smtpgw2.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6544FAC0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 0:51:56 -0500 Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw2.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id AAA02915; Fri, 7 Jan 2000 00:02:19 -0600 (CST) Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jan 2000 00:02:19 -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: Fri, 7 Jan 2000 00:02:16 -0600 Reply-To: "Lipford, Mark" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lipford, Mark" Subject: Re: [MOBILE-IP] AAA functionality X-To: Phil Karn To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Karl, Don't want to spend a lot of time discussing this, I do agree that co-located FA is one implementation that will work. But only supporting a single implementation is short-sighted from a service providers perspective. It is also an issue for the carrier that wants to be more then a simple "pipe" to transport data over. I do agree that you are entitled to your thoughts and opinions on what a carrier needs to offer, but as a carrier that is listening to many potential data customers we need to larger view. Regards -----Original Message----- From: Phil Karn [mailto:karn@qualcomm.com] Sent: Wednesday, January 05, 2000 7:28 PM To: MLipfo01@SPRINTSPECTRUM.COM Cc: MOBILE-IP@standards.nortelnetworks.com; karn@qualcomm.com Subject: Re: [MOBILE-IP] AAA functionality >telematics are two big ones). If we allow users a grace period they could >potentially run their business without getting properly authorized. While >there are possibly other ways to block this usage AAA is the best solution. Why is this an issue for you? In a properly layered network, Mobile IP would be outside the scope of the wireless carrier. It would exist as a co-located FA on the mobile user's computer and as a HA on the user's home network, e.g., at his residence or business. That's if it even existed at all, since MIP would be a user choice, and most mobile users given the choice wouldn't need it in the first place. You would just charge for the user's generic internet access service, and the behavior of MIP (or even its existence) wouldn't matter to you. It would all just be billable user data to you. Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 01:08: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 BAA00490 for ; Fri, 7 Jan 2000 01:05:06 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9ACD5B10@standards.nortelnetworks.com>; Fri, 7 Jan 2000 0:53:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 109902 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 00:52:04 -0500 Received: from smtpgw2.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.69E84410@standards.nortelnetworks.com>; Fri, 7 Jan 2000 0:52:03 -0500 Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw2.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id AAA02927; Fri, 7 Jan 2000 00:02:27 -0600 (CST) Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jan 2000 00:02:27 -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: Fri, 7 Jan 2000 00:02:26 -0600 Reply-To: "Lipford, Mark" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lipford, Mark" Subject: Re: [MOBILE-IP] Cellular IP for Private Network Access X-To: Yingchun Xu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sprint PCS would ask that the design of our network not be discussed over ANY public mail list. There are issues with NDA that we do not want to have remind these companies of. Please stop this thread with this email! Thank you -----Original Message----- From: Yingchun Xu [mailto:Yingchun_Xu@MW.3COM.COM] Sent: Thursday, January 06, 2000 9:27 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Cellular IP for Private Network Access Phil, Sprint network does not have Cellular IP. In Cellular IP draft, no PPP is used. Between GW and BS, Mobile Host IP addresses are used for packet routing. Cellular IP nodes maintain Route Cache. The problem occurs when two Mobile Hosts accessing different private networks get assigned the same IP address at WAN level. In this case, Cellular IP node will have problem for IP packet routing based on Mobile Host IP address. --Yingchun. Phil Karn on 01/05/2000 05:38:02 PM Please respond to Phil Karn Sent by: Phil Karn To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM cc: (Yingchun Xu/MW/US/3Com) Subject: Re: [MOBILE-IP] Cellular IP for Private Network Access >conflicted Mobile Node IP addresses may be assigned which will cause the failure > of IP packet forwarding. I don't know what this means. I do know from personal observation how Sprint PCS's wireless web service is set up, though. PPP gives you an address on network 10, and routes you through a bidirectional NAT in Kansas City. I.e., the NAT assigns you a routable address and translates between that and your network 10 address without any port translation. This forces you to run Mobile IP with tunneling in both directions if you want to give your mobile computer a predictable routable address. Is this what you had in mind? Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 03:20: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 DAA12990 for ; Fri, 7 Jan 2000 03:20:12 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7E35BC50@standards.nortelnetworks.com>; Fri, 7 Jan 2000 3:08:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 110052 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 03:06:47 -0500 Received: from monitor.internaut.com (206.253.202.42) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3AFCB880@standards.nortelnetworks.com>; Fri, 7 Jan 2000 3:06:45 -0500 Received: from vaiobean ([204.57.137.45]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id AAA33864; Fri, 7 Jan 2000 00:08:35 -0800 (PST) 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: <008801bf58e7$b640e860$2d8939cc@ntdev.microsoft.com> Date: Fri, 7 Jan 2000 00:17:59 -0800 Reply-To: aboba@internaut.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Bernard Aboba Subject: Re: [MOBILE-IP] AAA functionality X-To: "Martin Johnsson (ERA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <0DF8FF84C95BD211A9210008C7A433610674819F@esekint290.ki.sw.ericsson.se> Content-Transfer-Encoding: 7bit >AAA may come up with different solutions for different technologies, e.g. one for MIP and >another one for PPP (if they can be separated) The charter of the AAA WG is to define requirements for a AAA protocol based on inputs from the WGs that would use that protocol. It is explicitly *not* in the AAA WG charter to define how Mobile IP will use AAA. That is the job of the Mobile IP WG, which is best qualified for that task. Among other things, this ensures that issues of Mobile IP architecture are discussed within the WG that best understands Mobile IP. Bernard Aboba Co-Chair, AAA WG From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 03:34: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 DAA13073 for ; Fri, 7 Jan 2000 03:34:51 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.99AB63C0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 3:23:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 110113 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 03:22:10 -0500 Received: from servo.qualcomm.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.61B73390@standards.nortelnetworks.com>; Fri, 7 Jan 2000 3:22:09 -0500 Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.14) id AAA18299; Fri, 7 Jan 2000 00:32:31 -0800 (PST) Message-ID: <200001070832.AAA18299@servo.qualcomm.com> Date: Fri, 7 Jan 2000 00:32:31 -0800 Reply-To: Phil Karn Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Phil Karn Subject: Re: [MOBILE-IP] Cellular IP for Private Network Access X-To: MLipfo01@SPRINTSPECTRUM.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: (MLipfo01@SPRINTSPECTRUM.COM) >Sprint PCS would ask that the design of our network not be discussed over >ANY public mail list. There are issues with NDA that we do not want to have >remind these companies of. Please stop this thread with this email! My description of Sprint PCS's packet data service was based totally on my personal observations using my personally-owned phone, a data cable and a laptop running Linux. ANY Sprint PCS user who knows how to use standard Linux/UNIX networking tools such as pppd, netstat and traceroute can easily discern the very same information in a few minutes. It can hardly be considered proprietary. If my description is no longer accurate, I would appreciate any corrections you might make. I stopped using the service when my first bill gave me sticker shock. Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 03:49: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 DAA13125 for ; Fri, 7 Jan 2000 03:49:00 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.91484160@standards.nortelnetworks.com>; Fri, 7 Jan 2000 3:37:48 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 110171 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 03:36:27 -0500 Received: from servo.qualcomm.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.60A38EC0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 3:36:26 -0500 Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.14) id AAA18384; Fri, 7 Jan 2000 00:46:49 -0800 (PST) Message-ID: <200001070846.AAA18384@servo.qualcomm.com> Date: Fri, 7 Jan 2000 00:46:49 -0800 Reply-To: Phil Karn Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Phil Karn Subject: Re: [MOBILE-IP] AAA functionality X-To: MLipfo01@SPRINTSPECTRUM.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: (MLipfo01@SPRINTSPECTRUM.COM) >It is also an issue for the carrier that wants to be more then a simple >"pipe" to transport data over. I do agree that you are entitled to your Ah, here we reach the crux of the issue. Speaking as a potential user of your service, an IP "pipe" is all I want from you, and it's all I'm willing to pay for. And it's not just me. I know I speak for many prospective users (the ones who understand the issues, anyway) and for those who conceived the Internet architecture. Go read the classic paper by Saltzer, Reed & Clark, "End-to-End Arguments in System Design" (http://people.qualcomm.com/karn/library.html). This one paper is so fundamental that I've often thought prospective IETFers (especially those affiliated with telcos) should be required to read it and pass a test before they can participate in any IETF working group. :-) Unfortunately, many carriers (not just Sprint) see no glamor in being pipe providers, even though they can make plenty of money if they do it well and at reasonable cost. It's a widespread problem that also afflicts cable modem networks, for example. Fortunately, my own cable modem provider is proving themselves so incompetent at operating all these superfluous network functions that they're being forced to eliminate them just to keep the packets flowing. Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 04:30: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 EAA13350 for ; Fri, 7 Jan 2000 04:30:16 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4EF6F6C0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 4:18:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 110233 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 04:17:40 -0500 Received: from servo.qualcomm.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2285B4A0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 4:17:39 -0500 Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.14) id BAA18919; Fri, 7 Jan 2000 01:28:00 -0800 (PST) Message-ID: <200001070928.BAA18919@servo.qualcomm.com> Date: Fri, 7 Jan 2000 01:28:00 -0800 Reply-To: Phil Karn Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Phil Karn Subject: Re: [MOBILE-IP] Cellular IP for Private Network Access X-To: Yingchun_Xu@MW.3COM.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <8625685E.00552375.00@mwgate02.mw.3com.com> (message from Yingchun Xu on Thu, 6 Jan 2000 09:27:26 -0600) >The problem occurs when two Mobile Hosts accessing different private networks >get assigned the same IP address at WAN level. In this case, Cellular IP node >will have problem for IP packet routing based on Mobile Host IP address. How can/why should two mobile hosts get assigned the same IP address? We have no trouble avoiding that in wired networks, why should wireless be any different? Or are you referring to NON-global IP addresses (eg., on network 10) belonging to distinct private networks that multiple mobile users on the same cellular FA may wish to use at the same time? If so, this is a totally artificial problem created by the cellular carrier's pointless insistence on implementing its own MIP FA. If you strip all vestiges of MIP out of the carrier, put a co-located FA in the mobile hosts, and have the carrier simply provide a unique, possibly temporary, globally routable IP address to each mobile user for the duration of his session, the problem disappears. Each mobile user's FA peers with his own HA, and each FA/HA association can encapsulate packets with non-global IP addresses belonging to his home network without any conflict with anyone else doing the same. Once again, we see that co-locating the FA at the mobile host is the *only* MIP configuration that makes any technical or operational sense. But I suppose I'll be told (and not for the first time) that it doesn't make "marketing" sense from the carrier's perspective. Over-the-air encapsulation overhead is a red herring, for several reasons. First, there are more efficient ways to encapsulate than sending two complete IP headers. Second, even if you do send two full IP headers, VJ header compression can be easily extended to work on them. Third and most important, encapsulated MIP traffic will be a tiny (if not zero) fraction of most mobile packet data users' traffic for a very simple reason: the vast majority of mobile users run clients, not servers. Those clients can initiate their transactions with whatever temporary IP address is assigned by the carrier. Because most network transactions are apt to be very short compared to the rate at which addresses change due to inter-cellular-system mobility, an address change during a transaction will be a rare event, and if it happens it can easily be repeated. I.e., MIP solves a problem they just don't have, and it imposes some substantial costs in the process (e.g., routing that can be wildly suboptimum). Virtually every dialup ISP already uses PPP dynamic address assignment. I don't know of any that provide MIP FAs. Why is cellular any different? Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 05:31: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 FAA13748 for ; Fri, 7 Jan 2000 05: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.DCEC6390@standards.nortelnetworks.com>; Fri, 7 Jan 2000 5:20:08 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 110376 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 05:19:28 -0500 Received: from monza.broadswitch.com (195.178.164.73) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5F256750@standards.nortelnetworks.com>; Fri, 7 Jan 2000 5:09:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD15ADD6@monza.broadswitch.com> Date: Fri, 7 Jan 2000 11:19:34 +0100 Reply-To: Thomas Eklund Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thomas Eklund Subject: Re: [MOBILE-IP] Cellular IP for Private Network Access X-To: Phil Karn To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > -----Original Message----- > From: Phil Karn [mailto:karn@QUALCOMM.COM] > Sent: Friday, January 07, 2000 10:28 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Cellular IP for Private Network Access > > > >The problem occurs when two Mobile Hosts accessing different > private networks > >get assigned the same IP address at WAN level. In this case, > Cellular IP node > >will have problem for IP packet routing based on Mobile Host > IP address. > > How can/why should two mobile hosts get assigned the same IP address? > We have no trouble avoiding that in wired networks, why should > wireless be any different? Because the address space is not enough.... > > Or are you referring to NON-global IP addresses (eg., on network 10) > belonging to distinct private networks that multiple mobile users on > the same cellular FA may wish to use at the same time? > > If so, this is a totally artificial problem created by the cellular > carrier's pointless insistence on implementing its own MIP FA. If you > strip all vestiges of MIP out of the carrier, put a co-located FA in > the mobile hosts, and have the carrier simply provide a unique, > possibly temporary, globally routable IP address to each mobile user > for the duration of his session, the problem disappears. Each mobile > user's FA peers with his own HA, and each FA/HA association can > encapsulate packets with non-global IP addresses belonging to his home > network without any conflict with anyone else doing the same. You absolutly right and this is solved in mobile ipv6!!! in default... So I suppose you argue for IPv6 then?? > > Once again, we see that co-locating the FA at the mobile host is the > *only* MIP configuration that makes any technical or operational > sense. But I suppose I'll be told (and not for the first time) that > it doesn't make "marketing" sense from the carrier's perspective. Thats because they are running there systems on IPv4 and dont have enough addresses so they have to use private addresses and "share a smaller pool of global addresses" when they access the Internet.. This of course is a bad design and put several security restrictions on your network. > > Over-the-air encapsulation overhead is a red herring, for several > reasons. First, there are more efficient ways to encapsulate than > sending two complete IP headers. Second, even if you do send two full > IP headers, VJ header compression can be easily extended to work on > them. Third and most important, encapsulated MIP traffic will be a > tiny (if not zero) fraction of most mobile packet data users' traffic > for a very simple reason: the vast majority of mobile users run > clients, not servers. Those clients can initiate their transactions > with whatever temporary IP address is assigned by the carrier. Because > most network transactions are apt to be very short compared to the > rate at which addresses change due to inter-cellular-system mobility, > an address change during a transaction will be a rare event, and if it > happens it can easily be repeated. I.e., MIP solves a problem they > just don't have, and it imposes some substantial costs in the process > (e.g., routing that can be wildly suboptimum). This is not true...!! The mobility signalling is very heavy, especially how it is designed in today's mobileip... There are though efforts that try to solve this problem and try to scale up the micro mobility signalling (paging support/location management etc...). Imagine that you are a wireless carrier and you probably have a couple of hundred of thousands of users that are in an area and perhaps a hundred active ones.... Then you can imagine that the signalling load is quite big... > > Virtually every dialup ISP already uses PPP dynamic address > assignment. I don't know of any that provide MIP FAs. Why is cellular > any different? It provides mobility....:-) You cant roam between two operators using PPP.... /Thomas From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 05:37: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 FAA13782 for ; Fri, 7 Jan 2000 05:37:41 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B5F57460@standards.nortelnetworks.com>; Fri, 7 Jan 2000 5:26:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 110377 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 05:24:23 -0500 Received: from monza.broadswitch.com (195.178.164.73) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0F2F5250@standards.nortelnetworks.com>; Fri, 7 Jan 2000 5:14:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD15ADD7@monza.broadswitch.com> Date: Fri, 7 Jan 2000 11:24:43 +0100 Reply-To: Thomas Eklund Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thomas Eklund Subject: Re: [MOBILE-IP] Cellular IP for Private Network Access X-To: "Zoltan.Turanyi@ETH.ERICSSON.SE" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > -----Original Message----- > From: Zoltan Richard Turanyi [mailto:Zoltan.Turanyi@ETH.ERICSSON.SE] > Sent: Thursday, January 06, 2000 6:14 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Cellular IP for Private Network Access > > > Yingchun Xu wrote: > > Encapsulation may not be a disadvantage if it does not > across air link. > > It may not. But, the fact that something is not disadvantageous is no > reason to use it. > > > I meant tunneling based approaches in general. > > Can you point out how this is done and where it is > described in "Cellular IP > > draft"? > > It is not included in this version of Cellular IP. > > > It seems to me that a unified approach for handling both > public and private > > network access is prefered. > > I do not think that the tunneling of packets containing private > addresses breaks the "uniform approach" of Cellular IP. > Besides, public > and private addresses are handled differently in fixed > networks as well. > Yes it does because you snoop on the addresses.... And it is very hard if you tunnel packets, because the inner packet is encrypted, how do you get that info? It will be very hard for Cellular IP to obtain security...I have also pointed out that several times before and I agree with Yingchun Xu that this is a problem... /Thomas From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 07:25: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 HAA15085 for ; Fri, 7 Jan 2000 07:25:41 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D13D1B10@standards.nortelnetworks.com>; Fri, 7 Jan 2000 7:14:20 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 110527 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 07:12:54 -0500 Received: from ingate.uk.neceur.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.382097A0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 7:02:54 -0500 Received: from internal-mail.uk.neceur.com by ingate.uk.neceur.com id F0Q30O+rrX33G1; Fri, 7 Jan 2000 12:11:18 GMT Received: from tokyo.ttd.neceur.com by internal-mail.uk.neceur.com id 0lz10K+rrXZP91; Fri, 7 Jan 2000 12:11:17 GMT from tokyo.ttd.neceur.com (localhost [127.0.0.1]) id 0lz10K+rrXZP91 (3.3.2/3.1.31); Fri, 7 Jan 2000 12:11:17 GMT Received: by tokyo.ttd.neceur.com with Internet Mail Service (5.5.1960.3) id ; Fri, 7 Jan 2000 12:10:58 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Message-ID: <3B9AA5E712DCD011AAD500609770A0E920383F@tokyo.ttd.neceur.com> Date: Fri, 7 Jan 2000 12:10:57 -0000 Reply-To: "BINAR, Simon" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "BINAR, Simon" Subject: Re: [MOBILE-IP] 3G Mobile Architectures X-To: Rami Gabriel Mukhtar To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, thanks for the comments... My response is below. Regards, Simon Binar > -----Original Message----- > From: Rami Gabriel Mukhtar [mailto:r.mukhtar@ee.mu.oz.au] > Sent: 07 January 2000 00:20 > To: BINAR, Simon; MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] 3G Mobile Architectures > > > "BINAR, Simon" wrote: > > > > > Here is now my question: which advantage is there to have IP totally > > completely utterly all-embracing in the wireless network as > opposed to > > have it deployed only in the core network? My first guess > is that there > > might be advantages in the area of network management (but > I'm not an NM > > expert, therefore, I'd like to get comments from more knowledgeable > > people in this area). I think that arguments such as "the > IETF approach > > is more elegant" is not valid, since, by the end of the day, we also > > have to think about business... > > > > Simon, these are my thoughts... > > Bringing IP addresses out to the base station has the advantage > of making the network far more flexible. > > Although currently cellular networks are large proprietary networks, > they may not be in the future. > > In the future as base station density increases and access to IP > networks becomes more predominant, it may be cheaper for a Telco > to connect additional base stations to an existing IP network > with a SLA rather than run another leased line to the base station. > In order for this to be practical, base stations need to be > IP addressable. > [SB] I don't quite understand the relation to leased lines. In OSI parlance, leased lines are layer 1, whereas IP is layer 3. Even if base stations are directly connected to the Internet, IP packets needs to be carried over some form of physical media. Leased lines (e.g., microwave links) could be one such form of transport. I have also heard the argument of easier configurability. Would this mean that base stations would implement a routing protocol such as OSPF, which would allow the service provider's IP network to automatically detect the new base station? I would also assume that the new base station would acquire its own address via some dynamic mechanism, such as DHCP? This could make sense... > From another perspective, operators may wish to connect small > clusters of base stations directly > to the internet. For example a company may wish to connect a single > private cell to the internet to enable network access within > a building > without incurring expensive Telco charges. If the base station is IP > addressable this can be done without having to construct a core > network. This addresses the particular scenario of a private access. My question was more focused on the public network environment. Even when the Internet is all-pervasive, a lot of the Internet infrastructure will be privately owned (by telcos). I don't see what benefit there would be for a telco to connect base stations directly to the Internet (which is assumed not be "owned" by the telco), since the telco wouldn't be making any money from the user's traffic... > > Hope this helps, > > Regards, > -- > Rami Mukhtar > ___________________________________________ > Post Graduate Student > Telecommunications Group > The University of Melbourne > Ph: (03) 9344-9207 > WWW: http://www.ee.mu.oz.au/pgrad/rgmukht > ___________________________________________ > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 07:59: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 HAA16051 for ; Fri, 7 Jan 2000 07:59:39 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.951A9130@standards.nortelnetworks.com>; Fri, 7 Jan 2000 7:48:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 110589 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 07:47:59 -0500 Received: from prserv.net (165.87.194.243) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1EEF84D0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 7:37:59 -0500 Received: from vagabond1 ([129.37.119.148]) by prserv.net (out5) with SMTP id <20000107124822243007167ue>; Fri, 7 Jan 2000 12:48:23 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Message-ID: <013501bf5926$613d2650$6e762581@vagabond1> Date: Fri, 7 Jan 2000 07:46:33 -0800 Reply-To: Scott Guthery Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Scott Guthery Subject: Re: [MOBILE-IP] AAA functionality X-To: Phil Karn To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit On E2E grounds the IP pipe should go all the way to the SIM/WIM/USIM; i.e. MIP for smart cards. Some initial work has been done: www.scdk.com/websim.pdf. Comments are solicited and greatly appreciated. Cheers, Scott -----Original Message----- From: Phil Karn To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Date: Friday, January 07, 2000 12:48 AM Subject: Re: [MOBILE-IP] AAA functionality >It is also an issue for the carrier that wants to be more then a simple >"pipe" to transport data over. I do agree that you are entitled to your Ah, here we reach the crux of the issue. Speaking as a potential user of your service, an IP "pipe" is all I want from you, and it's all I'm willing to pay for. And it's not just me. I know I speak for many prospective users (the ones who understand the issues, anyway) and for those who conceived the Internet architecture. Go read the classic paper by Saltzer, Reed & Clark, "End-to-End Arguments in System Design" (http://people.qualcomm.com/karn/library.html). This one paper is so fundamental that I've often thought prospective IETFers (especially those affiliated with telcos) should be required to read it and pass a test before they can participate in any IETF working group. :-) Unfortunately, many carriers (not just Sprint) see no glamor in being pipe providers, even though they can make plenty of money if they do it well and at reasonable cost. It's a widespread problem that also afflicts cable modem networks, for example. Fortunately, my own cable modem provider is proving themselves so incompetent at operating all these superfluous network functions that they're being forced to eliminate them just to keep the packets flowing. Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 09:17: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 JAA18097 for ; Fri, 7 Jan 2000 09:17:10 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5BF11450@standards.nortelnetworks.com>; Fri, 7 Jan 2000 9:05:35 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 110683 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 09:04:15 -0500 Received: from mullian.ee.mu.OZ.AU by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C5FF43F0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 8:54:14 -0500 Received: from mucous.ee.mu.oz.au (mucous.ee.mu.OZ.AU [128.250.80.88]) by mullian.ee.mu.OZ.AU (8.9.1a/8.9.1) with ESMTP id BAA16234 for ; Sat, 8 Jan 2000 01:04:37 +1100 (EST) Received: (nobody@localhost) by mucous.ee.mu.oz.au (8.8.8/8.6.10) id OAA13080; Fri, 7 Jan 2000 14:04:37 GMT X-Authentication-Warning: mucous.ee.mu.oz.au: nobody set sender to rgmukht@ee.mu.oz.au using -f References: <3B9AA5E712DCD011AAD500609770A0E920383F@tokyo.ttd.neceur.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP3 Imap webMail Program 2.0.11 Message-ID: <200001071404.OAA13080@mucous.ee.mu.oz.au> Date: Fri, 7 Jan 2000 14:04:37 GMT Reply-To: rgmukht@ee.mu.oz.au Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Rami Gabriel Mukhtar Subject: Re: [MOBILE-IP] 3G Mobile Architectures To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <3B9AA5E712DCD011AAD500609770A0E920383F@tokyo.ttd.neceur.com> Content-Transfer-Encoding: 8bit Hi Simon, Thanks for the response, some valid points, but here are a few comments in reply... Quoting "BINAR, Simon" : > [SB] I don't quite understand the relation to leased lines. In OSI > parlance, leased lines are layer 1, whereas IP is layer 3. Even if base > stations are directly connected to the Internet, IP packets needs to be > carried over some form of physical media. Leased lines (e.g., microwave > links) could be one such form of transport. I guess I was a little vague, I need to clarify my point further... You are right leased lines are definately layer 1 as opposed to IP (layer 3). Also, yes! you still need a physical media ... My point was that if IP networks are common, then it may be a lot cheaper to connect to a LOCAL IP network as opposed to building an entire core network from scratch. For example consider if a Telco wished to introduce a CDMA network into an area that is currently well covered by another type of cellular network. If the other network is, say a GSM network, then a great deal of infrastructure needs to be built. BUT if the network was simply a whole lot of base stations hanging of an IP network, then the entire core network could be re-used, assuming the capacity was there. Using a standard network like IP as close to the edge as possible enables the flexibility to re-use existing infrastructure. > > I have also heard the argument of easier configurability. Would this > mean that base stations would implement a routing protocol such as OSPF, > which would allow the service provider's IP network to automatically > detect the new base station? I would also assume that the new base > station would acquire its own address via some dynamic mechanism, such > as DHCP? This could make sense... Yes, I guess a some sort of routing table update algorithm will need to be employed... > > > From another perspective, operators may wish to connect small > > clusters of base stations directly > > to the internet. For example a company may wish to connect a single > > private cell to the internet to enable network access within > > a building > > without incurring expensive Telco charges. If the base station is IP > > addressable this can be done without having to construct a core > > network. > > This addresses the particular scenario of a private access. My question > was more focused on the public network environment. Even when the > Internet is all-pervasive, a lot of the Internet infrastructure will be > privately owned (by telcos). I don't see what benefit there would be for > a telco to connect base stations directly to the Internet (which is > assumed not be "owned" by the telco), since the telco wouldn't be making > any money from the user's traffic... > For small future mobile service providers, it may be more cost effective to buy into the banwidth of a larger Telco's land line IP network then build and maintain its own core network. By doing so a small mobile provider could spend more money base stations, and get better coverage. I guess this may be a political thing ... depending on deregulation etc.? Even today competing telco's lease long haul bandwidth from competing telco's in preference to laying their own cables ... it can be very cost effective. Anyway, thanks for your comments, let me know what you think. Kind Regards, -- Rami Mukhtar ___________________________________________ Post Graduate Student Telecommunications Group The University of Melbourne Ph: (03) 9344-9207 WWW: http://www.ee.mu.oz.au/pgrad/rgmukht ___________________________________________ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 09:53: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 JAA19200 for ; Fri, 7 Jan 2000 09:53:06 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.692AC0D0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 9:41:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 110797 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 09:40:54 -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.E5326130@standards.nortelnetworks.com>; Fri, 7 Jan 2000 9:30:54 -0500 Received: from lt.eth.ericsson.se (lt.eth.ericsson.se [164.48.158.205]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id PAA01519; Fri, 7 Jan 2000 15:41:18 +0100 (MET) Received: from eth.ericsson.se by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id PAA06803; Fri, 7 Jan 2000 15:41:16 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: Hungarian, hu, en MIME-Version: 1.0 References: <45AFD48D077ED211BB4700A0C9DCE8FD15ADD7@monza.broadswitch.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3875FB0C.D60579A4@eth.ericsson.se> Date: Fri, 7 Jan 2000 15:41:16 +0100 Reply-To: Zoltan.Turanyi@ETH.ERICSSON.SE Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Zoltan Richard Turanyi Organization: Ericsson TrafficLab Subject: Re: [MOBILE-IP] Cellular IP for Private Network Access X-To: Thomas Eklund To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Thomas Eklund wrote: > > I do not think that the tunneling of packets containing private > > addresses breaks the "uniform approach" of Cellular IP. > > Besides, public > > and private addresses are handled differently in fixed > > networks as well. > > > Yes it does because you snoop on the addresses.... And it is very hard if > you tunnel packets, because the inner packet is encrypted, how do you get > that info? Thomas, In case of private home addrersses the whole purpose of tunneling is to hide the inner (private) address. Naturally Cellular IP nodes snoop the outer address. They are not even aware of the tunnel. > It will be very hard for Cellular IP to obtain security...I have also > pointed out that several times before and I agree with Yingchun Xu that this > is a problem... Tunneling of private addresses have little security consequencies here. I do not really see what one has to do with the other. Private addresses require only easy to add extensions to Cellular IP and do not break the basic mechanisms of location management and routing. It also seems that you are a bit unfamiliar with the new Cellular IP draft which contains security extensions (draft-valko-cellularip-01.txt). Feel free to raise specific security concerns relating to Cellular IP. /Zoltan -- Zoltan Richard Turanyi Research Fellow, Ericsson Hungary Traffic Analysis and Network Performance Lab From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 10:19: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 KAA19873 for ; Fri, 7 Jan 2000 10:19:12 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0E3B31B0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 10:07:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 110864 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 10:06:15 -0500 Received: from ingate.uk.neceur.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6FC163C0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 9:56:15 -0500 Received: from internal-mail.uk.neceur.com by ingate.uk.neceur.com id uHX10W80sXJmh1; Fri, 7 Jan 2000 15:04:40 GMT Received: from tokyo.ttd.neceur.com by internal-mail.uk.neceur.com id PwK20O80sXZBl1; Fri, 7 Jan 2000 15:04:38 GMT from tokyo.ttd.neceur.com (localhost [127.0.0.1]) id PwK20O80sXZBl1 (3.3.2/3.1.31); Fri, 7 Jan 2000 15:04:38 GMT Received: by tokyo.ttd.neceur.com with Internet Mail Service (5.5.1960.3) id ; Fri, 7 Jan 2000 15:04:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <3B9AA5E712DCD011AAD500609770A0E9203840@tokyo.ttd.neceur.com> Date: Fri, 7 Jan 2000 15:04:18 -0000 Reply-To: "BINAR, Simon" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "BINAR, Simon" Subject: Re: [MOBILE-IP] 3G Mobile Architectures X-To: "rgmukht@ee.mu.oz.au" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Some further comments and thoughts on this issue: - If I connect base stations directly to an IP network (a bunch of routers, presumably), where will the Radio Resources Management (RRM) function reside? In GSM, this was typically in the BSC, and in UMTS, this is in the RNC. If I put RRM functionality into every single base station, I will end-up with extremely expensive (and un-sellable) base stations. Thus, the RRM function would need to be located somewhere in the IP network, maybe in a server? If I do this, what impact will this have on system performance (I am especially thinking about handover latency). Should I have local servers to handle local areas (in order to improve system performance), or one single super-server to deal with the entire network? Obviously, if I use local servers, this will look much more like the "old" access networks of GSM and UMTS. This will also reduce the flexibility of the network that you mentioned. - The argument about re-using existing infrastructure needs to be considered with care. I think your scenario would apply to a very specific case, say, an ISP that wishes to get into the mobile networking business. In this case, having the ability to connect base stations directly to the existing IP infrastructure would be really great (of course, additional functions would also be required for billing, authorisation and accounting, etc...). But most mobile network operators already have infrastructure in place. If we look at a scenario in 3-5 years time where most mobile operators have either GPRS or a variant of an IMT-2000 network, then the infrastructure is already in place, and expanding that infrastructure shouldn't really be an issue. Simon Binar > -----Original Message----- > From: Rami Gabriel Mukhtar [mailto:rgmukht@EE.MU.OZ.AU] > Sent: 07 January 2000 14:05 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] 3G Mobile Architectures > > > Hi Simon, > > Thanks for the response, some valid points, but here > are > a few comments in reply... > > Quoting "BINAR, Simon" : > > > [SB] I don't quite understand the relation to > leased > lines. In OSI > > parlance, leased lines are layer 1, whereas IP is > layer 3. Even if base > > stations are directly connected to the Internet, > IP > packets needs to be > > carried over some form of physical media. Leased > lines > (e.g., microwave > > links) could be one such form of transport. > > I guess I was a little vague, I need to clarify my > point > further... You are right leased lines are > definately > layer 1 as opposed to IP (layer 3). Also, yes! you > still need a physical media ... > > My point was that if IP networks are common, then it > may > be a lot cheaper to connect to a LOCAL IP network as > opposed to building an entire core network from > scratch. > > For example consider if a Telco wished to introduce > a > CDMA network into an area that is currently well > covered > by another type of cellular network. > > If the other network is, say a GSM network, then a > great > deal of infrastructure needs to be built. BUT if > the > network was simply a whole lot of base stations > hanging > of an IP network, then the entire core network could > be > re-used, assuming the capacity was there. > > Using a standard network like IP as close to the > edge as > possible enables the flexibility to re-use existing > infrastructure. > > > > I have also heard the argument of easier > configurability. Would this > > mean that base stations would implement a routing > protocol such as OSPF, > > which would allow the service provider's IP > network to > automatically > > detect the new base station? I would also assume > that > the new base > > station would acquire its own address via some > dynamic > mechanism, such > > as DHCP? This could make sense... > > Yes, I guess a some sort of routing table update > algorithm will need to be employed... > > > > > > From another perspective, operators may wish to > connect small > > > clusters of base stations directly > > > to the internet. For example a company may wish > to > connect a single > > > private cell to the internet to enable network > access within > > > a building > > > without incurring expensive Telco charges. If > the > base station is IP > > > addressable this can be done without having to > construct a core > > > network. > > > > This addresses the particular scenario of a > private > access. My question > > was more focused on the public network > environment. > Even when the > > Internet is all-pervasive, a lot of the Internet > infrastructure will be > > privately owned (by telcos). I don't see what > benefit > there would be for > > a telco to connect base stations directly to the > Internet (which is > > assumed not be "owned" by the telco), since the > telco > wouldn't be making > > any money from the user's traffic... > > > > For small future mobile service providers, it may be > more cost effective to buy into the banwidth of a > larger > Telco's land line IP network then build and maintain > its > own core network. By doing so a small mobile > provider > could spend more money base stations, and get better > coverage. I guess this may be a political thing ... > depending on deregulation etc.? > > Even today competing telco's lease long haul > bandwidth > from competing telco's in preference to laying their > own > cables ... it can be very cost effective. > > Anyway, thanks for your comments, let me know what > you > think. > > Kind Regards, > > -- > Rami Mukhtar > ___________________________________________ > Post Graduate Student > Telecommunications Group > The University of Melbourne > Ph: (03) 9344-9207 > WWW: http://www.ee.mu.oz.au/pgrad/rgmukht > ___________________________________________ > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 10:23: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 KAA19956 for ; Fri, 7 Jan 2000 10:23:33 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9FC72C60@standards.nortelnetworks.com>; Fri, 7 Jan 2000 10:11:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 110916 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 10:11:20 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8B28B350@standards.nortelnetworks.com>; Fri, 7 Jan 2000 10:11:20 -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 IAA06268; Fri, 7 Jan 2000 08:21:43 -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 HAA18468; Fri, 7 Jan 2000 07:21:42 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id HAA06402; Fri, 7 Jan 2000 07:21: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: <200001071521.HAA06402@nasnfs.eng.sun.com> Date: Fri, 7 Jan 2000 07:25:26 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] AAA functionality X-To: Phil Karn To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Phil, My understanding, from TIA meetings, is that one of the main reasons behind not going with co-located MN is simply the header overhead over the air network. If spectrum wasn't an issue, I think that most people would agree with you. Perhaps the day that the government stops treating spectrum like property, we may get to this point. PatC >>It is also an issue for the carrier that wants to be more then a simple >>"pipe" to transport data over. I do agree that you are entitled to your > >Ah, here we reach the crux of the issue. Speaking as a potential user >of your service, an IP "pipe" is all I want from you, and it's all I'm >willing to pay for. > >And it's not just me. I know I speak for many prospective users (the >ones who understand the issues, anyway) and for those who conceived >the Internet architecture. Go read the classic paper by Saltzer, Reed >& Clark, "End-to-End Arguments in System Design" >(http://people.qualcomm.com/karn/library.html). > >This one paper is so fundamental that I've often thought prospective >IETFers (especially those affiliated with telcos) should be required >to read it and pass a test before they can participate in any IETF >working group. :-) > >Unfortunately, many carriers (not just Sprint) see no glamor in being >pipe providers, even though they can make plenty of money if they do >it well and at reasonable cost. It's a widespread problem that also >afflicts cable modem networks, for example. Fortunately, my own cable >modem provider is proving themselves so incompetent at operating all >these superfluous network functions that they're being forced to >eliminate them just to keep the packets flowing. > >Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 10:58: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 KAA20828 for ; Fri, 7 Jan 2000 10:58:16 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.87501AC0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 10:47:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 110997 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 10:45:10 -0500 Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.446CD810@standards.nortelnetworks.com>; Fri, 7 Jan 2000 10:45:09 -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 QAA15742; Fri, 7 Jan 2000 16:51:40 +0100 (MET) Received: from iseran (localhost [127.0.0.1]) by iseran.inrialpes.fr (8.8.7/8.8.5) with SMTP id QAA09925; Fri, 7 Jan 2000 16:55:28 +0100 (MET) X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 References: <3B9AA5E712DCD011AAD500609770A0E9203840@tokyo.ttd.neceur.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38760C6F.59D4@inrialpes.fr> Date: Fri, 7 Jan 2000 16:55:27 +0100 Reply-To: Claude.Castelluccia@INRIALPES.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Claude Castelluccia Subject: Re: [MOBILE-IP] 3G Mobile Architectures X-To: "BINAR, Simon" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, BINAR, Simon wrote: > > Some further comments and thoughts on this issue: > > - If I connect base stations directly to an IP network (a bunch of > routers, presumably), where will the Radio Resources Management (RRM) > function reside? In GSM, this was typically in the BSC, and in UMTS, > this is in the RNC. If I put RRM functionality into every single base > station, I will end-up with extremely expensive (and un-sellable) base > stations. Thus, the RRM function would need to be located somewhere in > the IP network, maybe in a server? If I do this, what impact will this > have on system performance (I am especially thinking about handover > latency). Should I have local servers to handle local areas (in order to > improve system performance), or one single super-server to deal with the > entire network? Obviously, if I use local servers, this will look much > more like the "old" access networks of GSM and UMTS. This will also > reduce the flexibility of the network that you mentioned. The RRM functions of GSM networks are complex because GSM is "connection-oriented". RRM would be much simpler if packet-based wireless access networks would be used and could easily be implemented in the BS without support from the network (IEEE802.11 BS are quite cheap, aren't they?). The main issue that I see with IP-based Cellular networks is the QoS issue. How do you guarante an acceptable QoS to the users without establishing a connection...? I believe that DiffSer/IntServ amd adaptive radios/applications might be very useful here... > - The argument about re-using existing infrastructure needs to be > considered with care. I think your scenario would apply to a very > specific case, say, an ISP that wishes to get into the mobile networking > business. In this case, having the ability to connect base stations > directly to the existing IP infrastructure would be really great (of > course, additional functions would also be required for billing, > authorisation and accounting, etc...). But most mobile network operators > already have infrastructure in place. If we look at a scenario in 3-5 > years time where most mobile operators have either GPRS or a variant of > an IMT-2000 network, then the infrastructure is already in place, and > expanding that infrastructure shouldn't really be an issue. that's exactly why it is important to design IP-based cellular networks: to allow new ISP to provide mobile networking services and also to allow a company or a university to set up its own wireless IP network (or intranet) without having to pay expensive fees to its GPRS operator.... Claude. ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 11:14: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 LAA21190 for ; Fri, 7 Jan 2000 11:14:12 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C552F930@standards.nortelnetworks.com>; Fri, 7 Jan 2000 11:03:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 111034 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 11:01:37 -0500 Received: from ns01.newbridge.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2BF15670@standards.nortelnetworks.com>; Fri, 7 Jan 2000 10:51:37 -0500 Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id KAA11330 for ; Fri, 7 Jan 2000 10:57:11 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdAAAtAwws_; Fri Jan 7 10:57:07 2000 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 11:01:51 -0500 Received: from pcswb ([138.120.245.101]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA7399; Fri, 7 Jan 2000 11:01:49 -0500 X-Sender: swb@kanmail01.ca.newbridge.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.2.20000107105636.00a578d0@kanmail01.ca.newbridge.com> Date: Fri, 7 Jan 2000 11:00:49 -0500 Reply-To: Scott W Brim Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Scott W Brim Subject: Re: [MOBILE-IP] 3G Mobile Architectures X-To: "BINAR, Simon" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <3B9AA5E712DCD011AAD500609770A0E920382F@tokyo.ttd.neceur.co m> There's no conflict between IP and ATM. Most of the Internet runs over ATM. The advantage to having IP in the mix is that the services people will want to access will, overwhelmingly, be off any ATM network, and you have much more flexibility when you have a common end-to-end protocol instead of a high level gateway in the middle which you have to keep up to date. ...Scott From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 11:23: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 LAA21406 for ; Fri, 7 Jan 2000 11:23:37 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0916E270@standards.nortelnetworks.com>; Fri, 7 Jan 2000 11:12:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 111035 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 11:11:03 -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.7CF37250@standards.nortelnetworks.com>; Fri, 7 Jan 2000 11:01:03 -0500 Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id RAA26370; Fri, 7 Jan 2000 17:11:26 +0100 (MET) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id SAA14150; Fri, 7 Jan 2000 18:11:23 +0200 (EET) Received: from greymse1.lmf.ericsson.se (greymse1.lmf.ericsson.se [131.160.1.6]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id SAA14146; Fri, 7 Jan 2000 18:11:22 +0200 (EET) Received: from ericsson.com (TOS92022-udp227087.lmf.ericsson.se [131.160.75.169]) by greymse1.lmf.ericsson.se (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id SAA27411; Fri, 7 Jan 2000 18:11:19 +0200 (EET) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <200001071521.HAA06402@nasnfs.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38761009.6B11CF2B@ericsson.com> Date: Fri, 7 Jan 2000 18:10:49 +0200 Reply-To: Mikael Latvala Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mikael Latvala Subject: Re: [MOBILE-IP] AAA functionality X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Pat, Pat.Calhoun@Eng.Sun.COM wrote: > > My understanding, from TIA meetings, is that one of the main reasons behind > not going with co-located MN is simply the header overhead over the air > network. > > If spectrum wasn't an issue, I think that most people would agree with you. > Perhaps the day that the government stops treating spectrum like property, > we may get to this point. > I agree with Phil; spectrum is hardly the issue here. Using the compression principles explained in rfc1144 minimal encapsulation for example would add only 2 bytes (header checksum for the minimal forwarding header) to the total size of the compressed header. Same should be the case also with rfc2003. /Mikael From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 11:31: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 LAA21673 for ; Fri, 7 Jan 2000 11:31:21 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2990FB70@standards.nortelnetworks.com>; Fri, 7 Jan 2000 11:20:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 111073 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 11:18:47 -0500 Received: from ingate.uk.neceur.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9188F540@standards.nortelnetworks.com>; Fri, 7 Jan 2000 11:08:47 -0500 Received: from internal-mail.uk.neceur.com by ingate.uk.neceur.com id w7P00WO4sXZm3; Fri, 7 Jan 2000 16:17:12 GMT Received: from tokyo.ttd.neceur.com by internal-mail.uk.neceur.com id bva20OO4sX3dA; Fri, 7 Jan 2000 16:17:10 GMT from tokyo.ttd.neceur.com (localhost [127.0.0.1]) id bva20OO4sX3dA (3.3.2/3.1.31); Fri, 7 Jan 2000 16:17:10 GMT Received: by tokyo.ttd.neceur.com with Internet Mail Service (5.5.1960.3) id ; Fri, 7 Jan 2000 16:16:51 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <3B9AA5E712DCD011AAD500609770A0E9203841@tokyo.ttd.neceur.com> Date: Fri, 7 Jan 2000 16:16:50 -0000 Reply-To: "BINAR, Simon" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "BINAR, Simon" Subject: Re: [MOBILE-IP] 3G Mobile Architectures X-To: Claude Castelluccia To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, See below my answer... Simon Binar > -----Original Message----- > From: Claude Castelluccia [mailto:claude.castelluccia@inrialpes.fr] > Sent: 07 January 2000 15:55 > To: BINAR, Simon > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] 3G Mobile Architectures > > > Hello, > > BINAR, Simon wrote: > > > > Some further comments and thoughts on this issue: > > > > - If I connect base stations directly to an IP network (a bunch of > > routers, presumably), where will the Radio Resources > Management (RRM) > > function reside? In GSM, this was typically in the BSC, > and in UMTS, > > this is in the RNC. If I put RRM functionality into every > single base > > station, I will end-up with extremely expensive (and > un-sellable) base > > stations. Thus, the RRM function would need to be located > somewhere in > > the IP network, maybe in a server? If I do this, what > impact will this > > have on system performance (I am especially thinking about handover > > latency). Should I have local servers to handle local areas > (in order to > > improve system performance), or one single super-server to > deal with the > > entire network? Obviously, if I use local servers, this > will look much > > more like the "old" access networks of GSM and UMTS. This will also > > reduce the flexibility of the network that you mentioned. > > The RRM functions of GSM networks are complex because GSM is > "connection-oriented". > RRM would be much simpler if packet-based wireless access > networks would > be used and could easily be implemented in the BS without support from > the > network (IEEE802.11 BS are quite cheap, aren't they?). > > The main issue that I see with IP-based Cellular networks is the QoS > issue. > How do you guarante an acceptable QoS to the users without > establishing > a connection...? I believe that DiffSer/IntServ amd adaptive > radios/applications might be very useful here... [SB] One can argue about what "cheap" means, but IEEE802.11 is presumably cheap because it works like a shared-media LAN (e.g., Ethernet). QoS makes the thing much more complex. You can use network layer QoS like DiffServ/IntServ for the core network, but you need also a dedicated QoS scheme at the radio layer as well. What's the point of agreeing a certain bandwidth via RSVP if it cannot be guaranteed by the radio layer (read: 802.11)? Introducing QoS at the radio layer essentially makes it connection-oriented, and thus makes it a complex system. Connectionless QoS may be possible in IP networks where bandwidth is supposedly abundant, but I believe radio spectrum will always be a scarce resource, even in times of UMTS and IMT-2000, and thus, efficient resource management will be required. > > > - The argument about re-using existing infrastructure needs to be > > considered with care. I think your scenario would apply to a very > > specific case, say, an ISP that wishes to get into the > mobile networking > > business. In this case, having the ability to connect base stations > > directly to the existing IP infrastructure would be really great (of > > course, additional functions would also be required for billing, > > authorisation and accounting, etc...). But most mobile > network operators > > already have infrastructure in place. If we look at a > scenario in 3-5 > > years time where most mobile operators have either GPRS or > a variant of > > an IMT-2000 network, then the infrastructure is already in > place, and > > expanding that infrastructure shouldn't really be an issue. > > that's exactly why it is important to design IP-based > cellular networks: > to allow new ISP to provide mobile networking services and > also to allow > a company or a university to set up its own wireless IP network (or > intranet) > without having to pay expensive fees to its GPRS operator.... > > Claude. > > ---------------------------------------- > Claude CASTELLUCCIA, INRIA Rhone-Alpes > ph: +33 4.76.61.52.15 (fax: 52.52) > http://www.inrialpes.fr/planete/ > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 12:09: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 MAA22875 for ; Fri, 7 Jan 2000 12:09:33 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7EBA07E0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 11:58:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 111220 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 11:57:07 -0500 Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.523A6DE0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 11:57:07 -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 SAA17459; Fri, 7 Jan 2000 18:03:39 +0100 (MET) Received: from iseran (localhost [127.0.0.1]) by iseran.inrialpes.fr (8.8.7/8.8.5) with SMTP id SAA10013; Fri, 7 Jan 2000 18:07:26 +0100 (MET) X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 References: <3B9AA5E712DCD011AAD500609770A0E9203841@tokyo.ttd.neceur.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38761D4D.51A0@inrialpes.fr> Date: Fri, 7 Jan 2000 18:07:25 +0100 Reply-To: Claude.Castelluccia@INRIALPES.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Claude Castelluccia Subject: Re: [MOBILE-IP] 3G Mobile Architectures X-To: "BINAR, Simon" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit thanks for your comments, BINAR, Simon wrote: > > [SB] One can argue about what "cheap" means, but IEEE802.11 is > presumably cheap because it works like a shared-media LAN (e.g., > Ethernet). QoS makes the thing much more complex. You can use network > layer QoS like DiffServ/IntServ for the core network, but you need also > a dedicated QoS scheme at the radio layer as well. What's the point of > agreeing a certain bandwidth via RSVP if it cannot be guaranteed by the > radio layer (read: 802.11)? Introducing QoS at the radio layer > essentially makes it connection-oriented, and thus makes it a complex > system. I do not fully agree. I believe that by using smart radio and applications that adapt to the environments and give higher priorities to sensitive flows you can do a lot without having to open connections.... For campus or company networks (i.e controled environments), adaptive radio/applications + well dimensioning should make it...when the user switches to a public network then that an other story but in this case it is probably OK to have more complex base stations (eventhough some coarse grain reservation + access control mechanisms might be enough)... I agree that more research/experimentations are needed though... regards, Claude. ------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 12:13: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 MAA23084 for ; Fri, 7 Jan 2000 12:13:22 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0F5C8CF0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 12:02:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 111209 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 12:01:09 -0500 Received: from proxy2.ba.best.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7C847FB0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 11:51:08 -0500 Received: from cub (node-d8e9376.powerinter.net [216.233.55.6]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id IAA14219 for ; Fri, 7 Jan 2000 08:59:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Message-ID: Date: Fri, 7 Jan 2000 08:59:52 -0800 Reply-To: "Joseph A. Latone" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Joseph A. Latone" Subject: Re: [MOBILE-IP] Cellular IP for Private Network Access To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200001070832.AAA18299@servo.qualcomm.com> Content-Transfer-Encoding: 7bit > >Sprint PCS would ask that the design of our network not be discussed over > >ANY public mail list. > My description of Sprint PCS's packet data service was based totally > on my personal observations using my personally-owned phone, a data > cable and a laptop running Linux. Just to confirm Phil's observations, I came to the same conclusions, although I used a different set of tools, and I don't think my service contract included an NDA. Joe From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 12:50: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 MAA24071 for ; Fri, 7 Jan 2000 12:50:57 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.41F10F60@standards.nortelnetworks.com>; Fri, 7 Jan 2000 12:39:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 111394 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 12:38:25 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1720FA20@standards.nortelnetworks.com>; Fri, 7 Jan 2000 12:38:25 -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 JAA25879 for ; Fri, 7 Jan 2000 09:48:45 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id JAA15844 for ; Fri, 7 Jan 2000 09:48:44 -0800 X-Virus-Scanned: Fri, 7 Jan 2000 09:48:44 -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) xma015543; Fri, 7 Jan 00 09:48:37 -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: <387626F5.2973732E@iprg.nokia.com> Date: Fri, 7 Jan 2000 09:48:37 -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] The grace period (AAA requirements) To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello folks, The revised AAA draft is due out soon, and some decision has to be made regarding whether to explicitly put in the requirement for allowing a grace period for Mobile IP registrations, in the AAA requirements draft. From the discussion on the mailing list, it does not seem that any consensus has been reached. But, perhaps more importantly, this discussion may not even belong in the AAA requirements draft. My reasoning is as follows. The original point is that sometimes a foreign agent might want to forward a Registration Request before getting an answer back from the AAA infrastructure. Whether or not the foreign agent does this does not necessarily limit its ability to rely on the AAA infrastructure for answers. So, for instance, we should try to make sure that the AAA infrastructure can provide the necessary authorization to a foreign agent, independent of whether or not the messages from the foreign agent to the AAAF contain the Mobile IP registration data. On the other hand, the discussion about whether a foreign agent should be allowed to offer this grace period is pretty important, and I hope will continue even if it is not crucial for the wording of the AAA requirements draft. Does this sound like a reasonable resolution for now? Regards, Charlie P. > "Lipford, Mark" wrote: > > As a wireless carrier interested in deploying a MIP solution I don't feel > comfortable allowing a "grace" period. We have received many request for > potential customers on how quickly they could send a "short burst" of data > through our network for particular applications (i.e. telemetry and > telematics are two big ones). If we allow users a grace period they could > potentially run their business without getting properly authorized. While > there are possibly other ways to block this usage AAA is the best solution. >> -----Original Message----- >> From: Patrik Flykt [mailto:patrik.flykt@NOKIA.COM] >> Sent: Wednesday, January 05, 2000 2:40 AM >> To: MOBILE-IP@standards.nortelnetworks.com >> Subject: Re: [MOBILE-IP] AAA functionality >> >> Hi, >> >>> Perhaps I am missing something, but I *really* don't see how the AAA >>> and Mobile-IP requests can be done in parallel. If a requirement is >>> that it must be possible to separate the two, then I would prefer to >>> see that both requests are done sequentially, first AAA then Mobile-IP. >>> This would remove many strange interactions, and would be a much cleaner >>> approach. >> >> I suppose there is a requirement that AAA and MIP messages can be separated >> (be it parallell or serial message sending). When you pay for access with >> your credit card the authorization/accounting goes to the credit card >> company's AAA server, while the Mobile IP messages go to your home agent. >> >> The sequential approach is extremely useful if the only case of using AAA >> with MIP is to ensure that the provider of the foreign agent is able to >> account for every second of foreign agent usage. However, the provider could >> also be interested in allowing a short grace period to ensure that the >> real-time applications used in the mobile node would experience the shortest >> possible service disruption. I suppose the AAA processing will take at least >> a couple of seconds and even longer when there are several brokers between >> the visited and home domains. The grace period enables of course a >> possibility of fraud, which the provider has to take into account. >> Minimizing fraud could be done for example by allowing the grace period only >> to those who have visited the same provider's network earlier and have been >> given a session key, as described in the "Minimal Latency Secure Hand-off" >> draft. There is also a third possibility when the provider is providing free >> access for everyone without any accounting but with authorization. The >> provider wants to be sure that the home AAA domain authorizes the mobile >> node, i.e. it is not stolen, in the (for some reason) wrong domain, etc. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 12: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 MAA24210 for ; Fri, 7 Jan 2000 12: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.1A6189B0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 12:45:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 111430 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 12:45:36 -0500 Received: from dumburken.it.kth.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1814B380@standards.nortelnetworks.com>; Fri, 7 Jan 2000 12:45:36 -0500 Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id SAA10983; Fri, 7 Jan 2000 18:55:52 +0100 (MET) X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f References: <200001071521.HAA06402@nasnfs.eng.sun.com> <38761009.6B11CF2B@ericsson.com> Message-ID: <200001071755.SAA10983@dumburken.it.kth.se> Date: Fri, 7 Jan 2000 18:55:52 +0100 Reply-To: Gerald Maguire Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gerald Maguire Subject: Re: [MOBILE-IP] AAA functionality X-To: mikael.latvala@ERICSSON.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <38761009.6B11CF2B@ericsson.com> (message from Mikael Latvala on Fri, 7 Jan 2000 18:10:49 +0200) Not only do I agree with Phil, but I want to point out that if efficient spectrum usage is important, then it is all the _more_ reason to use packets -- since you can now do VOIP and get far more efficient usage of the channel and you can also elimiate 1/2 the processing currently done at the basestations -- since you no longer need to do voice transcoding in the access network (only at the points where this traffic has to go into the legacy voice networks). Additionally, by simply supporting packet traffic and doing the encoding/decoding only in the end-points, it become much easier to introduce new CODECs which are more efficient or in the case of some languages more suitable. In the current systems the introduction of half-rate voice codecs takes a very long time. In certain vendors basestations the signal processor can not be remotely reprogrammed (i.e., their is no path from the BSC to the code memory of the signal processor). Hence to change this code requires a visit to each basestation. Here is another good example of where an IP network attached device would be much better, since it is more likely that the system would be remotely programmable. Another reason that telecom people should read the "End-to-End Arguments in System Design" by Jerome H. Saltzer, David P. Reed, and David D. Clark -- is so that they would stop doing foolish things like the interleaving that is done in GPRS -- which both increases the latency and increases the probability of damaging more than one packet. Over the last several years a number of theses have shown that the best thing (in terms of throughput and overall latency) that can be done with the low level ARQ mechanisms in DECT, GSM, ... is to turn them off! Chip From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 14:02: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 OAA25273 for ; Fri, 7 Jan 2000 14:02:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.32C30F20@standards.nortelnetworks.com>; Fri, 7 Jan 2000 13:50:46 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 111511 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 13:48:51 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EE163000@standards.nortelnetworks.com>; Fri, 7 Jan 2000 13:48: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 LAA23312 for ; Fri, 7 Jan 2000 11:59:16 -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 KAA03528 for ; Fri, 7 Jan 2000 10:59:17 -0800 (PST) Received: from bobo (bobo.Eng.Sun.COM [129.146.86.130]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA01587; Fri, 7 Jan 2000 10:59:15 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Fri, 7 Jan 2000 10:59:15 -0800 Reply-To: Erik Nordmark Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Erik Nordmark Subject: Re: [MOBILE-IP] AAA functionality X-To: pcalhoun@eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <200001071521.HAA06402@nasnfs.eng.sun.com> > Phil, > > My understanding, from TIA meetings, is that one of the main reasons behind > not going with co-located MN is simply the header overhead over the air > network. Have they've looked at RFC 2507 and friends? (There are some issues with packet loss which hopefully a future robhc working group will address.) > If spectrum wasn't an issue, I think that most people would agree with you. > Perhaps the day that the government stops treating spectrum like property, > we may get to this point. I think physics get in the way. The available spectrum between a sender and receiver is quite finite and always will be. Wired bandwith don't have such physical limitations. Erik From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 14: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 OAA25340 for ; Fri, 7 Jan 2000 14:10:44 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3333B5D0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 13:57:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 111581 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 13:57:06 -0500 Received: from servo.qualcomm.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.14B83680@standards.nortelnetworks.com>; Fri, 7 Jan 2000 13:57:05 -0500 Received: (from karn@localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.14) id LAA25997; Fri, 7 Jan 2000 11:07:29 -0800 (PST) Message-ID: <200001071907.LAA25997@servo.qualcomm.com> Date: Fri, 7 Jan 2000 11:07:29 -0800 Reply-To: Phil Karn Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Phil Karn Subject: Re: [MOBILE-IP] AAA functionality X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200001071521.HAA06402@nasnfs.eng.sun.com> (message from Patrice Calhoun on Fri, 7 Jan 2000 07:25:26 -0800) >My understanding, from TIA meetings, is that one of the main reasons behind >not going with co-located MN is simply the header overhead over the air >network. Remember the old saying, premature optimization is the root of all evil. As I pointed out in my message, header overhead is a red herring here. Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 16:00: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 QAA27205 for ; Fri, 7 Jan 2000 16:00:32 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C0C5EFD0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 15:49:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 111755 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 15:48:07 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.973EFC60@standards.nortelnetworks.com>; Fri, 7 Jan 2000 15:48: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 MAA14858; Fri, 7 Jan 2000 12:58:01 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id MAA03170; Fri, 7 Jan 2000 12:57:57 -0800 X-Virus-Scanned: Fri, 7 Jan 2000 12:57: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) xma000552; Fri, 7 Jan 00 12:57:34 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <200001070928.BAA18919@servo.qualcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3876533D.6E9B93EB@iprg.nokia.com> Date: Fri, 7 Jan 2000 12:57:33 -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] Cellular IP for Private Network Access X-To: Phil Karn To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Phil, I second most of your comments on pipes (spectrum) and end-to-end design. But I finally have to respond to the following. > If so, this is a totally artificial problem created by the cellular > carrier's pointless insistence on implementing its own MIP FA. Whether or not a foreign agent is pointless should be decided in each particular instance. You may say that it's pointless for ISPs to charge more for using multiple IP addresses, or that many other existing practices are pointless. I think it is important to allow for the _possibility_ that a mobile node may not wish to operate with a co-located care-of address. I also think it's fine if it wishes to do so. > If you > strip all vestiges of MIP out of the carrier, put a co-located FA in > the mobile hosts, and have the carrier simply provide a unique, > possibly temporary, globally routable IP address to each mobile user > for the duration of his session, the problem disappears. That depends on what you mean the problem is. There are a lot of reasons why an IP address should survive the duration of a single "session", and those reasons may well become even more important over time. > Each mobile > user's FA peers with his own HA, and each FA/HA association can > encapsulate packets with non-global IP addresses belonging to his home > network without any conflict with anyone else doing the same. I agree that this is a great model for mobile nodes that can support it. > Once again, we see that co-locating the FA at the mobile host is the > *only* MIP configuration that makes any technical or operational > sense. But I suppose I'll be told (and not for the first time) that > it doesn't make "marketing" sense from the carrier's perspective. I also don't agree that it's the "only" MIP configuration that makes sense, so I don't fit in your first person plurality, althought I certainly agree that it does make sense. Somehow, I don't feel as if I am being blinded by my marketing background. > Because > most network transactions are apt to be very short compared to the > rate at which addresses change due to inter-cellular-system mobility, > an address change during a transaction will be a rare event, and if it > happens it can easily be repeated. I.e., MIP solves a problem they > just don't have, and it imposes some substantial costs in the process > (e.g., routing that can be wildly suboptimum). From my understanding, you are saying that things only seem to be a little bit broken now. I compare your solution to the user-oriented retransmission algorithm (UORA): If it doesn't work the first time, hit the mouse button again. I'd rather build better systems than that. Furthermore, it's not so easy for embedded systems, which are increasingly likely to be mobile. And it would happen more and more often, as cell sizes shrink to offer more bandwidth. Lastly, I _agree_ with you that a mobile node should be able to use its temporary IP address for many such applications where retries are O.K, and transaction time short. While I'm spinning on this topic, I would like to point out that most of the recent problems that have been raised are involved with melding network authorization with Mobile IP. Putting in network authorization with Mobile IP might be easier than with any other infrastructure capable of rapid mobility, but it still isn't simple. I don't think that building up layer-2 mobility systems to replace the more natural mobility handling at layer-3 is the best way to make progress towards our future always-on, seamless mobility. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 17:13:32 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 RAA28283 for ; Fri, 7 Jan 2000 17:13:31 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F7F95C80@standards.nortelnetworks.com>; Fri, 7 Jan 2000 17:02:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 111853 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 17:01:36 -0500 Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DB6B5550@standards.nortelnetworks.com>; Fri, 7 Jan 2000 17:01:36 -0500 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Fri Jan 7 17:10:15 EST 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Fri Jan 7 17:10:14 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 1457C5701C; Fri, 7 Jan 2000 16:10:14 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200001070846.AAA18384@servo.qualcomm.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000107221014.1457C5701C@king.research.bell-labs.com> Date: Fri, 7 Jan 2000 16:10:14 -0600 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] AAA functionality X-To: Phil Karn To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200001070846.AAA18384@servo.qualcomm.com> Content-Transfer-Encoding: 7bit Hi, Phil, Phil Karn (PK) writes: >> It is also an issue for the carrier that wants to be more then a simple >> "pipe" to transport data over. I do agree that you are entitled to your PK> Ah, here we reach the crux of the issue. Speaking as a potential user PK> of your service, an IP "pipe" is all I want from you, and it's all I'm PK> willing to pay for. That's fine, and a Simple IP service will be available for customers like you. But carriers have also decided to provide a foreign agent service (with FA-located COA) for these networks, and I would argue that this does add value. I think we need to take into account current and future applications that need IP addresses to persist longer than the connectivity to a single base station or radio access network. The market will decide which one of us is right. Given that Mobile IP will be used, the advantages of FA-located COA include (in increasing order of importance, IMHO): 1) Reduced overhead on the air interface. Perhaps this is a red herring after mechanisms such as RFC2507 have been deployed, but I'm not sure how long that's going to take. 2) Reduced consumption of address space. Yes, we would like to provide a VPN service to mobile nodes where they don't even get a public address. This can be accomplished by concatenating the link-layer demux pipe with a Mobile IP pipe that originates at the FA. Both of the above are related to: 3) Simplified design of mobile nodes. Arguably, mobile nodes are made simpler if they only have to deal with one IP interface + a signaling protocol, rather than two IP interfaces, one with a Mobile IP encapsulation on it. This will ease the task of writing clients for existing operating systems (yes, I'm talking about Windows). Also, it would be nice to access a private network without having to implement IPSec on a handset. In this case hop-by-hop protection of traffic (using link-layer encryption) is good enough for a lot of people. 4) Future techniques for fast handoff. To support very low-latency handoff, some kind of forwarding mechanism needs to be in place at the old point of attachment. This service is one that cannot be provided end-to-end because the mobile node is no longer there at the time it is needed! It requires MIP signaling (using the Previous FA extension) and coordination with the network. All of the proposals for non-transparent micromobility (HAWAII, Cellular IP) require that the mobile node send MIP control messages to some entity in the network. 5) The "attendant" function. If you believe Chip's note about using true packet interfaces as opposed to circuit interfaces, which itself makes the end-to-end argument, then we need to replace PPP. Doing so while preserving all of the access controls that need to be provided is made possible by integrating such authorization with the Mobile IP registration process. PK> And it's not just me. I know I speak for many prospective users (the PK> ones who understand the issues, anyway) and for those who conceived PK> the Internet architecture. Go read the classic paper by Saltzer, Reed PK> & Clark, "End-to-End Arguments in System Design" PK> (http://people.qualcomm.com/karn/library.html). Certainly a good paper, and one of its points is that hop-by-hop measures are often appropriate for purposes of optimization. If carriers have decided to spend resources on optimizations like the above, who are we to argue? Most of the standards work has already been carried out in the Mobile IP working group and elsewhere. If we don't want to use them we can always fall back to Simple IP. -Pete From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 17:19: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 RAA28350 for ; Fri, 7 Jan 2000 17:19:23 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D07A78A0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 17:08:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 111891 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 17:07:30 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AE98C3E0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 17:07:30 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 7 Jan 2000 16:17:37 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Fri, 7 Jan 2000 17:17:16 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 7 Jan 2000 16:17:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF595C.F3FF7854" Message-ID: Date: Fri, 7 Jan 2000 16:17:14 -0600 Reply-To: Basavaraj Patil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: [MOBILE-IP] WG Opinion on MIER course? 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_01BF595C.F3FF7854 Content-Type: text/plain; charset="ISO-8859-1" Hello, After having had a discussion with our AD (Dave Oran) we have the following options for moving ahead with the MIER draft (draft-ietf-mobileip-mier-00.txt): 1. Do a WG last call for this draft requesting a Proposed standard status and have RFC2002-bis reference it for the definition of extensions. 2. Roll MIER into RFC2002-bis, which will be going to a WG last call soon. In view of the two drafts that are currently on the IESG plate, the MN-NAI draft and the Vendor specific extensions draft, the extensions defined in these drafts would have to be modified to the new mobile IP extension format. I would like to hear your views on the above two options. -Basavaraj ------_=_NextPart_001_01BF595C.F3FF7854 Content-Type: text/html; charset="ISO-8859-1" WG Opinion on MIER course?

Hello,

After having had a discussion with our AD (Dave Oran) we have
the following options for moving ahead with the MIER draft
(draft-ietf-mobileip-mier-00.txt):

1. Do a WG last call for this draft requesting a Proposed standard
   status and have RFC2002-bis reference it for the definition of
   extensions.
2. Roll MIER into RFC2002-bis, which will be going to a WG last call
   soon.

In view of the two drafts that are currently on the IESG plate, the
MN-NAI draft and the Vendor specific extensions draft, the extensions
defined in these drafts would have to be modified to the new mobile IP
extension format.

I would like to hear your views on the above two options.

-Basavaraj

------_=_NextPart_001_01BF595C.F3FF7854-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 18:43: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 SAA29085 for ; Fri, 7 Jan 2000 18:43:09 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.817F6470@standards.nortelnetworks.com>; Fri, 7 Jan 2000 18:32:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 111994 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 18:30:10 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3A858810@standards.nortelnetworks.com>; Fri, 7 Jan 2000 18:30:09 -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 PAA25712 for ; Fri, 7 Jan 2000 15:40:35 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA01897; Fri, 7 Jan 2000 15:40:34 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id PAA17672; Fri, 7 Jan 2000 15:40:23 -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: <200001072340.PAA17672@nasnfs.eng.sun.com> Date: Fri, 7 Jan 2000 15:37:31 -0800 Reply-To: pcalhoun@eng.sun.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: [MOBILE-IP] New Mobile-IP Internet Draft X-cc: pcalhoun@eng.sun.com, kempf@eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit All, I am submitting a new Internet Draft to the secretariat. I am including the I-Ds abstract below for your information. If you wish to get your hands on this draft before it is available in the archives, you can retrieve it at www.diameter.org/draft-calhoun-mobileip-proactive-fa-00.txt. The essence of the draft is that fast hand-offs using Mobile IP is a difficult thing to do. The route optimization draft proposes the binding update, that allows for a quicker hand-off, but there are still two issues when the binding update is used alone: 1. how does the new foreign agent get the security association from the previous foreign agent. 2. the mobile node must listen for advertisements in order to initiate the hand-off. The new proposal allows the new Foreign Agent to take a more proactive approach, by allowing it to send an indication to the mobile node that it must perform a hand-off. This proposal still requires that the route optimization's Binding Update be used between the Foreign Agents. We believe that this proposal, combined with the route optimization's Binding Update, will allow for fast hand-offs, similar to those seen in today's cellular networks. Note, this proposal only works with link layers that allow the foreign agent to measure signal strength, so one could not use this proposal over ethernet networks. Thanks, PatC ---- Abstract The Mobile IP WG has been investigating how its protocol can be used in environments that require fast hand-off, especially important for real-time applications such as voice and video. Certain link layers, such as those used in cellular networks, allow for the measurement of signal strength, which is typically used to determine when a hand-off is required. This specification defines extensions to the Mobile IP protocol, which allows the Foreign Agent to send an unsolicited message to the Mobile Node, requesting that the Mobile Node register with a new Foreign Agent. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 19:01: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 TAA29296 for ; Fri, 7 Jan 2000 19:01:08 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.07A89150@standards.nortelnetworks.com>; Fri, 7 Jan 2000 18:50:13 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 112043 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 18:50:05 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.02B8FCC0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 18:50: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 QAA01285; Fri, 7 Jan 2000 16:00:30 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA05709; Fri, 7 Jan 2000 16:00:28 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id QAA18393; Fri, 7 Jan 2000 16:00: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: <200001080000.QAA18393@nasnfs.eng.sun.com> Date: Fri, 7 Jan 2000 15:57:25 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] AAA functionality X-To: Phil Karn To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Allright, I'll bite. What *is* the access method in question? Are you talking about PPP? If so, the simple act of re-establishing PPP is quite high when a hand-off occurs. In our scenario, we are proposing that the carriers are delivering IP services (directly), and the service is requested through Mobile IP. Mobile IP will make use of AAA, in much the same way PPP does today. PatC >>telematics are two big ones). If we allow users a grace period they could >>potentially run their business without getting properly authorized. While >>there are possibly other ways to block this usage AAA is the best solution. > >Why is this an issue for you? In a properly layered network, Mobile IP >would be outside the scope of the wireless carrier. It would exist as >a co-located FA on the mobile user's computer and as a HA on the >user's home network, e.g., at his residence or business. That's if it >even existed at all, since MIP would be a user choice, and most mobile >users given the choice wouldn't need it in the first place. > >You would just charge for the user's generic internet access service, >and the behavior of MIP (or even its existence) wouldn't matter to >you. It would all just be billable user data to you. > >Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 20:26: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 UAA29839 for ; Fri, 7 Jan 2000 20:26:32 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ECB13940@standards.nortelnetworks.com>; Fri, 7 Jan 2000 20:15:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 112142 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 20:13:29 -0500 Received: from homer.ka9q.ampr.org (24.30.144.246) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.43C466A0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 20:03:28 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id RAA20516; Fri, 7 Jan 2000 17:13:41 -0800 References: <200001070846.AAA18384@servo.qualcomm.com> <20000107221014.1457C5701C@king.research.bell-labs.com> Message-ID: <200001080113.RAA20516@homer.ka9q.ampr.org> Date: Fri, 7 Jan 2000 17:13:41 -0800 Reply-To: karn@qualcomm.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Phil Karn Subject: Re: [MOBILE-IP] AAA functionality X-To: mccap@research.bell-labs.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <20000107221014.1457C5701C@king.research.bell-labs.com> (message from Pete McCann on Fri, 7 Jan 2000 16:10:14 -0600 (CST)) >that this does add value. I think we need to take into account >current and future applications that need IP addresses to persist >longer than the connectivity to a single base station or radio access >network. The market will decide which one of us is right. We agree that we should take this into account, even though I believe it's a minority requirement. I argue that the right way to do it is to put a FA in the mobile unit. >2) Reduced consumption of address space. This is also a red herring. In the simple IP service I envision, the user could say at setup time whether he needs a globally routable address, or if a net 10 address behind a NAT would be satisfactory. The vast majority of mobile network applications are pure clients, so they'd be happy with the NAT. (As far as I can tell, I don't get a choice with Sprint PCS. I get a net 10 address and the NAT, take it or leave it.) In the end, of course, we'll have no alternative but to deploy IPv6. It'll have to happen when the pain of not doing so exceeds the pain of transitioning. This discussion makes me think that may happen sooner than I thought. >Arguably, mobile nodes are made simpler if they only have to deal with >one IP interface + a signaling protocol, rather than two IP interfaces, >one with a Mobile IP encapsulation on it. This will ease the task of >writing clients for existing operating systems (yes, I'm talking about >Windows). I disagree. Most (all?) IP stacks already, or could easily, implement virtual interfaces that support tunneling. I suspect this already includes Windows. A mobile host with a pair of interfaces (one real and one virtual) would find it very straightforward to select between the two. Applications (usually servers, but possibly also long-lived telnet sessions) that need a fixed address regardless of location and are willing to pay the price in reduced performance would bind() to the virtual interface. This would automatically cause them to use MIP. Applications that don't care what local IP address they use (e.g., http, pop, smtp and other short lived clients) can bind to the real physical interface and bypass all of the MIP mechanisms and overhead. The two can coexist quite nicely on the same machine. I've done something much like this on my home Linux system ever since I got Road Runner cable modem service several years ago. My home machine runs servers (sendmail, ssh), but Road Runner issues dynamic IP addresses with DHCP. My solution is much like dual-interface MIP with a co-located FA, only I manage the tunnels manually instead of with the actual MIP registration protocols. ("Handoffs", i.e., IP address changes, are usually infrequent, so this hasn't been too much of a problem. The "home agent" is a Linux box sitting on the Qualcomm DMZ. I just ssh in and issue the appropriate routing commands). My local clients (which account for the vast majority of my traffic) use the RR-assigned address, so they communicate directly with their remote servers without using the tunnel at all. But when somebody sends me mail to my static address, the inbound packets are first routed to the machine on the Qualcomm DMZ, which encapsulates and re-routes the packets to my current RR IP address. My outbound replies are also tunneled, but only to evade a source address ingress filter in Road Runner's upstream path. Contrast this with a mobile node that only supports one interface, and a carrier-provided FA. MIP is either on or off, so if *any* mobile application needs MIP, they're *all* forced to use it. I could conceive of schemes that multiplex both kinds of traffic down the one interface to the carrier, but that's obviously so much more complicated and inelegant than the dual-interface approach that we needn't consider it. >Also, it would be nice to access a private network without having to >implement IPSec on a handset. In this case hop-by-hop protection of >traffic (using link-layer encryption) is good enough for a lot of >people. Only people who don't know any better. First of all, the link-layer "encryption" in *all* of the digital cellular systems is a joke. Even so, the real hazard has always been sniffers on ISP Ethernets along the way. Only end-to-end encryption (or possibly end-to-firewall encryption in the case of remote access to a corporate network) can provide any real security benefit. >All of the proposals for non-transparent micromobility (HAWAII, I confess that I'm concerned mainly with packet data on IS-95 CDMA, because that's what I've done for Qualcomm. CDMA has a "soft handoff" concept that can only be implemented down at the physical layer where individual channel symbols can be combined. It is just not possible to do it in Mobile IP on a per-packet basis. This means that CDMA systems have (and will always have) substantial intra-network mobility that greatly lessens the need for higher-layer mobility. A single CDMA system generally covers an entire metropolitan area, although this might not be true for some very large cities. In either case, the average inter-system handoff interval (i.e., where MIP would be of use) is extremely long compared with the average user session length, to say nothing of the average user transaction length. (By "transaction" I mean a TCP connection from start to finish, e.g., a GET from a webserver, or a POP or SMTP session to relay mail.) I understand that Mobile IP is being considered for intra-system mobility in some dense micro-cellular environments. Here I have less of a problem with it, since the routing inefficiencies are over shorter distances. But this does not alleviate the need for a co-located FA for the mobile user who needs true mobility, as he will probably need to roam to other networks without FAs, and also to avoid the use of wide-area MIP when it is not desired. And if you do control your whole network, why not just use a standard internal routing protocol like OSPF to keep track of your users as they move? Or you could punt with routing altogether and use Ethernet switching (bridging). >If you believe Chip's note about using true packet interfaces as >opposed to circuit interfaces, which itself makes the end-to-end >argument, then we need to replace PPP. Doing so while preserving all >of the access controls that need to be provided is made possible by >integrating such authorization with the Mobile IP registration >process. I haven't seen Chip's note yet, but there's another way to preserve access controls in a "true packet environment": IPSEC. >Certainly a good paper, and one of its points is that hop-by-hop >measures are often appropriate for purposes of optimization. If Actually, the statement was that lower-level functionality can sometimes be justified as a performance enhancement. This is clearly true; link level retransmission is the archetype. I put a link-level retransmission scheme into the radio link layer protocol I designed for IS-95. I see no similar performance enhancement associated with carrier-provided MIP, with the possible exception of reduced header overhead (which has already been discussed). On the contrary, I see a very big performance penalty assocated with MIP, namely suboptimal routing, and substantially increased network complexity. Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jan 8 02:01: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 CAA09233 for ; Sat, 8 Jan 2000 02:01:02 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A53D6690@standards.nortelnetworks.com>; Sat, 8 Jan 2000 1:49:48 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 112424 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 8 Jan 2000 01:47:52 -0500 Received: from homer.ka9q.ampr.org (24.30.144.246) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FA0AC2A0@standards.nortelnetworks.com>; Sat, 8 Jan 2000 1:37:51 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id WAA21188; Fri, 7 Jan 2000 22:48:02 -0800 References: <45AFD48D077ED211BB4700A0C9DCE8FD15ADD6@monza.broadswitch.com> Message-ID: <200001080648.WAA21188@homer.ka9q.ampr.org> Date: Fri, 7 Jan 2000 22:48:02 -0800 Reply-To: karn@qualcomm.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Phil Karn Subject: Re: [MOBILE-IP] Cellular IP for Private Network Access X-To: thomas.eklund@switchcore.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <45AFD48D077ED211BB4700A0C9DCE8FD15ADD6@monza.broadswitch.com> (message from Thomas Eklund on Fri, 7 Jan 2000 11:19:34 +0100) >Because the address space is not enough.... >Thats because they are running there systems on IPv4 and dont have enough >addresses so they have to use private addresses and "share a smaller pool of >global addresses" when they access the Internet.. This of course is a bad >design and put several security restrictions on your network. Well, given their current data airtime prices, I don't think Sprint PCS will have to worry about address exhaustion anytime soon. Your average generic dialup ISP charges a heck of a lot less than Sprint does and they don't seem to have any problem giving their customers global addresses for the duration of their connections. So do the cable modem services I know about (@Home and Road Runner). Actually, I think private addresses and a NAT would be acceptable to the vast majority of wireless data users for the same reason that MIP isn't very useful -- nearly all of the applications are network clients, not servers. >This is not true...!! The mobility signalling is very heavy, especially how >it is designed in today's mobileip... There are though efforts that try to I'm thinking mainly about IS-95 CDMA, which has considerable intra-system mobility for some good reasons (e.g., support of soft-handoff). This makes a MIP handoff a pretty rare event, so rare that most users probably wouldn't need MIP at all. Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 9 00: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 AAA10928 for ; Sun, 9 Jan 2000 00:06:26 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BBDBF650@standards.nortelnetworks.com>; Sat, 8 Jan 2000 23:54:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 112693 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 8 Jan 2000 23:53:56 -0500 Received: from smtpgw2.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9FAD4D30@standards.nortelnetworks.com>; Sat, 8 Jan 2000 23:53:55 -0500 Received: from pkcex003.sprintspectrum.com (pkcex003.sprintspectrum.com [208.10.75.138]) by smtpgw2.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id PAA13257; Sat, 8 Jan 2000 15:28:47 -0600 (CST) Received: by pkcex003.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id ; Sat, 8 Jan 2000 15:28:47 -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: Sat, 8 Jan 2000 15:28:46 -0600 Reply-To: "Lipford, Mark" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lipford, Mark" Subject: Re: [MOBILE-IP] Cellular IP for Private Network Access X-To: Phil Karn To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Phil, I will not get into a discussion of the validity of NDA related issues (see person e-mail to you). I will point out that if you are having issues connecting your Linus machine to the Internet from our CDMA network you AND you are doing it via the 3Com QNC technology there is a very simple explanation why you are having trouble. We currently DO NOT offer this service. The only services we offer using QNC is via the built-in microbrowser. We are working of developing a product that will allow direct access to the Internet and are working to put the appropriate back-end equipment into place. Once we have the network ready for the service then we will announce and launch the product. So I would argue that your description is not accurate. Regards -----Original Message----- From: Phil Karn [mailto:karn@QUALCOMM.COM] Sent: Friday, January 07, 2000 2:33 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Cellular IP for Private Network Access >Sprint PCS would ask that the design of our network not be discussed over >ANY public mail list. There are issues with NDA that we do not want to have >remind these companies of. Please stop this thread with this email! My description of Sprint PCS's packet data service was based totally on my personal observations using my personally-owned phone, a data cable and a laptop running Linux. ANY Sprint PCS user who knows how to use standard Linux/UNIX networking tools such as pppd, netstat and traceroute can easily discern the very same information in a few minutes. It can hardly be considered proprietary. If my description is no longer accurate, I would appreciate any corrections you might make. I stopped using the service when my first bill gave me sticker shock. Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 9 00: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 AAA10930 for ; Sun, 9 Jan 2000 00: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.BBFD39F0@standards.nortelnetworks.com>; Sat, 8 Jan 2000 23:54:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 112697 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 8 Jan 2000 23:53:56 -0500 Received: from smtpgw2.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9FE8F6A0@standards.nortelnetworks.com>; Sat, 8 Jan 2000 23:53:56 -0500 Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw2.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id PAA13267; Sat, 8 Jan 2000 15:28:51 -0600 (CST) Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id ; Sat, 8 Jan 2000 15:28:52 -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: Sat, 8 Jan 2000 15:28:48 -0600 Reply-To: "Lipford, Mark" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lipford, Mark" Subject: Re: [MOBILE-IP] AAA functionality X-To: Phil Karn To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I would disagree with your statement that we see no value in being just a "pipe" I believe that being a pipe is a service we should and will provide. I also believe there are users that want more then a pipe. We need to be prepared to be that as well. Per a different thread I have indicated that some of your current comments are not accurate, therefore I will not bore this group with the details again. Regards -----Original Message----- From: Phil Karn [mailto:karn@qualcomm.com] Sent: Friday, January 07, 2000 2:47 AM To: MLipfo01@SPRINTSPECTRUM.COM Cc: MOBILE-IP@standards.nortelnetworks.com; karn@qualcomm.com Subject: Re: [MOBILE-IP] AAA functionality >It is also an issue for the carrier that wants to be more then a simple >"pipe" to transport data over. I do agree that you are entitled to your Ah, here we reach the crux of the issue. Speaking as a potential user of your service, an IP "pipe" is all I want from you, and it's all I'm willing to pay for. And it's not just me. I know I speak for many prospective users (the ones who understand the issues, anyway) and for those who conceived the Internet architecture. Go read the classic paper by Saltzer, Reed & Clark, "End-to-End Arguments in System Design" (http://people.qualcomm.com/karn/library.html). This one paper is so fundamental that I've often thought prospective IETFers (especially those affiliated with telcos) should be required to read it and pass a test before they can participate in any IETF working group. :-) Unfortunately, many carriers (not just Sprint) see no glamor in being pipe providers, even though they can make plenty of money if they do it well and at reasonable cost. It's a widespread problem that also afflicts cable modem networks, for example. Fortunately, my own cable modem provider is proving themselves so incompetent at operating all these superfluous network functions that they're being forced to eliminate them just to keep the packets flowing. Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 9 02:23: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 CAA22955 for ; Sun, 9 Jan 2000 02:23:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DE182C80@standards.nortelnetworks.com>; 9 Jan 2000 2:11:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 112981 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 9 Jan 2000 02:10:52 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C0F3FFD0@standards.nortelnetworks.com>; 9 Jan 2000 2:10:52 -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 LAA05795; Sat, 8 Jan 2000 11:12:36 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id LAA17860; Sat, 8 Jan 2000 11:12:36 -0800 X-Virus-Scanned: Sat, 8 Jan 2000 11:12:36 -0800 Nokia Silicon Valley AntiVirus Appliance Received: from (maxdialin4.iprg.nokia.com [205.226.20.234]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma017776; Sat, 8 Jan 00 11:12:32 -0800 X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38778B99.C408BBDE@iprg.nokia.com> Date: Sat, 8 Jan 2000 11:10:17 -0800 Reply-To: charliep@iprg.nokia.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "C. Perkins/D. Reese" Subject: Re: [MOBILE-IP] WG Opinion on MIER course? X-cc: Basavaraj Patil , oran@cisco.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I think there are other alternatives. I agree that MIER would fit well in RFC2002-bis. Failing that, I would like to strongly suggest that MIER become an informational draft, not a Proposed Standard. My reasoning for this is simple. MIER does not specify any protocol. Second, the draft that I read had some _guidelines_ in the Appendix. I do not think that those guidelines should be considered binding on the design for whatever generalized extensions would be eventually be specified. For instance, the Challenge draft has a fully specified Generalized Authentication Extension, along with the definition for a particular subtype of that generalized extension. I expect that a revised Route Optimization draft will specify another subtype for that extension, and that the Regional Registration draft will specify yet another subtype. These definitions do conform to the guideline in MIER, the last time I looked. However, I do not expect that an NAI generalized extension, should one ever be defined, would need to conform to the guideline in the MIER appendix. I'll hold off on sending out the revised RFC2002-bis until I hear whether working group members wish to include MIER in that draft. I'd also like to suggest that the NAI draft be allowed to go forward before the MIER questions are resolved. Some people have been waiting a long time for that draft. Regards, Charlie P. Basavaraj Patil wrote: > > > Hello, > > After having had a discussion with our AD (Dave Oran) we have > the following options for moving ahead with the MIER draft > (draft-ietf-mobileip-mier-00.txt): > > 1. Do a WG last call for this draft requesting a Proposed standard > status and have RFC2002-bis reference it for the definition of > extensions. > 2. Roll MIER into RFC2002-bis, which will be going to a WG last call > soon. > > In view of the two drafts that are currently on the IESG plate, the > MN-NAI draft and the Vendor specific extensions draft, the extensions > defined in these drafts would have to be modified to the new mobile IP > > extension format. > > I would like to hear your views on the above two options. > > -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 9 08:43: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 IAA07930 for ; Sun, 9 Jan 2000 08:43:28 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.08381180@standards.nortelnetworks.com>; 9 Jan 2000 8:32:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 113411 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 9 Jan 2000 08:31:46 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F6C8DF60@standards.nortelnetworks.com>; 9 Jan 2000 8:31: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 FAA25267 for ; Sun, 9 Jan 2000 05:42:17 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id FAA23408 for ; Sun, 9 Jan 2000 05:42:16 -0800 X-Virus-Scanned: Sun, 9 Jan 2000 05:42:16 -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) xma023324; Sun, 9 Jan 00 05:42:14 -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: <38789036.C5478A2D@iprg.nokia.com> Date: Sun, 9 Jan 2000 05:42:14 -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] [Fwd: Re: [MOBILE-IP] WG Opinion on MIER course?] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I tried to send this message from home, but I think it got bounced. If this looks like a duplicate, please accept my apologies. Regards, Charlie P. -------- Original Message -------- Subject: Re: [MOBILE-IP] WG Opinion on MIER course? Date: Sat, 08 Jan 2000 11:10:17 -0800 From: "C. Perkins/D. Reese" Reply-To: charliep@iprg.nokia.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM CC: Basavaraj Patil , oran@cisco.com References: I think there are other alternatives. I agree that MIER would fit well in RFC2002-bis. Failing that, I would like to strongly suggest that MIER become an informational draft, not a Proposed Standard. My reasoning for this is simple. MIER does not specify any protocol. Second, the draft that I read had some _guidelines_ in the Appendix. I do not think that those guidelines should be considered binding on the design for whatever generalized extensions would be eventually be specified. For instance, the Challenge draft has a fully specified Generalized Authentication Extension, along with the definition for a particular subtype of that generalized extension. I expect that a revised Route Optimization draft will specify another subtype for that extension, and that the Regional Registration draft will specify yet another subtype. These definitions do conform to the guideline in MIER, the last time I looked. However, I do not expect that an NAI generalized extension, should one ever be defined, would need to conform to the guideline in the MIER appendix. I'll hold off on sending out the revised RFC2002-bis until I hear whether working group members wish to include MIER in that draft. I'd also like to suggest that the NAI draft be allowed to go forward before the MIER questions are resolved. Some people have been waiting a long time for that draft. Regards, Charlie P. Basavaraj Patil wrote: > > > Hello, > > After having had a discussion with our AD (Dave Oran) we have > the following options for moving ahead with the MIER draft > (draft-ietf-mobileip-mier-00.txt): > > 1. Do a WG last call for this draft requesting a Proposed standard > status and have RFC2002-bis reference it for the definition of > extensions. > 2. Roll MIER into RFC2002-bis, which will be going to a WG last call > soon. > > In view of the two drafts that are currently on the IESG plate, the > MN-NAI draft and the Vendor specific extensions draft, the extensions > defined in these drafts would have to be modified to the new mobile IP > > extension format. > > I would like to hear your views on the above two options. > > -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 9 09:17: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 JAA08115 for ; Sun, 9 Jan 2000 09: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.CA08EEC0@standards.nortelnetworks.com>; 9 Jan 2000 9:06:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 113453 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 9 Jan 2000 09:04:29 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.894C5CA0@standards.nortelnetworks.com>; 9 Jan 2000 9:04:29 -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 GAA26461; Sun, 9 Jan 2000 06:14:23 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id GAA25178; Sun, 9 Jan 2000 06:14:22 -0800 X-Virus-Scanned: Sun, 9 Jan 2000 06:14: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) xma025093; Sun, 9 Jan 00 06:14: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: <200001070846.AAA18384@servo.qualcomm.com> <20000107221014.1457C5701C@king.research.bell-labs.com> <200001080113.RAA20516@homer.ka9q.ampr.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <387897BB.7D60763@iprg.nokia.com> Date: Sun, 9 Jan 2000 06:14: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] AAA functionality X-To: karn@qualcomm.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Phil, I'm a bit constrained for time, so I cannot respond to all the points in your thoughtful notes. But I notice the following incongruity. On the one hand, you say: > The vast majority of mobile network applications are > pure clients, so they'd be happy with the NAT. On the other hand, you say: > I know I speak for many prospective users (the > ones who understand the issues, anyway) and for those who conceived > the Internet architecture. Go read the classic paper by Saltzer, Reed > & Clark, "End-to-End Arguments in System Design" > (http://people.qualcomm.com/karn/library.html). Great paper, worth rereading. But I don't see NAT as a way towards promoting the design principles articulated in that paper. Or, towards promoting IPsec either, which is relevant to other parts of your recent notes. I might reformulate the basic design principle by observing that applications that do not want to be mobility-aware must rely on implementation of mobility in lower layers of the system design. > In the end, of course, we'll have no alternative but to deploy IPv6. > It'll have to happen when the pain of not doing so exceeds the pain of > transitioning. Furthermore, IPv6 has a nicer mobility story. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 9 18:08: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 SAA10870 for ; Sun, 9 Jan 2000 18:08:20 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F6554420@standards.nortelnetworks.com>; 9 Jan 2000 17:57:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 113924 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 9 Jan 2000 17:56:46 -0500 Received: from mullian.ee.mu.OZ.AU by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E46C7530@standards.nortelnetworks.com>; 9 Jan 2000 17:56:45 -0500 Received: from ee.mu.oz.au (cell.ee.mu.OZ.AU [128.250.76.149]) by mullian.ee.mu.OZ.AU (8.9.1a/8.9.1) with ESMTP id KAA13134; Mon, 10 Jan 2000 10:07:08 +1100 (EST) X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <3B9AA5E712DCD011AAD500609770A0E9203840@tokyo.ttd.neceur.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38791499.1103AF39@ee.mu.oz.au> Date: Mon, 10 Jan 2000 10:07:05 +1100 Reply-To: Rami Gabriel Mukhtar Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Rami Gabriel Mukhtar Subject: Re: [MOBILE-IP] 3G Mobile Architectures X-To: "BINAR, Simon" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Simon, I understand some of your concerns, here are some comments: > - If I connect base stations directly to an IP network (a bunch of > routers, presumably), where will the Radio Resources Management (RRM) > function reside? In GSM, this was typically in the BSC, and in UMTS, > this is in the RNC. If I put RRM functionality into every single base > station, I will end-up with extremely expensive (and un-sellable) base > stations. Thus, the RRM function would need to be located somewhere in > the IP network, maybe in a server? If I do this, what impact will this > have on system performance (I am especially thinking about handover > latency). Your concern is valid! I have heard a lot of talk about how handoffs will be handled and the latency an IP network will introduce if it is used for signaling purposes. But why should an IP network be any slower then any other wire line network such as a GSM core network???? I think the trap is that people get confused between an IP network that will have a SLA to support the real time traffic, and the current PUBLIC Internet in its current state. They are two very different things! The current internet has grown to support explosive mostly elastic type traffic. Telco's in the future will build packet networks (IP) specifically to support real time traffic, there is no reason why they will be any worse in supporting signaling traffic then a dedicated network. > Should I have local servers to handle local areas (in order to > improve system performance), or one single super-server to deal with the > entire network? Obviously, if I use local servers, this will look much > more like the "old" access networks of GSM and UMTS. This will also > reduce the flexibility of the network that you mentioned. > I don't think RRM is such a difficult task to manage. In my opinion the IP address will terminate at the base station and then you will have a point to point link to the mobile. Applications that have strict bandwidth requirements will be able to request a particular bandwidth from lower layers, for the last leg of the link. I don't think this is too much to ask from a base station, ie: who to give bandwidth to (yes, specific protocols will need to be established). In GSM you have a connection orientated system with a whole lot of its own protocols. When you make a connection the HLR (maybe VLR) needs to be accessed, in IP this access is done by the home agent, connections need to be maintained BY THE NETWORK, in IP the connection is maintained by higher layers (transmission, application). This would make resource management a lot simpler in an IP network. Functions that have dedicated hardware in a GSM network can be implemented on a server or in an application on an IP network, thus demanding less of the network itself. Also some of these functions can be shared across networks, ie a home agent will be used regardless of using GPRS, IMT-2000 or IEEE802.11, this saves on a lot of infrastructure! > - The argument about re-using existing infrastructure needs to be > considered with care. I think your scenario would apply to a very > specific case, say, an ISP that wishes to get into the mobile networking > business. In this case, having the ability to connect base stations > directly to the existing IP infrastructure would be really great (of > course, additional functions would also be required for billing, > authorisation and accounting, etc...). But most mobile network operators > already have infrastructure in place. If we look at a scenario in 3-5 > years time where most mobile operators have either GPRS or a variant of > an IMT-2000 network, then the infrastructure is already in place, and > expanding that infrastructure shouldn't really be an issue. What about expanding to another network type. How compatible are GSM PLMN components with an IMT-2000 PLMS network??? I think it would be better to have a common end to end core network like IP then building customized high level gateways to bridge different RAN PLMN technologies together. Kind Regards, -- Rami Mukhtar ___________________________________________ Post Graduate Student Telecommunications Group The University of Melbourne Ph: (03) 9344-9207 WWW: http://www.ee.mu.oz.au/pgrad/rgmukht ___________________________________________ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 9 18:28:15 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 SAA10946 for ; Sun, 9 Jan 2000 18:28:15 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C3B185D0@standards.nortelnetworks.com>; 9 Jan 2000 18:17:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 113963 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 9 Jan 2000 18:16:04 -0500 Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3182D7F0@standards.nortelnetworks.com>; 9 Jan 2000 18:06:04 -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 BAA48154; Mon, 10 Jan 2000 01:16:35 +0200 (EET) X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.3 i686) MIME-Version: 1.0 References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <387916F9.E70823A9@cc.hut.fi> Date: Mon, 10 Jan 2000 01:17:13 +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] AAA functionality To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hello, I bring in my vote for the grace period... N. Asokan wrote: > > I think whether to allow free time or not is ultimately a policy issue. > Seems to me that we shouldn't devise a mechanism that precludes that > policy. I agree with Asokan, Patrik and others, that allowing the grace period is a policy issue. Furthermore, we should not forbid such liberal policies with our protocol design! Telcos may not like the possibility of using their network even for short periods of time. However, telcos are certainly not the only ones providing wireless services in the future. As someone pointed out earlier, the pure Ip accessibility may even not be the ultimate source for cash flows. I hope every university lab or airport lobby bar will be able to set up its own wireless AP and start providing access to the Internet. As the number of access provider increases, the number of "inter-domain" handoffs may significantly increase. I really do not want to mandate _everyone_ to disable the grace period and thus end up in rediculous latencies and unbearable glitches in the connections. Best regards, Tom -- Tom Weckström tweckstr@cc.hut.fi Otakaari 20 B 39 Helsinki University of Technology 02150 Espoo Department of Computer Science From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 9 18:53: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 SAA11100 for ; Sun, 9 Jan 2000 18:53:25 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.45653AB0@standards.nortelnetworks.com>; 9 Jan 2000 18:42:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 114051 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 9 Jan 2000 18:40:53 -0500 Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A8EBF7B0@standards.nortelnetworks.com>; 9 Jan 2000 18:30:52 -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 BAA48276; Mon, 10 Jan 2000 01:41:25 +0200 (EET) X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.3 i686) MIME-Version: 1.0 References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <38791CCA.C2589DCD@cc.hut.fi> Date: Mon, 10 Jan 2000 01:42:02 +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] AAA functionality To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hi, My comments about the Parallel vs Sequential AAA&MIP processing: If we can find a way to support a parallel processing of MIP and AAA signaling, I really support that. I think mixing MIP and AAA too much with each other is not a a good solution. Also, encapsulation the other's messages entirely inside other's messages seems both unnecessary and inefficient. Could we define the requirements for the interfaces between the AAA protocol and the MIP protocol to support parallel processing of these protocols? I think it would be possible. The picture I have in mind has two messaging flows, the original MIP and the AAA. AAA flow would happen at a smaller range (inside the core) (i.e. FA <-> AAAF <-> Broker / HA <-> AAAH <-> Broker) while the MIP would cover all the way from MN to HA. Here is my proposal: (message flows in a successfull registration) 1. The reg.request with enough information for Autorization and Authentication originates from the MN. 2. The reg.req. is processed by the FA. 3. An AAA message is send by the FA (either to AAAF or to a broker) The FA uses the information from the MIP reg.req. to build the AAA message. At the same time the MIP reg.req. is forwarded to the HA. 4. The MIP reg.req. is processed by the HA. 5. HA answers to MN with a MIP reg.reply. (E.g. according to MN authentication, but the user remains unauthenticated at the moment.) 6. Reg.reply reaches FA and MN, and MN starts using the network. (Alternatively we might stop the reply at FA to wait for the AAA approval, but the MN could try to access the network even without the received reply.) 7. An AAA message exchange happens between HA, AAAH, the Broker / AAAF, and other AAA elements. The user is authenticated and authorized, Acocunting begins. Finally, the FA gets the AAA approval/denial. 8. FA sends a new reg.reply or the postponed original reg.reply or a reg.reply with a correct denial code to the MN. The interface we would need here would contain: - FAs ability to fomulate AAA messages to AAAF (AAA module) - HAs ----------------- " --------------- AAAH ---- " ---- - FAs and HAs ability to understand the AAA messages and to generate replies according to them. I would claim this approach beats the sequential approach in efficiency by far. Your comments about possible weaknesses of this rapidly hacked parallelism example are most welcome! Best regards, Tom Patrik Flykt wrote: > > Hi, > > >Perhaps I am missing something, but I *really* don't see how the AAA > >and Mobile-IP requests can be done in parallel. If a requirement is > >that it must be possible to separate the two, then I would prefer to > >see that both requests are done sequentially, first AAA then Mobile-IP. > >This would remove many strange interactions, and would be a much cleaner > >approach. > > I suppose there is a requirement that AAA and MIP messages can be separated > (be it parallell or serial message sending). When you pay for access with > your credit card the authorization/accounting goes to the credit card > company's AAA server, while the Mobile IP messages go to your home agent. > > The sequential approach is extremely useful if the only case of using AAA > with MIP is to ensure that the provider of the foreign agent is able to > account for every second of foreign agent usage. However, the provider could > also be interested in allowing a short grace period to ensure that the > real-time applications used in the mobile node would experience the shortest > possible service disruption. I suppose the AAA processing will take at least > a couple of seconds and even longer when there are several brokers between > the visited and home domains. The grace period enables of course a > possibility of fraud, which the provider has to take into account. > Minimizing fraud could be done for example by allowing the grace period only > to those who have visited the same provider's network earlier and have been > given a session key, as described in the "Minimal Latency Secure Hand-off" > draft. There is also a third possibility when the provider is providing free > access for everyone without any accounting but with authorization. The > provider wants to be sure that the home AAA domain authorizes the mobile > node, i.e. it is not stolen, in the (for some reason) wrong domain, etc. > > Regards, > > Patrik -- Tom Weckström tweckstr@cc.hut.fi Otakaari 20 B 39 Helsinki University of Technology 02150 Espoo Department of Computer Science From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 9 19:51: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 TAA11378 for ; Sun, 9 Jan 2000 19:51:33 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.63238AE0@standards.nortelnetworks.com>; 9 Jan 2000 19:40:30 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 114127 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 9 Jan 2000 19:38:48 -0500 Received: from telecom.samsung.co.kr (165.213.221.4) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BFF0EFD0@standards.nortelnetworks.com>; 9 Jan 2000 19:28:47 -0500 Received: from keg ( [165.213.177.180] (may be forged)) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id JAA17647 for ; Mon, 10 Jan 2000 09:38:41 +0900 (KST) MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Message-ID: <008201bf5b02$9256fda0$b4b1d5a5@keg.telecom.samsung.co.kr> Date: Mon, 10 Jan 2000 09:35:10 +0900 Reply-To: Woo-June Kim Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Woo-June Kim Subject: [MOBILE-IP] Mobile IP Implementations for Windows .. To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id TAA11378 Hi All, Does anyone have any idea whether those folks at Microsoft are planning on implementing Mobile IP in the new Windows 2000 ? Additionally I've heard of some experimental implementations of Mobile IP for Windows, but are there any commercial products available ? thanks Woojune Kim, Senior Engineer Samsung Electronics Ltd. tel : +82-342-779-8526 hp : +82-11-368-7480 e-mail : keg@telecom.samsung.co.kr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 9 21:53:32 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 VAA12861 for ; Sun, 9 Jan 2000 21: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.523FE730@standards.nortelnetworks.com>; 9 Jan 2000 21:41:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 114274 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 9 Jan 2000 21:40:05 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.17808910@standards.nortelnetworks.com>; 9 Jan 2000 21:40:05 -0500 Received: from zmers013 by smtprch1.nortel.com; Sun, 9 Jan 2000 20:49:02 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Sun, 9 Jan 2000 21:48:46 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Sun, 9 Jan 2000 20:48:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5B15.35FF1F7A" Message-ID: <9A9367D1556AD21182C40000F80930AB010BC192@crchy28b.us.nortel.com> Date: Sun, 9 Jan 2000 20:48:43 -0600 Reply-To: Mohamed Khalil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohamed Khalil Subject: Re: [MOBILE-IP] WG Opinion on MIER course? 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_01BF5B15.35FF1F7A Content-Type: text/plain I think considering MIER draft as a Proposed standard is a better option of the WG for the following two reasons: 1- It will guarantee consistency of using the new extension among all future drafts and it will be much less confusing for people. 2- If the material is folded in other drafts, the authors of MIER should join the list of authors for those drafts. I don't think that the other drafts' authors would like this to happen, but I might be mistaken. Also, I agree with Charlie that the NAI draft should go forward. . > -----Original Message----- > From: C. Perkins/D. Reese [SMTP:charliep@IPRG.NOKIA.COM] > Sent: Saturday, January 08, 2000 1:10 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] WG Opinion on MIER course? > > I think there are other alternatives. > > I agree that MIER would fit well in RFC2002-bis. Failing that, > I would like to strongly suggest that MIER become an informational > draft, not a Proposed Standard. My reasoning for this is simple. > MIER does not specify any protocol. > > Second, the draft that I read had some _guidelines_ in the > Appendix. I do not think that those guidelines should be > considered binding on the design for whatever generalized > extensions would be eventually be specified. > > For instance, the Challenge draft has a fully specified > Generalized Authentication Extension, along with the > definition for a particular subtype of that generalized > extension. I expect that a revised Route Optimization > draft will specify another subtype for that extension, and > that the Regional Registration draft will specify yet another > subtype. These definitions do conform to the guideline in > MIER, the last time I looked. > > However, I do not expect that an NAI generalized extension, > should one ever be defined, would need to conform to the > guideline in the MIER appendix. > > I'll hold off on sending out the revised RFC2002-bis until I > hear whether working group members wish to include MIER > in that draft. > > I'd also like to suggest that the NAI draft be allowed to go > forward before the MIER questions are resolved. Some > people have been waiting a long time for that draft. > > Regards, > Charlie P. > > Basavaraj Patil wrote: > > > > > > > Hello, > > > > After having had a discussion with our AD (Dave Oran) we have > > the following options for moving ahead with the MIER draft > > (draft-ietf-mobileip-mier-00.txt): > > > > 1. Do a WG last call for this draft requesting a Proposed standard > > status and have RFC2002-bis reference it for the definition of > > extensions. > > 2. Roll MIER into RFC2002-bis, which will be going to a WG last call > > soon. > > > > In view of the two drafts that are currently on the IESG plate, the > > MN-NAI draft and the Vendor specific extensions draft, the extensions > > defined in these drafts would have to be modified to the new mobile IP > > > > extension format. > > > > I would like to hear your views on the above two options. > > > > -Basavaraj ------_=_NextPart_001_01BF5B15.35FF1F7A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] WG Opinion on MIER course?

     I think considering MIER draft = as a Proposed standard is  a better option of the WG for the = following two reasons:
    1- It will guarantee consistency of = using the new extension among all  future drafts and it will be = much less confusing  for people.

    2- If the material is folded in other = drafts,  the authors of MIER should join the list of authors for = those drafts. I don't think that the other drafts' authors would like = this to happen, but I might be mistaken.

    Also, I agree with Charlie that the = NAI draft should go forward.
    .


    -----Original Message-----
    From:   C. Perkins/D. Reese = [SMTP:charliep@IPRG.NOKIA.COM]
    Sent:   Saturday, January 08, 2000 1:10 PM
    To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: [MOBILE-IP] WG Opinion on MIER = course?

    I think there are other = alternatives.

    I agree that MIER would fit well in = RFC2002-bis.  Failing that,
    I would like to strongly suggest that = MIER become an informational
    draft, not a Proposed Standard.  = My reasoning for this is simple.
    MIER does not specify any = protocol.

    Second, the draft that I read had some = _guidelines_ in the
    Appendix.  I do not think that = those guidelines should be
    considered binding on the design for = whatever generalized
    extensions would be eventually be = specified.

    For instance, the Challenge draft has = a fully specified
    Generalized Authentication Extension, = along with the
    definition for a particular subtype = of that generalized
    extension.  I expect that a = revised Route Optimization
    draft will specify another subtype = for that extension, and
    that the Regional Registration draft = will specify yet another
    subtype.  These definitions do = conform to the guideline in
    MIER, the last time I looked.

    However, I do not expect that an NAI = generalized extension,
    should one ever be defined, would = need to conform to the
    guideline in the MIER = appendix.

    I'll hold off on sending out the = revised RFC2002-bis until I
    hear whether working group members = wish to include MIER
    in that draft.

    I'd also like to suggest that the NAI = draft be allowed to go
    forward before the MIER questions are = resolved.  Some
    people have been waiting a long time = for that draft.

    Regards,
    Charlie P.

    Basavaraj Patil wrote:

    >
    >
    > Hello,
    >
    > After having had a discussion = with our AD (Dave Oran) we have
    > the following options for moving = ahead with the MIER draft
    > = (draft-ietf-mobileip-mier-00.txt):
    >
    > 1. Do a WG last call for this = draft requesting a Proposed standard
    >    status and = have RFC2002-bis reference it for the definition of
    >    = extensions.
    > 2. Roll MIER into RFC2002-bis, = which will be going to a WG last call
    >    soon.
    >
    > In view of the two drafts that = are currently on the IESG plate, the
    > MN-NAI draft and the Vendor = specific extensions draft, the extensions
    > defined in these drafts would = have to be modified to the new mobile IP
    >
    > extension format.
    >
    > I would like to hear your views = on the above two options.
    >
    > -Basavaraj

------_=_NextPart_001_01BF5B15.35FF1F7A-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 9 22:45: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 WAA14132 for ; Sun, 9 Jan 2000 22:45:07 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9B916B00@standards.nortelnetworks.com>; 9 Jan 2000 22:33:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 114390 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 9 Jan 2000 22:32:43 -0500 Received: from apprentice.qualcomm.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.71B6D950@standards.nortelnetworks.com>; 9 Jan 2000 22:32:43 -0500 Received: from cx871310-a (primemover-client24.qualcomm.com [129.46.86.89]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.15) with SMTP id TAA04836; Sun, 9 Jan 2000 19:43:00 -0800 (PST) X-Sender: jwillkie@apprentice.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.1.20000109192820.0098dd80@apprentice.qualcomm.com> Date: Sun, 9 Jan 2000 19:33:13 -0800 Reply-To: Jim Willkie Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jim Willkie Subject: Re: [MOBILE-IP] Mobile IP Implementations for Windows .. X-To: Woo-June Kim To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <008201bf5b02$9256fda0$b4b1d5a5@keg.telecom.samsung.co.kr> At 09:35 AM 01/10/2000 +0900, Woo-June Kim wrote: >Hi All, > >Does anyone have any idea whether those folks at Microsoft are planning on >implementing Mobile IP in the new Windows 2000 ? Msoft has stated many times at different forums that MIP is not planned to be bundled into any of their desktop OSs. From what I have heard they may put MIP into Windows CE at some point, but I have not heard or seen anything recent from them on this topic. Jim Willkie From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 9 22:57: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 WAA14183 for ; Sun, 9 Jan 2000 22:57:51 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4B9BAEB0@standards.nortelnetworks.com>; 9 Jan 2000 22:45:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 114407 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 9 Jan 2000 22:44:19 -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.AAD50A90@standards.nortelnetworks.com>; 9 Jan 2000 22:34:18 -0500 Received: from mbb6.ericsson.se (mbb6.ericsson.se [136.225.151.211]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id EAA25266 for ; Mon, 10 Jan 2000 04:44:51 +0100 (MET) Received: from CONVERSION-DAEMON by mbb6.ericsson.se (PMDF V5.2-29 #33628) id <0FO300A01P2REH@mbb6.ericsson.se> for MOBILE-IP@standards.nortelnetworks.com; Mon, 10 Jan 2000 04:44:51 +0100 (MET) Received: from assc00.epa.ericsson.se (assc00.epa.ericsson.se [146.11.4.14]) by mbb6.ericsson.se (PMDF V5.2-29 #33628) with ESMTP id <0FO300B90P1AOR@mbb6.ericsson.se>; Mon, 10 Jan 2000 04:44:51 +0100 (MET) Received: from aspc051.epa.ericsson.se ([146.11.4.151] helo=asac.ericsson.se ident=epaanwo) by assc00.epa.ericsson.se with esmtp (Exim 3.01 #2) id 127VkG-0006OM-00; Mon, 10 Jan 2000 14:43:52 +1100 Message-ID: Date: Mon, 10 Jan 2000 14:43:38 +1100 Reply-To: Andrew Worsley Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Andrew Worsley Subject: Re: [MOBILE-IP] 3G Mobile Architectures X-cc: Rami Gabriel Mukhtar To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message of Mon, 10 Jan 2000 10:07:05 +1100." <38791499.1103AF39@ee.mu.oz.au> I am not sure if this thread or my question belongs on this list but... ... > > Your concern is valid! I have heard a lot of talk about how handoffs > will be handled and the latency an IP network will introduce if it is > used for signaling purposes. > > But why should an IP network be any slower then any other wire line > network such as a GSM core network???? > > I think the trap is that people get confused between an IP network that > will have a SLA to support the real time traffic, and the current PUBLIC > Internet in its current state. > ..... I understand that people worry that TCP (implementations) are not very good at handling data loss due to data corruption as most (BSD derived) implementations are optimised for data loss due to congestion and basically back off sending packets, instead of re-transmitting immeadiately. As radio networks are prone to great amounts of data corruption (as exemplified by the extensive work GSM does to correct errors by duplicating data, spreading voice data across succesive packets and so forth) the TCP and lossy radio networks probably don't mix very well. I presume that link level protocols will try to hide this a great deal - but is there any understanding at what level of error (due to data corruption) is acceptable for TCP? I guess voice can handle this loss as latency is more important but most of the Internet protocols we love want TCP. Andrew Worsley From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 9 23:26: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 XAA14331 for ; Sun, 9 Jan 2000 23:26:11 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5CEDE620@standards.nortelnetworks.com>; 9 Jan 2000 23:15:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 114535 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 9 Jan 2000 23:13:37 -0500 Received: from sunny.recin.com (206.171.92.254) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C2D24230@standards.nortelnetworks.com>; 9 Jan 2000 23:03:37 -0500 Received: from [206.171.92.254] ([203.197.188.237]) by sunny.recin.com (Netscape Mail Server v2.0) with SMTP id AAC615 for ; Sun, 9 Jan 2000 20:14:58 -0700 X-mailserver: Sent using the PostMaster (v3.1.5) X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: Date: Mon, 10 Jan 2000 09:45:13 +0500 Reply-To: kevin@sz.huawei.com.cn Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Kevin Cheng Organization: Huawei Technology Subject: [MOBILE-IP] Maximum Solicitation Interval To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, In RFC 2002 Section 2.4, it says: The maximum interval SHOULD be chosen appropriately based upon the characteristics of the media over which the mobile node is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ soliciting. This maximum interval SHOULD be at least one minute between Solicitations. Please give me further explaination, thanks. Regards, Kevin Cheng -------------------------------------------------------------- HUAWEI (BANGALORE) BUSINESS OPERATION, BANGALORE, INDIA From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 10 05:04: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 FAA28361 for ; Mon, 10 Jan 2000 05:04:06 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.854F6100@standards.nortelnetworks.com>; Mon, 10 Jan 2000 4:52:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 114851 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 04:50: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.43B54020@standards.nortelnetworks.com>; Mon, 10 Jan 2000 4:50: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 KAA06287; Mon, 10 Jan 2000 10:57:57 +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) ; Mon, 10 Jan 2000 09:52:50 0000 (GMT) Received: by esealnt400 with Internet Mail Service (5.5.2448.0) id ; Mon, 10 Jan 2000 10:52:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <0DF8FF84C95BD211A9210008C7A43361067481A9@esekint290.ki.sw.ericsson.se> Date: Mon, 10 Jan 2000 10:52:40 +0100 Reply-To: "Martin Johnsson (ERA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Martin Johnsson (ERA)" Subject: Re: [MOBILE-IP] AAA functionality X-To: "aboba@internaut.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM OK, I'm happy with your response. My main issue is really that AAA and IP mobility are separate topics and should be kept separated (and out from current discussion, most people seems to agree on that). But just to make one comparision. The ISSLL WG of IETF is the one group who is responsible for mapping the work of the Intserv WG to different link layer technologies. Mapping of AAA to different technologies/services would also be needed, and coordination an issue wherever there is a possible interaction, e.g. Mobile IP and PPP. Who will take care of that? Cheers, /Martin -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: den 7 januari 2000 09:18 To: 'Martin Johnsson (ERA)'; MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: RE: [MOBILE-IP] AAA functionality >AAA may come up with different solutions for different technologies, e.g. one for MIP and >another one for PPP (if they can be separated) The charter of the AAA WG is to define requirements for a AAA protocol based on inputs from the WGs that would use that protocol. It is explicitly *not* in the AAA WG charter to define how Mobile IP will use AAA. That is the job of the Mobile IP WG, which is best qualified for that task. Among other things, this ensures that issues of Mobile IP architecture are discussed within the WG that best understands Mobile IP. Bernard Aboba Co-Chair, AAA WG From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 10 06:50: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 GAA29040 for ; Mon, 10 Jan 2000 06:50:29 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.586BFE50@standards.nortelnetworks.com>; Mon, 10 Jan 2000 6:38:46 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 114937 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 06:37:41 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CBDAFF50@standards.nortelnetworks.com>; Mon, 10 Jan 2000 6:27:41 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28813; Mon, 10 Jan 2000 06:38:14 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200001101138.GAA28813@ietf.org> Date: Mon, 10 Jan 2000 06:38: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-08.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-08.txt Pages : 14 Date : 07-Jan-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-08.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-08.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-08.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: <20000107084825.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-challenge-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-challenge-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000107084825.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 10 10:35: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 KAA06176 for ; Mon, 10 Jan 2000 10:35:26 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B2D92920@standards.nortelnetworks.com>; Mon, 10 Jan 2000 10:23:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 115237 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 10:21:50 -0500 Received: from hsvexch1.tdsi.com (216.180.59.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1B4D30C0@standards.nortelnetworks.com>; Mon, 10 Jan 2000 10:11:48 -0500 Received: by HSVEXCH1 with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jan 2000 09:23:05 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF5B7E.97650450" Message-ID: <41495CFB69E1D1118B2600062B000E6286115F@HSVEXCH1> Date: Mon, 10 Jan 2000 09:23:05 -0600 Reply-To: Anne Atkinson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Anne Atkinson Subject: [MOBILE-IP] RAWCON2000 Call for Papers 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_000_01BF5B7E.97650450 Content-Type: text/plain; charset="iso-8859-1" The 2000 IEEE Radio and Wireless Conference (RAWCON2000) highlights interdisciplinary aspects of RF technology and communication system design. RAWCON2000 is sponsored by MTT-S and will be in Denver, CO on Sept. 10-13, 2000. RAWCON seeks papers in the areas of system architecture, system performance, antennas and propagation, active devices, and passive devices. The submission deadline is March 31, 2000. For details see the Call for Papers, attached below or available soon at the web page. Direct inquiries/responses to the RAWCON2000 General Chair, Dr. Michael S. Heutmaker (email heutmaker@lucent.com) or the RAWCON2000 Technical Program Chair, Dr. Kari-Pekka Estola (email kari-pekka.estola@research.nokia.com). ------_=_NextPart_000_01BF5B7E.97650450 Content-Type: application/octet-stream; name="RAWCON2000cfp.pdf" Content-Disposition: attachment; filename="RAWCON2000cfp.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjENCiXi48/TDQoyIDAgb2JqDQo8PA0KL0xlbmd0aCAxNzkyMQ0KL0ZpbHRlciAvTFpX RGVjb2RlDQo+Pg0Kc3RyZWFtDQqADEQQKBHIzg0FEIsCAXkcpwIznMQEUsQiBDAQDYYjIQDccxw5 GWEGaLCA0iCEDMai4ZxwbjUbi4ajYQDUaDMXDeOC0cjQXDQaCCQyMVQgZDYXDYcR0aysbzQZDGcR sQTwYT+l0MFGaigqMVcbDUQVccDOxiA1wgaWSjxkcyscVEQT4Zjegi2kDWsyIFDOfDSpR0YDEXRs ciA2ym/4EbTqf0E2Wq2TTGjLHiDIgq1i645Sy5yn5i1SsZYOM58caHMjTSabK5fMjXCDaVRnHUDR ArZUna0qcDbAbkaTEbjfT0jGzTY4S1xylDmZDHlQjd823Ui48KkDQczQb4PCjLD5m/T/A9/CYbcy QFRqc6635y5Yn25aYQIbfG4wLM8AXPE/DPhi8aEBsq4ZJg06pwI9rCPQty4LkzI0OoywaLk17cPo vQXBysrbQsyDqOg4DbOIGjpvanwco/EycxQ3KwpyGKgwzEQFMdBEatvG7GsKjzBPS8TcpgwsaSC8 MGBrC0MR49aEBw6CWqW9EksQhD4vvJD1MyHKrqksUbNyHCVsbMMnMy1DjKU5EEzSyy3zWHE2uNNK ru6/E0IQp6fhqw8xMyG7CQQ7zwS5PaYqPQshQYjzOQSpS4Bus07SNANJUpKDLBg3Eq0OBQcJ8G8P 09Ic0ryxrT0xMbsVU0FM1BKQZSpQ1TJGiwYOg6SBVKw76BjGjC1y675NzYCfBjYb8wPFNkpiHDUr dZljBhZ9ovzCL+VwnC/LNbD5W0BVk24m8XLtZtqs5a7ixfdFrTknz8qWzNj2FP9QqTD1jWDZM/z4 u151xKS3xA2FcMJMjKT0BTuw62TbKRgDc4at78Ya7N6PBhMt1tcVcsKjWOQY9iMIPcTpBcGAZOMu zLBtBEr5OpGVTW/LORuGNRvMpYbZtUNjRQ/8hp0wgYTnYwZ1QoNBYRlV95nlaOwupOYMy9iIIso7 Chzi1srm8zjBaGIcZSl6hL4jd46XWtfItAacpnYmMbc6CX4ViIaYDcQZbVgrcXolr/zJv2caTDsW YhF+9KkpEWT/i6OcBTdJ5FY2+KTtdGSfcTdpfWnNV/IrU8zK16dEu3CWNJeUsZhcaO3OWyQ/emg2 9aDOVh16WdT2kvybEOgd9Xm2aAvK/cr0zZ2VMic7N5O4Z55jirF5/PeRW6vBAI6EIwJSzjUgcXhA O65hAJoQC2LqMDIhA4otlLALMr6xw7A35LOMdfo2zjvanDxxj6NcQ6qMjp5ThoMWAcwGRLlJksQG 0hTaR1JnQVys1/ZeiXE3Q6WZX7KjCnBJeWSBD+0BlibsvlcIUyEBRe4/QsL9EPkYLS3sq5w2WP+O 6zEqSDidFMMsDF6hFnAmshuTFcKNCcEvJcDVA7cV6HiRmYdlrh1mxQLq/07Z+XLQ1OK1JOEOWrNZ JWDMGB3nDLVI4r8GaJGetSS+0dwDZAYJ+gLGM6TQG6xaUmTgt7hYkmsgKfZxDgEVqpUmXBfUT4xx lgKzOHsYWPNkb40uM8PYAk4Wg0szbY0UnxO5HWByKTPqjV4DOPhNmJnQBwpyQJMpBpYbJBiUCUXF tGP+p2SrkXsLAKuR6DMXyaQBOgdxljq4gMTdkec4ZhUxkxNlMWJq6DCFNV5DiaRnAclmXOT+LS9F kk5RbFNFiKWrlxZStVgqLIAEWR8pAx06ljTtTWzpKMR55GnJ9GUoLOVJGebJGssU/DQGUPiDlswY yLEvoGsQ4pNKBLnLcs+OjOVRJRoio8w9CFxQNLKc6g1GCBwNO/R5iJoWcxJact+gxYqNUnPfR4wj SZdLinufmmLL54zOTWxeME7KdGCl7IxnLRZGUjSNSGisUoPLABBS1nRMCXVLIJOYGE6Dv1BodVSd B+TsQ5pbVqnaZSerGrAacmJtCzUupGaeH8+6RUpXY3w41X1N1bricOsldZ5xfTrLsz7XEa08mCRa v8EqqnvqyTEv1SofkEgEVKqNjamkWJ6h2Y9RqmIDn/Caw536HIeJYmGwVk1xWgN6uw4Di7TJnkwD MpaA0VzHQybVAZ6SWt+NrV+xUn7Z0BsKju1tr7foutTaRscfEj1cmwilClpTLFRceSulcOiPn/gf cqhpA7qtGZ5R9Mhh7amFtufmiVGbKJfNDeSkCAyrqctFSWz97ZAUqoPed+CZ5Y19tLfJM5xItXsR +3cpLR7w2QcSmy4121oYHwJdW6C5r/4OuvU+udlLn3XoK857BpYagyW9aM+mHCf4eqBYgEBpZMR0 swQI0tZ0LmCslRoqMCrOWSKiT5o9V8TY3f43KrxRlgtHMbi5vWPMhUctdidYGI0zoWNri1zBzjb2 5KMDDFK/snFixEhdb2SCl5bxJkNzBS8ZWHy5j65mVWyE6ujAMsWIZbZsoYaE0ssXEXqu/iddJwKP XltIaU5Dg88R00ATIpucyoRl0NaK6V9QFaFKbfgmV+tIaHzEU8w+hVI4M0Ti7KWgSaZlzsv7UGes 1pD0vFrOpOdUYUz/nHVGGYglbyATGfWaGYlR1siXHVnsTmlJljCo8CyfKzm1VLP6s2UxtxXicGc0 zTa9kZh7aDFqu6hKNs8mRrrUN5NztTbaebg6/jlG23uv9iof3PjLYGTSf5PZzsu4DuMv7x1vmK4u Mt7IluUlHNOj0EEsrDm7XPAS66I1+aSwOftiOCw/n7di3C26D0zh5rdBL4a/QXQTRtLCjcWQGwq/ O3+QQ51TxXiWAsEcN2NpzZPCuXQLjHPO/3FeZm25Huzm99NZnsCEFQhALwjVpBAFRq5Yn5zHQQRg uxZClhUPo/MjBBiEAtva04KlGurlBCoHchAWwUAyBSXgFAMOxg27KCkGXaeyAgCSEXuAIApBh7OC gMgaQ3gg7p2QNwZAQBXDSSHuobAyhz7r4btYIAhhvDcGbsYNQUBl7qHLx/ke6huBSDEFAY/JBdCo EprL9SzkYf3DnZ6UjvOXfj0XqPRetdF68ArsARAy+YJ4CgO3mQYeRDk+bsayQUBhDkHINPYwcgoD eHQOgIAphvDr8YFAdA0BlDD4b24dAU+e9AV5uBh2xH/2f0UInXwUe09t8f3PwAyhyBZ9DxQbw2Bv 8p7cMIZA3gsBAFX6AU/fg4BQCC+y8+e4WEJ2UG/CCo/G9kBQCmDKDgDoDKDa+gDE/WIG+gBgbEBm /w+gw47M+09ChyIwMsJeoCTgJoL8mcwE2eJo6g/IDQ+UDgB0BeBeDkDCDu+gDG8YBcDe+gINAC+2 6EoC6KPYjkKCfnCIBAjORqMAXU64Po6snOLE6zAGqqMO66/ICO8k9uDdCy+O8o7Q72I2BQDYBSBo BQ8UDQDC+KbE808pA8AU6EOMIE6Mha++QRCjAS6vCio1CeqrDk9i9m8zDY90BQBc98KkBRDU80DG 8y7QDQ7G7WDC8kOlDE8zDK+YBS+OBc8zDMCREC8tEmDqDpAigW+DE2DXEk7RDbAEey++Kk65ATD4 6xD+BQCYBSJUBQ+ebE83EkBuBQDc+WCo7U93F482DQDdB3EPDGiA+Q8yBmBQDPGbEQBTGG8zF68N DcIxFak/AQ6q6uONCk+4MHD8/ICg+I9/Gc9sRo829+808lDK+xAw+QDc/bDXDMCcCU7qBA8y8gaM 9/DKJs7FDcCoK67BHhEPHdDEB0BABW9+92BjH8BQLxIgVzIgLwjXIq2fIebFDKBtB9DottFe/IDN DA80DxIVIYbFIdIqQMBzJWBnIhJbI3IjGjJfJkQGBvI9FYPTG3DwnPBWo07A+nGrFxFE7VGc7o7X FPKG8oWABQCA7VEpGW+fEO85KHF/H3EJBxGjAjDdCAIHCFI+bA/FG6nPCq60dYLNCtAVGDJlCzKp HOBREcBa8g8w+BES8gDHDA7QDYBAChIaBQ8o7WDfGgbFFTL0BRAibHDMCHLk8hMPLvMBJzDhK/Dn J0lvLGAVFjJ/CnHHAUCIDlE1JTDMCXErFLNFHMbE7WBaCg8k8gDXLhNfHjDA92Im7HGtEHINMFE2 DY7pGwKrJ3CrJ6qrD1LJD69g/ICdE9GRKSDSDDH1GWClFQBQDnOk+FEGDGDQBBFqL9FK80DFOXMi +A7o80DpPBKY93ETE+7RGvFXIHOLFlHJEHE07WCe8y7XPnDMCFGRGcDxGjOe8gLXGiBu/aZzDMCN EGCS7U7ROTDCBbE8qq7NEOU5GiBrJzGzJBMxFjG/LPHFOPAUCQDKDY+s7RETHRIhNjHVRLDNKwqr ImNZIhHpKaBACNQSZWBROTMLFoBTF6CCCcCJQtN+g/ODCmnRHBFjLTFnAe8y/9GU7QB1EZDMJUBx QdRsBzQdDCBpNLJe93JxHVI7HVIfIFIIBQ8dDC7pP5NLSfEnCRQrHVSnPsBRSs7VF6JvNLS7I5Gn JnDDS/DKZXTtSBFaePG5HCjm9c/IDXOtLs9/JmQQBQDhEfPUBRNfDDUQBdOkDnPLThGVDKDCCBPP Ui8M7ROrE3U/EW81EdDDE081GPTnUk+LHUDCBdK1DDK5FXK9DkZJSCMBG/FhDzUNUJCrFmCLL/P6 7WDRETO9WQ+jDPNLDA7XWVFVB+CNDjLBMtDtMwvbM69nNBL+7lHY+QDPNbMABACFW/NC+BP+BQCb LhNnMADXPY+3QuvFJDHDDlKBRvQSKBAXGDN9G1SHUJM3My6uI5LU7AJbQpXSCFKY81P3FK7WDJBs KO+CDy7U/8/wCaCHSgBABxGjIfEPJq81VVF67NF1A7PaK7M1V/WzQ87BXLHrGRFxLhDHGcDJLhXE /ZW7YzHrPrHVY2ytLhZ/X7QxUHQ1ZUdZW0+jZtDJITIXL/I1HUBbZBDLZ/JkBamJIxapHVJxaFSF Mw7BJHW/JNabNFafDLajazbMO5IhJxarQFIgLjY5TFOKqZHA7A/m7RXO8gDE/7EI9+8hAjC/b9Mi 7JRQ/8DnKebE8hETF6DLcbby+RbvGfMkCNCDMqMOfmMPCSLm2AkBBZYEnO65Q5SLFmCoDLOw7G/8 DdDU7REXNlFtEo7bL87I8o93MHW/BpEfDLFG+PH1Jk8XdzMRMTRI7q+VcbcnWpMrCPCMfhCQZmKC LWbILfBW6jJ9V/FjYJFmCbYXEJXSClYbAnKXE8+xNpHxF7ZFDNABYlEXWNPHF6DoD1KHA1cSBRXy 93GCNLAXUApiwXUG63ZVZYBRL8/88o+PGQ808dEyfM+rPHb+BTeGBa8TfTDLNjKPKxDVKTEk8hQI 8hEu/9EXPRGjE1No/0b5F87HGcDS/TZCBBgNTJExDNGDMVhaDXYpYlB3blUJOJc/ONYK/LE9U/EL O3DLFy7WDpTLPQBBfS8hU2BQDE+rDRQI7REvgLTgDdhrF7inUjAjF7PTVm7W77VVikCLKm7XU/PA Dg87FXXkLXLTV6nPew/ICa8NfNiTQVhNEPC3KHjrYlfHVdLrGdjnGZjxUXQJixfvhA93Ai/9GIBB R/DDYbkVYdERj/MXYbe3UfEPE1a4tc6fAS7BL9C7EHPBiPe5hi+PPTi3kFiKDRivPzjNYjLo/w/1 KbLrWe/TPvhZThlIBBOfDLd/DDiZPNEHPG7thvZPPe6fQ4Kph7M/XO8SClLhMHAoCJWdDFRQ8gDL Ri8TcFQTDDGC7Q/5a5jZQzG9V/W3XO81ka8ZIhJJDFZrJlkaDKCPGi/nME+TLhRjnTRxEnm7GcCn X5jVSDk5nJChaNCpgBXXNTMi93NDd5KxZc/VgdMBHTEhB5Ty79nnGW8lL3W/DHHro3MBHpd4Cm73 C7oo+QDMDM8VL/B3jLUfoU/lpLaTDLWVpbhNhxnO/cCU/W/nGXYpQLd7GXoy8hdpGlHqDaDbpFHs DfRRWfaXpkBACcDLIM81BtGW/lqbOnf0J+ytWxoLSM6vaRe1PlXTMZThUS93iZUuBBE7KbPADJGh DDUvok/xQO+PrVP7DCDpjNirUgDSDHXhLDoHf7dBf/mZEHgJlLSXb7NpNJhLhbidhrcC92DnWO/w CzEHmhF1gFNG7VDK8k93slhhgzGLiDFtgq92DFsCAVPdhzetrDgBlBPDdrl1rIClELsc8hPBGNPB svOVTgDXpbF7DRFHorn1E9PG7QDo7xVaDcDDiY/zE9lrERlvb7nFq7UHEBKbiAIniYDTfhEmDDfB Em+xHVOziFlVclTNE3HnqDDLQSjXhNgg+jrRq1RJuTkrThU/pfN1DDU+DDvLppPA8xk3f5OElZHA IxsO+BsTEKCVhbGNE9O1tPqM7XtJb3ajE+8hHhjLhftIDq/w/4/9guBQCHZ493XXDC/bNpvhdThO 83k1mPM9sRhftMlNZjwyDHgVsTw5w1ju80Dnlls9vlhRhVx9sSDmDSDptFlzKbgRDNozGpGXKvuv jbSJh1FjrFu5KwCa+q7U81mJsrTgJPOTUbmJUnuM+i8Q80DrrjEhlg+C/xQY81lMBRoBXjoFwNPf XtyvgBma98Ba/9VVNoCfpfgHhryBNi/9B3F7Hpg5vhGdZc7RoS/86LhC8qCVEKCvsW73w3Ntq1to 7Q9t0rKxs1VFEGDnELYy+PHhF7W5hxV9rAnPaRtlr5DDlJEK/4+PmIDcDVWbla7kDDlTvxHnY0Ct E9PTU/zdknzHvx0sQHUjdPyroIqrjhAVL9wZt/EPTLhXnnYlKRibe2DTGJGVg5OjKHvHi5vB0buj DDHTuphDybGd25DNXSCbVfLxKHLk80DTrjgrQLwJoC+/sHjcMHG/eze3ELy7MC7RRRDN3PQKDrZr EP3xvk81UnDK/a8SCbGIDpBrjt3A/TGdkZcFl/Gdkjkjxi+3tbyzz9h/rICbjDDN11LjrPuDVbiJ tnqM81ijDNvR5zKrEnF/2e+POlOxVZmBNLPB2XPTrn2nuzh9u3rJkdzBE3urPT4m8T5plTVfHfUW DR2XufNLiZQJ59FtiHUh6D1FGA8z6LShdP3dPBmDTh6ZUX6d4Ff3k6/J6p51ELtlOlSVEnU/izIM +D6NKV8FJztbf9wToRwaBBwfE9OpKxkxVPxfg7aTEODDKm814n35UgDdrjHbKxsTA1GWCbhbUz6l ipKbGVgr6fwPYDev5dv9E9EL291P4B5JfnkPUlUWDDOxGJkp5vEO/xfTo5GWDhVRKO7dDI9276Dr kDr32RGJtXXl4Jz39pEE+B4VOtUbNi8T03hLi7Sh/BUjU+DpyFUa9tltThOlU/VDERyXVbya7Xl3 l+7X7n9rPFE2/tcmBmIAIBiICoZgaChkNBAMBANRcMRhA4SIBmMRiLhmMhANhmMxcMBvGiobYPDC oY5LHxhIjvBxQQzCbDYIDMbzkICgYTgZTkcxSVDVBxeRhvAoJBgUORcORtC6dSqYIBkMRtH4UNpB HxnTZHKRgMBnBJQCpNLQUWxQVBSLRiMhQaBSORQZRASSLdxAUhSNxQYRSMRQZDSbxAYTdccCIL/b iuaTkZTYZZ8NhRkxQICHexQbzcZr/gJ4ZcPcjHdC4KCkQb+NBQV7WMb5mb4TycXBSILhcr9bMBlh AYjKYzfrxqKDaKRlbjLf8uYRBkTDgjcZxSXSoSpKILZDxoNYIRIOLRhKoHJ68MIUVLNaDSbjpPDJ a74aTmYzScPkKDYKRgKDS163MO4owjk16+Dyv6+MUti3M8vjhhavg5Dq/LjsomjNQhCTCvjCIUDs 3YYuKNzSjmED/wYFEBMvAAUDuv7+v+/rHsiny2P6ny3BA4TXrlCzjBSykKQ8Nw0jGMI6MHHsVRMM UlwQ2EWRSNEULaFAzrhDw2DS6kPDRJMWsPDwzhAOg0OW6zsLI7SLxEooqPABTxJU9KxvGr83vW/z 3OWFrKQKFocMq165rWygx0MFEkwg5MmN+17+z6yg6OJFzNUlQq2UENy8iNMtMURTS3jdRi3DZCCI SvSAUSg1jCtfTbkMDVcd0TUrjDbIdUyLULKRDQVF1WN0TRbGwYhnVjV0GtlkUoFtkT6GNBOPZAQQ 7VNMDnKrijONwXPzBcrL1FLVL410Usy/onrW4onXYFAWOq66DioFTzpFOzyIJPUX2Ot61tZI0Wrh QTcBTQUQrdEyYjmwjPWxJC1rlClBUA5QyTLgi5ufJFo4UOlrDKO2D0K/tTvwtjKOOqdMysw9gYlQ bixPl7L49IC5J46lBRQuTp5IwrHjDE0t5iNeSOW/oQCFROLM26IxMNkj4zTel7LIlTvPNrCI32g6 0MbIIURpsTl2Qn1BbQy7VKoFAxxLkm1XjHS4IsvoU7PoDF7GMozwpuz919vGxjZKDABBlbWL9ZAy Lph9kQKwDOM/RQWr/ZA4DC6m7bMy7D85mN+sptTFSs9vKdKt1KMpurQdSufArnUK5dXsbmcnuz/0 PwfSb30+7DIOu1drQG7QQGVkW/qoFXre6xPO8s9XGym2WRc7KMyyjaBBVDKYe/vv5L2y2NYn2Z21 mOa52/XB5vy1UjoOQw1DK2j4KObJPz8z/M5Ew6GENE3E/LFG+GFN+HIN50TCwEMFAFQRpUMKpQga wm5NiYggDgY9/DNQ6JIMGzUnzy3mpyTu11rcJT0p6MMh1BRzg5pgRSj8OobEQnFSSmIviZFoojDs Y5DSKkKtlUqitkCLUHGbPyTdlCD39KyPfEqJK7zJGig6sFIgcwXF1U4dE/MLD/RWL4px/64FnJWL gcUuh7wxpZjCkYmK8k1EMO2DE7p3zzlhhO14s4KIMhvOoXJ+TKy3LxaUi1cZxW2GsXOcU2QKDaAy K+QxFqLwZGUP+aw/agX2KudOaSTKgkKFyQ6tBcJbpKGUQg5A16yGjlyRs6wxAbw4GWBZAZzJo1Cm AJmZY5ZvVEmWg+YiQhzTXmAlwxhqRcgQBlDwbk/wKTWBiDTFZEUQC5PKXmmuOYNgcx2a4eh58JF9 Hqa+CgKECEYR8DeT4vkbzizsMuw8tyjGxylUsDKJgLS3ByDXPBup/ZZPciU1JbCsj9vnUurKeCNj in/OLPRz7SlKUPDhQ5t08J7MrWQiE/qUGlHAWtRYx4Y6JlzYxSWeiZQUnFn+xsI8AaCz7ncZcIdL Qw0imwmooZ3jylILaU4hlPyplVnADQpgLgbA4IISRNceZyR7NSFcIcj5IggfwGWftAkuHtJjLWDL 80kpHJms4vhwQ0K8gvBmKZ7oPP9ZoDqOBQgjVKp6QcqBTSGEMruVIqhVgQA0BwDIh5XKmAoC5JUG 5PyggKKGRAoxBSUndqUSZOKLCgVyp4Ucg5FwZ1GO1CUricYSx4T0FNBCfjKrONYtE1jK0LhQJ4Z4 FprEIJ/Nfa1ZRuzKIkTRNkoZRa6gKBwC4HFkyVEitFcecMJXozlRO+lkgY5MsTamwBPb60dsaQJW AngaQ9VtNfbtoBp0nMpWTJAy76AWo+MQkOTFbWaqvRSzVjCLWVmgP43dFL+4CNOZucdnJ7jbVxTl cO4qbCHg1Tfckr7WixpzK+Sycob3Hueco50OjojNz8bkb9obSHB1WZI7ViMlmxKoWQ5+XzBTds+c oxg46Vg3zSbE7Fzragdtiqs7pK+Ki+uxgxAhuDaWSIovE3ZzZgMcoXME2IM+PMSODyBfZvYb3guU di4tRTYseYoiA3ZkLaseLdwJCOEq+HoR6LQ1JQTGI1sku3SS7t31Fs1xytUModAx05rlXSzSciLg 4JBggGslZvWGsRYquVjrgnjskU5OBLjFWXsYEazNkAFWcs9hAGFoTswnJVaSctppf2qZbbiSsxLU JiVSxgKVujApKtQCAIIco1zTuscHUwdTH4Et/Y+nxHtH5nm9sTUBX7mx7ZpdKBl1mexAtmqpgoYo ENQzYrPaIIJKUNcGjRm4c2Ftvfyh4OYO6VXrX+zwOTVJsrMBdo+OeCpvacPKvkiJXE9BnNETy8Bb GfbanSjJviNVVo5RYlZHm/kgMqbEkONqR4ylu1lGHcs9l+oxvzt7cAIAmBBCdxXi8z0ZmQh2ZVYi qQoTFBRx7kHAeM8kUrxtvcXjdrNL88uOSbY66Rm/mib+yS0I2QO3E9+VJXbmYbeEFD4VnFyX7Rvl 4IH5GCMIgTN7PI1B0v6Ws5XQgUbmgIGx+LCVLL+DS41qN9OpHRMHiJDzx0cH5UotDoxldzZ5z3r6 uewDw6B0GdvQungFaIBtYnSljag5/0cDWyeh9J2Lp33zTJGNN2g2LOPexK81AoCSnzdZ9H6LIP+W 4ODRUbxAo2HIPJBKVxIBacWioY4Q2+KJ5IiBGAZlF2NgzzWx4TJ67cXyAnV9VJWf38FnBfQ5Mg2v 0W+bNWh3yZc1P5CCG0/OStgAy5Ow5PhJtbdIDLOyM1NLjl5aN/cFF3jgs8NzLlp082e2J9YOJoqU eh5PqzZJzpDLyVThcYuQIw5hT7N5IiH5U4/JLroZmaFZcD/ZVLgTjTgpWTtxVJBCd77A4pH6ewNz PMB6gCKL14FANZKpAMBL1rcx+I0SLzgy56+b1paw/LgTJ5FqDo/aERq6ErBz9q5Sp7oLIrJzHyN5 C6PrIZQZnhRLHzJLVTFx4ClSWBzjHgm5PouTCrCpzp2bLZ0ZoB3Bw6QwxEARBQOZw0I8LRTK9hKz MMIC1DMhuzJYy4KUML7aBBzMJbLR2rLpQjHwwrHxjEMZyh4aITdA48HCO65bzb7hh5yQOSQS/Ruy XD8rc5QSZwuhFBaY5D0isB7hSsRQ5qkkSxD4xAuiZIxJzLcEUBkZnMAbhKasRoOBycVQ3iaxRSDC 2Jyj75Zj8ItxEKYwxCCEWC9JRJBCVxRJSi1blUQibLMycZPRxpbTMhQUFJjQuhm62RBr/ikhEx7r padIEBmozhLZmoMpAjXDdD6wy5yZgpYo/Mc6F6/45Bw77j8D7x4rVAwD8a6IMru7PTPjSrPzTA7b QT9Qi4GqOjQ6w7wrRTSrRjxTd7xjSCyrx6zD2zyibrTjwSFCcLejzYIIw5SaAK8RwSfRQaFsjxWa 18OhsRzSDz1qiDvS4DP4izd4HIhT3cHjCL97BrzbZYNgOpDsJEXJMRQRMhYwwA45Ab5cPj7C8STQ w5xTipEK8Q1g94N0oQvsGKTRPp8pKpZBLpWI1jcxlBipWwtZQUsS/Q1gM7fpWL88mSowhT9by8nD 3zoD8JyRxr0xnx9bcz4kfDaMcS/Imcvp+TOQOS7zfptow4vjO5m0fjvUf4pEgLv8gjQznjwjwzyA I0hjTDxbxsy0iTSrS6n0iqz4lTwTlcT4OwugIhkRIx/Lw72q4Iqoqb3UHpOMjb3yFK5w9rZiL0Er aCHKDA/JVDp0TBTJyD6UDQv8sw/I/bjBFKI4NInkAhSqs8A6H8BRZI4rcz0xl0ccwzOjWQGJnzc0 AAFEAQwAJIIcrCsotZs837Mj882Y2DBBN0uQGEHacUuaFUPsWr7py7DcZA5BxRwbHz8rHTKjGUvD LhsTVhVTMDFrL4wEP0NbhhKxv6XUlRwZMCVDH0N6ZZ2rvJ5YocyDvq4kyYFzwMg7RM2EzYpEzsiD SUhTyK4LTUizyznkjJrc3BPQnKhYzSi01QzBVC3BaSPjE8k0kBRT2anU2LP64YG4G4gcmzn8nL3r 4BKo/sxRtyTJVJCgvhDqhtLZMlLKIAvg946hCU9wvo95jEUy9RVJkc9sXLirKkJEEw+ZWRiL09L5 8b0QPQMpjAzwuVMrsQnjcrAhQIF1KIgcuNHMHrzMur7Q/5ZAMadC8y+4vp+gtxjTZ5mtTxki7EfD NoEAJoIoJoKcfdET2k0SzYjSvIgQjSoavySpNokSpjTjCSPYKYOoMTGKhsU4ziLSF71pApITrhtx sSkqD9JiuUmDTCvdWCvdWacAhIG7BKwkm6cD3xPKco1UERCh1U6pWRVBGcsoyq+S20rJRNdJZYwA NZTBa6iVcq9NXrrgtxaiL9drc6apF6fJRpyw1hlBVLWDfVdhYxZBXQ/oNoNrWBiyjsCg09c5FDFJ Xp9gtg4tcLbECCIZMi2UoCapvxQBQRbJQjAaTSZZRKTLui1FixZyVSTVehXhWC/QygmRSpVpKVC9 hBPZVY6jnE+rnc27903LzZMwuhL8GqJYFAHQF4F5+RSrkLhKMIFyH5QBbjiz/lNa8pBVpbmpK4ui 8s8ZZJKIxVEbSz2wjwHLA9XM+5OtbUuoJrpQ3afbN5C4iqdKWqSCdIr8l7yQqqpM2sub3jn1ohPS LJvblKTQ/ZaBocSq+iNw96ezuD1w1jrckbIIMp8I0L8guiIydKCZ2z86SCpAG471RxOItCCwmYmx 18V8dyJSDSBxRS+BoD7y60RgxBJCLII11rkikiBFT5wYMaewOaAlsThlQjrxbUdNdEGsadzNzYOQ x9QTgIyKe127aMesu1NkF0YkQqPYOAMh8KWomJMxkgN4Op9ZjVUqVYFAKaaAy569ypsaZDtV14Og +swwOBkB8INJGpoMUYNhhowrcV/gMIMQyKLLzpoBI5/BYhFLp7dIuYx9rJfxpIFAMRy18AtBqJ/E P147pVTLZ9YLpS+I+kDl9C6xkF15bWBIMqrw6B/BHd5rudTRkF89kj1kXKs14VSqC9xUsckaPxkl qCGMeCmhRK7QxyCMEF7TMsHNKzUSPY9qF54tY5Q6K0pkLZaqMbWZGy6gylsUS9saadfgwAuAygum MAFBIbhgvg46dtZGK5ZJC+Mdshgq1hICdt/8Ta1BQBVwNBAhDpC7hIyhlAyhKBQUfrnMhypVR7ZC cItFXgzVsWODIpGxtKYIvmCBKxfriRVYmQ38alOTH5VdPpEJRVQJDAuRCA4qCsw1NNnuOUXJLaMt iFsZeNzBYtMuWVLdMtQaZ4txI991LcX+YNfg/ouCstrIhL12V5Spo4viWqNSs9IBWSsTAmRqOhrV wlK0uphqAi+mEzEDuLcj1t8rtR05YA0JYuHDquZrbhxkUZFqBk6VztxBciAmHLDeTqU1ADZ+USkE b+FYNIM06RjDCkbp+Y0uA9zr+5tpBFoF1DT5PQJsXi85w6StvVvouQ8YEAIyTpu6XWAuhtNqDAnS XpyBEw04hUOsUQ5hE2kQ540SP7LaTSZw2yjKdKUK1OUbqQ4IMoNMVKXIxNsQ4p48L1s9VoBQioh4 GCpVtuSDTsjS0bzYJTsIzRBBpSOheL8+pwiGqJNreUyySFvs2FZ4pCwQlcms2x50uknZSiat0On+ ddLjZraOVeuxjJpCDF48vJmWCeDBjGIJ8aeY0tQOux9Z/cftGkmNV4pyoSvqcAtoGgjFW6coIqZo NKaUPB29AAw9s+tKuwpavAp+0qvioghQiw8YGYGtbKb9t8/T36co1Iv44qqRkiqgr656d4zSAxzd cxSJiJmZkagr06iONtZBxzKuOaZaZrlw4rGiG0luOajClFZCkL1qeBlBUz1qji85HV85bCkTILKx v4/qkm7e3+7GXeCI5Ff5wj1oMh9+Yag8RzuOTmbVoObqcqkqsydO5Kem+9IlB7jG31M6JpBSi25K AwMQN4N6kqlqgSlRAZWWBL1sDyiiCKeeOajVNj1ufJKwzJQUlx+G7+9Rme8ZSIECl5YVrSmW+4zC m28t1uzSdKlqi26bLZmamqdKm9Yu/eiib6PBOzzcTqVKesTunr5dc8Sg5gm49vJFNZ4pZERujDOo xGxszQjS4KbtaW1KvwGwhwGQHCPCpkHWqsHp6QII1xuwzI4pdYvhdw4usxvYhg+m3+7jKpYeJD78 9qUW7IMUYbg5ZpM4xAur1oIpwfRZtvRZatuR3N4YxBApB5F5Aeog5aZQtSOhf8kfTT1yferXRCgg txjAKnUBRAuRupAI/5toOIOvUCjF+DGVZHVSZ7uh2hwfQgEFiVI3SIwAKgKhyw4oKbAY4uanQ+ib nT9iPfOi/R1RJRlyN5tvRJEdZCeGG3VxSZwYOroqZVADCh0pZAKaDpvZMXUxvduh21MHbG39AEBs NPVEXwxBLME3WskY/ZtqP3XnXxQXZ4JL1t+EkYKnY5eHcYvpz/UylRtvexQqZXgPa8kfbJwfbbLd hPb6eIv6VGOe3/eYuQyPemVtZGOOPe5RlxgQ3VZBMHffPvZawab2SfW86QxBEmmEYhBXfzzj1oKn YwFPELAgIoKg7NWAKQI6zYEAJQowNQhbd6pQO4gQhgJoECzao4HAq47u1Cpk8Yqvq6v6wQqINgg4 KfpAgYgYOQM/soo3ow7PpQhnpg8an/qCzeywGm1Y9Cvw2CwWqLBSpGoAg4IRq4OIg6zqpAGqboGv uNtYqQqopgsIjopbeQx4g4K8bw7PtIBSo1RfMwECwK4giapnxKpAi3zutZaQhoi6wAsIHBNoG4hT QojCpTQTd4gYsYGuy3w4hQG64YjgpvsQBW19FIHIotKOp/xFKAGQ7101RYGwjQGwi5PAEH11FIkJ HYg/54j/1n6X3Ajg5/66zlKX7bd/50gn4mywqgq4i4poG9tQsH6wBX7DxipX9j3CborFRYGggf+g 5I73+4GQHIgA1EA3GQuHIyGQgMYNBQ1GouHA2hI3GAuGkOEA1GMQHIxEA2G8WGEeGg4Fw3iUfGgu GEjhUMkouGowHEfGcQGA2EBsmEmGUYG03Gw4mo0kMHG82k4zgVGFw2G0eoM4nULBVOGYyqU3HEHE FOGQ4GkqFwxlFfkM5mo2ldMhNWGg2FwzG8CG0Ps1Ji8Wjsfh45psrG4znVQk4xmtwlYyvsgllsr8 3r2OGgzyMWlOOG45HMvq8VrsfHMGlN0gw5nQ3jY4GudGcrHMEgc3i+Jhmvk8YwdPGVj3A1s+7sUJ 3EggQ3lYxGFJq24lE15Eij1MF1ay3R4FJ6kageC4GeGejsPQuXIsY0gt1j2buYzosPkE6HEFGNmz 1OgQ4yXhncwkLkISsSWBwkiTJyy0BBizivpMwgQQS+6TBo1EHpW5aEpiu6PP0gwbr0k0PLHDivLg 0Ybv1B6CvmsaeAUMyGCihiPDO/yysHB6NhkyA2pguQZwVB6Ks286HpmzocIrH7AqeHLrxMur7pWi TjxMGiSJWGoaLG9iQK/LCXS4uj7oKGwYOvBr3K/IQZOuuSOoE8KytCuqLBiqrbxAGrUtgsQQPc6s FuwoM/JMGKsu6liBObQqftmk8oT+xD1pujTXQbG7dx+8DRpAibVx0r6NvC9aKhomjLuUsYbNGxDO sUmT5o/QrNq+uSW1UtNVrRJiEsNUcIurCaPrlBUMJMHEbsM9DztGGcxMM+LPI0p9DscjrLBqoVaV WzCxoc3iBo2nLmIZPSZPs1SDPqjKQyy68yNYjMDO43a7rfctC2RREzJ04EO0QwlsP/NlELuyyrXM GVTpQuYYoTLK5rugaQqJh6CzS9jGTuhqC0a9i3P6hqN2zJyIT6mbDvlUoYKa0cmw20GJRLOUEVFL MGMfmqTsBXazZ1HSxqtF4FBgEEaKvdsgogowQR4q8pOQgdmpLUKDWzieGprOKUS2h7e0U29myA6L kMtP+bujoFCI4idKZ45tWLjRzlOJEwYuO9O5VNAaB4ujy4Y7j0k0PLSTqjWSLX0p1TLWtMzWA79l Ner9mwWxymW9JIYV6/6z4Q+juKGjiBWyiDIIo6s9Iyh6Sy3kdaYR1k+3SqLLRbc1DS3ju7oyuVYo InCa38rKkt22tpXa46bw90iQsq6DF4ddiyr66MJ7/cuvU1hioeFMgaugkzW2Yg1NSQ6sPPu8VQfO u8PzrHC5q1Xb8tBpmhRloyepY4LRpKR5pxTj5vhIg1FFpcSZFeYY3cnUB03JgWI4QkJYUtrEdUfh fUC1DlwXbBlYgMDOwHecwsm6ZiBQiIsfw3ZLSEwoP07pDp50GmMb6aRnBg1JksekXBED24SmtZCT E77DAYHoiC+JnkC4jQHU47OC0DSYKshVBOC5JiopbQaVBnByniv+QIsA5ZqYvEeRa0MyrpmunVIQ 00mBNyzETNhBd0B60sNXPQdVQZwmCOATrDlZZXyCmxS3G4oZl0rGdhW5s+5DyiQ1je5QspF5HJaI yRtssNSUNgY4XMiMNTAOkJub01MoVsE3YCo4/S9yGymiGW1bCZHipSMqRk+hwSVn6YOuWWqeyIHf duxdYR0QcwgloTJpkwnVA1PSqCYS5JNkEl4DlPrtzVtoLw49aZIzrteVoyiR6dEtKuXK4ObZZWJM oIvHR0y/SKvgl4cCVTKHZpScmtOdRQyPLTLpHAk8xGEGrXQlh9MyiLNoLavqghGpRw2c+TKLRu09 MPI2ZyhZhCkrTKCdCUJOX1FLXeU9KEGHipkYIXtMrbSWKgLgQ9llKG7mdcLMyU0NHCrFlQzImCWH f0CQwkWRBgkgQIMrOo0NKzTnQmuZYvZDpENeSaV8vDGEiy5aeU+DKRV10xNknQplMCuOna9Gt/DS JOUfbuTWAJIQZzEXSuNXcNHUMsL0SExBdiTGoexWQ5Ba670lQavF0RRCdExmlXZq0qiYpIbwSwl0 B0QNReADFqljmG0jLK5OATsz6IYrUiiyL4DPNDaK0ehLqi7ntgBLomVpqsFJl/P0pNpyNWutUicz tsj7UEtvVhixBi/QpnjIG35r1+oqlnadZ0+W82xIfclaRBSHGFuappFoaLVXRt+Qlp1BC7lra8yG ghoS2QFhOuWN0krxrIvLJsol3jq2SvBCV+dpyET5jcZa+hsnSqGt+laTV+78U+uUh25hT2qUENVg UthtpNmvKkfCydqsHFkvVeC6FppbpQtfdi+jIbrSrKeXZrzh7tlCxEYeUB1Tl2/NiZ3BD0rT4tuf e9VRf5uyWNVb81TpMcYPjxXlaaHipS3xXQQrSqksSzxer3JNVHSsKtjk0jOJsKZFypfRw5VsPulT Tli1OIMumwU06U5d+DBKnyWWQimDM03jxza/Cebs0EFiLkN8uA863ZyzarPNsi+0EzjIxdebdBZA hKsnQuU5OW/NbfbReXrQthJOigiRFkbkbKCQIFpXFGhyDKQyMxBSjUXissKAOon06VKM7ZHsxr8a o1YVcuS7iPsji/Ac5OMNbRkpyWXXRLHJwOnNbdcWwdWp2tuRWyWvKqn1V7spK0QdcsPNGlnZkCDI GtmNtcuW2dSwhJhqjUmBtwIuRqUZ4W342Vk3QR/WF4GR3H3fNTV2tVYbXVZr98G+NfK92KixcpG9 kb2TNwBkWwyP7Q35s7hMkeFvS21tbeGBiM7V2jvTb25IgvOROvLjUZbVaj48Wwzt29xbu0trFc2t NVI3dvrO4+u7wbT3tvvme/eCbGIasRXRUdgcGdxz3hXN+GJl4d0TiHFtmLm2z0q8G3VvbqtfyJ8H H9QG3WIqBcxgK0dYJPkpN1oEWmmKgt6W7h+xkhJAtjs+zE/k/Wx2EmvY4rGxd61buZtyj0IJWRe9 Zpj3dsoL38uRcWH6zKYyEwlBe4ky8T2ORndmId+8U6zA/fSMdj6yv3uTIYzEVQ0RnvsjYAqljX5O STezEdmTq3Ug0kvJw70kYRfvfXpJ/LFRdLBXvcNMW+myZ3vaLkPkunHMaPgZF62UdxczxD7pr84/ IvS4sDq2JSlYlmBz4FhPv9R4SRaOfYmw6yRX4qOe/By0H2f3P0cG+MkD35GP3rea8kD+bq05KbYb 6wzZOk4iJPBChimiKoinhEpF4i4CKkdQDKrQBiZPzjBPuG9iCJ8jBEKQEsQwKnEu8gFMPm9jWnSE ipJPSinoiv8DWqYPQJiFvi2EMQVMXD4QECYQXv8QUoUvomWDztlQTFzQcv9DzO7wfE4i4vviIL4P jEoFvkspNQPmeQlJJOQCrnXvDjqk+tTiymWO7oKIgnAp8jysVoDkyP0u7pUwuJjFvC5QtoDo3EFm Eppo2iyv2FbF1wwjMMXQ5trmOwQo1IoCrnAl+i8JKI7izMXDYGmRBpupblYo+RCPRDcqlGOkbmIQ BJAC+PdQGkxoEwNRKI7iCGHszxICqRHIcRMmovJplQzQWxHD0RQjKxLkrEMG/RVvZQpCOPWRYGqx TEpDexcvWECMGPsRdHyrBpLEKFvrJPpiIRePfmqI+JsQ8IgmRvzxoIDwpwtQ3tzCrpTEuw3CxoAi uRpwquDIzvJJbr4Q1kOxCwjRxjYJpRrxxqpwvRxIgj4QxmIECR4J+xfRztWlVnSQ0xsCnFJR3x6I CxXvMiYLmr9PML1i9q6walGoDi8CzlviDyGjkvfSGIgihP2SNR0KLSCQoohLcvkCkoAlWLQPmvkp IDgQ0KUqYNqxTEiyVmZyWxHJhi9DRoQRXnpCYjexPvWj7oOyeLOCyjvxJl4yBSjqwmNylPhiIEHC nC2PGvnSRqLySjPQPCfExSkCBIAoeygROFWPzi8HeEJwsRACZSaIoy0P8CiljxjFbGbiYkJw7lEv 1KyE3wgy5u1RlkiovypS/MVK8zAvWCOiSGKH5yumcPgRHRKKxmUC6PGlbt1zIivQepuvTO7izJ2I UnhSAS8J5R/x5nbkhQki/qnzStJv6DTuVCKiDyXE7MeE5R5PnFpjWyrvpFpNMSXTbJLL4Pmv4Riy 7DGL/pLQau7OME7QgvTt4wcFnJKlzzJzoGETXscwezoGUCKQ9ubGUC2TWCmL/kkxjSPS2DASDr1z IxJFbQTQoqEjEHprJRvLVOuT4pKMNzgEikusNmCQlT9rzFqR5Q1FyjFyKTQMLCDFGlvijOgCuRyv Br4j2va0IOpr9LmmeLXitHSTyuDnmRVyEJNiNHhK6T7uriGjYMi0Drtrmm5RuubixQNPKHbu+pFR Tz00UTc0BwOnsi+R5FVrtUCDTvo0frwKWQ2i0jZHbqfFvUkIW0eHru70iT3FbDQwewTLtoPzPn+S 7FDPozOTNmb0XGENZotUXOX0ezkOVNZ00unsDR5TZQyPJSsHhzgSsGEHOvozbFCs0FiNouqjlQii 6snU9wii2F+kDQiplOolEmHnWJ4j/s/0OHhvmVJO1PYQRNyl/C7wYCnp8u1FdQWIv1NVQPiH507i n1SF1VPQHzRwfF/E2SXQfUxleS9yXD0Q9kyyqJzyFJnHcOIVJD4RJVJUqS7TKQoufUBQrCGOjCHP BCstYujPYDJHDujCWl+ihF+jxL9VsFpFWT+1uOqjBlvChTLkJVtmdp4nxTrkLTUl8GdwNTKNtM0D 9tqD2pSnyp4jRj9HhV6OGowxHDEL8NlJzu+otCrOjCEUN1UVoQFTlxJlBkW1q11vHJ819UqyNOIw IUIGESdF40bORz4GITrorWQi8F9GEWSQiiI2KrLwqFnFvV9P4U7VluhyVLYlStsw0kgVmQ2i/s9g FOjEy1OK8GQ2gqn0zVluBSQiGMtlOWQwIuu2gQCCXWRPuVokHGITzuGjKy0rsWDlS2sJGIaWEUFS 5WYGlwqVZFylmzs2zOKkBzuJk2Ow9mFL/25ybpzjxGr2qnhWnQGCCMGGhvFiInvEBsvjTFTM8Nbu 9Fz3CiZv3CjsXEyNYjTGTs6XFgFE/kJnSXLu3EJRljVlTu0nDF+3QwODTEs3SqU3KF2vTzXto3ES KEhJKXYzOiQJxXMuOTOv5F21QFSlYjTDNlsXfpVXKqEXiG1iRnhJ2m1m6CMp2oaFFtgTOjetyjTE m3lo1E/D/zs2G3twS3qK8jTP4XvDTF+XniLH53zWsPQHeDmi032KPXvoQXhvXk4K6KJPspNPAOtX TPFHfUa3/PNHTXCiaNmXBDxE0rdNomnP/qBpAuLvZkUFpjWO3HK384KvFNqpks6HJk4ixXOQ4wdJ I4QmHS8G9kyqLrN4RkmsXKJk0m94WzoiHTCTXj+FpktKlTXtBlRH5m9iiFsEcj7QMCJJ8wFGroDt lFYmUO4IglSqBlRG5Yk00YcMVwPzoijQbTZ0RPniZTos1k1UJTo4Mm9iczZ4Mm4S1Ygpejp29KLi NjfFWRjOBGo3pP0364mu6QHnMnU3KYE3Cv04Dw4XXQqyvNwjT4jFgxYjcmH3vI7iNY+VTCYYXnSZ HY4WHEkjQvsErXVOCvuk63VS5jVpu4VxKr9ZSi4JQwnZSozio43peqvVO5X1bj7ihLclRHHozwUT okFZYjgTZoQLEDVvJFxCvRqmTHhFxRUPsYgToiRxiGTX6jYpnZmYJp2qnxBzL3kI75XX0CSrEEVS uZttD5Ky1Cm5VX0DWqqIz5CCwr1wPJCFvYo0gRtEbY1jwrBo3OO4cD+IzizZknErEZ9aAFVi9ISw s4KDuZuRJJqzCG/Y14yYO5XioiSKJpKJ9IjZUpzZ5C5ol0TKTLcj0iMIA0qYQi6yGw0lBzvHeNhP k5G1OyGl2zr6RSGl83C6Tojn0X66Kaciw6X6eImEmFvaaLwNlR7aiLKCSqL4jtYrM30Y8ka1RNRT 4IXJikrQOIECZ5E6oCrpGGT6mSC5usEUQGhlpkdLi4RTKqJvz5StATmxlYVH5X8isr/mL5CCKaOY Qan5Ew23vTqj25y4fGXPz5t7B5Oo9zzPztMXui5zL62kc0y5UWmJxiDWPXkLt44VRXkaE5yiO4MC MJ9FGp/pe4t5iMDa8vmEcvfaGlpPQaVbWT1Z759kkxJTXx3a/zJX0YwGUE9MXbNzX7LaAtIsQGHJ 83Qsvr968qBpCaADY17jEa44DFpG3YC3MHSplY1jNullKFDsgi+nbltY1jUV72j62i20W7JUTpOX C4TRV6VD6Lcsk7okSUgpw4vwx0ZmI68v4DFx7DVvBEdYMMnHl8BNFCL7ZV+bG38m78B4San4kLa6 EawbwQ47jCcZBCGqnYQ5AzKviJ64IOlx26t8Ib1CHaX6uP0cN4IxsuqqW30DWWol/KKX0C70mPX7 fKC8bCO3qGr1TiZ7A8SF/JlXslnMXF2vfWwcjFYY+Fs1HiZQkp2lDnbnnNBwFUq38cTx5CUcslpF iXjr3y3bZqHJ8pGcxZplpcy6AYaQtQ262q6OIb0l/DK4Sxlj/slM6WHGKMbtJnkZkYvwOOqmFLe8 OHbtSsB9CV3cXTRQOMtk3UFbLlyuOal7hF/CCYXLGcldLToimMnGB9LiJF+l2zhY2T42sbWVZ6xb YEfUW4o089WLGJ49VzOjVQqbsZvYl9HZy5v7httCia4ovrtuLYQ7rdhJi3nHbmpre9j216Ore7rK 782wjLwdoXJGrOgWLa4jAdrmTdftmMPujLJdq9tN11otspAmb2IkhbQGLuO2IvqdD90Wki54OdrW imba0dl2gOBW9j6JFd3SjJXxH97JI6b8SOjD9YS9/WaVUdq98ujCma41BWikkxUax2Gd59leFWpJ I+G+NdwFhLdd4xsghAqCGAXgjHeCPAqXBHTDOmimipAkuufCJKLoJivAqGnQCJKAqCrGigqA7iGA UAQehgQAUgqA1CGAi+SgFEZ1ltZoM3uP/HfCkgWrJNLCktPUTLRiGA4uvFkHH+XgQerNRi7enjZC pif2TmnAhAk+TAr+xCS+TAkGJ+TAhAoAh+xeTAkgmgQA6A5A6tPgFAXgk+++//AgkgiAQB/h8AAf G/HAPh4fHfGgBh/h/h4fF/JfGgHhwfMgA/K/L/I/MgHhgfO/Ph//OfMgDhAfS/LfT/MgAADhCfX/ TfSfMgBhPfXg//WhGfX/b/c/W/cfOhP/f/L/g/Mhn/Xgf/W/h/Xhj/V/JflfLhH/n/JAx/qfGgP/ Whn/r/G/rfM/s/Lhz/a/JA5/x/NfWhz/UfJAY/1fz/Lh5/2/Ggcf4gH/W/4fXgMf4gD/Wh8/Q/JA OCAPAAQOBgN/vB/vmBQSBgw8QwAQaEPx8RAAA6HwwAwd/vyMwwHDCIRuEP48P+KgAHv9HjA/uCBg 9wxx/DCUTF/h8AP+YAAPzOEP+NymVh9AP9gTGgP9/xKBgd/j9A0iYsOOP9ARGGH+swyoUGkget0k HQSV2AAAeuzukh6n0yg1kD0mN1ifQW4UynzC61mdAC60G94CmX6B4G9RGF4kH128v6Cws/v+n0md xx+QMYyk/5AAOfLZOJwM8ykf55xz3RR2BnjMgAf5kA6mBj+OSl4Z4P5kBsGF7aEQIAvA/QMPxUBs iUh+OcJxD6Y8jlcaOTABucfzGBAdOUTqxFj38DzADj4+TiEeRnp+5TAHj7oWmOWFns+kgOyD/41+ 7A9PvsiKsg8P6/ok/oPnOvisg4f5PrwhC/B/BKGBxBqspIyifQkhaBwqZ8Lo4gYfB+ecOAAPJ/mO yyDteHg/nylKBnmf7aJ2eEWxfGIAHHGjVRu1qOtewBzn+eLJHglJ8n+fzPMAY6UN+eCFnjJbioLJ 58NNKTARmfzsoKR6Oy0vkeKiggDzCjzjHg60iKiroDuYfweO0+5nqY9iBgc2x/viB54PophHstPa mLclR4LkT6mQAAAOMmnKn0SlTmH/CdHUgR6sgHSYH0rS4MUhD7FONPkSw6pkU02hcBqZIyBjjVLQ MAhcXKZGCBhnVJxrohY+VSfDXoNVye0mk6mH5YVU1eAFJnxVJ/PO+SmHwhY4KTKimH9KyoWQjIYK TGdtP3VM1AAGBwNnVM+rfbVpXQ691k9dslviCB4AHJ9Ukdeh/0Pe4DzvVJnX7Q4AHwA9F1SYjbEP dZEMng9PXWcjJ4dVJAYifmJ1ScDJzDVJgY02F1oXSqmJ6CDKUguDqVShYYAaBQiiTmQo5kIQqZkG YXBwGwchAGGghAGQXByGwbhAGIYZ4GgbhqEAahuFwZByGQQCoNuZBQEGuhAFIqDVmQi50BWhbPpQ QDXmW0aEGIQCXtgXBiGeoDuEGeZ8GgQCaEGZDjmQY7mGeraHs+ehuG4ccMEAx60BW6byGGgBuGgX BsHG38funBBkHGr8ry/MhANnAhnzvPhAHGeBmGmodLyAYhwFwahrxfVhd1vX8D2QXBgGIbdV1nXa UGOphtt/P56HO9hj43L+Tou66uMfeeP5PBczt/ndmGHkdVwQZ+D7nL6Z8Hc+D6vIBkGwXBuGWocz 9HScDz3aaf8/xaUGYYbnyYIAbg5aM8B/b/WluUe6DZqD6m6QGf+Dd9r7Htv2BtAqADlnEtXBi+xo wMGoOhcw2+BgMXLAweJCB0bsHnNFZ+6By0IXiuCBq7KAANWev/edDKGjiWqAwcXCOHTt4bA4fe/R 2MJXiA4iHEWFUJHfQnamDVn8RnnRIg/FEGTzYnQmiuC5pzQA8u8itABqbrQZvFcs3SLoMofRoaoD dt8PI2Q/fq+198a42wqBk1N4zwY5Rtg28ePcZHoPNj25eQbim5vOca/WQTSZFRSg1IcGQMo4uzaO 4uDcdn4QAkw5iRrsXZg3Bm4uRUmYqO9Z/GeU8oHyA2BpKaT8mneu1lk0aUEI47RtlbLSG0lmgA4f 665pLzpfgxmC9IGDSYRzHmDGlqTxZdxCcRBqWrtnVRLeo6ZqYOYCRKmrFQGc3ZvvDd25AGbeQat7 dw7qcTknKQvhSzIMTNm5NMb23dv7gXBuFba4hxTjHHOBe80YHDe4eP4c3QUHNB5CA3hM0qZcT6Hw EaW1OH0XWkQioJHx/EPJsUXaoDlykUYp0iBo3WQkCmgQMom7WkrlwcxnpFNGHlMwQRhchS9pM4HP tJia/1ydPYhyDqC74HMkI+A2jPUeochI5vFqFUmQj3KpVIqU3OpkoXnVTkhEOHEPpcTxdE9unkF6 y1coZKWtEMGlvtf5JBywOZl0SiHHGGzdY6AKoa+h+LRZhVNZlX18Vf2eg0aBYRq7yqD2JdnHuwwO HmShr67Kw1DW919hNMmg1mZyTssBZN9VSYbvRZ68G0kwrTNScXTq1MWa0PvqBYOX4NYXPuqNbRql tnhO5aA7AHNtbFzmBBcG3dw4vUquM/C5DhLKXCdVBgGlma4TUiI1e0jibrRFtG7MGjyZtXFgFCax cNpYWogEDWtk4JkQLoI+2zFD5zz1AUzcBTOWd2naA2horR5itSi9IzADVWrtZbYCAM7W2vthZkC8 I0JG0hUDM/Vqjp3GQCwg8CYbV4KvumxgZszWH1AoCSFQKbYGxMzbKQENCmVuZHN0cmVhbQ0KZW5k b2JqDQozIDAgb2JqDQo8PA0KL1Byb2NTZXQgWy9QREYgL1RleHQgL0ltYWdlQiBdDQovRm9udCA8 PA0KL0YzIDQgMCBSDQovRjUgNSAwIFINCi9GNyA2IDAgUg0KL0Y4IDcgMCBSDQovRjEwIDggMCBS DQovRjEyIDkgMCBSDQovRjE0IDEwIDAgUg0KL0YxNSAxMSAwIFINCj4+DQovRXh0R1N0YXRlIDw8 DQovR1MxIDEyIDAgUg0KPj4NCj4+DQplbmRvYmoNCjE0IDAgb2JqDQo8PA0KL1R5cGUgL0hhbGZ0 b25lDQovSGFsZnRvbmVUeXBlIDENCi9IYWxmdG9uZU5hbWUgKERlZmF1bHQpDQovRnJlcXVlbmN5 IDYwDQovQW5nbGUgNDUNCi9TcG90RnVuY3Rpb24gL1JvdW5kDQo+Pg0KZW5kb2JqDQoxMiAwIG9i ag0KPDwNCi9UeXBlIC9FeHRHU3RhdGUNCi9TQSBmYWxzZQ0KL09QIGZhbHNlDQovSFQgL0RlZmF1 bHQNCj4+DQplbmRvYmoNCjE1IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnREZXNjcmlwdG9yDQovQXNj ZW50IDANCi9DYXBIZWlnaHQgMA0KL0Rlc2NlbnQgMA0KL0ZsYWdzIDQNCi9Gb250QkJveCBbMCAt MTAgNTMzIDc1OF0NCi9Gb250TmFtZSAvRkRER01BK0NoYXJjb2FsDQovSXRhbGljQW5nbGUgMA0K L1N0ZW1WIDANCi9DaGFyU2V0ICgvZzU1L2cwL2czL2c0NC9nNTQpDQovRm9udEZpbGUgMTYgMCBS DQo+Pg0KZW5kb2JqDQoxNiAwIG9iag0KPDwNCi9MZW5ndGggMTIyOA0KL0xlbmd0aDEgMzcyDQov TGVuZ3RoMiA4NTQNCi9MZW5ndGgzIDANCj4+DQpzdHJlYW0NCiUhRm9udFR5cGUxLTEuMDogRkRE R01BK0NoYXJjb2FsIDEKMTMgZGljdCBiZWdpbgovRm9udE5hbWUgL0ZEREdNQStDaGFyY29hbCBk ZWYgCi9Gb250VHlwZSAxIGRlZgovRm9udEJCb3ggezAgLTEwIDUzMyA3NTh9IHJlYWRvbmx5IGRl ZgovRm9udE1hdHJpeCBbMC4wMDEgMCAwIDAuMDAxIDAgMF0gcmVhZG9ubHkgZGVmCi9QYWludFR5 cGUgMCBkZWYKL0ZvbnRJbmZvIDEyIGRpY3QgZHVwIGJlZ2luCi9CYXNlRm9udE5hbWUgKENoYXJj b2FsKSBkZWYKZW5kIGRlZgovRW5jb2RpbmcgMjU2IGFycmF5CjAgMSAyNTUgezEgaW5kZXggZXhj aCAvLm5vdGRlZiBwdXR9IGZvcgpyZWFkb25seSBkZWYKY3VycmVudGRpY3QgZW5kCmN1cnJlbnRm aWxlIGVleGVjCvH3xrhENUrjMbMGjCnz66SpRUCvxW6PwEA+qRihumVm6RWZPOgnnT5aJSexxdkp i4If3X9UGjlpY+cCd/U2xJMvFBMuiR39s/GYNBySN6QANwLxx/J1CL+XVi14ajWOd36i0+hDZC65 ptDwk5lYUFl+dPfdlJZrl0/DrvpsQhAHE0Tk8HOTBZ/5SqhQAp75hwWBT31cImk5O6yZm5OV9tml Nq+JXO/wkehXT5gyMoIfEyEpjVDDHrQGfjo2K9iEdUTMFgcIDefRgc7Sv1/YfuOvaYUWaLB186FX 0yCm1g1MHkHDBP6PWs/HoPOszQ6ZIJPMYzPLWxNOxFyOz4RIgBBPLA2AiAUQC/9WK9+5s1yOUGVJ r7MyN85Kw9VcSZEGcWqoF849qzk5hL/ufGTtVZtdhDO1Sg9GDXAvZfVzdO1HDEk3DEt9SvMcVpWu IXliyeIbNV+eAoC26vbMBrm/AF1guc6LMBlvwG0HvJvpL3ohceVlHE3iZxvd7Sg9YTcUQ4vt66gB xKVVzoZw2ZID1HOO55w5KcVrovzulb3xmZbVkgOPZAaFVss64mxW5O5g58Hr9yV5Fe7qcCh+DAfJ l8w5aAesPy/2p3E8hEjXs7i6gO3dKAhHZdlrlAp1EZNQlit+5iEHfK4f2QzejUGIxhoJVwlV3hvL AAPsgf5gPsjAbVu9gFLRoR0XKPvgUNzHB5r22G4Gin81cJDvcL1k1AyWTEBCzpdliWq/rnTqREgq 2vkbR2ZoUlagxLuo1OWI5QSdEE/i1lMi+7p7j8mIRs2gSammjUWEAI1jXVpyJMz2U/B+mq3OqwUi +O+iU7xTRY2hJLGZ2EdPXxogYQsdsjDBmqCBdMdzn5srwep020doXEKFcOPhNvhqQubYsbc4UwRx gJkXZXaM/bSMD8UxGqj0HeW3F/WN7WqzahCCaMM0Aic0EuMBQ8UcvfP5yo090N4EZufM6gwUgKXe XYClzgmj+/9q+Qiqdnc0BwMRIq2POehm91g1uY2mknAAJIfwzCzbq6wCO4zKbWyOfm2bwdIX4Hdw zt/HKhQM4VkZRgvkwTycTKhveQm/yrpoI7RkAjAWz3rbojtnp6akNajeshwXKZIvt6vLdXWJG552 6c0bhGpSrZLlDQplbmRzdHJlYW0NCmVuZG9iag0KNCAwIG9iag0KPDwNCi9UeXBlIC9Gb250DQov U3VidHlwZSAvVHlwZTENCi9OYW1lIC9GMw0KL0VuY29kaW5nIDE3IDAgUg0KL0Jhc2VGb250IC9I ZWx2ZXRpY2EtQm9sZA0KPj4NCmVuZG9iag0KNSAwIG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3Vi dHlwZSAvVHlwZTENCi9OYW1lIC9GNQ0KL0VuY29kaW5nIDE3IDAgUg0KL0Jhc2VGb250IC9UaW1l cy1Cb2xkDQo+Pg0KZW5kb2JqDQo2IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9U eXBlMQ0KL05hbWUgL0Y3DQovRW5jb2RpbmcgMTcgMCBSDQovQmFzZUZvbnQgL1RpbWVzLVJvbWFu DQo+Pg0KZW5kb2JqDQo3IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UeXBlMQ0K L05hbWUgL0Y4DQovQmFzZUZvbnQgL1N5bWJvbA0KPj4NCmVuZG9iag0KOCAwIG9iag0KPDwNCi9U eXBlIC9Gb250DQovU3VidHlwZSAvVHlwZTENCi9OYW1lIC9GMTANCi9FbmNvZGluZyAxNyAwIFIN Ci9CYXNlRm9udCAvSGVsdmV0aWNhDQo+Pg0KZW5kb2JqDQo5IDAgb2JqDQo8PA0KL1R5cGUgL0Zv bnQNCi9TdWJ0eXBlIC9UeXBlMQ0KL05hbWUgL0YxMg0KL0VuY29kaW5nIDE3IDAgUg0KL0Jhc2VG b250IC9UaW1lcy1JdGFsaWMNCj4+DQplbmRvYmoNCjEwIDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQN Ci9TdWJ0eXBlIC9UeXBlMQ0KL05hbWUgL0YxNA0KL0ZpcnN0Q2hhciAwDQovTGFzdENoYXIgODQN Ci9XaWR0aHMgWzUwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCANCjAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgDQoyNDkgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg DQowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIA0KMCAwIDAgMCAwIDAgMCAwIDAgMzY2 IDAgMCAwIDAgMCAwIA0KMCAwIDAgNTY0IDUwMCBdDQovRW5jb2RpbmcgMTggMCBSDQovQmFzZUZv bnQgL0ZEREdNQStDaGFyY29hbA0KL0ZvbnREZXNjcmlwdG9yIDE1IDAgUg0KPj4NCmVuZG9iag0K MTEgMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1YnR5cGUgL1R5cGUxDQovTmFtZSAvRjE1DQov RW5jb2RpbmcgMTkgMCBSDQovQmFzZUZvbnQgL0hlbHZldGljYQ0KPj4NCmVuZG9iag0KMTcgMCBv YmoNCjw8DQovVHlwZSAvRW5jb2RpbmcNCi9EaWZmZXJlbmNlcyBbIDAvZ3JhdmUvYWN1dGUvY2ly Y3VtZmxleC90aWxkZS9tYWNyb24vYnJldmUvZG90YWNjZW50L2RpZXJlc2lzDQovcmluZy9jZWRp bGxhL2h1bmdhcnVtbGF1dC9vZ29uZWsvY2Fyb24vZG90bGVzc2kvYnVsbGV0L2J1bGxldA0KL2J1 bGxldC9idWxsZXQvYnVsbGV0L2J1bGxldC9idWxsZXQvYnVsbGV0L2J1bGxldC9idWxsZXQNCi9i dWxsZXQvYnVsbGV0L2J1bGxldC9idWxsZXQvYnVsbGV0L2J1bGxldC9idWxsZXQvYnVsbGV0DQog MzkvcXVvdGVzaW5nbGUgOTYvZ3JhdmUgMTI3L2J1bGxldC9idWxsZXQvYnVsbGV0L3F1b3Rlc2lu Z2xiYXNlL2Zsb3Jpbi9xdW90ZWRibGJhc2UNCi9lbGxpcHNpcy9kYWdnZXIvZGFnZ2VyZGJsL2Np cmN1bWZsZXgvcGVydGhvdXNhbmQvU2Nhcm9uL2d1aWxzaW5nbGxlZnQvT0UNCi9idWxsZXQvYnVs bGV0L2J1bGxldC9idWxsZXQvcXVvdGVsZWZ0L3F1b3RlcmlnaHQvcXVvdGVkYmxsZWZ0L3F1b3Rl ZGJscmlnaHQNCi9idWxsZXQvZW5kYXNoL2VtZGFzaC90aWxkZS90cmFkZW1hcmsvc2Nhcm9uL2d1 aWxzaW5nbHJpZ2h0L29lDQovYnVsbGV0L2J1bGxldC9ZZGllcmVzaXMvc3BhY2UgMTY0L2N1cnJl bmN5IDE2Ni9icm9rZW5iYXIgMTY4L2RpZXJlc2lzL2NvcHlyaWdodA0KL29yZGZlbWluaW5lIDE3 Mi9sb2dpY2Fsbm90L2h5cGhlbi9yZWdpc3RlcmVkL21hY3Jvbi9kZWdyZWUvcGx1c21pbnVzL3R3 b3N1cGVyaW9yDQovdGhyZWVzdXBlcmlvci9hY3V0ZS9tdSAxODMvcGVyaW9kY2VudGVyZWQvY2Vk aWxsYS9vbmVzdXBlcmlvci9vcmRtYXNjdWxpbmUgMTg4L29uZXF1YXJ0ZXINCi9vbmVoYWxmL3Ro cmVlcXVhcnRlcnMgMTkyL0FncmF2ZS9BYWN1dGUvQWNpcmN1bWZsZXgvQXRpbGRlL0FkaWVyZXNp cy9BcmluZw0KL0FFL0NjZWRpbGxhL0VncmF2ZS9FYWN1dGUvRWNpcmN1bWZsZXgvRWRpZXJlc2lz L0lncmF2ZS9JYWN1dGUNCi9JY2lyY3VtZmxleC9JZGllcmVzaXMvRXRoL050aWxkZS9PZ3JhdmUv T2FjdXRlL09jaXJjdW1mbGV4L090aWxkZQ0KL09kaWVyZXNpcy9tdWx0aXBseS9Pc2xhc2gvVWdy YXZlL1VhY3V0ZS9VY2lyY3VtZmxleC9VZGllcmVzaXMvWWFjdXRlDQovVGhvcm4vZ2VybWFuZGJs cy9hZ3JhdmUvYWFjdXRlL2FjaXJjdW1mbGV4L2F0aWxkZS9hZGllcmVzaXMvYXJpbmcNCi9hZS9j Y2VkaWxsYS9lZ3JhdmUvZWFjdXRlL2VjaXJjdW1mbGV4L2VkaWVyZXNpcy9pZ3JhdmUvaWFjdXRl DQovaWNpcmN1bWZsZXgvaWRpZXJlc2lzL2V0aC9udGlsZGUvb2dyYXZlL29hY3V0ZS9vY2lyY3Vt ZmxleC9vdGlsZGUNCi9vZGllcmVzaXMvZGl2aWRlL29zbGFzaC91Z3JhdmUvdWFjdXRlL3VjaXJj dW1mbGV4L3VkaWVyZXNpcy95YWN1dGUNCi90aG9ybi95ZGllcmVzaXMNCl0NCj4+DQplbmRvYmoN CjE4IDAgb2JqDQo8PA0KL1R5cGUgL0VuY29kaW5nDQovRGlmZmVyZW5jZXMgWyAwL2cwIDMyL2cz IDczL2c0NCA4My9nNTQvZzU1DQpdDQo+Pg0KZW5kb2JqDQoxOSAwIG9iag0KPDwNCi9UeXBlIC9F bmNvZGluZw0KL0RpZmZlcmVuY2VzIFsgOS9zcGFjZSAzOS9xdW90ZXNpbmdsZSA5Ni9ncmF2ZSAx MjgvQWRpZXJlc2lzL0FyaW5nL0NjZWRpbGxhL0VhY3V0ZS9OdGlsZGUNCi9PZGllcmVzaXMvVWRp ZXJlc2lzL2FhY3V0ZS9hZ3JhdmUvYWNpcmN1bWZsZXgvYWRpZXJlc2lzL2F0aWxkZS9hcmluZw0K L2NjZWRpbGxhL2VhY3V0ZS9lZ3JhdmUvZWNpcmN1bWZsZXgvZWRpZXJlc2lzL2lhY3V0ZS9pZ3Jh dmUvaWNpcmN1bWZsZXgNCi9pZGllcmVzaXMvbnRpbGRlL29hY3V0ZS9vZ3JhdmUvb2NpcmN1bWZs ZXgvb2RpZXJlc2lzL290aWxkZS91YWN1dGUNCi91Z3JhdmUvdWNpcmN1bWZsZXgvdWRpZXJlc2lz L2RhZ2dlci9kZWdyZWUgMTY0L3NlY3Rpb24vYnVsbGV0L3BhcmFncmFwaA0KL2dlcm1hbmRibHMv cmVnaXN0ZXJlZC9jb3B5cmlnaHQvdHJhZGVtYXJrL2FjdXRlL2RpZXJlc2lzL25vdGVxdWFsL0FF DQovT3NsYXNoL2luZmluaXR5L3BsdXNtaW51cy9sZXNzZXF1YWwvZ3JlYXRlcmVxdWFsL3llbi9t dS9wYXJ0aWFsZGlmZg0KL3N1bW1hdGlvbi9wcm9kdWN0L3BpL2ludGVncmFsL29yZGZlbWluaW5l L29yZG1hc2N1bGluZS9PbWVnYS9hZQ0KL29zbGFzaC9xdWVzdGlvbmRvd24vZXhjbGFtZG93bi9s b2dpY2Fsbm90L3JhZGljYWwvZmxvcmluL2FwcHJveGVxdWFsL0RlbHRhDQovZ3VpbGxlbW90bGVm dC9ndWlsbGVtb3RyaWdodC9lbGxpcHNpcy9zcGFjZS9BZ3JhdmUvQXRpbGRlL090aWxkZS9PRQ0K L29lL2VuZGFzaC9lbWRhc2gvcXVvdGVkYmxsZWZ0L3F1b3RlZGJscmlnaHQvcXVvdGVsZWZ0L3F1 b3RlcmlnaHQvZGl2aWRlDQovbG96ZW5nZS95ZGllcmVzaXMvWWRpZXJlc2lzL2ZyYWN0aW9uL0V1 cm8vZ3VpbHNpbmdsbGVmdC9ndWlsc2luZ2xyaWdodC9maQ0KL2ZsL2RhZ2dlcmRibC9wZXJpb2Rj ZW50ZXJlZC9xdW90ZXNpbmdsYmFzZS9xdW90ZWRibGJhc2UvcGVydGhvdXNhbmQvQWNpcmN1bWZs ZXgvRWNpcmN1bWZsZXgNCi9BYWN1dGUvRWRpZXJlc2lzL0VncmF2ZS9JYWN1dGUvSWNpcmN1bWZs ZXgvSWRpZXJlc2lzL0lncmF2ZS9PYWN1dGUNCi9PY2lyY3VtZmxleC9hcHBsZS9PZ3JhdmUvVWFj dXRlL1VjaXJjdW1mbGV4L1VncmF2ZSAyNDYvY2lyY3VtZmxleC90aWxkZQ0KL21hY3Jvbi9icmV2 ZS9kb3RhY2NlbnQvcmluZy9jZWRpbGxhL2h1bmdhcnVtbGF1dC9vZ29uZWsvY2Fyb24NCl0NCj4+ DQplbmRvYmoNCjEgMCBvYmoNCjw8DQovVHlwZSAvUGFnZQ0KL1BhcmVudCAxMyAwIFINCi9SZXNv dXJjZXMgMyAwIFINCi9Db250ZW50cyAyIDAgUg0KPj4NCmVuZG9iag0KMTMgMCBvYmoNCjw8DQov VHlwZSAvUGFnZXMNCi9LaWRzIFsxIDAgUl0NCi9Db3VudCAxDQovTWVkaWFCb3ggWzAgMCA2MTIg NzkyXQ0KPj4NCmVuZG9iag0KMjAgMCBvYmoNCjw8DQovVHlwZSAvQ2F0YWxvZw0KL1BhZ2VzIDEz IDAgUg0KPj4NCmVuZG9iag0KMjEgMCBvYmoNCjw8DQovQ3JlYXRpb25EYXRlIChEOjE5MTAwMDEw NjEyMzI0MCkNCi9Qcm9kdWNlciAoQWNyb2JhdCBEaXN0aWxsZXIgMy4wIGZvciBXaW5kb3dzKQ0K L0NyZWF0b3IgKFBTQ1JJUFQuRFJWIFZlcnNpb24gNC4wKQ0KL1RpdGxlIChNaWNyb3NvZnQgV29y ZCAtIFJBV0NPTjIwMDBjZnAtaC5kb2MpDQo+Pg0KZW5kb2JqDQp4cmVmDQowIDIyDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMjM4MzYgMDAwMDAgbg0KMDAwMDAwMDAxNyAwMDAwMCBuDQowMDAw MDE4MDE3IDAwMDAwIG4NCjAwMDAwMTk5ODAgMDAwMDAgbg0KMDAwMDAyMDA5MSAwMDAwMCBuDQow MDAwMDIwMTk4IDAwMDAwIG4NCjAwMDAwMjAzMDYgMDAwMDAgbg0KMDAwMDAyMDM5MSAwMDAwMCBu DQowMDAwMDIwNDk4IDAwMDAwIG4NCjAwMDAwMjA2MDggMDAwMDAgbg0KMDAwMDAyMDk3NiAwMDAw MCBuDQowMDAwMDE4MzQ3IDAwMDAwIG4NCjAwMDAwMjM5MjUgMDAwMDAgbg0KMDAwMDAxODIxNCAw MDAwMCBuDQowMDAwMDE4NDI3IDAwMDAwIG4NCjAwMDAwMTg2NTMgMDAwMDAgbg0KMDAwMDAyMTA4 NCAwMDAwMCBuDQowMDAwMDIyNTE2IDAwMDAwIG4NCjAwMDAwMjI2MDcgMDAwMDAgbg0KMDAwMDAy NDAxNSAwMDAwMCBuDQowMDAwMDI0MDcyIDAwMDAwIG4NCnRyYWlsZXINCjw8DQovU2l6ZSAyMg0K L1Jvb3QgMjAgMCBSDQovSW5mbyAyMSAwIFINCi9JRCBbPDVmNGQ5MGYxZDE2MzM0YjczZTYzMzIw MmQ3NTA5NGFkPjw1ZjRkOTBmMWQxNjMzNGI3M2U2MzMyMDJkNzUwOTRhZD5dDQo+Pg0Kc3RhcnR4 cmVmDQoyNDI2Mw0KJSVFT0YNCg== ------_=_NextPart_000_01BF5B7E.97650450-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 10 11:43: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 LAA07506 for ; Mon, 10 Jan 2000 11:43:20 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3BD5E430@standards.nortelnetworks.com>; Mon, 10 Jan 2000 11:31:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 115450 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 11:29:28 -0500 Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F42206A0@standards.nortelnetworks.com>; Mon, 10 Jan 2000 11:29:27 -0500 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Mon Jan 10 11:39:25 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 LAA13666; Mon, 10 Jan 2000 11:39:24 -0500 (EST) X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 References: <200001070846.AAA18384@servo.qualcomm.com> <20000107221014.1457C5701C@king.research.bell-labs.com> <200001080113.RAA20516@homer.ka9q.ampr.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <387A0CDB.F34CC7B0@dnrc.bell-labs.com> Date: Mon, 10 Jan 2000 16:46:19 +0000 Reply-To: ramjee@DNRC.BELL-LABS.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ramachandran Ramjee Subject: [MOBILE-IP] Why Mobile IP? [was: AAA functionality] X-To: karn@qualcomm.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Phil, I have been following your arguments in lurk mode and I agree with most of the points you make (such as the use of colocated addresses etc.) However, I don't think that wireless data service deployment is being held back by the complexity of Mobile IP - in fact, Mobile IP is an extremely simple protocol (If a client can have TCP, which it must, everything else is trivial!) It is the wireless side of things (bandwidth, price, utility, compatability/reuse of telco infrastructure) that is holding things back...I believe that it is fairly trivial to set up a wireless data service with WaveLANs (with DHCP and Mobile IP as well) but when you add issues with CDMA/GSM base stations, power-saving/paging, provisioning, interworking with voice services, etc., it gets complicated. The key question is does one just assume that packet data service will just be web access and be an adjunct to current voice infrastructure? If yes, just slap on a DHCP server with some AAA functionality, an interworking function to current base stations with some performance optimizations like header compression, a NAT for IP-address starved ISPs and be done with it. I think the Mobile IP community in general has a much more broader vision wherein the network is completely made up of IP addressable entities with air-interface specific processing relegated just to the base stations, and all services are delivered through IP (including voice). Only time can tell how things will end up... Finally, a personal pet peeve of mine...I think the different standard bodies now are trying to mix up both these models and are coming up with an ugly beast that is neither voice-centric nor data-centric... Cheers, Ram P.S. I felt the need to debate one of your points: you say CDMA has a "soft-handoff" capability that can only be implemented at the physical (link?) layer. Isn't this another violation of the end-to-end concept in itself? Why can't this "soft-handoff" service be achieved at the IP-layer (I can easily engineer a bunch of wavelan base stations to multicast IP packets during handoff for ONLY those users/services that need this feature)? From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 10 11:51: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 LAA07739 for ; Mon, 10 Jan 2000 11:51:22 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5BC103A0@standards.nortelnetworks.com>; Mon, 10 Jan 2000 11:39:30 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 115491 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 11:37:50 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1EA65060@standards.nortelnetworks.com>; Mon, 10 Jan 2000 11:37: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 JAA21188 for ; Mon, 10 Jan 2000 09:48:21 -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 IAA18618; Mon, 10 Jan 2000 08:48:16 -0800 (PST) Received: from onion (onion.East.Sun.COM [129.148.174.110]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA21207; Mon, 10 Jan 2000 08:48:16 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-MD5: OAW1AeDZTZc515BAcXpKDw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_36 SunOS 5.8 sun4u sparc Message-ID: <200001101648.IAA21207@jurassic.eng.sun.com> Date: Mon, 10 Jan 2000 11:48:21 -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] AAA functionality X-To: tweckstr@CC.HUT.FI To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id LAA07739 I'd also like to point out that not having a shared secret between the MN and HA can also be viewed as a policy issue, but Mobile IP requires it, as so many adamantly pointed out in DC! Despite this thread subject, this is a Mobile IP issue, not a AAA issue as it's up to the FA as the policy enforcement point. If a grace period is allowed, it'll also be an implementation issue. Another issue will be if the FA decides to revoke the registration request (after the HA has approved it) does it need to inform the home domain. This certainly is a AAA issue. Cheers, Steve >MIME-Version: 1.0 >Content-Transfer-Encoding: 8bit >From: Tom Weckström >Subject: Re: [MOBILE-IP] AAA functionality >To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > >Hello, > >I bring in my vote for the grace period... > > >N. Asokan wrote: >> >> I think whether to allow free time or not is ultimately a policy issue. >> Seems to me that we shouldn't devise a mechanism that precludes that >> policy. > > >I agree with Asokan, Patrik and others, that allowing the grace period >is a policy issue. Furthermore, we should not forbid such liberal >policies with our protocol design! >Telcos may not like the possibility of using their network even for >short periods of time. However, telcos are certainly not the only ones >providing wireless services in the future. As someone pointed out >earlier, the pure Ip accessibility may even not be the ultimate source >for cash flows. I hope every university lab or airport lobby bar will be >able to set up its own wireless AP and start providing access to the >Internet. As the number of access provider increases, the number of >"inter-domain" handoffs may significantly increase. I really do not want >to mandate _everyone_ to disable the grace period and thus end up in >rediculous latencies and unbearable glitches in the connections. > > >Best regards, > Tom > > >-- > Tom Weckström tweckstr@cc.hut.fi > Otakaari 20 B 39 Helsinki University of Technology > 02150 Espoo Department of Computer Science From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 10 13:17:32 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 NAA09774 for ; Mon, 10 Jan 2000 13:17:31 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.69E55A10@standards.nortelnetworks.com>; Mon, 10 Jan 2000 13:05:48 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 115680 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 13:05:13 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.54690420@standards.nortelnetworks.com>; Mon, 10 Jan 2000 13:05:12 -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 KAA27703 for ; Mon, 10 Jan 2000 10:15:43 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id KAA29104 for ; Mon, 10 Jan 2000 10:15:42 -0800 X-Virus-Scanned: Mon, 10 Jan 2000 10:15:42 -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) xma029013; Mon, 10 Jan 00 10:15:40 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <200001042003.MAA19380@jurassic.eng.sun.com> <387399CC.613C5C50@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <387A21CB.A09F45EC@iprg.nokia.com> Date: Mon, 10 Jan 2000 10:15:39 -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 am "following up" to my own notes of discussion regarding some comments made by Alper Yegin. I would like to issue a new draft, so I made some provisional decisions that will be detailed below. I would like to reissue the draft before tomorrow afternoon, so any timely comments would be appreciated. For anyone who wishes to see the newly revised draft, I have put it on my web page, at: http://www.iprg.nokia.com/~charliep/txt/mobileip/mobileip.txt The document has appendices with a list of changes, and a list of open issues that I know about. > Alper Yegin wrote: > > > [1] > > > > 3.4. Registration Reply > > ... > > UDP fields: > > > > Source Port > > > > Destination Port Copied from the source port of the > > corresponding Registration Request > > (Section 3.7.1). > > > > Why source port is a variable, why not 434? Forcing it to be 434 would make it > > *possible* to recognize this packet as MIP signalling on the wire. How about > > even saying that MN should use port 434? > > This seems like a perpetual unsolved design issue. Some people > say that having the source port variable enables better multi-threaded > design. Some say not. I'll change it if people say to change it, > but I don't think it should be changed unless there is more support. Current status: no change. > > [2] > > > > 3.1. Registration Overview > > ... > > The registration messages defined in Sections 3.3 and 3.4 use the > > User Datagram Protocol (UDP) [17]. A nonzero UDP checksum SHOULD be > > included in the header, and MUST be checked by the recipient. > > > > ...and later: > > > > 3.7.2.1. Validity Checks > > > > Registration Requests with an invalid, non-zero UDP checksum MUST be > > silently discarded. > > > > It's not very clear if a UDP chekcsum 0 is accepted or not. > > I agree it's not clear. I can add text that clarifies it. > One possibility would be to let the foreign agent accept such > packets, and to let action by the mobile node and home agent be > defined by whatever is in the Mobility Security Association between > them. In the absence of further discussion, I inserted the following text: A zero UDP checksum SHOULD be accepted by the recipient. The behavior of the mobile node and the home agent with respect to their mutual acceptance of packets with zero UDP checksums SHOULD be defined as part of the mobility security association which exists between them. > > [3] > > > > 4.6. ARP, Proxy ARP, and Gratuitous ARP > > ... > > Finally, while the > > mobile node is away from home, it MUST NOT reply to ARP Requests > > in which the target IP address is its own home address, unless the > > ARP Request is sent by a foreign agent with which the mobile node > > is attempting to register or a foreign agent with which the mobile > > node has an unexpired registration. > > > > But we know that the FA MUST NOT send ARP. So, this is contradicting. > > Which part should be changed? I changed the word "sent" to "unicast". This allows the foreign agent to send ARPs as long as it is not broadcast. I think this means even not using any layer-2 multicast or broadcast address. Help on this point will be appreciated. I don't have time just now to go through all the previous archived discussion on this point. From some previous discussion, I have the following unresolved point: > Q: new FA forwarding text; sometimes two MNs on the same FA sometimes get > traffic forwarded directly rather than via HA. Also MNs can introduce > denial of service if they make a mistake in their registration > messages - sometimes re-registrations can be redirected at a MN! Do I need to do anything here? Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 10 14:04: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 OAA10582 for ; Mon, 10 Jan 2000 14:04:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0103D150@standards.nortelnetworks.com>; Mon, 10 Jan 2000 13:52:59 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 115750 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 13:51:11 -0500 Received: from jazz.cs.utsa.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5B250200@standards.nortelnetworks.com>; Mon, 10 Jan 2000 13:41:11 -0500 Received: from wayward.cs.utsa.edu (wayward [129.115.11.3]) by jazz.cs.utsa.edu (8.9.3+Sun/8.9.1) with ESMTP id MAA07506 for ; Mon, 10 Jan 2000 12:49:52 -0600 (CST) Received: (from samir@localhost) by wayward.cs.utsa.edu (8.9.3+Sun/8.8.8) id MAA00545 for mobile-ip@standards.nortelnetworks.com; Mon, 10 Jan 2000 12:49:52 -0600 (CST) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Message-ID: <200001101849.MAA00545@wayward.cs.utsa.edu> Date: Sun, 10 Jan 0100 12:49:52 -0600 Reply-To: "Samir R. Das" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Samir R. Das" Subject: [MOBILE-IP] Call for Papers: MobiCom 2000 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM [Our apologies for any duplicate transmissions] Announcement and 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 Sponsored by ACM SIGMOBILE In cooperation with ACM SIGCOMM and SIGMETRICS; IEICE (Japan) and IFIP WG 6.3 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Visit http://www.research.telcordia.com/mobicom2000/ for the most up-to-date information * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * MobiCom 2000 is the sixth of an annual series of international conferences dedicated to addressing the challenges in wireless and mobile computing, communications and networking. By bringing together researchers, practitioners, and visionaries from all over the world, MobiCom provides an environment where ideas flow freely between individuals instrumental in shaping the world of tomorrow. MobiCom is a highly selective conference where the quality of its technical program is ensured by an outstanding technical program committee. A number of social and technical events, such as speeches by leaders in the field, panels on timely and controversial issues, tutorials on basic and advanced topics, and workshops focused on pressing issues of the day, provide ample opportunities for learning and exchanging information between users, providers, and researchers. MobiCom 2000 will be held at the Seaport Hotel at the World Trade Center, located on Boston's historic waterfront. TECHNICAL PAPERS: Technical papers describing original, previously unpublished, and completed research, not currently under review by another conference or journal, are solicited on the following topics: o Applications and computing services supporting mobile users o Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity o Database and data management issues in mobile computing o Performance of mobile/wireless networks and systems o Security and privacy of mobile/wireless networks and systems o Interaction between different layers of mobile/wireless systems o Integration and interworking of wired and wireless networks o Adaptive applications and systems for mobile environments o Distributed-system aspects of mobile systems o Operating system support for mobility o Location-dependent applications o Wireless multimedia systems o Power management o Mobile agents All papers will be refereed by the program committee. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Baltzer Wireless Networks (WINET) and Mobile Networks and Applications (MONET) journals. *** NOTE *** SPECIAL PAPERS FOR CHALLENGES SESSION: MobiCom solicits short papers (8 pages max.) that challenge the mobile computing community with new technologies or visionary applications. Such papers should provide stimulating ideas or visions that may open up exciting avenues of mobile computing research. Papers will be reviewed and should be submitted using the normal procedure. However, the papers should be clearly identified as intended for the Challenges session. SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their full paper. Papers must meet the following restrictions: o No longer than 15 pages (8 pages for Challenges papers). o Fit properly on US Letter-sized paper (8.5x11 inches). o PostScript version 2 or later, or Portable Document Format (PDF). o Use only Computer Modern or standard Adobe printer fonts (i.e., Courier, Times, Roman, or Helvetica). Other fonts may be used but must be included in the PostScript/PDF file. All submitted papers will be judged based on their quality through double-blind reviewing, where the identities of the authors are withheld from the reviewers. Authors' names must not appear in the paper or in the PostScript/PDF file. Exact submission procedures will be available from http://www.research.telcordia.com/mobicom2000/ by December 17, 1999. Please direct any questions about the submission process to the Program Co-Chairs, Ramon Caceres (ramon@research.att.com) and J.J. Garcia-Luna (jj@cse.ucsc.edu). Paper submission deadline is February 18, 2000. TUTORIALS: Proposals for tutorials are solicited. Evaluation of proposals will be based on the expertise and experience of the instructors, and on the relevance of the subject matter. Tutorial topics that encompass the systems aspects of mobile computing and/or practical experiences in building/deploying such systems are of particular interest. Potential instructors are requested to submit a tutorial proposal of at most 5 pages, including a biographical sketch, to the Tutorial Co-Chairs, Venkat Padmanabhan (padmanab@microsoft.com) and Nigel Davies (nigel@comp.lancs.ac.uk), by February 18, 2000. PANELS: Panels are solicited that examine innovative, controversial, or otherwise provocative issues of interest. Panel proposals should not exceed 3 pages, including biographical sketches of the panelists. Potential panel organizers should send the proposal to the Panels Co-Chairs, Pravin Bhagwat (pravinb@us.ibm.com) and Andrew Campbell (campbell@comet.columbia.edu), by Februray 21, 2000. RESEARCH DEMOS: Informal proposals for research demos are solicited. Proposals will be reviewed and selection made based on value to the community and interest level for the conference. Proposals should not exceed 3 pages and should include: the focus area in mobility, such as mobile networks, applications, interfaces etc., the technologies involved in the research, specific equipments to be used for the demo, demo layout, space required to set up the demo and possible interactions (interoperability) with other proposed demonstrations (e.g., Mobile IP implementations). Send proposals to the Demo Chair: Ronald Hutchins (ron.hutchins@oit.gatech.edu). BEST STUDENT PAPER AWARD: Papers with a student as a primary author will be considered for a cash award of $500 US Dollars for the best student paper competition. Student authors must clearly indicate with their submission that they would like to be considered for this award. -------------------------------------------------------------------- IMPORTANT DATES: Paper submissions due: February 18, 2000 Notification of acceptance: April 28, 2000 Camera-ready version due: May 26, 2000 -------------------------------------------------------------------- FOR MORE INFORMATION: Send email to mobicom2000@research.telcordia.com with any questions or comments about the conference or for more information. This Call For Papers and other MobiCom 2000 information are available from http://www.research.telcordia.com/mobicom2000/. ORGANIZING COMMITTEE: General Chair: Raymond Pickholtz, George Washington University General Vice Chair: Sajal K. Das, University of Texas at Arlington Program Co-Chairs: Ramon Caceres, AT&T Labs J.J. Garcia-Luna-Aceves, University of California at Santa Cruz Steering Committee Chair: Imrich Chlamtac, University of Texas at Dallas Tutorials Co-Chairs: Nigel Davies, Lancaster University, UK (currently at Sony US Research Labs) Venkat Padmanabhan, Microsoft Research Panels Co-Chairs: Pravin Bhagwat, IBM Watson Research Andrew Campbell, Columbia University Research Demos Chair: Ronald Hutchins, Georgia Institute of Technology Workshops Chair: Jason Redi, BBN Technologies Local Arrangements Co-Chairs: Rajesh Krishnan, BBN Technologies John Zavgren, BBN Technologies Publicity Co-Chairs: Kwang-Cheng Chen, National Taiwan University Samir R. Das, University of Texas at San Antonio Ashutosh Dutta, Telcordia Technologies Registration Chair: Irene Katzela, University of Toronto Finance Chair: David B. Johnson, Carnegie Mellon University Industry Exhibits/Sponsorships Chair: Andrew Campbell, Columbia University European Liaison: Adam Wolisz, Technical University, Berlin Asia/Pacific Liaisons: K.-C. Chua, National University of Singapore Hiroyuki Morikawa, University of Tokyo, Japan TECHNICAL PROGRAM COMMITTEE: Arup Acharya IBM Research Ian Akyildiz Georgia Tech B. Badrinath Rutgers University Victor Bahl Microsoft Research Mary Baker Stanford University Hari Balakrishnan MIT Stefano Basagni University of Texas at Dallas Pravin Bhagwat IBM Research Vaduvur Bharghavan University of Illinois at Urbana-Champaign Andrew Campbell Columbia University Scott Corson University of Maryland Sajal Das University of Texas at Arlington Nigel Davies Lancaster University (currently at Sony US) Dan Duchamp AT&T Labs Metin Feridun IBM Research Armando Fox Stanford University Mario Gerla University of California, Los Angeles Zygmunt Haas Cornell University Tomasz Imielinski Rutgers University Ravi Jain Telcordia David Johnson Carnegie Mellon University Anthony Joseph University of California, Berkeley Tom LaPorta Lucent Venkat Padmanabhan Microsoft Research Charles Perkins Nokia Research Center Chiara Petrioli Politecnico di Milano George Polyzos University of California, San Diego Ramesh Rao University of California, San Diego Ram Ramanathan BBN Technologies Jason Redi BBN Technologies Christopher Rose Rutgers University M. Satyanarayanan Carnegie Mellon University Srini Seshan IBM Research Adarshpal Sethi University of Delaware Martha Steenstrup BBN Technologies Roy Want Xerox PARC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 10 15:30: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 PAA11755 for ; Mon, 10 Jan 2000 15:30:06 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F55018D0@standards.nortelnetworks.com>; Mon, 10 Jan 2000 15:18:33 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 116048 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 15:16:39 -0500 Received: from homer.ka9q.ampr.org (24.30.144.246) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4B5383E0@standards.nortelnetworks.com>; Mon, 10 Jan 2000 15:06:38 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id MAA11072; Mon, 10 Jan 2000 12:16:59 -0800 References: <200001070846.AAA18384@servo.qualcomm.com> <20000107221014.1457C5701C@king.research.bell-labs.com> <200001080113.RAA20516@homer.ka9q.ampr.org> <387A0CDB.F34CC7B0@dnrc.bell-labs.com> Message-ID: <200001102016.MAA11072@homer.ka9q.ampr.org> Date: Mon, 10 Jan 2000 12:16:59 -0800 Reply-To: karn@ka9q.ampr.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Phil Karn Subject: Re: [MOBILE-IP] Why Mobile IP? [was: AAA functionality] X-To: ramjee@dnrc.bell-labs.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <387A0CDB.F34CC7B0@dnrc.bell-labs.com> (message from Ramachandran Ramjee on Mon, 10 Jan 2000 16:46:19 +0000) >However, I don't think that wireless data service deployment is being >held back by the complexity of Mobile IP - in fact, Mobile IP is an >extremely simple protocol (If a client can have TCP, which it must, >everything else Nothing is ever "simple" when you involve formal telephone standards bodies, such as the TIA. The MIP protocol itself may be simple, but the debates over mobility in the TIA clearly delayed deployment of a packet data service. To be fair, MIP wasn't the only culprit in the delay. Just as significant (if not more so) was the carriers' insistence on making asynch dialup modem emulation and fax support top priority, and giving low priority to direct IP packet access. This continued even after we succeeded in persuading the TIA to base the asynch data/fax service, making packet data a subset of what's needed to support async data/fax. What I've always found truly astounding is when a carrier concedes that a certain feature is best done end-to-end, but that it must still be a mandatory network feature regardless of cost or delay because the "average user" won't want to install the necessary software to support the feature on his own computer. When it comes to adding new features needed by their customers, even Microsoft looks fast and responsive in comparison to most telephone industry vendors. QNC is a good example; it's a kludge that exists solely to bypass the foot dragging of certain base station vendors in implementing CDMA IP packet data service, even though they had already done async data & fax. Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 10 16:22: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 QAA13083 for ; Mon, 10 Jan 2000 16:22:13 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.403B9D90@standards.nortelnetworks.com>; Mon, 10 Jan 2000 16:10:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 116222 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 16:08:50 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FB6627D0@standards.nortelnetworks.com>; Mon, 10 Jan 2000 16:08:50 -0500 Received: from zmers013 by smtprch1.nortel.com; Mon, 10 Jan 2000 15:17:43 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Mon, 10 Jan 2000 16:17:21 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 10 Jan 2000 15:17:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5BB0.143B1EB6" Message-ID: <9A9367D1556AD21182C40000F80930AB01B01D38@crchy28b.us.nortel.com> Date: Mon, 10 Jan 2000 15:17:12 -0600 Reply-To: Raja Narayanan Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Raja Narayanan Subject: Re: [MOBILE-IP] WG Opinion on MIER course? 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_01BF5BB0.143B1EB6 Content-Type: text/plain; charset="ISO-8859-1" Hello Charlie, Although the MIER draft does not specify a protocol, it does specify a template that is MANDATED for all future Mobile IP extensions. This is a strong binding to the base Mobile IP protocol and therefore the draft needs to be a 'proposed standard'. The authors of MIER are in favor of the option where we pursue MIER standardization independent of RFC2002bis. Work on MIER has come to a close and we should complete the standardization and move on. The guidelines in the appendix are meant to be just that ...guidelines! They are not intended to be binding on future design [beyond the first 32 bytes which, as mentioned above, MUST be in the MIER format]. --Raja -----Original Message----- From: C. Perkins/D. Reese [mailto:charliep@IPRG.NOKIA.COM] Sent: Saturday, January 08, 2000 1:10 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] WG Opinion on MIER course? I think there are other alternatives. I agree that MIER would fit well in RFC2002-bis. Failing that, I would like to strongly suggest that MIER become an informational draft, not a Proposed Standard. My reasoning for this is simple. MIER does not specify any protocol. Second, the draft that I read had some _guidelines_ in the Appendix. I do not think that those guidelines should be considered binding on the design for whatever generalized extensions would be eventually be specified. For instance, the Challenge draft has a fully specified Generalized Authentication Extension, along with the definition for a particular subtype of that generalized extension. I expect that a revised Route Optimization draft will specify another subtype for that extension, and that the Regional Registration draft will specify yet another subtype. These definitions do conform to the guideline in MIER, the last time I looked. However, I do not expect that an NAI generalized extension, should one ever be defined, would need to conform to the guideline in the MIER appendix. I'll hold off on sending out the revised RFC2002-bis until I hear whether working group members wish to include MIER in that draft. I'd also like to suggest that the NAI draft be allowed to go forward before the MIER questions are resolved. Some people have been waiting a long time for that draft. Regards, Charlie P. Basavaraj Patil wrote: > > > Hello, > > After having had a discussion with our AD (Dave Oran) we have > the following options for moving ahead with the MIER draft > (draft-ietf-mobileip-mier-00.txt): > > 1. Do a WG last call for this draft requesting a Proposed standard > status and have RFC2002-bis reference it for the definition of > extensions. > 2. Roll MIER into RFC2002-bis, which will be going to a WG last call > soon. > > In view of the two drafts that are currently on the IESG plate, the > MN-NAI draft and the Vendor specific extensions draft, the extensions > defined in these drafts would have to be modified to the new mobile IP > > extension format. > > I would like to hear your views on the above two options. > > -Basavaraj ------_=_NextPart_001_01BF5BB0.143B1EB6 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] WG Opinion on MIER course?

Hello Charlie,

Although the MIER draft does not specify a protocol, = it does specify a template that is MANDATED for all future Mobile IP = extensions. This is a strong binding to the base Mobile IP protocol and = therefore the draft needs to be a 'proposed standard'.

The authors of MIER are in favor of the option where = we pursue MIER standardization independent of RFC2002bis. Work on MIER = has come to a close and we should complete the standardization and move = on.

The guidelines in the appendix are meant to be just = that ...guidelines! They are not intended to be binding on future = design [beyond the first 32 bytes which, as mentioned above, MUST be in = the MIER format].

--Raja


-----Original Message-----
From: C. Perkins/D. Reese [mailto:charliep@IPRG.NOKIA.COM]
Sent: Saturday, January 08, 2000 1:10 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] WG Opinion on MIER = course?


I think there are other alternatives.

I agree that MIER would fit well in = RFC2002-bis.  Failing that,
I would like to strongly suggest that MIER become an = informational
draft, not a Proposed Standard.  My reasoning = for this is simple.
MIER does not specify any protocol.

Second, the draft that I read had some _guidelines_ = in the
Appendix.  I do not think that those guidelines = should be
considered binding on the design for whatever = generalized
extensions would be eventually be specified.

For instance, the Challenge draft has a fully = specified
Generalized Authentication Extension, along with = the
definition for a particular subtype of that = generalized
extension.  I expect that a revised Route = Optimization
draft will specify another subtype for that = extension, and
that the Regional Registration draft will specify = yet another
subtype.  These definitions do conform to the = guideline in
MIER, the last time I looked.

However, I do not expect that an NAI generalized = extension,
should one ever be defined, would need to conform to = the
guideline in the MIER appendix.

I'll hold off on sending out the revised RFC2002-bis = until I
hear whether working group members wish to include = MIER
in that draft.

I'd also like to suggest that the NAI draft be = allowed to go
forward before the MIER questions are = resolved.  Some
people have been waiting a long time for that = draft.

Regards,
Charlie P.

Basavaraj Patil wrote:

>
>
> Hello,
>
> After having had a discussion with our AD (Dave = Oran) we have
> the following options for moving ahead with the = MIER draft
> (draft-ietf-mobileip-mier-00.txt):
>
> 1. Do a WG last call for this draft requesting = a Proposed standard
>    status and have RFC2002-bis = reference it for the definition of
>    extensions.
> 2. Roll MIER into RFC2002-bis, which will be = going to a WG last call
>    soon.
>
> In view of the two drafts that are currently on = the IESG plate, the
> MN-NAI draft and the Vendor specific extensions = draft, the extensions
> defined in these drafts would have to be = modified to the new mobile IP
>
> extension format.
>
> I would like to hear your views on the above = two options.
>
> -Basavaraj

------_=_NextPart_001_01BF5BB0.143B1EB6-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 10 18:03: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 SAA14823 for ; Mon, 10 Jan 2000 18:03:10 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6585C950@standards.nortelnetworks.com>; Mon, 10 Jan 2000 17:52:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 116400 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 17:51:35 -0500 Received: from homer.ka9q.ampr.org (24.30.144.246) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F03146D0@standards.nortelnetworks.com>; Mon, 10 Jan 2000 17:41:34 -0500 Received: (from karn@localhost) by homer.ka9q.ampr.org (8.9.3/8.9.3/Debian/GNU) id OAA11318; Mon, 10 Jan 2000 14:52:07 -0800 References: <200001070846.AAA18384@servo.qualcomm.com> <20000107221014.1457C5701C@king.research.bell-labs.com> <200001080113.RAA20516@homer.ka9q.ampr.org> <387A0CDB.F34CC7B0@dnrc.bell-labs.com> Message-ID: <200001102252.OAA11318@homer.ka9q.ampr.org> Date: Mon, 10 Jan 2000 14:52:07 -0800 Reply-To: karn@qualcomm.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Phil Karn Subject: Re: [MOBILE-IP] Why Mobile IP? [was: AAA functionality] X-To: ramjee@dnrc.bell-labs.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <387A0CDB.F34CC7B0@dnrc.bell-labs.com> (message from Ramachandran Ramjee on Mon, 10 Jan 2000 16:46:19 +0000) >P.S. I felt the need to debate one of your points: you say >CDMA has a "soft-handoff" capability that can only be implemented >at the physical (link?) layer. Isn't this another violation of the >end-to-end concept in itself? Why can't this "soft-handoff" service >be achieved at the IP-layer (I can easily engineer a bunch of >wavelan base stations to multicast IP packets during handoff for ONLY >those users/services that need this feature)? CDMA forward link soft handoff works by combining the signals from multiple cell sites down at the symbol (encoded bit) level before they are even demodulated and Viterbi decoded. This often succeeds in producing a good frame when *none* of the individual signals could be decoded by themselves. Yes, you could implement a scheme in Mobile IP that would multicast the same packets across multiple cells. I suggested that very feature years ago when the group was new. But it produces a good packet only when at least one of the individual packets gets through. That's much better than nothing, but it cannot outperform true soft handoff. For best performance, you need to do the handoff combining on a much smaller granularity (the symbol level) than is possible anywhere above the IP layer (where the smallest unit is an IP datagram). CDMA soft handoff is an example of an optional performance enhancing feature implemented at a lower layer, so it is in harmony with the end-to-end model. Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 10 21:45: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 VAA16679 for ; Mon, 10 Jan 2000 21:45:45 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.78C95530@standards.nortelnetworks.com>; Mon, 10 Jan 2000 21:34:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 116723 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 21:34:05 -0500 Received: from smtpgw2.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6B032DE0@standards.nortelnetworks.com>; Mon, 10 Jan 2000 21:34:04 -0500 Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw2.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id UAA11625; Mon, 10 Jan 2000 20:44:39 -0600 (CST) Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jan 2000 20:44: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: Date: Mon, 10 Jan 2000 20:44:38 -0600 Reply-To: "Lipford, Mark" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lipford, Mark" Subject: Re: [MOBILE-IP] Why Mobile IP? [was: AAA functionality] X-To: karn@ka9q.ampr.org To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Phil, CDMA Carriers are not deploying data for a very simple reason. The business case does not prove in under current technologies and with what users are willing to pay. As you yourself have stated, data prices should not be billed at a premium, but instead at a discount (not your words exactly, but something like that). How can we charge less for a 64kbps rate that is using 6 to 8 times the RF spectrum (during active state) then a voice call, bill less then for a single voice call, and expect to stay in business? The N. American carriers implemented QNC for a very simple reason. It is a "packet look alike" (mobile originated only), cost basically nothing extra to implement, and is a solution that carriers believe will support most of their customers until we can get a good packet solution out there. Regarding our deployment of circuit based services, again, the decision was based on a through business case decision, not just technology. Regards -----Original Message----- From: Phil Karn [mailto:karn@ka9q.ampr.org] Sent: Monday, January 10, 2000 2:17 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Why Mobile IP? [was: AAA functionality] >However, I don't think that wireless data service deployment is being >held back by the complexity of Mobile IP - in fact, Mobile IP is an >extremely simple protocol (If a client can have TCP, which it must, >everything else Nothing is ever "simple" when you involve formal telephone standards bodies, such as the TIA. The MIP protocol itself may be simple, but the debates over mobility in the TIA clearly delayed deployment of a packet data service. To be fair, MIP wasn't the only culprit in the delay. Just as significant (if not more so) was the carriers' insistence on making asynch dialup modem emulation and fax support top priority, and giving low priority to direct IP packet access. This continued even after we succeeded in persuading the TIA to base the asynch data/fax service, making packet data a subset of what's needed to support async data/fax. What I've always found truly astounding is when a carrier concedes that a certain feature is best done end-to-end, but that it must still be a mandatory network feature regardless of cost or delay because the "average user" won't want to install the necessary software to support the feature on his own computer. When it comes to adding new features needed by their customers, even Microsoft looks fast and responsive in comparison to most telephone industry vendors. QNC is a good example; it's a kludge that exists solely to bypass the foot dragging of certain base station vendors in implementing CDMA IP packet data service, even though they had already done async data & fax. Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 10 22:46: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 WAA18705 for ; Mon, 10 Jan 2000 22:46:02 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E04F47C0@standards.nortelnetworks.com>; Mon, 10 Jan 2000 22:34:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 116809 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 22:32:55 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3D6DB2E0@standards.nortelnetworks.com>; Mon, 10 Jan 2000 22:22:54 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA25225; Mon, 10 Jan 2000 20:33:21 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id TAA20374; Mon, 10 Jan 2000 19:33:19 -0800 (PST) Received: from eastapp (eastapp.East.Sun.COM [129.148.163.25]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA06900; Mon, 10 Jan 2000 19:33:20 -0800 (PST) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Sun(TM) Web Access 1.0 Message-ID: <525509389.947561597186.JavaMail.aey@jurassic.Eng.Sun.COM> Date: Mon, 10 Jan 2000 22:33:17 -0500 Reply-To: Alper.Yegin@ENG.SUN.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Alper Yegin Subject: Re: [MOBILE-IP] RFC2002bis X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Charlie, and wg members, >> > [3] >> > >> > 4.6. ARP, Proxy ARP, and Gratuitous ARP >> > ... >> > Finally, while the >> > mobile node is away from home, it MUST NOT reply to ARP Requests >> > in which the target IP address is its own home address, unless the >> > ARP Request is sent by a foreign agent with which the mobile node >> > is attempting to register or a foreign agent with which the mobile >> > node has an unexpired registration. >> > >> > But we know that the FA MUST NOT send ARP. So, this is contradicting. >> >> Which part should be changed? > >I changed the word "sent" to "unicast". This allows the foreign agent >to send ARPs as long as it is not broadcast. I think this means even >not using any layer-2 multicast or broadcast address. > >Help on this point will be appreciated. I don't have time just now >to go through all the previous archived discussion on this point. We are ARPing the MN, because we don't know it's MAC address. I cannot see how we are able to find out the MAC address without link-layer broadcast or multicast. > >From some previous discussion, I have the following unresolved point: > >> Q: new FA forwarding text; sometimes two MNs on the same FA sometimes get >> traffic forwarded directly rather than via HA. The host specific route to MN shouldn't be available to any packets other than the ones arriving to FA on the tunnel configured for this MN. This requires forwarding based on not only destination address but also incoming interface. Without this, there's the problem of getting HA out of the loop, and in the case of MN moving another site, host specific route will not go away until previous FA expires the registration, and until then any communication going through this FA will be interrupted. How about adding some text, requiring above prevention. >> Also MNs can introduce >> denial of service if they make a mistake in their registration >> messages - sometimes re-registrations can be redirected at a MN! > >Do I need to do anything here? > > >Regards, >Charlie P. > Thanks, Alper Yegin Internet Engineering Sun Microsystems, Inc. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 10 23:20: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 XAA18826 for ; Mon, 10 Jan 2000 23:20:16 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A3BC96F0@standards.nortelnetworks.com>; Mon, 10 Jan 2000 23:08:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 116890 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 23:06:48 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5F382760@standards.nortelnetworks.com>; Mon, 10 Jan 2000 23:06:48 -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 UAA21902; Mon, 10 Jan 2000 20:17:22 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id UAA02167; Mon, 10 Jan 2000 20:17:21 -0800 X-Virus-Scanned: Mon, 10 Jan 2000 20:17:21 -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) xma002083; Mon, 10 Jan 00 20:17:17 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <9A9367D1556AD21182C40000F80930AB01B01D38@crchy28b.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <387AAECD.FC99B313@iprg.nokia.com> Date: Mon, 10 Jan 2000 20:17:17 -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 Opinion on MIER course? X-To: Raja Narayanan To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Raja, > Although the MIER draft does not specify a protocol, it does specify a > template that is MANDATED for all future Mobile IP extensions. I do not support the mandatory conformance of all future Mobile IP extensions to the format illustrated in MIER. There may other requirements that we don't know about yet. Furthermore, there might be extensions that don't need subtypes. > The authors of MIER are in favor of the option where we pursue MIER > standardization independent of RFC2002bis. Work on MIER has come to a > close and we should complete the standardization and move on. My comments should be counted as Last Call comments, requesting additional clarification and possibly respecification of MIER. I have not talked to _anyone_, outside the authors of the MIER draft, who supports the mandatory conformance of all future extensions to the MIER format, and I have talked to more than ne person who agrees with me that such conformance should not be mandated. I reiterate my request that MIER be considered purely informational, and not binding on future extension specifications. > The guidelines in the appendix are meant to be just that > ...guidelines! They are not intended to be binding on future design > [beyond the first 32 bytes which, as mentioned above, MUST be in the > MIER format]. Can you say a few words about why the appendices are there? I think the draft does not benefit from their presence, and that it would be very easy for the guidelines to be miscontrued in future Mobile IP discussions. It would be better for them to removed, in my opinion, and I have thought about it a lot of times. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 00:46: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 AAA19793 for ; Tue, 11 Jan 2000 00:46:31 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AEE3B2F0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 0:34:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 116973 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 00:33:31 -0500 Received: from sigma.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7C9DD370@standards.nortelnetworks.com>; Tue, 11 Jan 2000 0:33:31 -0500 Received: (from kleung@localhost) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA15761; Mon, 10 Jan 2000 21:44:07 -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: <200001110544.VAA15761@sigma.cisco.com> Date: Mon, 10 Jan 2000 21:44:06 -0800 Reply-To: "Kent K. Leung" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Kent K. Leung" Subject: Re: [MOBILE-IP] RFC2002bis X-To: Alper.Yegin@ENG.SUN.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <525509389.947561597186.JavaMail.aey@jurassic.Eng.Sun.COM> from "Alper Yegin" at Jan 10, 2000 10:33:17 PM Content-Transfer-Encoding: 7bit > > We are ARPing the MN, because we don't know it's MAC address. I cannot see > how we are able to find out the MAC address without link-layer broadcast or > multicast. > Why does an FA need to ARP the MN? The FA knows the MN's MAC address when the MN registers and should store this info in future communications. Am I not seeing a scenario that you're describing that requires an FA to ARP? > >> Q: new FA forwarding text; sometimes two MNs on the same FA sometimes get > >> traffic forwarded directly rather than via HA. > > The host specific route to MN shouldn't be available to any packets > other than the ones arriving to FA on the tunnel configured for this MN. > This requires forwarding based on not only destination address but also > incoming interface. Without this, there's the problem of getting HA out > of the loop, and in the case of MN moving another site, host specific > route will not go away until previous FA expires the registration, > and until then any communication going through this FA will be > interrupted. > > How about adding some text, requiring above prevention. > Isn't this route optimization? :) My thought is that bad to have packets forwarded directly instead of always through HA in the case both MNs are attached to the same FA? Should this be switching implementation dependant? I guess is the behaviour a MUST or SHOULD? -- Kent -- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 01:37: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 BAA22208 for ; Tue, 11 Jan 2000 01:37:34 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D211E0B0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 1:26:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 117045 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 01:24:22 -0500 Received: from sunny.recin.com (206.171.92.254) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.314410A0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 1:14:22 -0500 Received: from [206.171.92.254] ([203.197.189.209]) by sunny.recin.com (Netscape Mail Server v2.0) with SMTP id AAB2654 for ; Mon, 10 Jan 2000 22:25:48 -0700 X-mailserver: Sent using the PostMaster (v3.1.5) X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: Date: Tue, 11 Jan 2000 11:56:01 +0500 Reply-To: kevin@sz.huawei.com.cn Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Kevin Cheng Organization: Huawei Technology Subject: [MOBILE-IP] Performance figures with Mobile IP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Mobilers A quick and a small question from the novices. Do we have any figures with regards to the performance of routers when Mobile IP support is enabled ? The figures could be even in terms of percentage. For example, if a normal router has a throughput of X without Mobile IP support, what is its performance after enabling Mobile IP support ? Eagerly awaiting a quick response to quench our thirst for these figures ! Thanx and Regards Kevin -------------------------------------------------------------- HUAWEI (BANGALORE) BUSINESS OPERATION, BANGALORE, INDIA From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 06: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 GAA03934 for ; Tue, 11 Jan 2000 06: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.C5F48360@standards.nortelnetworks.com>; Tue, 11 Jan 2000 6:40:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 117417 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 06:38:39 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.18CD3B60@standards.nortelnetworks.com>; Tue, 11 Jan 2000 6:28:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03590; Tue, 11 Jan 2000 06:39:17 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200001111139.GAA03590@ietf.org> Date: Tue, 11 Jan 2000 06:39:12 -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-vendor-ext-07.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 Vendor/Organization-Specific Extensions Author(s) : G. Dommety, K. Leung Filename : draft-ietf-mobileip-vendor-ext-07.txt Pages : 4 Date : 10-Jan-00 This document proposes two new extensions to Mobile IP [1]. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-vendor-ext-07.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-vendor-ext-07.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-vendor-ext-07.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: <20000110111155.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-vendor-ext-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-vendor-ext-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000110111155.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 06:52: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 GAA03940 for ; Tue, 11 Jan 2000 06:52:51 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C61AA900@standards.nortelnetworks.com>; Tue, 11 Jan 2000 6:40:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 117420 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 06:40:02 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4A997E10@standards.nortelnetworks.com>; Tue, 11 Jan 2000 6:30:02 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03802; Tue, 11 Jan 2000 06:40:41 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200001111140.GAA03802@ietf.org> Date: Tue, 11 Jan 2000 06:40:41 -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-aaa-reqs-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 : Mobile IP Authentication, Authorization, and Accounting Requirements Author(s) : S. Glass, T. Hiller, S. Jacobs, C. Perkins Filename : draft-ietf-mobileip-aaa-reqs-01.txt Pages : 24 Date : 10-Jan-00 The Mobile IP and AAA working groups are currently looking at defining the requirements for Authentication, Authorization, and Accounting. This document contains the requirements which would have to be supported by a AAA service to aid in providing Mobile IP services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-reqs-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-aaa-reqs-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-aaa-reqs-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: <20000110123354.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-aaa-reqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-aaa-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000110123354.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 07:16: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 HAA04686 for ; Tue, 11 Jan 2000 07:16:31 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.25EF1A20@standards.nortelnetworks.com>; Tue, 11 Jan 2000 7:04:48 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 117547 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 07:03:27 -0500 Received: from smtp1.cluster.oleane.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F5815600@standards.nortelnetworks.com>; Tue, 11 Jan 2000 7:03:27 -0500 Received: from oleane (dyn-1-1-205.Vin.dialup.oleane.fr [195.25.4.205]) by smtp1.cluster.oleane.net with SMTP id NAA45601; Tue, 11 Jan 2000 13:13:54 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01BF5C35.58C52380" 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: <001201bf5c2c$fa913540$0401a8c0@oleane.com> Date: Tue, 11 Jan 2000 13:11:18 +0100 Reply-To: Peter Lewis Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Peter Lewis Subject: [MOBILE-IP] Cellular Internet Call for Paper To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_000F_01BF5C35.58C52380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cellular Internet: The Micro-Mobility Approach The micro-mobility concept is the most recent and promising approach = proposed to add mobility to the Internet and packet data services to = third generation cellular systems. =20 A CFP is available at:=20 http://www.upperside.fr/baipcn.htm ------=_NextPart_000_000F_01BF5C35.58C52380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_000F_01BF5C35.58C52380-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 10:08: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 KAA12182 for ; Tue, 11 Jan 2000 10:08:12 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.19FE8940@standards.nortelnetworks.com>; Tue, 11 Jan 2000 9:56:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 117873 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 09:54:44 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E2FD92B0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 9:54:44 -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 HAA00291; Tue, 11 Jan 2000 07:05:18 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id HAA01427; Tue, 11 Jan 2000 07:05:18 -0800 X-Virus-Scanned: Tue, 11 Jan 2000 07:05:18 -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) xma001171; Tue, 11 Jan 00 07:05:14 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <525509389.947561597186.JavaMail.aey@jurassic.Eng.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <387B46AA.407C8755@iprg.nokia.com> Date: Tue, 11 Jan 2000 07:05:14 -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] RFC2002bis X-To: Alper.Yegin@eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Alper, > >I changed the word "sent" to "unicast". This allows the foreign agent > >to send ARPs as long as it is not broadcast. I think this means even > >not using any layer-2 multicast or broadcast address. > > We are ARPing the MN, because we don't know it's MAC address. I cannot see > how we are able to find out the MAC address without link-layer broadcast or > multicast. Agreed. It might be useful for a FA to do a unicast ARP in case its current ARP-table entry were timing out. Or, maybe not. Should I delete the sentences? > >> Q: new FA forwarding text; sometimes two MNs on the same FA sometimes get > >> traffic forwarded directly rather than via HA. > > The host specific route to MN shouldn't be available to any packets > other than the ones arriving to FA on the tunnel configured for this MN. > This requires forwarding based on not only destination address but also > incoming interface. Without this, there's the problem of getting HA out > of the loop, and in the case of MN moving another site, host specific > route will not go away until previous FA expires the registration, > and until then any communication going through this FA will be > interrupted. I'll try to find a place to put this. Do you have a suggestion? Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 11:18: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 LAA14064 for ; Tue, 11 Jan 2000 11:18:57 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E9B72D50@standards.nortelnetworks.com>; Tue, 11 Jan 2000 11:06:30 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 118009 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 11:04:54 -0500 Received: from web1706.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4A777750@standards.nortelnetworks.com>; Tue, 11 Jan 2000 10:54:53 -0500 Received: (qmail 20163 invoked by uid 60001); 11 Jan 2000 15:58:10 -0000 Received: from [207.136.55.235] by web1706.mail.yahoo.com; Tue, 11 Jan 2000 07:58:10 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20000111155810.20162.qmail@web1706.mail.yahoo.com> Date: Tue, 11 Jan 2000 07:58:10 -0800 Reply-To: Raja Narayanan Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Raja Narayanan Subject: Re: [MOBILE-IP] WG Opinion on MIER course? X-To: raja@nortelnetworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, Charlie's opinions prefixed CharlieP> My response prefixed RN> CharlieP> I do not support the mandatory conformance of all future Mobile IP extensions to the format illustrated in MIER. There may other requirements that we don't know about yet. RN>We do not find technical rationale in the argument above. A simple way to ensure that future requirements are taken care of is to have reserved bits which you did not support. We have asked this several times before ...can you illustrate any future requirements that MIER format would preclude ? How much more simple can an inclusion of subtypes get. CharlieP> Furthermore, there might be extensions that don't need subtypes. RN>well!... Perhaps this was the thought when the extensions were originally designed... There might well be extensions that just need no subtypes _for now_...but MIER gives you the flexibility to add subtypes. CharlieP> I have not talked to _anyone_, outside the authors of the MIER draft, who supports the mandatory conformance of all future extensions to the MIER format, and I have talked to more than ne person who agrees with me that such conformance should not be mandated. RN> The WG mailing is established for the _very_ purpose of articulating positions. We need to encourage all who have an opinion to share with the mailing group _directly_. __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 11:25: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 LAA14289 for ; Tue, 11 Jan 2000 11:25:45 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.79F0B760@standards.nortelnetworks.com>; Tue, 11 Jan 2000 11:10:32 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 118069 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 11:08:38 -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.3617F120@standards.nortelnetworks.com>; Tue, 11 Jan 2000 11:08:38 -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 RAA21118; Tue, 11 Jan 2000 17:19:05 +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, 11 Jan 2000 16:19:05 0000 (GMT) Received: by esealnt400 with Internet Mail Service (5.5.2448.0) id ; Tue, 11 Jan 2000 17:18:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5F05C89FB2F8D211B6430008C791912701D2EB79@esealnt190> Date: Tue, 11 Jan 2000 17:18:56 +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] RFC2002bis X-To: Alper Yegin , "charliep@IPRG.NOKIA.COM" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi > > >> Q: new FA forwarding text; sometimes two MNs on the > same FA sometimes get > > >> traffic forwarded directly rather than via HA. > > > > The host specific route to MN shouldn't be available to any packets > > other than the ones arriving to FA on the tunnel > configured for this MN. > > This requires forwarding based on not only destination > address but also > > incoming interface. Without this, there's the problem of > getting HA out > > of the loop, and in the case of MN moving another site, > host specific > > route will not go away until previous FA expires the registration, > > and until then any communication going through this FA will be > > interrupted. > > I'll try to find a place to put this. Do you have a suggestion? Could you please clarify why it is not possible to optimise the forwarding when two communicating MNs are connected to the same FA (or GFA)? If you use smooth handoffs (or fast handoffs in the case of HFAs) then if the MN moves to another site there should be no problem. Also, what is the problem of getting the HA out of the loop? Regards, Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 11:33: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 LAA14634 for ; Tue, 11 Jan 2000 11:33:35 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2F912550@standards.nortelnetworks.com>; Tue, 11 Jan 2000 11:15:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 118128 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 11:14:15 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FF0DDD60@standards.nortelnetworks.com>; Tue, 11 Jan 2000 11:14:15 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 11 Jan 2000 10:24:39 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Tue, 11 Jan 2000 11:24:06 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 11 Jan 2000 10:24:05 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5C50.471F7A0C" Message-ID: <9A9367D1556AD21182C40000F80930AB010BC19B@crchy28b.us.nortel.com> Date: Tue, 11 Jan 2000 10:23:55 -0600 Reply-To: Mohamed Khalil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohamed Khalil Subject: Re: [MOBILE-IP] RFC2002bis 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_01BF5C50.471F7A0C Content-Type: text/plain > -----Original Message----- > From: Charles E. Perkins [SMTP:charliep@IPRG.NOKIA.COM] > Sent: Tuesday, January 11, 2000 9:05 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] RFC2002bis > > Hello Alper, > > > >I changed the word "sent" to "unicast". This allows the foreign agent > > >to send ARPs as long as it is not broadcast. I think this means even > > >not using any layer-2 multicast or broadcast address. > > > > > We are ARPing the MN, because we don't know it's MAC address. I cannot > see > > how we are able to find out the MAC address without link-layer broadcast > or > > multicast. > > Agreed. It might be useful for a FA to do a unicast ARP in case its > current ARP-table entry were timing out. Or, maybe not. Should I > delete the sentences? [MK>] Sending a unicast ARP request contradicts with the original definition of ARP request message where the destination address should be a broadcast address (RFC826). Sending a unicast ARP request will require the implementers to do some changes for the ARP module which might not be desirable. > > >> Q: new FA forwarding text; sometimes two MNs on the same FA sometimes > get > > >> traffic forwarded directly rather than via HA. > > > > The host specific route to MN shouldn't be available to any packets > > other than the ones arriving to FA on the tunnel configured for this MN. > > This requires forwarding based on not only destination address but also > > incoming interface. Without this, there's the problem of getting HA out > > of the loop, and in the case of MN moving another site, host specific > > route will not go away until previous FA expires the registration, > > and until then any communication going through this FA will be > > interrupted. > > I'll try to find a place to put this. Do you have a suggestion? > > > Regards, > Charlie P. ------_=_NextPart_001_01BF5C50.471F7A0C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] RFC2002bis

    -----Original Message-----
    From:   Charles E. Perkins = [SMTP:charliep@IPRG.NOKIA.COM]
    Sent:   Tuesday, January 11, 2000 9:05 AM
    To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: [MOBILE-IP] RFC2002bis

    Hello Alper,

    > >I changed the word = "sent" to "unicast".  This allows the foreign = agent
    > >to send ARPs as long as it = is not broadcast.  I think this means even
    > >not using any layer-2 = multicast or broadcast address.

    >
    > We are ARPing the MN, because we = don't know it's MAC address. I cannot see
    > how we are able to find out the = MAC address without link-layer broadcast or
    > multicast.

    Agreed.  It might be useful for a = FA to do a unicast ARP in case its
    current ARP-table entry were timing = out.  Or, maybe not.  Should I
    delete the sentences?
    [MK>]  Sending a unicast ARP = request contradicts with the original definition of ARP request message = where the destination address should be a broadcast address (RFC826). = Sending a unicast ARP request will require the implementers to do some = changes for the ARP module which might not be desirable.

    > >> Q: new FA forwarding = text; sometimes two MNs on the same FA sometimes get
    > >>    = traffic forwarded directly rather than via HA.
    >
    > The host specific route to MN = shouldn't be available to any packets
    > other than the ones arriving to = FA on the tunnel configured for this MN.
    > This requires forwarding based = on not only destination address but also
    > incoming interface. Without = this, there's the problem of getting HA out
    > of the loop, and in the case of = MN moving another site, host specific
    > route will not go away until = previous FA expires the registration,
    > and until then any communication = going through this FA will be
    > interrupted.

    I'll try to find a place to put = this.  Do you have a suggestion?


    Regards,
    Charlie P.

------_=_NextPart_001_01BF5C50.471F7A0C-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 12: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 MAA16401 for ; Tue, 11 Jan 2000 12: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.DBB3ADE0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 12:24:51 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 118310 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 12:23:53 -0500 Received: from ido.idolab.com (204.201.22.8) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B947BA80@standards.nortelnetworks.com>; Tue, 11 Jan 2000 12:23:53 -0500 Received: by idolab.com with Internet Mail Service (5.5.2448.0) id ; Tue, 11 Jan 2000 09:37:29 -0800 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Tue, 11 Jan 2000 09:37:25 -0800 Reply-To: Jeffery Brunson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jeffery Brunson Subject: Re: [MOBILE-IP] Why Mobile IP? [was: AAA functionality] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Just FYI. IDO and DDI jointly launched commercial IS-95B 64k packet service Jan 7 in Japan. Jeff Brunson IDO > -----Original Message----- > From: Phil Karn [mailto:karn@ka9q.ampr.org] > Sent: Monday, January 10, 2000 2:17 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Why Mobile IP? [was: AAA > functionality] > > >However, I don't think that wireless data service > deployment is being > >held back by the complexity of Mobile IP - in fact, Mobile > IP is an > >extremely simple protocol (If a client can have TCP, which > it must, > >everything else > > Nothing is ever "simple" when you involve formal telephone > standards > bodies, such as the TIA. The MIP protocol itself may be > simple, but > the debates over mobility in the TIA clearly delayed > deployment of a > packet data service. > > To be fair, MIP wasn't the only culprit in the delay. Just > as > significant (if not more so) was the carriers' insistence on > making > asynch dialup modem emulation and fax support top priority, > and giving > low priority to direct IP packet access. This continued even > after we > succeeded in persuading the TIA to base the asynch data/fax > service, > making packet data a subset of what's needed to support > async > data/fax. > > What I've always found truly astounding is when a carrier > concedes > that a certain feature is best done end-to-end, but that it > must still > be a mandatory network feature regardless of cost or delay > because the > "average user" won't want to install the necessary software > to support > the feature on his own computer. > > When it comes to adding new features needed by their > customers, even > Microsoft looks fast and responsive in comparison to most > telephone > industry vendors. QNC is a good example; it's a kludge that > exists > solely to bypass the foot dragging of certain base station > vendors in > implementing CDMA IP packet data service, even though they > had already > done async data & fax. > > Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 16:01: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 QAA21121 for ; Tue, 11 Jan 2000 16:01:09 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.72EB7780@standards.nortelnetworks.com>; Tue, 11 Jan 2000 15:49:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 118714 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 15:48:09 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.41CADE20@standards.nortelnetworks.com>; Tue, 11 Jan 2000 15:48:08 -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 MAA05455; Tue, 11 Jan 2000 12:58:05 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id MAA26494; Tue, 11 Jan 2000 12:58:05 -0800 X-Virus-Scanned: Tue, 11 Jan 2000 12:58:05 -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) xma026410; Tue, 11 Jan 00 12:58:01 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <5F05C89FB2F8D211B6430008C791912701D2EB79@esealnt190> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <387B9959.798D067A@iprg.nokia.com> Date: Tue, 11 Jan 2000 12:58:01 -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] RFC2002bis X-To: "Karim El-Malki (ERA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Karim, Suppose two nodes are in the same area, so that they could do as you suggest. The problem comes when one of them moves, there is no way for all the other nodes to find out that their ARP caches are now stale. Since the ARP request was (presumably) broadcast, all the other nodes that were in communication with the node in question would have acquired a new (and eventually incorrect) layer-2 address for the mobile node. Regards, Charlie P. "Karim El-Malki (ERA)" wrote: > > Hi > > > > >> Q: new FA forwarding text; sometimes two MNs on the > > same FA sometimes get > > > >> traffic forwarded directly rather than via HA. > > > > > > The host specific route to MN shouldn't be available to any packets > > > other than the ones arriving to FA on the tunnel > > configured for this MN. > > > This requires forwarding based on not only destination > > address but also > > > incoming interface. Without this, there's the problem of > > getting HA out > > > of the loop, and in the case of MN moving another site, > > host specific > > > route will not go away until previous FA expires the registration, > > > and until then any communication going through this FA will be > > > interrupted. > > > > I'll try to find a place to put this. Do you have a suggestion? > > Could you please clarify why it is not possible to optimise the forwarding > when two communicating MNs are connected to the same FA (or GFA)? If you > use smooth handoffs (or fast handoffs in the case of HFAs) then if the MN > moves to another site there should be no problem. Also, what is the > problem of getting the HA out of the loop? > > Regards, > Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 22:03: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 WAA25536 for ; Tue, 11 Jan 2000 22:03:35 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0A222DB0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 21:51:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 119140 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 21:49:57 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CD72BF60@standards.nortelnetworks.com>; Tue, 11 Jan 2000 21:49:57 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 11 Jan 2000 20:58:54 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Tue, 11 Jan 2000 21:58:53 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 11 Jan 2000 20:58:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5CA8.F4DFD878" Message-ID: Date: Tue, 11 Jan 2000 20:58:48 -0600 Reply-To: Basavaraj Patil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: [MOBILE-IP] Consensus for the extensions template defined in MIER 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_01BF5CA8.F4DFD878 Content-Type: text/plain; charset="ISO-8859-1" The MIER draft (draft-ietf-mobileip-mier-00.txt) states that all new extensions defined for Mobile IP in the future MUST follow the template that is specified in the document. The difference from the existing definition specified in RFC2002 is that adds a subtype field and the length field is increased two octets. If you have concerns or disagree with this proposal, please express it on the mailing list by the end of this week. -Basavaraj Patil ------_=_NextPart_001_01BF5CA8.F4DFD878 Content-Type: text/html; charset="ISO-8859-1" Consensus for the extensions template defined in MIER

The MIER draft (draft-ietf-mobileip-mier-00.txt) states that all new
extensions defined for Mobile IP in the future MUST follow the
template that is specified in the document.
The difference from the existing definition specified in RFC2002 is
that adds a subtype field and the length field is increased two
octets.

If you have concerns or disagree with this proposal, please express it
on the mailing list by the end of this week.

-Basavaraj Patil

------_=_NextPart_001_01BF5CA8.F4DFD878-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 22:23: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 WAA25633 for ; Tue, 11 Jan 2000 22:23:39 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DA9ACA90@standards.nortelnetworks.com>; Tue, 11 Jan 2000 22:11:48 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 119180 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 22:09:51 -0500 Received: from taurus.cs.albany.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2F209650@standards.nortelnetworks.com>; Tue, 11 Jan 2000 21:59:51 -0500 Received: from euler.cs.albany.edu (euler.cs.albany.edu [169.226.2.43]) by taurus.cs.albany.edu (8.9.3+Sun/8.9.1) with ESMTP id WAA28843 for ; Tue, 11 Jan 2000 22:10:24 -0500 (EST) Received: (from ravi@localhost) by euler.cs.albany.edu (SMI-8.6/CLI2) id WAA03277 for mobile-ip@standards.nortelnetworks.com; Tue, 11 Jan 2000 22:11:12 -0500 Message-ID: <200001120311.WAA03277@euler.cs.albany.edu> Date: Tue, 11 Jan 2000 22:11:12 -0500 Reply-To: "S.S.Ravi" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "S.S.Ravi" Subject: [MOBILE-IP] DIAL M for Mobility -- Preliminary Call for Papers To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM (Please accept our apologies if you receive multiple copies) PRELIMINARY CALL FOR PAPERS 4th International Workshop on Discrete Algorithms and Methods for Mobile Computing & Communications (DIALM for Mobility) August 11, 2000 Boston, Massachusetts, USA In conjunction with ACM MobiCom 2000 Submission Deadline: April 25, 2000 Program Chair: Errol L. Lloyd Department of Computer and Information Sciences University of Delaware Newark, DE, USA Email: elloyd@udel.edu Workshop URL : http://www.cis.udel.edu/~elloyd/dialm.d/home.html SCOPE: Mobile computing and communications devices such as portable phones, laptops and palmtops will have an enormous impact on our lifestyle over the next several decades. The introduction of mobility raises a number of new research issues. This workshop is devoted to discrete algorithms and methods in the context of mobile and wireless computing and communications. The workshop is intended to serve as a forum for open discussions and lively debate, and to foster cooperation among practitioners and theoreticians. The workshop encourages submission of papers based on work-in-progress. Proposals for panels designed to generate lively discussions are also invited. Contributions are solicited in all areas related to mobile computing and communications where discrete algorithms and methods are utilized, including, but not limited to: distributed algorithms frequency allocation scheduling location tracking site allocation multihop packet radio networks wireless networks synchronization cryptography and security error correcting codes handover (handoff) telecommunications modeling optimization routing satellite communication SUBMISSION GUIDELINES: All paper submissions and panel proposals will be handled electronically. Authors should e-mail a PostScript version of their full paper to elloyd@udel.edu. The font size should be at least 10 pt. The paper should not be longer than 10 single spaced pages using a standard 10point font. Panel proposals may be submitted in ASCII or PostScript format. A panel proposal should include panel topic, sample questions the panel would address, and proposed panel members and moderator. Since deadlines overlap, dual submission of papers to MobiCom and DIALM is encouraged. Any paper accepted for MobiCom will automatically be removed from consideration for DIALM. To ensure that the PostScript versions of the papers can be printed, use PostScript version 2 or later. Also ensure that the paper fits on "US Letter" size paper (8.5X11 inches). Reference only standard Adobe printer fonts (i.e., Courier, Times, Roman, or Helvetica); other fonts may be used but must be included in the PostScript file. Authors will receive a short email ack of their submission within two days of submission. If this is not received, the authors should contact the Program Chair immediately. Authors should separately email the title, authors, mailing address, and abstract to elloyd@udel.edu. IMPORTANT DATES: Submissions due : April 25, 2000 Acceptance notification: May 15, 2000 Final paper due : June 1, 2000 Workshop : August 11, 2000 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 23:05: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 XAA26845 for ; Tue, 11 Jan 2000 23:05:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BE529740@standards.nortelnetworks.com>; Tue, 11 Jan 2000 22:53:57 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 119236 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 22:52:12 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7F5FEFB0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 22:52:12 -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 UAA02858; Tue, 11 Jan 2000 20:02:38 -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 UAA14259; Tue, 11 Jan 2000 20:02:38 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id UAA21176; Tue, 11 Jan 2000 20:02: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: <200001120402.UAA21176@nasnfs.eng.sun.com> Date: Tue, 11 Jan 2000 21:58:57 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] Consensus for the extensions template defined in MIER X-To: Basavaraj Patil To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I do have some serious concerns about such a statement. It isn't clear that we are really running out of extensions at the moment, and although I agree that we will someday, requiring this for ALL future extensions MAY be self-defeating. There are many extensions that are unique in nature, and are not necessarily subject to being "grouped" in a MIER approach. PatC > >The MIER draft (draft-ietf-mobileip-mier-00.txt) states that all new >extensions defined for Mobile IP in the future MUST follow the >template that is specified in the document. >The difference from the existing definition specified in RFC2002 is >that adds a subtype field and the length field is increased two >octets. > >If you have concerns or disagree with this proposal, please express it >on the mailing list by the end of this week. > >-Basavaraj Patil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 23:36: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 XAA27399 for ; Tue, 11 Jan 2000 23:36:42 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1F26A8A0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 23:25:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 119285 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 23:24:11 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F76E0C90@standards.nortelnetworks.com>; Tue, 11 Jan 2000 23:24:11 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA04654; Tue, 11 Jan 2000 21:34:45 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id UAA15837; Tue, 11 Jan 2000 20:34:46 -0800 (PST) Received: from eastapp (eastapp.East.Sun.COM [129.148.163.25]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA19175; Tue, 11 Jan 2000 20:34:44 -0800 (PST) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Sun(TM) Web Access 1.0 Message-ID: <525780217.947651684402.JavaMail.aey@jurassic.Eng.Sun.COM> Date: Tue, 11 Jan 2000 23:34:44 -0500 Reply-To: Alper.Yegin@ENG.SUN.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Alper Yegin Subject: Re: [MOBILE-IP] RFC2002bis X-To: "Kent K. Leung" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit > >Why does an FA need to ARP the MN? The FA knows the MN's MAC address >when the MN registers and should store this info in future communications. >Am I not seeing a scenario that you're describing that requires an FA >to ARP? Right. Actually I'm not for ARPing the MN. All I was saying was ARPing would not work with unicast. I agree the right way to extract the MAC address would be to get it from the packets recevied from the MN. > >> >> Q: new FA forwarding text; sometimes two MNs on the same FA sometimes get >> >> traffic forwarded directly rather than via HA. >> >> The host specific route to MN shouldn't be available to any packets >> other than the ones arriving to FA on the tunnel configured for this MN. >> This requires forwarding based on not only destination address but also >> incoming interface. Without this, there's the problem of getting HA out >> of the loop, and in the case of MN moving another site, host specific >> route will not go away until previous FA expires the registration, >> and until then any communication going through this FA will be >> interrupted. >> >> How about adding some text, requiring above prevention. >> > >Isn't this route optimization? :) Well it's. It's free route optimization with side effects. Without somebody doing a clean up after MN moves to some other foreign link, this is going to cause interruption to some of the communication. > My thought is that bad to have >packets forwarded directly instead of always through HA in the case >both MNs are attached to the same FA? Should this be switching >implementation dependant? I guess is the behaviour a MUST or SHOULD? > >-- Kent -- > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 12 00:13: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 AAA27668 for ; Wed, 12 Jan 2000 00:13:38 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3469D3E0@standards.nortelnetworks.com>; Wed, 12 Jan 2000 0:01:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 119354 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jan 2000 00:01:14 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.24485770@standards.nortelnetworks.com>; Wed, 12 Jan 2000 0:01:14 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA13591 for ; Tue, 11 Jan 2000 22:11:53 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id VAA19209; Tue, 11 Jan 2000 21:11:53 -0800 (PST) Received: from eastapp (eastapp.East.Sun.COM [129.148.163.25]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA25738; Tue, 11 Jan 2000 21:11:51 -0800 (PST) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Sun(TM) Web Access 1.0 Message-ID: <525891663.947653911181.JavaMail.aey@jurassic.Eng.Sun.COM> Date: Wed, 12 Jan 2000 00:11:51 -0500 Reply-To: Alper.Yegin@ENG.SUN.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Alper Yegin Subject: Re: [MOBILE-IP] RFC2002bis X-To: "Karim El-Malki (ERA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Karim, > >Could you please clarify why it is not possible to optimise the forwarding >when two communicating MNs are connected to the same FA (or GFA)? If you >use smooth handoffs (or fast handoffs in the case of HFAs) then if the MN >moves to another site there should be no problem. Also, what is the >problem of getting the HA out of the loop? I have to go back and read fast handoff mechanism, but if it's doing clean up (arp tables) after MN moves to some other foreign link, then there's no problem. But if it doesn't, it disturbs the routing. Also, in the case of using overlapped private addresses and FA located CoA, how does this kind of route optimization work? (sorry if this is already discussed) HA might be collecting statistics on traffic to the MN, which you would assume will go through HA without explicit route optimization methods. The values would come out low, because of the 'side effect' route optimization. alper From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 12 01:46: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 BAA01188 for ; Wed, 12 Jan 2000 01:46:35 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.393049B0@standards.nortelnetworks.com>; Wed, 12 Jan 2000 1:34:52 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 119499 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jan 2000 01:34:26 -0500 Received: from jm2.epitest.fi (194.241.248.126) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.28FE2B70@standards.nortelnetworks.com>; Wed, 12 Jan 2000 1:34:25 -0500 Received: (qmail 12585 invoked by uid 500); 12 Jan 2000 06:44:58 -0000 References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i Message-ID: <20000112084458.A12492@jm.epitest.fi> Date: Wed, 12 Jan 2000 08:44:58 +0200 Reply-To: Jouni Malinen Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jouni Malinen Subject: Re: [MOBILE-IP] Consensus for the extensions template defined in MIER To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: On Tue, Jan 11, 2000 at 08:58:48PM -0600, Basavaraj Patil wrote: > The MIER draft (draft-ietf-mobileip-mier-00.txt) states that all new > extensions defined for Mobile IP in the future MUST follow the > template that is specified in the document. > The difference from the existing definition specified in RFC2002 is > that adds a subtype field and the length field is increased two > octets. > > If you have concerns or disagree with this proposal, please express it > on the mailing list by the end of this week. Doesn't this break the compatibility with RFC 2002 compliant implementations completely as far as new skippable extensions are concerned? The two octet length field could be used in non-skippable extensions as they should cause the whole message to be silently discarded (if the receiver does not recognize them), but I didn't see that kind of requirement in the draft. This would mean that all the new extensions (even skippable) would be required to use the proposed extension format. An old implementation not knowing of the MIER draft would be unable to parse the extensions as the length field would be in a different place and of different size. So messages with a new _skippable_ extension would be dropped. Is this kind of compatibility breaking approach all right? Are we trying to make a need for some complicated method of finding out whether each MN, FA, and HA on the path support MIER before an agent could send any new skippable extensions? Or should the agent try once and after some time try again without the MIER type extension? I'm not welcoming this kind of complexity. It would be easier to change the extension format in RFC 2002bis and forget about the compatibility, but I don't think it is acceptable to break the compatibility this way with RFC 2002. I do, however, think, that subtyping of extensions would be a good thing. Subtyping can be done with one byte length field in the original place for the skippable extensions so that the compatibility is maintained. In addition, I don't see any good enough reason for requiring that every new extension must use subtyping. -- Jouni Malinen From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 12 05:19: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 FAA11619 for ; Wed, 12 Jan 2000 05:19:54 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.09521FC0@standards.nortelnetworks.com>; Wed, 12 Jan 2000 5:08:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 119742 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jan 2000 05:06:35 -0500 Received: from sonne.darmstadt.gmd.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CC7586F0@standards.nortelnetworks.com>; Wed, 12 Jan 2000 5:06:35 -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 LAA25654; Wed, 12 Jan 2000 11:17:03 +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: <387C547A.9F141A04@darmstadt.gmd.de> Date: Wed, 12 Jan 2000 11:16:26 +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] Consensus for the extensions template defined in MIER X-cc: Basavaraj Patil To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit > Basavaraj Patil wrote: > > The MIER draft (draft-ietf-mobileip-mier-00.txt) states that all new > extensions defined for Mobile IP in the future MUST follow the > template that is specified in the document. > The difference from the existing definition specified in RFC2002 is > that adds a subtype field and the length field is increased two > octets. > > If you have concerns or disagree with this proposal, please express it > on the mailing list by the end of this week. > > -Basavaraj Patil I disagree with the proposal, for the following reasons. Let me view types and subtypes as a means of multiplexing a control channel. Adding a subtype field to the type field of Mobile IP has two effects. First, there are more bits, hence more channels can be multiplexed. Second, these bits are partitioned in two groups, hence implementations may use a two-layer nesting of switches (if-statements). Neither from the discussion in this mailing list nor from the extensive tests we carried out with current Mobile IP can I conclude that Mobile IP needs more channels or a two-layer arrangement of these channels. Though this should suffice as a justification (I think that the necessity of adding something should be proved, not the necessity of not adding it), I'd like to repeat some known arguments with which I agree. First, existing software would have to be re-implemented. Second, existing proposals for protocol extensions would have to be re-worked. Third, there is some chance that future proposals are hard to fit into the MIER format, anyhow. Fourth, having more bits for the type field might entail the temptation to overburden Mobile IP. -- 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 Wed Jan 12 05:28: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 FAA11680 for ; Wed, 12 Jan 2000 05:28:45 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4CF70F50@standards.nortelnetworks.com>; Wed, 12 Jan 2000 5:17:20 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 119782 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jan 2000 05:16:47 -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.39199C50@standards.nortelnetworks.com>; Wed, 12 Jan 2000 5:16:47 -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 LAA01754; Wed, 12 Jan 2000 11:27:17 +0100 (MET) Received: from esealnt172.ericsson.se ([130.100.184.165]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 12 Jan 2000 10:27:04 0000 (GMT) Received: by esealnt172 with Internet Mail Service (5.5.2448.0) id ; Wed, 12 Jan 2000 11:27:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5F05C89FB2F8D211B6430008C791912701D2EB7B@esealnt190> Date: Wed, 12 Jan 2000 11:27: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] RFC2002bis X-To: "charliep@IPRG.NOKIA.COM" , Alper Yegin To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Charlie and Alper Thanks for the explanation. So the main problem is the arp cache of other hosts on the same FA, in the case when the MN moves. Cutting the HA out of the loop brings advantage and disadvantage (as Alper pointed out), so I would imagine this depends on whether you are collecting statistics on the HA. However it is surely good to optimise forwarding in cases where there are few FAs (maybe even one) and you need to limit latency. When the MN moves, say it does a smooth handoff such that the "old" FA is notified. Could that trigger the "old" FA to clean up the arp problem with a gratuitous arp? A similar cleanup is for HFAs using Fast Handoffs. Also, applied to 3G networks you don't have the same restraints, so it would be good to leave this possibility open unless you see other major difficulties. Rgds /Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 12 06:52: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 GAA12307 for ; Wed, 12 Jan 2000 06:52:09 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E9E2DEB0@standards.nortelnetworks.com>; Wed, 12 Jan 2000 6:40:28 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 119883 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jan 2000 06:39:18 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5A6A0200@standards.nortelnetworks.com>; Wed, 12 Jan 2000 6:29:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12048; Wed, 12 Jan 2000 06:39:57 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200001121139.GAA12048@ietf.org> Date: Wed, 12 Jan 2000 06:39:52 -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-vendor-ext-08.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 Vendor/Organization-Specific Extensions Author(s) : G. Dommety, K. Leung Filename : draft-ietf-mobileip-vendor-ext-08.txt Pages : 4 Date : 11-Jan-00 This document proposes two new extensions to Mobile IP [1]. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-vendor-ext-08.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-vendor-ext-08.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-vendor-ext-08.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: <20000111095733.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-vendor-ext-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-vendor-ext-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000111095733.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 12 10:36: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 KAA17873 for ; Wed, 12 Jan 2000 10:36:33 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.25E09820@standards.nortelnetworks.com>; Wed, 12 Jan 2000 10:24:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 120312 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jan 2000 10:23:23 -0500 Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0DF39050@standards.nortelnetworks.com>; Wed, 12 Jan 2000 10:23:23 -0500 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Wed Jan 12 10:33:59 EST 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Wed Jan 12 10:33:58 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 598E25701C; Wed, 12 Jan 2000 09:33:57 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20000112153357.598E25701C@king.research.bell-labs.com> Date: Wed, 12 Jan 2000 09:33:57 -0600 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: [MOBILE-IP] Consensus for the extensions template defined in MIER X-To: Basavaraj Patil To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Basavaraj Patil (BP) writes: BP> If you have concerns or disagree with this proposal, please express it BP> on the mailing list by the end of this week. I do not think we should require all new extensions to follow the MIER format. MIER might not be appropriate for all situations and could unnecessarily slow down current standards efforts. New extension proposals should follow the MIER format if and when appropriate. -Pete From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 12 17:55: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 RAA26324 for ; Wed, 12 Jan 2000 17:55:28 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8CA7DB80@standards.nortelnetworks.com>; Wed, 12 Jan 2000 17:43:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 121035 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jan 2000 17:42:07 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.58473250@standards.nortelnetworks.com>; Wed, 12 Jan 2000 17:42:07 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 12 Jan 2000 16:52:28 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Wed, 12 Jan 2000 17:52:17 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 12 Jan 2000 16:52:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5D4F.AC5ED980" Message-ID: <9A9367D1556AD21182C40000F80930AB010BC1A4@crchy28b.us.nortel.com> Date: Wed, 12 Jan 2000 16:52:12 -0600 Reply-To: Mohamed Khalil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohamed Khalil Subject: Re: [MOBILE-IP] Consensus for the extensions template defined in MIER X-To: Wolfgang Schoenfeld 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_01BF5D4F.AC5ED980 Content-Type: text/plain > -----Original Message----- > From: Wolfgang Schoenfeld [SMTP:schfeld@DARMSTADT.GMD.DE] > Sent: Wednesday, January 12, 2000 4:16 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Consensus for the extensions template > defined in MIER > > > Basavaraj Patil wrote: > > > > The MIER draft (draft-ietf-mobileip-mier-00.txt) states that all new > > extensions defined for Mobile IP in the future MUST follow the > > template that is specified in the document. > > The difference from the existing definition specified in RFC2002 is > > that adds a subtype field and the length field is increased two > > octets. > > > > If you have concerns or disagree with this proposal, please express it > > on the mailing list by the end of this week. > > > > -Basavaraj Patil > > I disagree with the proposal, for the following reasons. > > Let me view types and subtypes as a means of multiplexing a control > channel. > Adding a subtype field to the type field of Mobile IP has two effects. > First, there are more bits, > hence more channels can be multiplexed. > Second, these bits are partitioned in two groups, > hence implementations may use a two-layer nesting of switches > (if-statements). > Neither from the discussion in this mailing list > nor from the extensive tests we carried out with current Mobile IP > can I conclude that Mobile IP needs more channels > or a two-layer arrangement of these channels. > Though this should suffice as a justification (I think that > the necessity of adding something should be proved, > not the necessity of not adding it), > I'd like to repeat some known arguments with which I agree. > First, existing software would have to be re-implemented. > [MK>] I disagree completely by what you said, no software has to be > re-implemented at all. All what you have to do for the protocols which > adopt MIER is to have one function to process the general type and inside > this function the subtype will be processed. In the matter of fact it > aggregate processing similar elements in one function instead of > multiple ones. This will make implementation and debugging problems more > easier. I don't understand why do you think that existing software has to > be re-implemented? > . > Second, existing proposals for protocol extensions would have to be > re-worked. > [MK>] We agree with that but we think that this re-work would be for the > benefit of the WG. . > Third, there is some chance that future proposals are hard to fit > [MK>] General statemets does not proof anything. Give me an example for > one which cannot fit. All what i am doing is adding a subtype field to the > current extension and increasing the length field. How would these minor > changes really make it hard for future proposals? > into the MIER format, anyhow. > Fourth, having more bits for the type field might entail > the temptation to overburden Mobile IP. > [MK>] I don't understand how this could be true? > > -- Wolfgang Schoenfeld > GMD-IPSI, Dolivostr. 15, Room 128, D-64293 Darmstadt > +49-6151-869-865 (Phone), -818 (FAX) > +49-170-2285450 (Mobile Phone) ------_=_NextPart_001_01BF5D4F.AC5ED980 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] Consensus for the extensions template defined in = MIER

    -----Original Message-----
    From:   Wolfgang Schoenfeld = [SMTP:schfeld@DARMSTADT.GMD.DE]
    Sent:   Wednesday, January 12, 2000 4:16 AM
    To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: [MOBILE-IP] Consensus for the = extensions template defined in MIER

    > Basavaraj Patil wrote:
    >
    > The MIER draft = (draft-ietf-mobileip-mier-00.txt) states that all new
    > extensions defined for Mobile IP = in the future MUST follow the
    > template that is specified in = the document.
    > The difference from the existing = definition specified in RFC2002 is
    > that adds a subtype field and = the length field is increased two
    > octets.
    >
    > If you have concerns or disagree = with this proposal, please express it
    > on the mailing list by the end = of this week.
    >
    > -Basavaraj Patil

    I disagree with the proposal, for the = following reasons.

    Let me view types and subtypes as a = means of multiplexing a control channel.
    Adding a subtype field to the type = field of Mobile IP has two effects.
    First, there are more bits,
    hence more channels can be = multiplexed.
    Second, these bits are partitioned in = two groups,
    hence implementations may use a = two-layer nesting of switches (if-statements).
    Neither from the discussion in this = mailing list
    nor from the extensive tests we = carried out with current Mobile IP
    can I conclude that Mobile IP needs = more channels
    or a two-layer arrangement of these = channels.

Though this should suffice as a = justification (I think that
the necessity of adding something = should be proved,
not the necessity of not adding = it),
I'd like to repeat some known = arguments with which I agree.
First, existing software would have = to be re-implemented.
[MK>]  I disagree completely by = what you said, no software has to be re-implemented at all. All what = you have to do for the protocols which adopt MIER is to have one = function to process the general type and inside this function the = subtype will be processed. In the matter of fact it aggregate = processing similar elements in one function instead   = of  multiple ones. This will make implementation and debugging = problems more easier. I don't understand why do you think that existing = software has to be re-implemented?

.

Second, existing proposals for = protocol extensions would have to be re-worked.
[MK>]   We agree with that but we think that = this re-work would be for the benefit of the WG.
.
Third, there is some chance that = future proposals are hard to fit
[MK>] General statemets does not proof anything. Give = me an example for one which cannot fit. All what i am doing is adding a = subtype field to the current extension and increasing the length field. = How would these minor changes really make it hard for future = proposals?

into the MIER format, anyhow.
Fourth, having more bits for the type = field might entail
the temptation to overburden Mobile = IP.
[MK>] I don't understand how this could be true? =
 

    -- Wolfgang Schoenfeld
    GMD-IPSI, Dolivostr. 15, Room 128, = D-64293 Darmstadt
    +49-6151-869-865 (Phone), -818 = (FAX)
    +49-170-2285450 (Mobile Phone)

------_=_NextPart_001_01BF5D4F.AC5ED980-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 13 03:22: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 DAA13923 for ; Thu, 13 Jan 2000 03:22:45 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C1AE48B0@standards.nortelnetworks.com>; Thu, 13 Jan 2000 3:10:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 121816 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jan 2000 03:08:53 -0500 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1FCE4550@standards.nortelnetworks.com>; Thu, 13 Jan 2000 2:58:53 -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 KAA27572 for ; Thu, 13 Jan 2000 10:09:32 +0200 (EET) Received: from loki.research.nokia.com (loki.research.nokia.com [172.21.33.76]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id KAA08782 for ; Thu, 13 Jan 2000 10:09:30 +0200 (EET) Received: from possu.research.nokia.com (possu.research.nokia.com [172.21.33.80]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id KAA07031 for ; Thu, 13 Jan 2000 10:09:29 +0200 (EET) Received: from localhost (asokan@localhost) by possu.research.nokia.com (8.9.1/8.9.1) with ESMTP id KAA21976 for ; Thu, 13 Jan 2000 10:09:29 +0200 (EET) X-Authentication-Warning: possu.research.nokia.com: asokan owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 13 Jan 2000 10:09:29 +0200 Reply-To: n.asokan@nokia.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "N. Asokan" Subject: Re: [MOBILE-IP] Consensus for the extensions template defined in MIER To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Jouni Malinen wrote: [...] > Doesn't this break the compatibility with RFC 2002 compliant > implementations completely as far as new skippable extensions are > concerned? The two octet length field could be used in non-skippable > extensions as they should cause the whole message to be silently > discarded (if the receiver does not recognize them), but I didn't see > that kind of requirement in the draft. This is clearly a problem. I already pointed this out several times, e.g. in message 74 of the December archives: http://standards.nortelnetworks.com/scripts/wa.exe?A2=ind9912&L=mobile-ip&O=D&P=8132 | [...] | Additional comments on the new MIER-01 draft (from a mail I sent to | Mohamed et al earlier today): | > - if you use two bytes for the length field, all MIER extensions have | > to be unskippable (for backward compatibility). This wouldn't be | > a good idea, esp. if it is mandated that all new extensions have | > to be in MIER style. | > | > I'd suggest that you propose two types of MIER extensions: regular | > and "unskippable jumbo" extensions. Regular extensions use only | > 1 byte length field and can be either skippable or unskippable. | > "Unskippable jumbo" extensions have 2 byte length fields and | > must be unskippable. | [...] Regards, - Asokan --- N. Asokan, Communication Systems Lab, Nokia Research Center, Helsinki From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 13 05:38: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 FAA14791 for ; Thu, 13 Jan 2000 05:38:34 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C6030230@standards.nortelnetworks.com>; Thu, 13 Jan 2000 5:26:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 121908 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jan 2000 05:25:23 -0500 Received: from sonne.darmstadt.gmd.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.97470CC0@standards.nortelnetworks.com>; Thu, 13 Jan 2000 5:25:23 -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 LAA27732; Thu, 13 Jan 2000 11:35:13 +0100 (MET) X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: de,en,it MIME-Version: 1.0 References: <9A9367D1556AD21182C40000F80930AB010BC1A4@crchy28b.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <387DAA3B.116BAD48@darmstadt.gmd.de> Date: Thu, 13 Jan 2000 11:34:36 +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] Consensus for the extensions template defined in MIER X-To: Mohamed Khalil To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I wrote: > ... > First, existing software would have to be re-implemented. > [MK>] I disagree completely by what you said, no software has to be > re-implemented at all. All what you have to do for the protocols which adopt > MIER is to have one function to process the general type and inside this > function the subtype will be processed. There is no guarantee that all implementors have followed this systematic way. The (current) RFC does not say anything about that. Imagine someone optimizing his/her code by masking the type field, i.e. going to the very bits! > In the matter of fact it aggregate > processing similar elements in one function instead of multiple ones. This > will make implementation and debugging problems more easier. Again, this is an implementation issue and, perhaps, can also be solved by some clever masking. Note that the type-subtype field separation hinders flexible use of all bits in the field (compare the role of subnet masking of IP addresses in routing!). > I don't > understand why do you think that existing software has to be re-implemented? You are right: It may happen that, when considering to incorporate MIER, some implementors will not feel forced to completely re-implement. > > Second, existing proposals for protocol extensions would have to be re-worked. > > [MK>] We agree with that but we think that this re-work would be for the > benefit of the WG. > . > Third, there is some chance that future proposals are hard to fit > [MK>] General statemets does not proof anything. Give me an example for one > which cannot fit. All what i am doing is adding a subtype field to the current > extension and increasing the length field. How would these minor changes > really make it hard for future proposals? I'm very sorry - YOU should prove that all future proposals fit to MIER, and not me that there is some which does not. See my previous note. > > into the MIER format, anyhow. > Fourth, having more bits for the type field might entail > the temptation to overburden Mobile IP. > [MK>] I don't understand how this could be true? This was meant similarly to the well-known programming experience: Not always does an abundance of resources (here: bits to represent types) lead to better (seen from the user) programs. Hoping not to annoy the other readers of this mailing list, yours 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 Thu Jan 13 06:01: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 GAA15039 for ; Thu, 13 Jan 2000 06:01:42 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FE722760@standards.nortelnetworks.com>; Thu, 13 Jan 2000 5:49:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 121949 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jan 2000 05:49:12 -0500 Received: from srvlis11.teleweb.pt by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.841FDF80@standards.nortelnetworks.com>; Thu, 13 Jan 2000 5:39:10 -0500 Received: from srvlis01.teleweb.pt (srvlis01.teleweb.pt [212.16.129.11]) by srvlis11.teleweb.pt (8.9.3/8.9.3) with ESMTP id KAA10240 for ; Thu, 13 Jan 2000 10:49:45 GMT Received: from srvlis01.teleweb.pt (nobody@srvlis02i.teleweb.pt [192.168.168.12]) by srvlis01.teleweb.pt (8.8.8/8.8.8) with SMTP id KAA04588; Thu, 13 Jan 2000 10:49:43 GMT X-CC-Sender: nuno.pimentel@teleweb.pt X-User-Info: 212.18.162.33 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <387dad34.13b5.0@srvlis01.teleweb.pt> Date: Thu, 13 Jan 2000 10:47:16 GMT Reply-To: nuno.pimentel@teleweb.pt Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: nuno.pimentel@teleweb.pt Subject: [MOBILE-IP] How can I UNSUBSCRIBE from this list!!!!!!!!!!!!!!!!!!!! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, I'm trying to unsubscribe from this for about 2 months and I don't know how!!! I would appreciate If someone could tell me how to unsubscribe from this list! I'm don't to continue to receive about 20 mail msgs that I DON'T want to receive! Thanks! Np From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 13 06:52: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 GAA15385 for ; Thu, 13 Jan 2000 06:52:13 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.078597E0@standards.nortelnetworks.com>; Thu, 13 Jan 2000 6:40:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 122097 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jan 2000 06:39:12 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8174B880@standards.nortelnetworks.com>; Thu, 13 Jan 2000 6:29:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15219; Thu, 13 Jan 2000 06:39:55 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200001131139.GAA15219@ietf.org> Date: Thu, 13 Jan 2000 06:39:54 -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-cellularip-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 : Cellular IP Author(s) : A. Campbell, J. Gomez, C. Wan, S. Kim, Z. Turanyi, A. Valko, Filename : draft-ietf-mobileip-cellularip-00.txt Pages : 22 Date : 12-Jan-00 This document specifies a protocol that allows routing IP datagrams to a mobile host. The protocol is intended to provide local mobility and handoff support. It can interwork with Mobile IP [1] to provide wide area mobility support. Four fundamental design principles of the protocol are: (1) location information is stored in distributed data bases (2) location information referring to a mobile host is created and updated by regular IP datagrams originated by the said mobile host (3) location information is stored as soft state (4) location management for idle mobile hosts is separated from location management of hosts that are actively transmitting or receiving data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-cellularip-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-cellularip-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-cellularip-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: <20000112084459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-cellularip-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-cellularip-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000112084459.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 13 06:52: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 GAA15387 for ; Thu, 13 Jan 2000 06:52:13 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.07C84630@standards.nortelnetworks.com>; Thu, 13 Jan 2000 6:40:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 122100 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jan 2000 06:39:17 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.844E3E50@standards.nortelnetworks.com>; Thu, 13 Jan 2000 6:29:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15233; Thu, 13 Jan 2000 06:39:59 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200001131139.GAA15233@ietf.org> Date: Thu, 13 Jan 2000 06:39:59 -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-mn-nai-07.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 Network Access Identifier Extension for IPv4 Author(s) : P. Calhoun, C. Perkins Filename : draft-ietf-mobileip-mn-nai-07.txt Pages : 7 Date : 12-Jan-00 AAA servers are in use within the Internet today to provide authentication and authorization services for dial-up computers. Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI). Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request. This draft also updates RFC2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mn-nai-07.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-mn-nai-07.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-mn-nai-07.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: <20000112084508.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-mn-nai-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-mn-nai-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000112084508.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 13 07:51: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 HAA16977 for ; Thu, 13 Jan 2000 07:51:23 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5A92E8E0@standards.nortelnetworks.com>; Thu, 13 Jan 2000 7:39:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 122646 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jan 2000 07:37:42 -0500 Received: from smtp2.cluster.oleane.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.12DA5060@standards.nortelnetworks.com>; Thu, 13 Jan 2000 7:37:41 -0500 Received: from oleane (dyn-1-1-028.Vin.dialup.oleane.fr [195.25.4.28]) by smtp2.cluster.oleane.net with SMTP id NAA35249; Thu, 13 Jan 2000 13:48:12 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01BF5DCC.758AB780" 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: <001001bf5dc4$19ddc240$0401a8c0@oleane.com> Date: Thu, 13 Jan 2000 13:45:31 +0100 Reply-To: Peter Lewis Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Peter Lewis Subject: [MOBILE-IP] MPLS Forum To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_000D_01BF5DCC.758AB780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The MPLS Forum will stand in Paris next 7-10 March. Reports from real deployments, standard progress issues, technical propositions, debate: building the next IP architecture. Get details at: www.upperside.fr/mplsforum.htm ------=_NextPart_000_000D_01BF5DCC.758AB780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The MPLS = Forum will stand=20 in Paris next 7-10 March. Reports from real
deployments, standard = progress=20 issues, technical propositions, debate:
building the next IP=20 architecture.
Get details at:
www.upperside.fr/mplsforum= .htm
 
 
------=_NextPart_000_000D_01BF5DCC.758AB780-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 13 10:21: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 KAA19726 for ; Thu, 13 Jan 2000 10:20:54 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1D472E00@standards.nortelnetworks.com>; Thu, 13 Jan 2000 10:08:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 122826 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jan 2000 10:07:08 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F34DA2A0@standards.nortelnetworks.com>; Thu, 13 Jan 2000 10:07:08 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 13 Jan 2000 09:15:42 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Thu, 13 Jan 2000 10:15:38 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 13 Jan 2000 09:15:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5DD9.0B7E25EA" Message-ID: <9A9367D1556AD21182C40000F80930AB010BC1A7@crchy28b.us.nortel.com> Date: Thu, 13 Jan 2000 09:15:35 -0600 Reply-To: Mohamed Khalil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohamed Khalil Subject: Re: [MOBILE-IP] Consensus for the extensions template defined in MIER X-To: Jouni Malinen 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_01BF5DD9.0B7E25EA Content-Type: text/plain > -----Original Message----- > From: Jouni Malinen [SMTP:jkmaline@CC.HUT.FI] > Sent: Wednesday, January 12, 2000 12:45 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Consensus for the extensions template > defined in MIER > > On Tue, Jan 11, 2000 at 08:58:48PM -0600, Basavaraj Patil wrote: > > > The MIER draft (draft-ietf-mobileip-mier-00.txt) states that all new > > extensions defined for Mobile IP in the future MUST follow the > > template that is specified in the document. > > The difference from the existing definition specified in RFC2002 is > > that adds a subtype field and the length field is increased two > > octets. > > > > If you have concerns or disagree with this proposal, please express it > > on the mailing list by the end of this week. > > Doesn't this break the compatibility with RFC 2002 compliant > implementations completely as far as new skippable extensions are > concerned? The two octet length field could be used in non-skippable > extensions as they should cause the whole message to be silently > discarded (if the receiver does not recognize them), but I didn't see > that kind of requirement in the draft. > > This would mean that all the new extensions (even skippable) would be > required to use the proposed extension format. An old implementation > not knowing of the MIER draft would be unable to parse the extensions > as the length field would be in a different place and of different > size. So messages with a new _skippable_ extension would be dropped. > > Is this kind of compatibility breaking approach all right? Are we > trying to make a need for some complicated method of finding out > whether each MN, FA, and HA on the path support MIER before an agent > could send any new skippable extensions? Or should the agent try once > and after some time try again without the MIER type extension? I'm not > welcoming this kind of complexity. It would be easier to change the > extension format in RFC 2002bis and forget about the compatibility, > but I don't think it is acceptable to break the compatibility this way > with RFC 2002. > > I do, however, think, that subtyping of extensions would be a good > thing. Subtyping can be done with one byte length field in the > original place for the skippable extensions so that the compatibility > is maintained. In addition, I don't see any good enough reason for > requiring that every new extension must use subtyping. [MK>] Your point of view is completely valid, and i think your suggestion about having another template for skippable extension where the location of the length field is preserved is a good suggestion and will be taken in consideration in the next version of this draft. Once again, thanks for your constructive comments. -- > -- > Jouni Malinen > > > Mohamed Khalil ------_=_NextPart_001_01BF5DD9.0B7E25EA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] Consensus for the extensions template defined in = MIER

    -----Original Message-----
    From:   Jouni Malinen [SMTP:jkmaline@CC.HUT.FI]
    Sent:   Wednesday, January 12, 2000 12:45 AM
    To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: [MOBILE-IP] Consensus for the = extensions template defined in MIER

    On Tue, Jan 11, 2000 at 08:58:48PM = -0600, Basavaraj Patil wrote:

    > The MIER draft = (draft-ietf-mobileip-mier-00.txt) states that all new
    > extensions defined for Mobile IP = in the future MUST follow the
    > template that is specified in = the document.
    > The difference from the existing = definition specified in RFC2002 is
    > that adds a subtype field and = the length field is increased two
    > octets.
    >
    > If you have concerns or disagree = with this proposal, please express it
    > on the mailing list by the end = of this week.

    Doesn't this break the compatibility = with RFC 2002 compliant
    implementations completely as far as = new skippable extensions are
    concerned? The two octet length field = could be used in non-skippable
    extensions as they should cause the = whole message to be silently
    discarded (if the receiver does not = recognize them), but I didn't see
    that kind of requirement in the = draft.

    This would mean that all the new = extensions (even skippable) would be
    required to use the proposed = extension format. An old implementation
    not knowing of the MIER draft would = be unable to parse the extensions
    as the length field would be in a = different place and of different
    size. So messages with a new = _skippable_ extension would be dropped.

    Is this kind of compatibility breaking = approach all right? Are we
    trying to make a need for some = complicated method of finding out
    whether each MN, FA, and HA on the = path support MIER before an agent
    could send any new skippable = extensions? Or should the agent try once
    and after some time try again without = the MIER type extension? I'm not
    welcoming this kind of complexity. It = would be easier to change the
    extension format in RFC 2002bis and = forget about the compatibility,
    but I don't think it is acceptable to = break the compatibility this way
    with RFC 2002.

    I do, however, think, that subtyping = of extensions would be a good
    thing. Subtyping can be done with one = byte length field in the
    original place for the skippable = extensions so that the compatibility
    is maintained. In addition, I don't = see any good enough reason for
    requiring that every new extension = must use subtyping.
    [MK>]   Your point of view is completely valid, = and i think your suggestion about having another template  for = skippable extension where the location of the length field is = preserved  is a good suggestion and will be taken in consideration = in the next version of this draft. Once again, thanks for your = constructive comments.

    --


    --
    Jouni Malinen



    Mohamed = Khalil


------_=_NextPart_001_01BF5DD9.0B7E25EA-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 13 10:46: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 KAA20028 for ; Thu, 13 Jan 2000 10:46:54 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C47BDE70@standards.nortelnetworks.com>; Thu, 13 Jan 2000 10:34:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 122871 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jan 2000 10:33:46 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ABEA8050@standards.nortelnetworks.com>; Thu, 13 Jan 2000 10:33:46 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 13 Jan 2000 09:43:51 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Thu, 13 Jan 2000 10:43:07 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 13 Jan 2000 09:43:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5DDC.E2586D5C" Message-ID: <9A9367D1556AD21182C40000F80930AB010BC1A8@crchy28b.us.nortel.com> Date: Thu, 13 Jan 2000 09:43:01 -0600 Reply-To: Mohamed Khalil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohamed Khalil Subject: Re: [MOBILE-IP] Consensus for the extensions template defined in MIER X-To: "n.asokan@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_01BF5DDC.E2586D5C Content-Type: text/plain Hi Asokan, > -----Original Message----- > From: N. Asokan [SMTP:n.asokan@NOKIA.COM] > Sent: Thursday, January 13, 2000 2:09 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Consensus for the extensions template > defined in MIER > > Jouni Malinen wrote: > [...] > > Doesn't this break the compatibility with RFC 2002 compliant > > implementations completely as far as new skippable extensions are > > concerned? The two octet length field could be used in non-skippable > > extensions as they should cause the whole message to be silently > > discarded (if the receiver does not recognize them), but I didn't see > > that kind of requirement in the draft. > > This is clearly a problem. I already pointed this out several times, e.g. > in message 74 of the December archives: > [MK>] Your concern is completely valid. I read your message again Asokan's Old Message> > I'd suggest that you propose two types of MIER extensions: regular > and "unskippable jumbo" extensions. Regular extensions use only > 1 byte length field and can be either skippable or unskippable. > "Unskippable jumbo" extensions have 2 byte length fields and > must be unskippable. Your proposal is very similar to Jouni proposal. We will take that in consideration in next revision. Thank you for your comments. > http://standards.nortelnetworks.com/scripts/wa.exe?A2=ind9912&L=mobile-ip& > O=D&P=8132 > > | [...] > | Additional comments on the new MIER-01 draft (from a mail I sent to > | Mohamed et al earlier today): > | > - if you use two bytes for the length field, all MIER extensions have > | > to be unskippable (for backward compatibility). This wouldn't be > | > a good idea, esp. if it is mandated that all new extensions have > | > to be in MIER style. > | > > | > I'd suggest that you propose two types of MIER extensions: regular > | > and "unskippable jumbo" extensions. Regular extensions use only > | > 1 byte length field and can be either skippable or unskippable. > | > "Unskippable jumbo" extensions have 2 byte length fields and > | > must be unskippable. > | [...] > > Regards, > - Asokan > > --- > N. Asokan, Communication Systems Lab, Nokia Research Center, Helsinki ------_=_NextPart_001_01BF5DDC.E2586D5C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] Consensus for the extensions template defined in = MIER

Hi Asokan,


    -----Original Message-----
    From:   N. Asokan [SMTP:n.asokan@NOKIA.COM]
    Sent:   Thursday, January 13, 2000 2:09 AM
    To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: [MOBILE-IP] Consensus for the = extensions template defined in MIER

    Jouni Malinen = <jkmaline@CC.HUT.FI> wrote:
    [...]
    > Doesn't this break the = compatibility with RFC 2002 compliant
    > implementations completely as = far as new skippable extensions are
    > concerned? The two octet length = field could be used in non-skippable
    > extensions as they should cause = the whole message to be silently
    > discarded (if the receiver does = not recognize them), but I didn't see
    > that kind of requirement in the = draft.

    This is clearly a problem.  I = already pointed this out several times, e.g.
    in message 74 of the December = archives:

    [MK>] Your concern is completely valid. I read your message = again

    Asokan's Old = Message>
    >   = I'd suggest that you propose two types of MIER extensions: = regular
    >   = and "unskippable jumbo" extensions.  Regular extensions = use only
    >   = 1 byte length field and can be either skippable or = unskippable.
    >   = "Unskippable jumbo" extensions have 2 byte length fields = and
    >   = must be unskippable.

    Your = proposal  is very similar to  Jouni proposal.  We will = take that in consideration in next revision.
    Thank you for = your comments.
    http://standards.nortelnetworks.com/scripts/wa.exe?A2=3D= ind9912&L=3Dmobile-ip&O=3DD&P=3D8132

    | [...]
    | Additional comments on the new = MIER-01 draft (from a mail I sent to
    | Mohamed et al earlier = today):
    | > - if you use two bytes for the = length field, all MIER extensions have
    | >   to be unskippable = (for backward compatibility).  This wouldn't be
    | >   a good idea, esp. = if it is mandated that all new extensions have
    | >   to be in MIER = style.
    | >
    | >   I'd suggest that = you propose two types of MIER extensions: regular
    | >   and = "unskippable jumbo" extensions.  Regular extensions use = only
    | >   1 byte length = field and can be either skippable or unskippable.
    | >   "Unskippable = jumbo" extensions have 2 byte length fields and
    | >   must be = unskippable.
    | [...]

    Regards,
    - Asokan

    ---
    N. Asokan, Communication Systems Lab, = Nokia Research Center, Helsinki

------_=_NextPart_001_01BF5DDC.E2586D5C-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 13 11:22: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 LAA20588 for ; Thu, 13 Jan 2000 11:22:53 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CE32CCD0@standards.nortelnetworks.com>; Thu, 13 Jan 2000 11:10:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 122923 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jan 2000 11:08:41 -0500 Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8C667860@standards.nortelnetworks.com>; Thu, 13 Jan 2000 11:08:41 -0500 Received: from zrchh190 by smtprich.nortel.com; Thu, 13 Jan 2000 10:19:48 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zrchh190; Thu, 13 Jan 2000 10:25:27 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 13 Jan 2000 10:16:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5DE1.8BA1625C" X-Orig: Message-ID: Date: Thu, 13 Jan 2000 10:16:28 -0600 Reply-To: Basavaraj Patil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: [MOBILE-IP] WG Last Call (draft-ietf-mobileip-challenge-08.txt) To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ------_=_NextPart_001_01BF5DE1.8BA1625C Content-type: text/plain; charset="ISO-8859-1" Mobile IP Challenge/Response Extensions draft (draft-ietf-mobileip-challenge-08.txt) has undergone a couple of revisions since the previous WG last call. As a result we are sending out another WG last call on this I-D. Please provide comments and feedback within the next two weeks. WG last call issued on: Jan 13, 2000 Regards, Basavaraj Phil ------_=_NextPart_001_01BF5DE1.8BA1625C Content-type: text/html; charset="ISO-8859-1" WG Last Call (draft-ietf-mobileip-challenge-08.txt)

Mobile IP Challenge/Response Extensions draft
(draft-ietf-mobileip-challenge-08.txt) has undergone a couple of
revisions since the previous WG last call. As a result we are sending out
another WG last call on this I-D. Please provide comments and feedback
within the next two weeks.

WG last call issued on: Jan 13, 2000

Regards,
Basavaraj
Phil

------_=_NextPart_001_01BF5DE1.8BA1625C-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 13 11:32: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 LAA20868 for ; Thu, 13 Jan 2000 11:32:51 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.350E2BB0@standards.nortelnetworks.com>; Thu, 13 Jan 2000 11:20:33 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 122952 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jan 2000 11:19:12 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.04BAA650@standards.nortelnetworks.com>; Thu, 13 Jan 2000 11:19:12 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 13 Jan 2000 10:29:37 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Thu, 13 Jan 2000 11:29:20 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 13 Jan 2000 10:29:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5DE3.5211BADA" Message-ID: Date: Thu, 13 Jan 2000 10:29:08 -0600 Reply-To: Ron Young Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ron Young Subject: [MOBILE-IP] Unsubscribing from the Mobile IP mailing list 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_01BF5DE3.5211BADA Content-Type: text/plain; charset="ISO-8859-1" To be removed from the Mobile IP list: Send email to: listserv@standards.nortelnetworks.com and in the *body* of the message (not in the subject) type: signoff mobile-ip or unsubscribe mobile-ip You must send the message using the same e-mail address as the one you subscribed with. If this can not be done (i.e., your mail domain has changed, etc.), then send a note to mobile-ip-request@standards.nortelnetworks.com and ask the helpful and handsome list owner to look for your subscription and delete you. ------------------------------------------------------------------------ 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. ------_=_NextPart_001_01BF5DE3.5211BADA Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Unsubscribing from the Mobile IP mailing list

To be removed from the Mobile IP list:

Send email to:  = listserv@standards.nortelnetworks.com

and in the *body* of the message (not in
the subject) type:  signoff mobile-ip or = unsubscribe mobile-ip

You must send the message using the same e-mail = address as the one you subscribed with.  If this can not be done = (i.e., your mail domain has changed, etc.), then send a note to = mobile-ip-request@standards.nortelnetworks.com and ask the helpful and = handsome list owner to look for your subscription and delete = you.

---------------------------------------------------------------= ---------
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.
 

------_=_NextPart_001_01BF5DE3.5211BADA-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 13 13:40: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 NAA23565 for ; Thu, 13 Jan 2000 13:40:17 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0041C330@standards.nortelnetworks.com>; Thu, 13 Jan 2000 13:27:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123074 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jan 2000 13:26:41 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D3E5DDD0@standards.nortelnetworks.com>; Thu, 13 Jan 2000 13:26:41 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29330 for ; Thu, 13 Jan 2000 11:37:23 -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 KAA15892; Thu, 13 Jan 2000 10:37:23 -0800 (PST) Received: from istanbul (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA03643; Thu, 13 Jan 2000 10:37:22 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8o5P+3uk1Mlm8ltAury51w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Message-ID: <200001131837.KAA03643@jurassic.eng.sun.com> Date: Thu, 13 Jan 2000 10:36:50 -0800 Reply-To: Alper Yegin Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Alper Yegin Subject: Re: [MOBILE-IP] RFC2002bis X-To: Karim.El-Malki@ERA.ERICSSON.SE To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > When the MN moves, say it does a smooth handoff such that the "old" FA > is notified. Could that trigger the "old" FA to clean up the arp problem > with a gratuitous arp? I think so. But this requires a security association between 'old' FA and whoever is sending the notification (HA, new FA) to it. Otherwise one can launch DoS attacks. alper From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 13 13:57: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 NAA23741 for ; Thu, 13 Jan 2000 13:56:57 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.61C78340@standards.nortelnetworks.com>; Thu, 13 Jan 2000 13:44:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123108 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jan 2000 13:43:23 -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.28E01970@standards.nortelnetworks.com>; Thu, 13 Jan 2000 13:43:23 -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 TAA25320; Thu, 13 Jan 2000 19:54:04 +0100 (MET) Received: from esealnt172.ericsson.se ([130.100.184.165]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 13 Jan 2000 18:53:51 0000 (GMT) Received: by esealnt172 with Internet Mail Service (5.5.2448.0) id ; Thu, 13 Jan 2000 19:53:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5F05C89FB2F8D211B6430008C791912701D2EB89@esealnt190> Date: Thu, 13 Jan 2000 19:54:00 +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] RFC2002bis X-To: Alper Yegin To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > When the MN moves, say it does a smooth handoff such that > the "old" FA > > is notified. Could that trigger the "old" FA to clean up > the arp problem > > with a gratuitous arp? > > I think so. But this requires a security association between > 'old' FA and > whoever is sending the notification (HA, new FA) to it. > Otherwise one can launch > DoS attacks. Regarding security, the Previous Foreign Agent Notification extension (used in smooth handoff) is authenticated. Rgds /Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 16 02:39: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 CAA01414 for ; Sun, 16 Jan 2000 02:39:10 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3A686A90@standards.nortelnetworks.com>; 16 Jan 2000 2:27:26 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 125762 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 16 Jan 2000 02:25:40 -0500 Received: from c008.sfo.cp.net (209.228.14.208) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FB2977C0@standards.nortelnetworks.com>; 16 Jan 2000 2:25:40 -0500 Received: (cpmta 11522 invoked from network); 15 Jan 2000 23:36:30 -0800 Received: from du-148-233-48-178.prodigy.net.mx (HELO uno) (148.233.48.178) by smtp.avispa.net with SMTP; 15 Jan 2000 23:36:30 -0800 X-Sent: 16 Jan 2000 07:36:30 GMT X-Sender: marco@mail.avispa.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) X-Priority: 2 (High) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.6.32.20000116013740.0090dab0@mail.avispa.net> Date: Sun, 16 Jan 2000 01:37:40 -0600 Reply-To: MARCO ADAMO FADL Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: MARCO ADAMO FADL Subject: [MOBILE-IP] Network's power. To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello folks, I just suscribe to Multikredits.com, a new and very unique company: http://multikredits.com/cgi-bin/db2www/main.d2w/input?ID=MARCOADAMO Regards, MA ;) From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 17 10:52: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 KAA02946 for ; Mon, 17 Jan 2000 10:52:45 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.55FD4500@standards.nortelnetworks.com>; Mon, 17 Jan 2000 10:40:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 126826 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Jan 2000 10:39:09 -0500 Received: from dirty.research.bell-labs.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B05C6910@standards.nortelnetworks.com>; Mon, 17 Jan 2000 10:29:09 -0500 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Mon Jan 17 10:38:06 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 KAA03567 for ; Mon, 17 Jan 2000 10:38:06 -0500 (EST) Received: (from salga@localhost) by valjean.dnrc.bell-labs.com (8.9.3/8.8.7) id KAA01033 for MOBILE-IP@standards.nortelnetworks.com; Mon, 17 Jan 2000 10:37:45 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us X-Operating-System: Linux 2.2.12-20 X-Organization: Lucent Technologies, Bell Laboratories Message-ID: <20000117103745.D24787@bell-labs.com> Date: Mon, 17 Jan 2000 10:37:45 -0500 Reply-To: Luca Salgarelli Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Luca Salgarelli Subject: [MOBILE-IP] Reverse tunnels, bcast packets and RFC2002bis To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi. Reading both RFC2344 and RFC2002(bis) I found no reference to what a multi-homed HA should do with packets addressed to itself, i.e. coming from a reverse tunnel from a registered client, with the inner destination address set to broadcast. I guess the logic would be that, after having passed all the security checks specified in 4.3.2 of RFC2344, the HA should inject the broadcast packet only on the interface that is on the home-net of the client. I was wondering if a clarification on this point should be put in RFC2002bis. Thanks Luca -- _________________ Luca Salgarelli Bell Laboratories Room 4F-506 101 Crawfords Corner Rd. Holmdel, NJ 07733, USA Tel: +1-732-332-6870 Fax: +1-732-949-7397 E-mail: lsalgarelli@bell-labs.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 17 14:24: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 OAA06406 for ; Mon, 17 Jan 2000 14:24:20 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DE9B0010@standards.nortelnetworks.com>; Mon, 17 Jan 2000 14:12:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 127083 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Jan 2000 14:10:36 -0500 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3A458FE0@standards.nortelnetworks.com>; Mon, 17 Jan 2000 14:00:36 -0500 Received: from kec.iwa-kec.co.jp (kec.iwa-kec.co.jp [210.161.194.131]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id NAA06517 for ; Mon, 17 Jan 2000 13:11:29 -0600 (CST) Received: from kec.iwa-kec.co.jp ([210.161.194.142]) by kec.iwa-kec.co.jp (8.9.3/3.7Wpl2/IWA-KEC) with SMTP id EAA26503 for mobile-ip@smallworks.com; Tue, 18 Jan 2000 04:07:31 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Message-ID: <200001171907.EAA26503@kec.iwa-kec.co.jp> Date: Tue, 18 Jan 2000 04:07:31 +0900 Reply-To: mbender22@ASEAN-MAIL.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: mbender22@ASEAN-MAIL.COM Subject: [MOBILE-IP] adv: Search Engine Registration X-To: mobile-ip@smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM To be removed call: 888-800-6339 X1377 I saw your listing on the internet. I work for a company that specializes in getting clients web sites listed as close to the top of the major search engines as possible. Our fee is only $29.95 per month to submit your site at least twice a month to over 350 search engines and directories. To get started and put your web site in the fast lane, call our toll free number below. Mike Bender 888-532-8842 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 17 15:48: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 PAA08640 for ; Mon, 17 Jan 2000 15:48:34 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A32C58B0@standards.nortelnetworks.com>; Mon, 17 Jan 2000 15:36:35 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 127259 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Jan 2000 15:34:53 -0500 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.00A0AC00@standards.nortelnetworks.com>; Mon, 17 Jan 2000 15:24:53 -0500 Received: from yourdomain.com (bay2-209.houston.ziplink.net [209.206.14.209]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id OAA07066 for ; Mon, 17 Jan 2000 14:35:47 -0600 (CST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <665.729588.831777@yourdomain.com> Date: Mon, 17 Jan 2000 15:34:53 -0500 Reply-To: success@WORLDUSERVE.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: success@WORLDUSERVE.COM Subject: [MOBILE-IP] Are You Serious About Creating Wealth? X-To: mobile-ip@smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit If you have reached the point in your life where you are ready for Financial Freedom and a Real opportunity to Retire in 2-3 years, we would like you to continue reading. This is not a program for everyone, so if you are not a highly motivated, goal oriented person with a burning desire to be successful and wealthy, please delete this message now. The number below will give you a two minute introduction to a business that is not a franchise or mlm. I speak with many people each day, and therefore am short on time, but also ready to listen if you fit the description above. And please, only call if you are serious about being among the wealthiest and best informed in the new millennium. ****24 hour recorded message: 1-800-320-9895 ext. 6579**** "There is no other road to genius and wealth than through voluntary self effort." Napoleon Hill From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 18 06:05: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 GAA27733 for ; Tue, 18 Jan 2000 06:05:19 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.525846B0@standards.nortelnetworks.com>; Tue, 18 Jan 2000 5:53:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 127735 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Jan 2000 05:51:58 -0500 Received: from fcu.edu.tw (140.134.4.1) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A771EE00@standards.nortelnetworks.com>; Tue, 18 Jan 2000 5:41:23 -0500 Received: from smallwei (pc173.iecs.fcu.edu.tw [140.134.24.173]) by fcu.edu.tw (8.9.2/8.9.2) with SMTP id SAA02165 for ; Tue, 18 Jan 2000 18:47:28 +0800 (CST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01BF61E5.6FD99A00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2014.211 Message-ID: <000c01bf61a2$6316d460$ad18868c@iecs.fcu.edu.tw> Date: Tue, 18 Jan 2000 18:54:24 +0800 Reply-To: phlin Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: phlin Subject: [MOBILE-IP] subscribe mobile-ip To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0009_01BF61E5.6FD99A00 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable subscribe mobile-ip ann lin ------=_NextPart_000_0009_01BF61E5.6FD99A00 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
subscribe mobile-ip ann = lin
------=_NextPart_000_0009_01BF61E5.6FD99A00-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 18 09:23: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 JAA29834 for ; Tue, 18 Jan 2000 09:23:35 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.02935F90@standards.nortelnetworks.com>; Tue, 18 Jan 2000 9:11:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 127903 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Jan 2000 09:10:30 -0500 Received: from nc3a.nato.int (192.41.140.186) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DDC05740@standards.nortelnetworks.com>; Tue, 18 Jan 2000 9:10:29 -0500 Received: from comsun21.nc3a.nato.int (comsun21.nc3a.nato.int [192.150.94.60]) by nc3a.nato.int (8.9.0/8.9.0) with ESMTP id PAA11505; Tue, 18 Jan 2000 15:17:18 +0100 (MET) Received: from comsun21 (comsun21 [192.150.94.60]) by comsun21.nc3a.nato.int (8.9.1b+Sun/8.9.1) with SMTP id PAA00556; Tue, 18 Jan 2000 15:21:13 +0100 (MET) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: nFJP1lDhQ1Xx6WjKruFbww== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc Message-ID: <200001181421.PAA00556@comsun21.nc3a.nato.int> Date: Tue, 18 Jan 2000 15:21:13 +0100 Reply-To: Rob Goode Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Rob Goode Subject: [MOBILE-IP] Mobile Router hints X-cc: eit@nc3a.nato.int, Rob.Goode@nc3a.nato.int To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Dear gentle folk, as part of our studies into how to apply Internet technology we put together a prototype Mobile Router system for a demonstration. A Mobile Router is a system with more than one interface which does IP forwarding between its interfaces and runs Mobile Node software. A Mobile Router is a useful device if you want a mobile network on, for instance, a ship or a train. The Mobile Router is entirely consistent with RFC2002, where a Mobile Node is defined as a "host or a router". There is nothing about a Mobile Router which deviates from the IETF standards. The Mobile Router prototype was made by modifying the Mobile IP implementation which Sun make publicly available in source code form for compiling under Solaris and Linux. We have compiled a list of detailed hints showing most of the changes that were necessary to get the Mobile Router working. The hints are for the Solaris base but are largely applicable to the Linux base. These hints are available from myself on request. Please send an email to me if you want them. You should be aware that they come with no warranty (express or implied) and no support. We are not liable in any way for any consequences of the use or non use of the hints. You are on your own. Have a nice day! Cheers, Rob Goode Principal Scientist CSD/T NATO C3 Agency The Hague, The Netherlands Tel: +31-(0)70-3142442 Fax: +31-(0)703142176 Email: Rob.Goode@nc3a.nato.int From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 18 11:19: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 LAA01969 for ; Tue, 18 Jan 2000 11:19:43 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3D2D8F30@standards.nortelnetworks.com>; Tue, 18 Jan 2000 11:07:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 128025 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Jan 2000 11:06:19 -0500 Received: from europe.std.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A675D6C0@standards.nortelnetworks.com>; Tue, 18 Jan 2000 10:56:19 -0500 Received: from world.std.com (brunner@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id LAA06547; Tue, 18 Jan 2000 11:07:17 -0500 (EST) Received: from localhost (brunner@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id LAA15307; Tue, 18 Jan 2000 11:07:15 -0500 (EST) X-Authentication-Warning: world.std.com: brunner@localhost didn't use HELO protocol Message-ID: <200001181607.LAA15307@world.std.com> Date: Tue, 18 Jan 2000 11:07:15 -0500 Reply-To: Eric Brunner Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Eric Brunner Subject: Re: [MOBILE-IP] Mobile Router hints X-To: Rob Goode To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of "Tue, 18 Jan 2000 15:21:13 EST." <200001181421.PAA00556@comsun21.nc3a.nato.int> Rob, I'd like to try this as well. Please send me a hint. TiA, Eric From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 18 12:37: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 MAA03431 for ; Tue, 18 Jan 2000 12:37:53 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2B85E6F0@standards.nortelnetworks.com>; Tue, 18 Jan 2000 12:25:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 128165 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Jan 2000 12:24:16 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EF73CA10@standards.nortelnetworks.com>; Tue, 18 Jan 2000 12:24:15 -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 JAA17256 for ; Tue, 18 Jan 2000 09:35:13 -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 JAA29237; Tue, 18 Jan 2000 09:35:12 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id JAA13000; Tue, 18 Jan 2000 09:34:45 -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: <200001181734.JAA13000@nasnfs.eng.sun.com> Date: Tue, 18 Jan 2000 09:30:41 -0800 Reply-To: pcalhoun@eng.sun.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: [MOBILE-IP] FA Assisted Hand-off I-D X-cc: pcalhoun@eng.sun.com, kempf@eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Chairs and WG, James Kempf and I submitted a draft a couple of weeks ago, which would extend Mobile IP to further reduce the latency involved in the hand-off. This seems really important given the number of threads recently that pertain to IP in cellular networks, and the need for a low latency hand-off. The question I have for the WG is whether this draft should be considered a WG work item. Thanks, PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 18 12:37: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 MAA03433 for ; Tue, 18 Jan 2000 12:37:54 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2BA4E0A0@standards.nortelnetworks.com>; Tue, 18 Jan 2000 12:25:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 128169 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Jan 2000 12:25:37 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1FE18E30@standards.nortelnetworks.com>; Tue, 18 Jan 2000 12:25:37 -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 JAA18064; Tue, 18 Jan 2000 09:36:29 -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 JAA29576; Tue, 18 Jan 2000 09:36:28 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id JAA13032; Tue, 18 Jan 2000 09:36:17 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-ID: <200001181736.JAA13032@nasnfs.eng.sun.com> Date: Tue, 18 Jan 2000 09:32:00 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] AAA functionality X-To: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit All, I really don't see this as a requirement, since it is really an implementation issue. isn't it? PatC >Hello, > >I bring in my vote for the grace period... > > >N. Asokan wrote: >> >> I think whether to allow free time or not is ultimately a policy issue. >> Seems to me that we shouldn't devise a mechanism that precludes that >> policy. > > >I agree with Asokan, Patrik and others, that allowing the grace period >is a policy issue. Furthermore, we should not forbid such liberal >policies with our protocol design! >Telcos may not like the possibility of using their network even for >short periods of time. However, telcos are certainly not the only ones >providing wireless services in the future. As someone pointed out >earlier, the pure Ip accessibility may even not be the ultimate source >for cash flows. I hope every university lab or airport lobby bar will be >able to set up its own wireless AP and start providing access to the >Internet. As the number of access provider increases, the number of >"inter-domain" handoffs may significantly increase. I really do not want >to mandate _everyone_ to disable the grace period and thus end up in >rediculous latencies and unbearable glitches in the connections. > > >Best regards, > Tom > > >-- > Tom Weckström tweckstr@cc.hut.fi > Otakaari 20 B 39 Helsinki University of Technology > 02150 Espoo Department of Computer Science From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 18 12:50: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 MAA03666 for ; Tue, 18 Jan 2000 12:50:43 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FFCAC380@standards.nortelnetworks.com>; Tue, 18 Jan 2000 12:39:02 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 128238 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Jan 2000 12:37:34 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CB332BD0@standards.nortelnetworks.com>; Tue, 18 Jan 2000 12:37: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 JAA24168; Tue, 18 Jan 2000 09:48:30 -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 JAA02233; Tue, 18 Jan 2000 09:48:29 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id JAA13359; Tue, 18 Jan 2000 09:48:15 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-ID: <200001181748.JAA13359@nasnfs.eng.sun.com> Date: Tue, 18 Jan 2000 09:44:00 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] AAA functionality X-To: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit The problem I see with the proposal below is that it assumes that the mobility entities have a pre-configured security association. In the "unnecessary and inneffient" (as you call it) proposal, the AAAH generates the keying information. If we decide to split, which MUST be optional, the process, and allow the procedures to occur serially, then the AAAH can STILL create the keying information, but it would require additional round trips over the 'net. If the we opt for parallel, then either ALL of the mobility entities have a pre-configured security association, which would rule out dynamic home agent allocation (which is a requirement), or require some third party security mechanism, such as IP security (which requires MANY round trips over the 'net). So, how is your proposal more efficient? PatC >Hi, > >My comments about the Parallel vs Sequential AAA&MIP processing: > >If we can find a way to support a parallel processing of MIP and AAA >signaling, I really support that. I think mixing MIP and AAA too much >with each other is not a a good solution. Also, encapsulation the >other's messages entirely inside other's messages seems both unnecessary >and inefficient. > >Could we define the requirements for the interfaces between the AAA >protocol and the MIP protocol to support parallel processing of these >protocols? >I think it would be possible. > >The picture I have in mind has two messaging flows, the original MIP and >the AAA. AAA flow would happen at a smaller range (inside the core) > (i.e. FA <-> AAAF <-> Broker / HA <-> AAAH <-> Broker) >while the MIP would cover all the way from MN to HA. > >Here is my proposal: >(message flows in a successfull registration) > >1. The reg.request with enough information for Autorization and >Authentication originates from the MN. > >2. The reg.req. is processed by the FA. > >3. An AAA message is send by the FA (either to AAAF or to a broker) > The FA uses the information from the MIP reg.req. to build the AAA >message. > At the same time the MIP reg.req. is forwarded to the HA. > >4. The MIP reg.req. is processed by the HA. > >5. HA answers to MN with a MIP reg.reply. >(E.g. according to MN authentication, but the user remains >unauthenticated at the moment.) > >6. Reg.reply reaches FA and MN, and MN starts using the network. > (Alternatively we might stop the reply at FA to wait for the AAA >approval, but the MN could try to access the network even without the >received reply.) > >7. An AAA message exchange happens between HA, AAAH, the Broker / AAAF, >and other AAA elements. The user is authenticated and authorized, >Acocunting begins. Finally, the FA gets the AAA approval/denial. > >8. FA sends a new reg.reply or the postponed original reg.reply or a >reg.reply with a correct denial code to the MN. > > >The interface we would need here would contain: >- FAs ability to fomulate AAA messages to AAAF (AAA module) >- HAs ----------------- " --------------- AAAH ---- " ---- >- FAs and HAs ability to understand the AAA messages and to generate >replies according to them. > > >I would claim this approach beats the sequential approach in efficiency >by far. >Your comments about possible weaknesses of this rapidly hacked >parallelism example are most welcome! > >Best regards, > Tom > > > >Patrik Flykt wrote: >> >> Hi, >> >> >Perhaps I am missing something, but I *really* don't see how the AAA >> >and Mobile-IP requests can be done in parallel. If a requirement is >> >that it must be possible to separate the two, then I would prefer to >> >see that both requests are done sequentially, first AAA then Mobile-IP. >> >This would remove many strange interactions, and would be a much cleaner >> >approach. >> >> I suppose there is a requirement that AAA and MIP messages can be separated >> (be it parallell or serial message sending). When you pay for access with >> your credit card the authorization/accounting goes to the credit card >> company's AAA server, while the Mobile IP messages go to your home agent. >> >> The sequential approach is extremely useful if the only case of using AAA >> with MIP is to ensure that the provider of the foreign agent is able to >> account for every second of foreign agent usage. However, the provider could >> also be interested in allowing a short grace period to ensure that the >> real-time applications used in the mobile node would experience the shortest >> possible service disruption. I suppose the AAA processing will take at least >> a couple of seconds and even longer when there are several brokers between >> the visited and home domains. The grace period enables of course a >> possibility of fraud, which the provider has to take into account. >> Minimizing fraud could be done for example by allowing the grace period only >> to those who have visited the same provider's network earlier and have been >> given a session key, as described in the "Minimal Latency Secure Hand-off" >> draft. There is also a third possibility when the provider is providing free >> access for everyone without any accounting but with authorization. The >> provider wants to be sure that the home AAA domain authorizes the mobile >> node, i.e. it is not stolen, in the (for some reason) wrong domain, etc. >> >> Regards, >> >> Patrik > >-- > Tom Weckström tweckstr@cc.hut.fi > Otakaari 20 B 39 Helsinki University of Technology > 02150 Espoo Department of Computer Science From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 18 17:02: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 RAA06477 for ; Tue, 18 Jan 2000 17:02:21 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1C1432B0@standards.nortelnetworks.com>; Tue, 18 Jan 2000 16:50:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 128468 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Jan 2000 16:49:18 -0500 Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.90314E00@standards.nortelnetworks.com>; Tue, 18 Jan 2000 16:39:17 -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 XAA05460; Tue, 18 Jan 2000 23:50:10 +0200 (EET) X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.3 i686) MIME-Version: 1.0 References: <200001181736.JAA13032@nasnfs.eng.sun.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <3884E034.FCB2CB5F@cc.hut.fi> Date: Tue, 18 Jan 2000 23:50:44 +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] AAA functionality X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hello, Patrice Calhoun wrote: > > All, > > I really don't see this as a requirement, since it is really an implementation > issue. isn't it? > > PatC To me, implementation issue is not the same as a policy issue. Policy based decision is more flexible. I can see two extreme scenarios: 1. We leave the grace period issue entirely as an implementation choice and future implementations fail in interops or at least fail to provide fast "session" initialization times e.g. for VoIP calls. 2. We require a possibility to allow the grace period with configuration or policy management and the future implementations are more configurable and allow faster access initialization. I do not see any possible implementational problem with this idea of allowing the grace period. One can ask, why should we not require the possibility to allow the grace period? One can _also_ ask why should we. I say we should, because the Internet access initialization would be faster that way and there would be one item less to confuse the implementors. Regards, Tom > >Hello, > > > >I bring in my vote for the grace period... > > > > > >N. Asokan wrote: > >> > >> I think whether to allow free time or not is ultimately a policy issue. > >> Seems to me that we shouldn't devise a mechanism that precludes that > >> policy. > > > > > >I agree with Asokan, Patrik and others, that allowing the grace period > >is a policy issue. Furthermore, we should not forbid such liberal > >policies with our protocol design! > >Telcos may not like the possibility of using their network even for > >short periods of time. However, telcos are certainly not the only ones > >providing wireless services in the future. As someone pointed out > >earlier, the pure Ip accessibility may even not be the ultimate source > >for cash flows. I hope every university lab or airport lobby bar will be > >able to set up its own wireless AP and start providing access to the > >Internet. As the number of access provider increases, the number of > >"inter-domain" handoffs may significantly increase. I really do not want > >to mandate _everyone_ to disable the grace period and thus end up in > >rediculous latencies and unbearable glitches in the connections. > > > > > >Best regards, > > Tom -- Tom Weckström tweckstr@cc.hut.fi From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 18 17:28: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 RAA06651 for ; Tue, 18 Jan 2000 17:28:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C11401C0@standards.nortelnetworks.com>; Tue, 18 Jan 2000 17:16:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 128519 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Jan 2000 17:14:43 -0500 Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1D4FFC20@standards.nortelnetworks.com>; Tue, 18 Jan 2000 17:04:43 -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 AAA05854; Wed, 19 Jan 2000 00:15:39 +0200 (EET) X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.3 i686) MIME-Version: 1.0 References: <200001181748.JAA13359@nasnfs.eng.sun.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <3884E62E.D29A3344@cc.hut.fi> Date: Wed, 19 Jan 2000 00:16:14 +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] AAA functionality X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hi, Patrice Calhoun wrote: > > The problem I see with the proposal below is that it assumes that the mobility > entities have a pre-configured security association. Yes, you are right. We could also make the signaling go through the HA up to the AAAH, but this would then slow down the process. What about setting this to optional, and if there was no shared secret (e.g. in dynamic HA allocation), we'd act according to the (possibly) slower mode? > In the "unnecessary and > inneffient" (as you call it) proposal, the AAAH generates the keying > information. Sorry, I did not mean to insult. I meant it seems inefficient to me. I may be wrong, but I'd like to have good justifications for why the sequential model is more efficient. If it is not, then it would be unnecessary at least for those who have a shared secret, but possibly useful for those without it. > If we decide to split, which MUST be optional, the process, > and allow the procedures to occur serially, then the AAAH can STILL create > the keying information, but it would require additional round trips over > the 'net. > > If the we opt for parallel, then either ALL of the mobility entities have a > pre-configured security association, which would rule out dynamic home agent > allocation (which is a requirement), or require some third party security > mechanism, such as IP security (which requires MANY round trips over the 'net). > So, how is your proposal more efficient? It is more efficient at least for those who have a SA with their HA, because it allows the MN to start using the 'net while the AAA process is still unfinished. Any counter arguments? It might be more efficient even for those who need a dynamics HA allocation, since also that could be separated from the registration, as follows: - Allocation of a HA in a foreign domain The idea is from Patrik Flykt. I modified the message sequencies a little bit. Letters I changed appear with asterisks: *d.* c. +----+ <---- +------+ --------> +------+ | HA | f. | FAAA | | HAAA | +----+ ----> +------+ <-------- +------+ <----- ^ | *e.* i. | |g. | | b.| | a. | V +----+ -----> +----+ | MN | *h.* | FA | +----+ <----- +----+ Explanation: - (*.d*) Is a request to the allocated HA BEFORE an ack is coming from the HAAA. Speeds up, but adds signals, if the reply from the HAAA (*e.*) is a DENIAL. - As soons as (*e.*) arrives, send it to FA in (g.). Speeds up, too. - The new (i.) Is only needed if (*e.*) was a DENIAL. - The (*h.*) is sent to the MN before the (i.) to speed up latency of the handoff handling. My observations: - The message order is radical. - The scheme is based on the assumption that HAAA normally accepts the MN. - I assume the core network and HA are fast, and sending/processing a couple of extra messages is allowed in DENIAL cases. - This should speed up the process in situations where the MN ia correctly authorized, since the HA would be dynamically allocated already when the (*e.*) arrives. - In situations where AAAH is not needed, the sequential mode and the parallel mode reduce to one and the same. Regards, Tom > > >Hi, > > > >My comments about the Parallel vs Sequential AAA&MIP processing: > > > >If we can find a way to support a parallel processing of MIP and AAA > >signaling, I really support that. I think mixing MIP and AAA too much > >with each other is not a a good solution. Also, encapsulation the > >other's messages entirely inside other's messages seems both unnecessary > >and inefficient. > > > >Could we define the requirements for the interfaces between the AAA > >protocol and the MIP protocol to support parallel processing of these > >protocols? > >I think it would be possible. > > > >The picture I have in mind has two messaging flows, the original MIP and > >the AAA. AAA flow would happen at a smaller range (inside the core) > > (i.e. FA <-> AAAF <-> Broker / HA <-> AAAH <-> Broker) > >while the MIP would cover all the way from MN to HA. > > > >Here is my proposal: > >(message flows in a successfull registration) > > > >1. The reg.request with enough information for Autorization and > >Authentication originates from the MN. > > > >2. The reg.req. is processed by the FA. > > > >3. An AAA message is send by the FA (either to AAAF or to a broker) > > The FA uses the information from the MIP reg.req. to build the AAA > >message. > > At the same time the MIP reg.req. is forwarded to the HA. > > > >4. The MIP reg.req. is processed by the HA. > > > >5. HA answers to MN with a MIP reg.reply. > >(E.g. according to MN authentication, but the user remains > >unauthenticated at the moment.) > > > >6. Reg.reply reaches FA and MN, and MN starts using the network. > > (Alternatively we might stop the reply at FA to wait for the AAA > >approval, but the MN could try to access the network even without the > >received reply.) > > > >7. An AAA message exchange happens between HA, AAAH, the Broker / AAAF, > >and other AAA elements. The user is authenticated and authorized, > >Acocunting begins. Finally, the FA gets the AAA approval/denial. > > > >8. FA sends a new reg.reply or the postponed original reg.reply or a > >reg.reply with a correct denial code to the MN. > > > > > >The interface we would need here would contain: > >- FAs ability to fomulate AAA messages to AAAF (AAA module) > >- HAs ----------------- " --------------- AAAH ---- " ---- > >- FAs and HAs ability to understand the AAA messages and to generate > >replies according to them. > > > > > >I would claim this approach beats the sequential approach in efficiency > >by far. > >Your comments about possible weaknesses of this rapidly hacked > >parallelism example are most welcome! > > > >Best regards, > > Tom > > > > > > > >Patrik Flykt wrote: > >> > >> Hi, > >> > >> >Perhaps I am missing something, but I *really* don't see how the AAA > >> >and Mobile-IP requests can be done in parallel. If a requirement is > >> >that it must be possible to separate the two, then I would prefer to > >> >see that both requests are done sequentially, first AAA then Mobile-IP. > >> >This would remove many strange interactions, and would be a much cleaner > >> >approach. > >> > >> I suppose there is a requirement that AAA and MIP messages can be separated > >> (be it parallell or serial message sending). When you pay for access with > >> your credit card the authorization/accounting goes to the credit card > >> company's AAA server, while the Mobile IP messages go to your home agent. > >> > >> The sequential approach is extremely useful if the only case of using AAA > >> with MIP is to ensure that the provider of the foreign agent is able to > >> account for every second of foreign agent usage. However, the provider could > >> also be interested in allowing a short grace period to ensure that the > >> real-time applications used in the mobile node would experience the shortest > >> possible service disruption. I suppose the AAA processing will take at least > >> a couple of seconds and even longer when there are several brokers between > >> the visited and home domains. The grace period enables of course a > >> possibility of fraud, which the provider has to take into account. > >> Minimizing fraud could be done for example by allowing the grace period only > >> to those who have visited the same provider's network earlier and have been > >> given a session key, as described in the "Minimal Latency Secure Hand-off" > >> draft. There is also a third possibility when the provider is providing free > >> access for everyone without any accounting but with authorization. The > >> provider wants to be sure that the home AAA domain authorizes the mobile > >> node, i.e. it is not stolen, in the (for some reason) wrong domain, etc. > >> > >> Regards, > >> > >> Patrik > > > >-- > > Tom Weckström tweckstr@cc.hut.fi -- Tom Weckström tweckstr@cc.hut.fi From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 18 17:28: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 RAA06653 for ; Tue, 18 Jan 2000 17:28:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C1415350@standards.nortelnetworks.com>; Tue, 18 Jan 2000 17:16:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 128534 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Jan 2000 17:16:01 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B175BF10@standards.nortelnetworks.com>; Tue, 18 Jan 2000 17:16:01 -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 OAA27039; Tue, 18 Jan 2000 14:26:53 -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 OAA16437; Tue, 18 Jan 2000 14:26:52 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id OAA20933; Tue, 18 Jan 2000 14:26:46 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-ID: <200001182226.OAA20933@nasnfs.eng.sun.com> Date: Tue, 18 Jan 2000 14:22:21 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] AAA functionality X-To: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit >Hi, > > >Patrice Calhoun wrote: >> >> The problem I see with the proposal below is that it assumes that the >mobility >> entities have a pre-configured security association. > >Yes, you are right. >We could also make the signaling go through the HA up to the AAAH, but >this would then slow down the process. The AAAH MUST somehow be contacted, in order to get some reassurances that the AAAH is willing to pay for the services rendered. The AAAF will expect to get this before it provides services. > >What about setting this to optional, and if there was no shared secret >(e.g. in dynamic HA allocation), we'd act according to the (possibly) >slower mode? hmmm... I would state that shared secrets in an inter-domain mobility network would be the rule, not the exception. It seems as if you are targetting lan mobility, and the cellular carriers that I've talked to need roaming. > > >> In the "unnecessary and >> inneffient" (as you call it) proposal, the AAAH generates the keying >> information. > >Sorry, I did not mean to insult. I meant it seems inefficient to me. I >may be wrong, but I'd like to have good justifications for why the >sequential model is more efficient. If it is not, then it would be >unnecessary at least for those who have a shared secret, but possibly >useful for those without it. It wasn't taken as an insult, but it was simply your viewpoint, not the WGs. > >> If we decide to split, which MUST be optional, the process, >> and allow the procedures to occur serially, then the AAAH can STILL create >> the keying information, but it would require additional round trips over >> the 'net. >> >> If the we opt for parallel, then either ALL of the mobility entities have a >> pre-configured security association, which would rule out dynamic home agent >> allocation (which is a requirement), or require some third party security >> mechanism, such as IP security (which requires MANY round trips over the >'net). > > >> So, how is your proposal more efficient? > >It is more efficient at least for those who have a SA with their HA, >because it allows the MN to start using the 'net while the AAA process >is still unfinished. I still haven't heard back from many carriers that state that they would provide free services. In fact, all I've heard are comments from carriers against the grace period. >Any counter arguments? Well, expecting all devices to have a pre-configured shared secret doesn't scale. What other argument do we need? Perhaps I am missing something fundamental here, but I don't see the problem. In our proposals, we aren't requiring that the AAA infrastructure process, or parse, the Registration Requests, they are considered blobs. So, how is a single internet round trip ineffient? Your proposal requires additional latency (two round trips), free services, unmanageable security relationships, and cannot support dynamic home agents. >It might be more efficient even for those who need a dynamics HA >allocation, since also that could be separated from the registration, as >follows: > >- Allocation of a HA in a foreign domain > >The idea is from Patrik Flykt. >I modified the message sequencies a little bit. >Letters I changed appear with asterisks: > > > *d.* c. > +----+ <---- +------+ --------> +------+ > | HA | f. | FAAA | | HAAA | > +----+ ----> +------+ <-------- +------+ > <----- ^ | *e.* > i. | |g. > | | > b.| | > a. | V > +----+ -----> +----+ > | MN | *h.* | FA | > +----+ <----- +----+ > >Explanation: > >- (*.d*) Is a request to the allocated HA BEFORE an ack is coming from >the HAAA. >Speeds up, but adds signals, if the reply from the HAAA (*e.*) is a >DENIAL. > >- As soons as (*e.*) arrives, send it to FA in (g.). Speeds up, too. > >- The new (i.) Is only needed if (*e.*) was a DENIAL. > >- The (*h.*) is sent to the MN before the (i.) to speed up latency of >the handoff handling. > >My observations: >- The message order is radical. >- The scheme is based on the assumption that HAAA normally accepts the >MN. and if this isn't the case, then free service is a problem. >- I assume the core network and HA are fast, and sending/processing a >couple of extra messages is allowed in DENIAL cases. >- This should speed up the process in situations where the MN ia >correctly authorized, since the HA would be dynamically allocated >already when the (*e.*) arrives. How did you select the home agent. How do you know if the home agent needs to be allocated in the local, or the foreign domain? This information would come from the AAAH. >- In situations where AAAH is not needed, the sequential mode and the >parallel mode reduce to one and the same. so how do you support dynamic home agent (local or foreign) when using a parallel approach? Perhaps I missed it, but I don't see it. PatC > > >Regards, > Tom > > >> >> >Hi, >> > >> >My comments about the Parallel vs Sequential AAA&MIP processing: >> > >> >If we can find a way to support a parallel processing of MIP and AAA >> >signaling, I really support that. I think mixing MIP and AAA too much >> >with each other is not a a good solution. Also, encapsulation the >> >other's messages entirely inside other's messages seems both unnecessary >> >and inefficient. >> > >> >Could we define the requirements for the interfaces between the AAA >> >protocol and the MIP protocol to support parallel processing of these >> >protocols? >> >I think it would be possible. >> > >> >The picture I have in mind has two messaging flows, the original MIP and >> >the AAA. AAA flow would happen at a smaller range (inside the core) >> > (i.e. FA <-> AAAF <-> Broker / HA <-> AAAH <-> Broker) >> >while the MIP would cover all the way from MN to HA. >> > >> >Here is my proposal: >> >(message flows in a successfull registration) >> > >> >1. The reg.request with enough information for Autorization and >> >Authentication originates from the MN. >> > >> >2. The reg.req. is processed by the FA. >> > >> >3. An AAA message is send by the FA (either to AAAF or to a broker) >> > The FA uses the information from the MIP reg.req. to build the AAA >> >message. >> > At the same time the MIP reg.req. is forwarded to the HA. >> > >> >4. The MIP reg.req. is processed by the HA. >> > >> >5. HA answers to MN with a MIP reg.reply. >> >(E.g. according to MN authentication, but the user remains >> >unauthenticated at the moment.) >> > >> >6. Reg.reply reaches FA and MN, and MN starts using the network. >> > (Alternatively we might stop the reply at FA to wait for the AAA >> >approval, but the MN could try to access the network even without the >> >received reply.) >> > >> >7. An AAA message exchange happens between HA, AAAH, the Broker / AAAF, >> >and other AAA elements. The user is authenticated and authorized, >> >Acocunting begins. Finally, the FA gets the AAA approval/denial. >> > >> >8. FA sends a new reg.reply or the postponed original reg.reply or a >> >reg.reply with a correct denial code to the MN. >> > >> > >> >The interface we would need here would contain: >> >- FAs ability to fomulate AAA messages to AAAF (AAA module) >> >- HAs ----------------- " --------------- AAAH ---- " ---- >> >- FAs and HAs ability to understand the AAA messages and to generate >> >replies according to them. >> > >> > >> >I would claim this approach beats the sequential approach in efficiency >> >by far. >> >Your comments about possible weaknesses of this rapidly hacked >> >parallelism example are most welcome! >> > >> >Best regards, >> > Tom >> > >> > >> > >> >Patrik Flykt wrote: >> >> >> >> Hi, >> >> >> >> >Perhaps I am missing something, but I *really* don't see how the AAA >> >> >and Mobile-IP requests can be done in parallel. If a requirement is >> >> >that it must be possible to separate the two, then I would prefer to >> >> >see that both requests are done sequentially, first AAA then Mobile-IP. >> >> >This would remove many strange interactions, and would be a much cleaner >> >> >approach. >> >> >> >> I suppose there is a requirement that AAA and MIP messages can be >separated >> >> (be it parallell or serial message sending). When you pay for access with >> >> your credit card the authorization/accounting goes to the credit card >> >> company's AAA server, while the Mobile IP messages go to your home agent. >> >> >> >> The sequential approach is extremely useful if the only case of using AAA >> >> with MIP is to ensure that the provider of the foreign agent is able to >> >> account for every second of foreign agent usage. However, the provider >could >> >> also be interested in allowing a short grace period to ensure that the >> >> real-time applications used in the mobile node would experience the >shortest >> >> possible service disruption. I suppose the AAA processing will take at >least >> >> a couple of seconds and even longer when there are several brokers between >> >> the visited and home domains. The grace period enables of course a >> >> possibility of fraud, which the provider has to take into account. >> >> Minimizing fraud could be done for example by allowing the grace period >only >> >> to those who have visited the same provider's network earlier and have >been >> >> given a session key, as described in the "Minimal Latency Secure Hand-off" >> >> draft. There is also a third possibility when the provider is providing >free >> >> access for everyone without any accounting but with authorization. The >> >> provider wants to be sure that the home AAA domain authorizes the mobile >> >> node, i.e. it is not stolen, in the (for some reason) wrong domain, etc. >> >> >> >> Regards, >> >> >> >> Patrik >> > >> >-- >> > Tom Weckström tweckstr@cc.hut.fi > >-- > Tom Weckström tweckstr@cc.hut.fi From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 18 18:51: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 SAA07626 for ; Tue, 18 Jan 2000 18:51:35 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.60A74A70@standards.nortelnetworks.com>; Tue, 18 Jan 2000 18:39:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 128681 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Jan 2000 18:38:31 -0500 Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D1EADFF0@standards.nortelnetworks.com>; Tue, 18 Jan 2000 18:28:30 -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 BAA06768; Wed, 19 Jan 2000 01:39:25 +0200 (EET) X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.3 i686) MIME-Version: 1.0 References: <200001182226.OAA20933@nasnfs.eng.sun.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <3884F9D0.1A2F8824@cc.hut.fi> Date: Wed, 19 Jan 2000 01:40:00 +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] AAA functionality X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Patrice Calhoun wrote: > >Patrice Calhoun wrote: > >> > >> The problem I see with the proposal below is that it assumes that the > >mobility > >> entities have a pre-configured security association. > > > >Yes, you are right. > >We could also make the signaling go through the HA up to the AAAH, but > >this would then slow down the process. > > The AAAH MUST somehow be contacted, in order to get some reassurances that > the AAAH is willing to pay for the services rendered. The AAAF will expect > to get this before it provides services. This is the point. You say the AAAF needs the info before, and some others say it should be a policy issue whether the AAA authentication reply should come from the AAAH before the access is granted. Let's vote. What do other people think about this grace period issue? We already have some opinions, but I'd like to see some more. > >What about setting this to optional, and if there was no shared secret > >(e.g. in dynamic HA allocation), we'd act according to the (possibly) > >slower mode? > > hmmm... I would state that shared secrets in an inter-domain mobility network > would be the rule, not the exception. It seems as if you are targetting > lan mobility, and the cellular carriers that I've talked to need roaming. I did not target to any specific mobility scheme. It may be that the cellular carriers need the dynamic HA allocation more to get rid of configuration tasks. o If we have a shared secret between HA and MN and we use a static HA, then the parallel mode works well, right? This might be the situation for corporate roaming workforce. o If we have a dynamic HA allocation, then we'd have to get the decision from the AAAH first, as you said. I did not take into account that also the Home Network might want to assign the HA dynamically. > >> So, how is your proposal more efficient? > > > >It is more efficient at least for those who have a SA with their HA, > >because it allows the MN to start using the 'net while the AAA process > >is still unfinished. > > I still haven't heard back from many carriers that state that they would provide > free services. In fact, all I've heard are comments from carriers against > the grace period. Hmm. Visit Finland some time. Telia just starts providing Internet access for free, and there has been a smaller operator called NIC that has done that for a longer time. :-) Also professor Arto Karila from HUT stated last summer that it will be most probable that there will be much more free access providers by the end of the year here in Finland. The story is available in Finnish at: http://www.wow.fi/WOW/17332438005461012486069354?path=tietotekniikka/juttu&document_id=125418 > >Any counter arguments? > > Well, expecting all devices to have a pre-configured shared secret doesn't > scale. All the devices meaning all the Mobile Nodes and their HAs. Well, that can be a one time issue like the similar actions for a cellular phone. Also the phones have their HLR and it does not bring too much scalability problems, does it? ;) > What other argument do we need? Perhaps I am missing something fundamental > here, but I don't see the problem. In our proposals, we aren't requiring that > the AAA infrastructure process, or parse, the Registration Requests, they are > considered blobs. So, how is a single internet round trip ineffient? Your > proposal requires additional latency (two round trips), free services, > unmanageable security relationships, and cannot support dynamic home agents. The problem is the AAA processing time and the most probably longer round trip time through the path of AAA servers, proxies, brokers, ets. than through plain Internet (direct FA <--> HA). I admit that the sequential proposal has less messages. The overhead the parallel mode would bring is the couple of octets in the additional headers plus some processing time in the routers. Then again, the sequential mode packets might get fragmented due to their possibly large size thus ending up to almost the same amount of transferred data and used router processor time... The key question is: "How we measure efficiency" with: - Number of messages - Latency for the session initialization - Handoff latency - Administratvie burden - Accuracy of billing - Amount of sent data I can see there some contradictory elements. That is why I am for a definition that allows both modes. > >It might be more efficient even for those who need a dynamics HA > >allocation, since also that could be separated from the registration, as > >follows: > > > >- Allocation of a HA in a foreign domain > > > >The idea is from Patrik Flykt. > >I modified the message sequencies a little bit. > >Letters I changed appear with asterisks: > > > > > > *d.* c. > > +----+ <---- +------+ --------> +------+ > > | HA | f. | FAAA | | HAAA | > > +----+ ----> +------+ <-------- +------+ > > <----- ^ | *e.* > > i. | |g. > > | | > > b.| | > > a. | V > > +----+ -----> +----+ > > | MN | *h.* | FA | > > +----+ <----- +----+ > > > >Explanation: > > > >- (*.d*) Is a request to the allocated HA BEFORE an ack is coming from > >the HAAA. > >Speeds up, but adds signals, if the reply from the HAAA (*e.*) is a > >DENIAL. > > > >- As soons as (*e.*) arrives, send it to FA in (g.). Speeds up, too. > > > >- The new (i.) Is only needed if (*e.*) was a DENIAL. > > > >- The (*h.*) is sent to the MN before the (i.) to speed up latency of > >the handoff handling. > > > >My observations: > >- The message order is radical. > >- The scheme is based on the assumption that HAAA normally accepts the > >MN. > > and if this isn't the case, then free service is a problem. If the free service really IS a problem. And additional countermeasures may be started in a case of misuse. Of course, this would need some elaborate software which would make the solution slightly more complex. But what wouldn't one do for a faster access. ;) Regards, Tom -- Tom Weckström tweckstr@cc.hut.fi From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 18 19:00: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 TAA07727 for ; Tue, 18 Jan 2000 19:00:22 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A4BC39E0@standards.nortelnetworks.com>; Tue, 18 Jan 2000 18:48:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 128745 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Jan 2000 18:47:05 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6A254B50@standards.nortelnetworks.com>; Tue, 18 Jan 2000 18:47:05 -0500 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA04820; Tue, 18 Jan 2000 15:58:02 -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 PAA21963; Tue, 18 Jan 2000 15:58:01 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id PAA23509; Tue, 18 Jan 2000 15:57:46 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-ID: <200001182357.PAA23509@nasnfs.eng.sun.com> Date: Tue, 18 Jan 2000 15:53:27 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] AAA functionality X-To: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit >Patrice Calhoun wrote: > >> >Patrice Calhoun wrote: >> >> >> >> The problem I see with the proposal below is that it assumes that the >> >mobility >> >> entities have a pre-configured security association. >> > >> >Yes, you are right. >> >We could also make the signaling go through the HA up to the AAAH, but >> >this would then slow down the process. >> >> The AAAH MUST somehow be contacted, in order to get some reassurances that >> the AAAH is willing to pay for the services rendered. The AAAF will expect >> to get this before it provides services. > >This is the point. You say the AAAF needs the info before, and some >others say it should be a policy issue whether the AAA authentication >reply should come from the AAAH before the access is granted. > >Let's vote. What do other people think about this grace period issue? We >already have some opinions, but I'd like to see some more. ok. I assume you already know what my vote would sound like? :) > > >> >What about setting this to optional, and if there was no shared secret >> >(e.g. in dynamic HA allocation), we'd act according to the (possibly) >> >slower mode? >> >> hmmm... I would state that shared secrets in an inter-domain mobility network >> would be the rule, not the exception. It seems as if you are targetting >> lan mobility, and the cellular carriers that I've talked to need roaming. > >I did not target to any specific mobility scheme. It may be that the >cellular carriers need the dynamic HA allocation more to get rid of >configuration tasks. > >o If we have a shared secret between HA and MN and we use a static HA, >then the parallel mode works well, right? This might be the situation >for corporate roaming workforce. I would assume that most corporate networks would be reluctant to provide access to a mobile without prior authentication. I know that my company's MIS (IT) is quite strict about security. Perhaps some networks are more lax in their security requirements. > >o If we have a dynamic HA allocation, then we'd have to get the decision >from the AAAH first, as you said. I did not take into account that also >the Home Network might want to assign the HA dynamically. ok. > >> >> So, how is your proposal more efficient? >> > >> >It is more efficient at least for those who have a SA with their HA, >> >because it allows the MN to start using the 'net while the AAA process >> >is still unfinished. >> >> I still haven't heard back from many carriers that state that they would >provide >> free services. In fact, all I've heard are comments from carriers against >> the grace period. > >Hmm. Visit Finland some time. Telia just starts providing Internet >access for free, and there has been a smaller operator called NIC that >has done that for a longer time. :-) >Also professor Arto Karila from HUT stated last summer that it will be >most probable that there will be much more free access providers by the >end of the year here in Finland. >The story is available in Finnish at: >http://www.wow.fi/WOW/17332438005461012486069354?path=tietotekniikka/juttu&document_id=125418 Perhaps finland is a special case. I wish that we had free access here in the US :) > > >> >Any counter arguments? >> >> Well, expecting all devices to have a pre-configured shared secret doesn't >> scale. > >All the devices meaning all the Mobile Nodes and their HAs. Well, that >can be a one time issue like the similar actions for a cellular phone. >Also the phones have their HLR and it does not bring too much >scalability problems, does it? ;) well, we aren't designing the system around HLR and VLRs, right? Since we KNOW that this will be run over the Internet, some security is required between the FA (VLR) and the HA (HLR). Further, some security is required between the MN (MS) and the FA. The scalability problem doesn't come from the MN-HA, but rather from the MN-FA and the FA-HA. This is especially problematic in an inter-domain network. > > >> What other argument do we need? Perhaps I am missing something fundamental >> here, but I don't see the problem. In our proposals, we aren't requiring that >> the AAA infrastructure process, or parse, the Registration Requests, they are >> considered blobs. So, how is a single internet round trip ineffient? Your >> proposal requires additional latency (two round trips), free services, >> unmanageable security relationships, and cannot support dynamic home agents. > >The problem is the AAA processing time and the most probably longer >round trip time through the path of AAA servers, proxies, brokers, ets. >than through plain Internet (direct FA <--> HA). Well, given that this typically ONLY occurs when then MS is turned on, I fail to see the problem. One could easily argue that the processing power on the AAA servers could be such that the Internet bandwidth becomes the issue, and here more traversals over the 'net would be a problem. > >I admit that the sequential proposal has less messages. The overhead the >parallel mode would bring is the couple of octets in the additional >headers plus some processing time in the routers. Then again, the >sequential mode packets might get fragmented due to their possibly large >size thus ending up to almost the same amount of transferred data and >used router processor time... I think this is a red herring. The number of registration requests that will result in a check with the AAA infrastructure is so low that I have a hard time accepting that as a counter-argument. To date, I have never seen a registration request exceed 800 bytes, even with all of the fluff that we've been adding to Mobile IP recently. Furthermore, the more messages there are on the internet, the higher the possiblity for packet drops, and the need for retransmission. > >The key question is: "How we measure efficiency" >with: > - Number of messages > - Latency for the session initialization > - Handoff latency > - Administratvie burden > - Accuracy of billing > - Amount of sent data > > >I can see there some contradictory elements. That is why I am for a >definition that allows both modes. I won't argue in supporting both, but I am not sure how popular the parallel method will be. Also, the more we support, the more code I need to write, and some people may have issues with that. > >> >It might be more efficient even for those who need a dynamics HA >> >allocation, since also that could be separated from the registration, as >> >follows: >> > >> >- Allocation of a HA in a foreign domain >> > >> >The idea is from Patrik Flykt. >> >I modified the message sequencies a little bit. >> >Letters I changed appear with asterisks: >> > >> > >> > *d.* c. >> > +----+ <---- +------+ --------> +------+ >> > | HA | f. | FAAA | | HAAA | >> > +----+ ----> +------+ <-------- +------+ >> > <----- ^ | *e.* >> > i. | |g. >> > | | >> > b.| | >> > a. | V >> > +----+ -----> +----+ >> > | MN | *h.* | FA | >> > +----+ <----- +----+ >> > >> >Explanation: >> > >> >- (*.d*) Is a request to the allocated HA BEFORE an ack is coming from >> >the HAAA. >> >Speeds up, but adds signals, if the reply from the HAAA (*e.*) is a >> >DENIAL. >> > >> >- As soons as (*e.*) arrives, send it to FA in (g.). Speeds up, too. >> > >> >- The new (i.) Is only needed if (*e.*) was a DENIAL. >> > >> >- The (*h.*) is sent to the MN before the (i.) to speed up latency of >> >the handoff handling. >> > >> >My observations: >> >- The message order is radical. >> >- The scheme is based on the assumption that HAAA normally accepts the >> >MN. >> >> and if this isn't the case, then free service is a problem. > >If the free service really IS a problem. And additional countermeasures >may be started in a case of misuse. Of course, this would need some >elaborate software which would make the solution slightly more complex. >But what wouldn't one do for a faster access. ;) Just to re-iterate (and make sure that we agree), the AAA involvement is ONLY performed when the MN is started. The AAA infrastructure is also checked when keys expire, but this can be done sufficiently in advance as to not affect access. PatC > > >Regards, > Tom > >-- > Tom Weckström tweckstr@cc.hut.fi From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 19 01:49: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 BAA15386 for ; Wed, 19 Jan 2000 01:49:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AD2C2BB0@standards.nortelnetworks.com>; Wed, 19 Jan 2000 1:36:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 128931 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jan 2000 01:35:56 -0500 Received: from dumburken.it.kth.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.87D12EB0@standards.nortelnetworks.com>; Wed, 19 Jan 2000 1:35:56 -0500 Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id HAA05947; Wed, 19 Jan 2000 07:46:53 +0100 (MET) X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f References: <200001182357.PAA23509@nasnfs.eng.sun.com> Message-ID: <200001190646.HAA05947@dumburken.it.kth.se> Date: Wed, 19 Jan 2000 07:46:53 +0100 Reply-To: Gerald Maguire Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gerald Maguire Subject: Re: [MOBILE-IP] AAA functionality X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200001182357.PAA23509@nasnfs.eng.sun.com> (message from Patrice Calhoun on Tue, 18 Jan 2000 15:53:27 -0800) >Hmm. Visit Finland some time. Telia just starts providing Internet >access for free, and there has been a smaller operator called NIC that >has done that for a longer time. :-) >Also professor Arto Karila from HUT stated last summer that it will be >most probable that there will be much more free access providers by the >end of the year here in Finland. >The story is available in Finnish at: >http://www.wow.fi/WOW/17332438005461012486069354?path=tietotekniikka/juttu&document_id=125418 Perhaps finland is a special case. I wish that we had free access here in the US :) I think access providers are finding that with bandwidth costing less and less, with increasing numbers of hot spots (which are paid for by the users regularily in these sites -- generally for a contracted price), ... that doing the accounting/billing/... to squeeze every last $/SEK/FIM/... out of users is not good economics. a. Consider that the transit systems in a number of cities don't have turnstiles -- but rather have patrols which spot check that the riders have paid. The operator saves all the capital costs of the turnstiles, the maintenance personnel required to keep them working, the lost revenue when they don't work properly, ... -- and trades this off for some lost revenue due to people riding who did not pay. b. Consider that most major credit card companies have a certain fraction of fraudulant transactions. They have learned that it is not economical to decrease this below a certain rate (as the costs to do so is greater than the loss of not doing so). In the case of cellular, Telia offers large customers the ability to have a site specific GSM service for which the customer pays a flat price per user. Thus there is no per call billing for all calls from these users in this specific area. The operator can easily calculated what the contract price for an N year period should be to provide this service for Y users. The customer periodically tells the operator who these Y users are to be. The result is wireless voice access for less cost (for the N years) that putting up a campus based cordless phone system. As Tom righly points out: the penalty for not allowing the grace period is a reduction in performance of the handover -- even for those who are paying! Chip From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 19 04:54: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 EAA25117 for ; Wed, 19 Jan 2000 04:54:51 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AC5DB950@standards.nortelnetworks.com>; Wed, 19 Jan 2000 4:43:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 128995 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jan 2000 04:41:42 -0500 Received: from nc3a.nato.int (192.41.140.186) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7B27C330@standards.nortelnetworks.com>; Wed, 19 Jan 2000 4:41:41 -0500 Received: from comsun21.nc3a.nato.int (comsun21.nc3a.nato.int [192.150.94.60]) by nc3a.nato.int (8.9.0/8.9.0) with ESMTP id KAA19170; Wed, 19 Jan 2000 10:48:22 +0100 (MET) Received: from comsun21 (comsun21 [192.150.94.60]) by comsun21.nc3a.nato.int (8.9.1b+Sun/8.9.1) with SMTP id KAA01291; Wed, 19 Jan 2000 10:52:17 +0100 (MET) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: WRwGbcWXGKq7rZ9LWtQiEg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc Message-ID: <200001190952.KAA01291@comsun21.nc3a.nato.int> Date: Wed, 19 Jan 2000 10:52:17 +0100 Reply-To: Rob Goode Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Rob Goode Subject: [MOBILE-IP] mobile-router mailing list? X-cc: Rob.Goode@nc3a.nato.int, qa3445@email.mot.com, bpatil@nortelnetworks.com, eit@nc3a.nato.int To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Dear Ron, good morning and how are you? I sent out a message about some work I was doing to the Mobile IP mailing list on mobile routers yesterday and received a reply from about fifteen people who are interested in this topic. I feel that it would be helpful to have a mailing list to discuss issues connected with mobile routers and implementation issues, and that probably the Mobile IP mailing list is not the right forum as this is a topic for a subset of members rather than being of interest to all. As Nortel are hosting the Mobile IP mailing list I am asking you whether you would also host a mobile-routers mailing list for discussion of mobile router issues. Please could you give me a yes/no quite soon as otherwise I will set up an egroups mailing list - I wish to strike whilst the iron is hot, as one might say. Cheers, Rob Goode NC3A-NL From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 19 05:07: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 FAA25216 for ; Wed, 19 Jan 2000 05:07:44 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7F4DB440@standards.nortelnetworks.com>; Wed, 19 Jan 2000 4:56:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 129041 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jan 2000 04:54:15 -0500 Received: from nc3a.nato.int (192.41.140.186) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3C3AD610@standards.nortelnetworks.com>; Wed, 19 Jan 2000 4:54:15 -0500 Received: from comsun21.nc3a.nato.int (comsun21.nc3a.nato.int [192.150.94.60]) by nc3a.nato.int (8.9.0/8.9.0) with ESMTP id LAA19303 for ; Wed, 19 Jan 2000 11:01:11 +0100 (MET) Received: from comsun21 (comsun21 [192.150.94.60]) by comsun21.nc3a.nato.int (8.9.1b+Sun/8.9.1) with SMTP id LAA01321 for ; Wed, 19 Jan 2000 11:05:06 +0100 (MET) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: qJO5IEGc5wIbL88mjG/h2w== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc Message-ID: <200001191005.LAA01321@comsun21.nc3a.nato.int> Date: Wed, 19 Jan 2000 11:05:06 +0100 Reply-To: Rob Goode Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Rob Goode Subject: Re: [MOBILE-IP] mobile-router mailing list? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Dear all mailing list members, sorry for sending that last message to the mailing list, I forgot to check the TO: field. I meant to send it to Ron and not the mailing list. Please ignore it. Rob Goode From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 19 10:38: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 KAA00836 for ; Wed, 19 Jan 2000 10:38:42 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AD9FD570@standards.nortelnetworks.com>; Wed, 19 Jan 2000 10:26:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 129391 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jan 2000 10:25:20 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7CB87480@standards.nortelnetworks.com>; Wed, 19 Jan 2000 10:25:20 -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 IAA01194 for ; Wed, 19 Jan 2000 08:36:21 -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 HAA06985; Wed, 19 Jan 2000 07:36:20 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id HAA09881; Wed, 19 Jan 2000 07:35:52 -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: <200001191535.HAA09881@nasnfs.eng.sun.com> Date: Wed, 19 Jan 2000 07:31:42 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] AAA functionality X-To: Gerald Maguire To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit > >Hmm. Visit Finland some time. Telia just starts providing Internet > >access for free, and there has been a smaller operator called NIC that > >has done that for a longer time. :-) > >Also professor Arto Karila from HUT stated last summer that it will be > >most probable that there will be much more free access providers by the > >end of the year here in Finland. > >The story is available in Finnish at: > >>http://www.wow.fi/WOW/17332438005461012486069354?path=tietotekniikka/juttu&document_id=125418 > > Perhaps finland is a special case. I wish that we had free access here in >the > US :) > >I think access providers are finding that with bandwidth costing less >and less, with increasing numbers of hot spots (which are paid for by >the users regularily in these sites -- generally for a contracted >price), ... that doing the accounting/billing/... to squeeze every >last $/SEK/FIM/... out of users is not good economics. > > a. Consider that the transit systems in a number of cities don't > have turnstiles -- but rather have patrols which spot check that the > riders have paid. The operator saves all the capital costs of the > turnstiles, the maintenance personnel required to keep them working, > the lost revenue when they don't work properly, ... -- and trades this > off for some lost revenue due to people riding who did not pay. > > b. Consider that most major credit card companies have a certain > fraction of fraudulant transactions. They have learned that it is > not economical to decrease this below a certain rate (as the costs > to do so is greater than the loss of not doing so). > >In the case of cellular, Telia offers large customers the ability to >have a site specific GSM service for which the customer pays a flat >price per user. Thus there is no per call billing for all calls from >these users in this specific area. The operator can easily calculated >what the contract price for an N year period should be to provide this >service for Y users. The customer periodically tells the operator who >these Y users are to be. The result is wireless voice access for less >cost (for the N years) that putting up a campus based cordless phone >system. > >As Tom righly points out: the penalty for not allowing the grace period >is a reduction in performance of the handover -- even for those who >are paying! This is where I am missing something. The *serial* and combined proposals do not necessarily require that the AAA infrastructure. In fact, unless an inter-domain hand-off is done, the AAA infrastructure is only contacted when the keys are about to expire, and this can be arranged as to not interfere with a hand-off. So, what is your point? PatC > >Chip From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 19 12:31: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 MAA02436 for ; Wed, 19 Jan 2000 12:31:16 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.365F2AA0@standards.nortelnetworks.com>; Wed, 19 Jan 2000 12:17:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 129531 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jan 2000 12:17:14 -0500 Received: from dumburken.it.kth.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1E87A6A0@standards.nortelnetworks.com>; Wed, 19 Jan 2000 12:17:14 -0500 Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id SAA07182; Wed, 19 Jan 2000 18:28:12 +0100 (MET) X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f References: <200001191535.HAA09881@nasnfs.eng.sun.com> Message-ID: <200001191728.SAA07182@dumburken.it.kth.se> Date: Wed, 19 Jan 2000 18:28:12 +0100 Reply-To: Gerald Maguire Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gerald Maguire Subject: Re: [MOBILE-IP] AAA functionality X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200001191535.HAA09881@nasnfs.eng.sun.com> (message from Patrice Calhoun on Wed, 19 Jan 2000 07:31:42 -0800) With lots of local cells operated by/for the specific location/organization - there will be lots of inter-domain handoffs. Just think of what happens when I walk down the street in Kista where every building has a wireless LAN, but every other building is a different domain - most would probably be willing to take my traffic IFF when they walk into/by my building I will do the same. But as these are different domains the AAA mechanism will be invoked for each handoff. Chip From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 19 14:08: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 OAA03700 for ; Wed, 19 Jan 2000 14:08:17 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F3938640@standards.nortelnetworks.com>; Wed, 19 Jan 2000 13:56:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 129661 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jan 2000 13:55:21 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D3B4CD70@standards.nortelnetworks.com>; Wed, 19 Jan 2000 13:55:21 -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 MAA02120; Wed, 19 Jan 2000 12:06:21 -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 LAA16800; Wed, 19 Jan 2000 11:06:20 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id LAA15220; Wed, 19 Jan 2000 11:06:13 -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: <200001191906.LAA15220@nasnfs.eng.sun.com> Date: Wed, 19 Jan 2000 11:01:41 -0800 Reply-To: pcalhoun@eng.sun.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: [MOBILE-IP] 2nd notice for bake-off participation X-To: diameter@ipass.com X-cc: pcalhoun@eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit All, This is the second request for anyone interested in the next Mobile IP and DIAMETER bake-off. Note that you do not need both to participate. This time around, the bake-off is held at the connect-a-thon, which is must better organized than the previous bake-off. More information can be found at www.connectathon.org. As previous discussed, the Mobile IP tests will include: - Mobile IP v4 (bis) - mobile IP challenge/Response Extension - Mobile IP NAI extension - Vendor Specific extension - Mobile IP Extensions Rationalization (MIER) - MN AAA Keys (which is about to be a WG work item) As for DIAMETER, the following will be tested: - Base Protocol - Accounting Extension - Mobile IP Extension - Strong Security Of course, each implementation does not have to have all of the above in order to participate. Ideally, if we have at least two of each of the above, we could get the WG draft moving along quicker. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 19 15:52: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 PAA05055 for ; Wed, 19 Jan 2000 15:52:48 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ED29BA80@standards.nortelnetworks.com>; Wed, 19 Jan 2000 15:50:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0121 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jan 2000 15:49:34 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C7F72D10@standards.nortelnetworks.com>; Wed, 19 Jan 2000 15:49:33 -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 NAA28447; Wed, 19 Jan 2000 13:50:58 -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 MAA09611; Wed, 19 Jan 2000 12:50:57 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (centralapp.Central.Sun.COM [129.147.34.61]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id MAA18057; Wed, 19 Jan 2000 12:50:50 -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: <200001192050.MAA18057@nasnfs.eng.sun.com> Date: Wed, 19 Jan 2000 12:46:16 -0800 Reply-To: pcalhoun@eng.sun.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] (diameter) 2nd notice for bake-off participation X-To: Diameter Working Group To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Seems as if I forgot reverse tunneling in the list of Mobile IP tests. PatC >All, > >This is the second request for anyone interested in the next Mobile IP and >DIAMETER bake-off. Note that you do not need both to participate. This time >around, the bake-off is held at the connect-a-thon, which is must better >organized than the previous bake-off. More information can be found at >www.connectathon.org. > >As previous discussed, the Mobile IP tests will include: > - Mobile IP v4 (bis) > - mobile IP challenge/Response Extension > - Mobile IP NAI extension > - Vendor Specific extension > - Mobile IP Extensions Rationalization (MIER) > - MN AAA Keys (which is about to be a WG work item) > >As for DIAMETER, the following will be tested: > - Base Protocol > - Accounting Extension > - Mobile IP Extension > - Strong Security > >Of course, each implementation does not have to have all of the above >in order to participate. Ideally, if we have at least two of each of the >above, we could get the WG draft moving along quicker. > >PatC > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 19 20:42: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 UAA07268 for ; Wed, 19 Jan 2000 20: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.582CDF60@standards.nortelnetworks.com>; Wed, 19 Jan 2000 20:39:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0379 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jan 2000 20:38:27 -0500 Received: from raptor.access.net.id by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.220272B0@standards.nortelnetworks.com>; Wed, 19 Jan 2000 20:38:24 -0500 Received: from ts-tap (pteredon97.access.net.id [202.180.8.97]) by raptor.access.net.id (8.9.3/8.9.3) with SMTP id IAA00983; Thu, 20 Jan 2000 08:41:00 +0700 X-Sender: teddyap@pop3.access.net.id 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.20000120083559.00d2ee90@pop3.access.net.id> Date: Thu, 20 Jan 2000 08:35:59 +0700 Reply-To: Teddy A Purwadi Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Teddy A Purwadi Subject: Re: [MOBILE-IP] mobile-router mailing list? X-To: Rob Goode To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200001191005.LAA01321@comsun21.nc3a.nato.int> At 11:05 19/01/00 +0100, Rob Goode wrote: >Dear all mailing list members, > >sorry for sending that last message to the mailing list, >I forgot to check the TO: field. I meant to send it to >Ron and not the mailing list. Please ignore it. > >Rob Goode > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 20 07:10: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 HAA25395 for ; Thu, 20 Jan 2000 07:10:23 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C8E06C70@standards.nortelnetworks.com>; Thu, 20 Jan 2000 7:05:51 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0867 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jan 2000 07:05:40 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5CA79C00@standards.nortelnetworks.com>; Thu, 20 Jan 2000 6:55:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24869; Thu, 20 Jan 2000 06:57:06 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200001201157.GAA24869@ietf.org> Date: Thu, 20 Jan 2000 06:57:05 -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-3gwireless-ext-02.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 Based Micro Mobility Management Protocol in The Third Generation Wireless Network Author(s) : Y. Xu, R. Bhalla et.al Filename : draft-ietf-mobileip-3gwireless-ext-02.txt Pages : 15 Date : 19-Jan-00 This document defines extensions to the Mobile IP protocol [1] to allow mobility management for the interface between a radio network and a packet data network in the third generation cdma2000 network. Mobile IP requires link layer connectivity between the Mobile Node and the Foreign Agent. This draft proposes a protocol for achieving this when the physical layer terminating at a point distant from the FA. In particular, this protocol applies to cdma2000 networks where the physical layer terminates at a Radio Network Node (RNN) and the FA resides inside a separate Packet Data Serving Node (PDSN). The PDSN is responsible for establishing, maintaining, and terminating the link layer to the Mobile Node. A RNN is responsible for relaying the link layer protocol between a Mobile Node and its corresponding PDSN. The interface between the RNN and the PDSN is called the RP interface. This interface requires mobility management for handling handoff from one RNN to another without interrupting end to end communication. It also requires the support of the link layer protocol encapsulation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-3gwireless-ext-02.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-3gwireless-ext-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-3gwireless-ext-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000119140447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-3gwireless-ext-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-3gwireless-ext-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000119140447.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 20 07:10: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 HAA25397 for ; Thu, 20 Jan 2000 07:10:24 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.10A9A6C0@standards.nortelnetworks.com>; Thu, 20 Jan 2000 7:07:51 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0868 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jan 2000 07:06:13 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.70BBFD80@standards.nortelnetworks.com>; Thu, 20 Jan 2000 6:56:13 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24886; Thu, 20 Jan 2000 06:57:39 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200001201157.GAA24886@ietf.org> Date: Thu, 20 Jan 2000 06:57:39 -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-vendor-ext-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 Vendor/Organization-Specific Extensions Author(s) : G. Dommety, K. Leung Filename : draft-ietf-mobileip-vendor-ext-09.txt Pages : 4 Date : 19-Jan-00 This document proposes two new extensions to Mobile IP [1]. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-vendor-ext-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-vendor-ext-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-vendor-ext-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: <20000119140509.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-vendor-ext-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-vendor-ext-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000119140509.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 20 07:14: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 HAA25549 for ; Thu, 20 Jan 2000 07:14:52 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.58B36C80@standards.nortelnetworks.com>; Thu, 20 Jan 2000 7:09:52 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0869 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jan 2000 07:08:42 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C903A150@standards.nortelnetworks.com>; Thu, 20 Jan 2000 6:58:41 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25200; Thu, 20 Jan 2000 07:00:07 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200001201200.HAA25200@ietf.org> Date: Thu, 20 Jan 2000 07:00: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-mier-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 : Mobile IP Extensions Rationalization (MIER) Author(s) : M. Khalil, R. Narayanan, H. Akhtar, E. Qaddoura Filename : draft-ietf-mobileip-mier-01.txt Pages : 8 Date : 19-Jan-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-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-mier-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-mier-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: <20000119140459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-mier-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-mier-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000119140459.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 20 14:45: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 OAA13388 for ; Thu, 20 Jan 2000 14: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.BB00D5A0@standards.nortelnetworks.com>; Thu, 20 Jan 2000 14:43:35 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1366 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jan 2000 14:42:17 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8C2D3980@standards.nortelnetworks.com>; Thu, 20 Jan 2000 14:42:16 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 20 Jan 2000 13:43:05 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Thu, 20 Jan 2000 14:42:54 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 20 Jan 2000 13:42:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF637E.8837997C" Message-ID: Date: Thu, 20 Jan 2000 13:42:42 -0600 Reply-To: Basavaraj Patil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] FA Assisted Hand-off I-D X-cc: "Pat.Calhoun@eng.sun.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_01BF637E.8837997C Content-Type: text/plain; charset="windows-1252" >Chairs and WG, > >James Kempf and I submitted a draft a couple of weeks ago, which would >extend Mobile IP to further reduce the latency involved in the hand-off. >This seems really important given the number of threads recently that >pertain to IP in cellular networks, and the need for a low latency >hand-off. > >The question I have for the WG is whether this draft should be >considered a WG work item. > >Thanks, > >PatC Pat, Before the WG can take this document as a WG item we need to spur more discussion and interest in it. With that in mind I would suggest that we hold on to making a decision if it should be a WG document until after Adelaide. I would encourage WG members to provide comments and feedback on this draft through the discussion list in the interim period. -Basavaraj ------_=_NextPart_001_01BF637E.8837997C Content-Type: text/html; charset="windows-1252" RE: [MOBILE-IP] FA Assisted Hand-off I-D

>Chairs and WG,
>
>James Kempf and I submitted a draft a couple of weeks ago, which would
>extend Mobile IP to further reduce the latency involved in the hand-off.
>This seems really important given the number of threads recently that
>pertain to IP in cellular networks, and the need for a low latency
>hand-off.
>
>The question I have for the WG is whether this draft should be
>considered a WG work item.
>
>Thanks,
>
>PatC

Pat,

Before the WG can take this document as a WG item we need to spur more
discussion and interest in it. With that in mind I would suggest that
we hold on to making a decision if it should be a WG document until
after Adelaide.

I would encourage WG members to provide comments and feedback on this
draft through the discussion list in the interim period.

-Basavaraj

------_=_NextPart_001_01BF637E.8837997C-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 20 14:58: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 OAA13786 for ; Thu, 20 Jan 2000 14:58:39 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8DD691D0@standards.nortelnetworks.com>; Thu, 20 Jan 2000 14:56:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1403 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jan 2000 14:55:10 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.58FA01E0@standards.nortelnetworks.com>; Thu, 20 Jan 2000 14:55:10 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 20 Jan 2000 13:55:18 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Thu, 20 Jan 2000 14:55:01 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 20 Jan 2000 13:55:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6380.3B2E9CDC" Message-ID: Date: Thu, 20 Jan 2000 13:54:59 -0600 Reply-To: Basavaraj Patil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: [MOBILE-IP] Conclusion: Consensus for the extensions template defined in MIER 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_01BF6380.3B2E9CDC Content-Type: text/plain; charset="ISO-8859-1" > >The MIER draft (draft-ietf-mobileip-mier-00.txt) states that all new >extensions defined for Mobile IP in the future MUST follow the >template that is specified in the document. >The difference from the existing definition specified in RFC2002 is >that adds a subtype field and the length field is increased two >octets. > >If you have concerns or disagree with this proposal, please express it >on the mailing list by the end of this week. > Based on the opinions received from the (active) WG members on the issue of the MIER draft (draft-ietf-mobileip-mier-00.txt), the consensus is: - there is a strong disagreement to mandate the template proposed in this draft as the one that MUST be followed by all new extensions. The draft will need to undergo revisions to comply with the WG sentiments. -Basavaraj ------_=_NextPart_001_01BF6380.3B2E9CDC Content-Type: text/html; charset="ISO-8859-1" Conclusion: Consensus for the extensions template defined in MIER

>
>The MIER draft (draft-ietf-mobileip-mier-00.txt) states that all new
>extensions defined for Mobile IP in the future MUST follow the
>template that is specified in the document.
>The difference from the existing definition specified in RFC2002 is
>that adds a subtype field and the length field is increased two
>octets.
>
>If you have concerns or disagree with this proposal, please express it
>on the mailing list by the end of this week.
>


Based on the opinions received from the (active) WG members on the
issue of the MIER draft (draft-ietf-mobileip-mier-00.txt), the
consensus is:

- there is a strong disagreement to mandate the template proposed in
  this draft as the one that MUST be followed by all new extensions.

The draft will need to undergo revisions to comply with the WG
sentiments.

-Basavaraj

------_=_NextPart_001_01BF6380.3B2E9CDC-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 20 15: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 PAA14836 for ; Thu, 20 Jan 2000 15: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.BAC66080@standards.nortelnetworks.com>; Thu, 20 Jan 2000 15:33:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1438 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jan 2000 15:32:01 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7F294C90@standards.nortelnetworks.com>; Thu, 20 Jan 2000 15:32:01 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 20 Jan 2000 14:32:57 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Thu, 20 Jan 2000 15:32:48 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 20 Jan 2000 14:32:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6385.80980F74" Message-ID: Date: Thu, 20 Jan 2000 14:32:39 -0600 Reply-To: Basavaraj Patil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] mobile-router mailing list? X-cc: Rob.Goode@nc3a.nato.int, qa3445@email.mot.com, eit@nc3a.nato.int 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_01BF6385.80980F74 Content-Type: text/plain; charset="windows-1252" >I sent out a message about some work I was doing to the >Mobile IP mailing list on mobile routers yesterday and >received a reply from about fifteen people who are >interested in this topic. I feel that it would be helpful >to have a mailing list to discuss issues connected >with mobile routers and implementation issues, and that >probably the Mobile IP mailing list is not the right >forum as this is a topic for a subset of members rather >than being of interest to all. > >As Nortel are hosting the Mobile IP mailing list I am >asking you whether you would also host a mobile-routers >mailing list for discussion of mobile router issues. > >Please could you give me a yes/no quite soon as otherwise >I will set up an egroups mailing list - I wish to strike >whilst the iron is hot, as one might say. > > >Cheers, > >Rob Goode >NC3A-NL Rob, Mobile IP covers both mobile nodes as well as mobile routers. I believe you have raised this point earlier at the time when we were doing the new charter for this WG. Discussion on this topic is very much part of the charter. I am sure there are many of us on this list who are just as interested in this topic (maybe not apparent). So I would argue against going off and creating a separate mailing list to deal with this topic. Regards, -Basavaraj ------_=_NextPart_001_01BF6385.80980F74 Content-Type: text/html; charset="windows-1252" RE: mobile-router mailing list?

>I sent out a message about some work I was doing to the
>Mobile IP mailing list on mobile routers yesterday and
>received a reply from about fifteen people who are
>interested in this topic. I feel that it would be helpful
>to have a mailing list to discuss issues connected
>with mobile routers and implementation issues, and that
>probably the Mobile IP mailing list is not the right
>forum as this is a topic for a subset of members rather
>than being of interest to all.
>
>As Nortel are hosting the Mobile IP mailing list I am
>asking you whether you would also host a mobile-routers
>mailing list for discussion of mobile router issues.
>
>Please could you give me a yes/no quite soon as otherwise
>I will set up an egroups mailing list - I wish to strike
>whilst the iron is hot, as one might say.
>
>
>Cheers,
>
>Rob Goode
>NC3A-NL

Rob,

Mobile IP covers both mobile nodes as well as mobile
routers. I believe you have raised this point earlier at the time when
we were doing the new charter for this WG. Discussion on this topic is
very much part of the charter. I am sure there are many of us on this
list who are just as interested in this topic (maybe not apparent). So
I would argue against going off and creating a separate mailing list
to deal with this topic.

Regards,

-Basavaraj

------_=_NextPart_001_01BF6385.80980F74-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 21 02:35: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 CAA04904 for ; Fri, 21 Jan 2000 02:35:23 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D746A740@standards.nortelnetworks.com>; Fri, 21 Jan 2000 2:33:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1682 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 02:31:06 -0500 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.91721100@standards.nortelnetworks.com>; Fri, 21 Jan 2000 2:31:06 -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 JAA27776 for ; Fri, 21 Jan 2000 09:32:33 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (esebh03nok.ntc.nokia.com [131.228.118.244]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id JAA29189 for ; Fri, 21 Jan 2000 09:32:32 +0200 (EET) Received: by esebh03nok with Internet Mail Service (5.5.2650.10) id ; Fri, 21 Jan 2000 09:32:31 +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: Fri, 21 Jan 2000 09:32:28 +0200 Reply-To: patrik.flykt@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrik Flykt Subject: Re: [MOBILE-IP] AAA functionality To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, >so how do you support dynamic home agent (local or foreign) when using >a parallel approach? Being able to support a parallel approach means that the address of the home agent is known to the mobile node, or the mobile node is doing an dynamic home agent discovery, otherwise there wouldn't be anywhere to send the registration request to. Yes, then we need pre-shared secrets with our home agent. Why not allow pre-shared authenticators, since one has to configure the home agent's address anyway ? With the sequential approach dynamic home agent allocation becomes possible, this is a desired feature in many networks. Unfortunately, with the sequential approach it becomes impossible to split the MIP registration and the access authorization. With the parallel approach one could pay for or authorize the access by some means, e.g. a credit card (/whatever) company, and acquire connectivity through the MIP protocol. The authorizing company need necessarily not be interested in which protocol you are using when accessing the IP network. It is important to support both the serial and the parallel approach since this gives MIP a lot of flexibility, one can allocate a home address and a home agent dynamically and split up the authorization from the acces protocol when needed. Regards, Patrik From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 21 05:40: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 FAA06288 for ; Fri, 21 Jan 2000 05: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.B472CB80@standards.nortelnetworks.com>; Fri, 21 Jan 2000 5:38:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1790 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 05:36:39 -0500 Received: from nc3a.nato.int (192.41.140.186) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7D5A0730@standards.nortelnetworks.com>; Fri, 21 Jan 2000 5:36:39 -0500 Received: from comsun21.nc3a.nato.int (comsun21.nc3a.nato.int [192.150.94.60]) by nc3a.nato.int (8.9.0/8.9.0) with ESMTP id LAA10971; Fri, 21 Jan 2000 11:33:54 +0100 (MET) Received: from comsun21 (comsun21 [192.150.94.60]) by comsun21.nc3a.nato.int (8.9.1b+Sun/8.9.1) with SMTP id LAA03226; Fri, 21 Jan 2000 11:37:46 +0100 (MET) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: talw8vS6PGVAJ7cJa6ny3g== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc Message-ID: <200001211037.LAA03226@comsun21.nc3a.nato.int> Date: Fri, 21 Jan 2000 11:37:46 +0100 Reply-To: Rob Goode Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Rob Goode Subject: Re: [MOBILE-IP] mobile-router mailing list? X-To: bpatil@NORTELNETWORKS.COM X-cc: qa3445@email.mot.com, ronyoung@NORTELNETWORKS.COM, Rob.Goode@nc3a.nato.int To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Dear Basavaraj, my comments are below. I leave it to you whether we have another mailing list or not. > >I sent out a message about some work I was doing to the > >Mobile IP mailing list on mobile routers yesterday and > >received a reply from about fifteen people who are > >interested in this topic. I feel that it would be helpful > >to have a mailing list to discuss issues connected > >with mobile routers and implementation issues, and that > >probably the Mobile IP mailing list is not the right > >forum as this is a topic for a subset of members rather > >than being of interest to all. > > > >As Nortel are hosting the Mobile IP mailing list I am > >asking you whether you would also host a mobile-routers > >mailing list for discussion of mobile router issues. > > > >Please could you give me a yes/no quite soon as otherwise > >I will set up an egroups mailing list - I wish to strike > >whilst the iron is hot, as one might say. > > > > > >Cheers, > > > >Rob Goode > >NC3A-NL > > Rob, > > Mobile IP covers both mobile nodes as well as mobile > routers. I believe you have raised this point earlier at the time when > we were doing the new charter for this WG. Discussion on this topic is > very much part of the charter. I am sure there are many of us on this > list who are just as interested in this topic (maybe not apparent). So > I would argue against going off and creating a separate mailing list > to deal with this topic. > > Regards, > > -Basavaraj I fully agree with you that the Mobile IP WG charter covers mobile routers as well as mobile hosts, and yes it was me who was arguing for that when the charter was last revised. I fully agree that mobile routers are a valid topic for discussion on the mobile ip mailing list. What I was trying to say (but obviously failed to make clear) was that implementation issues of interest to a small number of people trying to get a mobile router running in their lab was probably not of interest to all the 1202 people on the mobile ip mailing list, and that this seemed worth setting up a new mailing list for. I was thinking there may be some discussion on the mobile router hints I have sent out, and that may grow to discuss changes to other source codes available for implementing mobile ip. I suppose I should have said a "mr-implementors" mailing list. What I propose then is that you as the WG chair are the appropriate person to arrange an additional mailing list if you deem it useful. If you deem it better to have it on the mobile ip mailing list then that is fine with me, of course there may not be any mobile router discussions in which case the point is moot. For now then, all discussions are on the mobile ip mailing list and there is no other list. Cheers, Rob Goode From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 21 06:01:32 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 GAA06526 for ; Fri, 21 Jan 2000 06:01:32 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A56046B0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 5:59:14 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1825 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 05:57:50 -0500 Received: from monza.broadswitch.com (195.178.164.73) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0CED22A0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 5:47:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD15AE09@monza.broadswitch.com> Date: Fri, 21 Jan 2000 11:49:09 +0100 Reply-To: Thomas Eklund Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thomas Eklund Subject: Re: [MOBILE-IP] mobile-router mailing list? X-To: Rob Goode To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Why should there be a separate mailing list for nodes that only supports a subset of mobile ip i.e correspondent node and home agent functionality = "mobile router"....? I simply dont understand that..? There is good events like the upcoming Conectathon 2000 that SUN is hosting to test mobile ip implementations against eachother. I'm quite sure that if you only want to test your correspondent node and home agent functionality that you are welcome ther to test it. If you mean a mobile router in a handset where you have a ad-hoc network (like blutooth on one side) and a mobile ip network on the other side then it is discussed within the MANET WG... Best Regards Thomas > -----Original Message----- > From: Rob Goode [mailto:goode@NC3A.NATO.INT] > Sent: Friday, January 21, 2000 11:38 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] mobile-router mailing list? > > > Dear Basavaraj, > > my comments are below. I leave it to you whether we have > another mailing list or not. > > > > >I sent out a message about some work I was doing to the > > >Mobile IP mailing list on mobile routers yesterday and > > >received a reply from about fifteen people who are > > >interested in this topic. I feel that it would be helpful > > >to have a mailing list to discuss issues connected > > >with mobile routers and implementation issues, and that > > >probably the Mobile IP mailing list is not the right > > >forum as this is a topic for a subset of members rather > > >than being of interest to all. > > > > > >As Nortel are hosting the Mobile IP mailing list I am > > >asking you whether you would also host a mobile-routers > > >mailing list for discussion of mobile router issues. > > > > > >Please could you give me a yes/no quite soon as otherwise > > >I will set up an egroups mailing list - I wish to strike > > >whilst the iron is hot, as one might say. > > > > > > > > >Cheers, > > > > > >Rob Goode > > >NC3A-NL > > > > Rob, > > > > Mobile IP covers both mobile nodes as well as mobile > > routers. I believe you have raised this point earlier at > the time when > > we were doing the new charter for this WG. Discussion on > this topic is > > very much part of the charter. I am sure there are many of > us on this > > list who are just as interested in this topic (maybe not > apparent). So > > I would argue against going off and creating a separate mailing list > > to deal with this topic. > > > > Regards, > > > > -Basavaraj > > I fully agree with you that the Mobile IP WG charter covers > mobile routers as well as mobile hosts, and yes it was me > who was arguing for that when the charter was last revised. > > I fully agree that mobile routers are a valid topic for > discussion on the mobile ip mailing list. > > What I was trying to say (but obviously failed to make clear) > was that implementation issues of interest to a small number of > people trying to get a mobile router running in their lab > was probably not of interest to all the 1202 people on the > mobile ip mailing list, and that this seemed worth setting up > a new mailing list for. I was thinking there may be some > discussion on the mobile router hints I have sent out, and > that may grow to discuss changes to other source codes available > for implementing mobile ip. I suppose I should have said > a "mr-implementors" mailing list. > > What I propose then is that you as the WG chair are the > appropriate person to arrange an additional mailing list if > you deem it useful. If you deem it better to have it on > the mobile ip mailing list then that is fine with me, of > course there may not be any mobile router discussions in > which case the point is moot. For now then, all discussions > are on the mobile ip mailing list and there is no other > list. > > Cheers, > > Rob Goode > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 21 10:21: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 KAA11577 for ; Fri, 21 Jan 2000 10:21:02 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DE4905B0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 10:18:32 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2042 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 10:16:51 -0500 Received: from nc3a.nato.int (192.41.140.186) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A1EA9D90@standards.nortelnetworks.com>; Fri, 21 Jan 2000 10:16:50 -0500 Received: from comsun21.nc3a.nato.int (comsun21.nc3a.nato.int [192.150.94.60]) by nc3a.nato.int (8.9.0/8.9.0) with ESMTP id QAA13858; Fri, 21 Jan 2000 16:14:12 +0100 (MET) Received: from comsun21 (comsun21 [192.150.94.60]) by comsun21.nc3a.nato.int (8.9.1b+Sun/8.9.1) with SMTP id QAA03633; Fri, 21 Jan 2000 16:18:04 +0100 (MET) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: fJEP7yxQAo6Krh2ulPsQOg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc Message-ID: <200001211518.QAA03633@comsun21.nc3a.nato.int> Date: Fri, 21 Jan 2000 16:18:04 +0100 Reply-To: Rob Goode Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Rob Goode Subject: Re: [MOBILE-IP] mobile-router mailing list? X-To: thomas.eklund@switchcore.com X-cc: eit@nc3a.nato.int To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Dear Thomas, Thomas Eklund wrote on Fri, 21 Jan 2000 11:49:09 +0100 > > Why should there be a separate mailing list for nodes that only supports a > subset of mobile ip i.e correspondent node and home agent functionality = > "mobile router"....? A "mobile router" is a term that I am using to mean a RFC 2002 Mobile Node implementation which is on a platform that has two or more interfaces and can do IP forwarding between them. One or more of the interfaces run the mobile IP protocol, and one or more interfaces do not run the mobile IP protocol. I think that this use of the term is correct within the Mobile IP community, but the term "mobile router" certainly has other meanings in other communities. The utility of a mobile router is to act as the gateway to a mobile network, by which I mean a network (usually a LAN) which changes its point of attachment to an Internet or Intranet, thereby causing itself to be unroutable unless some mechanism (routing table updates, Mobile IP, DNS updates, Manet, cellular IP etc.) is used. An example I am thinking of is a ship with an onboard network which uses different bearer networks (radio, satellite, pierside cables etc.) to reach an Intranet. I rather think that a mobile router is a useful architectural building block for real world networks - but I may be wrong. Mobile routers are part of RFC2002, and are described in the "textbooks" by Charles. E. Perkins and Jim Soloman. > > I simply dont understand that..? Did I help clarify the term mobile router? The reason I was proposing an additional list was to discuss the implementation details of particular instantiations, e.g. what command line switches do I use? Why did it core dump? what does this compiler error mean? ...those sort of things. Basavaraj can decide. For architectural discussions of mobile routers and everything else derived from RFC2002 then the mobile ip mailing list is the right place. My apologies for the confusion caused. > > There is good events like the upcoming Conectathon 2000 that SUN is hosting > to test mobile ip implementations against eachother. > > I'm quite sure that if you only want to test your correspondent node and > home agent functionality that you are welcome ther to test it. > > If you mean a mobile router in a handset where you have a ad-hoc network > (like blutooth on one side) and a mobile ip network on the other side then > it is discussed within the MANET WG... > > Best Regards Thomas Cheers, Rob Goode > > > -----Original Message----- > > From: Rob Goode [mailto:goode@NC3A.NATO.INT] > > Sent: Friday, January 21, 2000 11:38 AM > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] mobile-router mailing list? > > > > > > Dear Basavaraj, > > > > my comments are below. I leave it to you whether we have > > another mailing list or not. > > > > > > > >I sent out a message about some work I was doing to the > > > >Mobile IP mailing list on mobile routers yesterday and > > > >received a reply from about fifteen people who are > > > >interested in this topic. I feel that it would be helpful > > > >to have a mailing list to discuss issues connected > > > >with mobile routers and implementation issues, and that > > > >probably the Mobile IP mailing list is not the right > > > >forum as this is a topic for a subset of members rather > > > >than being of interest to all. > > > > > > > >As Nortel are hosting the Mobile IP mailing list I am > > > >asking you whether you would also host a mobile-routers > > > >mailing list for discussion of mobile router issues. > > > > > > > >Please could you give me a yes/no quite soon as otherwise > > > >I will set up an egroups mailing list - I wish to strike > > > >whilst the iron is hot, as one might say. > > > > > > > > > > > >Cheers, > > > > > > > >Rob Goode > > > >NC3A-NL > > > > > > Rob, > > > > > > Mobile IP covers both mobile nodes as well as mobile > > > routers. I believe you have raised this point earlier at > > the time when > > > we were doing the new charter for this WG. Discussion on > > this topic is > > > very much part of the charter. I am sure there are many of > > us on this > > > list who are just as interested in this topic (maybe not > > apparent). So > > > I would argue against going off and creating a separate mailing list > > > to deal with this topic. > > > > > > Regards, > > > > > > -Basavaraj > > > > I fully agree with you that the Mobile IP WG charter covers > > mobile routers as well as mobile hosts, and yes it was me > > who was arguing for that when the charter was last revised. > > > > I fully agree that mobile routers are a valid topic for > > discussion on the mobile ip mailing list. > > > > What I was trying to say (but obviously failed to make clear) > > was that implementation issues of interest to a small number of > > people trying to get a mobile router running in their lab > > was probably not of interest to all the 1202 people on the > > mobile ip mailing list, and that this seemed worth setting up > > a new mailing list for. I was thinking there may be some > > discussion on the mobile router hints I have sent out, and > > that may grow to discuss changes to other source codes available > > for implementing mobile ip. I suppose I should have said > > a "mr-implementors" mailing list. > > > > What I propose then is that you as the WG chair are the > > appropriate person to arrange an additional mailing list if > > you deem it useful. If you deem it better to have it on > > the mobile ip mailing list then that is fine with me, of > > course there may not be any mobile router discussions in > > which case the point is moot. For now then, all discussions > > are on the mobile ip mailing list and there is no other > > list. > > > > Cheers, > > > > Rob Goode > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 21 12:14: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 MAA14065 for ; Fri, 21 Jan 2000 12:14:44 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BA8B4AB0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 12:12:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2324 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 12:11:01 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.94E8BD60@standards.nortelnetworks.com>; Fri, 21 Jan 2000 12:11:01 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 21 Jan 2000 11:11:57 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Fri, 21 Jan 2000 12:11:46 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 21 Jan 2000 11:11:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6432.9762A9D2" Message-ID: Date: Fri, 21 Jan 2000 11:11:42 -0600 Reply-To: Basavaraj Patil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] mobile-router mailing list? X-To: Rob Goode X-cc: qa3445@email.mot.com, Ron Young , Rob.Goode@nc3a.nato.int 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_01BF6432.9762A9D2 Content-Type: text/plain; charset="windows-1252" My comments below: >> Rob, >> >> Mobile IP covers both mobile nodes as well as mobile >> routers. I believe you have raised this point earlier at the time when >> we were doing the new charter for this WG. Discussion on this topic is >> very much part of the charter. I am sure there are many of us on this >> list who are just as interested in this topic (maybe not apparent). So >> I would argue against going off and creating a separate mailing list >> to deal with this topic. >> >> Regards, >> >> -Basavaraj >I fully agree with you that the Mobile IP WG charter covers >mobile routers as well as mobile hosts, and yes it was me >who was arguing for that when the charter was last revised. > >I fully agree that mobile routers are a valid topic for >discussion on the mobile ip mailing list. > >What I was trying to say (but obviously failed to make clear) >was that implementation issues of interest to a small number of >people trying to get a mobile router running in their lab >was probably not of interest to all the 1202 people on the >mobile ip mailing list, and that this seemed worth setting up >a new mailing list for. I was thinking there may be some >discussion on the mobile router hints I have sent out, and >that may grow to discuss changes to other source codes available >for implementing mobile ip. I suppose I should have said >a "mr-implementors" mailing list. > > >Cheers, > >Rob Goode Rob, I guess we could create another discussion list specifically for discussion of Mobile Router implementations and the issues associated. The 1202 people on this list may actually appreciate not receiving mail that they are not very keen on. I will go ahead and ask Ron Young to create this discussion list and let you know when it is done. You could announce the creation and subscription info on the Mobile IP mailing list once it's done. Regards, -Basavaraj ------_=_NextPart_001_01BF6432.9762A9D2 Content-Type: text/html; charset="windows-1252" RE: [MOBILE-IP] mobile-router mailing list?

My comments below:

>> Rob,
>>
>> Mobile IP covers both mobile nodes as well as mobile
>> routers. I believe you have raised this point earlier at the time when
>> we were doing the new charter for this WG. Discussion on this topic is
>> very much part of the charter. I am sure there are many of us on this
>> list who are just as interested in this topic (maybe not apparent). So
>> I would argue against going off and creating a separate mailing list
>> to deal with this topic.
>>
>> Regards,
>>
>> -Basavaraj

>I fully agree with you that the Mobile IP WG charter covers
>mobile routers as well as mobile hosts, and yes it was me
>who was arguing for that when the charter was last revised.
>
>I fully agree that mobile routers are a valid topic for
>discussion on the mobile ip mailing list.
>
>What I was trying to say (but obviously failed to make clear)
>was that implementation issues of interest to a small number of
>people trying to get a mobile router running in their lab
>was probably not of interest to all the 1202 people on the
>mobile ip mailing list, and that this seemed worth setting up
>a new mailing list for. I was thinking there may be some
>discussion on the mobile router hints I have sent out, and
>that may grow to discuss changes to other source codes available
>for implementing mobile ip. I suppose I should have said
>a "mr-implementors" mailing list.
>

>
>Cheers,
>
>Rob Goode


Rob,

I guess we could create another discussion list specifically for
discussion of Mobile Router implementations and the issues
associated. The 1202 people on this list may actually appreciate not
receiving mail that they are not very keen on. I will go ahead and ask
Ron Young to create this discussion list and let you know when it is
done. You could announce the creation and subscription info on the
Mobile IP mailing list once it's done.

Regards,
-Basavaraj


------_=_NextPart_001_01BF6432.9762A9D2-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 21 20:52: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 UAA20057 for ; Fri, 21 Jan 2000 20:52:12 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.14D623D0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 20:49:59 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2923 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 20:48:46 -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.835A4B30@standards.nortelnetworks.com>; Fri, 21 Jan 2000 20:38:45 -0500 Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id CAA02767 for ; Sat, 22 Jan 2000 02:40:13 +0100 (MET) Received: from CONVERSION-DAEMON by mbb1.ericsson.se (PMDF V5.2-29 #33627) id <0FOP00D01RB1C8@mbb1.ericsson.se> for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 22 Jan 2000 02:40:13 +0100 (MET) Received: from SMTP (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by mbb1.ericsson.se (PMDF V5.2-29 #33627) with SMTP id <0FOP00D8URB1D7@mbb1.ericsson.se> for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 22 Jan 2000 02:40:13 +0100 (MET) Received: from esealnt172.ericsson.se ([130.100.184.165]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Sat, 22 Jan 2000 01:40:12 +0000 (GMT) Received: by esealnt172 with Internet Mail Service (5.5.2448.0) id ; Sat, 22 Jan 2000 02:40:11 +0100 MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: text/plain; charset=ISO-8859-1 Message-ID: <79D18F182376D311856D0008C791A939BD2622@ESEALNT407.al.sw.ericsson.se> Date: Sat, 22 Jan 2000 02:40:10 +0100 Reply-To: =?ISO-8859-1?Q?Tomas_Goldbeck-L=F6we_=28ERA=29?= Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: =?ISO-8859-1?Q?Tomas_Goldbeck-L=F6we_=28ERA=29?= Subject: [MOBILE-IP] challenge / response; MN auth timeout To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA20057 Hi all, (when I write SA below, I mean the security association between the MN and the FA) I have some comments in the challenge response draft about which auth extension to include in the Reg Request from the MN. In chapter 3.1 of the draft there is a lot about "if the mobile node does not have a security association with the FA...." and "if the mobile node has a security association with the FA...." in order to decide which auth extension to include in the Reg Request. My concern is how the MN does know if it has a VALID security association. I think this is a more appropriate question than if it just do have a SA or not. A security association that is not valid will be rejected by the FA anyway. The FA knows if the SA is valid or not, since it received a timeout together with the SA from the AAA. The problem seams to be that the FA can not forward this timeout to the MN. I am aware that there is a proposal in the draft about MobileIP Diameter Requirements that says that the timeout for the keys must be an integer multiple of the registration lifetime offered by the FA to the MN. But I don't see how this solves the problem, since (a) the HA can give the MN an other lifetime than the one offered by the FA and (b) all we know from rfc2002 is that the MN will re-register when the lifetime is near to expire. (not _exactly_ when it re-registers) As I see it, there are four different ways to solve this (someone can probably come up with another one) 1) Add an extension to the Reg Reply to let the FA forward the SA timeout to the MN. This will make it possible for the MN to include the correct auth extension in the following Reg Requests. However, more extensions means larger messages to the MN which, in a cellular environment, are connected over an air interface. 2) Include a "SA lifetime" in the session key extensions in the AAA Keys draft (draft-calhoun-mobileip-aaa-key-00.txt). By including the information in an existing extension, we will not extend the Reg Reply even more. (they are already quite large) 3) Add a rule for the MN Reg Request procedure. If the MN gets a Reg Reply with code BAD_AUTHENTICATION, the MN SHOULD include the MN-AAA auth in the next Reg Request. This will mean some extra delay, since the first Reg Request will be rejected. 4) Both the MN-FA and the MN-AAA auth extension is included in the RegRequest. Then the FA can take the correct action since it kows if the SA are valid or not. The draft does not exclude this today. To include both keys is also mentioned in the MN AAA Keys draft. However, this means more processing for the MN and that there always will be one auth extension in the RegRequest that is not used. To me, that doesn't sound good from a security point of view... If we don't specify a solution to this, we can end up in a deadlock situation where the MN tries to register with the (invalid) SA which always will be rejected by the FA. Personally I'm in favor of option 2, alternatively option 1, with option 3 as "backup". However, including the timeout in the AAA key extensions will result in changes to another draft, which might have impact on the challenge response draft last call procedure. My suggestion is that we include the timeout in the AAA Keys draft (option 2) and add the extra rule for the MN (option 3) as optional (SHOULD) in the draft. Regards, --> Tomas _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Tomas Goldbeck-Löwe ph. +1 650 463 6138 Ericsson Inc. mobile. +1 510 305 6109 1555 Adams Drive fax. +1 650 463 6851 Menlo Park, CA 94025 tomas.goldbeck-lowe@ericsson.com _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > -----Original Message----- > From:> Basavaraj Patil [SMTP:bpatil@NORTELNETWORKS.COM] > Sent: Thursday, January 13, 2000 8:16 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] WG Last Call (draft-ietf-mobileip-challenge-08.txt) > > > Mobile IP Challenge/Response Extensions draft > (draft-ietf-mobileip-challenge-08.txt) has undergone a couple of > revisions since the previous WG last call. As a result we are sending out > another WG last call on this I-D. Please provide comments and feedback > within the next two weeks. > > WG last call issued on: Jan 13, 2000 > > Regards, > Basavaraj > Phil > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 21 22:48: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 WAA22736 for ; Fri, 21 Jan 2000 22:48:14 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4D2A8220@standards.nortelnetworks.com>; Fri, 21 Jan 2000 22:46:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3004 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 22:44:51 -0500 Received: from tsbgw.wide.toshiba.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.205C2BE0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 22:44:50 -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 MAA01658; Sat, 22 Jan 2000 12:46:12 +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 MAA00415; Sat, 22 Jan 2000 12:46:11 +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 MAA29490; Sat, 22 Jan 2000 12:46:11 +0900 (JST) References: <79D18F182376D311856D0008C791A939BD2622@ESEALNT407.al.sw.ericsson.se> X-Mailer: Datula version 1.21.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200001220346.MAA29490@isl.rdc.toshiba.co.jp> Date: Sat, 22 Jan 2000 12:56: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] challenge / response; MN auth timeout X-To: =?ISO-8859-1?Q?Tomas_Goldbeck-L=F6we_=28ERA=29?= To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <79D18F182376D311856D0008C791A939BD2622@ESEALNT407.al.sw.ericsson.se> Hello, Tomas and Pat, My comment is attached at the end of this email: On Sat, 22 Jan 2000 02:40:10 +0100, Tomas_Goldbeck wrote: >> Hi all, >> >> (when I write SA below, I mean the security association between the MN and the FA) >> >> I have some comments in the challenge response draft about which auth extension >> to include in the Reg Request from the MN. >> In chapter 3.1 of the draft there is a lot about "if the mobile node does not >> have a security association with the FA...." and "if the mobile node has a >> security association with the FA...." in order to decide which auth extension >> to include in the Reg Request. >> My concern is how the MN does know if it has a VALID security association. I >> think this is a more appropriate question than if it just do have a SA or not. >> A security association that is not valid will be rejected by the FA anyway. >> >> The FA knows if the SA is valid or not, since it received a timeout together >> with the SA from the AAA. The problem seams to be that the FA can not forward >> this timeout to the MN. >> >> I am aware that there is a proposal in the draft about MobileIP Diameter >> Requirements that says that the timeout for the keys must be an integer multiple >> of the registration lifetime offered by the FA to the MN. But I don't see how >> this solves the problem, since (a) the HA can give the MN an other lifetime than >> the one offered by the FA and (b) all we know from rfc2002 is that the MN will >> re-register when the lifetime is near to expire. (not _exactly_ when it re-registers) >> >> >> As I see it, there are four different ways to solve this (someone can probably >> come up with another one) >> 1) Add an extension to the Reg Reply to let the FA forward the SA timeout to >> the MN. This will make it possible for the MN to include the correct auth >> extension in the following Reg Requests. However, more extensions means >> larger messages to the MN which, in a cellular environment, are connected >> over an air interface. >> 2) Include a "SA lifetime" in the session key extensions in the AAA Keys draft >> (draft-calhoun-mobileip-aaa-key-00.txt). By including the information in an >> existing extension, we will not extend the Reg Reply even more. (they are >> already quite large) >> 3) Add a rule for the MN Reg Request procedure. If the MN gets a Reg Reply >> with code BAD_AUTHENTICATION, the MN SHOULD include the MN-AAA auth in the >> next Reg Request. This will mean some extra delay, since the first Reg >> Request will be rejected. >> 4) Both the MN-FA and the MN-AAA auth extension is included in the RegRequest. >> Then the FA can take the correct action since it kows if the SA are valid >> or not. The draft does not exclude this today. To include both keys is also >> mentioned in the MN AAA Keys draft. However, this means more processing for >> the MN and that there always will be one auth extension in the RegRequest >> that is not used. To me, that doesn't sound good from a security point of >>> view... >> >> If we don't specify a solution to this, we can end up in a deadlock situation >> where the MN tries to register with the (invalid) SA which always will be >> rejected by the FA. >> >> Personally I'm in favor of option 2, alternatively option 1, with option 3 as >> "backup". >> However, including the timeout in the AAA key extensions will result in >> changes to another draft, which might have impact on the challenge response >> draft last call procedure. >> My suggestion is that we include the timeout in the AAA Keys draft (option 2) >> and add the extra rule for the MN (option 3) as optional (SHOULD) in the draft. Your proposal may improve the protocol. But, there is another way, although it's similar to your option 3: An MN can get a hint of the FA key expiration. Because, the life time, which an MN received in the last registration reply before the FA key expiration, ends at the same time when the previous life time will expire. Thus, the MN can send another registration request to the FA with a Mobile Node NAI extension and a MN-AAA authentication extension. I agree with you; I also couldn't find the exact description about this issue in drafts. I think, an explicit description will improve the drafts. Or, am I missing a draft about this issue ? Cheers. -Yoshi From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 21 23:26: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 XAA22937 for ; Fri, 21 Jan 2000 23:26:17 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9E6CB770@standards.nortelnetworks.com>; Fri, 21 Jan 2000 23:24:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3047 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 23:22:58 -0500 Received: from hanarotel.co.kr (210.94.1.61) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0DDCC570@standards.nortelnetworks.com>; Fri, 21 Jan 2000 23:12:57 -0500 Received: from [210.94.1.119] by hanarotel.co.kr (Netscape Messaging Server 3.5) with SMTP id AAA1202 for ; Sat, 22 Jan 2000 13:10:15 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01BF64DB.4EBEB640" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Message-ID: <000701bf648f$df7745e0$aa030e0a@------.ns.hanarotel.net> Date: Sat, 22 Jan 2000 13:19:26 +0900 Reply-To: =?euc-kr?B?udq9xcf9?= Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: =?euc-kr?B?udq9xcf9?= Subject: [MOBILE-IP] subscribtion To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0004_01BF64DB.4EBEB640 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 RGVhciBzaXIsDQoNCk15IG5hbWUgaXMgU2luaHllIFBhcmsgZnJvbSBIYW5hcm8gVGVsZWNvbW11 bmljYXRpb24gSW5jLiBpbiBLb3JlYS4NCkkgd291bGQgbGlrZSB0byBzdWJzY3JpYmUgZm9yIHRo ZSBlLW1haWwgbGlzdC4NCk15IGUtbWFpbCBhZGRyZXNzIGlzIHNpbmh5ZUBoYW5hcm90ZWwuY28u a3INCg0KVGhhbmsgeW91Lg0K ------=_NextPart_000_0004_01BF64DB.4EBEB640 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD4N CjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9a3NfY181NjAxLTE5 ODciIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0nIk1TSFRNTCA0Ljcy LjM2MTIuMTcwMCInIG5hbWU9R0VORVJBVE9SPg0KPC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZm ZmZmPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj5EZWFyIHNpciw8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgY29sb3I9IzAwMDAwMCBzaXplPTI+TXkgbmFtZSBpcyBTaW5oeWUgUGFyayBm cm9tIEhhbmFybyANClRlbGVjb21tdW5pY2F0aW9uIEluYy4gaW4gS29yZWEuPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj5JIHdvdWxkIGxpa2UgdG8gc3Vic2Ny aWJlIGZvciB0aGUgZS1tYWlsIA0KbGlzdC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9y PSMwMDAwMDAgc2l6ZT0yPk15IGUtbWFpbCBhZGRyZXNzIGlzIDxBIA0KaHJlZj0ibWFpbHRvOnNp bmh5ZUBoYW5hcm90ZWwuY28ua3IiPnNpbmh5ZUBoYW5hcm90ZWwuY28ua3I8L0E+PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPlRoYW5rIHlvdS48L0ZPTlQ+PC9ESVY+ PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0004_01BF64DB.4EBEB640-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jan 22 13:32: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 NAA10042 for ; Sat, 22 Jan 2000 13:32:04 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BDB45CC0@standards.nortelnetworks.com>; Sat, 22 Jan 2000 13:29:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3414 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 22 Jan 2000 13:28:33 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.94511DF0@standards.nortelnetworks.com>; Sat, 22 Jan 2000 13:28:33 -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 KAA09954; Sat, 22 Jan 2000 10:29:34 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id KAA17503; Sat, 22 Jan 2000 10:29:34 -0800 X-Virus-Scanned: Sat, 22 Jan 2000 10:29:34 -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) xma017408; Sat, 22 Jan 00 10:29: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: <79D18F182376D311856D0008C791A939BD2622@ESEALNT407.al.sw.ericsson.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <3889F702.4941C7DB@iprg.nokia.com> Date: Sat, 22 Jan 2000 10:29: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] challenge / response; MN auth timeout X-To: "Tomas =?iso-8859-1?Q?Goldbeck=2DL=F6we?= (ERA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hello Tomas, >> == Tomas Goldbeck-Löwe >> My concern is how the MN does know if it has a VALID security association. I think that your only concern about validity is whether the association has timed out. Am I right? >> The FA knows if the SA is valid or not, since it received a timeout >> together with the SA from the AAA. The problem seams to be that the FA >> can not forward this timeout to the MN. This is not a concern for the FA Challenge draft, since there is no key distribution specified in that draft. So, I do not think that draft should be delayed. We can independently continue to search for a resolution to the problem you have raised. >> I am aware that there is a proposal in the draft about MobileIP Diameter >> Requirements that says that the timeout for the keys must be an integer >> multiple of the registration lifetime offered by the FA to the MN. >> But I don't see how this solves the problem ... I agree that the Mobile-IP DIAMETER extensions draft may need to be reconsidered. Perhaps it is appropriate to add a lifetime to the key extensions. Furthermore, I am currently in the process of revising the Registration Key draft (draft-ietf-mobileip-regkey-00.txt). The new draft will feature a Generalized Registration Key Reply extension. I think it is appropriate to make the extensions of the AAA keys draft into subtypes of the generalized extension, and I expect to write that up soon, unless further discussion indicates otherwise. Relevant to this discussion, I would then expect that there should be _two_ kinds of Generalized Key Reply extensions. One would have a "lifetime" field, and the other would not. The current Registration Key draft does not specify any lifetime for the keys. Up until now, the thought seems to be that a Registration Key should be valid until the foreign agent uses it to make a smooth handover to a new care-of address. I would very much like to get comments on the advisability of allowing both variants. Perhaps Registration Keys should _always_ last for as long as the mobile node continues to reregister the same care-of address. Alternatively, perhaps Registration Keys should _always_ come along with a timeout parameter. Unless I hear otherwise, I will continue to allow for both possibilities with all of the existing key reply extension subtypes. Some other more minor comments: >> As I see it, there are four different ways to solve this (someone can >> probably come up with another one) >> 1) Add an extension to the Reg Reply to let the FA forward the SA timeout >> to the MN. This will make it possible for the MN to include the correct >> auth extension in the following Reg Requests. However, more extensions >> means larger messages to the MN which, in a cellular environment, are >> connected over an air interface. >> 2) Include a "SA lifetime" in the session key extensions in the AAA Keys >> draft (draft-calhoun-mobileip-aaa-key-00.txt). By including the >> information in an existing extension, we will not extend the Reg >> Reply even more. (they are already quite large) >> 3) Add a rule for the MN Reg Request procedure. If the MN gets a Reg Reply >> with code BAD_AUTHENTICATION, the MN SHOULD include the MN-AAA auth in >> the next Reg Request. This will mean some extra delay, since the first >> Reg Request will be rejected. >> 4) Both the MN-FA and the MN-AAA auth extension is included in the >> RegRequest. Then the FA can take the correct action since it kows if >> the SA are valid or not. The draft does not exclude this today. >> To include both keys is also mentioned in the MN AAA Keys draft. >> However, this means more processing for the MN and that there always >> will be one auth extension in the RegRequest that is not used. To me, >> that doesn't sound good from a security point of view... >> >> Personally I'm in favor of option 2, alternatively option 1, with option 3 >> as "backup". I think I substantially agree with this, with the interpretation that (2) can be managed by adding a lifetime field to the Registration Key Reply extension as in draft-ietf-mobileip-regkey-00.txt, and that a key that arrives with no lifetime is good as long as the mobile node continues to use the same care-of address. >> However, including the timeout in the AAA key extensions will result in >> changes to another draft, which might have impact on the challenge response >> draft last call procedure. My suggestion is that we include the timeout >> in the AAA Keys draft (option 2) and add the extra rule for the MN >> (option 3) as optional (SHOULD) in the draft. Your suggestion doesn't have to be considered a "rule". It can be considered a clarification and a suggested procedure to overcome a particular failure. A mobile node could avoid using the suggested procedure and still interoperate with foreign agents that perform as specified; the downside would be that it would not be able to register if it did not make use of one of its existing security associations (namely, that with its home AAA server). I think I can speak for Pat that we will await further comment before including this clarification into a new Challenge draft. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jan 22 13:37: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 NAA10080 for ; Sat, 22 Jan 2000 13:37:50 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.95F7AC90@standards.nortelnetworks.com>; Sat, 22 Jan 2000 13:35:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3447 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 22 Jan 2000 13:34:48 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.73C4F1A0@standards.nortelnetworks.com>; Sat, 22 Jan 2000 13:34:48 -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 KAA10438; Sat, 22 Jan 2000 10:35:45 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id KAA18762; Sat, 22 Jan 2000 10:35:43 -0800 X-Virus-Scanned: Sat, 22 Jan 2000 10:35:43 -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) xma018667; Sat, 22 Jan 00 10:35:32 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <79D18F182376D311856D0008C791A939BD2622@ESEALNT407.al.sw.ericsson.se> <200001220346.MAA29490@isl.rdc.toshiba.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3889F874.962A44A@iprg.nokia.com> Date: Sat, 22 Jan 2000 10:35:32 -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] challenge / response; MN auth timeout X-To: Yoshiyuki Tsuda To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Yoshiyuki Tsuda wrote: > An MN can get a hint of the FA key expiration. Because, the life time, > which an MN received in the last registration reply before the FA key > expiration, ends at the same time when the previous life time will expire. > Thus, the MN can send another registration request to the FA with a Mobile > Node NAI extension and a MN-AAA authentication extension. > > I agree with you; I also couldn't find the exact description about this > issue in drafts. I think, an explicit description will improve the drafts. > Or, am I missing a draft about this issue ? I think it has always been the intention to allow a security association between a mobile node and a foreign agent to survive (i.e., last longer than) individual Mobile IP registration timeouts. Thus I don't understand your comments in the first paragraph above. Can you say more about the explicit description that is needed? Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jan 22 18:36: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 SAA12340 for ; Sat, 22 Jan 2000 18:36:07 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3D9059B0@standards.nortelnetworks.com>; Sat, 22 Jan 2000 18:33:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3592 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 22 Jan 2000 18:32:45 -0500 Received: from gwu.ericy.com (208.196.3.162) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ADD989A0@standards.nortelnetworks.com>; Sat, 22 Jan 2000 18:22:45 -0500 Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id RAA08231; Sat, 22 Jan 2000 17:23:47 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id RAA21675; Sat, 22 Jan 2000 17:23:47 -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 RAA21684; Sat, 22 Jan 2000 17:23:46 -0600 (CST) X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <79D18F182376D311856D0008C791A939BD2622@ESEALNT407.al.sw.ericsson.se> <3889F702.4941C7DB@iprg.nokia.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <388A3C00.E5FC82DE@ericsson.com> Date: Sat, 22 Jan 2000 15:23:44 -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] challenge / response; MN auth timeout X-To: "Charles E. Perkins" X-cc: "Tomas =?iso-8859-1?Q?Goldbeck=2DL=F6we?= (ERA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hi Charlie, > == Charles E. Perkins > > Hello Tomas, > > >> == Tomas Goldbeck-Löwe > > >> My concern is how the MN does know if it has a VALID security association. > > I think that your only concern about validity is whether the association > has timed out. Am I right? Yes, I guess that is another way to say it. It seams that we agree that the MN need to know if the keys are valid or not. > > >> The FA knows if the SA is valid or not, since it received a timeout > >> together with the SA from the AAA. The problem seams to be that the FA > >> can not forward this timeout to the MN. > > This is not a concern for the FA Challenge draft, since there is > no key distribution specified in that draft. So, I do not think > that draft should be delayed. We can independently continue to search > for a resolution to the problem you have raised. I fully agree that the timeout of the keys better belong in the draft which specifies key distribution. Just as long as the timeout also is sent to the MN. > > >> I am aware that there is a proposal in the draft about MobileIP Diameter > >> Requirements that says that the timeout for the keys must be an integer > >> multiple of the registration lifetime offered by the FA to the MN. > >> But I don't see how this solves the problem ... > > I agree that the Mobile-IP DIAMETER extensions draft may need to be > reconsidered. Perhaps it is appropriate to add a lifetime to the > key extensions. > > Furthermore, I am currently in the process of revising the > Registration Key draft (draft-ietf-mobileip-regkey-00.txt). > The new draft will feature a Generalized Registration Key Reply > extension. I think it is appropriate to make the extensions of > the AAA keys draft into subtypes of the generalized extension, > and I expect to write that up soon, unless further discussion > indicates otherwise. > I couldn't find the Registration Key draft on the ietf homepage. And the link from your page isn't valid any more :-( > Relevant to this discussion, I would then expect that there > should be _two_ kinds of Generalized Key Reply extensions. > One would have a "lifetime" field, and the other would not. > The current Registration Key draft does not specify any lifetime > for the keys. Up until now, the thought seems to be that a > Registration Key should be valid until the foreign agent uses > it to make a smooth handover to a new care-of address. > I'm not really sure that I follow you here. Do you mean that as long as a MN is registered at the same FA the key is always valid? And when the MN moves to a new FA, it will get new keys from the home AAA server. This means that there are no timeout for the keys, moving means getting new keys. > I would very much like to get comments on the advisability of > allowing both variants. Perhaps Registration Keys should _always_ > last for as long as the mobile node continues to reregister the > same care-of address. Alternatively, perhaps Registration Keys > should _always_ come along with a timeout parameter. Unless I > hear otherwise, I will continue to allow for both possibilities > with all of the existing key reply extension subtypes. > > Some other more minor comments: > > >> As I see it, there are four different ways to solve this (someone can > >> probably come up with another one) > >> 1) Add an extension to the Reg Reply to let the FA forward the SA timeout > >> to the MN. This will make it possible for the MN to include the correct > >> auth extension in the following Reg Requests. However, more extensions > >> means larger messages to the MN which, in a cellular environment, are > >> connected over an air interface. > >> 2) Include a "SA lifetime" in the session key extensions in the AAA Keys > >> draft (draft-calhoun-mobileip-aaa-key-00.txt). By including the > >> information in an existing extension, we will not extend the Reg > >> Reply even more. (they are already quite large) > >> 3) Add a rule for the MN Reg Request procedure. If the MN gets a Reg Reply > >> with code BAD_AUTHENTICATION, the MN SHOULD include the MN-AAA auth in > >> the next Reg Request. This will mean some extra delay, since the first > >> Reg Request will be rejected. > >> 4) Both the MN-FA and the MN-AAA auth extension is included in the > >> RegRequest. Then the FA can take the correct action since it kows if > >> the SA are valid or not. The draft does not exclude this today. > >> To include both keys is also mentioned in the MN AAA Keys draft. > >> However, this means more processing for the MN and that there always > >> will be one auth extension in the RegRequest that is not used. To me, > >> that doesn't sound good from a security point of view... > >> > >> Personally I'm in favor of option 2, alternatively option 1, with option 3 > >> as "backup". > > I think I substantially agree with this, with the interpretation that > (2) can be managed by adding a lifetime field to the Registration Key > Reply extension as in draft-ietf-mobileip-regkey-00.txt, and that a > key that arrives with no lifetime is good as long as the mobile node > continues to use the same care-of address. > > >> However, including the timeout in the AAA key extensions will result in > >> changes to another draft, which might have impact on the challenge response > >> draft last call procedure. My suggestion is that we include the timeout > >> in the AAA Keys draft (option 2) and add the extra rule for the MN > >> (option 3) as optional (SHOULD) in the draft. > > Your suggestion doesn't have to be considered a "rule". It can > be considered a clarification and a suggested procedure to overcome > a particular failure. A mobile node could avoid using > the suggested procedure and still interoperate with foreign > agents that perform as specified; the downside would be that > it would not be able to register if it did not make use of > one of its existing security associations (namely, that with > its home AAA server). > Agree. I think my "optional rule" is the same as your "clarification and a suggested prodedure". Regards, --> Tomas > I think I can speak for Pat that we will await further comment before > including this clarification into a new Challenge draft. > > Regards, > Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 23 12:09: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 MAA10497 for ; Sun, 23 Jan 2000 12:09:11 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.480C7C50@standards.nortelnetworks.com>; 23 Jan 2000 12:06:29 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3947 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jan 2000 12:04:54 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0F382550@standards.nortelnetworks.com>; 23 Jan 2000 12:04:54 -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 JAA12073 for ; Sun, 23 Jan 2000 09:06:30 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id JAA12360 for ; Sun, 23 Jan 2000 09:06:29 -0800 X-Virus-Scanned: Sun, 23 Jan 2000 09:06:29 -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) xma012255; Sun, 23 Jan 00 09:06:17 -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: <388B3509.6C825E0@iprg.nokia.com> Date: Sun, 23 Jan 2000 09:06:17 -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] Advertisement interval To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, I am working away on getting a new revision of RFC 2002 ready for dissemination. I remember that many people have asked to lower the minimum advertisement interval so that multiple advertisements (beacons) could be sent every second. I very much support this step, and there have been several papers published that supply good technical reasons for doing so. What is important is for the beacons to occupy negligible bandwidth, and that depends more on the wireless medium than on restricting the frequency to once each second. I would like to respecify the minimum interval to be 10 milliseconds. This of course does not require foreign agents to change their current behavior. It only allows for "better" foreign agents in the future, from the point of view of some new wireless media. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 23 12:33: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 MAA10634 for ; Sun, 23 Jan 2000 12:33:50 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C817B150@standards.nortelnetworks.com>; 23 Jan 2000 12:31:33 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3986 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jan 2000 12:29:46 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8857F5C0@standards.nortelnetworks.com>; 23 Jan 2000 12:29: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 JAA13521; Sun, 23 Jan 2000 09:31:22 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id JAA17657; Sun, 23 Jan 2000 09:31:21 -0800 X-Virus-Scanned: Sun, 23 Jan 2000 09:31:21 -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) xma017562; Sun, 23 Jan 00 09:31:09 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <525900371.947652489051.JavaMail.aey@jurassic.Eng.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <388B3ADD.14D84F4C@iprg.nokia.com> Date: Sun, 23 Jan 2000 09:31: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: Re: [MOBILE-IP] RFC2002bis X-To: Alper.Yegin@eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Alper, Regarding the following text: > The host specific route to MN shouldn't be available to any packets > other than the ones arriving to FA on the tunnel configured for this MN. > This requires forwarding based on not only destination address but also > incoming interface. Without this, there's the problem of getting HA out > of the loop, and in the case of MN moving another site, host specific > route will not go away until previous FA expires the registration, > and until then any communication going through this FA will be > interrupted. I can't include this, because it would totally break route optimization. I did clarify that the foreign agent MUST NOT advertise routes to the mobile node. Is there something more that I should say that would not break route optimization? The discussion about FAs sending gratuitous ARPs is interesting, but I can't put that into RFC 2002bis unless there is more demand for that from more people in the working group. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 23 14:54:15 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 OAA11199 for ; Sun, 23 Jan 2000 14:54:14 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5DD23FE0@standards.nortelnetworks.com>; 23 Jan 2000 14:51:44 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4137 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jan 2000 14:50:02 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.20E02340@standards.nortelnetworks.com>; 23 Jan 2000 14:50:02 -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 LAA19903; Sun, 23 Jan 2000 11:51:39 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id LAA10132; Sun, 23 Jan 2000 11:51:38 -0800 X-Virus-Scanned: Sun, 23 Jan 2000 11:51:38 -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) xma010016; Sun, 23 Jan 00 11:51:23 -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: <388B5BBB.3CC391C1@iprg.nokia.com> Date: Sun, 23 Jan 2000 11:51: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: [MOBILE-IP] Registration Keys draft; web page links X-cc: Dave Johnson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello again, I have also been informed that many of the links on my web page are no longer valid, since the Internet Drafts they point to have been expired. Most of the expired drafts will be reissued before Adelaide. In particular, the existing (expired) Registration Keys draft is being heavily revised to reflect the MIER philosophy, albeit not with the exact MIER formats. The previous draft is available at: http://www.iprg.nokia.com/~charliep/txt/mobileip/regkey.txt A newer, unfinished draft is available at: http://www.iprg.nokia.com/~charliep/txt/mobileip/regkey.NEW I expect to put in something for elliptic curves, and a citation for Pat Calhoun's blob^H^H^H^Hopaque-data-transfer draft. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 23 14:54: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 OAA11201 for ; Sun, 23 Jan 2000 14:54:15 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5E20FC20@standards.nortelnetworks.com>; 23 Jan 2000 14:51:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4141 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jan 2000 14:51:31 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.55FACDA0@standards.nortelnetworks.com>; 23 Jan 2000 14:51:31 -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 LAA19920; Sun, 23 Jan 2000 11:53:08 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id LAA10307; Sun, 23 Jan 2000 11:53:07 -0800 X-Virus-Scanned: Sun, 23 Jan 2000 11:53:07 -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) xma010212; Sun, 23 Jan 00 11:52:56 -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: <388B5C18.9503B4F6@iprg.nokia.com> Date: Sun, 23 Jan 2000 11:52:56 -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] IP Mobility Support for IPv4, revised X-cc: Basavaraj Patil , Phil Roberts To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, I have finished a new draft, draft-ietf-mobileip-rfc2002-bis-01.txt and it is available on my web page at: http://www.iprg.nokia.com/~charliep/txt/mobileip/mobileip.txt There are a list of Open Issues in the above draft. If someone has answers, I'd appreciate getting e-mail or mailing list discussion about the issues before I send the draft to the IETF directories. Or else, I can just delete the section. Or, I can leave the section in the revised draft, and hope that answers become available as the revised draft goes through Last Call. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 23 16:04: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 QAA11704 for ; Sun, 23 Jan 2000 16:04:08 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.28E529A0@standards.nortelnetworks.com>; 23 Jan 2000 16:01:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4208 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jan 2000 16:00:50 -0500 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9F6959E0@standards.nortelnetworks.com>; 23 Jan 2000 15:50:50 -0500 Received: from ns.click ([163.121.204.222]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id OAA25076 for ; Sun, 23 Jan 2000 14:52:26 -0600 (CST) Received: from artim (ABDB8209.ipt.aol.com [171.219.130.9]) by ns.click with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CXTCGYW3; Sun, 23 Jan 2000 22:45:49 +0200 Message-ID: <200001232052.OAA25076@hosaka.smallworks.com> Date: Sun, 23 Jan 2000 14:52:26 -0600 Reply-To: opt-in@SOFTHOME.NET Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: opt-in@SOFTHOME.NET Subject: [MOBILE-IP] How to make $1000 - $2000 weekly helping car dealerships To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM No come-ons, no hype, just plain old fashioned good deals... Flat Rate Discount Long Distance Telephone Service Individually customized programs available designed for your individual or business usage AS LOW AS 3 CENTS PER MINUTE TO 7.5 CENTS PER MINUTE... 24 hours a day - 7 days a week Ultra Modern Fiber-Optic Network Dial 1 Service - No Special 10-10 Codes Perfect for Residential or Business Calling cards available at 9.9 to 14.9 cpm "800" numbers as low as 7.5 cpm International rates at equally fantastic savings No contracts to sign - No long term commitment Outgoing USA numbers only BUSINESS OPPORTUNITY AVAILABLE To get more info, Send Your Name: U.S. Phone # (required): and Best time to contact you: To mailto:telecom14@newmail.net (Sorry, International phone numbers can not be processed at this time. Inquiries must have phone numbers.) Thanks for your time. To unsubscribe, mailto:unsubscribe121@newmail.net From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 24 00:25: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 AAA16471 for ; Mon, 24 Jan 2000 00:25:57 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.384241D0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 0:23:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4591 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 00:21:52 -0500 Received: from tsbgw.wide.toshiba.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.02510D90@standards.nortelnetworks.com>; Mon, 24 Jan 2000 0:21:50 -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 OAA22840; Mon, 24 Jan 2000 14:23:13 +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 OAA11394; Mon, 24 Jan 2000 14:23:13 +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 OAA25539; Mon, 24 Jan 2000 14:23:13 +0900 (JST) References: <79D18F182376D311856D0008C791A939BD2622@ESEALNT407.al.sw.ericsson.se> <200001220346.MAA29490@isl.rdc.toshiba.co.jp> <3889F874.962A44A@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: <200001240523.OAA25539@isl.rdc.toshiba.co.jp> Date: Mon, 24 Jan 2000 14:33:34 +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] challenge / response; MN auth timeout X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <3889F874.962A44A@iprg.nokia.com> Hello, Charlie, I attached a more explicit description; I'm sorry my comment itself wasn't explicit: On Sat, 22 Jan 2000 10:35:32 -0800, Charles E. Perkins wrote: >> Yoshiyuki Tsuda wrote: >> >> > An MN can get a hint of the FA key expiration. Because, the life time, >> > which an MN received in the last registration reply before the FA key >> > expiration, ends at the same time when the previous life time will expire. >> > Thus, the MN can send another registration request to the FA with a Mobile >> > Node NAI extension and a MN-AAA authentication extension. >> > >> > I agree with you; I also couldn't find the exact description about this >> > issue in drafts. I think, an explicit description will improve the drafts. >> > Or, am I missing a draft about this issue ? >> >> I think it has always been the intention to allow a security association >> between a mobile node and a foreign agent to survive (i.e., last longer >> than) individual Mobile IP registration timeouts. Thus I don't >> understand >> your comments in the first paragraph above. Can you say more about the >> explicit description that is needed? >> >> Regards, >> Charlie P. Here is a figure about life times, and so on: |-----------------Tsa-----------------------| t-prev t-expire |--------Tprev--------| t-req |--------Treq--------| t-last |--Tlast--| "Tsa" is a life time about a security association between an MN and an FA, also between an MN and an HA. At t-prev, the MN received the previous registration reply from the FA, whose life time is "Tprev". Both Tsa and Tprev will expire at "t-expire". At "t-req", the MN sends a registration request whose life time is "Treq". Then, the MN receives a registration reply at "t-last", but its accepted life time is "Tlast". Although the MN doesn't know Tsa will expire at t-expire, the MN gets a hint about it by that both Tprev and Tlast will expire at(or about) t-expire. By this hint, I think, the MN may be able to send a registration request with a Mobile Node NAI extension and a MN-AAA authentication extension. Thanks. -Yoshi From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 24 03:50: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 DAA29735 for ; Mon, 24 Jan 2000 03:50:13 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C3AF8D10@standards.nortelnetworks.com>; Mon, 24 Jan 2000 3:47:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4742 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 03:46:36 -0500 Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EDA336F0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 3:34:32 -0500 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id NAA16819 for ; Mon, 24 Jan 2000 13:45:04 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256870.002A2B68 ; Mon, 24 Jan 2000 13:10:36 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256870.002A2AA4.00@sandesh.hss.hns.com> Date: Mon, 24 Jan 2000 13:13:55 +0530 Reply-To: csirish@HSS.HNS.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sirish K Challagulla Subject: [MOBILE-IP] About Mobile IP stack PL Help Me To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, all Can any one help me from where can i get or any information regarding Mobile IPStack For Wndows, I have designed the H/W for 11mbps wireless lan using AMD and harris semiconductors, Pl suggest and help me regarding Ip stack or send me some information regarding Stack devlopment resources i am looking for windows based (95,98,NT) Best Regards Sirish From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 24 04:20: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 EAA00152 for ; Mon, 24 Jan 2000 04:20:16 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F6C93A80@standards.nortelnetworks.com>; Mon, 24 Jan 2000 4:17:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4789 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 04:16: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.BA3D80D0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 4:16:03 -0500 Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id KAA23741 for ; Mon, 24 Jan 2000 10:17:40 +0100 (MET) Received: from CONVERSION-DAEMON by mbb1.ericsson.se (PMDF V5.2-29 #33627) id <0FOU00I010WF0N@mbb1.ericsson.se> for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 10:17:33 +0100 (MET) Received: from SMTP (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by mbb1.ericsson.se (PMDF V5.2-29 #33627) with SMTP id <0FOU00I5L1AV0L@mbb1.ericsson.se>; Mon, 24 Jan 2000 10:06: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) ; Mon, 24 Jan 2000 09:06:30 +0000 (GMT) Received: by esealnt400 with Internet Mail Service (5.5.2448.0) id ; Mon, 24 Jan 2000 10:06:27 +0100 MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: text/plain; charset=ISO-8859-1 Message-ID: <5F05C89FB2F8D211B6430008C791912701D2EBC0@esealnt190> Date: Mon, 24 Jan 2000 10:06:22 +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] challenge / response; MN auth timeout X-To: Yoshiyuki Tsuda To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Yoshi > Here is a figure about life times, and so on: > > |-----------------Tsa-----------------------| > t-prev t-expire > |--------Tprev--------| > > t-req > |--------Treq--------| > t-last > |--Tlast--| > > "Tsa" is a life time about a security association between an MN and > an FA, also between an MN and an HA. At t-prev, the MN received the > previous registration reply from the FA, whose life time is "Tprev". > Both Tsa and Tprev will expire at "t-expire". The expiration of the SA (Tsa) and of the registration lifetime (Tprev) do not necessarily have to coincide. Regards, Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 24 04:55: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 EAA00502 for ; Mon, 24 Jan 2000 04:55:30 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DE736C80@standards.nortelnetworks.com>; Mon, 24 Jan 2000 4:52:51 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4832 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 04:51:15 -0500 Received: from beamer.mchh.siemens.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3F1706C0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 4:41:14 -0500 Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA15027 for ; Mon, 24 Jan 2000 10:42:19 +0100 (MET) Received: from mchh202e.demchh201e.icn.siemens.de ([218.1.68.105]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA12883 for ; Mon, 24 Jan 2000 10:40:25 +0100 (MET) Received: by MCHH202E with Internet Mail Service (5.5.2448.0) id ; Mon, 24 Jan 2000 10:42:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF664F.64EF6B88" Message-ID: Date: Mon, 24 Jan 2000 10:42:24 +0100 Reply-To: Petri Bernhard Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Petri Bernhard Subject: [MOBILE-IP] FW: I-D ACTION:draft-petri-mobileip-pipe-00.txt 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_000_01BF664F.64EF6B88 Content-Type: text/plain I've submitted draft-petri-mobileip-pipe-00.txt to the Internet-draft editor (see message below). This is an attempt to provide a solution for the use of private IP addresses within Mobile IP, which was mentioned to be an open issue at the last two meetings of the Mobile IP group, and was also addressed by some mails on the list recently. Unlike Charlie's draft at the Oslo meeting, I've tried to provide a more generic solution showing how IP-IP tunnels (RFC 2003) could make use of private IP addresses. Based on that basic solution for IP-IP, it's easy for Mobile IP to use private IP addresses; this is outlined by an example in the draft. Comments welcome. Kind regards Bernhard Bernhard Petri, Siemens Tel: +49 89 722-34578 Fax: +49 89 722-29098 bernhard.petri@icn.siemens.de ______________________________ > -----Original Message----- > From: Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org] > Sent: Friday, January 21, 2000 12:46 PM > Subject: I-D ACTION:draft-petri-mobileip-pipe-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Private IP Encapsulation within IP (PIPE) > Author(s) : B. Petri > Filename : draft-petri-mobileip-pipe-00.txt > Pages : 14 > Date : 20-Jan-00 > > RFC 2003 specifies a method by which an IP datagram may be > encapsulated (carried as payload) within an IP datagram. This is a > means to alter the normal IP routing for datagrams, by delivering > them to an intermediate destination that would otherwise not be > selected by the (network part of the) IP Destination Address field in > the original IP header. > This draft allows to extend this encapsulation mechanism also for > private IP addresses. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-petri-mobileip-pipe-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-petri-mobileip-pipe-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-petri-mobileip-pipe-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_000_01BF664F.64EF6B88 Content-Type: message/rfc822 Content-Description: Unbenannte Anlage To: Subject: Date: Mon, 24 Jan 2000 10:42:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01BF664F.64EF6B88" ------_=_NextPart_002_01BF664F.64EF6B88 Content-Type: text/plain ------_=_NextPart_002_01BF664F.64EF6B88 Content-Type: application/octet-stream; name="ATT20031.txt" Content-Disposition: attachment; filename="ATT20031.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000120095556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-petri-mobileip-pipe-00.txt ------_=_NextPart_002_01BF664F.64EF6B88 Content-Type: message/external-body; site="internet-drafts"; dir="draft-petri-mobileip-pipe-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01BF664F.64EF6B88-- ------_=_NextPart_000_01BF664F.64EF6B88-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 24 07:32: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 HAA03021 for ; Mon, 24 Jan 2000 07:32:50 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D786F480@standards.nortelnetworks.com>; Mon, 24 Jan 2000 7:30:08 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5062 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 07:28:57 -0500 Received: from tsbgw.wide.toshiba.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ACA3CC70@standards.nortelnetworks.com>; Mon, 24 Jan 2000 7:28:57 -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 VAA27014; Mon, 24 Jan 2000 21:30:20 +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 VAA14362; Mon, 24 Jan 2000 21:30:20 +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 VAA12439; Mon, 24 Jan 2000 21:30:19 +0900 (JST) References: <5F05C89FB2F8D211B6430008C791912701D2EBC0@esealnt190> X-Mailer: Datula version 1.21.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200001241230.VAA12439@isl.rdc.toshiba.co.jp> Date: Mon, 24 Jan 2000 21:40:40 +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] challenge / response; MN auth timeout X-To: "Karim El-Malki (ERA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <5F05C89FB2F8D211B6430008C791912701D2EBC0@esealnt190> Hello, Karim, On Mon, 24 Jan 2000 10:06:22 +0100, Karim El-Malki (ERA) wrote: >> Hi Yoshi >> >> > Here is a figure about life times, and so on: >> > >> > |-----------------Tsa-----------------------| >> > t-prev t-expire >> > |--------Tprev--------| >> > >> > t-req >> > |--------Treq--------| >> > t-last >> > |--Tlast--| >> > >> > "Tsa" is a life time about a security association between an MN and >> > an FA, also between an MN and an HA. At t-prev, the MN received the >> > previous registration reply from the FA, whose life time is "Tprev". >> > Both Tsa and Tprev will expire at "t-expire". >> >> The expiration of the SA (Tsa) and of the registration lifetime (Tprev) >> do not necessarily have to coincide. >> >> Regards, >> Karim The HA or FA knows the SA will expire at t-expire, so, Tprev cannot be longer than t-expire - t-prev. Therefore, logically there is the first accepted life time(Tprev), which coincides with the end of Tsa. After this happens, all successive acceptable life time will coincide with the end of Tsa. In practice, I should say these are closely coincided, I think. Thanks. -Yoshi From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 24 07:52: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 HAA03832 for ; Mon, 24 Jan 2000 07:52:47 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A4C91E80@standards.nortelnetworks.com>; Mon, 24 Jan 2000 7:50:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5103 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 07:49:00 -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.79FB5330@standards.nortelnetworks.com>; Mon, 24 Jan 2000 7:49:00 -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 NAA05680; Mon, 24 Jan 2000 13:50:18 +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) ; Mon, 24 Jan 2000 12:50:16 0000 (GMT) Received: by esealnt400 with Internet Mail Service (5.5.2448.0) id ; Mon, 24 Jan 2000 13:50:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <5F05C89FB2F8D211B6430008C791912703EA7E0F@esealnt190> Date: Mon, 24 Jan 2000 13:50:13 +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] challenge / response; MN auth timeout X-To: Yoshiyuki Tsuda , "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Yoshi > The HA or FA knows the SA will expire at t-expire, so, Tprev cannot > be longer than t-expire - t-prev. Therefore, logically there is the > first accepted life time(Tprev), which coincides with the > end of Tsa. > > After this happens, all successive acceptable life time > will coincide > with the end of Tsa. > > In practice, I should say these are closely coincided, I think. In this you assume that the SA will last only for one MN Registration lifetime. As Charlie mentioned in a previous email, it is normal to expect the SA to last many Registration lifetimes. Therefore the MN must have a way to understand when it is to use the MN-AAA extension to re-establish the SA (as Tomas pointed out). Please correct me if I misunderstood your point. Given these discussions, it may be appropriate for people who are implementing the Challenge/Response draft if it identified the cases in which the MN-AAA extension may be used: - Expiry of SA (regkey lifetime expiry or BAD_AUTHENTICATION) - Change of COA Regards, Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 24 08:14: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 IAA04724 for ; Mon, 24 Jan 2000 08:14:08 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.967555D0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 8:11:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5152 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 08:09:40 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5CC803F0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 8:09:40 -0500 Received: from zmers013 by smtprch1.nortel.com; Mon, 24 Jan 2000 07:11:10 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Mon, 24 Jan 2000 08:10:48 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 24 Jan 2000 07:10:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF666C.6D6EA1B2" Message-ID: Date: Mon, 24 Jan 2000 07:10:37 -0600 Reply-To: Ron Young Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Ron Young Subject: [MOBILE-IP] New list created 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_01BF666C.6D6EA1B2 Content-Type: text/plain; charset="ISO-8859-1" Everyone, The Mobile router implementors list has been created. To subscribe, please send a note to listserv@standards.nortelnetworks.com with "subscribe mr-implementors first_name last_name" in the body. Please leave off the quotes and change first_name last_name to your own first and last name. ------------------------------------------------------------------------ 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. ------_=_NextPart_001_01BF666C.6D6EA1B2 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable New list created

Everyone,

The Mobile router implementors list has been = created.  To subscribe, please send a note to = listserv@standards.nortelnetworks.com with "subscribe = mr-implementors first_name last_name" in the body.  Please = leave off the quotes and change first_name last_name to your own first = and last name.

---------------------------------------------------------------= ---------
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.
 

------_=_NextPart_001_01BF666C.6D6EA1B2-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 24 09:44: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 JAA08638 for ; Mon, 24 Jan 2000 09:44:29 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.32B5FBA0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 9:41:32 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5291 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 09:41:02 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BA643EB0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 9:31:01 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08116; Mon, 24 Jan 2000 09:32:31 -0500 (EST) Message-ID: <200001241432.JAA08116@ietf.org> Date: Mon, 24 Jan 2000 09:32:30 -0500 Reply-To: The IESG Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: CC field duplicated. Last occurrence was retained. Comments: RFC822 error: CC field duplicated. Last occurrence was retained. Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: [MOBILE-IP] Protocol Action: Mobile IP Network Access Identifier Extension to Proposed Standard To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM The IESG has approved the Internet-Draft 'Mobile IP Network Access Identifier Extension' as a Proposed Standard. This document is the product of the IP Routing for Wireless/Mobile Hosts Working Group. The IESG contact persons are David Oran and Rob Coltun. Technical Summary AAA servers are in use within the Internet today to provide authentication and authorization services for dial-up and roaming computers. Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI). This specification defines a way for the mobile node to identify itself to the AAA server of the the foreign domain by including the NAI along with the Mobile IP Registration Request it sends to the foreign agent of the domain. Additionally, it allows a mobile node to authenticate itself despite not having a permanently-assigned IP address. Working Group Summary There was no dissent on the technical approach taken. There was some controversy concerning the inclusion of example scenarios employing the DIAMETER AAA protocol, on which consensus has not been reached in the AAA working group. Those examples have been removed. The protocol was originally last-called for Experimental status. At IETF-46 the WG met and there was strong consensus that the protocol should instead be standards track. After discussion with the Area Directors, the specification was deemed mature and solid enough to progress to proposed standard. Protocol Quality At the last bakeoff/interop testing held in July '99 in San Jose there were four implementation of MN-NAI. These implementations were able to sucessfully interoperate with each other. Details of this interop are available at: http://www.diameter.org/mip_results.txt This specification was reviewed for the IESG by Dave Oran. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 24 12:04: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 MAA14502 for ; Mon, 24 Jan 2000 12:04:00 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B54F6250@standards.nortelnetworks.com>; Mon, 24 Jan 2000 12:01:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5658 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 11:59:40 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7E06DB70@standards.nortelnetworks.com>; Mon, 24 Jan 2000 11:59:39 -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 JAA24091; Mon, 24 Jan 2000 09:01:15 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA06732; Mon, 24 Jan 2000 09:01:15 -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 JAA24321; Mon, 24 Jan 2000 09:01:07 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-ID: <200001241701.JAA24321@nasnfs.eng.sun.com> Date: Mon, 24 Jan 2000 08:56:00 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] challenge / response; MN auth timeout X-To: =?ISO-8859-1?Q?Tomas_Goldbeck-L=F6we_=28ERA=29?= To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit >Hi all, > >(when I write SA below, I mean the security association between the MN and the >FA) > >I have some comments in the challenge response draft about which auth extension >to include in the Reg Request from the MN. >In chapter 3.1 of the draft there is a lot about "if the mobile node does not >have a security association with the FA...." and "if the mobile node has a >security association with the FA...." in order to decide which auth extension to >include in the Reg Request. >My concern is how the MN does know if it has a VALID security association. I >think this is a more appropriate question than if it just do have a SA or not. A >security association that is not valid will be rejected by the FA anyway. > >The FA knows if the SA is valid or not, since it received a timeout together >with the SA from the AAA. The problem seams to be that the FA can not forward >this timeout to the MN. > >I am aware that there is a proposal in the draft about MobileIP Diameter >Requirements that says that the timeout for the keys must be an integer multiple >of the registration lifetime offered by the FA to the MN. But I don't see how >this solves the problem, since (a) the HA can give the MN an other lifetime than >the one offered by the FA and (b) all we know from rfc2002 is that the MN will >re-register when the lifetime is near to expire. (not _exactly_ when it >re-registers) The DIAMETER extension doesn't work in the method you described. The lifetime returned is the expiration time, in a format consistent with NTP time. It is up to the Mobile Node to determine whether it should request new keying information, by including the MN-AAA authentication extension in the registration request. > > >As I see it, there are four different ways to solve this (someone can probably >come up with another one) >1) Add an extension to the Reg Reply to let the FA forward the SA timeout to the >MN. This will make it possible for the MN to include the correct auth extension >in the following Reg Requests. However, more extensions means larger messages to >the MN which, in a cellular environment, are connected over an air interface. >2) Include a "SA lifetime" in the session key extensions in the AAA Keys draft >(draft-calhoun-mobileip-aaa-key-00.txt). By including the information in an >existing extension, we will not extend the Reg Reply even more. (they are >already quite large) >3) Add a rule for the MN Reg Request procedure. If the MN gets a Reg Reply with >code BAD_AUTHENTICATION, the MN SHOULD include the MN-AAA auth in the next Reg >Request. This will mean some extra delay, since the first Reg Request will be >rejected. >4) Both the MN-FA and the MN-AAA auth extension is included in the RegRequest. >Then the FA can take the correct action since it kows if the SA are valid or >not. The draft does not exclude this today. To include both keys is also >mentioned in the MN AAA Keys draft. However, this means more processing for the >MN and that there always will be one auth extension in the RegRequest that is >not used. To me, that doesn't sound good from a security point of view... > >If we don't specify a solution to this, we can end up in a deadlock situation >where the MN tries to register with the (invalid) SA which always will be >rejected by the FA. > >Personally I'm in favor of option 2, alternatively option 1, with option 3 as >"backup". >However, including the timeout in the AAA key extensions will result in changes >to another draft, which might have impact on the challenge response draft last >call procedure. >My suggestion is that we include the timeout in the AAA Keys draft (option 2) >and add the extra rule for the MN (option 3) as optional (SHOULD) in the draft. I would agree that the two options you described above are the logical choices. #2 is the best way, and #3 provides the safeguard. However, my assumption was that code 67, defined in RFC 2002, could be used for this purpose. Since a code already exists for the Foreign Agent to communicate with the Foreign Agent that the authentication has failed, why should this document define a new one? PatC > > > >Regards, > > --> Tomas > > >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > Tomas Goldbeck-Löwe ph. +1 650 463 6138 > Ericsson Inc. mobile. +1 510 305 6109 > 1555 Adams Drive fax. +1 650 463 6851 > Menlo Park, CA 94025 > tomas.goldbeck-lowe@ericsson.com >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > > >> -----Original Message----- >> From:> Basavaraj Patil [SMTP:bpatil@NORTELNETWORKS.COM] >> Sent: Thursday, January 13, 2000 8:16 AM >> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >> Subject: [MOBILE-IP] WG Last Call (draft-ietf-mobileip-challenge-08.txt) >> >> >> Mobile IP Challenge/Response Extensions draft >> (draft-ietf-mobileip-challenge-08.txt) has undergone a couple of >> revisions since the previous WG last call. As a result we are sending out >> another WG last call on this I-D. Please provide comments and feedback >> within the next two weeks. >> >> WG last call issued on: Jan 13, 2000 >> >> Regards, >> Basavaraj >> Phil >> From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 24 12:41: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 MAA15918 for ; Mon, 24 Jan 2000 12:41:38 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E6583BB0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 12:38:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5780 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 12:37:54 -0500 Received: from bells.cs.ucl.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D5734830@standards.nortelnetworks.com>; Mon, 24 Jan 2000 12:37:53 -0500 Received: from ginger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 24 Jan 2000 17:39:13 +0000 X-Mailer: exmh version 2.0.2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <1274.948735553@cs.ucl.ac.uk> Date: Mon, 24 Jan 2000 17:39:13 +0000 Reply-To: Theo PAGTZIS Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Theo PAGTZIS Subject: [MOBILE-IP] Any Info on the Ericsson Mobile IPv6 impl. To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Can anyone point to more info about Ericssons mobile IPv6 implementation?? Cheers Theo From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 24 12:45: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 MAA16077 for ; Mon, 24 Jan 2000 12:45:52 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7609D110@standards.nortelnetworks.com>; Mon, 24 Jan 2000 12:42:23 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5750 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 12:41:17 -0500 Received: from gwa.ericsson.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E91BE500@standards.nortelnetworks.com>; Mon, 24 Jan 2000 12:31:17 -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 LAA27810; Mon, 24 Jan 2000 11:32:41 -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 LAA01211; Mon, 24 Jan 2000 11:32:42 -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 LAA02637; Mon, 24 Jan 2000 11:32:41 -0600 (CST) X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <200001241701.JAA24321@nasnfs.eng.sun.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <388C8CB6.C54D16F0@ericsson.com> Date: Mon, 24 Jan 2000 09:32:38 -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] challenge / response; MN auth timeout X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hi Pat, Patrice Calhoun wrote: > > >Hi all, > > > >(when I write SA below, I mean the security association between the MN and the > >FA) > > > >I have some comments in the challenge response draft about which auth extension > >to include in the Reg Request from the MN. > >In chapter 3.1 of the draft there is a lot about "if the mobile node does not > >have a security association with the FA...." and "if the mobile node has a > >security association with the FA...." in order to decide which auth extension to > >include in the Reg Request. > >My concern is how the MN does know if it has a VALID security association. I > >think this is a more appropriate question than if it just do have a SA or not. A > >security association that is not valid will be rejected by the FA anyway. > > > >The FA knows if the SA is valid or not, since it received a timeout together > >with the SA from the AAA. The problem seams to be that the FA can not forward > >this timeout to the MN. > > > >I am aware that there is a proposal in the draft about MobileIP Diameter > >Requirements that says that the timeout for the keys must be an integer multiple > >of the registration lifetime offered by the FA to the MN. But I don't see how > >this solves the problem, since (a) the HA can give the MN an other lifetime than > >the one offered by the FA and (b) all we know from rfc2002 is that the MN will > >re-register when the lifetime is near to expire. (not _exactly_ when it > >re-registers) > > The DIAMETER extension doesn't work in the method you described. The > lifetime returned is the expiration time, in a format consistent > with NTP time. It is up to the Mobile Node to determine whether it should > request new keying information, by including the MN-AAA authentication > extension in the registration request. > That's just my point, we can not use the DIAMETER extension. My point is simply that when we distribute keys to the Mobile Node with ANY protocol (DIAMETER or whatever), we also include a lifetime for the key in the same extension. That will make it possible for the Mobile Node to choose between the MN-FA or the MN-AAA authentication extensions. > > > > > >As I see it, there are four different ways to solve this (someone can probably > >come up with another one) > >1) Add an extension to the Reg Reply to let the FA forward the SA timeout to the > >MN. This will make it possible for the MN to include the correct auth extension > >in the following Reg Requests. However, more extensions means larger messages to > >the MN which, in a cellular environment, are connected over an air interface. > >2) Include a "SA lifetime" in the session key extensions in the AAA Keys draft > >(draft-calhoun-mobileip-aaa-key-00.txt). By including the information in an > >existing extension, we will not extend the Reg Reply even more. (they are > >already quite large) > >3) Add a rule for the MN Reg Request procedure. If the MN gets a Reg Reply with > >code BAD_AUTHENTICATION, the MN SHOULD include the MN-AAA auth in the next Reg > >Request. This will mean some extra delay, since the first Reg Request will be > >rejected. > >4) Both the MN-FA and the MN-AAA auth extension is included in the RegRequest. > >Then the FA can take the correct action since it kows if the SA are valid or > >not. The draft does not exclude this today. To include both keys is also > >mentioned in the MN AAA Keys draft. However, this means more processing for the > >MN and that there always will be one auth extension in the RegRequest that is > >not used. To me, that doesn't sound good from a security point of view... > > > >If we don't specify a solution to this, we can end up in a deadlock situation > >where the MN tries to register with the (invalid) SA which always will be > >rejected by the FA. > > > >Personally I'm in favor of option 2, alternatively option 1, with option 3 as > >"backup". > >However, including the timeout in the AAA key extensions will result in changes > >to another draft, which might have impact on the challenge response draft last > >call procedure. > >My suggestion is that we include the timeout in the AAA Keys draft (option 2) > >and add the extra rule for the MN (option 3) as optional (SHOULD) in the draft. > > I would agree that the two options you described above are the logical choices. > #2 is the best way, and #3 provides the safeguard. However, my assumption > was that code 67, defined in RFC 2002, could be used for this purpose. Since > a code already exists for the Foreign Agent to communicate with the Foreign > Agent that the authentication has failed, why should this document define > a new one? > Does the draft really specifiy a new error code? BAD_AUTHENTICATION is defined as code 67 in the challenge response draft. And in rfc2002, error code 67 is defined as "mobile node failed authentication". My understading was that these were the same. Am I missing something? Regards, --> Tomas > PatC > > > > > > > >Regards, > > > > --> Tomas > > > > > >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > Tomas Goldbeck-Löwe ph. +1 650 463 6138 > > Ericsson Inc. mobile. +1 510 305 6109 > > 1555 Adams Drive fax. +1 650 463 6851 > > Menlo Park, CA 94025 > > tomas.goldbeck-lowe@ericsson.com > >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > > > > > > >> -----Original Message----- > >> From:> Basavaraj Patil [SMTP:bpatil@NORTELNETWORKS.COM] > >> Sent: Thursday, January 13, 2000 8:16 AM > >> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > >> Subject: [MOBILE-IP] WG Last Call (draft-ietf-mobileip-challenge-08.txt) > >> > >> > >> Mobile IP Challenge/Response Extensions draft > >> (draft-ietf-mobileip-challenge-08.txt) has undergone a couple of > >> revisions since the previous WG last call. As a result we are sending out > >> another WG last call on this I-D. Please provide comments and feedback > >> within the next two weeks. > >> > >> WG last call issued on: Jan 13, 2000 > >> > >> Regards, > >> Basavaraj > >> Phil > >> From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 24 13:12: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 NAA17057 for ; Mon, 24 Jan 2000 13:12:18 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3ECA7520@standards.nortelnetworks.com>; Mon, 24 Jan 2000 13:09:28 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5859 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 13:08:08 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0F0F8640@standards.nortelnetworks.com>; Mon, 24 Jan 2000 13:08:08 -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 KAA26352; Mon, 24 Jan 2000 10:09:42 -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 KAA02254; Mon, 24 Jan 2000 10:09:42 -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 KAA26000; Mon, 24 Jan 2000 10:09:22 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-ID: <200001241809.KAA26000@nasnfs.eng.sun.com> Date: Mon, 24 Jan 2000 10:04:26 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] challenge / response; MN auth timeout X-To: Tomas =?iso-8859-1?Q?Goldbeck=2DL=F6we?= To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit >Hi Pat, > >Patrice Calhoun wrote: >> >> >Hi all, >> > >> >(when I write SA below, I mean the security association between the MN and >the >> >FA) >> > >> >I have some comments in the challenge response draft about which auth >extension >> >to include in the Reg Request from the MN. >> >In chapter 3.1 of the draft there is a lot about "if the mobile node does >not >> >have a security association with the FA...." and "if the mobile node has a >> >security association with the FA...." in order to decide which auth extension >to >> >include in the Reg Request. >> >My concern is how the MN does know if it has a VALID security association. I >> >think this is a more appropriate question than if it just do have a SA or >not. A >> >security association that is not valid will be rejected by the FA anyway. >> > >> >The FA knows if the SA is valid or not, since it received a timeout together >> >with the SA from the AAA. The problem seams to be that the FA can not >forward >> >this timeout to the MN. >> > >> >I am aware that there is a proposal in the draft about MobileIP Diameter >> >Requirements that says that the timeout for the keys must be an integer >multiple >> >of the registration lifetime offered by the FA to the MN. But I don't see >how >> >this solves the problem, since (a) the HA can give the MN an other lifetime >than >> >the one offered by the FA and (b) all we know from rfc2002 is that the MN >will >> >re-register when the lifetime is near to expire. (not _exactly_ when it >> >re-registers) >> >> The DIAMETER extension doesn't work in the method you described. The >> lifetime returned is the expiration time, in a format consistent >> with NTP time. It is up to the Mobile Node to determine whether it should >> request new keying information, by including the MN-AAA authentication >> extension in the registration request. >> >That's just my point, we can not use the DIAMETER extension. I believe that "DIAMETER be itself" is what you meant, right? This draft was intended to be used with the draft you refer to in option 2 below since the mobile node does not talk directly to the DIAMETER infrastructure, and therefore must be the keying material through Mobile IP. > >My point is simply that when we distribute keys to the Mobile Node with >ANY protocol (DIAMETER or whatever), we also include a lifetime for the >key in the same extension. That will make it possible for the Mobile >Node to choose between the MN-FA or the MN-AAA authentication >extensions. So, the AAA protocol is not the issue here, right? We simply need to be able to provide the keying material to the Mobile Node, and the keys MUST have an explicit expiration time. > > >> > >> > >> >As I see it, there are four different ways to solve this (someone can >probably >> >come up with another one) >> >1) Add an extension to the Reg Reply to let the FA forward the SA timeout to >the >> >MN. This will make it possible for the MN to include the correct auth >extension >> >in the following Reg Requests. However, more extensions means larger messages >to >> >the MN which, in a cellular environment, are connected over an air >interface. >> >2) Include a "SA lifetime" in the session key extensions in the AAA Keys >draft >> >(draft-calhoun-mobileip-aaa-key-00.txt). By including the information in an >> >existing extension, we will not extend the Reg Reply even more. (they are >> >already quite large) >> >3) Add a rule for the MN Reg Request procedure. If the MN gets a Reg Reply >with >> >code BAD_AUTHENTICATION, the MN SHOULD include the MN-AAA auth in the next >Reg >> >Request. This will mean some extra delay, since the first Reg Request will >be >> >rejected. >> >4) Both the MN-FA and the MN-AAA auth extension is included in the >RegRequest. >> >Then the FA can take the correct action since it kows if the SA are valid or >> >not. The draft does not exclude this today. To include both keys is also >> >mentioned in the MN AAA Keys draft. However, this means more processing for >the >> >MN and that there always will be one auth extension in the RegRequest that >is >> >not used. To me, that doesn't sound good from a security point of view... >> > >> >If we don't specify a solution to this, we can end up in a deadlock >situation >> >where the MN tries to register with the (invalid) SA which always will be >> >rejected by the FA. >> > >> >Personally I'm in favor of option 2, alternatively option 1, with option 3 >as >> >"backup". >> >However, including the timeout in the AAA key extensions will result in >changes >> >to another draft, which might have impact on the challenge response draft >last >> >call procedure. >> >My suggestion is that we include the timeout in the AAA Keys draft (option >2) >> >and add the extra rule for the MN (option 3) as optional (SHOULD) in the >draft. >> >> I would agree that the two options you described above are the logical >choices. >> #2 is the best way, and #3 provides the safeguard. However, my assumption >> was that code 67, defined in RFC 2002, could be used for this purpose. Since >> a code already exists for the Foreign Agent to communicate with the Foreign >> Agent that the authentication has failed, why should this document define >> a new one? >> >Does the draft really specifiy a new error code? >BAD_AUTHENTICATION is defined as code 67 in the challenge response >draft. >And in rfc2002, error code 67 is defined as "mobile node failed >authentication". >My understading was that these were the same. Am I missing something? you are correct. They are one and the same. I now understand that you were just asking for specific text to be added to the draft, not a new error code. PatC > >Regards, > --> Tomas > >> PatC >> > >> > >> > >> >Regards, >> > >> > --> Tomas >> > >> > >> >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ >> > Tomas Goldbeck-Löwe ph. +1 650 463 6138 >> > Ericsson Inc. mobile. +1 510 305 6109 >> > 1555 Adams Drive fax. +1 650 463 6851 >> > Menlo Park, CA 94025 >> > tomas.goldbeck-lowe@ericsson.com >> >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ >> > >> > >> > >> >> -----Original Message----- >> >> From:> Basavaraj Patil [SMTP:bpatil@NORTELNETWORKS.COM] >> >> Sent: Thursday, January 13, 2000 8:16 AM >> >> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >> >> Subject: [MOBILE-IP] WG Last Call >(draft-ietf-mobileip-challenge-08.txt) >> >> >> >> >> >> Mobile IP Challenge/Response Extensions draft >> >> (draft-ietf-mobileip-challenge-08.txt) has undergone a couple of >> >> revisions since the previous WG last call. As a result we are sending out >> >> another WG last call on this I-D. Please provide comments and feedback >> >> within the next two weeks. >> >> >> >> WG last call issued on: Jan 13, 2000 >> >> >> >> Regards, >> >> Basavaraj >> >> Phil >> >> From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 24 14:27: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 OAA20484 for ; Mon, 24 Jan 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.BFBBC030@standards.nortelnetworks.com>; Mon, 24 Jan 2000 14:24:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5979 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 14:24:10 -0500 Received: from gwa.ericsson.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.461C2680@standards.nortelnetworks.com>; Mon, 24 Jan 2000 14:14:06 -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 NAA03987; Mon, 24 Jan 2000 13:15:27 -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 NAA11876; Mon, 24 Jan 2000 13:15:28 -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 NAA08015; Mon, 24 Jan 2000 13:15:27 -0600 (CST) X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <200001241809.KAA26000@nasnfs.eng.sun.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <388CA4CD.15E5A1E8@ericsson.com> Date: Mon, 24 Jan 2000 11:15:25 -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] challenge / response; MN auth timeout X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hi Pat, Patrice Calhoun wrote: > > >Hi Pat, > > > >Patrice Calhoun wrote: > >> > >> >Hi all, > >> > > >> >(when I write SA below, I mean the security association between the MN and > >the > >> >FA) > >> > > >> >I have some comments in the challenge response draft about which auth > >extension > >> >to include in the Reg Request from the MN. > >> >In chapter 3.1 of the draft there is a lot about "if the mobile node does > >not > >> >have a security association with the FA...." and "if the mobile node has a > >> >security association with the FA...." in order to decide which auth extension > >to > >> >include in the Reg Request. > >> >My concern is how the MN does know if it has a VALID security association. I > >> >think this is a more appropriate question than if it just do have a SA or > >not. A > >> >security association that is not valid will be rejected by the FA anyway. > >> > > >> >The FA knows if the SA is valid or not, since it received a timeout together > >> >with the SA from the AAA. The problem seams to be that the FA can not > >forward > >> >this timeout to the MN. > >> > > >> >I am aware that there is a proposal in the draft about MobileIP Diameter > >> >Requirements that says that the timeout for the keys must be an integer > >multiple > >> >of the registration lifetime offered by the FA to the MN. But I don't see > >how > >> >this solves the problem, since (a) the HA can give the MN an other lifetime > >than > >> >the one offered by the FA and (b) all we know from rfc2002 is that the MN > >will > >> >re-register when the lifetime is near to expire. (not _exactly_ when it > >> >re-registers) > >> > >> The DIAMETER extension doesn't work in the method you described. The > >> lifetime returned is the expiration time, in a format consistent > >> with NTP time. It is up to the Mobile Node to determine whether it should > >> request new keying information, by including the MN-AAA authentication > >> extension in the registration request. > >> > >That's just my point, we can not use the DIAMETER extension. > > I believe that "DIAMETER be itself" is what you meant, right? Yes. >This draft > was intended to be used with the draft you refer to in option 2 below > since the mobile node does not talk directly to the DIAMETER infrastructure, > and therefore must be the keying material through Mobile IP. > > > > >My point is simply that when we distribute keys to the Mobile Node with > >ANY protocol (DIAMETER or whatever), we also include a lifetime for the > >key in the same extension. That will make it possible for the Mobile > >Node to choose between the MN-FA or the MN-AAA authentication > >extensions. > > So, the AAA protocol is not the issue here, right? We simply need to be > able to provide the keying material to the Mobile Node, and the keys > MUST have an explicit expiration time. > Right, the AAA protocol is not the issue. Maybe I should have made my point above a little clearer. The AAA protocol distributes the keying information (key and lifetime) to the home agent and the foreign agent. The key and lifetime is sent to the mobile node, in the key extensions added to the Registration Reply as described in the AAA Reg Keys draft (draft-calhoun-mobileip-aaa-key-00.txt). This means adding a lifetime field in that draft. I'd be happy to give you some text to add to the draft. --> Tomas > > > > > >> > > >> > > >> >As I see it, there are four different ways to solve this (someone can > >probably > >> >come up with another one) > >> >1) Add an extension to the Reg Reply to let the FA forward the SA timeout to > >the > >> >MN. This will make it possible for the MN to include the correct auth > >extension > >> >in the following Reg Requests. However, more extensions means larger messages > >to > >> >the MN which, in a cellular environment, are connected over an air > >interface. > >> >2) Include a "SA lifetime" in the session key extensions in the AAA Keys > >draft > >> >(draft-calhoun-mobileip-aaa-key-00.txt). By including the information in an > >> >existing extension, we will not extend the Reg Reply even more. (they are > >> >already quite large) > >> >3) Add a rule for the MN Reg Request procedure. If the MN gets a Reg Reply > >with > >> >code BAD_AUTHENTICATION, the MN SHOULD include the MN-AAA auth in the next > >Reg > >> >Request. This will mean some extra delay, since the first Reg Request will > >be > >> >rejected. > >> >4) Both the MN-FA and the MN-AAA auth extension is included in the > >RegRequest. > >> >Then the FA can take the correct action since it kows if the SA are valid or > >> >not. The draft does not exclude this today. To include both keys is also > >> >mentioned in the MN AAA Keys draft. However, this means more processing for > >the > >> >MN and that there always will be one auth extension in the RegRequest that > >is > >> >not used. To me, that doesn't sound good from a security point of view... > >> > > >> >If we don't specify a solution to this, we can end up in a deadlock > >situation > >> >where the MN tries to register with the (invalid) SA which always will be > >> >rejected by the FA. > >> > > >> >Personally I'm in favor of option 2, alternatively option 1, with option 3 > >as > >> >"backup". > >> >However, including the timeout in the AAA key extensions will result in > >changes > >> >to another draft, which might have impact on the challenge response draft > >last > >> >call procedure. > >> >My suggestion is that we include the timeout in the AAA Keys draft (option > >2) > >> >and add the extra rule for the MN (option 3) as optional (SHOULD) in the > >draft. > >> > >> I would agree that the two options you described above are the logical > >choices. > >> #2 is the best way, and #3 provides the safeguard. However, my assumption > >> was that code 67, defined in RFC 2002, could be used for this purpose. Since > >> a code already exists for the Foreign Agent to communicate with the Foreign > >> Agent that the authentication has failed, why should this document define > >> a new one? > >> > >Does the draft really specifiy a new error code? > >BAD_AUTHENTICATION is defined as code 67 in the challenge response > >draft. > >And in rfc2002, error code 67 is defined as "mobile node failed > >authentication". > >My understading was that these were the same. Am I missing something? > > you are correct. They are one and the same. I now understand that you were just > asking for specific text to be added to the draft, not a new error code. > > PatC > > > > >Regards, > > --> Tomas > > > >> PatC > >> > > >> > > >> > > >> >Regards, > >> > > >> > --> Tomas > >> > > >> > > >> >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > >> > Tomas Goldbeck-Löwe ph. +1 650 463 6138 > >> > Ericsson Inc. mobile. +1 510 305 6109 > >> > 1555 Adams Drive fax. +1 650 463 6851 > >> > Menlo Park, CA 94025 > >> > tomas.goldbeck-lowe@ericsson.com > >> >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > >> > > >> > > >> > > >> >> -----Original Message----- > >> >> From:> Basavaraj Patil [SMTP:bpatil@NORTELNETWORKS.COM] > >> >> Sent: Thursday, January 13, 2000 8:16 AM > >> >> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > >> >> Subject: [MOBILE-IP] WG Last Call > >(draft-ietf-mobileip-challenge-08.txt) > >> >> > >> >> > >> >> Mobile IP Challenge/Response Extensions draft > >> >> (draft-ietf-mobileip-challenge-08.txt) has undergone a couple of > >> >> revisions since the previous WG last call. As a result we are sending out > >> >> another WG last call on this I-D. Please provide comments and feedback > >> >> within the next two weeks. > >> >> > >> >> WG last call issued on: Jan 13, 2000 > >> >> > >> >> Regards, > >> >> Basavaraj > >> >> Phil > >> >> From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 24 14:36: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 OAA21004 for ; Mon, 24 Jan 2000 14:36:19 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.03891F50@standards.nortelnetworks.com>; Mon, 24 Jan 2000 14:33:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6035 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 14:31:49 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BFC36BE0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 14:31:49 -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 LAA06974; Mon, 24 Jan 2000 11:33:27 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA16039; Mon, 24 Jan 2000 11:33: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 LAA28860; Mon, 24 Jan 2000 11:33:19 -0800 (PST) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-ID: <200001241933.LAA28860@nasnfs.eng.sun.com> Date: Mon, 24 Jan 2000 11:28:10 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] challenge / response; MN auth timeout X-To: Tomas =?iso-8859-1?Q?Goldbeck=2DL=F6we?= To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit So, if we fix up draft-calhoun-mobileip-aaa-key-00.txt, you would be happy, or is any additional text ALSO necessary in the challenge/response draft? PatC >Hi Pat, > >Patrice Calhoun wrote: >> >> >Hi Pat, >> > >> >Patrice Calhoun wrote: >> >> >> >> >Hi all, >> >> > >> >> >(when I write SA below, I mean the security association between the MN >and >> >the >> >> >FA) >> >> > >> >> >I have some comments in the challenge response draft about which auth >> >extension >> >> >to include in the Reg Request from the MN. >> >> >In chapter 3.1 of the draft there is a lot about "if the mobile node does >> >not >> >> >have a security association with the FA...." and "if the mobile node has >a >> >> >security association with the FA...." in order to decide which auth >extension >> >to >> >> >include in the Reg Request. >> >> >My concern is how the MN does know if it has a VALID security association. >I >> >> >think this is a more appropriate question than if it just do have a SA or >> >not. A >> >> >security association that is not valid will be rejected by the FA anyway. >> >> > >> >> >The FA knows if the SA is valid or not, since it received a timeout >together >> >> >with the SA from the AAA. The problem seams to be that the FA can not >> >forward >> >> >this timeout to the MN. >> >> > >> >> >I am aware that there is a proposal in the draft about MobileIP Diameter >> >> >Requirements that says that the timeout for the keys must be an integer >> >multiple >> >> >of the registration lifetime offered by the FA to the MN. But I don't see >> >how >> >> >this solves the problem, since (a) the HA can give the MN an other >lifetime >> >than >> >> >the one offered by the FA and (b) all we know from rfc2002 is that the MN >> >will >> >> >re-register when the lifetime is near to expire. (not _exactly_ when it >> >> >re-registers) >> >> >> >> The DIAMETER extension doesn't work in the method you described. The >> >> lifetime returned is the expiration time, in a format consistent >> >> with NTP time. It is up to the Mobile Node to determine whether it should >> >> request new keying information, by including the MN-AAA authentication >> >> extension in the registration request. >> >> >> >That's just my point, we can not use the DIAMETER extension. >> >> I believe that "DIAMETER be itself" is what you meant, right? > >Yes. > >>This draft >> was intended to be used with the draft you refer to in option 2 below >> since the mobile node does not talk directly to the DIAMETER infrastructure, >> and therefore must be the keying material through Mobile IP. >> >> > >> >My point is simply that when we distribute keys to the Mobile Node with >> >ANY protocol (DIAMETER or whatever), we also include a lifetime for the >> >key in the same extension. That will make it possible for the Mobile >> >Node to choose between the MN-FA or the MN-AAA authentication >> >extensions. >> >> So, the AAA protocol is not the issue here, right? We simply need to be >> able to provide the keying material to the Mobile Node, and the keys >> MUST have an explicit expiration time. >> > >Right, the AAA protocol is not the issue. >Maybe I should have made my point above a little clearer. The AAA >protocol distributes the keying information (key and lifetime) to the >home agent and the foreign agent. >The key and lifetime is sent to the mobile node, in the key extensions >added to the Registration Reply as described in the AAA Reg Keys draft >(draft-calhoun-mobileip-aaa-key-00.txt). This means adding a lifetime >field in that draft. I'd be happy to give you some text to add to the >draft. > > --> Tomas > >> > >> > >> >> > >> >> > >> >> >As I see it, there are four different ways to solve this (someone can >> >probably >> >> >come up with another one) >> >> >1) Add an extension to the Reg Reply to let the FA forward the SA timeout >to >> >the >> >> >MN. This will make it possible for the MN to include the correct auth >> >extension >> >> >in the following Reg Requests. However, more extensions means larger >messages >> >to >> >> >the MN which, in a cellular environment, are connected over an air >> >interface. >> >> >2) Include a "SA lifetime" in the session key extensions in the AAA Keys >> >draft >> >> >(draft-calhoun-mobileip-aaa-key-00.txt). By including the information in >an >> >> >existing extension, we will not extend the Reg Reply even more. (they are >> >> >already quite large) >> >> >3) Add a rule for the MN Reg Request procedure. If the MN gets a Reg >Reply >> >with >> >> >code BAD_AUTHENTICATION, the MN SHOULD include the MN-AAA auth in the >next >> >Reg >> >> >Request. This will mean some extra delay, since the first Reg Request >will >> >be >> >> >rejected. >> >> >4) Both the MN-FA and the MN-AAA auth extension is included in the >> >RegRequest. >> >> >Then the FA can take the correct action since it kows if the SA are valid >or >> >> >not. The draft does not exclude this today. To include both keys is also >> >> >mentioned in the MN AAA Keys draft. However, this means more processing >for >> >the >> >> >MN and that there always will be one auth extension in the RegRequest >that >> >is >> >> >not used. To me, that doesn't sound good from a security point of view... >> >> > >> >> >If we don't specify a solution to this, we can end up in a deadlock >> >situation >> >> >where the MN tries to register with the (invalid) SA which always will be >> >> >rejected by the FA. >> >> > >> >> >Personally I'm in favor of option 2, alternatively option 1, with option >3 >> >as >> >> >"backup". >> >> >However, including the timeout in the AAA key extensions will result in >> >changes >> >> >to another draft, which might have impact on the challenge response draft >> >last >> >> >call procedure. >> >> >My suggestion is that we include the timeout in the AAA Keys draft >(option >> >2) >> >> >and add the extra rule for the MN (option 3) as optional (SHOULD) in the >> >draft. >> >> >> >> I would agree that the two options you described above are the logical >> >choices. >> >> #2 is the best way, and #3 provides the safeguard. However, my assumption >> >> was that code 67, defined in RFC 2002, could be used for this purpose. >Since >> >> a code already exists for the Foreign Agent to communicate with the >Foreign >> >> Agent that the authentication has failed, why should this document define >> >> a new one? >> >> >> >Does the draft really specifiy a new error code? >> >BAD_AUTHENTICATION is defined as code 67 in the challenge response >> >draft. >> >And in rfc2002, error code 67 is defined as "mobile node failed >> >authentication". >> >My understading was that these were the same. Am I missing something? >> >> you are correct. They are one and the same. I now understand that you were >just >> asking for specific text to be added to the draft, not a new error code. >> >> PatC >> >> > >> >Regards, >> > --> Tomas >> > >> >> PatC >> >> > >> >> > >> >> > >> >> >Regards, >> >> > >> >> > --> Tomas >> >> > >> >> > >> >> >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ >> >> > Tomas Goldbeck-Löwe ph. +1 650 463 6138 >> >> > Ericsson Inc. mobile. +1 510 305 6109 >> >> > 1555 Adams Drive fax. +1 650 463 6851 >> >> > Menlo Park, CA 94025 >> >> > tomas.goldbeck-lowe@ericsson.com >> >> >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ >> >> > >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From:> Basavaraj Patil [SMTP:bpatil@NORTELNETWORKS.COM] >> >> >> Sent: Thursday, January 13, 2000 8:16 AM >> >> >> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >> >> >> Subject: [MOBILE-IP] WG Last Call >> >(draft-ietf-mobileip-challenge-08.txt) >> >> >> >> >> >> >> >> >> Mobile IP Challenge/Response Extensions draft >> >> >> (draft-ietf-mobileip-challenge-08.txt) has undergone a couple of >> >> >> revisions since the previous WG last call. As a result we are sending >out >> >> >> another WG last call on this I-D. Please provide comments and feedback >> >> >> within the next two weeks. >> >> >> >> >> >> WG last call issued on: Jan 13, 2000 >> >> >> >> >> >> Regards, >> >> >> Basavaraj >> >> >> Phil >> >> >> From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 24 15:05: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 PAA22426 for ; Mon, 24 Jan 2000 15: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.142AF280@standards.nortelnetworks.com>; Mon, 24 Jan 2000 15:02:49 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6089 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 15:01:26 -0500 Received: from gwu.ericy.com (208.196.3.162) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7D627130@standards.nortelnetworks.com>; Mon, 24 Jan 2000 14:51:26 -0500 Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id NAA02710; Mon, 24 Jan 2000 13:53:04 -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 NAA25194; Mon, 24 Jan 2000 13:53:04 -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 NAA10160; Mon, 24 Jan 2000 13:53:02 -0600 (CST) X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <200001241933.LAA28860@nasnfs.eng.sun.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <388CAD9C.F7CD8FB8@ericsson.com> Date: Mon, 24 Jan 2000 11:53:00 -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] challenge / response; MN auth timeout X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Adding a lifetime field to the draft-calhoun-mobileip-aaa-key-00.txt makes I'm happy. Adding the text in option 3 below, about that the MN SHOULD include the MN-AAA auth in the next Reg Request if the MN gets a Reg Reply with code BAD_AUTHENTICATION, would make me even happier. --> Tomas Patrice Calhoun wrote: > > So, if we fix up draft-calhoun-mobileip-aaa-key-00.txt, you would be happy, > or is any additional text ALSO necessary in the challenge/response draft? > > PatC > >Hi Pat, > > > >Patrice Calhoun wrote: > >> > >> >Hi Pat, > >> > > >> >Patrice Calhoun wrote: > >> >> > >> >> >Hi all, > >> >> > > >> >> >(when I write SA below, I mean the security association between the MN > >and > >> >the > >> >> >FA) > >> >> > > >> >> >I have some comments in the challenge response draft about which auth > >> >extension > >> >> >to include in the Reg Request from the MN. > >> >> >In chapter 3.1 of the draft there is a lot about "if the mobile node does > >> >not > >> >> >have a security association with the FA...." and "if the mobile node has > >a > >> >> >security association with the FA...." in order to decide which auth > >extension > >> >to > >> >> >include in the Reg Request. > >> >> >My concern is how the MN does know if it has a VALID security association. > >I > >> >> >think this is a more appropriate question than if it just do have a SA or > >> >not. A > >> >> >security association that is not valid will be rejected by the FA anyway. > >> >> > > >> >> >The FA knows if the SA is valid or not, since it received a timeout > >together > >> >> >with the SA from the AAA. The problem seams to be that the FA can not > >> >forward > >> >> >this timeout to the MN. > >> >> > > >> >> >I am aware that there is a proposal in the draft about MobileIP Diameter > >> >> >Requirements that says that the timeout for the keys must be an integer > >> >multiple > >> >> >of the registration lifetime offered by the FA to the MN. But I don't see > >> >how > >> >> >this solves the problem, since (a) the HA can give the MN an other > >lifetime > >> >than > >> >> >the one offered by the FA and (b) all we know from rfc2002 is that the MN > >> >will > >> >> >re-register when the lifetime is near to expire. (not _exactly_ when it > >> >> >re-registers) > >> >> > >> >> The DIAMETER extension doesn't work in the method you described. The > >> >> lifetime returned is the expiration time, in a format consistent > >> >> with NTP time. It is up to the Mobile Node to determine whether it should > >> >> request new keying information, by including the MN-AAA authentication > >> >> extension in the registration request. > >> >> > >> >That's just my point, we can not use the DIAMETER extension. > >> > >> I believe that "DIAMETER be itself" is what you meant, right? > > > >Yes. > > > >>This draft > >> was intended to be used with the draft you refer to in option 2 below > >> since the mobile node does not talk directly to the DIAMETER infrastructure, > >> and therefore must be the keying material through Mobile IP. > >> > >> > > >> >My point is simply that when we distribute keys to the Mobile Node with > >> >ANY protocol (DIAMETER or whatever), we also include a lifetime for the > >> >key in the same extension. That will make it possible for the Mobile > >> >Node to choose between the MN-FA or the MN-AAA authentication > >> >extensions. > >> > >> So, the AAA protocol is not the issue here, right? We simply need to be > >> able to provide the keying material to the Mobile Node, and the keys > >> MUST have an explicit expiration time. > >> > > > >Right, the AAA protocol is not the issue. > >Maybe I should have made my point above a little clearer. The AAA > >protocol distributes the keying information (key and lifetime) to the > >home agent and the foreign agent. > >The key and lifetime is sent to the mobile node, in the key extensions > >added to the Registration Reply as described in the AAA Reg Keys draft > >(draft-calhoun-mobileip-aaa-key-00.txt). This means adding a lifetime > >field in that draft. I'd be happy to give you some text to add to the > >draft. > > > > --> Tomas > > > >> > > >> > > >> >> > > >> >> > > >> >> >As I see it, there are four different ways to solve this (someone can > >> >probably > >> >> >come up with another one) > >> >> >1) Add an extension to the Reg Reply to let the FA forward the SA timeout > >to > >> >the > >> >> >MN. This will make it possible for the MN to include the correct auth > >> >extension > >> >> >in the following Reg Requests. However, more extensions means larger > >messages > >> >to > >> >> >the MN which, in a cellular environment, are connected over an air > >> >interface. > >> >> >2) Include a "SA lifetime" in the session key extensions in the AAA Keys > >> >draft > >> >> >(draft-calhoun-mobileip-aaa-key-00.txt). By including the information in > >an > >> >> >existing extension, we will not extend the Reg Reply even more. (they are > >> >> >already quite large) > >> >> >3) Add a rule for the MN Reg Request procedure. If the MN gets a Reg > >Reply > >> >with > >> >> >code BAD_AUTHENTICATION, the MN SHOULD include the MN-AAA auth in the > >next > >> >Reg > >> >> >Request. This will mean some extra delay, since the first Reg Request > >will > >> >be > >> >> >rejected. > >> >> >4) Both the MN-FA and the MN-AAA auth extension is included in the > >> >RegRequest. > >> >> >Then the FA can take the correct action since it kows if the SA are valid > >or > >> >> >not. The draft does not exclude this today. To include both keys is also > >> >> >mentioned in the MN AAA Keys draft. However, this means more processing > >for > >> >the > >> >> >MN and that there always will be one auth extension in the RegRequest > >that > >> >is > >> >> >not used. To me, that doesn't sound good from a security point of view... > >> >> > > >> >> >If we don't specify a solution to this, we can end up in a deadlock > >> >situation > >> >> >where the MN tries to register with the (invalid) SA which always will be > >> >> >rejected by the FA. > >> >> > > >> >> >Personally I'm in favor of option 2, alternatively option 1, with option > >3 > >> >as > >> >> >"backup". > >> >> >However, including the timeout in the AAA key extensions will result in > >> >changes > >> >> >to another draft, which might have impact on the challenge response draft > >> >last > >> >> >call procedure. > >> >> >My suggestion is that we include the timeout in the AAA Keys draft > >(option > >> >2) > >> >> >and add the extra rule for the MN (option 3) as optional (SHOULD) in the > >> >draft. > >> >> > >> >> I would agree that the two options you described above are the logical > >> >choices. > >> >> #2 is the best way, and #3 provides the safeguard. However, my assumption > >> >> was that code 67, defined in RFC 2002, could be used for this purpose. > >Since > >> >> a code already exists for the Foreign Agent to communicate with the > >Foreign > >> >> Agent that the authentication has failed, why should this document define > >> >> a new one? > >> >> > >> >Does the draft really specifiy a new error code? > >> >BAD_AUTHENTICATION is defined as code 67 in the challenge response > >> >draft. > >> >And in rfc2002, error code 67 is defined as "mobile node failed > >> >authentication". > >> >My understading was that these were the same. Am I missing something? > >> > >> you are correct. They are one and the same. I now understand that you were > >just > >> asking for specific text to be added to the draft, not a new error code. > >> > >> PatC > >> > >> > > >> >Regards, > >> > --> Tomas > >> > > >> >> PatC > >> >> > > >> >> > > >> >> > > >> >> >Regards, > >> >> > > >> >> > --> Tomas > >> >> > > >> >> > > >> >> >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > >> >> > Tomas Goldbeck-Löwe ph. +1 650 463 6138 > >> >> > Ericsson Inc. mobile. +1 510 305 6109 > >> >> > 1555 Adams Drive fax. +1 650 463 6851 > >> >> > Menlo Park, CA 94025 > >> >> > tomas.goldbeck-lowe@ericsson.com > >> >> >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > >> >> > > >> >> > > >> >> > > >> >> >> -----Original Message----- > >> >> >> From:> Basavaraj Patil [SMTP:bpatil@NORTELNETWORKS.COM] > >> >> >> Sent: Thursday, January 13, 2000 8:16 AM > >> >> >> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > >> >> >> Subject: [MOBILE-IP] WG Last Call > >> >(draft-ietf-mobileip-challenge-08.txt) > >> >> >> > >> >> >> > >> >> >> Mobile IP Challenge/Response Extensions draft > >> >> >> (draft-ietf-mobileip-challenge-08.txt) has undergone a couple of > >> >> >> revisions since the previous WG last call. As a result we are sending > >out > >> >> >> another WG last call on this I-D. Please provide comments and feedback > >> >> >> within the next two weeks. > >> >> >> > >> >> >> WG last call issued on: Jan 13, 2000 > >> >> >> > >> >> >> Regards, > >> >> >> Basavaraj > >> >> >> Phil > >> >> >> -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Tomas Goldbeck-Löwe ph. +1 650 463 6138 Ericsson Inc. mobile. +1 510 305 6109 1555 Adams Drive fax. +1 650 463 6851 Menlo Park, CA 94025 tomas.goldbeck-lowe@ericsson.com Ericsson Radio Systems AB Tel: +46 8 7641467 SE-164 80 Stockholm Fax: +46 8 4045769 Mobile: +46 70 9860680 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 24 15:19: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 PAA23073 for ; Mon, 24 Jan 2000 15:19:25 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0AF11F30@standards.nortelnetworks.com>; Mon, 24 Jan 2000 15:16:52 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6137 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 15:15:19 -0500 Received: from madcow.borg.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6D14A2B0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 15:05:18 -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 PAA25923 for ; Mon, 24 Jan 2000 15:06:56 -0500 (EST) Received: from fredswin98 (cti-fw2.borg.com [205.217.206.199]) by mail.borg.com (8.9.3/8.9.3) with SMTP id PAA23457 for ; Mon, 24 Jan 2000 15:06:48 -0500 (EST) (envelope-from fredtims@critical.com) X-Sender: fredtims@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.20000124151601.007bfec0@mail.borg.com> Date: Mon, 24 Jan 2000 15:16:01 -0500 Reply-To: Fred Tims Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fred Tims Subject: [MOBILE-IP] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Fred Tims From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 24 21: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 VAA02313 for ; Mon, 24 Jan 2000 21: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.5DC2DF40@standards.nortelnetworks.com>; Mon, 24 Jan 2000 21:24:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6448 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 21:23:15 -0500 Received: from tsbgw.wide.toshiba.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.394F3500@standards.nortelnetworks.com>; Mon, 24 Jan 2000 21:23:14 -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 LAA04795; Tue, 25 Jan 2000 11:24:29 +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 LAA19835; Tue, 25 Jan 2000 11:24:28 +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 LAA26541; Tue, 25 Jan 2000 11:24:28 +0900 (JST) References: <5F05C89FB2F8D211B6430008C791912703EA7E0F@esealnt190> X-Mailer: Datula version 1.21.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200001250224.LAA26541@isl.rdc.toshiba.co.jp> Date: Tue, 25 Jan 2000 11:34:50 +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] challenge / response; MN auth timeout X-To: "Karim El-Malki (ERA)" , pcalhoun@eng.sun.com X-cc: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <5F05C89FB2F8D211B6430008C791912703EA7E0F@esealnt190> Hello, Karim and Pat, My comment and my new concerning are embedded: On Mon, 24 Jan 2000 13:50:13 +0100, Karim El-Malki (ERA) wrote: >> Hi Yoshi >> >> > The HA or FA knows the SA will expire at t-expire, so, Tprev cannot >> > be longer than t-expire - t-prev. Therefore, logically there is the >> > first accepted life time(Tprev), which coincides with the >> > end of Tsa. >> > >> > After this happens, all successive acceptable life time >> > will coincide >> > with the end of Tsa. >> > >> > In practice, I should say these are closely coincided, I think. >> >> In this you assume that the SA will last only for one MN Registration >> lifetime. As Charlie mentioned in a previous email, it is normal to >> expect the SA to last many Registration lifetimes. Therefore the MN >> must have a way to understand when it is to use the MN-AAA extension >> to re-establish the SA (as Tomas pointed out). Please correct me if >> I misunderstood your point. I was assuming an SA lifetime is multiple times of MN Registration lifetime from the beginning... But, judging from the last Pat's email, they have already come to a consensus to add a lifetime field in the expired draft-ietf-mobileip-aaa-key-00.txt. This solution may be better than mine, I agree. But, there is a new problem to this solution: If an MN receives an SA lifetime, the MN must keep the SA until the lifetime is expired. This means in some cases an MN must keep too many SAs. If an MN visits many subnets, and if their SA lifetimes are long, SAs to be kept will soon grow more than an MN's ability. I will appreciate, if there is a method about re-getting or re-newing keying information with its lifetime. If there is such a method, an MN can abandon some old SAs before being expired. Winthout such a method, if an MN abandons an SA between the MN and an FA, an MN cannot anymore register the FA whose SA the MN had abandon before, because the FA knows there is an SA between the FA and the MN. Or, am I missing some sentences ? Thanks. -Yoshi >> Given these discussions, it may be appropriate for people who are >> implementing the Challenge/Response draft if it identified the cases >> in which the MN-AAA extension may be used: >> >> - Expiry of SA (regkey lifetime expiry or BAD_AUTHENTICATION) >> - Change of COA >> >> Regards, >> Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 25 01:45: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 BAA10414 for ; Tue, 25 Jan 2000 01:45:11 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.762F9400@standards.nortelnetworks.com>; Tue, 25 Jan 2000 1:42:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6694 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 01:41:25 -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.E50006A0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 1:31:25 -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 HAA11549; Tue, 25 Jan 2000 07:29:42 +0100 (MET) Received: from rcur98nbn146w by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id HAA22370; Tue, 25 Jan 2000 07:29:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Message-ID: <000c01bf66fd$809a0600$79b5d693@rcur98nbn146w.ericsson.se> Date: Tue, 25 Jan 2000 07:29:16 +0100 Reply-To: Conny Larsson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Conny Larsson Subject: Re: [MOBILE-IP] Any Info on the Ericsson Mobile IPv6 impl. X-cc: Theo PAGTZIS To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <1274.948735553@cs.ucl.ac.uk> Content-Transfer-Encoding: 7bit Hi Theo, I'm one of the implementers to the Ericsson Mobile IPv6 code. We don't have any public material available but I can give you a short summary. Our development platform is FreeBSD and we are using the IPv6 implementation from the KAME team. We have implemented everything according to draft-ietf-mobileip-ipv6-09.txt except support for renumbering of the home subnet. IPSec should work but we have not been able to test it due to some problems when parsing a file containing SA and SP data. We have had it up and running for quite some time now and it has been very stable during the tests that we have performed. We made a delivery to the KAME team for a couple of months ago but unfortunately the delivery was not easy to import for the KAME team. To save a lot of job for Itojun and make future deliveries easy to import in the KAME repository we have decided to reorganise the structure of the code and make a new delivery of it no later than the 7th of February. The status today is that we have changed our repository and we are currently making the changes needed to get the code starting. Hopefully, once the code has been delivered to KAME, the code will be public available from their repository. If this is not the case, i.e. the KAME team does not chose to use our code , you can send me a e-mail and I will make a delivery to you. Regards Conny Larsson Ericsson > -----Original Message----- > From: IP Routing for Wireless/Mobile Hosts (mobile-ip) > [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Theo PAGTZIS > Sent: den 24 januari 2000 18:39 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] Any Info on the Ericsson Mobile IPv6 impl. > > > Can anyone point to more info about Ericssons mobile IPv6 > implementation?? > > > Cheers > > Theo > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 25 08:40: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 IAA25327 for ; Tue, 25 Jan 2000 08:40:47 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.88ECE4A0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 8:38:20 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7202 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 08:37:03 -0500 Received: from ccserv.csie.nctu.edu.tw (140.113.209.2) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F19569C0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 8:26:57 -0500 Received: from Jeny (Jeny.Dorm11.NCTU.edu.tw [140.113.192.168]) by ccserv.csie.nctu.edu.tw (8.9.3/8.9.0) with ESMTP id VAA11447 for ; Tue, 25 Jan 2000 21:28:09 +0800 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Message-ID: Date: Tue, 25 Jan 2000 21:28:11 +0800 Reply-To: rsliu@csie.nctu.edu.tw Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ren-Shiou Liu Subject: [MOBILE-IP] Is it possible? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello everyone, I was wondering if it is possible for a mobile node, with overlapping wireless cells, to receive multiple agent advertisements from different foreign agents? If it is possible, what should the mobile node do? And dose this imply that the underlying link layer has the capability of receiving data from multiple agents? Thank you for your reply! -- Jason Liu, Parallel and Distributed Processing Lab. Dept. of Computer Science & Information Engineering National Chiao-Tung University, Hsinchu, Taiwan E-Mail: rsliu@csie.nctu.edu.tw From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 25 10:17: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 KAA00009 for ; Tue, 25 Jan 2000 10:17:19 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FBC5E960@standards.nortelnetworks.com>; Tue, 25 Jan 2000 10:14:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7402 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 10:13:23 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CF9C3790@standards.nortelnetworks.com>; Tue, 25 Jan 2000 10:13: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 HAA14245; Tue, 25 Jan 2000 07:14:31 -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 HAA13751; Tue, 25 Jan 2000 07:14:30 -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 HAA12934; Tue, 25 Jan 2000 07:14:19 -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: <200001251514.HAA12934@nasnfs.eng.sun.com> Date: Tue, 25 Jan 2000 07:09:07 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] challenge / response; MN auth timeout X-To: Yoshiyuki Tsuda , "Karim El-Malki (ERA)" X-cc: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit >Hello, Karim and Pat, > > My comment and my new concerning are embedded: > >On Mon, 24 Jan 2000 13:50:13 +0100, Karim El-Malki (ERA) wrote: >>> Hi Yoshi >>> >>> > The HA or FA knows the SA will expire at t-expire, so, Tprev cannot >>> > be longer than t-expire - t-prev. Therefore, logically there is the >>> > first accepted life time(Tprev), which coincides with the >>> > end of Tsa. >>> > >>> > After this happens, all successive acceptable life time >>> > will coincide >>> > with the end of Tsa. >>> > >>> > In practice, I should say these are closely coincided, I think. >>> >>> In this you assume that the SA will last only for one MN Registration >>> lifetime. As Charlie mentioned in a previous email, it is normal to >>> expect the SA to last many Registration lifetimes. Therefore the MN >>> must have a way to understand when it is to use the MN-AAA extension >>> to re-establish the SA (as Tomas pointed out). Please correct me if >>> I misunderstood your point. > > I was assuming an SA lifetime is multiple times of MN Registration lifetime > from the beginning... > > But, judging from the last Pat's email, they have already come to a consensus > to add a lifetime field in the expired draft-ietf-mobileip-aaa-key-00.txt. > This solution may be better than mine, I agree. > > But, there is a new problem to this solution: > If an MN receives an SA lifetime, the MN must keep the SA until the lifetime > is expired. This means in some cases an MN must keep too many SAs. If an MN > visits many subnets, and if their SA lifetimes are long, SAs to be kept will > soon grow more than an MN's ability. > > I will appreciate, if there is a method about re-getting or re-newing > keying information with its lifetime. If there is such a method, an MN can > abandon some old SAs before being expired. Winthout such a method, if an > MN abandons an SA between the MN and an FA, an MN cannot anymore register the > FA whose SA the MN had abandon before, because the FA knows there is an SA > between the FA and the MN. > > Or, am I missing some sentences ? Yes, the fact that the Mobile Node can simply request new keying material by including the MN-AAA Authentication Extension in the Registration Request. This needs to be supported since we do not know that a Mobile Node no longer has an SA because of laziness, or due to a host reboot. PatC > >Thanks. >-Yoshi > > >>> Given these discussions, it may be appropriate for people who are >>> implementing the Challenge/Response draft if it identified the cases >>> in which the MN-AAA extension may be used: >>> >>> - Expiry of SA (regkey lifetime expiry or BAD_AUTHENTICATION) >>> - Change of COA >>> >>> Regards, >>> Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 25 12:17: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 MAA03970 for ; Tue, 25 Jan 2000 12:17:24 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C808C370@standards.nortelnetworks.com>; Tue, 25 Jan 2000 12:14:51 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7569 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 12:13:24 -0500 Received: from smtpgw2.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.88338410@standards.nortelnetworks.com>; Tue, 25 Jan 2000 12:13:04 -0500 Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw2.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id LAA17500 for ; Tue, 25 Jan 2000 11:14:08 -0600 (CST) Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Jan 2000 11:14:08 -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: Tue, 25 Jan 2000 11:14:03 -0600 Reply-To: "Lipford, Mark" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lipford, Mark" Subject: Re: [MOBILE-IP] Is it possible? X-To: "rsliu@csie.nctu.edu.tw" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM My understanding of mobile IP is that a client can be registered to multiple FA at once. This should not be an issue. -----Original Message----- From: Ren-Shiou Liu [mailto:rsliu@csie.nctu.edu.tw] Sent: Tuesday, January 25, 2000 7:28 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] Is it possible? Hello everyone, I was wondering if it is possible for a mobile node, with overlapping wireless cells, to receive multiple agent advertisements from different foreign agents? If it is possible, what should the mobile node do? And dose this imply that the underlying link layer has the capability of receiving data from multiple agents? Thank you for your reply! -- Jason Liu, Parallel and Distributed Processing Lab. Dept. of Computer Science & Information Engineering National Chiao-Tung University, Hsinchu, Taiwan E-Mail: rsliu@csie.nctu.edu.tw From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 25 12:35: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 MAA04478 for ; Tue, 25 Jan 2000 12:35:29 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4E4C2F10@standards.nortelnetworks.com>; Tue, 25 Jan 2000 12:32:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7611 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 12:31:58 -0500 Received: from isis.lip6.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C5A95A30@standards.nortelnetworks.com>; Tue, 25 Jan 2000 12:21:57 -0500 Received: from rp.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.9.3/jtpda-5.3.2) with ESMTP id SAA16095 for ; Tue, 25 Jan 2000 18:23:32 +0100 Received: from avalon (avalon.ipv6.lip6.fr [132.227.72.134]) by rp.lip6.fr (8.8.8/jtpda-5.2) with SMTP id SAA29052 for ; Tue, 25 Jan 2000 18:23:32 +0100 (MET) 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: Tue, 25 Jan 2000 18:23:35 +0100 Reply-To: Gwendal.Le-Grand@lip6.fr Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gwendal LE GRAND Subject: [MOBILE-IP] handoffs To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, I would like to know how much time is necessary to complete a handoff. Is there a minimum value since a certain number of Router Advertisement have to be missed ? Thanks Gwendal From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 25 12:44: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 MAA04716 for ; Tue, 25 Jan 2000 12:44:40 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.91E9F2B0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 12:41:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7620 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 12:41:56 -0500 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1612DF90@standards.nortelnetworks.com>; Tue, 25 Jan 2000 12:31:21 -0500 Received: from cse.uta.edu (cse.uta.edu [129.107.12.1]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id LAA09382 for ; Tue, 25 Jan 2000 11:32:59 -0600 (CST) Received: from localhost by cse.uta.edu (8.9.0/8.9.0) with SMTP id LAA04984; Tue, 25 Jan 2000 11:44:14 -0600 (CST) X-Sender: ramesh@cse MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Tue, 25 Jan 2000 11:44:14 -0600 Reply-To: Ramesh Yeraballi Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ramesh Yeraballi Subject: [MOBILE-IP] WoWMoM-2000: Call for Papers X-To: alg@comm.toronto.edu, cabernet-events@ncl.ac.uk, cellular@dfv.rwth-aachen.de, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, dbworld@cs.wisc.edu, DMANET@zpr.uni-koeln.de, end2end-interest@isi.edu, enternet@bbn.com, giga@tele.pitt.edu, hipparch@sophia.inria.fr, ieeetcpc@ccvm.sunysb.edu, itc@ieee.org, kuvs-elg@fokus.gmd.de, manet@itd.NRL.NAVY.MIL, mobile-ip@smallworks.com, multicomm@cc.bellcore.com, multicomm@research.panasonic.com, performance@haven.epm.ornl.gov, reres@laas.fr, sig-dsm@doc.ic.ac.uk, sigmetrics-bb@haven.epm.ornl.gov, tccc@ieee.org, tchen@seas.smu.edu, tcos-announce@Dartmouth.EDU, testnet@canarie.ca, theorynt@listserv.nodak.edu, xtp-relay@cs.concordia.ca To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello Everybody, We wish to publicize the following call for papers announcement through your help to the widest audience possible. Kindly forward it to interested parties and include it in your list of announcements. Thanks Ramesh ------------------------------------- Dr. Ramesh Yerraballi Assistant Professor, Dept. of CSE Univ. of Texas at Arlington Phone: (817)-272-5128 e-mail: ramesh@cse.uta.edu ------------------------------------- ------------------------------------------------------------------------- Call for Papers ------------------------------------------------------------------------- The Third ACM International Workshop on WIRELESS MOBILE MULTIMEDIA (WoWMoM-2000) (to be held in conjuction with MobiCom-2000) August 11, 2000 (Friday) Seaport Hotel at the World Trade Center Boston, Massachusetts, USA Sponsored by ACM SIGMOBILE with support from Nortel Networks, Microsoft Research, University of California at Riverside, and CReWMaN at the University of Texas at Arlington URL: http://www-cse.uta.edu/crewman/conferences/wowmom-2000 SUBMISSION DEADLINE: April 25, 2000 GENERAL CHAIR Sajal K. Das, Director Center for Research in Wireless Mobility and Networking (CReWMaN) Department of Computer Science and Engineering Tel: (817) 272-7405 The University of Texas at Arlington Fax: (817) 272-3784 Arlington, TX 76019-0015 E-mail: das@cse.uta.edu PROGRAM CO-CHAIRS Satish K. Tripathi, Dean Kalyan Basu, Director William R. Johnson, Jr. Family Professor Wireless Technologies Bourns College of Engineering Nortel Networks University of California 2201 Lakeside Blvd Riverside, CA 92521-0425 Richardson, TX 75083 USA USA Phone: (909) 787-6374 Phone : (972) 684-5399 Fax: (909) 787-3188 Fax : (972) 684-3775 E-mail: tripathi@engr.ucr.edu E-mail: kbasu@nortelnetworks.com ------------------------------------------------------------------------- IMPORTANT DATES: Paper Submissions Deadline: April 25, 2000 Acceptance Notification: June 1, 2000 Camera-ready Manuscripts: June 15, 2000 Workshop August 11, 2000 ------------------------------------------------------------------------- SCOPE: Over the last decade there has been a rapid growth of wireless communication technology. Voice communication using cellular phones has matured and become a significant part of our life today. In the recent past, the emergence of portable computing devices such as notebook computers and personal digital assistants have led to the opportunity of such services as electronic mail, fax and calendar/diary programs being provided to mobile or roving users. Observing this trend, it can be predicted that the traffic over next generation, high-speed wireless networks will be dominated by personal multimedia applications such as video/news-on-demand, telemetry services, traveler information systems, WWW browsing, and so on. The 3rd Generation Wireless activities are focused through the effort of UMTS and IMT-2000 are considering the ATM technologies for the network implementation. The recent activities at 3GIP forum is actively considering the use of IP technology for the future wireless network. The wideband wireless network using IP technology is becomming an important industry issue and the seamless integration of the wireless standards and wireless IP and mobility standard are necessary to create this future network. The role of the different IP technologies like SIP, HTML, XML, Netmeeting for wireless and mobility are not finalised and will require considerable discussion to obtain the resolution. Also, the wireless access techniques like Bluetooth, WAP etc may require seamless intregration to the 2.5G (GPRS) and 3G wireless standards. The objective of this workshop is to provide a forum for researchers and technologists to present new ideas and contributions in the form of technical paper, panel discussions, as well as online demos of service applications or technology related to wireless multimedia. The issues and challenges for the development of wireless multimedia networks not only encompass a broad spectrum of research topics such as quality-of-service provisioning, broadband wireless, network support, prootocols, or handover, but also involves a way to envision the evolution of multimedia networks in the future. TOPICS: Technical papers and/or product demos are solicited in all areas related to wireless multimedia and its interfaces (or co-existence) with the conventional wireline networks. Topics include but are not limited to: - Third Generation Systems - Multimedia Applications - Fixed or Mobile Wireless Multimedia Access - Wireless Network Evolution - Broadband Wireless - Wireless ATM and Wireless IP - Multicasting in Wireless Services - Delay and Jitter Management for Multimedia Services - Synchronization of Multimedia Wireless services using ATM and IP - Quality-of-Service amd Admission Control - Multimedia Network Architecture and Protocols - Compression Techniques - Mobility Management & Handover Issues - Routing - WWW Browsing - Telemetry Services - Broadcast Data - Mobile Agents ------------------------------------------------------------- SUBMISSION GUIDELINES: All submissions will be handled electronically. Authors should E-mail a PostScript version of their full paper to wowmom-2000@engr.ucr.edu . This E-mail address will become available by February 15, 2000. In order to ensure that the PostScript versions of the papers can be printed, authors should be careful that their papers meet the following restrictions: - PostScript version 2 or later. - Fits properly on "US Letter" size paper (8.5 X 11 inches) - Reference only Computer Modern or standard Adobe printer fonts (i.e. Courier, Times, Roman, or Helvetica); other fonts may be used but must be included in the PostScript file. - No longer than 20 pages including, pictures, tables and references. In addition, authors should separately E-mail the title, author names and full address, and abstract of their paper to the Program Co-Chairs: Satish K. Tripathi at tripathi@engr.ucr.edu and Kalyan Basu at kbasu@nortel.com. It is expected that all accepted papers will be presented at the workshop. The Workshop Proceedings will be published by the ACM Press. Selected papers will be considered for publication in the ACM/Baltzer WINET and MONET journals. (WoWMoM'99 and WoWMoM'98 proceedings are available on the ACM digital library.) TECHNICAL PROGRAM COMMITTEE * Azzedine Boukerche (Univ of North Texas, USA) * Pravin Bhagwat (IBM Watson Research Center, USA) * Andrew Campbell (Columbia Univ, USA) * Yanghee Choi (Seoul National Univ, Korea) * K.-C. Chua (National University of Singapore) * Marco Conti (CNUCE, Pisa, Italy) * Subir Das (Telcordia Technologies, USA) * Lorenzo Donatiello (Univ of Bologna, Italy) * Anthony Joseph (UC Berkeley, USA) * Anurag Kumar (Indian Inst of Science, Bangalore) * Mohan Kumar (Curtin Univ, Perth, Australia) * Giri Mandyam (Nokia Research, Irving, USA) * Hiroyuki Morikawa, University of Tokyo, Japan * Raja Neogi (Intel, Portland, USA) * Venkat Padmanabhan (Microsoft Research, USA) * Vasant Prabhu (UNiv of Texas at Arlington, USA) * Jason Redi (BBN Technologies, USA) * Sumit Roy (Univ of Washington, USA) * Sanjoy Sen (Nortel Networks, USA) * Krishna Sivalingam (Washington State Univ, USA) * Mani Srivastava (Univ of California at Los Angeles, USA) * Violet Syrotiuk (Univ of Texas at Dallas, USA) * Philip Whiting (Lucent/Bell Labs, USA) STEERING COMMITTEE * Prathima Agrawal (Telcordia) * Ian Akyildiz (Georgia Institute of Technology) * Kalyan Basu (Nortel Networks) * Maurizio Bonuccelli (University of Pisa) * Imrich Chlamtac (University of Texas at Dallas) * Sajal K. Das (Univ of Texas at Arlington) * Randy Katz (University of California at Berkeley) * Mahmoud Naghshineh (IBM Watson Research) * Christopher Rose (Rutgers University) * Mischa Schwartz (Columbia University) * Satish Tripathi (University of California at Riverside) FINANCE CHAIR * Tom Jacob, University of North Texas PUBLICITY CO-CHAIRS * Dhawal Moghe, Nortel Networks * Ramesh Yerraballi, Univ of Texas at Arlington * Amitava Mukherjee, Pricewaterhouse Coopers Ltd From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 25 13:07: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 NAA05423 for ; Tue, 25 Jan 2000 13:07:44 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CB23E1F0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 13:05:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7718 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 13:03:20 -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.8D64B150@standards.nortelnetworks.com>; Tue, 25 Jan 2000 13:03:19 -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 TAA29886; Tue, 25 Jan 2000 19:04:42 +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, 25 Jan 2000 18:04:42 0000 (GMT) Received: by esealnt172 with Internet Mail Service (5.5.2448.0) id ; Tue, 25 Jan 2000 19:04:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5F05C89FB2F8D211B6430008C791912703EA7E1F@esealnt190> Date: Tue, 25 Jan 2000 19:04:31 +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] challenge / response; MN auth timeout X-To: Yoshiyuki Tsuda , Patrice Calhoun To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Yoshi > But, there is a new problem to this solution: > If an MN receives an SA lifetime, the MN must keep the SA > until the lifetime > is expired. This means in some cases an MN must keep too > many SAs. If an MN > visits many subnets, and if their SA lifetimes are long, > SAs to be kept will > soon grow more than an MN's ability. The MN does not necessarily keep an MN-FA SA if it leaves the relative FA. My understanding is that normally the MN keeps one MN-FA SA unless it has simultaneous bindings (COAs) at the HA. > I will appreciate, if there is a method about re-getting or > re-newing > keying information with its lifetime. If there is such a > method, an MN can > abandon some old SAs before being expired. Winthout such a > method, if an > MN abandons an SA between the MN and an FA, an MN cannot > anymore register the > FA whose SA the MN had abandon before, because the FA knows > there is an SA > between the FA and the MN. Are you considering the case in which an MN returns to an FA which has maintained the MN-FA SA even though it no longer has a binding for the MN? (unless there are simultaneous bindings) Can an FA maintain SAs for some time after the expiry of the relative binding (reg. lifetime)? If so the MN should be aware of this time period and cache SAs. Anyone have any comments? Regards, Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 25 13:27: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 NAA05660 for ; Tue, 25 Jan 2000 13:27:38 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.98CEB8D0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 13:25:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7766 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 13:23:19 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F26CD6D0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 13:13:18 -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 LAA23378 for ; Tue, 25 Jan 2000 11:15:00 -0700 (MST) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.65.34]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id KAA17945; Tue, 25 Jan 2000 10:14:59 -0800 (PST) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA18186; Tue, 25 Jan 2000 10:14:58 -0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 25 Jan 2000 10:14:58 -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] handoffs X-To: Gwendal.Le-Grand@lip6.fr To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" There is a considerable amount of work in progress that will ensure that the delay in the hand-off will be minimized. The new I-D that I announced recently, which allows the FA to send a hand-off request to a MN will reduce the delay. Right now the said draft isn't a WG item, but I hope to make it by Adelaide. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 25 14:10: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 OAA06407 for ; Tue, 25 Jan 2000 14:10:38 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9CD56540@standards.nortelnetworks.com>; Tue, 25 Jan 2000 14:08:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7820 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 14:07:06 -0500 Received: from concorde.inria.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.76389970@standards.nortelnetworks.com>; Tue, 25 Jan 2000 14:07:06 -0500 Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id UAA05358; Tue, 25 Jan 2000 20:08:48 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id UAA32633; Tue, 25 Jan 2000 20:08:47 +0100 (MET) Message-ID: <200001251908.UAA32633@givry.inria.fr> Date: Tue, 25 Jan 2000 20:08:47 +0100 Reply-To: Francis.Dupont@INRIA.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] handoffs X-To: Gwendal.Le-Grand@lip6.fr To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Tue, 25 Jan 2000 18:23:35 +0100. In your previous mail you wrote: I would like to know how much time is necessary to complete a handoff. Is there a minimum value since a certain number of Router Advertisement have to be missed ? => I think this is very dependent of the kind of movements (according to experiments with IPv6 mobility where there are Router Advertisements but where they are not used as you have suggested, ie. detection is mostly based on prefixes). Regards Francis.Dupont@inria.fr PS: this is not a new question then there are some papers about this (just wait for more answers?) From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 25 16:37: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 QAA08104 for ; Tue, 25 Jan 2000 16:37:35 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EF7FDF50@standards.nortelnetworks.com>; Tue, 25 Jan 2000 16:33:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8106 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 16:32:31 -0500 Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.611B7FE0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 16:22:31 -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 XAA80368; Tue, 25 Jan 2000 23:24:12 +0200 (EET) X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.3 i686) MIME-Version: 1.0 References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <388E14A3.A18249F9@cc.hut.fi> Date: Tue, 25 Jan 2000 23:24:51 +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] handoffs X-To: Gwendal.Le-Grand@lip6.fr To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Gwendal LE GRAND wrote: > > Hello, > > I would like to know how much time is necessary to complete a handoff. Is > there a minimum value since a certain number of Router Advertisement have to > be missed ? > > Thanks > > Gwendal Hello, Yes, there has been lots of work going on in minimizing the handoff time. There are several 'variables' affecting the handoff time: - Robustness of the FA equipment - Network speed - Network latency between the Foreign network and MN's Home Network - Link layer quality (probability of packet loss) - etc... One of the most important variables is the network latency between the FA and HA. E.g. This latency can easily be N * 100ms. For example: --- www.cisco.com ping statistics --- 41 packets transmitted, 41 packets received, 0% packet loss round-trip min/avg/max = 173.1/175.1/182.7 ms And this was done with a 100Mbps connection to a switched core. :) Some customized proposals, like: R.Caceres and V.Padmanabhan, `Fast and scalable handoffs for wireless internetworks,' in Proceedings of the 2nd IEEE Annual International Conference on Mobile Computing and Networking (MOBICOM), Rye, NY, USA, November 1996. have achieved really short handoff times, but they mainly use link layer optimizations and/or then make specific assumptions on the underlying link layer - which the basic Mobile IP does not do. In optimizing the handoff time, localized handoffs have an important role. Handoffs can be localized entirely on the network layer with a hierarchical Mobile IP solution, where the signalling required in handoffs only travel a minimal distance to a point in the FA hierarchy, where the previous location (and thus the session information) of the MN is known. Dynamics team at Helsinki University of Technology has been implementing and testing Dynamics - HUT Mobile IP, a hierarchical Mobile IP on Linux. We have achieved handoff times of 20ms, when the full advantage of the hierarchy is achieved. Passing one more layer in the hierarhcy has brought some 19ms more to the handoff time, but this is mainly dependant on the core network speed and the robustness of the FA machines, and can be further decreased. These results are from our tests, where the FAs in the hierarchy have been relatively slow i486/120MHz based computers with WaveLAN adapters (downlink) and 10Mbps Ethernet connections (uplink). These results show that hierarchical Mobile IP, like Dynamics, can provide secure and fast handoffs to support e.g. glitchless audio streaming to mobile devece while roaming in campus area wireless LAN. A research paper about our hierarchical solution was presented in MoMuC'99 conference. The paper is available from Dynamics web site 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 Tue Jan 25 18:56: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 SAA10284 for ; Tue, 25 Jan 2000 18:56:13 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.87A3CCC0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 18:53:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8307 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 18:52:48 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F9CC4400@standards.nortelnetworks.com>; Tue, 25 Jan 2000 18:42: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 QAA16646 for ; Tue, 25 Jan 2000 16:44:30 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id PAA17427 for ; Tue, 25 Jan 2000 15:44:31 -0800 (PST) Received: (from samita@localhost) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) id PAA23539; Tue, 25 Jan 2000 15:44:29 -0800 (PST) X-Sun-Charset: US-ASCII Message-ID: <200001252344.PAA23539@jurassic.eng.sun.com> Date: Tue, 25 Jan 2000 15:44:29 -0800 Reply-To: Samita Chakrabarti Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Samita Chakrabarti Subject: [MOBILE-IP] Private addressing reference in rfc2002-bis ? X-cc: samita@jurassic.Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM draft-ietf-mobileip-privaddr-00.txt has expired on Dec 1999 and I see that it points to rfc2002 for inclusion of a new 'P' bit in the FA advertisement in order to advertise it's willingness to support privately addressed mobile nodes. Now should draft-ietf-mobileip-rfc2002-bis-01.txt include a 'P' bit for private addressing support ? According to the reverse tunneling specification, T bit alone is not capable of handling overlapping private addresses of MNs belonging to two different HAs. Also, I am curious to find out: -Current status of the private address draft-- will there be a new draft soon ? - Does it make sense for RFC2344 to specify that it should be able to handle communication between FA and two different MNs having same private addresses (but different home agents) visiting this FA ? -How do we specify the mipagent behavior in the simple case scenario when we have global foreign agent address, global home agent address ( one side of the HA has public address and the other side has private address and private MNs have home addresses on this private subnet ) and privately addressed MNs are talking to each other on different foreign links ? -Samita From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 25 20:05: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 UAA12006 for ; Tue, 25 Jan 2000 20:05:39 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.386E80A0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:03:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8576 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 20:02:04 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0CA8E7D0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:02:04 -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 RAA25512 for ; Tue, 25 Jan 2000 17:03:47 -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 RAA14757 for ; Tue, 25 Jan 2000 17:03: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 RAA01232; Tue, 25 Jan 2000 17:03: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: <200001260103.RAA01232@nasnfs.eng.sun.com> Date: Tue, 25 Jan 2000 16:58:19 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: [MOBILE-IP] draft-ietf-mobileip-vendor-ext-09.txt X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Is there anyway that we could change "Critical Vendor/Organization Specific Extension (CVSE)" to have the Length aligned on a 16 bit boundary? This would be more consistent with the new Generalized Authentication and Key drafts, and would provide consistent extension parsing. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 25 20:31: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 UAA12346 for ; Tue, 25 Jan 2000 20:31:00 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BEA43B30@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:28:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8754 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 20:26:58 -0500 Received: from sigma.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8724C5D0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:26:58 -0500 Received: (from kleung@localhost) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA18902; Tue, 25 Jan 2000 17:28:40 -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: <200001260128.RAA18902@sigma.cisco.com> Date: Tue, 25 Jan 2000 17:28:40 -0800 Reply-To: "Kent K. Leung" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Kent K. Leung" Subject: Re: [MOBILE-IP] draft-ietf-mobileip-vendor-ext-09.txt X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200001260103.RAA01232@nasnfs.eng.sun.com> from "Patrice Calhoun" at Jan 25, 2000 04:58:19 PM Content-Transfer-Encoding: 7bit The CVSE is not an Authentication extension, so I'm not clear why it should follow this convention? Doesn't this conflict with MIER draft? 2.2 New [Proposed] Mobile IP Extension format This draft proposes the following structure for Mobile IP extensions to be carried in the Mobile IP control messages. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- Kent -- > > Is there anyway that we could change "Critical Vendor/Organization Specific > Extension (CVSE)" to have the Length aligned on a 16 bit boundary? This > would be more consistent with the new Generalized Authentication and Key > drafts, and would provide consistent extension parsing. > > PatC > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 25 20:31: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 UAA12382 for ; Tue, 25 Jan 2000 20:31:02 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BECA60D0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:28:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8757 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 20:28:24 -0500 Received: from leonis.nus.edu.sg by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BA13DDA0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:28:23 -0500 Received: from localhost (engp7498@localhost) by leonis.nus.edu.sg (8.9.3/8.9.3) with SMTP id JAA15903; Wed, 26 Jan 2000 09:30:00 +0800 (SST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 26 Jan 2000 09:29:59 +0800 Reply-To: Foo Siang Fook Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Foo Siang Fook Subject: Re: [MOBILE-IP] handoffs X-To: Gwendal LE GRAND To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Gwendal, Yuh, there is a minimum value if u strictly follows RFC2002 protocol which uses ICMP messages (minimum value one second for each messages) for the router advertisement. Since it requires three advertisements to be missed (assuming without using any link layer protocol), the minimum value is >2 seconds to complete a handoff (this excludes the distant registration time period,CPU processing etc.). The average value is 2.5 seconds (also excludes the distant registration time period, CPU processing etc.) However, there are a lot of proposals to shorten the advertisement periods or to use link protocol for handoff. Note that we also need to consider the distant registration period during handoff. There are a few drafts to solve the distant registration period such as HFA, RAFA etc. regards, Foo Siang Fook On Tue, 25 Jan 2000, Gwendal LE GRAND wrote: > Hello, > > I would like to know how much time is necessary to complete a handoff. Is > there a minimum value since a certain number of Router Advertisement have to > be missed ? > > Thanks > > Gwendal > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 25 20:34: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 UAA12457 for ; Tue, 25 Jan 2000 20:34:06 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.08431FE0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:30:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8788 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 20:30:24 -0500 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.02357120@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:30:24 -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 RAA06302; Tue, 25 Jan 2000 17:32:02 -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 RAA19391; Tue, 25 Jan 2000 17:31: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 RAA01979; Tue, 25 Jan 2000 17:31:44 -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: <200001260131.RAA01979@nasnfs.eng.sun.com> Date: Tue, 25 Jan 2000 17:26:25 -0800 Reply-To: pcalhoun@Eng.Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] draft-ietf-mobileip-vendor-ext-09.txt X-To: "Kent K. Leung" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit yes, but we (many of us) repetedly requested that the MIER length be aligned, and you can bet that the MIER draft will be stopped during WG last call because this was never addressed. Perhaps this requires a separate thread on the subject, but I am just tired to stating the same thing over and over and over .... (get the picture :). So, while I agree that CVSE is not an authentication extension, alignment is good. alignment is my friend, and I would really like people to take that into account, when possible, during protocol design. Thanks, PatC >The CVSE is not an Authentication extension, so I'm not clear >why it should follow this convention? Doesn't this conflict >with MIER draft? > >2.2 New [Proposed] Mobile IP Extension format > > This draft proposes the following structure for Mobile IP > extensions to be carried in the Mobile IP control messages. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Sub-Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data ..... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >-- Kent -- > >> >> Is there anyway that we could change "Critical Vendor/Organization Specific >> Extension (CVSE)" to have the Length aligned on a 16 bit boundary? This >> would be more consistent with the new Generalized Authentication and Key >> drafts, and would provide consistent extension parsing. >> >> PatC >> >> > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 25 21:00: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 VAA12673 for ; Tue, 25 Jan 2000 21:00:00 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D1DA4DD0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:57:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8886 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 20:56:26 -0500 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A4B63670@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:56:25 -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 UAA24872; Tue, 25 Jan 2000 20:58:04 -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: <388E81CC.76E36319@comet.columbia.edu> Date: Tue, 25 Jan 2000 21:10:36 -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] handoffs X-To: Foo Siang Fook To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Best I've seen Cellular IP do between bases lab is 3 ms ;-) We demoed this at IEEE MOMUC99. Foo Siang Fook wrote: > > Gwendal, > Yuh, there is a minimum value if u strictly follows RFC2002 > protocol which uses ICMP messages (minimum value one second for each > messages) for the router advertisement. Since it requires three > advertisements to be missed (assuming without using any link layer > protocol), the minimum value is >2 seconds to complete a handoff (this > excludes the distant registration time period,CPU processing etc.). The > average value is 2.5 seconds (also excludes the distant registration time > period, CPU processing etc.) > > However, there are a lot of proposals to shorten the advertisement > periods or to use link protocol for handoff. Note that we also need to > consider the distant registration period during handoff. There are a few > drafts to solve the distant registration period such as HFA, RAFA etc. > > regards, > Foo Siang Fook > > On Tue, 25 Jan 2000, Gwendal LE GRAND wrote: > > > Hello, > > > > I would like to know how much time is necessary to complete a handoff. Is > > there a minimum value since a certain number of Router Advertisement have to > > be missed ? > > > > Thanks > > > > Gwendal > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 26 00:02: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 AAA16710 for ; Wed, 26 Jan 2000 00:02:38 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.477673C0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 23:59:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9072 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 23:58:01 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.031CE4C0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 23:58:01 -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 UAA28489; Tue, 25 Jan 2000 20:59:43 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id UAA09834; Tue, 25 Jan 2000 20:59:42 -0800 X-Virus-Scanned: Tue, 25 Jan 2000 20:59:42 -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) xma009643; Tue, 25 Jan 00 20:59:21 -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: <388E7F29.2BCF55B6@iprg.nokia.com> Date: Tue, 25 Jan 2000 20:59:21 -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] Is it possible? X-To: "Lipford, Mark" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Mark, 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). If people would like to keep this feature, I think it is important to demonstrate implementations that make use of the feature. Regards, Charlie P. "Lipford, Mark" wrote: > > My understanding of mobile IP is that a client can be registered to multiple > FA at once. This should not be an issue. > > -----Original Message----- > From: Ren-Shiou Liu [mailto:rsliu@csie.nctu.edu.tw] > Sent: Tuesday, January 25, 2000 7:28 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] Is it possible? > > Hello everyone, > I was wondering if it is possible for a mobile node, with > overlapping > wireless cells, to receive multiple agent advertisements from > different > foreign agents? If it is possible, what should the mobile node do? > And > dose this imply that the underlying link layer has the capability of > receiving > data from multiple agents? Thank you for your reply! > > -- > Jason Liu, Parallel and Distributed Processing Lab. > Dept. of Computer Science & Information Engineering > National Chiao-Tung University, Hsinchu, Taiwan > E-Mail: rsliu@csie.nctu.edu.tw From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 26 00:48: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 AAA17000 for ; Wed, 26 Jan 2000 00:48:29 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B9A532F0@standards.nortelnetworks.com>; Wed, 26 Jan 2000 0:46:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9172 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 00:45:20 -0500 Received: from tsbgw.wide.toshiba.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9F17DDC0@standards.nortelnetworks.com>; Wed, 26 Jan 2000 0:45:20 -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 OAA20972; Wed, 26 Jan 2000 14:46:24 +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 OAA01453; Wed, 26 Jan 2000 14:46:24 +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 OAA11729; Wed, 26 Jan 2000 14:46:23 +0900 (JST) References: <5F05C89FB2F8D211B6430008C791912703EA7E1F@esealnt190> X-Mailer: Datula version 1.21.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200001260546.OAA11729@isl.rdc.toshiba.co.jp> Date: Wed, 26 Jan 2000 14:56:45 +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] challenge / response; MN auth timeout X-To: "Karim El-Malki (ERA)" , Pat.Calhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <5F05C89FB2F8D211B6430008C791912703EA7E1F@esealnt190> Hello, Pat and Karim, My comments are embedded in the followings: On Tue, 25 Jan 2000 07:09:07 -0800, Patrice Calhoun wrote: >> >> Yes, the fact that the Mobile Node can simply request new keying material >> by including the MN-AAA Authentication Extension in the Registration >> Request. This needs to be supported since we do not know that a Mobile Node >> no longer has an SA because of laziness, or due to a host reboot. >> >> PatC Thanks Pat; I'm happy to hear the above. You know, according to rfc2002 and rfc2002bis in the 3.7.2.1 section, if an FA and an MN share an SA, and if the Mobile-Foreign authentication extension doesn't exist in a request, the FA will silently discard the request. And, I couldn't find any related descriptions in the challenge draft and an expired keying draft. So, I assumed an FA would discard such a request. I'm looking forward to seeing something like the above in a coming keying draft. On Tue, 25 Jan 2000 19:04:31 +0100, Karim El-Malki (ERA) wrote: >> Hi Yoshi >> >> > But, there is a new problem to this solution: >> > If an MN receives an SA lifetime, the MN must keep the SA >> > until the lifetime >> > is expired. This means in some cases an MN must keep too >> > many SAs. If an MN >> > visits many subnets, and if their SA lifetimes are long, >> > SAs to be kept will >> > soon grow more than an MN's ability. >> >> The MN does not necessarily keep an MN-FA SA if it leaves the >> relative FA. My understanding is that normally the MN keeps one >> MN-FA SA unless it has simultaneous bindings (COAs) at the HA. As for binding information, you are right. But, as for SAs, I don't think so according to the current drafts. >> > I will appreciate, if there is a method about re-getting or >> > re-newing >> > keying information with its lifetime. If there is such a >> > method, an MN can >> > abandon some old SAs before being expired. Winthout such a >> > method, if an >> > MN abandons an SA between the MN and an FA, an MN cannot >> > anymore register the >> > FA whose SA the MN had abandon before, because the FA knows >> > there is an SA >> > between the FA and the MN. >> >> Are you considering the case in which an MN returns to an FA which >> has maintained the MN-FA SA even though it no longer has a binding for >> the MN? (unless there are simultaneous bindings) >> Can an FA maintain SAs for some time after the expiry of the >> relative binding (reg. lifetime)? If so the MN should be aware of >> this time period and cache SAs. Anyone have any comments? >> >> Regards, >> Karim Yes, I was saying about this. From my understanding, an FA will maintain SAs for their lifetimes, even if there are no binding. An MN will try to cache SAs. In case of current laptop PCs, it may be OK, because there are plenty of memory and hard disk. But, in case of poor MNs, resources may be restricted, I'm afraid. But, Pat mentioned about requesting new keying material. This will enable an MN to discard old SAs before their lifetimes. Thanks. -Yoshi From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 26 01:26: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 BAA18759 for ; Wed, 26 Jan 2000 01:26:30 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0C186E30@standards.nortelnetworks.com>; Wed, 26 Jan 2000 1:24:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9250 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 01:22:31 -0500 Received: from sigma.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D0898B10@standards.nortelnetworks.com>; Wed, 26 Jan 2000 1:22:30 -0500 Received: (from kleung@localhost) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA10857; Tue, 25 Jan 2000 22:24: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: <200001260624.WAA10857@sigma.cisco.com> Date: Tue, 25 Jan 2000 22:24:13 -0800 Reply-To: "Kent K. Leung" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Kent K. Leung" Subject: Re: [MOBILE-IP] draft-ietf-mobileip-vendor-ext-09.txt X-To: pcalhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200001260131.RAA01979@nasnfs.eng.sun.com> from "Patrice Calhoun" at Jan 25, 2000 05:26:25 PM Content-Transfer-Encoding: 7bit Sure, no problem. Will update draft. Thanks. -- Kent -- > > yes, but we (many of us) repetedly requested that the MIER length be aligned, > and you can bet that the MIER draft will be stopped during WG last call > because this was never addressed. Perhaps this requires a separate thread > on the subject, but I am just tired to stating the same thing over and > over and over .... (get the picture :). > > So, while I agree that CVSE is not an authentication extension, > alignment is good. alignment is my friend, and I would really like > people to take that into account, when possible, during protocol > design. > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 26 04:22: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 EAA00448 for ; Wed, 26 Jan 2000 04:22:54 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A79B99F0@standards.nortelnetworks.com>; Wed, 26 Jan 2000 4:20:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9358 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 04:18:43 -0500 Received: from twilight.cs.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.08CE54D0@standards.nortelnetworks.com>; Wed, 26 Jan 2000 4:08:43 -0500 Received: from bright.cs.hut.fi ([130.233.41.135]:3146 "EHLO bright.cs.hut.fi") by mail.niksula.cs.hut.fi with ESMTP id ; Wed, 26 Jan 2000 11:10:15 +0200 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 26 Jan 2000 11:10:14 +0200 Reply-To: dan.forsberg@iki.fi Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Dan Forsberg Subject: Re: [MOBILE-IP] Is it possible? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: rsliu> I was wondering if it is possible for a mobile node, with rsliu> overlapping wireless cells, to receive multiple agent rsliu> advertisements from different foreign agents? If it is rsliu> possible, what should the mobile node do? And dose this rsliu> imply that the underlying link layer has the capability of rsliu> receiving data from multiple agents? Thank you for your rsliu> reply! The agent advertisements are sent to broadcast or multicast address. Thus, if the MN is one hop away from the FA, it is possible for the MN to hear more than one FA simultaneously (IP routing). There is no need for simultaneous bindings for this kind of behaviour. If we need to establish connections with both FAs, it would be necessary. To the handoff discussion. When the MN hears multiple FAs at the same time, it has the possibility to choose the best one. The decision for the "best" node is problem for the MN. If received signal strengths can be obtained from the link layer, the decision becomes easier. Thus, also the handoff decisions can be made much more faster than the agent advertisement interval. The hierarchical Dynamics - HUT Mobile IP uses the link layer signal quality information of WLANs and the handoff decisions is based on that in the MN. In addition the ability of the MN to hear multiple FAs at the same time enables soft handoffs and thus packet loss is minimized. No buffering nor multicasting type scenarios are needed to support smooth handoffs with soft handoff. Simple and effective ;). Dan -- Dan.Forsberg@iki.fi Dynamics - HUT Mobile IP From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 26 05:28: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 FAA00792 for ; Wed, 26 Jan 2000 05:28:54 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E3AD5290@standards.nortelnetworks.com>; Wed, 26 Jan 2000 5:26:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9436 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 05:25:15 -0500 Received: from smtp2.cluster.oleane.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B9FDC880@standards.nortelnetworks.com>; Wed, 26 Jan 2000 5:25:15 -0500 Received: from oleane (dyn-1-1-250.Vin.dialup.oleane.fr [195.25.4.250]) by smtp2.cluster.oleane.net with SMTP id LAA40220; Wed, 26 Jan 2000 11:26:54 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0071_01BF67EF.D509D7E0" 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: <007401bf67e7$74073940$0401a8c0@oleane.com> Date: Wed, 26 Jan 2000 11:23:55 +0100 Reply-To: Peter Lewis Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Peter Lewis Subject: [MOBILE-IP] IP Based Cellular Networks Conference To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0071_01BF67EF.D509D7E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IP Based Cellular Networks Conference. A scientific committe composed of = the most eminent experts in this technology will review the abstracts = submitted from the Call For Papers: http://www.upperside.fr/baipcn.htm ------=_NextPart_000_0071_01BF67EF.D509D7E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
IP Based Cellular Networks = Conference. A=20 scientific committe composed of the most eminent experts in this = technology will=20 review the abstracts submitted from the Call For Papers:
http://www.upperside.fr/baipc= n.htm
 
------=_NextPart_000_0071_01BF67EF.D509D7E0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 26 10:58: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 KAA05886 for ; Wed, 26 Jan 2000 10:58:20 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E6007B70@standards.nortelnetworks.com>; Wed, 26 Jan 2000 10:55:46 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9697 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 10:53:54 -0500 Received: from hub.ecutel.com (209.220.224.35) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A32946B0@standards.nortelnetworks.com>; Wed, 26 Jan 2000 10:53:54 -0500 Received: from 192.168.50.149 by smtp.ecutel.com Wed, 26 Jan 2000 11:03:03 -0500 Received: from qiangmmx [192.168.50.155] by hub.ecutel.com (SMTPD32-5.05) id AB231FBE00B4; Wed, 26 Jan 2000 11:04:51 -0500 X-Sender: qzhang@hub.ecutel.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.5.32.20000126103038.00c748e0@hub.ecutel.com> Date: Wed, 26 Jan 2000 10:30:38 -0500 Reply-To: Qiang Zhang Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Qiang Zhang Subject: Re: [MOBILE-IP] Is it possible? X-To: rsliu@csie.nctu.edu.tw To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Jason, I remember there was a thread "CDMA misinterpret" on the list(around last August) discussing the cellular underlayer link impact which you might be interested. >From my understanding, MIP itself has no problem to maintain multiple bindings, however a lot wireless mediums so far can't support the happening of multiple bindings via the same adapter, i.e. in the 802.11 LAN or the Cellular environment, you are not able to receive packets simultaneously from 2 access points or base stations. Chiang At 09:28 PM 1/25/00 +0800, Ren-Shiou Liu wrote: >Hello everyone, > I was wondering if it is possible for a mobile node, with overlapping >wireless cells, to receive multiple agent advertisements from different >foreign agents? If it is possible, what should the mobile node do? And >dose this imply that the underlying link layer has the capability of receiving >data from multiple agents? Thank you for your reply! > >-- >Jason Liu, Parallel and Distributed Processing Lab. >Dept. of Computer Science & Information Engineering >National Chiao-Tung University, Hsinchu, Taiwan >E-Mail: rsliu@csie.nctu.edu.tw > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 26 12:28: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 MAA07140 for ; Wed, 26 Jan 2000 12:28:26 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7D83C040@standards.nortelnetworks.com>; Wed, 26 Jan 2000 12:25:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9805 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 12:24:46 -0500 Received: from beamer.mchh.siemens.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.54E3D170@standards.nortelnetworks.com>; Wed, 26 Jan 2000 12:24:46 -0500 Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA05455; Wed, 26 Jan 2000 18:25:42 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([218.1.68.147]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA28532; Wed, 26 Jan 2000 18:26:19 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2448.0) id ; Wed, 26 Jan 2000 18:26:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: Date: Wed, 26 Jan 2000 18:26:26 +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: Samita Chakrabarti To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Samita, I don't know whether the authors of draft-ietf-mobileip-privaddr-00.txt intend to provide a new version, but I remember that Charlie, when presenting the draft in Oslo, pointed to a number of remaining issues related to the draft. As the handling of private addresses in Mobile IP was again mentioned to be an open issue at the Washington meeting, I assumed that there was no intention for further work on the draft, so I've therefore submitted the new draft-petri-mobileip-pipe-00.txt. You mention the proposal for the definition of a new 'P' bit in the FA advertisement, by which an FA indicates its ability/willingness to support privately addressed mobile nodes. The proposal looks like being quite useful to me, even if it may not be clear at this time, how the final handling of private addresses in Mobile IP may look like. Maybe, one idea could be to interpret that 'P' bit even in a more generic sense, i.e. that the FA can handle private addresses in general, e.g. also when communicating with a privately addressed HA. Kind regards - Bernhard ____________________________________________________________________________ ______________________ > -----Original Message----- > From: Samita Chakrabarti [SMTP:Samita.Chakrabarti@ENG.SUN.COM] > Sent: Wednesday, January 26, 2000 12:44 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] Private addressing reference in rfc2002-bis ? > > draft-ietf-mobileip-privaddr-00.txt has expired on Dec 1999 and I see > that > it points to rfc2002 for inclusion of a new 'P' bit in the FA > advertisement > in order to advertise it's willingness to support privately addressed > mobile nodes. Now should draft-ietf-mobileip-rfc2002-bis-01.txt include > a > 'P' bit for private addressing support ? > According to the reverse tunneling specification, T bit alone is > not capable of handling overlapping private addresses of MNs belonging > to two different HAs. > > Also, I am curious to find out: > > -Current status of the private address draft-- will there be a new draft > soon ? > > - Does it make sense for RFC2344 to specify that it should be able to > handle > communication between FA and two different MNs having same private > addresses > (but different home agents) visiting this FA ? > > -How do we specify the mipagent behavior in the simple case scenario when > we have global foreign agent address, global home agent address ( one > side > of the HA has public address and the other side has private address and > private MNs have home addresses on this private subnet ) and privately > addressed MNs are talking to each other on different foreign links ? > > > -Samita From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 26 19:21: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 TAA13702 for ; Wed, 26 Jan 2000 19:21:59 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.43C87F50@standards.nortelnetworks.com>; Wed, 26 Jan 2000 19:19:28 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10246 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 19:17:42 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.04550F00@standards.nortelnetworks.com>; Wed, 26 Jan 2000 19:17:42 -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 QAA27486; Wed, 26 Jan 2000 16:18:48 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id QAA19596; Wed, 26 Jan 2000 16:18:48 -0800 X-Virus-Scanned: Wed, 26 Jan 2000 16:18: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) xma018496; Wed, 26 Jan 00 16:17:57 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <8625682A.0076DFE9.00@mwgate02.mw.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <388F8EB5.1F679B69@iprg.nokia.com> Date: Wed, 26 Jan 2000 16:17:57 -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] Route Optimization draft comments X-To: Karl Freter X-cc: Dave Johnson , Wireless System Architecture Group To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Karl, I hope you can find a way to excuse my extreme tardiness in responding to your note. It's been on my list for a long time, but only now am I able to revise the Route Optimization draft, and thus to pay attention to these issues. > The first issue is the number of different methods for updating binding caches > during a registration. The draft discusses three means: (1) The MN sending a > binding warning extension during the registration request, (2) The MN sending a > Previous FA Notification extension during the registration request, and (3) the > MN sending binding update messges if it fails to get a binding ack from the FA > after sending the Previous FA Notification extension. The Previous FA Notification extension is designed for smooth handoff. The Binding Warning extension was requested by engineers from Nortel who pointed out that the home agent was often well placed to deliver the warnings. Lastly, since the Previous FA Notification is basically a one-shot mechanism to handle the _usual_ case of successful transmission between wired foreign agents, we did not want to make the new foreign agent responsible for retransmissions. This leads directly to making the mobile node responsible for them. Furthermore, if the mobile node does NOT send the binding update, it alone will suffer whatever the consequences might be. > I believe these methods are overkill and should be reduced to just the binding > warning extension (if even that). I also believe the HA should be required to > send binding updates when it detects a change in the FA assignment for a MN. The home agent can be pretty far away from the scene of the action, though. Furthermore, with regional registration, the home agent wouldn't be involved at all. > Here's the rational: Only the HA can send the initial Binding Update message to > a node. It may be in response to a Binding Warning Message/Extension, a Binding > Request, or done on its own, but the HA is the only point where the initial > Binding Update messages originate. This is not true if you like the idea of using Previous Foreign Agent Notification messages. > Since I believe there is no reason why one would want to leave a node pointing > to an old FA (please correct me if I'm wrong), the HA is the perfect point > during a registration to automatically update all binding caches to all nodes > via the Binding update messsage. The HA also knows the old FA, so it could send > the old FA a small lifetime (and the full lifetime to the other nodes). This > would ensure that packets in transit to the old FA would get to the new FA and > would alleviate all the old FA issues related to requiring special tunnels, > binding ACKs and data coming before the Registration Reply, required MN/FA > security associations, etc. This just isn't true, if the home agent doesn't even get the Registration Request until 100ms (say) after the mobile node sends it. Or, 500ms. Or, even worse on a bad day. > I would propose making the HA required to keep track of all nodes it sends a > binding update to and require that the HA send a BInding Update to those nodes > and the old FA whenever a MN roams to a new FA. It would be better to make the mobile node do it, especially if you believe that communications are more often local than remote. On the other hand, it would be nice to cut down traffic over the air interface during busy times like handovers. On the third hand, there are many issues involved and it is difficult to make blanket statements that are always true. > A second issue is how to handle binding updates for non-routable IP address > assignments. The HA can not send binding updates for MNs that are assigned non > routable IPaddresses, regardless of the Privacy bit setting. All packets must > be tunneled throught the HA to the FA. I believe you want to add this statement > to the draft. Right now, the Route Optimization draft doesn't have a lot to say about private addresses. The Privacy bit has to do with halting the dissemination of bindings to third parties, and is not related to the nature of the home address (i.e., whether it is a routable address). On the other hand, I would be happy to add some clarifying text if you will craft a statement that says what you want to be said. > A third issue relates to correspondant nodes tunneling data to the FA instead of > the HA. If the correspondant node uses GRE, that node must not try to use > sequence numbers. Since the FA can get data from any number of nodes (as the HA > or MN may initiate the binding update without telling the FA), the FA would need > to setup a sequence number history for each node that tunnels it data. This is > not reasonable. Thus, some words are required to discuss what portions of the > tunneling protocols are not allowed. [I did not review the other options, but > remembered that GRE could pose a problem.] Again, I would appreciate it if you could craft some appropriate text to be inserted as needed. I have not myself used GRE tunnels for this, so I do not have the experience. GRE was included as a tunneling option by other people in the working group. As far as I know, it has not been tested for interoperability. I agree that there should be some implementations and some testing so that the feature can be kept, but I won't be able to help much with the task of doing so. > The last item is minor. In sections 8 and 8.1, you mention "Previous FA > Notification messages". Shouldn't those really be extensions instead of > messages? Yes, that is true. I'll make the changes. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 26 21:37: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 VAA14874 for ; Wed, 26 Jan 2000 21:37:08 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.29CA2910@standards.nortelnetworks.com>; Wed, 26 Jan 2000 21:34:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10461 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 21:32:58 -0500 Received: from smtpgw1.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EA119970@standards.nortelnetworks.com>; Wed, 26 Jan 2000 21:32:58 -0500 Received: from pkcex003.sprintspectrum.com (pkcex003.sprintspectrum.com [208.10.75.138]) by smtpgw1.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id UAA28650; Wed, 26 Jan 2000 20:34:43 -0600 (CST) Received: by pkcex003.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jan 2000 20:34:43 -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, 26 Jan 2000 20:34:41 -0600 Reply-To: "Lipford, Mark" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lipford, Mark" Subject: Re: [MOBILE-IP] Is it possible? X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Charlie, As a carrier that hopes to deploy this, and as I think about what our architecture will look like I don't see this as a strong requirement. If this feature falls out I currently don't see an issue. I am glad to see that I do at least have an understanding (and was correct) that MIP currently does support this (in theory). Thanks -----Original Message----- From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] Sent: Tuesday, January 25, 2000 10:59 PM To: Lipford, Mark Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Is it possible? Hello Mark, 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). If people would like to keep this feature, I think it is important to demonstrate implementations that make use of the feature. Regards, Charlie P. "Lipford, Mark" wrote: > > My understanding of mobile IP is that a client can be registered to multiple > FA at once. This should not be an issue. > > -----Original Message----- > From: Ren-Shiou Liu [mailto:rsliu@csie.nctu.edu.tw] > Sent: Tuesday, January 25, 2000 7:28 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] Is it possible? > > Hello everyone, > I was wondering if it is possible for a mobile node, with > overlapping > wireless cells, to receive multiple agent advertisements from > different > foreign agents? If it is possible, what should the mobile node do? > And > dose this imply that the underlying link layer has the capability of > receiving > data from multiple agents? Thank you for your reply! > > -- > Jason Liu, Parallel and Distributed Processing Lab. > Dept. of Computer Science & Information Engineering > National Chiao-Tung University, Hsinchu, Taiwan > E-Mail: rsliu@csie.nctu.edu.tw From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 27 04:37: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 EAA01919 for ; Thu, 27 Jan 2000 04:37:49 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E25C5360@standards.nortelnetworks.com>; Thu, 27 Jan 2000 4:35:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10718 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 04:33:51 -0500 Received: from monza.broadswitch.com (195.178.164.73) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4FE85F20@standards.nortelnetworks.com>; Thu, 27 Jan 2000 4:23:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD15AE25@monza.broadswitch.com> Date: Thu, 27 Jan 2000 10:25:11 +0100 Reply-To: Thomas Eklund Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thomas Eklund Subject: Re: [MOBILE-IP] Is it possible? X-To: "Lipford, Mark" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM You probably right... Since It is part of move detection policy and there is nothing there that explicitly states how the policy should look like. But wat is noted is that if you have a capability to have simultanously bindings you have a kind of multimoming facility. /Thomas > -----Original Message----- > From: Lipford, Mark [mailto:MLipfo01@SPRINTSPECTRUM.COM] > Sent: Thursday, January 27, 2000 3:35 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Is it possible? > > > Hi Charlie, > > As a carrier that hopes to deploy this, and as I think about what our > architecture will look like I don't see this as a strong > requirement. If > this feature falls out I currently don't see an issue. I am > glad to see > that I do at least have an understanding (and was correct) that MIP > currently does support this (in theory). > > Thanks > > -----Original Message----- > From: Charles E. Perkins > [mailto:charliep@iprg.nokia.com] > Sent: Tuesday, January 25, 2000 10:59 PM > To: Lipford, Mark > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Is it possible? > > > Hello Mark, > > 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). > > If people would like to keep this feature, I > think it is > important > to demonstrate implementations that make use > of the feature. > > Regards, > Charlie P. > > > > "Lipford, Mark" wrote: > > > > My understanding of mobile IP is that a > client can be > registered to multiple > > FA at once. This should not be an issue. > > > > -----Original Message----- > > From: Ren-Shiou Liu > [mailto:rsliu@csie.nctu.edu.tw] > > Sent: Tuesday, January 25, 2000 7:28 AM > > To: > MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: [MOBILE-IP] Is it possible? > > > > Hello everyone, > > I was wondering if it is > possible for a mobile > node, with > > overlapping > > wireless cells, to receive multiple agent > advertisements from > > different > > foreign agents? If it is possible, > what should the > mobile node do? > > And > > dose this imply that the underlying > link layer has > the capability of > > receiving > > data from multiple agents? Thank > you for your > reply! > > > > -- > > Jason Liu, Parallel and Distributed > Processing > Lab. > > Dept. of Computer Science & Information > Engineering > > National Chiao-Tung University, > Hsinchu, Taiwan > > E-Mail: rsliu@csie.nctu.edu.tw > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 27 10:16: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 KAA07222 for ; Thu, 27 Jan 2000 10:16:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0B1ABB50@standards.nortelnetworks.com>; Thu, 27 Jan 2000 10:12:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11099 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 10:11:03 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D157E5A0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 10:11:03 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 09:12:29 -0600 Received: from zrchb200.us.nortel.com (actually zrchb200) by zmers013; Thu, 27 Jan 2000 10:12:10 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 27 Jan 2000 09:12:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF68D8.DD95C84E" Message-ID: <9A9367D1556AD21182C40000F80930AB010BC1F1@crchy28b.us.nortel.com> Date: Thu, 27 Jan 2000 09:11:57 -0600 Reply-To: Mohamed Khalil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohamed Khalil Subject: Re: [MOBILE-IP] draft-ietf-mobileip-vendor-ext-09.txt X-To: "pcalhoun@Eng.Sun.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_01BF68D8.DD95C84E Content-Type: text/plain; charset="ISO-8859-1" Hi All, I agree with Pat that we should take byte alignment in consideration because it is a little more efficient to execute extension which preserve byte alignment. We will fix this in the next version. -----Original Message----- From: Patrice Calhoun [mailto:Pat.Calhoun@ENG.SUN.COM] Sent: Tuesday, January 25, 2000 7:26 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] draft-ietf-mobileip-vendor-ext-09.txt yes, but we (many of us) repetedly requested that the MIER length be aligned, and you can bet that the MIER draft will be stopped during WG last call because this was never addressed. Perhaps this requires a separate thread on the subject, but I am just tired to stating the same thing over and over and over .... (get the picture :). So, while I agree that CVSE is not an authentication extension, alignment is good. alignment is my friend, and I would really like people to take that into account, when possible, during protocol design. Thanks, PatC >The CVSE is not an Authentication extension, so I'm not clear >why it should follow this convention? Doesn't this conflict >with MIER draft? > >2.2 New [Proposed] Mobile IP Extension format > > This draft proposes the following structure for Mobile IP > extensions to be carried in the Mobile IP control messages. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Sub-Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data ..... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >-- Kent -- > >> >> Is there anyway that we could change "Critical Vendor/Organization Specific >> Extension (CVSE)" to have the Length aligned on a 16 bit boundary? This >> would be more consistent with the new Generalized Authentication and Key >> drafts, and would provide consistent extension parsing. >> >> PatC >> >> > ------_=_NextPart_001_01BF68D8.DD95C84E Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] draft-ietf-mobileip-vendor-ext-09.txt

Hi All,

I agree with Pat that we should take byte alignment = in consideration because it is a little more efficient to execute = extension which preserve byte alignment. We will fix this in the next = version.


-----Original Message-----
From: Patrice Calhoun [mailto:Pat.Calhoun@ENG.SUN.COM]
Sent: Tuesday, January 25, 2000 7:26 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] = draft-ietf-mobileip-vendor-ext-09.txt


yes, but we (many of us) repetedly requested that the = MIER length be aligned,
and you can bet that the MIER draft will be stopped = during WG last call
because this was never addressed. Perhaps this = requires a separate thread
on the subject, but I am just tired to stating the = same thing over and
over and over .... (get the picture :).

So, while I agree that CVSE is not an authentication = extension,
alignment is good. alignment is my friend, and I = would really like
people to take that into account, when possible, = during protocol
design.

Thanks,

PatC

>The CVSE is not an Authentication extension, so = I'm not clear
>why it should follow this convention?  = Doesn't this conflict
>with MIER draft?
>
>2.2 New [Proposed] Mobile IP Extension = format
>
>    This draft proposes the = following structure for Mobile IP
>    extensions to be carried in = the Mobile IP control messages.
>
>     = 0            = ;       = 1            = ;       = 2            = ;       3
>     0 1 2 3 4 5 6 7 8 9 0 1 = 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
>    |     = Type      = |            = ; = Length           = |    Sub-Type   |
>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
>    = |            = ;            = ;   Data      .....
>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
>
>-- Kent --
>
>>
>> Is there anyway that we could change = "Critical Vendor/Organization Specific
>> Extension (CVSE)" to have the Length = aligned on a 16 bit boundary? This
>> would be more consistent with the new = Generalized Authentication and Key
>> drafts, and would provide consistent = extension parsing.
>>
>> PatC
>>
>>
>

------_=_NextPart_001_01BF68D8.DD95C84E-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 27 16:32: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 QAA15223 for ; Thu, 27 Jan 2000 16:32:27 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BD3CB340@standards.nortelnetworks.com>; Thu, 27 Jan 2000 16:29:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11969 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 16:27:57 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.77E1B9D0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 16:27:56 -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 NAA00785; Thu, 27 Jan 2000 13:29:45 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id NAA21857; Thu, 27 Jan 2000 13:29:44 -0800 X-Virus-Scanned: Thu, 27 Jan 2000 13:29:44 -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) xma021041; Thu, 27 Jan 00 13:28:54 -0800 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <5F05C89FB2F8D211B6430008C791912703EA7E1F@esealnt190> <200001260546.OAA11729@isl.rdc.toshiba.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3890B896.5D3F2152@iprg.nokia.com> Date: Thu, 27 Jan 2000 13:28:54 -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] challenge / response; MN auth timeout X-cc: Yoshiyuki Tsuda , "Karim El-Malki (ERA)" , Pat Calhoun To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello folks, Excuse my late reply, but I wanted to raise a little more discussion about the lifetime for the keys generated for the mobile node during registration. I think there are two cases. Clearly, the key generated for use between the mobile node and the home agent has to have a lifetime. The key could be used for quite a few registrations, and should not have to be regenerated every time the mobile node moves to a new foreign agent. However, I do not think the same considerations apply for a key generated for use between the mobile node and the foreign agent. For instance, I would say that the same key should be used by the mobile node for as long as it stays at the same foreign agent. New registrations at the same foreign agent should be able to use the same key; since the home agent verifies each registration, and especially if the home agent has a security association with the foreign agent, there is no need to distrust the mobile node. And, unless the key is use for bulk data encryption, there is so little traffic that cryptanalysis is unlikely to succeed in compromising the key. Bottom line: - I think the key generated between mobile node and home agent should have a lifetime. This lifetime _may_ correspond to the amount of time that the AAAF is willing to "trust" the home agent. - I think the key generated between the mobile node and the foreign agent should last until the mobile node moves to a new care-of address and carries out the protocol operations for a smooth handover. This is the philosophy that is currently reflected in the newly revised AAA keys draft, which is finally done. Regards, Charlie P. Yoshiyuki Tsuda wrote: > > Hello, Pat and Karim, > > My comments are embedded in the followings: > > On Tue, 25 Jan 2000 07:09:07 -0800, Patrice Calhoun wrote: > >> > >> Yes, the fact that the Mobile Node can simply request new keying material > >> by including the MN-AAA Authentication Extension in the Registration > >> Request. This needs to be supported since we do not know that a Mobile Node > >> no longer has an SA because of laziness, or due to a host reboot. > >> > >> PatC > > Thanks Pat; I'm happy to hear the above. > > You know, according to rfc2002 and rfc2002bis in the 3.7.2.1 section, > if an FA and an MN share an SA, and if the Mobile-Foreign authentication > extension doesn't exist in a request, the FA will silently discard the > request. And, I couldn't find any related descriptions in the challenge > draft and an expired keying draft. So, I assumed an FA would discard > such a request. > I'm looking forward to seeing something like the above in a coming keying > draft. > > On Tue, 25 Jan 2000 19:04:31 +0100, Karim El-Malki (ERA) wrote: > >> Hi Yoshi > >> > >> > But, there is a new problem to this solution: > >> > If an MN receives an SA lifetime, the MN must keep the SA > >> > until the lifetime > >> > is expired. This means in some cases an MN must keep too > >> > many SAs. If an MN > >> > visits many subnets, and if their SA lifetimes are long, > >> > SAs to be kept will > >> > soon grow more than an MN's ability. > >> > >> The MN does not necessarily keep an MN-FA SA if it leaves the > >> relative FA. My understanding is that normally the MN keeps one > >> MN-FA SA unless it has simultaneous bindings (COAs) at the HA. > > As for binding information, you are right. But, as for SAs, > I don't think so according to the current drafts. > > >> > I will appreciate, if there is a method about re-getting or > >> > re-newing > >> > keying information with its lifetime. If there is such a > >> > method, an MN can > >> > abandon some old SAs before being expired. Winthout such a > >> > method, if an > >> > MN abandons an SA between the MN and an FA, an MN cannot > >> > anymore register the > >> > FA whose SA the MN had abandon before, because the FA knows > >> > there is an SA > >> > between the FA and the MN. > >> > >> Are you considering the case in which an MN returns to an FA which > >> has maintained the MN-FA SA even though it no longer has a binding for > >> the MN? (unless there are simultaneous bindings) > >> Can an FA maintain SAs for some time after the expiry of the > >> relative binding (reg. lifetime)? If so the MN should be aware of > >> this time period and cache SAs. Anyone have any comments? > >> > >> Regards, > >> Karim > > Yes, I was saying about this. From my understanding, an FA will > maintain SAs for their lifetimes, even if there are no binding. An > MN will try to cache SAs. In case of current laptop PCs, it may be > OK, because there are plenty of memory and hard disk. But, in case > of poor MNs, resources may be restricted, I'm afraid. > > But, Pat mentioned about requesting new keying material. This will > enable an MN to discard old SAs before their lifetimes. > > Thanks. > -Yoshi From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 27 21:49: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 VAA18946 for ; Thu, 27 Jan 2000 21:49:45 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.135E3EC0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 21:47:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12250 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 21:45:42 -0500 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.75CE0D80@standards.nortelnetworks.com>; Thu, 27 Jan 2000 21:35:41 -0500 Received: from ns.click ([163.121.204.222]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id UAA29010 for ; Thu, 27 Jan 2000 20:37:29 -0600 (CST) Received: from ramb (ABD751FB.ipt.aol.com [171.215.81.251]) by ns.click with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DWQCGBKJ; Fri, 28 Jan 2000 04:34:15 +0200 Message-ID: <200001280237.UAA29010@hosaka.smallworks.com> Date: Thu, 27 Jan 2000 20:37:29 -0600 Reply-To: bizonline@BUSINESSWEEKMAIL.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: bizonline@BUSINESSWEEKMAIL.COM Subject: [MOBILE-IP] Make $3,000 + per month from home on the Internet To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Own Your Own Internet Business! Make $3,000 + Per Month From Home Offer The Hottest Internet Products and Services Get Paid To Help People With Total Internet Solutions Easy and simple. Guaranteed! For the full, FREE details, Send your: Name: U.S. Phone Number (required): and Best time to call: To mailto:totalnet5@newmail.net To unsubscribe mailto:unsubscribe127@newmail.net From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 28 06:53: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 GAA05926 for ; Fri, 28 Jan 2000 06:53:18 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F97EA430@standards.nortelnetworks.com>; Fri, 28 Jan 2000 6:50:33 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12449 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jan 2000 06:49:32 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6EF0A120@standards.nortelnetworks.com>; Fri, 28 Jan 2000 6:39:31 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05559; Fri, 28 Jan 2000 06:41:16 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200001281141.GAA05559@ietf.org> Date: Fri, 28 Jan 2000 06:41:16 -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-02.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-02.txt Pages : 8 Date : 27-Jan-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-02.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-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-mier-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000127125904.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-mier-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-mier-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000127125904.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jan 29 04:34: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 EAA17979 for ; Sat, 29 Jan 2000 04:34:13 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BC4EC390@standards.nortelnetworks.com>; Sat, 29 Jan 2000 4:31:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13795 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 29 Jan 2000 04:29:43 -0500 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DF0147C0@standards.nortelnetworks.com>; Sat, 29 Jan 2000 4:18:18 -0500 Received: from dist.dist.unige.it (dist.dist.unige.it [130.251.1.4]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id DAA09519 for ; Sat, 29 Jan 2000 03:20:10 -0600 (CST) Received: from [130.251.1.188] (dialhost1.dist.unige.it [130.251.1.188]) by dist.dist.unige.it (8.9.3/8.9.3/generic-osf1) with ESMTP id KAA07523; Sat, 29 Jan 2000 10:21:15 +0100 (MET) X-Sender: franco@dist.dist.unige.it (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Date: Sat, 29 Jan 2000 10:21:15 +0100 Reply-To: Franco Davoli Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Franco Davoli Subject: [MOBILE-IP] SPECTS 2000 Deadline is approaching X-To: alg@comm.toronto.edu, cabernet-events@ncl.ac.uk, cellular@dfv.rwth-aachen.de, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, dbworld@cs.wisc.edu, DMANET@zpr.uni-koeln.de, end2end-interest@isi.edu, enternet@bbn.com, giga@tele.pitt.edu, hipparch@sophia.inria.fr, ieeetcpc@ccvm.sunysb.edu, itc@ieee.org, kuvs-elg@fokus.gmd.de, manet@itd.nrl.navy.mil, mobile-ip@smallworks.com, multicomm@cc.bellcore.com, multicomm@research.panasonic.com, performance@haven.epm.ornl.gov, reres@laas.fr, sig-dsm@doc.ic.ac.uk, sigmetrics-bb@haven.epm.ornl.gov, tccc@ieee.org, tchen@seas.smu.edu, tcos-announce@Dartmouth.EDU, testnet@canarie.ca, theorynt@listserv.nodak.edu, xtp-relay@cs.concordia.ca X-cc: radaideh@ca.ibm.com, Steve Branch , Mohammad Obaidat To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM (Our apologies if you receive multiple copies of this message) SPECTS 2000 DEADLINE IS APPROACHING (JAN. 31, 2000)! Call For Papers SPECTS 2000 [see also the SPECTS 2000 Web site at http://www.scs.org/confernc/scsc00/spects/spects2k.html ] 2000 SCS Symposium on Performance Evaluation of Computer and Telecommunication Systems July 16-20, 2000 Coast Plaza Suites Hotel 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-2154 E-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 F. 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 T.J. Watson Res. Center, USA S. Palazzo, University of Catania, Italy G. I. Papadimitriou, Aristotle University, Thessaloniki, 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 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, IBM, Canada, radaideh@ca.ibm.com (Publicity Chair) 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, lelus@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 - January 31, 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 URL: http://www.scs.org Prof. Franco Davoli DIST-University of Genoa Via Opera Pia 13 I-16145 Genova, Italy Phone: +39 010 3532732 Fax: +39 010 3532154 E-mail: franco@dist.unige.it http://www.com.dist.unige.it From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 30 06:39: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 GAA07538 for ; Sun, 30 Jan 2000 06:39:57 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.73245410@standards.nortelnetworks.com>; 30 Jan 2000 6:37:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14290 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 30 Jan 2000 06:36:59 -0500 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EA2DE0F0@standards.nortelnetworks.com>; 30 Jan 2000 6:26:17 -0500 Received: from uci.agh.edu.pl (root@galaxy.uci.agh.edu.pl [149.156.96.9]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id FAA16862 for ; Sun, 30 Jan 2000 05:28:07 -0600 (CST) Received: from saturn.kt.agh.edu.pl (root@saturn.kt.agh.edu.pl [149.156.114.3]) by uci.agh.edu.pl (8.9.3/8.8.7/rchk1.20) with SMTP id KAA02891; Sun, 30 Jan 2000 10:45:15 +0100 (MET) Received: from pcnt.kt.agh.edu.pl by saturn.kt.agh.edu.pl (AIX 3.2/UCB 5.64/5.1) id AA35697; Sun, 30 Jan 2000 10:33:45 +0100 Address: Mickiewicza 30, 30-059 Krakow, POLAND X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <389407A4.8CD4A415@kt.agh.edu.pl> Date: Sun, 30 Jan 2000 10:43:00 +0100 Reply-To: Piotr Pacyna Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Piotr Pacyna Organization: University of Mining and Metallurgy Subject: [MOBILE-IP] PROMS2000 CfP X-To: tccc , itc , comswtc , edoc-info , cschao , "dave.ingham" , ganesh , kikn , "Judy.Holyer" , jon , junzhang , zll , madhukar , "M.C.Little" , sakaguti , urbano , tang , pauls , prasant , liu , ichikawa , echen , sigmetrics , sigmob , chiang , performance , agrawal , cellular , cnom , commsoft , cost237-transport , ctc-members , dbworld , DMANET , end2end-interest , enternet , giga , hipparch , ieeetcpc , kuvs-elg , manet , mobile-ip , multicomm , multicomm , reres , sig-dsm , sigmetrics-bb , tchen , tcos-announce , testnet , theorynt , xtp-relay , ramesh , info , alg , cabernet-events , almeroth , nonnen , apc , apc_members , cabernet-general , ccrc , cellular , comsoc-chapters , comsoc-gicb , "comsoc.tac" , comswtc , f-troup , fokus-user , g-troup , ieee_rtc_list , isadsoc , itc , kia , osimcast , "sb.all" , sigmedia , papir To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit We do apologize if you receive multiple copies of the CfP. with regards, Piotr Pacyna ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ (Please apologize, if you receive multiple copies of this CfP) Announcement and Call for Papers PROTOCOLS FOR MULTIMEDIA SYSTEMS - PROMS2000 Cracow, Poland, October 22-25, 2000 Sponsored by IEEE Poland Sect. and Cracow Communications Soc. Chap. Lucent Technologies http://PROMS2000.kt.agh.edu.pl/ After past successful PROMS conferences held in Berlin, Salzburg, Madrid, and Santiago de Chile now we cordially invite you to Cracow/Poland, a lovely university city, with a 1000 year history, today one of cultural capitals of Europe. Emerging broadband interactive applications along with a development of different networking technologies should draw telecom operators' and service providers' attention to protocols supporting multimedia systems as an interface between these two environments that has to be still investigated and modified. The PROMS2000 conference is intended to contribute to a scientific, strategical and practical cooperation between research institutes and industrial companies in the area of distributed multimedia applications, protocols, and intelligent management tools, with emphasis on their provision over broadband networks. PROMS2000 will cover papers and demonstrations on research and achievements related to the following topics: TOPICS * design and implementation of multimedia protocols for public switched telephony networks, mobile networks, data networks, and satellite networks using IP, ATM or other connectivity techniques; * application, media, and protocol integration: synchronization of media streams; * multiparty and group communication protocols; * mobile networking and routing: multimedia communication architectures for mobile networks; * multimedia applications: video-on-demand, digital video libraries, video games, virtual community, teleworking, teleteaching, e-commerce, telemeeting, virtual reality simulations; * content based searching and querying; * techniques for the specification of communication services required by multimedia applications; * methods for real-time testing and analysis of service implementations; * integration of media storage and communication mechanisms, operating system and high-performance issues; * experiences with service provisioning using distributed multimedia applications; * performance of protocols and applications: modeling, simulation and optimization in different networks * multimedia traffic engineering; * applications and platforms for service management and provisioning; * definition, provisioning, and supervision of QoS parameters for networked applications and services; * intelligent management tools pertaining to costs and quality of service, network access, accounting, security, and system resilience; * service access - security, authentication, privacy; * accounting and tariff policing for multimedia teleservices. IMPORTANT DATES * Full papers due June 26, 2000 * Authors notified July 24, 2000 * Full paper camera ready due September 25, 2000 CONFERENCE TIMETABLE * 1st day October 22 full-day sightseeing tour (optional) * 2nd day October 23 tutorials, welcome reception * 3rd day October 24 invited talks, sessions, panel, banquet * 4th day October 25 invited talks, sessions VENUE Its history rooted deep in the Middle Ages, Cracow, is the most celebrated city in Poland. UNESCO has added its architectural complex to the World Heritage List. Cracow's appeal today, however, is no longer attributable solely to the beauty of its medieval architecture, but to its strong scientific potential for applied research and development. The PROMS2000 Conference will be held on the modern premises of the Department of Telecommunications within walking distance of both the downtown area and hotels. Direct flights to Cracow are available to and from Chicago, Copenhagen, New York, Toronto, Frankfurt, London, Paris, Rome, Tel Aviv, Vienna and Zurich. SUBMISSION Submit a full manuscript to the PROMS chair in an electronic form (MSWord, Postscript or pdf file); editorial requirements can be found at http://PROMS2000.kt.agh.edu.pl/. CONFERENCE CHAIR Zdzislaw PAPIR Department of Telecommunications University of Mining and Metallurgy Al. Mickiewicza 30 30-059 Cracow, Poland E-mail: papir@kt.agh.edu.pl Phone: +48 12 634 55 82 Fax: +48 12 634 23 72 PROGRAM COMMITTEE Koichi Asatani, Univ. Kogakuin, asatani@sin.cc.kogakuin.ac.jp William Atwood, Univ. Concordia, Bill@cs.Concordia.ca Arturo Azcorra, Univ. Carlos III de Madrid, azcorra@it.uc3m.es Stanislaw Budkowski, INT-Evry, stan@int-evry.fr Andrew Campbell, Univ. Columbia, campbell@ctr.columbia.edu Michel Diaz, LAAS-CNRS, diaz@laas.fr Wolfgang Effelsberg, Univ. Mannheim, effelsberg@informatik.uni-mannheim.de Paolo Fasano, CSELT, Paolo.Fasano@cselt.it Francisco Fontes, Portugal Telecom, fontes@ptinovacao.pt Nicolas D. Georganas, Univ. Ottawa, georgana@mcrlab.uottawa.ca Per Gunningberg, Univ. Uppsala, Per.Gunningberg@docs.uu.se Ulrich Hofmann, Univ. Salzburg, ulrich.hofmann@fh-sbg.ac.at David Hutchison, Univ. Lancaster, dh@comp.lancs.ac.uk Yuji Inoue, NTT, yuji@rd.nttdata.co.jp Andrzej Jajszczyk, Univ. Mining and Metallurgy, jajszcz@kt.agh.edu.pl Pedro Lizcano, Telefonica Labs, lizcano@tid.es Andrzej R. Pach, Univ. Mining & Metallurgy, pach@kt.agh.edu.pl Sergio Palazzo, Univ. Catania, palazzo@iit.unict.it Thomas Plagemann, Center for Technology, plageman@unik.no Radia Perlman, SUN, radia.perlman@sun.com Radu Popescu-Zeletin, GMD, zeletin@fokus.gmd.de Marten J. van Sinderen, Univ. Twente, sinderen@cs.utwente.nl Kazem Sohraby, Lucent, sohraby@lucent.com Joan I. Solana, Nokia Telecom R & D, juan.solana@nokia.com Eduardo Vera, Univ. of Chile, evera@accessnova.cl Johan Zuidweg, Tecsidel, johan.zuidweg@ieee.org ORGANISING COMMITTEE Chair: Piotr PACYNA, pacyna@kt.agh.edu.pl K. Juszkiewicz, juszkiew@kt.agh.edu.pl J. Gozdecki, gozdecki@kt.agh.edu.pl J. Roman, roman@kt.agh.edu.pl ++++++++++++++++++++++++++++++++++++++++++++++++++++++ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 31 00:49: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 AAA16853 for ; Mon, 31 Jan 2000 00:49:33 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A2E84790@standards.nortelnetworks.com>; Mon, 31 Jan 2000 0:46:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15210 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 00:45:18 -0500 Received: from smtp7.atl.mindspring.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0C24A840@standards.nortelnetworks.com>; Mon, 31 Jan 2000 0:35:17 -0500 Received: from uf4xc (user-33qschk.dialup.mindspring.com [199.174.50.52]) by smtp7.atl.mindspring.net (8.9.3/8.8.5) with SMTP id AAA01518 for ; Mon, 31 Jan 2000 00:37:16 -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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <000201bf6bad$c0b588e0$020aa8c0@uf4xc> Date: Sun, 30 Jan 2000 23:40:58 -0600 Reply-To: Basavaraj Patil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: [MOBILE-IP] IETF47 - Requests for timeslots To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit We are now accepting requests for timeslots for the Mobile IP WG meeting(s) at IETF47. Please send the requests to either Phil or myself. Requests MUST contain the following information: 1. Title of presentation 2. I-D associated with the presentation 3. Amount of time requested 4. Relevance to the Mobile IP WG Regards, -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 31 18:13: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 SAA17965 for ; Mon, 31 Jan 2000 18:13:59 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.811FD2D0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 18:10:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16629 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 18:10:15 -0500 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.06F13F90@standards.nortelnetworks.com>; Mon, 31 Jan 2000 18:00:15 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA25557 for ; Mon, 31 Jan 2000 16:02:15 -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 PAA20107 for ; Mon, 31 Jan 2000 15:02:14 -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 PAA06962 for ; Mon, 31 Jan 2000 15:02:12 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: G/alRI6e+X2eknr6JvAJDg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Message-ID: <200001312302.PAA06962@jurassic.eng.sun.com> Date: Mon, 31 Jan 2000 15:01:27 -0800 Reply-To: Ashish Mehta Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ashish Mehta Subject: [MOBILE-IP] retrieving MN's link layer address To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM The revised version of the draft, draft-ietf-mobileip-rfc2002-bis-01.txt mentions in section 4.2.2. "Foreign Agent Considerations": "A foreign agent MUST NOT use broadcast ARP for a mobile node's MAC address on a foreign network. It may obtain the MAC address by copying the information from an Agent Solicitation or a Registration Request transmitted from a mobile node" The question is for various implementors, how does IP retrieve the link layer address from the link layer? Has anyone implemented this piece? A (reliable) solution does not seem apparent to me, so any comments/insights would be welcome. ashish