From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 1 21:53:38 2001 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00840 for ; Mon, 1 Jan 2001 21:53:37 -0500 (EST) Received: from standards (47.234.32.16:3597) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC71E6@standards.nortelnetworks.com>; Mon, 1 Jan 2001 21:32:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36141 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 1 Jan 2001 21:32:21 -0500 Received: from mail0.u-aizu.ac.jp (163.143.1.43:48165) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC71E4@standards.nortelnetworks.com>; Mon, 1 Jan 2001 21:32:20 -0500 Received: from pross114.u-aizu.ac.jp (pross114 [163.143.180.102]) by mail0.u-aizu.ac.jp (8.9.3+3.1W/3.7Winternet-gw) with ESMTP id LAA08005 for ; Tue, 2 Jan 2001 11:51:17 +0900 (JST) Received: from u-aizu.ac.jp (localhost [127.0.0.1]) by pross114.u-aizu.ac.jp (8.9.3+3.1W/3.7Wistcmx+kanji) with ESMTP id LAA25694 for ; Tue, 2 Jan 2001 11:51:17 +0900 (JST) X-Mailer: Mozilla 4.7 [en_jp] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <200012212107.NAA08627@nasnfs.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: sarikaya@U-AIZU.AC.JP Message-ID: <3A514224.422F4589@u-aizu.ac.jp> Date: Tue, 2 Jan 2001 11:51:17 +0900 Reply-To: Behcet Sarikaya Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Behcet Sarikaya Organization: University of Aizu Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession forFastHandoffDiscussion To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Phil and Raj, First off happy new year to you all and a happy new millenium. It seems to me that a) merging the two drafts is not going to work, b) People seem to regard highly mipv6 handover design team work, c) Many of the issues are common for mipv4 and mipv6. If you agree with the above, the natural conclusion is to hand over the handover work item for mipv4 also to the mipv6 design team. This may require enlarging slightly the team, if necessary, but I do not think it is. My 0.002 cents. -- behcet From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 2 02:39:10 2001 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16086 for ; Tue, 2 Jan 2001 02:39:08 -0500 (EST) Received: from standards (47.234.32.16:4162) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC727F@standards.nortelnetworks.com>; Tue, 2 Jan 2001 2:18:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36346 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 Jan 2001 02:18:04 -0500 Received: from cs.tut.fi (varis2.cs.tut.fi) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC727D@standards.nortelnetworks.com>; Tue, 2 Jan 2001 2:18:04 -0500 Received: from rami (varis.cs.tut.fi [130.230.4.42]) by cs.tut.fi (8.8.8/8.8.8) with SMTP id JAA21936 for ; Tue, 2 Jan 2001 09:37:03 +0200 (EET) 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.6700 Importance: Normal Approved-By: Rami Lehtonen Message-ID: Date: Tue, 2 Jan 2001 09:38:04 +0200 Reply-To: Rami Lehtonen Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Rami Lehtonen Subject: [MOBILE-IP] unsubscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit unsubsribe From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 2 11:42:09 2001 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20050 for ; Tue, 2 Jan 2001 11:42:09 -0500 (EST) Received: from standards (47.234.32.16:3307) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC7377@standards.nortelnetworks.com>; Tue, 2 Jan 2001 11:21:13 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36660 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 Jan 2001 11:21:12 -0500 Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC7375@standards.nortelnetworks.com>; Tue, 2 Jan 2001 11:21:12 -0500 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA14041 for ; Tue, 2 Jan 2001 11:40:13 -0500 (EST) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA14032 for ; Tue, 2 Jan 2001 11:40:13 -0500 (EST) Received: by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA05595; Tue, 2 Jan 2001 10:40:12 -0600 (CST) Received: from lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA05540; Tue, 2 Jan 2001 10:40:10 -0600 (CST) X-Mailer: Mozilla 4.72 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 Original-CC: "Chander, Sharat S." Content-Type: multipart/mixed; boundary="------------65D720FC7566082F18FC905D" Approved-By: "Sharat S. Chander" Message-ID: <3A5204AF.18EAD57@lucent.com> Date: Tue, 2 Jan 2001 10:41:26 -0600 Reply-To: sharat@lucent.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Sharat S. Chander" Organization: Lucent Tech - Bell Labs Wireless Standards Subject: [MOBILE-IP] unsubscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------65D720FC7566082F18FC905D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe --------------65D720FC7566082F18FC905D Content-Type: text/x-vcard; charset=us-ascii; name="sharat.vcf" Content-Description: Card for Sharat S. Chander Content-Disposition: attachment; filename="sharat.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Chander;Sharat S. tel;pager:No more! Use my SMS!!! tel;cell:+1 630 728 5202 tel;fax:+1 630 713 1921 tel;work:+1 630 713 1438 x-mozilla-html:TRUE org:Area: Wireless Data Applications Stds Devt;Firm: Lucent Technologies - Bell Laboratories adr:;;Address: Room 2F-224, Indian Hill Park;263 Shuman Boulevard, Naperville, Illinois-60566, USA.;Short Message Service: 6307285202@messaging.sprintpcs.com;Mobile Wireless Email:;1. sharat@sprintpcs.com or 2. sharat0@yahoo.com version:2.1 email;internet:sharat@lucent.com title:Title: Distinguished Member of the Technical Staff x-mozilla-cpt:;3 fn:Chander, Sharat S. end:vcard --------------65D720FC7566082F18FC905D-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 2 12:57:00 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20581 for ; Tue, 2 Jan 2001 12:56:59 -0500 (EST) Received: from standards (47.234.32.16:1657) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC73CE@standards.nortelnetworks.com>; Tue, 2 Jan 2001 12:35:59 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36772 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 Jan 2001 12:35:58 -0500 Received: from gate.internaut.com (64.38.134.108:4922) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC73CC@standards.nortelnetworks.com>; Tue, 2 Jan 2001 12:35:58 -0500 Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f02Hq5C22929; Tue, 2 Jan 2001 09:52:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Approved-By: Bernard Aboba Message-ID: Date: Tue, 2 Jan 2001 09:54:33 -0800 Reply-To: Bernard Aboba Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Bernard Aboba Subject: Re: [MOBILE-IP] authorization to issue a Binding Update for a Home Address X-To: Francis Dupont To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200012211021.LAA28156@givry.rennes.enst-bretagne.fr> Content-Transfer-Encoding: 7bit >this is again the authorization problem. I don't understand why >this is so hard for mobile IPv6 when the problem exists for VPN too >(a security gateway will give a subnet identity in phase two, this >should be accepted only if the peer is authorized to be a security >gateway for this subnet. My understanding is that most implementations are not able to validate the subnet identity if provided by a security gateway. It's worth reflecting on what the IKE exchange provides in the VPN case, and what it doesn't provide. In the case of shared secret authentication in MM, typically group secrets are required precisely because it is hard to tie the source IP address to a shared secret (the user could be trying to connect from anywhere). Note: In IKE MM, the shared secret is required prior to obtaining the identity; this is not the case in aggressive mode. If certificates are used, life is easier because then the machine/user identity can be used and validated. In general, we don't care whether a user is at an authorized IP address, only that they are authorized for VPN access. After the IKE negotiation completes, we are able to verify that each packet came from the same source that negotiated the key via IKE. Similarly, it's worth thinking through *exactly* what assurances need to be provided for MIP: a) Do you want to know that the binding update is being provided by the *same* entity with whom you were originally communicating? Typically, this requires authentication of both the original conversation and binding update, and tieing between the two. b) Do you want to know that the source is actually reachable at the care-of/home address that is indicated? A three way handshake (e.g. a request-response-request sequence) can provide this. c) Do you want to know that the source is authorized to use the care of address? home address? This is the hardest level of assurance to provide. If you feel that you need this, then it's important to make sure that assurance is required within the conversation itself, not just the binding update. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 2 13:51:35 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21301 for ; Tue, 2 Jan 2001 13:51:34 -0500 (EST) Received: from standards (47.234.32.16:4434) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC740E@standards.nortelnetworks.com>; Tue, 2 Jan 2001 13:30:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36860 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 Jan 2001 13:30:31 -0500 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC740C@standards.nortelnetworks.com>; Tue, 2 Jan 2001 13:30:30 -0500 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f02IlD430804; Tue, 2 Jan 2001 19:47:13 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA05765; Tue, 2 Jan 2001 19:47:12 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f02IlCO00961; Tue, 2 Jan 2001 19:47:12 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Approved-By: Francis.Dupont@ENST-BRETAGNE.FR Message-ID: <200101021847.f02IlCO00961@givry.rennes.enst-bretagne.fr> Date: Tue, 2 Jan 2001 19:47:12 +0100 Reply-To: Francis Dupont Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] authorization to issue a Binding Update for a Home Address X-To: Bernard Aboba To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Tue, 02 Jan 2001 09:54:33 PST. In your previous mail you wrote: >this is again the authorization problem. I don't understand why >this is so hard for mobile IPv6 when the problem exists for VPN too >(a security gateway will give a subnet identity in phase two, this >should be accepted only if the peer is authorized to be a security >gateway for this subnet. My understanding is that most implementations are not able to validate the subnet identity if provided by a security gateway. => I agree but it is important to know if some are able to validate identities and even more important how they do that... Today VPN is a business so I believe the question will get an answer! If certificates are used, life is easier because then the machine/user identity can be used and validated. In general, we don't care whether a user is at an authorized IP address, only that they are authorized for VPN access. => this is not enough with a layered VPN (ie. with a SG manageing different VPNs with different security requirements). After the IKE negotiation completes, we are able to verify that each packet came from the same source that negotiated the key via IKE. => we are able but we should *not* do this check: the correct check is to verify the original source is in the subnet (ie. check the inner source, not the outer source). Similarly, it's worth thinking through *exactly* what assurances need to be provided for MIP: => authorization to use the home address. a) Do you want to know that the binding update is being provided by the *same* entity with whom you were originally communicating? Typically, this requires authentication of both the original conversation and binding update, and tieing between the two. => there is no original conversation in the common case. b) Do you want to know that the source is actually reachable at the care-of/home address that is indicated? A three way handshake (e.g. a request-response-request sequence) can provide this. => this is not important. c) Do you want to know that the source is authorized to use the care of address? home address? => the care-of address is nearly random... The important point is the authorization to use the home address (this will give previous points when they apply). This is the hardest level of assurance to provide. => it is easier than we can believe because the home address is the phase 2 entity (ie. the SAs are built for the home address) so the burden is not when the binding update is received: the assurance is required in the phase two of IKE, ie. we just have to give the concrete code for "Local policy will dictate whether the proposals are acceptable for the identities specified". My idea is still to post a provicative question about this statement in the VPN context in the IPsec mailing-list (:-)... If you feel that you need this, then it's important to make sure that assurance is required within the conversation itself, not just the binding update. => see previous point (this is another argument to set the SAs for the home address). IKE knows mobility is involved because of the phase two identity (a different address) and if it rejects the identity (ie. deny the authorization) the binding update will not be authenticated (and it MUST be authenticated, ie. it will be canceled when IKE will notify the INVALID-ID-INFORMATION failure). Thanks (and Happy New Year!) Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 2 19:03:00 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24237 for ; Tue, 2 Jan 2001 19:03:00 -0500 (EST) Received: from standards (47.234.32.16:1778) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC74BE@standards.nortelnetworks.com>; Tue, 2 Jan 2001 18:42:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37097 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 Jan 2001 18:42:04 -0500 Received: from herbert.eecs.wsu.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC74BC@standards.nortelnetworks.com>; Tue, 2 Jan 2001 18:42:03 -0500 Received: from carmel.eecs.wsu.edu ([199.237.72.81]) by herbert.eecs.wsu.edu (Post.Office MTA v3.5.3 release 223 ID# 0-68625U3000L300S0V35) with ESMTP id edu for ; Tue, 2 Jan 2001 16:00:36 -0800 Received: (from dawn@localhost) by carmel.eecs.wsu.edu (8.9.3/) id QAA01200 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 2 Jan 2001 16:01:04 -0800 X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: DAWN Research Lab Message-ID: <200101030001.QAA01200@carmel.eecs.wsu.edu> Date: Tue, 2 Jan 2001 16:01:04 -0800 Reply-To: DAWN Research Lab Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: DAWN Research Lab Subject: [MOBILE-IP] CFP: ACM MobiCom 2001 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Enclosed below please find a Preliminary Announcement and Call for Papers for the 7th Annual International Conference on Mobile Computing and Networking (MobiCom) to be held in Rome, Italy from July 16-21, 2001. As you might already know, MobiCom has an established reputation as the pre-eminent conference in this area owing to the exceptionally high quality of papers, excellent tutorials and workshops, and stimulating panels conducted by mobile computing illuminati of various stripes. For complete information about the upcoming conference, please visit: http://www.research.ibm.com/mobicom2001/ A printer friendly version of this CFP is available at: http://www.eecs.wsu.edu/~krishna/Mobicom2001-onepagecfp.pdf (PDF) http://www.eecs.wsu.edu/~krishna/Mobicom2001-onepagecfp.ps (PS) We apologize if you received multiple copies of this Call for Papers. Please feel free to distribute it to those who might be interested. Very truly yours, ACM SIGMOBILE MobiCom 2001 Organizing Committee *********************************************************************** Preliminary Announcement and Call for Papers *** ACM MobiCom 2001 *** The Seventh Annual International Conference on Mobile Computing and Networking July 16-21, Rome, Italy Sponsored by ACM SIGMOBILE http://www.research.ibm.com/mobicom2001/ http://www.acm.org/sigmobile/ Submission Deadline: January 12, 2001 *********************************************************************** PAPERS: Technical papers (maximum 15 pages) describing original, previously unpublished, completed research, not currently under review by another conference or journal, are solicited on the following topics: * Applications and computing services supporting mobile users * Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity * Database and data management issues in mobile computing * Performance of mobile/wireless networks and systems * Security and privacy of mobile/wireless systems * Interaction between different layers of mobile/wireless systems * Integration and interworking of wired and wireless networks * Adaptive applications and systems for mobile environments * Distributed-system aspects of mobile systems * Operating system support for mobility * Location-dependent applications * Wireless multimedia systems * Power management * Mobile agents * Pervasive computing * Wireless sensor networks * Wireless/mobile service management and delivery All papers will be refereed by the program committee. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Baltzer Wireless Networks (WINET) and Mobile Networks and Applications (MONET) journals. Note: Student Registrations will be provided at a discounted rate. CHALLENGES SESSION, PANELS, RESEARCH DEMOS, TUTORIALS: Short papers (maximum of 8 pages) that challenge the mobile computing community with new technologies or visionary applications are solicited. Such papers should provide stimulating ideas or visions that may open up exciting avenues of mobile computing research. Proposals are solicited for panels that examine innovative, controversial, or otherwise provocative issues of interest. Proposals for tutorials are solicited. Tutorial topics that encompass the systems aspects of mobile computing and/or practical experiences in building/deploying such systems are of particular interest. Informal proposals for research demos are solicited. Proposals should include: the focus area in mobility, the technologies involved, specific equipment used, demo layout, space required, etc. Please refer to the conference website for submission and other details. (The paper submission website is READY for submissions now.) IMPORTANT DATES: * Technical Paper Submissions due: January 12, 2001 - Please refer to the website for submission instructions * Notification of acceptance: May 1, 2001 * Camera-ready version due: May 15, 2001 * Challenges Session Papers, Panel Proposals, Tutorial Proposals Submissions due: January 12, 2001 - Please refer to the website for submission instructions FOR MORE INFORMATION: Send email to mobicom2001@winlab.rutgers.edu with any questions or comments about the conference or for more information. ORGANIZING COMMITTEE: * General Chair: * Tutorials Co-Chairs: Christopher Rose Ravi Jain Rutgers University, WINLAB Telcordia Technologies * General Vice Chair: Chiara Petrioli Politecnico di Milano Sergio Palazzo Universita` di Catania * Panels Chair: * Program Co-Chairs: Ramesh Rao Univ. of California, San Diego Mahmoud Naghshineh IBM T.J. Watson Research Center * Local Arrangement Chair: Michele Zorzi Marco Listanti Universita` di Ferrara Universita` di Roma "La Sapienza" * Finance Chair: Chiara Petrioli Politecnico di Milano David B. Johnson Rice University * Registration Chair: * Exhibits/Sponsorships Chair: Irene Katzela Marco Ajmone Marsan Lucent Technologies Politecnico di Torino * Publicity Co-Chairs: * Research Demos Chair: Stefano Basagni Nigel Davies Univ. of Texas at Dallas Lancaster University Krishna Sivalingam * Steering Committee Chair: Washington State University Imrich Chlamtac Univ. of Texas at Dallas *********************************************************************** From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 3 06:52:21 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA17961 for ; Wed, 3 Jan 2001 06:52:21 -0500 (EST) Received: from standards (47.234.32.16:1237) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC7623@standards.nortelnetworks.com>; Wed, 3 Jan 2001 6:31:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37562 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 3 Jan 2001 06:31:10 -0500 Received: from mercury.ukc.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC7621@standards.nortelnetworks.com>; Wed, 3 Jan 2001 6:31:10 -0500 Received: from athena.ukc.ac.uk ([129.12.200.18]) by mercury.ukc.ac.uk with esmtp (Exim 3.16 #1) id 14DmQl-0005DM-00 for MOBILE-IP@standards.nortelnetworks.com; Wed, 03 Jan 2001 11:50:11 +0000 Received: from stue493.ukc.ac.uk ([129.12.228.147] helo=ukc.ac.uk) by athena.ukc.ac.uk with esmtp (Exim 2.12 #1) id 14DmR2-0006sS-00 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 3 Jan 2001 11:50:28 +0000 X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Kumarendra Sivarajah Message-ID: <3A53109F.F7E2BF06@ukc.ac.uk> Date: Wed, 3 Jan 2001 11:44:31 +0000 Reply-To: Kumarendra Sivarajah Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Kumarendra Sivarajah Subject: [MOBILE-IP] Mobile IP Library For OPNET To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi there everyone Does anyone out there have the mobile IP library RFC 2002 for OPNET whom is willing to share it with me. I would be grateful if you could help me. I am interested in simulation of mobile IP Multicasting using OPNET. Thank you -- ################################# Kumarendra Sivarajah (INdran) University of Kent at Canterbury Tel: +44 (0)7949 505914 Fax: +44 (0)7902 181526 ################################# From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 3 07:44:25 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19341 for ; Wed, 3 Jan 2001 07:44:24 -0500 (EST) Received: from standards (47.234.32.16:4000) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC7664@standards.nortelnetworks.com>; Wed, 3 Jan 2001 7:23:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37651 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 3 Jan 2001 07:23:26 -0500 Received: from mailhub1.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC7662@standards.nortelnetworks.com>; Wed, 3 Jan 2001 7:23:26 -0500 Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.16 #1) id 14DnFJ-0004R0-00; Wed, 03 Jan 2001 12:42:25 +0000 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 3 Jan 01 12:42:25 +0000 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 3 Jan 01 12:42:24 +0000 Received: from Mobile1 (143.167.59.139) by ridingwood.shef.ac.uk (Mercury 1.48); 3 Jan 01 12:42:16 +0000 References: <3A53109F.F7E2BF06@ukc.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Approved-By: cnyap Message-ID: <00ce01c07582$284c9640$923ba78f@Mobile1> Date: Wed, 3 Jan 2001 12:39:04 -0000 Reply-To: cnyap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cnyap Subject: Re: [MOBILE-IP] Mobile IP Library For OPNET X-To: Kumarendra Sivarajah To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi I know that Virginia Tech has one. I could not get hold of the person, if you could please let me as well. Cheers Chern Nam Yap MIEEE, MSc(Res), BSc(Hons) Research Associate Center for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield F132 Mappin Building Mappin Street Sheffield S1 3JD United Kingdom Tel:+44 (0) 114-222-5182 Mobile:+ 44(0) 7712804892 Web: www.mobile1.net E-mail: cny@ieee.org ----- Original Message ----- From: "Kumarendra Sivarajah" To: Sent: Wednesday, January 03, 2001 11:44 AM Subject: [MOBILE-IP] Mobile IP Library For OPNET > Hi there everyone > Does anyone out there have the mobile IP library RFC 2002 for OPNET whom > is willing to share it with me. > I would be grateful if you could help me. I am interested in simulation > of mobile IP Multicasting using OPNET. > Thank you > > -- > ################################# > Kumarendra Sivarajah (INdran) > University of Kent at Canterbury > Tel: +44 (0)7949 505914 > Fax: +44 (0)7902 181526 > ################################# From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 3 22:59:21 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15225 for ; Wed, 3 Jan 2001 22:59:21 -0500 (EST) Received: from standards (47.234.32.16:4690) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC78F7@standards.nortelnetworks.com>; Wed, 3 Jan 2001 22:38:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0344 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 3 Jan 2001 22:38:20 -0500 Received: from web6105.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC78F5@standards.nortelnetworks.com>; Wed, 3 Jan 2001 22:38:20 -0500 Received: from [161.142.100.85] by web6105.mail.yahoo.com; Wed, 03 Jan 2001 19:57:25 PST MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Approved-By: =?iso-8859-1?q?Coulibaly=20Yahya?= Message-ID: <20010104035725.7999.qmail@web6105.mail.yahoo.com> Date: Wed, 3 Jan 2001 19:57:25 -0800 Reply-To: =?iso-8859-1?q?Coulibaly=20Yahya?= Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: =?iso-8859-1?q?Coulibaly=20Yahya?= Subject: [MOBILE-IP] Mobile Ipv6 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Dear All, Can any body provide me with the future challenges in Mobile Ipv6. Thank you in advace. COULIBALY Yahaya. cool. __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 4 02:37:53 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29930 for ; Thu, 4 Jan 2001 02:37:52 -0500 (EST) Received: from standards (47.234.32.16:2239) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC7979@standards.nortelnetworks.com>; Thu, 4 Jan 2001 2:16:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0504 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 4 Jan 2001 02:16:55 -0500 Received: from m018.com (210.112.10.141:20917) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC7977@standards.nortelnetworks.com>; Thu, 4 Jan 2001 2:16:55 -0500 Received: from ns ([211.113.87.7]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 4 Jan 2001 16:31:46 +0900 References: MIME-Version: 1.0 Content-Type: text/plain; charset="BIG5" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Approved-By: "Lee, Jiwoong" Message-ID: <003f01c07621$15f5c300$d012060a@hansol.co.kr> Date: Thu, 4 Jan 2001 16:36:11 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: Re: [MOBILE-IP] Mobile Node multicast group membership controlmessages X-To: Moter Du To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit MIPv6 (issue 13): Rate Limiting for Sending Binding UpdatesTypically, it will be IGMP v3. Or SIP (kind of) messages if applicable. If the MN's application uses yet another control sheme, the control messages mean it. Jiwoong ----- Original Message ----- From: Moter Du To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sent: Friday, December 29, 2000 4:27 PM Subject: [MOBILE-IP] Mobile Node multicast group membership control messages Could anyone please instruct me where I can find references for "multicast group membership control messages" mentioned in MIPv6 specification? Thanks. Sincerely Moter Du ============================================================ Moter Du D410, Siemens STSL phone +886 2 25186011 Fax +886 2 25053866 mailto:moter_du@stsl.siemens.com.tw ============================================================ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 5 11:25:21 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15991 for ; Fri, 5 Jan 2001 11:25:19 -0500 (EST) Received: from standards (47.234.32.16:3019) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC7D2E@standards.nortelnetworks.com>; Fri, 5 Jan 2001 11:04:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1647 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 5 Jan 2001 11:04:03 -0500 Received: from prue.eim.surrey.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC7D2C@standards.nortelnetworks.com>; Fri, 5 Jan 2001 11:04:03 -0500 Received: from carter-e0.ee.surrey.ac.uk ([131.227.86.16]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14EZe4-0001lr-00 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 05 Jan 2001 16:23:12 +0000 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Karann Chew Message-ID: Date: Fri, 5 Jan 2001 16:23:12 +0000 Reply-To: Karann Chew Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Karann Chew Subject: [MOBILE-IP] Where can I find info on OBAST? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi There! Could any body tell me where I can get more information or discussion on OBAST? I could find only two drafts on it. Thanks in advance. Karann From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 5 20:15:27 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26411 for ; Fri, 5 Jan 2001 20:15:26 -0500 (EST) Received: from standards (47.234.32.16:2320) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC7E63@standards.nortelnetworks.com>; Fri, 5 Jan 2001 19:54:28 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2051 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 5 Jan 2001 19:54:28 -0500 Received: from herbert.eecs.wsu.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC7E61@standards.nortelnetworks.com>; Fri, 5 Jan 2001 19:54:28 -0500 Received: from carmel.eecs.wsu.edu ([199.237.72.81]) by herbert.eecs.wsu.edu (Post.Office MTA v3.5.3 release 223 ID# 0-68625U3000L300S0V35) with ESMTP id edu for ; Fri, 5 Jan 2001 17:13:08 -0800 Received: (from dawn@localhost) by carmel.eecs.wsu.edu (8.9.3/) id RAA06723 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 5 Jan 2001 17:13:37 -0800 X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: DAWN Research Lab Message-ID: <200101060113.RAA06723@carmel.eecs.wsu.edu> Date: Fri, 5 Jan 2001 17:13:37 -0800 Reply-To: DAWN Research Lab Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: DAWN Research Lab Subject: [MOBILE-IP] Deadline Extended: ACM MobiCom 2001 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit ************************************************************************** DEADLINE EXTENDED FOR ACM MobiCom 2001 SUBMISSIONS The NEW (and FINAL deadline) is Monday, Jan 22, 2001, 11.59 PM US Eastern ST ************************************************************************** For complete information about the conference and for submission instructions, please visit: http://www.research.ibm.com/mobicom2001/ We apologize if you received multiple copies of this Call for Papers. Please feel free to distribute it to those who might be interested. Very truly yours, ACM SIGMOBILE MobiCom 2001 Organizing Committee *********************************************************************** *** ACM MobiCom 2001 *** The Seventh Annual International Conference on Mobile Computing and Networking July 16-21, Rome, Italy Sponsored by ACM SIGMOBILE http://www.research.ibm.com/mobicom2001/ http://www.acm.org/sigmobile/ Submission Deadline (NEW): January 22, 2001 *********************************************************************** From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 8 13:47:46 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13453 for ; Mon, 8 Jan 2001 13:47:45 -0500 (EST) Received: from standards (47.234.32.16:1690) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC82CF@standards.nortelnetworks.com>; Mon, 8 Jan 2001 13:26:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3471 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 Jan 2001 13:26:16 -0500 Received: from mage.qualcomm.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC82CD@standards.nortelnetworks.com>; Mon, 8 Jan 2001 13:26:16 -0500 Received: from mlioy.qualcomm.com (mlioy.qualcomm.com [129.46.219.140]) by mage.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id KAA04669; Mon, 8 Jan 2001 10:45:35 -0800 (PST) X-Sender: mlioy@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: Marcello Lioy Message-ID: <4.3.1.2.20010108101847.00b2eb00@mail1.qualcomm.com> Date: Mon, 8 Jan 2001 10:34:31 -0800 Reply-To: Marcello Lioy Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Marcello Lioy Subject: [MOBILE-IP] IPv4 Dynamic addressing and SPIs X-cc: jeffd@qualcomm.com, nish@qualcomm.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I have a couple of questions about Mobile IPv4. 1) The new NAI extension (RFC 2794) allows a Mobile node to receive a dynamically allocated home address. My question is how does this work for a mobile that needs an address but comes up in it's home network? In this case is should send a deregistration with a lifetime of zero (it is after all at home) with the home address field set to 0 - is this correct? If so would it be assigned an address via the registration reply? 2) How does one determine the SPI to use in M.IPv4 registration messages? Is this some value that is agreed upon by the Home Agent and the Mobile Node? Are there any assigned numbers related to this? Answers would be most appreciated. ------------------------------------------------------------------ Marcello Lioy Voice: (858)651-8220 Qualcomm Inc. PGR: (858)635-0867 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 8 14:13:45 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14032 for ; Mon, 8 Jan 2001 14:13:44 -0500 (EST) Received: from standards (47.234.32.16:1690) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC831A@standards.nortelnetworks.com>; Mon, 8 Jan 2001 13:52:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3568 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 8 Jan 2001 13:52:39 -0500 Received: from diamond.cavtel.net (diamond.rccrichmond.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC8318@standards.nortelnetworks.com>; Mon, 8 Jan 2001 13:52:33 -0500 Received: by DIAMOND with Internet Mail Service (5.5.2650.21) id ; Mon, 8 Jan 2001 13:59:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Approved-By: Stephen Mandas Message-ID: <11C94477259FD211AF33004005416F9E11AB68@DIAMOND> Date: Mon, 8 Jan 2001 13:59:21 -0500 Reply-To: Stephen Mandas Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Stephen Mandas Subject: [MOBILE-IP] Mobile IP on Intel VPN To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Folks, Does anyone know if Intel has a VPN Mobile IP implementation? Thanks, Stephen Mandas RCC Consultants Richmond, Va. (804) 422-8455 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 10 06:46:19 2001 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA13361 for ; Wed, 10 Jan 2001 06:46:18 -0500 (EST) Received: from standards (47.234.32.16:1108) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC87AB@standards.nortelnetworks.com>; Wed, 10 Jan 2001 6:24:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5031 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 10 Jan 2001 06:24:54 -0500 Received: from smtp4.cluster.oleane.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC87A9@standards.nortelnetworks.com>; Wed, 10 Jan 2001 6:24:54 -0500 Received: from oleane (dyn-1-1-059.Vin.dialup.oleane.fr [195.25.4.59]) by smtp4.cluster.oleane.net with SMTP id f0ABiHF77823 for ; Wed, 10 Jan 2001 12:44:17 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_026A_01C07B03.3D230F00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Approved-By: Peter Lewis Message-ID: <026d01c07afa$dba1ca80$8001a8c0@oleane.com> Date: Wed, 10 Jan 2001 12:45:40 +0100 Reply-To: Peter Lewis Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Peter Lewis Subject: [MOBILE-IP] MPLS World, February 6-9, Paris To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_026A_01C07B03.3D230F00 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 MPLS World, February 6-9, Paris.=20 =20 http://www.upperside.fr/congress/congress.htm =20 With the challenges and uncertainties engendered by the development of = the MPLS architecture, the MPLS World Conference is, in essence, an open = platform for debate on the future of telecommunications networks.=20 Looking Farther Ahead=20 MPLS World is preoccupied with future developments, like using MPLS in = the access network and in the LAN. MPLambdaS, MPLS/mobility convergence = are addressed in papers never before given. MPLS is a unique occasion = for participants to unveil their work and expose new ideas.=20 =20 The exhibition =20 Already 20 exhibitors for this very first MPLS exhibition. Upper Side = will fullfill his objectives. Vendors shouldn't miss the opportunity: http://www.upperside.fr/congress/exhi.htm ------=_NextPart_000_026A_01C07B03.3D230F00 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
MPLS World, February 6-9, Paris.=20
 
http://www.uppersi= de.fr/congress/congress.htm
 
With the=20 challenges and uncertainties engendered by the development of the MPLS=20 architecture, the MPLS World Conference is, in essence, an open platform = for=20 debate on the future of telecommunications networks.=20

Looking=20 Farther Ahead

MPLS World is preoccupied with future = developments,=20 like using MPLS in the access network and in the LAN. MPLambdaS, = MPLS/mobility=20 convergence are addressed in papers never before given. MPLS is a unique = occasion for participants to unveil their work and expose new ideas.=20
 
The=20 exhibition
 
Already 20=20 exhibitors for this very first MPLS exhibition. Upper Side will fullfill = his=20 objectives. Vendors shouldn't miss the opportunity:
http://www.upperside.f= r/congress/exhi.htm
 
 
------=_NextPart_000_026A_01C07B03.3D230F00-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 11 20:45:53 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17377 for ; Thu, 11 Jan 2001 20:45:52 -0500 (EST) Received: from standards (47.234.32.16:3953) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC8E68@standards.nortelnetworks.com>; Thu, 11 Jan 2001 20:23:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7163 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 11 Jan 2001 20:23:52 -0500 Received: from ms.hansol.co.kr (210.112.2.207:3568) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC8E66@standards.nortelnetworks.com>; Thu, 11 Jan 2001 20:23:50 -0500 Received: from ns ([211.113.87.7]) by ms.hansol.co.kr (8.9.3/8.9.3) with SMTP id KAA26758 for ; Fri, 12 Jan 2001 10:40:53 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Approved-By: "Lee, Jiwoong" Message-ID: <009801c07c39$23178d20$d012060a@hansol.co.kr> Date: Fri, 12 Jan 2001 10:43:30 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: [MOBILE-IP] Editorial Error: MobileIPv6 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Authors, In at the first paragraph of page no. 83, there seems an editorial error where a protocol constant MAX_UPDATE_RATE is used. Specifically, a mobile node MUST NOT send a Binding Update about a new care-of address to its home agent (which is required to register the new address as its primary care-of address) more often than once per MAX_UPDATE_RATE seconds. That constant is defined as MAX_UPDATE_RATE once per second So the last part of the sentence had better be changed into: .... more often than MAX_UPDATE_RATE. Right? :> Jiwoong From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 12 06:08:31 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06862 for ; Fri, 12 Jan 2001 06:08:29 -0500 (EST) Received: from standards (47.234.32.16:1444) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC90DE@standards.nortelnetworks.com>; Fri, 12 Jan 2001 5:46:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7969 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 12 Jan 2001 05:46:18 -0500 Received: from artemis.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC90DC@standards.nortelnetworks.com>; Fri, 12 Jan 2001 5:46:10 -0500 Received: from [143.167.1.9] (helo=mailhub1.shef.ac.uk) by artemis.shef.ac.uk with esmtp (Exim 3.16 #2) id 14H1s1-0000f8-00; Fri, 12 Jan 2001 10:55:45 +0000 Received: from ridingwood.shef.ac.uk ([143.167.59.249]) by mailhub1.shef.ac.uk with esmtp (Exim 3.16 #1) id 14H1s0-00043P-00; Fri, 12 Jan 2001 10:55:44 +0000 Received: from RIDINGWOOD/SpoolDir by ridingwood.shef.ac.uk (Mercury 1.48); 12 Jan 01 10:55:44 +0000 Received: from SpoolDir by RIDINGWOOD (Mercury 1.48); 12 Jan 01 10:55:33 +0000 Received: from Mobile1 (143.167.59.146) by ridingwood.shef.ac.uk (Mercury 1.48); 12 Jan 01 10:55:25 +0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0130_01C07C85.B77497A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Scanner: exiscan@artemis *14H1s1-0000f8-00* http://duncanthrax.net/exiscan/ Approved-By: cnyap Message-ID: <013401c07c85$b7962960$923ba78f@Mobile1> Date: Fri, 12 Jan 2001 10:52:11 -0000 Reply-To: cnyap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cnyap Subject: [MOBILE-IP] draft-cnyap-iip-02.txt X-To: Kumarendra Sivarajah , Praveen Muley , Xingang Liang , "Shahrier, Sharif M." , jtphilli@alpha.engr.twsu.edu, "Iyer, Prakash" , Kulwinder Atwal , "Lee, Jiwoong" , Larry McFarland , ccfoo@hawk.ee.nus.edu.sg, Brenda , Coulibaly Yahaya X-cc: matthias_kraner@hotmail.com, Dave Ludlam , seamoby@diameter.org To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0130_01C07C85.B77497A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0131_01C07C85.B77497A0" ------=_NextPart_001_0131_01C07C85.B77497A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Itinerant Internet Protocol Author(s) : Chern Nam Yap et al. Filename : draft-cnyap-iip-02.txt Pages : 45 Date : 10-Jan-01 This document specifies a protocol that allows any IP node to communicate with other IP nodes in the mobile environment without any fundamental changes to TCP/IP. Any mobile aware nodes are able to communicate with one another with standard IP routing. Mobile awareness is achieved by means of address updates through a query mechanism. Backward compatibility capability is supported via the means of one or more anchoring points that are put in place. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cnyap-iip-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-cnyap-iip-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-cnyap-iip-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_001_0131_01C07C85.B77497A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A New=20 Internet-Draft is available from the on-line Internet-Drafts=20 directories.

       =20 Title           =20 : Itinerant Internet = Protocol
       =20 Author(s)    : Chern Nam Yap et=20 al.
       =20 Filename     :=20 draft-cnyap-iip-02.txt
       =20 Pages         =20 : 45
       =20 Date            : = 10-Jan-01

This document specifies a protocol that allows any IP = node=20 to
communicate with other IP nodes in the mobile environment without=20 any
fundamental changes to TCP/IP. Any mobile aware nodes are able=20 to
communicate with one another with standard IP routing. = Mobile
awareness=20 is achieved by means of address updates through a query
mechanism. = Backward=20 compatibility capability is supported via the
means of one or more = anchoring=20 points that are put in place.

A URL for this Internet-Draft=20 is:
http://www.ietf.org/internet-drafts/draft-cnyap-iip-02.txt

Internet-Drafts are also available by = anonymous=20 FTP. Login with the username
"anonymous" and a password of your = e-mail=20 address. After logging in,
type "cd internet-drafts" and=20 then
        "get=20 draft-cnyap-iip-02.txt".

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

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

Send a message = to:
       =20 mailserv@ietf.org.
In=20 the body type:
        "FILE=20 /internet-drafts/draft-cnyap-iip-02.txt".

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


Below is the data which will enable a MIME = compliant mail=20 reader
implementation to automatically retrieve the ASCII version of=20 the
Internet-Draft.
------=_NextPart_001_0131_01C07C85.B77497A0-- ------=_NextPart_000_0130_01C07C85.B77497A0 Content-Type: text/plain; name="draft-cnyap-iip-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-cnyap-iip-02.txt" Content-Transfer-Encoding: 7bit Network Working Group Chern Nam Yap Internet Draft Matthias Kraner University of Sheffield Srba Cvetkovic Logica 10 January 2000 Itinerant Internet Protocol Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of RFC 2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents, valid for maximum of six months, and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ieft.org/shadow.html Abstract This document specifies a protocol that allows any IP node to communicate with other IP nodes in the mobile environment without any fundamental changes to TCP/IP. Any mobile aware nodes are able to communicate with one another with standard IP routing. Mobile awareness is achieved by means of address updates through a query mechanism. Backward compatibility capability is supported via the means of one or more anchoring points that are put in place. Chern Nam Yap et al. Expires 10 July 2001 Page i Internet Draft Itinerant Internet Protocol 10 January 2000 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Comparison with Mobile IP for IPv4 2 3. Terminology 4 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Itinerant Internet Protocol Terms . . . . . . . . . . . . 4 3.3. Specification Language . . . . . . . . . . . . . . . . . 6 4. Overview of Itinerant Internet Protocol 7 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 7 4.2. Short Circuit Mechanism . . . . . . . . . . . . . . . . . 9 4.2. Itinerant Internet Protocol Signalling . . . . . . . . .10 4.3. IPSec Requirements for Binding Updates and Binding Acknowledgement . . . . . . . . . . . . . . . . . . . . .11 4.4. Conceptual Data Structures . . . . . . . . . . . . . . .11 4.5. Binding Management . . . . . . . . . . . . . . . . . . .14 5. Itinerant Internet Protocol Signalling Message Type . . . . . .15 5.1. Binding Update packet . . . . . . . . . . . . . . . . . .15 5.2. Binding Acknowledgement packet . . . . . . . . . . . . .18 5.3. Binding Request packet . . . . . . . . . . . . . . . . .20 6. Requirements for IP Nodes 22 6.1. Requirements for All Mobile Aware Nodes . . . . . . . . .22 6.2. Requirements for Base Home Register . . . . . . . . . . .22 6.3. Requirements for Temporary Visit Register . . . . . . . .23 6.4. Requirements for Near Correspondent Register . . . . . .24 7. Correspondent Node Operation 25 7.1. Receiving Binding Updates . . . . . . . . . . . . . . . .25 7.2. Request to Cache a Binding . . . . . . . . . . . . . . .26 7.3. Sending Binding Acknowledgements . . . . . . . . . . . .26 7.4. Sending Binding Requests . . . . . . . . . . . . . . . .27 7.5. Cache Replacement Policy . . . . . . . . . . . . . . . .27 7.6. Sending Packet to a Mobile Node . . . . . . . . . . . . .28 8. Base Home Register Operation 29 8.1. Co-located Address Registration . . . . . . . . . . . . .29 8.2. Intercepting Packets for a Mobile Node . . . . . . . . .30 8.3. Tunnelling Intercepted Packets to a Mobile Node . . . . .30 Chern Nam Yap Expires 10 July 2001 Page ii Internet Draft Itinerant Internet Protocol 10 January 2000 9. Temporary Visit Register Operation 31 9.1. Co-located Address Registration . . . . . . . . . . . . .31 9.2. Intercepting Packets for a Mobile Node . . . . . . . . .32 10. Near Correspondent Register Operation 33 10.1. Near Correspondent Registration . . . . . . . . . . . .33 10.2. Intercepting Packets for a Mobile Node . . . . . . . . .34 10.3. Tunnelling Intercepted Packets to a Mobile Node . . . .34 11. Mobile Node Operation 35 11.1. Sending Packets While Away from Home . . . . . . . . . .35 11.2. Receiving Packets While Away from Home . . . . . . . . .35 11.3. Movement Detection . . . . . . . . . . . . . . . . . . .35 11.4. Sending Binding Updates to the Base Home Register . . .36 11.5. Sending Binding Updates to the Temporary Visit Register.37 11.6. Sending Binding Updates to the Near Correspondent Visit Register . . . . . . . . . . . . . . . . . . . . . . . .37 11.7. Sending Binding Updates to Correspondent Nodes . . . . .38 11.8. Retransmit Binding Updates . . . . . . . . . . . . . . .39 11.9. Receiving Binding Acknowledgements . . . . . . . . . . .39 11.10. Routing Multicast Packets . . . . . . . . . . . . . . .40 12. Protocol Constants 42 13. IANA Considerations 43 References 44 Authors' Addresses 45 Chern Nam Yap Expires 10 July 2001 Page iii Internet Draft Itinerant Internet Protocol 10 January 2000 1. Introduction This document specifies a protocol that allows any IP node to communicate with any other IP node in the mobile environment with minimum changes to TCP/IP. Without mobility awareness or mobility management on an IP machine, communicating would not be possible when either side changes IP subnets. This is because current IP routing is subnet prefix based and not Host based. In order to allow communication in spite of the move, address updating to all sides of the communication is required. This allows communication in this scenario to be unaffected. Such a scheme is defined as a protocol known as "Itinerant Internet Protocol" (IIP). - In the basic scheme, all nodes are mobile aware. The initialising node MUST send a query for the destination node's latest address. In order not to incur any delay, data is sent immediately after the query has been sent. The query SHOULD be responded to and the initialising node SHOULD reconstruct the data packet destination address with the latest information to send to the mobile node. Moreover, data transmission and subsequent updates of address MAY be multi-homed. All data traffic is pure standard IP routing. - In the backward compatibility scheme where the correspondent node is not mobile aware, there are two cases of communication. Case 1 The initialising node is the mobile node. When the mobile node leaves a particular subnet and the correspondent node sends data to the mobile node, the previous subnet's anchoring point SHOULD forward all the packets to the mobile node. Case 2 The initialising node is the correspondent node. The mobile node's home anchoring point SHOULD always first forward all the packets to the mobile node. If a mobile aware anchoring point is discovered between correspondent node and the home anchoring point, this mobile aware anchoring point will the forward the packets to the mobile node. In order to support ingress filtering, in the reverse traffic (from the mobile node to the correspondent node) will still done through the home anchoring point. IIP is suitable for mobility across both homogenous and heterogeneous media. One can think that IIP is a solution to the 3G IP mobility problems as it is designed to do so. Chern Nam Yap Expires 10 July 2001 Page 1 Internet Draft Itinerant Internet Protocol 10 January 2000 2. Comparison with Mobile IP IIP is designed to work across both IPv4 and IPv6. IIP is situated at a layer between TCP/IP and applications. This layer is known as Management Layer, and because of this IIP reduces the need to concern or to do any harm to the progression of IP development. The differences between Mobile IP and IIP are described as follows: - Diversion is a MUST for IIP mobile aware correspondent nodes. Data traffic after diversion does not incur encapsulation. IIP always tries to avoid using the forwarding mechanism whenever possible. Diversion is a method to change IP address of any IP packet before the packet is being sent out. This is normally done after the packet is formed. This is so that there SHOULD NOT have any effect on the transport layer whenever a mobile node moves hence it is transparent to any transport layer. - IIP uses a "first communication contact addressing mechanism" and "short circuit mechanism" to improve triangular routing. Temporary Visit Register and Near Correspondent Register are invented to achieve such effect. In many case, IIP SHOULD assume each subnet would have at least one anchoring entity that act as a BHR/NCR/TVR. Temporary Visit Register can be upgraded to a Base Home Register to increase reliability in connections. NCR is assumed MAY exist in between Correspondent Node and BHR. Thus there is no complex Hierarchical topology in IIP scheme for mobile network. - A mobile node in IIP MUST always use its latest co-located address in the source field in any of its IP packets. In such manner, mobile node is always in the right topology, and hence it has no problem with ingress filtering [1]. - IIP Binding Updates contain the latest transport port value allowing multi-home and MPLS operation to be carried out. Many application uses dynamic ports allocation while the connection is kept. With support latest transport port value allows easier applications creation. - No mobility action takes place during cell-to-cell switching in a single IP subnet. This is due to fact subnet prefix switching mechanism, like PPP [12], is used. Hence no periodic Agent Advertisements would be need that significantly cut down traffic between mobile node and the core network. Thus IIP uses simple control signalling rather many different complex type of signalling. Chern Nam Yap Expires 10 July 2001 Page 2 Internet Draft Itinerant Internet Protocol 10 January 2000 - No need to worry for IPv4 to IPv6 transitions, fully compatible with both IPv4 and IPv6 at the same time. Machines that can handle both IPv4 and IPv6 SHOULD not have problems receiving IPv4 and IPv6 packets in the mobile environment. Chern Nam Yap Expires 10 July 2001 Page 3 Internet Draft Itinerant Internet Protocol 10 January 2000 3. Terminology 3.1 General Term IP Internet Protocol. IIP Itinerant Internet Protocol. Node A device that implements IP. Router A node that forwards IP packets not explicitly address to itself. Host Any node that is not a router. Link The Layer underneath IP. Subnet prefix A bit string that consist of a number of initial bits of an IP address. Packet An IP header plus payload. 3.2 Itinerant Internet Protocol Terms Home Address An IP address assigned to a mobile node within the HOME link. Visit Address An IP address assigned to a mobile node within a visit link. Near Address An IP address either belongs to a Near Correspondent Register Home Subnet Prefix The subnet prefix associated with the mobile node's Home Address. Visit Subnet Prefix The subnet prefix associated with mobile node's Visit Address. Chern Nam Yap Expires 10 July 2001 Page 4 Internet Draft Itinerant Internet Protocol 10 January 2000 HOME link The link where the mobile node's home subnet prefix is defined. Visit Link The link where mobile node's visit subnet prefix is defined. Old link The link where a mobile node is assigned a Home/Visit Address. It can be either HOME link or Visit link. New link The link that a mobile node has just entered, it can be either a HOME link or Visit link. Mobile node A node whose movement between subnets has minimum effect on its applications. Movement A change in link, when a mobile node moves from an OLD link to a NEW link. Correspondent node A peer node that the mobile node is communicating with. It can be mobile or stationary. BHR (Base Home Register) An anchoring point for the mobile node at the HOME link that aids the mobile node to diverse its address. It also forwards packets to the mobile node when there is necessity to do so. TVR (Temporary Visit Register) An anchoring point for the mobile node at a visit link that aids in forwarding packets to the mobile node when the mobile node leaves the OLD link. NCR (Near Correspondent Register) An anchoring point for the mobile node situate between the correspondent node and BHR. It aids in forwarding packets to the mobile node to route optimise the link from the correspondent node to the mobile node if the correspondent node is not mobile aware and initialised the traffic first. Chern Nam Yap Expires 10 July 2001 Page 5 Internet Draft Itinerant Internet Protocol 10 January 2000 Co-located Address An IP address that the mobile node uses to co-locate itself. This address is used by the Mobile aware correspondent nodes, the BHR and the TVR to send packets to the mobile node. Binding The association of the Home/Visit address with the co-located address for any mobile node, along with the remaining lifetime of that association. Shorted Flag A flag in TOS field for mobile short-circuiting. 3.3 Specification Language The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENEDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Chern Nam Yap Expires 10 July 2001 Page 6 Internet Draft Itinerant Internet Protocol 10 January 2000 4. Overview of Itinerant Internet Protocol 4.1 Basic Operation In the basic scheme, a mobile node SHOULD be addressed by its co- located address, whether or not it is currently attached to the HOME link or a visit link. Standard IP routing is used when the mobile node is at home and there is no OLD link after the mobile node is switched on. When a mobile node moves to a NEW link, it SHOULD be assigned a co- located address. The mobile node SHOULD then register this address with its BHR and TVR. This is done through the means of address binding updates. Similarly, a correspondent node that is in communication with the mobile node SHOULD also get address binding updates. Packets sent to the mobile node SHOULD then either be forwarded or diverted to mobile node's latest co-located address. Example: A mobile node is switched on at Visit link, and it moves to its HOME link. In this case the Visit link is its OLD link and the HOME link is its NEW link. A new co-located address SHOULD be assigned to the mobile node and SHOULD be sent to the BHR and TVR. Since the mobile node is in the HOME link, the home address SHOULD be assigned to it. Packets that go straight to the HOME link SHOULD have not additional processing. If a communication was started in the OLD link (Visit link), the packets SHOULD be forwarded to the mobile node via the TVR by the means of tunnelling [6]. Hence the co-located address can either be the Home address or a Visit Address. The association between a mobile node's Home/Visit Address and co- located address is known as "Binding" for the mobile node. A mobile node typically acquires its co-located address through PPP [12]. Other methods of acquiring a co-located address are possible, but details of other methods are currently beyond the scope of this document. While a mobile node moves, it registers it newly acquired address with the BHR and TVR. Moreover, a mobile node can also upgrade one of its TVR to BHR in the case if its BHR is not working. The mobile node sends a "Binding Update" packet to achieve the above binding registration. The BHR or TVR SHOULD reply to the registration by sending a "Binding Acknowledgement" packet. Chern Nam Yap Expires 10 July 2001 Page 7 Internet Draft Itinerant Internet Protocol 10 January 2000 In IPv4, the mobile node's BHR/TVR SHOULD use "proxy ARP/gratuitous ARP" [7] to intercept any IP packets addressed to the mobile node's home/visit address. In IPv6, the mobile node's BHR/TVR SHOULD use "neighbour discovery mechanism" to intercept any IP packets addressed to the mobile node's home/visit address. The BHR/TVR MUST then divert (Address Binding Updates) or tunnel [6] the packets to the mobile node's co-located address. A mobile aware correspondent node MUST always use the diversion method. In which case, the correspondent node MUST send a "Binding Request". It is RECOMMENDED that data packets be sent immediately, without waiting for the "Binding Update" reply. In the backward compatibility scheme, communication between the mobile node and the correspondent node SHOULD depend on who has started the communication first. If the correspondent started the communication, the correspondent node could only have known the mobile node's home address (through DNS). Hence the BHR SHOULD tunnels [6] all traffic to the mobile node's latest co-located address. When the mobile node moves from one Visit Link to another, the TVR MUST intercept the mobile node's traffic and aid the tunnelling [6] process. The reason for this is simple, since the TVR in this sense provides smooth handoffs. Moreover, the mobile node will initiate a NCR discovery mechanism (Short Circuit mechanism). Once a NCR is found along the way between the correspondent node and BHR, NCR will take over the forwarding functionality of the BHR in the direction towards the mobile node. If the mobile node starts the communication, then it SHOULD depend on where the mobile node is located. If the mobile node is located at the HOME link, then it is very much the same as if the correspondent node started the communication. If the mobile node is located at a visit link, due to the fact the mobile node SHOULD use the visit address as the source field in the IP packet, the correspondent SHOULD send all the traffic to this visit address. As the mobile node moves to a NEW link, the OLD link TVR SHOULD intercept the packets for the mobile node and tunnel [6] them to the mobile node. Chern Nam Yap Expires 10 July 2001 Page 8 Internet Draft Itinerant Internet Protocol 10 January 2000 All mobile nodes MUST be mobile aware correspondent nodes and MUST be able to do forwarding and reverse tunnelling [6]. In any case a BHR/TVR/NCR can be a mobile node as well. If a BHR/TVR/NCR works as a mobile node, it MUST first handover its functionality before it becomes mobile. This functionality of BHR and TVR being mobile SHOULD not be mentioned in this document, but on another document. Any peer communicating with a mobile node is referred to in this document as a "correspondent node". It MAY be either a mobile node or stationary node. Currently Binding Update, Binding Acknowledgment and Binding Request are all in UDP [9] payload format. This might change in the future to SCTP [14] payload format as well. Currently, the protocol will work on port 700 that currently is unassigned by any protocol. Mobile node MUST always source its packets using its NEW link co- located address, whether it is a Home address or Visit address. Hence the mobile node is always topologically correct. Thus IIP does not need to deal with "ingress-filtering issues" [1]. 4.2 Short Circuit Mechanism As aforementioned this is a NCR discovery mechanism. Whenever a non- mobile-aware correspondent node sends a packet to mobile node. The packet will be tunnelled through the BHR. This forwarding process indicated that the either mobile node is in anonymous mode or the correspondent node is not mobile-aware. If shorted circuit were done, the mobile node would as well receive a forwarded packet. Mobile Node would ignore to re preformed "Short Circuit Mechanism" as there isn't a need to. The first packet that mobile node send back to the correspondent node in the IP header would have a flag in the unused TOS field. Normal IPv4 header with the unused TOS field flag This flag is known as Shorted Flag throughout this document 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | IHL | TOS |1| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | | Chern Nam Yap Expires 10 July 2001 Page 9 Internet Draft Itinerant Internet Protocol 10 January 2000 IP version 6 is not mentioned here is assumed that all IP version 6 node SHOULD be mobile aware, hence this feature is not required. Since every router along the way would have to decode the IP header (i.e. between the BHR and the Correspondent Node). If a NCR exist, it should be able to pick up this and send a "Near Registration" to the Mobile Node. Hence once the two-way "Near Registration" (explained in 10.1) is completed, the route from non-mobile aware correspondent node to mobile node will be "short circuited" as the NCR would intercept mobile node packet and forward to the mobile node's latest link. The mobile node SHOULD send Binding Update refresh to keep this short circuit. 4.2 Itinerant Internet Protocol Signalling As discussed in general in Section 4.1, the following three new UDP [9] packets are defined for IIP Signalling. Binding Update The mobile node notifies the BHR/TVR/NCR as well as in communication with correspondent nodes using this packet. This packet is also used by the BHR to reply to a correspondent node request of the mobile node's current co-located address. At the same time this packet is also used by the NCR start "short circuiting". The Binding Update sent to the BHR to register the mobile node's co-located address is known as "Home Registration". The Binding Update sent to the TVR to register the mobile node's co-located address is known as "Visit Registration". Any mobile node can upgrade its TVR to BHR using "Home Registration". The Binding Update sent by NCR to Mobile Node for "short circuiting" is known as "Near Registration". This packet SHOULD be protected from security attacks. Currently, IPSec [2] is used to protect this Binding Update packet as defined in Section 4.3 to guard against any malicious Binding Updates. Binding Acknowledgment This packet is used to acknowledge receipt of Binding Update, if an acknowledgement was requested in the Binding Update. This packet SHOULD be protected from security attacks. Currently, IPSec [2] is used to protect this Binding Acknowledgment packet as defined in Section 4.3 to guard against any malicious Binding Acknowledgment. Chern Nam Yap Expires 10 July 2001 Page 10 Internet Draft Itinerant Internet Protocol 10 January 2000 Binding Request Correspondent node uses this packet to request for mobile node's latest co-located. This packet is normally sent to BHR/TVR, and a correspondent node for refreshing binding also can use it. This is sent as a normal packet, or it can also be sent with security protection. 4.3 IPSec [2] Requirements for Binding Updates and Binding Acknowledgement. Currently, IPSec [2] MUST be used to protect both Binding Update and Binding Acknowledgement packets. Specifically, any Binding Update or Binding Acknowledgement packet MUST utilise IPSec [2] sender authentication, data integrity protection, and replay protection. Currently, IIP requires that this protection covering a Binding Update or Binding Acknowledgement MUST use AH [4] and ESP [5]. IIP is a transport payload, hence it is easily protected by AH [4] and ESP [5]. 4.4 Conceptual Data Structures This document describes IIP in terms of the following conceptual data structures: Mobile Binding Cache Each mobile aware node needs to maintain a binding cache. This cache contains bindings of the mobile aware node with any mobile nodes. The Mobile Binding Cache MAY be implemented in any manner consistence with the external behaviour described in this document. Each Mobile Binding Cache entry conceptually contains the following fields: - Home/Visit Address of a mobile node. This field is used as the key value to aid searching the Binding Cache for the destination address of a packet being sent. When the destination address of the packet matches Home/Visit Address in the Binding Cache entry, this entry SHOULD be used in routing that packet. - The co-located address of mobile node. It is the field in the same entry that is associated with the Home/Visit field. If the destination address of a packet being sent matches Home/Visit Address, then the packet SHOULD be routed to this co-located address. Chern Nam Yap Expires 10 July 2001 Page 11 Internet Draft Itinerant Internet Protocol 10 January 2000 - A lifetime value that shows the remaining lifetime for this Binding Cache entry. This value is initialised from the lifetime field in the Binding Update that created or last modified this Binding Cache entry. Once the lifetime on this entry has expires, the entry MUST be deleted from the Binding Cache. - A flag indicating whether this Binding Cache entry is a "Home Registration" or "Visit Registration" or "Near Registration". - The Maximum value of the Sequence Number field that is received in previous Binding Updates for this mobile node home address. The Sequence Number field is 32 bit long, and all comparisons between Sequence Number values MUST be performed modulo 2^32. - Binding Cache entry recent usage information. It is needed to implement cache replacement policy in use in the Binding Cache. This also assists in determining whether a Binding Request SHOULD be sent when the lifetime on this entry is near expiration. An entry in a node's Binding Cache for which the node is serving as a BHR is marked as "Home Registration" entry (TVR is marked as "Visit Registration" entry, NCR is marked as "Near Registration" entry). This entry SHOULD NOT be deleted by the BHR/TVR/NCR until the expiration of its binding lifetime. Other Binding Cache entries MAY be replaced at any time by any reasonable local cache replacement policy but SHOULD NOT unnecessary to be deleted. The node's Binding Cache MAY contain at most one entry for each mobile node Home/Visit Address. Binding Update List Binding Update list that is maintained by each mobile node, records information for each Binding Update sent by the mobile node for which the lifetime sent in that Binding Update has not been expired. It includes all bindings sent by the mobile node to its correspondent nodes, BHR/TVR/NCR. However, for multiple Binding Updates sent to the same destination address, the Binding Update List contains only the most recent Binding Updates (where Greatest Sequence Number is used in this case to confirm the most recent Binding Updates) sent to the destination. The Binding Update list MAY be implemented in any manner consistent with the external behaviour as described in this document. Each Biding update list entry conceptually contains the following fields: Chern Nam Yap Expires 10 July 2001 Page 12 Internet Draft Itinerant Internet Protocol 10 January 2000 - The IP address of the node to which a Binding Update was sent. If the Binding Update was successfully received by that node and if that node has not been deleted the entry before its expiration, this node might still have a Binding Cache entry. - The Home/Visit address for which that Binding update was sent. This is meant for the mobile node to distinguish between co-located and Home/Visit address. - The co-located address of the Binding Update. This value is necessary for the mobile node to determine if it has sent its latest co-located address in the Binding Update to the right destination after changing its co-located address. - The initial value of the Lifetime field sent in that Binding Update. - The remaining lifetime of that binding. This lifetime is initialised from the lifetime value sent in the Binding Update and is decremented until it reaches zero, at which time this entry MUST be deleted from the Binding Update list. - The maximum value of the Sequence Number field sent in previous Binding Updates to this destination. The Sequence Number field is 32 bit long, and all comparisons between Sequence Number values MUST be performed modulo 2^32. - The time at which a Binding Update was last sent to this destination, as needed to implement the rate limiting restriction for sending Binding Updates. - The state of any retransmissions needed for this Binding Update. This state includes the time remaining until the next retransmission attempts for the Binding Update, and the current state of the exponential back-off mechanism for retransmissions. - A flag that indicates that future Binding Updates SHOULD not be sent to any particular destination when it is being set. Chern Nam Yap Expires 10 July 2001 Page 13 Internet Draft Itinerant Internet Protocol 10 January 2000 4.5 Binding Management When a mobile node acquires a new co-located address, the mobile node SHOULD register this new binding with its BHR/TVR/NCR by sending the BHR/TVR/NCR a Binding Update. The mobile node indicates that an acknowledgement is needed for this Binding Update and continues to periodically retransmit it until it receives an acknowledgment. The acknowledgement is in the form of Binding Acknowledgement packet as mentioned above. When a mobile node receives a packet tunnelled [6] to it from the BHR/TVR/NCR, it SHOULD assume that the original sender is not mobile aware, until it receives a packet that is send directly from the sender to the mobile node, if the communication is not initiated by the mobile node. When this takes place, as aforementioned "short circuit mechanism" should take place. A correspondent node with a Binding Cache entry for a mobile node MAY wanted to refresh this binding, for example if the binding's lifetime is near expiration, by the correspondent node MAY send a Binding Request to the mobile node for a refresh for the Binding. Normally, a correspondent node SHOULD only refresh a Binding Cache entry in this way if it is actively having a ongoing communication with the mobile node. (For example as an open TCP [10] connection to the mobile node) When a mobile node receives a Binding Request, it replies by returning a Binding Update to the node sending the Binding Request. Since some correspondent nodes are mobile aware, it is expected that correspondent nodes SHOULD usually route packets directly to the mobile node's co-located address, so that the BHR is rarely involved with the packet transmission to the mobile node. This is essential for scalability and reliability, and for minimising overall network load. Optimal routing of packets can be achieved from the correspondent node to the mobile node, by caching the co-located address of a mobile node. Routing packets directly to the mobile node's co-located address also eliminates congestion at the mobile node's BHR and HOME link. In addition, the impact of any possible failure of the BHR, the HOME link, or intervening networks leading to or from the HOME link is reduced, since these nodes and links are not involved in the delivery of most packets to the mobile node. Mobile node should try to upgrade all of its TVR to BHR to allow minimum loss of connection when BHR fails. Hence IIP is a more reliable protocol. Chern Nam Yap Expires 10 July 2001 Page 14 Internet Draft Itinerant Internet Protocol 10 January 2000 5. Itinerant Internet Protocol Signalling Message Types 5.1 Binding Update Packet The Binding Update is used by the mobile node to notify its BHR/TVR/NCR Correspondent nodes of a newly assigned co-located address. The Binding Update packet is encoded in type-length value (TLV) format as follows: 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 | Options | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home / Visit / Near / Co-located IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Number | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Length The total length of the message, in bytes, excluding the Type and Length bytes. Options: Based on 8bit ASCII code ______________________________________________________________________ Acknowledge (A) The Acknowledge (A) bit is set by the sending mobile node to request a Binding Acknowledgement (Section 5.2) be returned upon receipt of the Binding Update. Mobile Node (M) The Mobile Node (M) bit is set by the sending mobile node to the correspondent node for identification. Base Home Register (B) The Base Home Register (B) bit is set by the BHR to the correspondent node for identification. Chern Nam Yap Expires 10 July 2001 Page 15 Internet Draft Itinerant Internet Protocol 10 January 2000 Temporary Visit Register (T) The Temporary Visit Register (T) bit is set by the TVR to the correspondent node for identification. Home Registration (H) The Home Registration (H) bit is set by a mobile node to request the receiving node to be its BHR. The destination of the packet carrying this option MUST be a node sharing the same subnet prefix as the mobile node Home address. Visit Registration (V) The Visit Registration (V) bit is set by a mobile node to request the receiving node to be its TVR. The destination of the packet carrying this option MUST be a node sharing the same subnet prefix as the mobile node Visit address. Near Registration (N) The Near Registration (N) bit is set by a mobile node/NCR to register/update NCR. Privacy (P) Privacy (P) bit is set by mobile node to allow it to run in privacy, no binding update SHOULD be sent to correspondent node as the mobile node wish to be anonymous. Reserved This field is unused. It MUST be initialised to zero by the sender and MUST be ignored by the receiver. Sequence Number Used by the receiving node to sequence Binding Updates and by the sending node to match a returned Binding Acknowledgement with this Binding Update. Each Binding Update sent by a mobile node MUST use a Sequence Number greater than the Sequence Number value sent in the previous Binding Update (if any) to the same destination address (modulo 2^32). There is no requirement, however, that the Sequence Number value strictly increase by 1 with each new Binding Update sent or received. Lifetime It is 32-bit unsigned integer. The number of seconds remaining before the binding MUST be considered expired. A value of all one bits (0xffffffff) indicates infinity. A value of zero indicates that the Binding Cache entry for the mobile node MUST be deleted. Chern Nam Yap Expires 10 July 2001 Page 16 Internet Draft Itinerant Internet Protocol 10 January 2000 Home/Visit/Co-located Address If the Home/Visit IP Address is sent to the BHR/TVR/NCR/Correspondent Node to update Binding by the mobile node, then the M bit MUST be set here. If the Near IP Address is set to Mobile Node to "short-circuit" by the NCR, then the N bit MUST be set here. If the Co-located IP Address is sent to Correspondent Node to update the Binding by the BHR, then the B bit MUST be set here. If the Co-located IP Address is sent to Correspondent Node to update the Binding by the TVR, then the T bit MUST be set here. Port Number This is a 16-bit value to allow change of port number that mobile node and the correspondent node would agree on using for the future communication. Session ID This is a 16-bit value to allow identification for corresponding Binding Request/Binding Updates/Binding Acknowledgement. The co-located address for the binding given in the Binding Update is specified by the Source Address field. It is in the IP header of the Binding Update. A Binding Cache entry for the mobile node MUST NOT be created in response to the following Binding Update packet: If present, or in the Source Address field in the packet's IP header is equal to the home address of the mobile node and if the lifetime field in the Binding Update is equal to 0. The mobile node stores the Last Sequence Number value in Binding Update list entry for a destination that it sent a Binding Update. The correspondent node store the Last Sequence Number value that is received from a mobile node in a Binding Update in its Binding Cache entry for that mobile node. Thus, the mobile node and correspondent node SHOULD have the knowledge of the Last Sequence Number and SHOULD expire at the same time. If the sending mobile node has no Binding Update List entry, the Sequence Number MAY start at any value. If the receiving correspondent node has no Binding Cache entry for the sending mobile node, it MUST accept any Sequence Number value in a received Binding Update from the mobile node. Chern Nam Yap Expires 10 July 2001 Page 17 Internet Draft Itinerant Internet Protocol 10 January 2000 5.2 Binding Acknowledgement Packet The Binding Acknowledgement packet is used to acknowledge receipt of a Binding Update (Section 5.1). When a node receives the Binding Update Packet, it MUST return a Binding Acknowledgement to the source of the packet if the Acknowledge (A) bit is set in the Binding Update. The Binding Acknowledgement packet is encoded in type-length-value (TLV) format as follows: 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 | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Number | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 Length The total length of the message, in bytes, excluding the Type and Length bytes. Status It is an 8-bit unsigned integer indicating the disposition of the Binding Updates. Values of the Status field less than 128 indicate that the receiving node accepted the Binding Updates. The following such Status values are currently defined: 0 Binding Update accepted Chern Nam Yap Expires 10 July 2001 Page 18 Internet Draft Itinerant Internet Protocol 10 January 2000 Values of the Status field greater than or equal to 128 indicate that the receiving node rejected the Binding Updates. The following such Status values are currently defined: 128 Reason unspecified 129 Administratively prohibited 130 Insufficient resources 131 Not BHR for this mobile node 132 Not TVR for this mobile node 133 Not NCR for this mobile node 134 Home registrations not supported 135 Visit registrations not supported 136 Not home subnet 137 Not visit subnet Reserved This field is unused. It MUST be initialised to zero by the sender and MUST be ignored by the receiver. Sequence Number Sequence Number in the Binding Acknowledgment is copied form the Sequence Number field in the Binding Update being acknowledge, for use by the mobile node in matching this Acknowledgement with an outstanding Binding Update. Lifetime The granted lifetime is in terms of seconds. If the node sending the Binding Acknowledgement is serving as the mobile node's BHR/TVR, the lifetime period SHOULD also indicate the period for which this node SHOULD continue this service. If the mobile node requires BHR/TVR service from this node beyond this period, the mobile node MUST send a new Binding Update to it before the expiration of this period, in order to extend the lifetime. The value of this field SHOULD be undefined it the Status field indicated that the Binding Update was rejected. Port Number This is a 16-bit value to allow change of port number that mobile node and the correspondent node would agree on using for the future communication. Session ID This is a 16-bit value to allow identification for corresponding Binding Request/Binding Updates/Binding Acknowledgement. Chern Nam Yap Expires 10 July 2001 Page 19 Internet Draft Itinerant Internet Protocol 10 January 2000 If the node returning the Binding Acknowledgement accepts the Binding Update for which the Acknowledgement is being returned (The value of the Status field in the Acknowledgement is less than 128), this node SHOULD have an entry for the mobile node in its Binding Cache and MUST use this entry (which includes the co-located address received in the Binding Update) to send the Binding Acknowledgement packet to the mobile node. The details of sending this packet to the mobile node are the same for sending any packet to a mobile node using a binding, and are described in Section 7.7. The packet is routed to the mobile node by way of its co-located address recorded in the Binding Cache entry. If the node returning the Binding Acknowledgement instead rejects the Binding Update (the value of the status field in the Acknowledgement is greater than or equal to 128), the co-located address used by this node for sending the Binding Acknowledgement packet MUST be copied from the co-located address received in the rejected Binding Update. This node MUST NOT modify its Binding Cache in response to receiving this rejected Binding Update and MUST ignore its Binding Cache in sending this Binding Acknowledgement packet. This packet is routed to the co-located address of the rejected Binding Updated packet. 5.3 Binding Request Packet The Binding Request Packet is used to request a mobile node's binding from the BHR. When the BHR receives a Binding request packet, it SHOULD return a Binding Update (Section 5.1) to the source of the Binding Request, if the mobile node has not requested privacy through the use of the P bit. The Binding Request packet is encoded in type-length-value (TLV) format as follows: 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 | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 Length The total length of the message, in bytes, excluding the Type and Length bytes. Chern Nam Yap Expires 10 July 2001 Page 20 Internet Draft Itinerant Internet Protocol 10 January 2000 Session ID This is a 16-bit value to allow identification for corresponding Binding Request/Binding Updates/Binding Acknowledgement. Session ID Chern Nam Yap Expires 10 July 2001 Page 21 Internet Draft Itinerant Internet Protocol 10 January 2000 6. Requirement for IP Nodes IIP places some requirements on the functions needed to make a node mobile aware. This section summarises those requirements by identifying the functionality each requirement is intended to support. Further details on this functionality are provided in the following sections. 6.1 Requirements for All Mobile Aware Nodes Since any mobile node MAY at any time be a correspondent node, either sending or receiving a packet, the following requirements apply to all mobile nodes: - Every mobile node MUST be able to process a Binding Update packet, and to return a Binding Acknowledgement packet if the Acknowledge (A) bit is set in the received Binding Update. - Every mobile node SHOULD be able to maintain a Binding Cache of the binding received in the accepted Binding Updates. - Every mobile node MUST be able to decapsulate and reverse tunnel [6] any packet to the BHR or TVR. -Every mobile node MUST maintain a Binding Update List in which it records the IP address of each node to which it has sent a Binding Update, for which the lifetime sent in that binding has not expired. 6.2 Requirements for Base Home Register In order to enable a mobile node to operate correctly while away from home, there MUST be a node to act as BHR for the mobile node. The following requirements apply to the BHR: - Every BHR MUST be able to maintain an entry in its Binding Cache for each mobile node it is serving. Each Binding Cache entry records the mobile node binding with its co-located address. Chern Nam Yap Expires 10 July 2001 Page 22 Internet Draft Itinerant Internet Protocol 10 January 2000 - Every BHR MUST be able to intercept packets as mentioned above, addressed to the mobile node, for which it is currently serving as the BHR on the mobile node's HOME link, while the mobile node is away from home. - Every BHR MUST be able to encapsulate such packets in order to tunnel [6] them to the co-located address of the mobile node indicated in its binding in the BHR's Binding Cache. - Every BHR MUST be able to return a Binding Acknowledgement packet in response to a Binding Update packets received with (A) bit set. - Every BHR MUST maintain a separate BHR List for each link on which it is serving as a BHR. - Every BHR MUST be able to process a Binding Request packet, and response with a Binding Update. This Binding Update is sent back to the correspondent node, and holds the requested mobile node's latest co-located IP address. 6.3 Requirement for Temporary Visit Register In order to enable a mobile node to operate correctly while away from visit, there MUST be a node to act as a TVR for the mobile node. The following requirements apply to the TVR: - Every TVR MUST be able to maintain an entry in its Binding Cache for each mobile node it serves. Each Binding Cache entry records the mobile node's binding with its co-located address. - Every TVR MUST be able to intercept packets addressed to a mobile node for which it is currently serving as the TVR, while the mobile node is away from its visit link. - Every TVR MUST be able to encapsulate packets in order to tunnel [6] them to the new co-located address for the mobile node indicated in its binding in the TVR's Binding Cache. - Every TVR MUST be able to return a Binding Acknowledgement packet in response to Binding Update packets received with (A) bit set. - Every TVR MUST maintain a separate TVR List for each link on which it is serving as TVR. - Every TVR SHOULD be able to upgraded to a BHR, if there are such requests from a mobile node. Chern Nam Yap Expires 10 July 2001 Page 23 Internet Draft Itinerant Internet Protocol 10 January 2000 6.4 Requirements for Near Correspondent Register In order to enable a mobile node to "short circuit", it is assume that there MAY be a node to act as NCR for the mobile node. The following requirements apply to the NCR: - Every NCR MUST be able to maintain an entry in its Binding Cache for each mobile node it is serving. Each Binding Cache entry records the mobile node binding with its co-located address. - Every NCR MUST be able to intercept packets as mentioned above, addressed to the mobile node, for which it is currently serving as the NCR. - Every NCR MUST be able to encapsulate such packets in order to tunnel [6] them to the co-located address of the mobile node indicated in its binding in the NCR's Binding Cache. - Every NCR MUST be able to return a Binding Acknowledgement packet in response to a Binding Update packets received with (A) bit set. - Every NCR MUST maintain a separate NCR List for each link on which it is serving as a NCR. - Every NCR MUST be able to process Shorted Flag and perform Near Registration. - A NCR MAY be upgraded to a BHR, if a mobile node requested and the NCR can provide an IP address to the mobile node. Chern Nam Yap Expires 10 July 2001 Page 24 Internet Draft Itinerant Internet Protocol 10 January 2000 7. Correspondent Node Operation A correspondent node is any node communicating with a mobile node. The correspondent node itself MAY be stationary or mobile. In this section, only the mobile aware correspondent node SHOULD be mentioned, as there is no point in mentioning non-mobile aware correspondent node. 7.1 Receiving Binding Updates Upon receiving a Binding Update in some packet, the receiving node MUST validate the Biding Update according to the following tests: - The packet meets the specific IPSec [2] requirements for Binding Updates, defined in Section 4.3 - The address for binding is specified by the Home/Visit/Co-located field. Either the M bit or the B bit MUST be set. - The Sequence Number field in the Binding Update is greater than the Sequence Number received in the previous Binding Update for this home address, if any. As note in Section 4.6, this Sequence Number comparison MUST be performed modulo 2^32. Any invalid Binding Update MUST be silently ignored, and the Binding Update packet MUST be discarded. If the Binding Update is valid according to the tests above, then the Binding Update is processed further as follows: - If the lifetime specified in the Binding Update is nonzero and the specified co-located address is not equal to the home address for the binding, then this is a request to cache a binding for the mobile node. If the Home Registration (H) bit is set in the Binding Update, the Binding Update SHOULD be processed according to the procedure specified in Section 8.1. If the Visit Registration (V) bit is set in the Binding Update, the Binding Update is processed according to the procedure specified in Section 9.1. Otherwise, it is processed according to the procedure specified in Section 7.2. - If the lifetime specified in the Binding Update is zero or the specified co-located address matches the home address for the binding, then this is a request to delete the mobile node's cached binding. If the Home Registration (H) bit is set in the Binding Update, the Binding Update is processed according to the procedure specified in Section 8.2. If the Visit Registration (V) bit is set in the Binding Update, the Binding Update is processed according to the procedure specified in Section 9.2. Otherwise, it is processed according to the procedure specified in Section 7.3. Chern Nam Yap Expires 10 July 2001 Page 25 Internet Draft Itinerant Internet Protocol 10 January 2000 7.2 Request to Cache a Binding When a node receives a Binding Update, it MUST validate it and determine the type of Binding Update according to the steps described in Section 7.1. This section describes the processing of a valid Binding Update that requests a node to cache a mobile node's binding, for which the Home Registration (H) bit or Visit Registration (V) bit is not set in the Binding Update. In this case, the receiving node SHOULD create a new entry in its Binding Cache for this mobile node (or update its existing Binding Cache entry for this mobile node, if such an entry already exists). The home address of the mobile node is taken from the Home/Visit Address field. The new Binding Cache entry records the association between this home address and the co-located address for the binding, as specified in co-located address field of the Binding Update packet's source address field. The lifetime for the Binding Cache entry is initialised from the Lifetime field specified in the Binding Update, although the node caching the binding MAY reduce this lifetime. The lifetime for the Binding Cache entry MUST NOT be greater than the Lifetime value specified in the Binding Update. Any Binding Cache entry MUST be deleted after the expiration of this lifetime on the Binding Cache entry. 7.3 Sending Binding Acknowledgements When any node receives a Binding Update packet in which the Acknowledge (A) bit is set, it SHOULD return a Binding Acknowledgement packet acknowledging receipt of the Binding Update. If the node accepts the Binding Update and creates or updates an entry in its Binding Cache for this binding, the Status field in the Binding Acknowledgement MUST be set to a value less than 128. If the node rejects the Binding Update and does not create or update an entry for this binding, the Status field in the Binding Acknowledgement MUST be set to a value greater than or equal to 128. Specific values for the Status field are described in Section 5.2. The packet in which the Binding Acknowledgement is returned MUST meet the specific IPSec [2] requirements for Binding Acknowledgements. The packet MUST be sent to the mobile node using mobile node's co-located address (even if the binding was rejected), as described in section 7.8. The packet is routed first to the co-located address contained in the Binding Update being acknowledged and then mobile node home address. This ensures that the Binding Acknowledgement packet SHOULD be routed to the current location of the node sending the Binding Update, whether the Binding Update was accepted or rejected. Chern Nam Yap Expires 10 July 2001 Page 26 Internet Draft Itinerant Internet Protocol 10 January 2000 7.4 Sending Binding Requests Entries in a node's Binding Cache MUST be deleted when their lifetime expires. If such an entry is still in active use in sending packets to a mobile node, a new Binding Request SHOULD be sent to the mobile node's HOME link, where it SHOULD be intercepted and the BHR SHOULD send a Binding Update to the sender, allowing it to create a new Binding Cache entry for sending future packets to the mobile node. Communication with the mobile node continues uninterrupted, but this diversion creates overhead and latency in delivering packets to the mobile node. Any correspondent node will use the Session ID value that it sent to the BHR/TVR or the mobile node to verify which is the right session it is talking about. If the sender knows that the Binding Cache entry is still in active use, it MAY send a Binding Request packet to the mobile node in an attempt to avoid this overhead and latency due to deleting and recreating the Binding Cache entry. When the mobile node receives a Binding Request packet from some sender, it returns a Binding Update packet to that sender, giving its current binding and a new lifetime. 7.5 Cache Replacement Policy After the expiration of the Lifetime specified in the Binding Update from which any entry was created or last updated, the entry in a node's Binding Cache MUST be deleted. Conceptually, a node SHOULD maintain a separate timer for each entry in its Binding Cache. The node sets the timer for this entry to the specified Lifetime period when creating or updating a Binding Cache entry in response to a received and accepted Binding Update. When a Binding Cache entry's timer expires, the node deletes the entry. Chern Nam Yap Expires 10 July 2001 Page 27 Internet Draft Itinerant Internet Protocol 10 January 2000 Each node's Binding Cache SHOULD, by necessity, has a finite size. A node MAY use any reasonable local policy for managing the space within its Binding Cache, except that any entry marked as a "Home Registration" (Section 8.3) MUST NOT be deleted from the cache until the expiration of its lifetime period. This SHOULD as well apply to "Visit Registration". When attempting to add a new "Home Registration" entry in response to a Binding Update with the Home Registration (H) bit set, if insufficient space exists (or can be reclaimed) in the node's Binding Cache, the node MUST reject the Binding Update and SHOULD return a Binding Acknowledgement to the sending mobile node, in which the Status field is set to 130 (insufficient resources). When otherwise attempting to add a new entry to its Binding Cache, a node MAY, if needed, choose to drop any entry already in its Binding Cache, other than a "Home Registration" or "Visit Registration" entry, in order to make space for the new entry. Normally a BHR/TVR should have much more resources than normal nodes in a subnet, as it is RECOMMENDED that these nodes are able to work in such environment. Any binding dropped from a node's Binding Cache due to the lack of cache space SHOULD be rediscovered and a new cache entry SHOULD be created, if the binding is still in active use by the node for sending packets. If the node sends a packet to a destination for which it has dropped the entry from its Binding Cache, the packet SHOULD be routed normally, leading to the mobile node's HOME link. There, the packet SHOULD be intercepted by the mobile node's BHR and the BHR SHOULD reply with a Binding Updates that allowing the correspondent node to add an entry again for this destination mobile node to its Binding Cache. 7.6 Sending Packets to a Mobile Node Before sending any packet, the sending node SHOULD examine its Binding Cache for an entry for the destination address to which the packet is being sent. If the sending node has a Binding Cache entry for this address, the sending node SHOULD route the packet to this mobile node (the destination node) by way of the co-located address in the binding recorded in that Binding Cache entry. If, instead, the sending node has no Binding Cache entry for the destination address to which the packet is being sent, the sending node simply sends the Binding Request packet and SHOULD be intercepted by the mobile node's BHR which SHOULD sent the Binding Updates allowing the sending node to create a Binding Cache entry for its use in sending subsequent packets to this mobile node. Chern Nam Yap Expires 10 July 2001 Page 28 Internet Draft Itinerant Internet Protocol 10 January 2000 8. Base Home Register Operation A mobile node SHOULD have a default BHR, and MUST register itself to the BHR while it is at home. 8.1 Co-located Address Registration When a node receives a Binding Update, it MUST validate it and determine the type of Binding Update according to the steps described in Section 7.1. This section describes the processing of a valid Binding Update that requests the receiving node to serve as its BHR (Essentially a TVR), registering its co-located address. To begin processing the Binding Update, the BHR MUST perform the following sequence of tests: - If the home address for the binding is not in the same HOME link respect to the BHR links, then the BHR MUST reject the Binding Update and SHOULD return a Binding Acknowledgement to the mobile node, in which the Status field is set to 135 (Not home subnet). - Else, if the BHR chooses to reject the Binding Update for any other reason (e.g., insufficient resources to serve another mobile node as a Home Register), then the BHR SHOULD return a Binding Acknowledgement to the mobile node, in which the Status field is set to an appropriate value to indicate the reason for the rejection. If the BHR does not reject the Binding Update as described above, then it SHOULD update its existing Binding Cache entry for this mobile node. The home address of the mobile node is taken from the Home Address field. The co-located address for this Binding Cache entry is taken from the Source Address field in the packet header. The BHR MUST mark this Binding Cache entry as a "Home Registration" to indicate that the node is serving as a BHR for this binding. Binding Cache entries mark as a "Home Registration" MUST be excluded from the normal cache replacement policy used for the Binding Cache (Section 7.6) and MUST NOT be removed from the Binding Cache. If the Acknowledge (A) bit is set in the Binding Update (it SHOULD be), then the BHR MUST return a Binding Acknowledgement to the mobile node, constructed as follows: - The Status field MUST be set to a value indicating success (the value MUST be less than 128). The only currently defined success Status value is 0, indicating simply that the Binding Update was accepted. Chern Nam Yap Expires 10 July 2001 Page 29 Internet Draft Itinerant Internet Protocol 10 January 2000 - The Sequence Number field MUST be copied from the Sequence Number given in the Binding Update. - The Lifetime field MUST be set to the remaining lifetime for the binding as set by the BHR in its "Home Registration" Binding Cache entry for the mobile node. In addition, the BHR MUST follow the procedure defined in Section 8.2 to intercept packets on the mobile node's HOME link addressed to the mobile node. 8.2 Intercepting Packets for a Mobile Node While a node is serving as the BHR for the mobile node (while the node has an entry in its Binding Cache for this mobile node that is marked as a "Home Registration"), this node MUST attempt to intercept packets on the mobile node's HOME link addressed to the mobile node. It MUST return any Binding Request for any mobile node in BHR Entry, and it MUST tunnel [6] all data packets that are sent to the mobile node if there are any. 8.3 Tunnelled [6] Intercepted packets to a Mobile Node For forwarding each intercepted data packet to the mobile node, the BHR MUST tunnelled [6] the packet to the mobile node using IP in IP [6] encapsulation. The tunnel entry point node is the BHR, and the tunnel exit point node is the co-located address as registered with the BHR (It is the mobile node NEW link assigned address). When a BHR encapsulates an intercepted packet for forwarding to the mobile node, the BHR SHOULD set the Source Address in the tunnel IP header to the BHR own IP address, and SHOULD set the Destination Address in the tunnel IP header to the mobile node's co-located address. When received by the mobile node (using its co-located address), normal processing of the tunnel header SHOULD result in de-capsulation and processing of the original packet by the mobile node. Chern Nam Yap Expires 10 July 2001 Page 30 Internet Draft Itinerant Internet Protocol 10 January 2000 9. Temporary Visit Register Operation A mobile node MUST register itself to the TVR while it is at visit link. 9.1 Co-located Address Registration When a node receives a Binding Update, it MUST validate it and determine the type of Binding Update according to the steps described in Section 7.1. This section describes the processing of a valid Binding Update that requests the receiving node to serve as its TVR, registering its co-located address. To begin processing the Binding Update, the TVR MUST perform the following sequence of tests: - If the visit address for the binding is not in the same TVR links, then the TVR MUST reject the Binding Update and SHOULD return a Binding Acknowledgement to the mobile node, in which the Status field is set to 136 (Not visit subnet). - Else, if the TVR chooses to reject the Binding Update for any other reason (e.g., insufficient resources to serve another mobile node as a TVR), then the TVR SHOULD return a Binding Acknowledgement to the mobile node, in which the Status field is set to an appropriate value to indicate the reason for the rejection. If the TVR does not reject the Binding Update as described above, then it SHOULD update its existing Binding Cache entry for this mobile node. The visit address of the mobile node is taken from the Visit Address field. The co-located address for this Binding Cache entry is taken from the Source Address field in the packet header. The TVR MUST mark this Binding Cache entry as a "Visit Registration" to indicate that the node is serving as a TVR for this binding. Binding Cache entries marked as a "Visit Registration" MUST be excluded from the normal cache replacement policy used for the Binding Cache (Section 7.6) and MUST NOT be removed from the Binding Cache. Binding Cache entries mark as a "Visit Registration" MUST be remove if it receives a Binding Update without a "V" bit. If the Acknowledge (A) bit is set in the Binding Update (it SHOULD be), then the TVR MUST return a Binding Acknowledgement to the mobile node, constructed as follows: Chern Nam Yap Expires 10 July 2001 Page 31 Internet Draft Itinerant Internet Protocol 10 January 2000 - The Status field MUST be set to a value indicating success (the value MUST be less than 128). The only currently defined success Status value is 0, indicating simply that the Binding Update was accepted. - The Sequence Number field MUST be copied from the Sequence Number given in the Binding Update. - The Lifetime field MUST be set to the remaining lifetime for the binding as set by the TVR in its "Visit Registration" Binding Cache entry for the mobile node. In addition, the TVR MUST follow the procedure defined in Section 9.2 to intercept packets on the mobile node's TVR link addressed to the mobile node. 9.2 Intercepting Packets for a Mobile Node While a node is serving as the TVR for mobile node (while the node has an entry in its Binding Cache for this mobile node that is marked as a "Visit Registration"), this node MUST attempt to intercept packets on the mobile node's visit link addressed to the mobile node. It MUST tunnel [6] all data packet that is sent to the mobile node. For forwarding each intercepted data packet to the mobile node, the TVR MUST tunnels [6] the packets to the mobile node using IP in IP encapsulation. The tunnel entry point node is the TVR, and the tunnel exit point node is the co-located address as registered with the TVR. When a TVR encapsulates an intercepted packet for forwarding to the mobile node, the TVR sets the Source Address in the tunnel IP header to the TVR own IP address, and sets the Destination Address in the tunnel IP header to the mobile node's new co-located address. When received by the mobile node (using its co-located address), normal processing of the tunnel header SHOULD result in de-capsulation and processing of the original packet by the mobile node. Chern Nam Yap Expires 10 July 2001 Page 32 Internet Draft Itinerant Internet Protocol 10 January 2000 10. Near Correspondent Register Operation If a mobile node receives a tunnelled packet, it SHOULD perform "short circuit mechanism". 10.1 Near Correspondent Registration When a node picks up the Shorted Flag, it MUST validate it by sending a Binding Update to the mobile node. This node would only know about the mobile node's home address. The mobile node would acknowledge and at the same time send a Binding Updates with its latest co-located address to the NCR. N bit MUST be set when these Binding Updates is sent. This process is known as the two-way Near Correspondent Registration. When the NCR receives the Binding Update, it MUST validate it and determine the type of Binding Update according to the steps described in Section 7.1. This section describes the processing of a valid Binding Update that requests the receiving node update its co-located address. To begin processing the Binding Update, the NCR MUST perform the following sequence of tests: The NCR MUST mark this Binding Cache entry as a "Near Registration" to indicate that the node is serving as a NCR for this binding. Binding Cache entries mark as a "Near Registration" MAY be excluded from the normal cache replacement policy used for the Binding Cache (Section 7.6) and MAY be removed from the Binding Cache. This is because there is always a BHR to fall back on. If the Acknowledge (A) bit is set in the Binding Update (it SHOULD be), then the NCR MUST return a Binding Acknowledgement to the mobile node, constructed as follows: - The Status field MUST be set to a value indicating success (the value MUST be less than 128). The only currently defined success Status value is 0, indicating simply that the Binding Update was accepted. - The Sequence Number field MUST be copied from the Sequence Number given in the Binding Update. - The Lifetime field MUST be set to the remaining lifetime for the binding as set by the NCR in its "Near Registration" Binding Cache entry for the mobile node. Chern Nam Yap Expires 10 July 2001 Page 33 Internet Draft Itinerant Internet Protocol 10 January 2000 In addition, the NCR MUST follow the procedure defined in Section 10.2 to intercept packets on the mobile node's HOME link addressed to the mobile node. 10.2 Intercepting Packets for a Mobile Node While a node is serving as the NCR for the mobile node, this node MAY attempt to intercept packets. It MUST tunnel [6] all data packets that are sent to the mobile node if there are any. 10.3 Tunnelled [6] Intercepted packets to a Mobile Node For forwarding each intercepted data packet to the mobile node, the NCR MUST tunnelled [6] the packet to the mobile node using IP in IP [6] encapsulation. The tunnel entry point node is the NCR, and the tunnel exit point node is the co-located address as registered with the NCR (It is the mobile node NEW link assigned address). When a NCR encapsulates an intercepted packet for forwarding to the mobile node, the NCR SHOULD set the Source Address in the tunnel IP header to the NCR own IP address, and SHOULD set the Destination Address in the tunnel IP header to the mobile node's co-located address. When received by the mobile node (using its co-located address), normal processing of the tunnel header SHOULD result in de-capsulation and processing of the original packet by the mobile node. Chern Nam Yap Expires 10 July 2001 Page 34 Internet Draft Itinerant Internet Protocol 10 January 2000 11. Mobile Node Operation 11.1 Sending Packets While Away from Home While a mobile node is away from home, it uses its newly acquired co- located address. For packets sent by a mobile node while it is at home, no special IIP processing is required for sending this packet. If the mobile node uses any address other than its home address as the source of a packet sent while away from home (from the point of view of applications, as described above), no special Itinerant Internet Protocol processing is required for sending that packet. In each case, the packet is simply addressed and transmitted in the same way as any normal IP packet. By using the co-located address as the Source Address in the IP header, the packet SHOULD be able to safely pass through any router implementing ingress filtering [1]. 11.2 Receiving Packets While Away from Home While away from home, a mobile node SHOULD receive packets by one of two methods: - The mobile aware correspondent node SHOULD first send a Binding Request to mobile node home address, which SHOULD be intercepted and the reply with a Binding Update. Hence the correspondent node sends all its data packets to the mobile node, using its co-located address as the destination IP address of these packets. - The non-mobile aware correspondent node SHOULD send the data packets to the mobile node's home address, which SHOULD be intercepted and tunnelled [6] to the mobile node. 11.3 Movement Detection A mobile node uses Subnet Prefix Matching Switching mechanism method to detect when it has moved from one link to another. The Prefix Matching Switching mechanism (For example IIP periodically detects changes in IP address that is being assigned during communication. Once a movement is done, PPP SHOULD use IPCP [12] function to assign another new IP address, hence that is used as a hint of movement.) Chern Nam Yap Expires 10 July 2001 Page 35 Internet Draft Itinerant Internet Protocol 10 January 2000 This method is very reliable as assignment of new IP address on a new prefix means a confirmation establishment in link layer of a new IP subnet. The new assigned IP address SHOULD hence be the new co-located address. Once this is being done, the mobile node SHOULD need to immediately send Binding Updates to its BHR/TVR/NCR and correspondent node. 11.4 Sending Binding Updates to the Base Home Register After a mobile node has changed one of its addresses to a new co- located address, a mobile node MUST register this co-located address with its BHR. To do so, the mobile node SHOULD send a Binding Update packet to its BHR and the packet constructed as follows: - The Home Registration (H) bit MUST be set in the Binding Update. - The Acknowledge (A) bit MUST be set in the Binding Update. - The packet MUST contain a Home Address field that contain its home address. - The mobile MUST use the new co-located address as source to send the Binding Update. - The value specified in the Lifetime field SHOULD be less than or equal to the remaining lifetime of the co-located address specified for the binding. The Acknowledge (A) bit in the Binding Update requests from the BHR to return a Binding Acknowledgement in response to this Binding Update. As described in Section 5.2, the mobile node MUST retransmit this Binding Update to its BHR until it receives a matching Binding Acknowledgement. Once reaching a retransmission timeout period of MAX_TIMEOUT, the mobile node SHOULD continue to periodically retransmit the Binding Update at this rate until acknowledged. When sending a Binding Update to its BHR, the mobile node MUST also create or update the corresponding Binding Update List entry, as specified in Section 10.6. Chern Nam Yap Expires 10 July 2001 Page 36 Internet Draft Itinerant Internet Protocol 10 January 2000 11.5 Sending Binding Updates to the Temporary Visit Register After a mobile node has changed one of its addresses to a new co- located address, a mobile node MUST register this co-located address with its TVR. To do so, the mobile node SHOULD send a Binding Update packet to its OLD link TVR and the packet constructed as follows: - The Visit Registration (V) bit MUST be set in the Binding Update. - The Acknowledge (A) bit MUST be set in the Binding Update. - The packet MUST contain a Visit Address field that contains its visit address - The mobile MUST use the new co-located address as source to send the Binding Update. - The value specified in the Lifetime field SHOULD be less than or equal to the remaining lifetime of the co-located address specified for the binding. 11.6 Sending Binding Updates to the Near Correspondent Register After a mobile node has changed one of its addresses to a new co- located address, a mobile node MUST register this co-located address with its NCR. To do so, the mobile node SHOULD send a Binding Update packet to all its NCR and the packet constructed as follows: - The Near Registration (N) bit MUST be set in the Binding Update. - The Acknowledge (A) bit MUST be set in the Binding Update. - The packet MUST contain a Home Address field that contains its home address - The mobile MUST use the new co-located address as source to send the Binding Update. - The value specified in the Lifetime field SHOULD be less than or equal to the remaining lifetime of the co-located address specified for the binding. Chern Nam Yap Expires 10 July 2001 Page 37 Internet Draft Itinerant Internet Protocol 10 January 2000 11.7 Sending Binding Updates to Correspondent Nodes A mobile node MUST immediately send a Binding Update to all correspondent nodes that it is communicating once it has acquired a new co-located address. The Binding Update requests the correspondent node to update an entry for the mobile node in the correspondent node's Binding Cache to record this co-located address for use in sending packets to the mobile node. In this case, the value specified in the lifetime field sent in the Binding Update SHOULD be less than or equal to the remaining lifetime of the co-located specified for the binding. If, instead, the packet source address is set to the mobile node's home address, the Binding Update SHOULD request the correspondent node to delete any existing Binding Cache entry that it has for the mobile node. When sending any Binding Update, the mobile node MUST record in its Binding Update List the following fields from the Binding Update: - The IP address of the node to which the Binding Update was sent. - The home address for which the Binding Update was sent (the value in the Home Address field). - The initial lifetime of the binding, initialised from the Lifetime field sent in the Binding Update. - The remaining lifetime of the binding is also initialised from the Lifetime field sent in the Binding Update. This remaining lifetime value counts down and MAY also be reduced when the matching Binding Acknowledgement is received, based on the Lifetime value specified in that Binding Acknowledgement, as described in Section 10.8. When this remaining lifetime reaches zero, the Binding Update List entry MUST be deleted. The mobile node MUST retain in its Binding Update List information about all Binding Updates sent, for which the lifetime of the binding has not yet expired. However, when sending a Binding Update, if an entry already exists in the mobile node's Binding Update List for an earlier Binding Update sent to that same destination node, the existing Binding Update List entry SHOULD be updated to reflect the new Binding Update rather than creating a new Binding Update List entry. Chern Nam Yap Expires 10 July 2001 Page 38 Internet Draft Itinerant Internet Protocol 10 January 2000 Binding Updates that is sent to all its correspondent nodes has no requirement for acknowledgement. However, if the mobile node wants to be sure that its new co-located address has been entered into a correspondent node's Binding Cache, the mobile node MAY request an acknowledgement by setting the Acknowledge (A) bit in the Binding Update. In this case, however, the mobile node SHOULD NOT continues to retransmit the Binding Update once the retransmission timeout period has reached MAX_TIMEOUT. 11.8 Retransmit Binding Updates If, after sending a Binding Update in which the Acknowledge (A) bit is set, a mobile node fails to receive a valid, matching Binding Acknowledgement within INITIAL_TIMEOUT seconds, the mobile node SHOULD retransmit the Binding Update, until a Binding Acknowledgement is received. Such a retransmitted Binding Update MUST use a Sequence Number value greater than that used for the previous transmission of this Binding Update. The retransmissions by the mobile node MUST use an exponential back-off process, in which the timeout period is doubled upon each retransmission until either the node receives a Binding Acknowledgement or the timeout period reaches the value MAX_TIMEOUT. 11.9 Receiving Binding Acknowledgements Upon receiving a packet carrying a Binding Acknowledgement, a mobile node MUST validate the packet according to the following tests: - The packet meets the specific IPSec [2] requirements for Binding Acknowledgements, defined in Section 4.3. - The Sequence Number field matches the Sequence Number sent by the mobile node to this destination address in an outstanding Binding Update. Any Binding Acknowledgement not satisfying all of these tests MUST be silently ignored. Chern Nam Yap Expires 10 July 2001 Page 39 Internet Draft Itinerant Internet Protocol 10 January 2000 When a mobile node receives a packet carrying a valid Binding Acknowledgement, the mobile node MUST examine the Status field as follows: - If the Status field indicates that the Binding Update was accepted (the Status field is less than 128), then the mobile node MUST update the corresponding entry in its Binding Update List to indicate that the Binding Update has been acknowledged. The mobile node MUST then stop retransmits the Binding Update. In addition, if the value specified in the Lifetime field in the Binding Acknowledgement is less than the Lifetime value sent in the Binding Update being acknowledged, then the mobile node MUST subtract the difference between these two Lifetime values from the remaining lifetime for the binding as maintained in the corresponding Binding Update List entry (with a minimum value for the Binding Update List entry lifetime of 0). That is, if the Lifetime value sent in the Binding Update was , the Lifetime value received in the Binding Acknowledgement was , and the current remaining lifetime of the Binding Update List entry is , then the new value for the remaining lifetime of the Binding Update List entry SHOULD be MAX((remain - (update - ack)), 0) Where Max(X, Y) is the maximum of X and Y. The effect of this step is to correctly manage the mobile node's view of the binding's remaining lifetime (as maintained in the corresponding Binding Update List entry) so that it correctly counts down from the Lifetime value given in the Binding Acknowledgement, but with the timer countdown beginning at the time that the Binding Update was sent. - If the Status field indicates that the Binding Update was rejected (the Status field is greater than or equal to 128), then the mobile node MUST delete the corresponding Binding Update List entry (and MUST also stop retransmit the Binding Update). 11.10 Routing Multicast Packets A mobile node that is connected to its HOME link functions in the same way as any other (stationary) node. Thus, when it is at home, a mobile node functions identically to other multicast senders and receivers. This section therefore describes the behaviour of a mobile node that is not on its HOME link. Chern Nam Yap Expires 10 July 2001 Page 40 Internet Draft Itinerant Internet Protocol 10 January 2000 In order to receive packets sent to some multicast group, a mobile node MUST join that multicast group. A mobile node SHOULD join the group via a (local) multicast router on the Visit link. The mobile node SHOULD use its co-located address sharing a subnet prefix with the multicast router, as the source IP address of its multicast group membership control messages. A mobile node MAY join multicast groups via a bi-directional tunnel [6] to its BHR/TVR. The mobile node tunnels [6] its multicast group membership control packets to its BHR/TVR, and the BHR/TVR forwards multicast packets down the tunnel [6] to the mobile node. Chern Nam Yap Expires 10 July 2001 Page 41 Internet Draft Itinerant Internet Protocol 10 January 2000 12. Protocol Constants INITIAL_TIMEOUT 1 second MAX_TIMEOUT 256 seconds Chern Nam Yap Expires 10 July 2001 Page 42 Internet Draft Itinerant Internet Protocol 10 January 2000 13. IANA Considerations This document defines three new types of UDP packets, which need to have assigned a port number (Section 4.1). Moreover each of which must be assigned an Option Type value: - The Binding Update packet, described in Section 4.1; - The Binding Acknowledgement packet, described in Section 4.2; - The Binding Request packet described in Section 4.3. Chern Nam Yap Expires 10 July 2001 Page 43 Internet Draft Itinerant Internet Protocol 10 January 2000 Reference [1] Paul Ferguson and Daniel Senie. Network ingress filtering: Defeating denial of service attacks which employ IP source address spoofing. RFC 2267, January 1998. [2] Stephen Kent and Randall Atkinson. Security architecture for the Internet Protocol. RFC 2401, November 1998. [3] Scott Bradner. Key words for use in RFCs to indicate requirement levels. RFC 2119, March 1997. [4] Stephen Kent and Randall Atkinson. IP Authentication header. RFC 2402, November 1998. [5] Stephen Kent and Randall Atkinson. IP Encapsulating Security Payload (ESP). RFC 2406, November 1998. [6] Charles Perkins. IP encapsulation within IP. RFC 2003, October 1996. [7] Charles Perkins, editor. IP mobility support. RFC 2002, October 1996. [8] David C. Plummer. An Ethernet address resolution protocol: Or converting network protocol addresses to 48.bit Ethernet addresses for transmission on Ethernet hardware. RFC 826, November 1982. [9] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. [10] J. B. Postel, editor. Transmission Control Protocol. RFC 793, September 1981. [11] Thomas Narten, Erik Nordmark, and William Allen Simpson. Neighbor Discovery for IP version 6 (IPv6). RFC 2461, December 1998. [12] Glenn McGregor. The PPP Internet Protocol Control Protocol (IPCP). RFC 1332, May 1992 [13] Charles Perkins, editor. IP mobility support for IPv6. Internet Draft version 12, April 2000. [14] Stewart, editor. Stream Control Transmission Protocol. Internet Draft version 13, July 2000. Chern Nam Yap Expires 10 July 2001 Page 44 Internet Draft Itinerant Internet Protocol 10 January 2000 Comments about this document SHOULD be discussed on the seamoby@egroups.com mailing list or Authors' Addresses Questions about this document can also be directed to the authors: Chern Nam Yap Centre for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield F132 Mappin Building Mapping Street Sheffield S3 3JD Phone: +44 114 222 5182 Web: http://www.mobile1.net E-mail: cny@ieee.org ------=_NextPart_000_0130_01C07C85.B77497A0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jan 13 18:54:04 2001 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21033 for ; Sat, 13 Jan 2001 18:54:03 -0500 (EST) Received: from standards (47.234.32.16:4639) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC98A0@standards.nortelnetworks.com>; Sat, 13 Jan 2001 18:32:02 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10501 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 13 Jan 2001 18:32:01 -0500 Received: from herbert.eecs.wsu.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC989E@standards.nortelnetworks.com>; Sat, 13 Jan 2001 18:32:01 -0500 Received: from carmel.eecs.wsu.edu ([199.237.72.81]) by herbert.eecs.wsu.edu (Post.Office MTA v3.5.3 release 223 ID# 0-68625U3000L300S0V35) with ESMTP id edu for ; Sat, 13 Jan 2001 15:51:02 -0800 Received: (from dawn@localhost) by carmel.eecs.wsu.edu (8.9.3/) id PAA04379 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 13 Jan 2001 15:51:35 -0800 X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: DAWN Research Lab Message-ID: <200101132351.PAA04379@carmel.eecs.wsu.edu> Date: Sat, 13 Jan 2001 15:51:35 -0800 Reply-To: DAWN Research Lab Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: DAWN Research Lab Subject: [MOBILE-IP] Last Call: ACM MobiCom 2001 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit ******************** LAST CALL ************************************** Deadline: January 22, 2001 ********************************************************************* Enclosed below please find the Announcement and Call for Papers for the 7th Annual International Conference on Mobile Computing and Networking (MobiCom) to be held in Rome, Italy from July 16-21, 2001. As you might already know, MobiCom has an established reputation as the pre-eminent conference in this area owing to the exceptionally high quality of papers, excellent tutorials and workshops, and stimulating panels conducted by mobile computing illuminati of various stripes. For complete information about the upcoming conference, please visit: http://www.research.ibm.com/mobicom2001/ A printer friendly version of this CFP is available at: http://www.eecs.wsu.edu/~krishna/Mobicom2001-onepagecfp.pdf (PDF) http://www.eecs.wsu.edu/~krishna/Mobicom2001-onepagecfp.ps (PS) We apologize if you received multiple copies of this Call for Papers. Please feel free to distribute it to those who might be interested. Very truly yours, ACM SIGMOBILE MobiCom 2001 Organizing Committee *********************************************************************** Announcement and Call for Papers *** ACM MobiCom 2001 *** The Seventh Annual International Conference on Mobile Computing and Networking July 16-21, Rome, Italy Sponsored by ACM SIGMOBILE http://www.research.ibm.com/mobicom2001/ http://www.acm.org/sigmobile/ Submission Deadline: January 22, 2001 *********************************************************************** PAPERS: Technical papers (maximum 15 pages) describing original, previously unpublished, completed research, not currently under review by another conference or journal, are solicited on the following topics: * Applications and computing services supporting mobile users * Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity * Database and data management issues in mobile computing * Performance of mobile/wireless networks and systems * Security and privacy of mobile/wireless systems * Interaction between different layers of mobile/wireless systems * Integration and interworking of wired and wireless networks * Adaptive applications and systems for mobile environments * Distributed-system aspects of mobile systems * Operating system support for mobility * Location-dependent applications * Wireless multimedia systems * Power management * Mobile agents * Pervasive computing * Wireless sensor networks * Wireless/mobile service management and delivery All papers will be refereed by the program committee. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Baltzer Wireless Networks (WINET) and Mobile Networks and Applications (MONET) journals. Note: Student Registrations will be provided at a discounted rate. CHALLENGES SESSION, PANELS, RESEARCH DEMOS, TUTORIALS: Short papers (maximum of 8 pages) that challenge the mobile computing community with new technologies or visionary applications are solicited. Such papers should provide stimulating ideas or visions that may open up exciting avenues of mobile computing research. Proposals are solicited for panels that examine innovative, controversial, or otherwise provocative issues of interest. Proposals for tutorials are solicited. Tutorial topics that encompass the systems aspects of mobile computing and/or practical experiences in building/deploying such systems are of particular interest. Informal proposals for research demos are solicited. Proposals should include: the focus area in mobility, the technologies involved, specific equipment used, demo layout, space required, etc. Please refer to the conference website for submission and other details. (The paper submission website is READY for submissions now.) IMPORTANT DATES: * Technical Paper Submissions due: January 22, 2001 - Please refer to the website for submission instructions * Notification of acceptance: May 1, 2001 * Camera-ready version due: May 15, 2001 * Challenges Session Papers, Panel Proposals, Tutorial Proposals Submissions due: January 22, 2001 - Please refer to the website for submission instructions FOR MORE INFORMATION: Send email to mobicom2001@winlab.rutgers.edu with any questions or comments about the conference or for more information. ORGANIZING COMMITTEE: * General Chair: * Tutorials Co-Chairs: Christopher Rose Ravi Jain Rutgers University, WINLAB Telcordia Technologies * General Vice Chair: Chiara Petrioli Politecnico di Milano Sergio Palazzo Universita` di Catania * Panels Chair: * Program Co-Chairs: Ramesh Rao Univ. of California, San Diego Mahmoud Naghshineh IBM T.J. Watson Research Center * Local Arrangement Chair: Michele Zorzi Marco Listanti Universita` di Ferrara Universita` di Roma "La Sapienza" * Finance Chair: Chiara Petrioli Politecnico di Milano David B. Johnson Rice University * Registration Chair: * Exhibits/Sponsorships Chair: Irene Katzela Marco Ajmone Marsan Lucent Technologies Politecnico di Torino * Publicity Co-Chairs: * Research Demos Chair: Stefano Basagni Nigel Davies Univ. of Texas at Dallas Lancaster University Krishna Sivalingam * Steering Committee Chair: Washington State University Imrich Chlamtac Univ. of Texas at Dallas *********************************************************************** From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 15 09:37:45 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06296 for ; Mon, 15 Jan 2001 09:37:44 -0500 (EST) Received: from standards (47.234.32.16:2803) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCA2C4@standards.nortelnetworks.com>; Mon, 15 Jan 2001 9:15:29 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13854 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 15 Jan 2001 09:15:29 -0500 Received: from mgw-dax2.ext.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCA2C2@standards.nortelnetworks.com>; Mon, 15 Jan 2001 9:15:28 -0500 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0FEa6616768 for ; Mon, 15 Jan 2001 08:36:16 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 15 Jan 2001 08:34:58 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Mon, 15 Jan 2001 08:30:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Approved-By: Basavaraj.Patil@NOKIA.COM Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03189060@daeis07nok> Date: Mon, 15 Jan 2001 08:30:24 -0600 Reply-To: Basavaraj.Patil@nokia.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: [MOBILE-IP] Minutes of WG meetings at IETF49 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Mobile IP WG at IETF49 meeting minutes. Thanks to James Kempf and Scott Corson for capturing the proceedings. -------------------------------------------------------- Session 1: :::::::::: Agenda bashing - accepted. Other topics deferred to end of session 2. Charter update - streamlined, specific to MIP, other stuff offloaded to Seamoby. - fast handoff for mobile IP v4 & 6 FH MIPv4 - complete FH MIPv6 - in progress MIPv6 spec - issues pending New RFCs - Info 2977 AAA Reqs. 3012 MIPv4 CHAP, Standards track. Editors queue - 2344bis - reverse tunnelling vendor extensions Passed WG last call - route optimization (no comments) move to IESG next week regional tunnelling (issues raised) being addressed, revision forthcoming Possibly another wg last call. general NAI ext. (no comments) to IESG next week MIPv6. Security issues, new revision result of changes. IPSEC WG Other IDS - 2002bis IESG last call complete Ext rationalization - fallen off. Complete last calls last time, (AD comment?) 3G wireless extensions - WG last call, issues during IESG last call discussion, returned to IESG. HMIPv6 - going to WG doc. Talk about today. Original and INRIA proposal, concensus, no comment. Connectathon Event Testing of MIPv4, MIPv6, Diameter. Questions about including HMIPPv6 since it is not yet official. Dave Johnson - Mobicomm announcement (Rome) Charlie on MIPv6 update. reduce confusion, clarify, make sure interoperable. text included, placements for home address option and binding update option. Home address option - needs to be in front of security headers but before routing header, but means that intermediate nodes must process. IPv6 - dest options before routing and after security, but can put elsewhere. Will be after routing header but before fragement header (like to have firewalls use home address for processing). Binding update after security headers. Renumbering work, appendix on how to get home address if you don't have one to start with. Main part of draft, spec on what to do when home network renumbers, want to avoid flooding router adverts. Q. does this use ESP? Later. Eliminate renumbering, part of message flow. How to calculate AH (needing for binding update auth)? Home address option changes care of address, calculate on stream of data w. home addr in IP addr field and coa in home addr optoin. Security association is considered tied to home address. Use of ESP or AH? Draft allows AH only now. Revisit requests - return to this. Can send router solicitation to get more lifetime for home address, request from home agent. D bit - does HA have to do duplicate addr detetion? HA may or may not make sure unique. If mobile does out of blue, dup addr detection necessary. Takes longer than spec was for retransmitting BU. Initial BU retransmission longer. Details about home agent delaying router adverts when home network renumbered. minor point - preferences for HF must be zero if unspecified. Issues during last call: use ESP? - AH put into IPSEC without full enthusiasm from IPSEC, seems right for binding update. AH is mandated for use with BU and BA. If ESP is better, then why not allow? Reason for doing w. AH: it works. Politial problem in IPSEC - some IPSEC WG members want to get rid of AH. Meeting with security people, no agreement on AH v.s. ESP. Will be sent to ADs. Question: do they need to redo IKE associations if using ESP and go mobile? Hardware acceleration is easier for ESP. Changing opposition: advanced stage of last call. Using ESP in tunnel mode? No overhead. Tech problem: must auth binding update, doesn't contain HA or CoA. ESP only protects part below header, AH protects whole packet. CoA is above ESP, so would not be protected. Overhead of adding CoA lower down is too much, too many ways to encode. ESP is slightly larger than AH, but to add CoA lower down would require 16 bytes for address, 2 bytes for identification, another 6 bytes for padding. 2 kinds of overhead, per packet, overhead of additional SA, need to be discusssed. SA overhead only once, when you go mobile. Process issue: consistent doc not there, will get comments from IESG. Last night: send to AD with preface pointing to issues. Trying to complete. IETF last call once. Code running is for draft 13. But not in draft. Only two implementors know how to do it. Code is not in draft. Nonagreement - whether it should be specified in draft. What's in the draft- result of last interop test. What is the prob getting doc only using AH, details yet to be resolved. Separate draft about how to use ESP. With more implementation experience, then revise. ESP has momentum. ETSI bakeoff, didn't have AH, one implementation does not use AH. BA, protected by AH, can't protect unless in tunnel mode because can't protect routing header. Using AH makes simple to protect routing header. AH v.s ESP discussion ended. How does key negotiantion between CH and MN occur. SA is associated wi. HA not CoA. Security DB selectors is difficult problem, select from database for doing auth, not this level of granularity in IKE. binding update one SA, ack another. How does BU security scale? Security ADs lead that it is broken. But logic says that IPv6 security is therefore broken. Operational issue. Not a routing area issue. Solution: do triangle routing. Intractable problem: global PKI, narrow slices. What is MIP issue is how many SAs need to be created. Many keys, could have an SA that does both BU and normal traffic. Proactive FAs FH design team - reduce number proposals to one two proposals, combined three into one of two email to only use messages from binding family authors felt that needs bidirectional support. need both oFA and nFA to initialte. Source and target triggers. Source: oFA sends msg to nFA, Target: nFA sends msg to oFA. Bicasting - once handoff message, new packets sent across both, no L2 - drop packets. Address power consumption - dormant mode, don't require mobile to awake. Draft doesn't require. generalized link layer address - include hardware address to map link layer to mobile. Also supports regional registration. mobile moves to new FA, message handoffs occur, nFA knows a GFA involved, regional reg done by GFA. Was design team to come up with solution or combine drafts? v4 - consolidate drafts where possible, one draft going forward. Not all possible scenarios. v6 - more comprehensive. Result not to rubber stamp. Security to prevent hijacking of messages, why transfer? Assume trust relationship. FAs have security association, includes FA/FA auth extension, can prove. Only proves who I am, not that it's authed. Some access networks in which assumption is not valid. Possible to solve fast handoff with 802.11? Hasn't looked at those access networks. IAPP only in one subnet. How to you handle packet loss? Is L2 authenticated? Hesham: mobile does movement detection. uses standard 2002. support both mobile network, mobile most be able to decide whether it can register or not. support ping-pong. No knowledge of timing. independent of L2. support local mobility, with GFA, etc. Anticipate if L2 allows you to do so. Simultaneous binding, S bit to two locations to support ping pong. Relay to mobile node, mobile node runs movement detection, registers right away w. SA2, mobile node moves to FA2, traffic is already there. Not necessarily two streams because L2 may drop. Need to decouple from L2. Don't have to base on regional. Final particular case, GFA as first hop, bicasting to to both places, but sent to where out. Comparisons: FH draft requires L2 messaging over the air before complete. Need to have an advert multihop solicatation, mobile node must come on traffic channel, no access to signalling channel, send reg request, reply back before handoff can take place, indicate to network that complete. Radio environment may deteriorate during handoff on old link. Provisioning neighbors. Associate link layer triggers w. FA both, FH also requires advert FH relies on GFA to redirect traffic. Who is in control? FH mobile has control, L2 controls today, mobile has final say. Karim. Mobile can do movement detection. One approach, do registration after, not clear. Don't need to adverise. Intersystem handoff, no new messages in FH. Forced by network to do handoff where you don't want to go, network hands you off, data sent to wrong FA, no sim bindings, clear problem. Much discussion about L3 v.s. L2 handoff. L3 signalling appropriate for multiple L3 handover, shouldn't rule out L3 smarts. Bicasting, base stations can't tell if mobile is dormant or talking to another base station. Discard rather than buffer on L2. Put drafts together, assumptions on link layer, similar kinds of network. Several types of scenarios. Can you start with something and cover all cases? Come up with a generic solution? Not for one link layer. IAPP traffic for monitoring on 802.11. What is the best handoff? Merge two drafts? Hum says merge. IPv6 fast handoff. Design goals - be flexible, one size does not fit all. Focus on Break before Make - most clear cut case. Mobile initiated/network initiated. L2 features when available, but also when not there Robust, fall back. Other MIP features - bicasting, buffering, context transfer, localized mm Advance prepartion of the handoff. Use MIPv6 messages where possible. Scenarios: 1) Mobile nod initates handoff at new access router 2) New access router initiates handoff when mobile connects... 2 others initiate handoff at old, prepare hanoff btween ARs, complete handoff at new details not done. Network initiated. Data coming to old AR, trigger, tells you that handoff needs to take place. Proxy Router advert send to MN, allows mobile to create new CoA before gets to new AR, mobile may need to send a BU. Old AR sends handoff iniitate to new, acked by new Mobile connects to new, handoff update, new starts forwarding to mobile. Later mobile sends BU to home agent, etc. Will mobile get a binding ack? Could come on old link or new, if old is deteriorated. Mobile initiated. Mobile requests special router solicitation for new one. after that, same as previous. Layer 2 assist. Layer 2 trigger at old causes binding update to new AR. HAck returned. CoA is actually old CoA, mobile can't create new CoA, old is valid at new AR for awhile, gets new. Some variations. Plans. High level done, devil is in details. New draft with solution section to be published by end of year Regular drafts published as details get resolved. Conference calls, face to face in January. Finsh by Minneapolis. Include more scenarios? Merge of INRIA and HMIP motivation: reduce MIP signalling, reduce signalling delay one or more anchor points in hierarchy LCOA on link, MAP CoA MN binds LCOA w. MAP, Packets intercepted by MAP nd encapsulated to MN. HMIPv6 does not require new security assoc modify MIPv6 no new protocols no special routers prevent a mn from using both modes. 2 modes: 1) basic, one MAP-COA per MN 2) MAP-COA belongs to the MAP subnet 3) Map intercepts packets to MN's COA extended: MAP0COA is the MAP address Map receives packets and forwards to LCOA Less encapsulation overhead when RO is used MAP is slightly different from a HA Ch7 has a comparison why might need either MAP discovery: Dynaimc map discovery (should be secured) Router renumbering extension map optoin in a destiantion option sent to the ARs (from the MAP or another node). Implementaiton. INRIA has a KAME and FDupont implement. 300 lines Two implementations interop test in Connectathon. Need an IPR statement at end. can mobile node use MAP on link, eq. foreign agent. Modifying router adverts? Adding an option. No new protocol? Modifying MIP protocol, didn't modify binding update. Only supports one layer of hierarchy. More than one layer of hierarchy, will select more than one MAP, mobile needs to know which MAP to send to. MAP sends packets to mobile node, encapsulate. Restictions on MAP location in topology? HA only works because is on same link, MAP sends option with prefix, home agent may not need. Not subnet that mobile is visiting, necessarily. Two BUs to MAP and to HA. What about only one? Why not just fast handoff? Doesn't reduce amount of signalling. Would need to update BUs to all CNs. Map needs to know LCOA. difference w. fast handoff - design team's fast handoff, update previous access router, could also be elsewhere. No provision for MAP to MAP, standard MIPv6 smooth handoff. Flexibility of not having FA on first hop, not forced to have hop by hop hierarchy. v4 allos coloc coa. most usual case on subnet. -------------------------------------------------------- Session 2: :::::::::: A Framework for QoS Support in Mobile IPv6, Hemant Chaskar, Nokia MIPv6 does not yet address QoS. This is a proposal to perform QoS signalling in MIP by introducing a QoS object as an IPv6 extension header, where the object corresponds to one unidirectional packet stream. Object should describe required packet volume, and is included as a hop-by-hop option. Different approaches to handling MPLS, DiffServ and IntServ are included. Comments from floor that this is (or will be) reinvention of RSVP. Object would be sent end to end in BU from MN to HA and CN. IPv6 Regional Registrations, Charlie Perkins, Nokia Mentioned solutions to RR problems discussed in Pittsburgh. The idea is to reduce signaling to the HA and CNs. The new approach uses an anycast group as the destination of a BU. This was challenged as not being defined in IPsec. The approach uses hierarchical anycast to localize signalling, and can be viewed as a distributed, more robust structure. But unfortunately this approach nails down the data path (like loose source routing) due to security requirement of BUs, and thus does not have the robust properties that it might have otherwise. Mobile IPv6 ETSI Bakeoff, Vijay Devarapalli, Nokia Report was given on what occurred. Mobile Network Support in IPv6, INRIA, Thierry Ernst Presented an approach for supporting mobile sub-network(s). Mentioned that with MIPv6 there is no way to send a packet to a mobile on a mobile sub-network. One solution is to send network scope binding updates. Sender of BU must be the mobile router, and must authenticate the BU as it manages the mobility of the subnet. The solution raises an issue of authorization, can the mobile router do this? Does HMIPv6 solve this and is it a better solution? It depends if MNs are mobile aware ...take to the mailing list. Limited Private Address Support, Samita Chakrabarti, Sun Private addresses are limited to mobile nodes only. Mobile must obtain a reverse tunnel with registration. A MN must have a unique home address in its home domain. Paging Extension to Hierarchical Mobile IPv6, Regional Paging MIP is bowing out of paging work for now according to chair in deference to ongoing work in SeaMoby. OUT OF SCOPE! Registration Revocation in Mobile IP, Steven Glass, Sun Original MIPv4 thought was that short lifetimes would be sufficient, and denial of service holes would be present otherwise. AAA has a requirement that a registration be revoked immediately. Termination messages must be authenticated. An easy solution? Perhaps not, as the revoke beacon can be spoofed. Pitfalls...comments from Dave J. are that the DoS hole should be closed. Pat mentioned that we should do this with MIP signalling and not ICMP signalling. Should the hole in 2002bis be documented in a separate draft? DHCP in Mobile IP, Glass, Sun Requires changes to HA only and not MN, FA or DHCP. MIP Extension proposed to carry full DHCP Ack. Using one home address to renew/get another requires turning the HA into a DHCP relay. Unclear as to whether/when this will become a WG draft. Homeless MIPv6, Bengi Shalin, Ericsson Bind sockets to dynamic address sets, not to single addresses. Update address sets via MIPv6 BUs. Home addresses are not needed, hence the name. Home agents may still be used as points of contact, if wanted. Relies on DDNS, SIP etc. to be reachable (server-mode). Intercepting Location Updates, Glenn Morrow, Nortel Goals include simultaneous location privacy and route optimization. Allow a more realistic deployment of route optimization in IPv4. CoA hidden from CN by Network in new proposal. Brings the redirection function from the CNs to the last hop routers in the form of Correspondent Agents (CA). Makes use of Router Alert bit in IPv4. HMIP-type support is also possible. A router can be configured to ignore a router alert or not, and this may be fast or slow path, or not. The required SAs between routers are typically already in place. 0-byte overhead tunnels (double NAT end to end) are also proposed. What happens if a wrong address occurs (memory error), there is no recovery option according to Dave Johnson based on past WG examination, and who claims the proposed approach has been previously discussed by the WG and rejected as not workable. SGM Support in Mobile IP, Jiwoong Lee, Korea Telecom SGM (implicit multicast) aims to help solve scalability of mobile IP multicast. Uses a level 3.5 header to enumerate the unicast destination address of all mobile nodes. IM packets can be sent from HA to FA COA or to MN CCOA. Assumes FA is not a mcast router. If native mcast is available, this is really not required as was pointed out by Alan. Introducing Mobile IP in IPv4/IPv6 Interconnected Networks, Tsao, Siemens Aims to solve problem of roaming between IPv4/IPv6 networks, homogeneous and heterogeneous cases. The basic approach suggests no new protocol, but requires translation which is generally to be avoided if possible. NGtrans is considering this issue as well, and George commented that NAT should be used as an option of last resort. Diameter Extensions to MIP, Charlie Perkins, Nokia Gave an update of changes to the draft, including allowing a home agent to be allocated in a foreign domain. Mobile IP and GRE Enhancements, Pat Calhoun, Sun GRE supports a key field used as a session ID and is multi-protocol. I-D defines two new MIP extensions, GRE key extension and the GRE type extension, to enable GRE protocol type pre-negotiation on registration prior to data exchange. GSM SIM Authentication and Key Exchange for Mobile IP, Havinen, Nokia Useful to bootstrap MIP/AAA infrastructure off of existing GSMSIM cellular infrastructure. See draft if interested. SA Establishment for Route Optimization in MIPv6, Hesham, Ericsson MIPv6 mandates secured BUs. This requires key exchange. What, how, when? IKE may be too heavy? Proposal is not as secure as IKE, not intended to replace IKE. Involves one RTT from MN to CN. Only works if CN has a AAA server. There is an IPR statement on this from Ericsson. Number of messages over the air is 4 or 6, but still less than IKE in aggressive mode. MIP WG Wrap up from Phil MIPv4 handoff consolidation will begin. MIPv6 handoff continues. blah... ---------------------------------------------------------------------------- --------------------------- -Basavaraj -Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jan 15 19:45:50 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18182 for ; Mon, 15 Jan 2001 19:45:50 -0500 (EST) Received: from standards (47.234.32.16:1104) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCA8D8@standards.nortelnetworks.com>; Mon, 15 Jan 2001 19:24:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15891 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 15 Jan 2001 19:24:10 -0500 Received: from ms.hansol.co.kr (210.112.2.207:2239) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCA8D6@standards.nortelnetworks.com>; Mon, 15 Jan 2001 19:24:09 -0500 Received: from ns ([211.113.87.7]) by ms.hansol.co.kr (8.9.3/8.9.3) with SMTP id JAA10652; Tue, 16 Jan 2001 09:40:58 +0900 References: <7B5C0390ACE7D211BC9C0008C7EABA2B03189060@daeis07nok> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Approved-By: "Lee, Jiwoong" Message-ID: <001901c07f55$790089c0$d012060a@hansol.co.kr> Date: Tue, 16 Jan 2001 09:43:48 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: Re: [MOBILE-IP] Minutes of WG meetings at IETF49 X-To: Basavaraj.Patil@nokia.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit From: "Basavaraj Patil" To: Sent: Monday, January 15, 2001 11:30 PM Subject: [MOBILE-IP] Minutes of WG meetings at IETF49 > SGM Support in Mobile IP, Jiwoong Lee, Korea Telecom > > SGM (implicit multicast) aims to help solve scalability of mobile IP > multicast. Uses a level 3.5 header to enumerate the unicast destination > address of all mobile nodes. IM packets can be sent from HA to FA COA or > to MN CCOA. Assumes FA is not a mcast router. If native mcast is > available, this is really not required as was pointed out by Alan. Thank you for a comment. Could anybody please technically explain the last sentence: "If native mcast is available, this is really not required as was pointed out by Alan" for accurate understanding ? I'll admit it in a humble mind and reflect over the problem again. Thank you, Jiwoong Korea Telecom M.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 16 03:08:36 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06996 for ; Tue, 16 Jan 2001 03:08:36 -0500 (EST) Received: from standards (47.234.32.16:3646) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCACB1@standards.nortelnetworks.com>; Tue, 16 Jan 2001 2:46:49 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17199 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 16 Jan 2001 02:46:49 -0500 Received: from mr.tuwien.ac.at by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCACAF@standards.nortelnetworks.com>; Tue, 16 Jan 2001 2:46:48 -0500 Received: from pop.tuwien.ac.at (phaeton.ikn.tuwien.ac.at [128.131.88.62]) by mr.tuwien.ac.at (8.11.1/8.11.1) with ESMTP id f0G86TC13756 for ; Tue, 16 Jan 2001 09:06:29 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <3A6409D9.B0A18428@pop.tuwien.ac.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Nam Hoang Nguyen Message-ID: <3A640A1E.AA9DD9F7@pop.tuwien.ac.at> Date: Tue, 16 Jan 2001 09:45:18 +0100 Reply-To: Hoang.Nguyen-Nam@tuwien.ac.at Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Nam Hoang Nguyen Subject: [MOBILE-IP] Message flows for mobile IP handoff ?? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi ! Could any body tell me where I can get more information about message flows for seamless mobile IP handoff ??? I tried to look for but I donot find appropriate documents. Many thanks in advance Nam From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 17 18:42:04 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28706 for ; Wed, 17 Jan 2001 18:42:04 -0500 (EST) Received: from standards (47.234.32.16:3016) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCD07A@standards.nortelnetworks.com>; Wed, 17 Jan 2001 18:20:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21813 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 17 Jan 2001 18:20:02 -0500 Received: from boreas.isi.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCD078@standards.nortelnetworks.com>; Wed, 17 Jan 2001 18:20:01 -0500 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id PAA11222; Wed, 17 Jan 2001 15:39:45 -0800 (PST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Message-ID: <200101172339.PAA11222@boreas.isi.edu> Date: Wed, 17 Jan 2001 15:39:45 -0800 Reply-To: RFC Editor Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: RFC Editor Subject: [MOBILE-IP] RFC 3024 on Reverse Tunneling for Mobile IP, revised To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3024 Title: Reverse Tunneling for Mobile IP, revised Author(s): G. Montenegro, Editor Status: Standards Track Date: January 2001 Mailbox: gab@sun.com Pages: 30 Characters: 63929 Obsoletes: 2344 I-D Tag: draft-ietf-mobileip-rfc2344-bis-03.txt URL: ftp://ftp.isi.edu/in-notes/rfc3024.txt Mobile Internet Protocol (IP) uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign network, and assumes that routing is independent of source address. When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent. This document proposes backwards-compatible extensions to Mobile IP to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. This document obsoletes RFC 2344. This document is a product of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010117153709.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3024 --OtherAccess Content-Type: Message/External-body; name="rfc3024.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010117153709.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 18 03:17:52 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20944 for ; Thu, 18 Jan 2001 03:17:51 -0500 (EST) Received: from standards (47.234.32.16:2788) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCD2BF@standards.nortelnetworks.com>; Thu, 18 Jan 2001 2:56:46 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22571 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 18 Jan 2001 02:56:46 -0500 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCD2BD@standards.nortelnetworks.com>; Thu, 18 Jan 2001 2:56:46 -0500 Received: from lt.eth.ericsson.se (lt.eth.ericsson.se [164.48.158.205]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f0I8GXC03714 for ; Thu, 18 Jan 2001 09:16:33 +0100 (MET) Received: from lt.eth.ericsson.se by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA15175; Thu, 18 Jan 2001 09:16:31 +0100 (MET) X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Approved-By: Andras Valko Message-ID: <3A66A6D8.EF61E7A5@lt.eth.ericsson.se> Date: Thu, 18 Jan 2001 09:18:32 +0100 Reply-To: Andras Valko Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Andras Valko Subject: [MOBILE-IP] CFP : RSRCP Journal - Mobility and Internet To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit [Apologies if you receive multiple copies.] CALL for PAPERS SPECIAL ISSUE MOBILITY AND INTERNET of RSRCP Journal http://www-r2.u-strasbg.fr/rsrcp/mintcfp.html The RSRCP journal, which is now specialized on thematic issues on Network and Distributed System is pleased to announce a special issue on "Mobility and Internet". This special issue is sponsored by IEEE Distributed Systems and the French IEEE Computer Chapter. Wireless mobile access to the Internet will add new dimensions to the way we access information and communicate. Currently, several network protocols are being studied to maintain communication between a mobile host and its correspondents during the mobile host's movements. This special issue is devoted to the presentation of recent research on network protocols and services for mobile hosts and wireless communication on the Internet. We solicit high quality papers reporting original work in theoretical or experimental research. Topics of interest include, but are not limited to the following : - Ad hoc networks - Cellular IP networks - Distributed system aspects of mobile systems - Handoffs in IP networks - Header compression in wireless networks - Hierarchical mobility - IP-based third generation mobile and wireless networks - Micro-mobility architectures and protocols - Multicast communications for mobile hosts - Mobility and IPv6 - Mobile management - Network protocols for mobile nodes - QoS in a wireless/mobile environment - Security and authentication - Service location in wireless environnement - Wireless LAN Important dates: 1. Submission deadline: June 30, 2001; 2. Notifications to the authors: September, 30, 2001; 3. Publication : December 2001; Submissions: Contributions should follow the instructions and the format of the journal edited by Hermes. (see http://www-r2.u-strasbg.fr/rsrcp/authorsguidelines.pdf) Contributions should be original ones and should not be longer than 25 pages. Submissions should be forwarded to the Guest Editors (rsrcp@clarinet.u-strasbg.fr - PS or PDF format, compressed). Guest Editors : Thomas Noel Andras Valko Universite Louis Pasteur - LSIIT Ericsson Research Pole API - Boulevard Sébastien Brant Traffic Laboratory F- 67400 - Illkirch H-1037 Budapest, Laborc u 1. France Hungary Editorial Board : Scott Corson Francis Dupont Flarion Technologies ENST - Bretagne USA France Philip Eardley Andras Farago British Telecom University of Texas - Dallas UK USA Phil Neumiller Thomas Noel 3Com LSIIT USA France Hesham Soliman Tapio Suihko Ericsson VTT Technical Research Center Australia Finland C.K. Toh Michel Trehel Georgia Institute of Technology Universite de Franche-Comte USA France Andras Valko Ericsson Research Hungary -- Andras G. Valko, Ph.D. Ericsson Research tel: +36 1 4377774 fax: +36 1 4377219 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 18 07:08:10 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22276 for ; Thu, 18 Jan 2001 07:08:09 -0500 (EST) Received: from standards (47.234.32.16:3771) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCD41E@standards.nortelnetworks.com>; Thu, 18 Jan 2001 6:46:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23027 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 18 Jan 2001 06:46:18 -0500 Received: from correio.inescn.pt by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCD41C@standards.nortelnetworks.com>; Thu, 18 Jan 2001 6:46:16 -0500 Received: from bluenose.inescn.pt (bluenose.inescn.pt [194.117.24.35]) by correio.inescn.pt (8.9.1/8.9.1/13) with ESMTP id MAA19235 for ; Thu, 18 Jan 2001 12:04:31 GMT Received: from zeus (zeus.inescn.pt [194.117.24.46]) by bluenose.inescn.pt (8.9.3+Sun/8.9.1) with SMTP id LAA02667 for ; Thu, 18 Jan 2001 11:55:03 -0100 (GMT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C4_01C08146.80013330" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Approved-By: Jaime Dias Message-ID: <00c701c08146$804911a0$2e1875c2@zeus> Date: Thu, 18 Jan 2001 12:02:16 -0000 Reply-To: Jaime Dias Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jaime Dias Subject: [MOBILE-IP] all IP on 3gpp To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_00C4_01C08146.80013330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi! I'm studying scenarios for the ALL IP in an UMTS environment.=20 I've already see some approach with Cellular IPv6 and/or MIPv6, but = that's where the confusion begin:=20 Some approach byu 3G.IP refers about an MIP to the RNC. Until now the IP between the UE and the RNC are tunnelled, so, where = the Cellular IP take place? In respect of the advantages of an IPv6 ALL IP, "I think" that it don't = rest many doubts: Mobility as an inherent feature Route optimisation MIPv6 includes features to minimize loss in-flight packets during = handover No foreign agents need to be deployed. Address space. QoS Security So, can anybody tell me why the 3GPP2 are so reluctant about the IPv6? I would be very thankful. Jaime Dias __________________________________________ Jaime Sousa Dias INESC Porto=20 fone.: +351 22 2094258 fax:+351 22 2084172 Telecom & Multimedia Unit=20 Porto, Portugal=20 http://www.inescporto.pt/ http://telecom.inescn.pt __________________________________________ ------=_NextPart_000_00C4_01C08146.80013330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi!
 
I'm studying scenarios = for the ALL=20 IP in an UMTS environment. 
I've already see some approach with = Cellular IPv6=20 and/or MIPv6, but that's where the = confusion=20 begin:
    Some approach byu = 3G.IP refers=20 about an MIP to the RNC.
    Until now the IP = between the UE=20 and the RNC are tunnelled, so, where the Cellular = IP take=20 place?
 
In respect of the advantages of an = IPv6 ALL IP, "I=20 think" that it don't rest many doubts:
    Mobility as an = inherent=20 feature
    Route = optimisation
    MIPv6 includes = features to=20 minimize loss in-flight packets during handover
        = No foreign=20 agents need to be deployed.
    Address = space.
    QoS
    = Security
 
So, can anybody tell me why the = 3GPP2 are so=20 reluctant about the IPv6?
 
I would be very thankful.
 
Jaime Dias
__________________________________________
Jaime Sousa = Dias
INESC=20 Porto
fone.: +351 22 2094258
fax:+351 22=20 2084172
Telecom & Multimedia Unit =
Porto, Portugal=20
http://www.inescporto.pt/  = http://telecom.inescn.pt
_______= ___________________________________
------=_NextPart_000_00C4_01C08146.80013330-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jan 18 21:13:25 2001 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08174 for ; Thu, 18 Jan 2001 21:13:23 -0500 (EST) Received: from standards (47.234.32.16:1274) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCD9E7@standards.nortelnetworks.com>; Thu, 18 Jan 2001 20:51:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20829 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 18 Jan 2001 20:51:30 -0500 Received: from stsl.siemens.com.tw (192.72.45.189:55605) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCD9E5@standards.nortelnetworks.com>; Thu, 18 Jan 2001 20:51:26 -0500 Received: from stslex.siemens.com.tw (stslex [192.72.45.13]) by stsl.siemens.com.tw (8.9.1/8.9.1) with ESMTP id KAA12874; Fri, 19 Jan 2001 10:20:32 +0800 (CST) Received: by stslex.siemens.com.tw with Internet Mail Service (5.5.2448.0) id ; Fri, 19 Jan 2001 10:12:43 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C081BD.4E1BDDA8" Approved-By: Moter Du Message-ID: <92C0C0AC8AE8D411864300105A835CBB501430@stslex.siemens.com.tw> Date: Fri, 19 Jan 2001 10:12:41 +0800 Reply-To: Moter Du Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Moter Du Subject: [MOBILE-IP] Returning Home, unicast Neighbor Solicitation X-cc: "MWIP@icn.siemens.de" 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_01C081BD.4E1BDDA8 Content-Type: text/plain; charset="BIG5" In the MIPv6 specification, Chapter 10.20, it descibes a mobile node can use a special Neighbor Solicitation to learn the link-layer address of home agent. The destination address of the Neighbor Solicitation is home agent's unicast address, and the source address is unspecified. The unicast Neighbor Solicitation is used for address resolution in this case, and turns it to a chicken-egg problem. The problem is, how could a mobile node send the "unicast" Neighbor Solicitation if it didn't know destination MAC address? As far as I know currently all implementation either does not do it, or uses solicited multicast Neighbor Solicitation (the normal way) for this case. Sincerely Moter Du ============================================================ Moter Du D410, Siemens STSL phone +886 2 25186011 Fax +886 2 25053866 mailto:moter_du@stsl.siemens.com.tw ============================================================ ------_=_NextPart_001_01C081BD.4E1BDDA8 Content-Type: text/html; charset="BIG5" Content-Transfer-Encoding: quoted-printable Returning Home, unicast Neighbor Solicitation

In the MIPv6 specification, Chapter 10.20, it = descibes a mobile node can use a special Neighbor Solicitation to learn = the link-layer address of home agent.  The destination address of = the Neighbor Solicitation is home agent's unicast address, and the = source address is unspecified.

The unicast Neighbor Solicitation is used for address = resolution in this case, and turns it to a chicken-egg problem.  = The problem is, how could a mobile node send the "unicast" = Neighbor Solicitation if it didn't know destination MAC address?  = As far as I know currently all implementation either does not do it, or = uses solicited multicast Neighbor Solicitation (the normal way) for = this case.


        Sincerely =
        Moter = Du
 
        = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
        Moter = Du           &nbs= p;           &nbs= p;          D410, Siemens = STSL
        = phone   +886 2 25186011
        = Fax     +886 2 25053866
        mailto:moter_du@stsl.siemen= s.com.tw
        =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------_=_NextPart_001_01C081BD.4E1BDDA8-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 19 06:28:17 2001 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27267 for ; Fri, 19 Jan 2001 06:28:16 -0500 (EST) Received: from standards (47.234.32.16:1731) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCDCEA@standards.nortelnetworks.com>; Fri, 19 Jan 2001 6:06:28 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21844 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 19 Jan 2001 06:06:28 -0500 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCDCE8@standards.nortelnetworks.com>; Fri, 19 Jan 2001 6:06:27 -0500 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f0JBQ3k47474; Fri, 19 Jan 2001 12:26:03 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA06021; Fri, 19 Jan 2001 12:26:03 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f0JBQ1O11496; Fri, 19 Jan 2001 12:26:02 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Approved-By: Francis.Dupont@ENST-BRETAGNE.FR Message-ID: <200101191126.f0JBQ1O11496@givry.rennes.enst-bretagne.fr> Date: Fri, 19 Jan 2001 12:26:01 +0100 Reply-To: Francis Dupont Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] Returning Home, unicast Neighbor Solicitation X-To: Moter Du To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Fri, 19 Jan 2001 10:12:41 +0800. <92C0C0AC8AE8D411864300105A835CBB501430@stslex.siemens.com.tw> In your previous mail you wrote: In the MIPv6 specification, Chapter 10.20, it descibes a mobile node can use a special Neighbor Solicitation to learn the link-layer address of home agent. The destination address of the Neighbor Solicitation is home agent's unicast address, and the source address is unspecified. => this is already known to be incorrect. I think the next version of the draft will come back to the previous text without a MUST because to perform a DAD for the home agent address is a "last chance" solution. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 19 11:11:38 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01253 for ; Fri, 19 Jan 2001 11:11:35 -0500 (EST) Received: from standards (47.234.32.16:3432) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCDDFE@standards.nortelnetworks.com>; Fri, 19 Jan 2001 10:49:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22199 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 19 Jan 2001 10:49:31 -0500 Received: from mgw-dax1.ext.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCDDFC@standards.nortelnetworks.com>; Fri, 19 Jan 2001 10:49:30 -0500 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0JG9OR14608 for ; Fri, 19 Jan 2001 10:09:24 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 19 Jan 2001 10:09:21 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 19 Jan 2001 10:09:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Approved-By: Basavaraj.Patil@NOKIA.COM Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B032132EB@daeis07nok> Date: Fri, 19 Jan 2001 10:04:52 -0600 Reply-To: Basavaraj.Patil@nokia.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: [MOBILE-IP] BURP BOF To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM A BOF on Basic User Registration Protocol (BURP) Charter: The vision of pervasive computing also includes constantly being connected and the ability to access the Internet or the enterprise over the Internet. Mobile computing solutions based on protocols such as Mobile IP offer seamless and continuous connectivity for users. However a lot of roadwarriors and other types of users access the network from places like airports, hotels, malls and sports complexes. These environments may offer access to the network over wireless LANs or via Ethernet LAN ports or other mediums. In such scenarios, DHCP can provide configuration information (e.g., giving a valid address etc.), but there is no standard way for service providers to obtain user information to perform AAA functions. For users who do not have Mobile IP clients on their devices but would like to access the network, they need to register and be authenticated by the local network service provider before being authorized to use the resources. The intent of this proposal is to develop an application layer registration protocol that allows a user to register in the local network by providing identity and authentication information to the local network which then uses a AAA infrastructure to validate the user, charge him and, authorize use of resources. We would like to request a BOF on a "Basic User Registration Protocol (BURP)" for the March 2001 meeting of the IETF in Minneapolis. The objective of the BOF will be to -- Detail the scope of the proposal and applicable scenarios -- Chart a course and an action plan (including milestones and deliverables) for BURP. -- Investigate the impact on existing AAA protocols and make it flexible to support various authentication schemes. The goal will be to define a standard UNI for environments in which neither PPP nor Mobile IP is required but AAA interaction is essential. The basic principle will include: -- The solution being a client-server application layer protocol -- Is applicable to both IPv4 and IPv6. -- User interacts only with a local Registration Agent (RA), which may reside on any node in the Network Domain. -- It should work with any configuration protocol, such as DHCP, IPv6 stateless autoconfiguration, and manual configuration. -- Protects RA from replay attacks. -- Provide information on and control of network usage. -- Interacts with routers/policers to limit packets forwarding based on a user's Service Level Specification (may be optional or may interwork with standard policy protocols). -- Defines an RA-to-AAA interface ----------------------------------------------------------------------- To subscribe to the mailing list for discussion on this topic, please follow these instructions: To subscribe, send mail to urp-request@research.telcordia.com, and use "subscribe" for the subject line. To unsubscribe, send mail to urp-request@research.telcordia.com, and use "unsubscribe" for the subject line. To contribute to the list, send mail to urp@research.telcordia.com. For additional help, send mail to urp-request@research.telcordia.com and use "help" for the subject line. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 19 12:30:17 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02964 for ; Fri, 19 Jan 2001 12:30:15 -0500 (EST) Received: from standards (47.234.32.16:3441) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCDEC3@standards.nortelnetworks.com>; Fri, 19 Jan 2001 12:08:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22458 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 19 Jan 2001 12:08:24 -0500 Received: from auemail2.firewall.lucent.com (auemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCDEC1@standards.nortelnetworks.com>; Fri, 19 Jan 2001 12:08:24 -0500 Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA27730 for ; Fri, 19 Jan 2001 12:28:15 -0500 (EST) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA27716 for ; Fri, 19 Jan 2001 12:28:15 -0500 (EST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 19 Jan 2001 11:28:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Dolan, Michael F (Mike)" Message-ID: Date: Fri, 19 Jan 2001 11:28:13 -0600 Reply-To: "Dolan, Michael F (Mike)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Dolan, Michael F (Mike)" Subject: Re: [MOBILE-IP] all IP on 3gpp X-To: Jaime Dias To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Jaime, Hi! I am the vice-chair of the 3GPP2 All-IP Group. Please be assured that 3GPP2 certainly intends to support IPv6. That decision is already written into our adopted Requirements document. Mobile IP and specifically Mobile IPv6 have been at the core of many discussions for the last year or more, and are a basic tenet in our ongoing work. 3GPP2 already has IPv4 (and Mobile IPv4) built into its standards. Members of 3GPP2 TSG-P (Tom Hiller, Pat Calhoun, Pete McCann, Mark Lipford, and others) have been working closely with the Mobile IP WG for some time now to add needed extensions to Mobile IPv4 to support wireless environments. Since Mobile IPv4 is already a foundation block of 3GPP2 systems, 3GPP2 cannot abandon IPv4. Instead, an evolutionary path that moves 3GPP2 systems as quickly as possible to IPv6 is a hot work item. Your list of issues is a good one. It matches many similar lists held by others. I suggest that if you (or others) wish to continue this discussion, please contact me directly. That will help keep this email list for more technical topics. Thanks for your question. Have a good day, Mike Dolan 3GPP2 All-IP Vice-Chair Lucent Technologies mfdolan@lucent.com PH +1.630.979.1033 Mob +1.630.697.3549 -----Original Message----- From: Jaime Dias [mailto:jdias@inescporto.pt] Sent: Thursday, January 18, 2001 6:02 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] all IP on 3gpp Hi! I'm studying scenarios for the ALL IP in an UMTS environment. I've already see some approach with Cellular IPv6 and/or MIPv6, but that's where the confusion begin: Some approach byu 3G.IP refers about an MIP to the RNC. Until now the IP between the UE and the RNC are tunnelled, so, where the Cellular IP take place? In respect of the advantages of an IPv6 ALL IP, "I think" that it don't rest many doubts: Mobility as an inherent feature Route optimisation MIPv6 includes features to minimize loss in-flight packets during handover No foreign agents need to be deployed. Address space. QoS Security So, can anybody tell me why the 3GPP2 are so reluctant about the IPv6? I would be very thankful. Jaime Dias __________________________________________ Jaime Sousa Dias INESC Porto fone.: +351 22 2094258 fax:+351 22 2084172 Telecom & Multimedia Unit Porto, Portugal http://www.inescporto.pt/ http://telecom.inescn.pt __________________________________________ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 19 13:06:46 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03566 for ; Fri, 19 Jan 2001 13:06:45 -0500 (EST) Received: from standards (47.234.32.16:3441) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCDF87@standards.nortelnetworks.com>; Fri, 19 Jan 2001 12:44:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22715 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 19 Jan 2001 12:44:50 -0500 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCDF85@standards.nortelnetworks.com>; Fri, 19 Jan 2001 12:44:49 -0500 Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0JI4fC06494 for ; Fri, 19 Jan 2001 19:04:41 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Fri Jan 19 19:04:40 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Fri, 19 Jan 2001 19:03:39 +0100 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Pietro Biasci (TEI)" Message-ID: <6346FEEF1F24D31183830008C791C55B04D35B31@eitrmnt101.tei.ericsson.se> Date: Fri, 19 Jan 2001 19:04:40 +0100 Reply-To: "Pietro Biasci (TEI)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Pietro Biasci (TEI)" Subject: Re: [MOBILE-IP] all IP on 3gpp: MIPv6 X-To: "Dolan, Michael F (Mike)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi all, While 3GPP selected IPv6 as mandatory for IP Multimedia, it seems that 3GPP IMS architectures are neglecting for the moment MIPv6 (see for example 3G TS 23.228), I think for some different reasons (such as SIP location and mobility management built-in features), but I cannot completely understand why. In fact for the 3GPP Release 5, I was not able to find in 3GPP recent discussions about MIPv6 or TR/TS about that...MIPv6 seems out of scope, but I'm not sure it's a so good technical decision, if it is. Are you (or anybody of the list) able to clearly explain 3GPP technical viewpoint about MIPv6 in a Multimedia environment ? Interesting is also 3GPP2 point of view and timeframe. BR, /Pietro ERICSSON/// Pietro Biasci UMTS IP Networking E-mail * Pietro.Biasci@tei.ericsson.se -----Original Message----- From: Dolan, Michael F (Mike) [mailto:mfdolan@lucent.com] Sent: Friday, January 19, 2001 6:28 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] all IP on 3gpp Jaime, Hi! I am the vice-chair of the 3GPP2 All-IP Group. Please be assured that 3GPP2 certainly intends to support IPv6. That decision is already written into our adopted Requirements document. Mobile IP and specifically Mobile IPv6 have been at the core of many discussions for the last year or more, and are a basic tenet in our ongoing work. 3GPP2 already has IPv4 (and Mobile IPv4) built into its standards. Members of 3GPP2 TSG-P (Tom Hiller, Pat Calhoun, Pete McCann, Mark Lipford, and others) have been working closely with the Mobile IP WG for some time now to add needed extensions to Mobile IPv4 to support wireless environments. Since Mobile IPv4 is already a foundation block of 3GPP2 systems, 3GPP2 cannot abandon IPv4. Instead, an evolutionary path that moves 3GPP2 systems as quickly as possible to IPv6 is a hot work item. Your list of issues is a good one. It matches many similar lists held by others. I suggest that if you (or others) wish to continue this discussion, please contact me directly. That will help keep this email list for more technical topics. Thanks for your question. Have a good day, Mike Dolan 3GPP2 All-IP Vice-Chair Lucent Technologies mfdolan@lucent.com PH +1.630.979.1033 Mob +1.630.697.3549 -----Original Message----- From: Jaime Dias [mailto:jdias@inescporto.pt] Sent: Thursday, January 18, 2001 6:02 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] all IP on 3gpp Hi! I'm studying scenarios for the ALL IP in an UMTS environment. I've already see some approach with Cellular IPv6 and/or MIPv6, but that's where the confusion begin: Some approach byu 3G.IP refers about an MIP to the RNC. Until now the IP between the UE and the RNC are tunnelled, so, where the Cellular IP take place? In respect of the advantages of an IPv6 ALL IP, "I think" that it don't rest many doubts: Mobility as an inherent feature Route optimisation MIPv6 includes features to minimize loss in-flight packets during handover No foreign agents need to be deployed. Address space. QoS Security So, can anybody tell me why the 3GPP2 are so reluctant about the IPv6? I would be very thankful. Jaime Dias __________________________________________ Jaime Sousa Dias INESC Porto fone.: +351 22 2094258 fax:+351 22 2084172 Telecom & Multimedia Unit Porto, Portugal http://www.inescporto.pt/ http://telecom.inescn.pt __________________________________________ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 21 12:17:11 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09975 for ; Sun, 21 Jan 2001 12:17:10 -0500 (EST) Received: from standards (47.234.32.16:3500) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCEB2A@standards.nortelnetworks.com>; 21 Jan 2001 11:55:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26840 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 21 Jan 2001 11:55:05 -0500 Received: from web1004.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCEB28@standards.nortelnetworks.com>; 21 Jan 2001 11:55:04 -0500 Received: (qmail 25218 invoked by uid 60001); 21 Jan 2001 17:15:03 -0000 Received: from [208.61.160.110] by web1004.mail.yahoo.com; Sun, 21 Jan 2001 09:15:03 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Approved-By: Vasos Vassiliou Message-ID: <20010121171503.25217.qmail@web1004.mail.yahoo.com> Date: Sun, 21 Jan 2001 09:15:03 -0800 Reply-To: Vasos Vassiliou Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Vasos Vassiliou Subject: [MOBILE-IP] Hierarchical MIP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello all, I am researching the HMIP area and i was wondering if, besides the I-D on HMIP for MIPv6 there are any other IETF documents or pubished papers that you can point me to for further info. Thanks in advance Vasos VAssiliou Georgia Tech __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 23 11:59:27 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17699 for ; Tue, 23 Jan 2001 11:59:26 -0500 (EST) Received: from standards (47.234.32.16:4711) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCF462@standards.nortelnetworks.com>; Tue, 23 Jan 2001 11:36:51 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29957 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 23 Jan 2001 11:36:51 -0500 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCF460@standards.nortelnetworks.com>; Tue, 23 Jan 2001 11:36:50 -0500 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA06414 for ; Tue, 23 Jan 2001 09:56:54 -0700 (MST)] Received: [from az33exb01.corp.mot.com (az33exb01.corp.mot.com [199.2.84.12]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id JAA09234 for ; Tue, 23 Jan 2001 09:56:54 -0700 (MST)] Received: by az33exb01.corp.mot.com with Internet Mail Service (5.5.2651.58) id ; Tue, 23 Jan 2001 09:56:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Approved-By: White Douglas-P28617 Message-ID: <87568F78ABDCD211A0AC0008C707718B03ED8E05@az10exm03.sat.mot.com> Date: Tue, 23 Jan 2001 09:56:53 -0700 Reply-To: White Douglas-P28617 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: White Douglas-P28617 Subject: Re: [MOBILE-IP] all IP on 3gpp: MIPv6 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Pietro, I'm not qualified to give you a "3GPP technical viewpoint", but here's my observations in working with 3GPP, for what it's worth: MIPv6 is on the radar screen for at least *some* companies participating in 3GPP. A proposed work item was submitted to TSG SA2 from MWIF trying to get MIPv6 enhancements in Release 5 (started off as S2-001814 and was revised to S2-002061 --> ftp://ftp.3gpp.org/TSG_SA/WG2_Arch/TSGS2_15/tdocs/). The last I saw, it met some resitence, was slightly revised a couple of times (S2-002061rev2), and ended up getting shot down for various reason. The main reason being the lack of analysis performed to specifically address the impacts on the IMS. Keep in mind that MIPv6 in UMTS would not take the place of existing mobility management mechanisms, but would really just be there to support inter-system mobility. There was an brief email discussion on the SA2 email exploder discussing the proposed work item. If you (or anyone else) is interested, I have that email chain that I could send you if you want to see the history and reasons for not approving it. I just don't want to post it here in the interest of everyone else on this list :-) But long story short, without an approved work item in 3GPP no work will get (officially) done. As it stands, IMHO, 3GPP doesn't have any resemblence of an IPv6 inter-system mobility solution. I'm not sure what the plans are to reintroduce the proposal at a later date, but in order to have time to get the work done in the Release 5 time frame (~Dec 2001), I would imagine the work item would need to be approved rather soon. BR, Doug -----Original Message----- From: Pietro Biasci (TEI) [mailto:Pietro.Biasci@tei.ericsson.se] Sent: Friday, January 19, 2001 11:05 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] all IP on 3gpp: MIPv6 Importance: High Hi all, While 3GPP selected IPv6 as mandatory for IP Multimedia, it seems that 3GPP IMS architectures are neglecting for the moment MIPv6 (see for example 3G TS 23.228), I think for some different reasons (such as SIP location and mobility management built-in features), but I cannot completely understand why. In fact for the 3GPP Release 5, I was not able to find in 3GPP recent discussions about MIPv6 or TR/TS about that...MIPv6 seems out of scope, but I'm not sure it's a so good technical decision, if it is. Are you (or anybody of the list) able to clearly explain 3GPP technical viewpoint about MIPv6 in a Multimedia environment ? Interesting is also 3GPP2 point of view and timeframe. BR, /Pietro ERICSSON/// Pietro Biasci UMTS IP Networking E-mail * Pietro.Biasci@tei.ericsson.se -----Original Message----- From: Dolan, Michael F (Mike) [mailto:mfdolan@lucent.com] Sent: Friday, January 19, 2001 6:28 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] all IP on 3gpp Jaime, Hi! I am the vice-chair of the 3GPP2 All-IP Group. Please be assured that 3GPP2 certainly intends to support IPv6. That decision is already written into our adopted Requirements document. Mobile IP and specifically Mobile IPv6 have been at the core of many discussions for the last year or more, and are a basic tenet in our ongoing work. 3GPP2 already has IPv4 (and Mobile IPv4) built into its standards. Members of 3GPP2 TSG-P (Tom Hiller, Pat Calhoun, Pete McCann, Mark Lipford, and others) have been working closely with the Mobile IP WG for some time now to add needed extensions to Mobile IPv4 to support wireless environments. Since Mobile IPv4 is already a foundation block of 3GPP2 systems, 3GPP2 cannot abandon IPv4. Instead, an evolutionary path that moves 3GPP2 systems as quickly as possible to IPv6 is a hot work item. Your list of issues is a good one. It matches many similar lists held by others. I suggest that if you (or others) wish to continue this discussion, please contact me directly. That will help keep this email list for more technical topics. Thanks for your question. Have a good day, Mike Dolan 3GPP2 All-IP Vice-Chair Lucent Technologies mfdolan@lucent.com PH +1.630.979.1033 Mob +1.630.697.3549 -----Original Message----- From: Jaime Dias [mailto:jdias@inescporto.pt] Sent: Thursday, January 18, 2001 6:02 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] all IP on 3gpp Hi! I'm studying scenarios for the ALL IP in an UMTS environment. I've already see some approach with Cellular IPv6 and/or MIPv6, but that's where the confusion begin: Some approach byu 3G.IP refers about an MIP to the RNC. Until now the IP between the UE and the RNC are tunnelled, so, where the Cellular IP take place? In respect of the advantages of an IPv6 ALL IP, "I think" that it don't rest many doubts: Mobility as an inherent feature Route optimisation MIPv6 includes features to minimize loss in-flight packets during handover No foreign agents need to be deployed. Address space. QoS Security So, can anybody tell me why the 3GPP2 are so reluctant about the IPv6? I would be very thankful. Jaime Dias __________________________________________ Jaime Sousa Dias INESC Porto fone.: +351 22 2094258 fax:+351 22 2084172 Telecom & Multimedia Unit Porto, Portugal http://www.inescporto.pt/ http://telecom.inescn.pt __________________________________________ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 26 13:50:23 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17903 for ; Fri, 26 Jan 2001 13:50:23 -0500 (EST) Received: from standards (47.234.32.16:1157) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCF7D7@standards.nortelnetworks.com>; Fri, 26 Jan 2001 13:21:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20013 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 26 Jan 2001 13:21:24 -0500 Received: from s3.smtp.oleane.net (195.25.12.10:4620) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCF7BE@standards.nortelnetworks.com>; Fri, 26 Jan 2001 12:13:30 -0500 Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16]) by s3.smtp.oleane.net (Postfix) with ESMTP id C36A3213F4 for ; Wed, 24 Jan 2001 15:20:22 +0100 (CET) Received: from oleane (dyn-1-1-051.Vin.dialup.oleane.fr [195.25.4.51]) by smtp1.cluster.oleane.net with SMTP id f0OE41625612 for ; Wed, 24 Jan 2001 15:04:01 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01C08617.06F0FB80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Approved-By: Peter Lewis Message-ID: <005c01c0860e$a56fb700$8001a8c0@oleane.com> Date: Wed, 24 Jan 2001 15:05:02 +0100 Reply-To: Peter Lewis Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Peter Lewis Subject: [MOBILE-IP] IPCN '01 conference To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0059_01C08617.06F0FB80 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The request for proposals dead line for the IPCN '01 conference = (IP-based Cellular Networks) has been extended to February 15th. Please get more details at: http://www.upperside.fr/baipcn2001.htm ------=_NextPart_000_0059_01C08617.06F0FB80 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The request for proposals dead line = for the IPCN=20 '01 conference (IP-based Cellular Networks) has been = extended=20 to February 15th.
Please get more details = at:
http://www.upperside.fr/b= aipcn2001.htm
------=_NextPart_000_0059_01C08617.06F0FB80-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 26 13:50:25 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17933 for ; Fri, 26 Jan 2001 13:50:25 -0500 (EST) Received: from standards (47.234.32.16:1157) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCF813@standards.nortelnetworks.com>; Fri, 26 Jan 2001 13:21:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20116 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 26 Jan 2001 13:21:42 -0500 Received: from mgw-dax2.ext.nokia.com (63.78.179.217:36687) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCF7EA@standards.nortelnetworks.com>; Fri, 26 Jan 2001 12:28:11 -0500 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0O0ZX613400 for ; Tue, 23 Jan 2001 18:35:33 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 23 Jan 2001 18:33:56 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 23 Jan 2001 18:28:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Approved-By: Franck.Le@NOKIA.COM Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B028DBEB6@daeis07nok> Date: Tue, 23 Jan 2001 18:29:24 -0600 Reply-To: Franck.Le@nokia.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Le Franck Subject: [MOBILE-IP] Mobile IPv6 - IPsec question X-To: Mohan.Parthasarathy@eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, This question may have already been raised but why does in MIPv6, Home address need to be in cleartext since it seems that according to [RFC2401] section 5.2.1, the first SA look up will be based on the Destination IP Address, the IPsec protocol and SPI. You will then use the corresponding SA to decrypt/authenticate (step2) and after that, you will make sure if it matches the policy (using the packet's selectors such as the decrypted home address). Thank you. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 26 13:50:26 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17944 for ; Fri, 26 Jan 2001 13:50:25 -0500 (EST) Received: from standards (47.234.32.16:1157) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCF81A@standards.nortelnetworks.com>; Fri, 26 Jan 2001 13:21:44 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20129 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 26 Jan 2001 13:21:44 -0500 Received: from rajma.kniveton.com (63.197.0.77:1456) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCF7F1@standards.nortelnetworks.com>; Fri, 26 Jan 2001 12:33:44 -0500 Received: from [192.168.1.42] (qool.kniveton.com [192.168.1.42]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id f0NM3Ua47250 for ; Tue, 23 Jan 2001 14:03:32 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: "T.J. Kniveton" Message-ID: Date: Tue, 23 Jan 2001 14:03:54 -0800 Reply-To: "T.J. Kniveton" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "T.J. Kniveton" Subject: [MOBILE-IP] Any implementations of MobileIPv6 network renumbering? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, Does anyone have a Mobile IPv6 implementation which incorporates home subnet renumbering? (section 9.8 of Mobile IPv6 draft) And if so, are you planning on attending Connectathon in March to do interoperability testing? Feel free to reply to me directly. Thanks, -- TJ Kniveton NOKIA Research From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 26 13:50:26 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17953 for ; Fri, 26 Jan 2001 13:50:26 -0500 (EST) Received: from standards (47.234.32.16:1157) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCF823@standards.nortelnetworks.com>; Fri, 26 Jan 2001 13:21:47 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20146 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 26 Jan 2001 13:21:47 -0500 Received: from selene.cps.intel.com (192.198.165.10:4980) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCF7F9@standards.nortelnetworks.com>; Fri, 26 Jan 2001 12:36:36 -0500 Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by selene.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id MAA29874 for ; Wed, 24 Jan 2001 12:25:36 -0800 (PST) Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 24 Jan 2001 20:25:35 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 12:25:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Liu, Changwen" Message-ID: <7B3D67AA81EBD111AC4000A0C96B23F704FFE009@orsmsx32.jf.intel.com> Date: Wed, 24 Jan 2001 12:25:31 -0800 Reply-To: "Liu, Changwen" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Liu, Changwen" Subject: [MOBILE-IP] Mobile security association question To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > RFC2002 specifies mobile security association for providing security > services to Mobile IP protocol messages. Wonder anywork has being done for > establishing and refreshing mobile security association. For example, > IPsec uses IKE to establish SAs. Any similar work for the mobile security > association? > Thanks in advance. > changwen > P.S. It seems that my earlier posting of the above message to the list was lost. So send it again. Apologies for anyone who receives this message twice. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 26 13:50:29 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17984 for ; Fri, 26 Jan 2001 13:50:28 -0500 (EST) Received: from standards (47.234.32.16:1157) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCF848@standards.nortelnetworks.com>; Fri, 26 Jan 2001 13:21:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20206 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 26 Jan 2001 13:21:55 -0500 Received: from mgw-dax1.ext.nokia.com (63.78.179.216:52976) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCF810@standards.nortelnetworks.com>; Fri, 26 Jan 2001 12:57:23 -0500 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0OIlBR19818 for ; Wed, 24 Jan 2001 12:47:11 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 24 Jan 2001 12:47:09 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 24 Jan 2001 12:47:09 -0600 Expiry-Date: Fri, 26 Jan 2001 12:46:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain Approved-By: Franck.Le@NOKIA.COM Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B028DBEC0@daeis07nok> Date: Wed, 24 Jan 2001 12:42:35 -0600 Reply-To: Franck.Le@nokia.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Le Franck Subject: [MOBILE-IP] Recall: Mobile IPv6 - IPsec question X-To: Mohan.Parthasarathy@eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Le Franck (NRC/Dallas) would like to recall the message, "Mobile IPv6 - IPsec question". From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jan 26 14:14:27 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18890 for ; Fri, 26 Jan 2001 14:14:27 -0500 (EST) Received: from standards (47.234.32.16:1157) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCFC21@standards.nortelnetworks.com>; Fri, 26 Jan 2001 13:48:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21528 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 26 Jan 2001 13:48:24 -0500 Received: from thalia.fm.intel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBCFC1C@standards.nortelnetworks.com>; Fri, 26 Jan 2001 13:48:23 -0500 Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id BAA08011 for ; Wed, 24 Jan 2001 01:38:14 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 24 Jan 2001 01:36:49 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 23 Jan 2001 17:36:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Liu, Changwen" Message-ID: <7B3D67AA81EBD111AC4000A0C96B23F704FFE006@orsmsx32.jf.intel.com> Date: Tue, 23 Jan 2001 17:36:46 -0800 Reply-To: "Liu, Changwen" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Liu, Changwen" Subject: [MOBILE-IP] Mobile security association question To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM RFC2002 specifies mobile security association for providing security services to Mobile IP protocol messages. Wonder anywork has being done for establishing and refreshing mobile security association. For example, IPsec uses IKE to establish SAs. Any similar work for the mobile security association? Thanks in advance. changwen From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 28 10:35:38 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08907 for ; Sun, 28 Jan 2001 10:35:37 -0500 (EST) Received: from standards (47.234.32.16:4793) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD0214@standards.nortelnetworks.com>; 28 Jan 2001 10:13:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23537 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 28 Jan 2001 10:13:03 -0500 Received: from mr.tuwien.ac.at by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD0212@standards.nortelnetworks.com>; 28 Jan 2001 10:13:02 -0500 Received: from pop.tuwien.ac.at (phaeton.ikn.tuwien.ac.at [128.131.88.62]) by mr.tuwien.ac.at (8.11.1/8.11.1) with ESMTP id f0SFXHP13792 for ; Sun, 28 Jan 2001 16:33:21 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <20010121171503.25217.qmail@web1004.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Nam Hoang Nguyen Message-ID: <3A7444EA.48EF355C@pop.tuwien.ac.at> Date: Sun, 28 Jan 2001 17:12:26 +0100 Reply-To: Hoang.Nguyen-Nam@tuwien.ac.at Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Nam Hoang Nguyen Subject: [MOBILE-IP] HELP : Handover !!! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear mobile-IP experts ! I have a simple question about INTER-network (inter-domain) handover: Is this true that : new link layer connectivity could be only established AFTER network-layer (here IP) handover finishes ??????? Note: I get confusion while reading about fast handover draft where it is wrote that IP-layer handover could be initiated through new link layer connectivity. I suppose that it is only true for Intra-domain but I am not sure. Many thanks in advance ! Nam From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jan 28 21:07:18 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11269 for ; Sun, 28 Jan 2001 21:07:13 -0500 (EST) Received: from standards (47.234.32.16:2494) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD030D@standards.nortelnetworks.com>; 28 Jan 2001 20:44:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23869 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 28 Jan 2001 20:44:49 -0500 Received: from hp06.postech.ac.kr (141.223.2.1:3344) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD030B@standards.nortelnetworks.com>; 28 Jan 2001 20:44:48 -0500 Received: from postech.ac.kr (comus.postech.ac.kr [141.223.92.55]) by hp06.postech.ac.kr (8.9.3/8.9.3) with ESMTP id LAA02290 for ; Mon, 29 Jan 2001 11:10:51 +0900 (JST) X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,ko MIME-Version: 1.0 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Approved-By: Geunhyung Kim Message-ID: <3A74CEB3.3A9800C5@postech.ac.kr> Date: Mon, 29 Jan 2001 11:00:19 +0900 Reply-To: Geunhyung Kim Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Geunhyung Kim Subject: [MOBILE-IP] Difference between IPv4 MIP and IPv6 MIP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello All, I am Geunhyung Kim and a newbie in Mobile IP. In the IETF works, there are two individual activities for IPv4 MIP and IPv6 MIP. Could you explain the difference between IPv4 MIP and IPv6 MIP activities ? Thanks in advance Geunhyung Kim -- None of us is as smart as all of us ========================================== Geunhyung Kim E-mail: geunkim@postech.ac.kr Tel: +82-54-279-5655 Fax: +82-54-279-5699 Networking & Distributed Systems Lab. CSE POSTECH =========================================== From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 30 11:57:17 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12717 for ; Tue, 30 Jan 2001 11:57:17 -0500 (EST) Received: from standards (47.234.32.16:3117) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD0BE9@standards.nortelnetworks.com>; Tue, 30 Jan 2001 11:34:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21323 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 30 Jan 2001 11:34:17 -0500 Received: from thumper.research.telcordia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD0BE7@standards.nortelnetworks.com>; Tue, 30 Jan 2001 11:34:17 -0500 Received: from shannon.research.telcordia.com (shannon [128.96.73.2]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f0UGsgO02065; Tue, 30 Jan 2001 11:54:42 -0500 (EST) Received: from research.telcordia.com (extranet-243.cc.telcordia.com [192.4.246.243]) by shannon.research.telcordia.com (8.8.8/8.8.8) with ESMTP id LAA28868; Tue, 30 Jan 2001 11:54:39 -0500 (EST) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Sudha Ramesh Message-ID: <3A76F201.D7D27B14@research.telcordia.com> Date: Tue, 30 Jan 2001 11:55:29 -0500 Reply-To: Sudha Ramesh Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sudha Ramesh Subject: [MOBILE-IP] Who implements MIP? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit First of all, I am sorry if this is a repeat question for some/most of you. I have been unable to access the archive over the web (May be the IEEE pages point to the wrong address!) Does anyone know who implement Mobile IP in their products? My guess is that the v4 version is implemented. Does anyone do v6? Is anyone implementing the route optimization extensions? Thanks for all your help. Sudha Ramesh From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 30 14:53:34 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16602 for ; Tue, 30 Jan 2001 14:53:33 -0500 (EST) Received: from standards (47.234.32.16:2609) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD0CEE@standards.nortelnetworks.com>; Tue, 30 Jan 2001 14:31:14 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21654 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 30 Jan 2001 14:31:13 -0500 Received: from quartz.airtouch.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD0CEC@standards.nortelnetworks.com>; Tue, 30 Jan 2001 14:31:12 -0500 Received: from Notes.airtouch.com (ath-irv-smtp1.it.cl.airtouch.com [153.114.55.212]) by quartz.airtouch.com (8.8.8+Sun/8.8.8) with SMTP id LAA27166 for ; Tue, 30 Jan 2001 11:51:48 -0800 (PST) Received: by Notes.airtouch.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882569E4.006D3305 ; Tue, 30 Jan 2001 11:52:44 -0800 X-Lotus-FromDomain: AIRTOUCH Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Approved-By: Bryan_Cook@NOTES.AIRTOUCH.COM Message-ID: <882569E4.006D30F3.00@Notes.airtouch.com> Date: Tue, 30 Jan 2001 11:49:21 -0800 Reply-To: Bryan_Cook@Notes.airtouch.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Bryan Cook Subject: [MOBILE-IP] Interoperability Testing for Mobile IP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, I'm interested in interoperability sessions for Mobile IP and similar technologies. I know that Connectathon is getting ready to happen, but are there other session planned - hopefully that give more accessibility to results to carriers, etc. Thanks, Bryan From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 30 17:15:21 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18301 for ; Tue, 30 Jan 2001 17:15:19 -0500 (EST) Received: from standards (47.234.32.16:3371) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD0E04@standards.nortelnetworks.com>; Tue, 30 Jan 2001 16:53:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21993 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 30 Jan 2001 16:53:07 -0500 Received: from quartz.airtouch.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD0E02@standards.nortelnetworks.com>; Tue, 30 Jan 2001 16:53:07 -0500 Received: from Notes.airtouch.com (ath-irv-smtp1.it.cl.airtouch.com [153.114.55.212]) by quartz.airtouch.com (8.8.8+Sun/8.8.8) with SMTP id OAA29319; Tue, 30 Jan 2001 14:13:39 -0800 (PST) Received: by Notes.airtouch.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882569E4.007A2A47 ; Tue, 30 Jan 2001 14:14:22 -0800 X-Lotus-FromDomain: AIRTOUCH Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Approved-By: Bryan_Cook@NOTES.AIRTOUCH.COM Message-ID: <882569E4.007A288E.00@Notes.airtouch.com> Date: Tue, 30 Jan 2001 14:11:55 -0800 Reply-To: Bryan_Cook@Notes.airtouch.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Bryan Cook Subject: Re: [MOBILE-IP] Interoperability Testing for Mobile IP X-To: James Kempf To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Thanks for the responses concerning Connectathon and interoperability testing. The problem, from the vantage point of a carrier, is that it is very difficult for us to take advantage of what it has to offer. We want to be assured that our vendors have interoperability with each other and also operate correctly with standards (RFC2002, etc.) Be assued that I understand the reasons for the results being kept confidential. However, for it to benefit a carrier, we must have accessibility to the outcomes. Of course, individual vendors can supply them to us under NDA, etc., but there is nothing like 3rd party certification. I would interested in a Connectathon type event where results ARE public. Something that vendors attend to demonstrate interoperability after they have worked out problems or issues that might have been caught in something like Connectathon. Does such a public event exist? Thanks, Bryan James Kempf on 01/30/2001 12:52:24 PM To: Bryan Cook/Corporate/AirTouch@AirTouch cc: Subject: Re: [MOBILE-IP] Interoperability Testing for Mobile IP What's the problem with attending Connectathon? Anybody can attend. I think they prorate the fees such that you don't have to pay full price unless you want to do testing. If not, you only need to find somebody with an implementation that will let you tag along. jak At 11:49 AM 1/30/01 -0800, you wrote: >Hi, > >I'm interested in interoperability sessions for Mobile IP and similar >technologies. I know that Connectathon >is getting ready to happen, but are there other session planned - >hopefully that >give more accessibility to >results to carriers, etc. > >Thanks, >Bryan From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 30 18:13:48 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18995 for ; Tue, 30 Jan 2001 18:13:47 -0500 (EST) Received: from standards (47.234.32.16:3371) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD0EC1@standards.nortelnetworks.com>; Tue, 30 Jan 2001 17:51:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22247 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 30 Jan 2001 17:51:35 -0500 Received: from tuan.cse.rmit.EDU.AU (131.170.118.1:50849) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD0EBF@standards.nortelnetworks.com>; Tue, 30 Jan 2001 17:51:34 -0500 Received: from wombat.cse.rmit.EDU.AU (s9902666@wombat.cse.rmit.edu.au [131.170.118.15]) by tuan.cse.rmit.EDU.AU (8.9.1a/8.9.1) with ESMTP id KAA11611; Wed, 31 Jan 2001 10:11:57 +1100 (EST) Received: from localhost (s9902666@localhost) by wombat.cse.rmit.EDU.AU (8.8.8+Sun/8.8.8) with SMTP id KAA03853; Wed, 31 Jan 2001 10:11:24 +1100 (EST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Ha Thanh Le Message-ID: Date: Wed, 31 Jan 2001 10:11:23 +1100 Reply-To: Ha Thanh Le Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ha Thanh Le Subject: Re: [MOBILE-IP] Who implements MIP? X-To: Sudha Ramesh To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <3A76F201.D7D27B14@research.telcordia.com> Hi, I currently know that there are at least two MIP v4 models contributed to the OPNET open library. And there is no model for v6 in OPNET. To archieve the model in OPNET open library, go in http://www.opnet.com. Cheers, Ha Thanh Le (9902666S - CSE.RMIT) ---------------------------------- e-mail: s9902666@student.rmit.edu.au On Tue, 30 Jan 2001, Sudha Ramesh wrote: > First of all, I am sorry if this is a repeat question for some/most of > you. > I have been unable to access the archive over the web (May be the IEEE > pages point to the wrong address!) > > Does anyone know who implement Mobile IP in their products? My guess > is that the v4 version is implemented. Does anyone do v6? Is anyone > implementing the route optimization extensions? > > Thanks for all your help. > > Sudha Ramesh > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 30 19:31:28 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19680 for ; Tue, 30 Jan 2001 19:31:27 -0500 (EST) Received: from standards (47.234.32.16:3501) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD0F7B@standards.nortelnetworks.com>; Tue, 30 Jan 2001 19:09:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22496 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 30 Jan 2001 19:09:16 -0500 Received: from ms.hansol.co.kr (210.112.2.207:3410) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD0F79@standards.nortelnetworks.com>; Tue, 30 Jan 2001 19:09:16 -0500 Received: from ns ([211.113.87.7]) by ms.hansol.co.kr (8.9.3/8.9.3) with SMTP id JAA23515; Wed, 31 Jan 2001 09:25:42 +0900 References: <3A76F201.D7D27B14@research.telcordia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Approved-By: Jiwoong Lee Message-ID: <004f01c08b1c$fc0c8d00$0f00a8c0@hansol.co.kr> Date: Wed, 31 Jan 2001 09:29:42 +0900 Reply-To: Jiwoong Lee Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jiwoong Lee Subject: Re: [MOBILE-IP] Who implements MIP? X-To: Sudha Ramesh To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id TAA19680 Most of the IMT-2000 wireless cellular network device vendors do. Jiwoong Lee ----- Original Message ----- From: Sudha Ramesh To: Sent: Wednesday, January 31, 2001 1:55 AM Subject: [MOBILE-IP] Who implements MIP? > First of all, I am sorry if this is a repeat question for some/most of > you. > I have been unable to access the archive over the web (May be the IEEE > pages point to the wrong address!) > > Does anyone know who implement Mobile IP in their products? My guess > is that the v4 version is implemented. Does anyone do v6? Is anyone > implementing the route optimization extensions? > > Thanks for all your help. > > Sudha Ramesh > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 30 19:59:52 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19816 for ; Tue, 30 Jan 2001 19:59:51 -0500 (EST) Received: from standards (47.234.32.16:3501) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD100E@standards.nortelnetworks.com>; Tue, 30 Jan 2001 19:37:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22692 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 30 Jan 2001 19:37:39 -0500 Received: from ms.samsung.com (211.45.29.136:45466) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD100C@standards.nortelnetworks.com>; Tue, 30 Jan 2001 19:37:38 -0500 Received: from keg ([203.241.48.20]) by ms.samsung.com (Netscape Messaging Server 4.15) with SMTP id G8059Q00.588 for ; Wed, 31 Jan 2001 09:56:14 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Approved-By: wjkim@SAMSUNG.COM Message-ID: <013301c08b1f$f5d507c0$88b2d5a5@keg.telecom.samsung.co.kr> Date: Wed, 31 Jan 2001 09:51:34 +0900 Reply-To: Woo-June Kim Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Woojune Kim Subject: Re: [MOBILE-IP] Who implements MIP? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id TAA19816 Which is really saying very little. As none of them have products out there that works. The closest is the 2.5G cdma2000 1xRTT systems that are currently in commercial service in Korea (as I am sure you are aware), but even they do not have any commercial mobile IP terminals. It would help if (as numerous people have said) if Microsoft would get around to really supporting Mobile IP v4 / v6 in their OS ... Woojune Kim, Senior Engineer Samsung Electronics Ltd. Most of the IMT-2000 wireless cellular network device vendors do. Jiwoong Lee ----- Original Message ----- From: Sudha Ramesh To: Sent: Wednesday, January 31, 2001 1:55 AM Subject: [MOBILE-IP] Who implements MIP? > First of all, I am sorry if this is a repeat question for some/most of > you. > I have been unable to access the archive over the web (May be the IEEE > pages point to the wrong address!) > > Does anyone know who implement Mobile IP in their products? My guess > is that the v4 version is implemented. Does anyone do v6? Is anyone > implementing the route optimization extensions? > > Thanks for all your help. > > Sudha Ramesh > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jan 30 20:07:59 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19898 for ; Tue, 30 Jan 2001 20:07:59 -0500 (EST) Received: from standards (47.234.32.16:3501) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD106E@standards.nortelnetworks.com>; Tue, 30 Jan 2001 19:45:44 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22813 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 30 Jan 2001 19:45:43 -0500 Received: from u-mail.rd.francetelecom.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD106C@standards.nortelnetworks.com>; Tue, 30 Jan 2001 19:45:43 -0500 Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0) id ; Tue, 30 Jan 2001 17:06:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08B21.FE9BAEF2" Approved-By: HUYLEBROECK Jeremy / FTR&D Message-ID: <337055FBC675D311A85D00508B5A9C4F9AEA52@u-mail.rd.francetelecom.com> Date: Tue, 30 Jan 2001 17:06:08 -0800 Reply-To: HUYLEBROECK Jeremy / FTR&D Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: HUYLEBROECK Jeremy / FTR&D Subject: Re: [MOBILE-IP] Who implements MIP? 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_01C08B21.FE9BAEF2 Content-Type: text/plain; charset="EUC-KR" I thought Nextel uses M-IP already on its network (in USA at least). I am wrong if I say they must have MIP equipment then ? Jeremy Huylebroeck France Telecom R&D -----Original Message----- From: Woojune Kim [mailto:wjkim@samsung.com] Sent: Tuesday, January 30, 2001 4:52 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Who implements MIP? Which is really saying very little. As none of them have products out there that works. The closest is the 2.5G cdma2000 1xRTT systems that are currently in commercial service in Korea (as I am sure you are aware), but even they do not have any commercial mobile IP terminals. It would help if (as numerous people have said) if Microsoft would get around to really supporting Mobile IP v4 / v6 in their OS ... Woojune Kim, Senior Engineer Samsung Electronics Ltd. Most of the IMT-2000 wireless cellular network device vendors do. Jiwoong Lee ----- Original Message ----- From: Sudha Ramesh To: Sent: Wednesday, January 31, 2001 1:55 AM Subject: [MOBILE-IP] Who implements MIP? > First of all, I am sorry if this is a repeat question for some/most of > you. > I have been unable to access the archive over the web (May be the IEEE > pages point to the wrong address!) > > Does anyone know who implement Mobile IP in their products? My guess > is that the v4 version is implemented. Does anyone do v6? Is anyone > implementing the route optimization extensions? > > Thanks for all your help. > > Sudha Ramesh > ------_=_NextPart_001_01C08B21.FE9BAEF2 Content-Type: text/html; charset="EUC-KR" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] Who implements MIP?

I thought Nextel uses M-IP already on its network (in = USA at least).
I am wrong if I say they must have MIP equipment = then ?

Jeremy Huylebroeck
France Telecom R&D

-----Original Message-----
From: Woojune Kim [mailto:wjkim@samsung.com]
Sent: Tuesday, January 30, 2001 4:52 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] Who implements MIP?


Which is really saying very little. As none of them = have products out there that works.

The closest is the 2.5G cdma2000 1xRTT systems that = are currently in commercial service in Korea (as I am sure you are = aware), but even they do not have any commercial mobile IP terminals. =

It would help if (as numerous people have said) if = Microsoft would get around to really supporting Mobile IP v4 / v6 in = their OS ...

Woojune Kim,
Senior Engineer
Samsung Electronics Ltd.


Most of the IMT-2000 wireless cellular network device = vendors do.

Jiwoong Lee

----- Original Message -----
From: Sudha Ramesh = <sudha@research.telcordia.com>
To: = <MOBILE-IP@STANDARDS.NORTELNETWORKS.COM>
Sent: Wednesday, January 31, 2001 1:55 AM
Subject: [MOBILE-IP] Who implements MIP?


> First of all, I am sorry if this is a repeat = question for some/most of
> you.
> I have been unable to access the archive over = the web (May be the IEEE
> pages point to the wrong address!)
>
> Does anyone know who implement Mobile IP in = their products? My guess
> is that the v4 version is implemented. Does = anyone do v6? Is anyone
> implementing the route optimization = extensions?
>
> Thanks for all your help.
>
> Sudha Ramesh
>

------_=_NextPart_001_01C08B21.FE9BAEF2-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jan 31 06:33:32 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09045 for ; Wed, 31 Jan 2001 06:33:32 -0500 (EST) Received: from standards (47.234.32.16:4757) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD1476@standards.nortelnetworks.com>; Wed, 31 Jan 2001 6:11:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24164 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 31 Jan 2001 06:11:14 -0500 Received: from zooty.lancs.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD1474@standards.nortelnetworks.com>; Wed, 31 Jan 2001 6:11:14 -0500 Received: from exchange-ims.lancs.ac.uk ([148.88.17.22]) by zooty.lancs.ac.uk with esmtp (Exim 3.16 #1) id 14NvUC-0001yN-00; Wed, 31 Jan 2001 11:31:40 +0000 Received: by exchange-ims.lancs.ac.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 31 Jan 2001 11:31:43 -0000 X-Mailer: Internet Mail Service (5.5.2650.21) Approved-By: "Finney, Joe" Message-ID: <7823222F821AD311844800204840353A0358B306@exchange2.lancs.ac.uk> Date: Wed, 31 Jan 2001 11:31:40 -0000 Reply-To: "Finney, Joe" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Finney, Joe" Subject: Re: [MOBILE-IP] Who implements MIP? X-To: Sudha Ramesh To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, > First of all, I am sorry if this is a repeat question for some/most of > you. > I have been unable to access the archive over the web (May be the IEEE > pages point to the wrong address!) > > Does anyone know who implement Mobile IP in their products? My guess > is that the v4 version is implemented. Does anyone do v6? Is anyone > implementing the route optimization extensions? > > Thanks for all your help. > For info, as part of the LandMARC project we've been developing a Mobile IPv6 implementation (mobile node, correspondent node and home agent) for Windows in collaboration with Microsoft Research. The code currently runs on Windows NT and Windows 2000 and we're planning to look at CE in the near future. The code has just gone to public release a few weeks ago, so you can download it and try it out if you like. See http://www.LandMARC.net for more info. We also have a Linux implementation which we're currently bringing up to date, which will be released in the next month or so. Thanks, Joe -------------------------------------------------------------------- Dr. Joe Finney e-mail: joe@comp.lancs.ac.uk Computing Dept, tel: (+44) (0)1524 592732 Faculty of Applied Sciences, Lancaster University, Lancaster, fax: (+44) (0)1524 593608 UK. www: http://www.comp.lancs.ac.uk/ computing/staff/joe LA1 4YR ---------------------------------------------------------------------